我们真的需要Service Mesh吗？

George Miranda

业务对于Service Mesh微服务架构的讨论热度居高不下，很多人认为Service Mesh将是云原生应用基础设施解决方案的MUST，它在构建健壮微服务架构应用时的能量令人印象深刻。不过在人气飙升的同时，人们对于落地Service Mesh的确切价值仍有困惑，因此有必要深入了解什么是Service Mesh以及它解决了哪些问题，以便我们确定是否真的需要Service Mesh。

Service Mesh

Service Mesh是一个用于处理服务之间通信的基础结构层，其体系结构的具体细节在不同实现中略有差异。一般来说，每个Service Mesh都是作为一个系列(或“mesh”)实现的，这些相互连接的网络代理设计允许我们更优雅地管理服务流量（service traffic）。

该解决方案随着微服务架构的广泛接受而兴起，它引入了一种全新的通信流量（communication traffic）概念。但不幸的是，采用者往往没有做太多的考虑。这有时被归因为南北流量模式与东西流量模式的区别。简单来说，南北流量是server-to-client流量，而东西流量则是server-to-server流量。以上命名来源于“映射”网络流量的关系图，图中通常用垂直线表示server-client流量，水平线表示server-to-server流量。在Server-to-server流量世界里，除了对网络和传输层(L3/L4)考量，在会话层（session layer）中还有一个重要的差异要考虑。

在这个新的世界中，service-to-service通信成为了应用在应用时行为的基本决定因素。应用函数在本地作为相同运行时的一部分出现，而不是以在不可靠的网络上传输的远程过程调用出现。这意味着，反映业务需求的复杂决策树（decision tree）的成功或失败，现在需要您考虑分布式系统编程的现实。对于大多数人来说，这是一个新的专业领域，需要创建并在代码中编写大量定制的工具。而Service Mesh，减轻了应用开发人员的负担，将工具与应用分离开来，并将这种“责任”推到了基础架构层。

使用Service Mesh，每个应用的endpoint(无论是容器、pod还是主机，无论如何在部署中设置这些endpoint)都被配置为“将通信路由到本地代理”(例如以sidecar容器形式安装)。本地代理公开了可以用于管理诸如重试逻辑、加密机制、自定义路由规则、服务发现等内容的原语。这些代理的集合构成了一个“网格”服务，共享公共网络流量的管理属性。这些代理可以从一个集中的控制平面进行控制，操作人员可以在该控制平面中对影响整个网格行为的策略加以组合。

由于service-to-service的通信是基于微服务的应用运行时行为的基本决定因素，能够从Sercice Mesh中获取价值的最明显的地方是管理用于远程过程调用(或API调用)的消息。对比Service Mesh和其他消息管理解决方案，如面向消息的中间件、企业服务总线(ESB)、企业应用程序集成模式(EAI)或API网关，Service Mesh可能与其中的一些功能有轻微重叠，但是作为一个整体，它面对的是一个更大的问题集。

Service Mesh是作为基础设施实现的，位于应用之外，因此应用不需要修改任何代码就可以使用Service Mesh。Service Mesh的价值起初是在检查rpc(或消息)管理时实现的，随后扩展到了所有入站和出站流量的管理。与直接将远程通信管理编码到应用中不同，Service Mesh允许您更容易地跨整个分布式基础设施管理该逻辑。

The problem space

Service Mesh的核心是解决管理分布式系统带来的固有挑战。这并不是一格新的问题，但在微服务数量激增的情况下，越来越多用户开始面对这些问题。而关于分布式系统，存在着一下谬误——

网络是可靠的（The Network is Reliable）
延迟为零（Latency is Zero）
带宽是无限的（Bandwidth is Infinite）
网络是安全的（The Network is Secure）
拓扑不会改变（Topology does not Change）
有一名管理员（There is one Administrator）
传输成本为零（Transport Cost is Zero）
网络是同质的（The Network is Homogenous）

了解更多：Service Mesh微服务架构的崛起

这些错误往往会在大规模运行时出现，往往在发现时已经太晚了，不过好在，经过这么多年的实践，已经有了不少经过验证的解决方案。

过去，应用开发人员通过在应用中直接创建自定义工具来解决这些问题：打开一个socket、传输数据、在某个特定的时间段内重新尝试，当事务不可避免地需要终止时关闭socket，等等。分布式应用的编程负担直接落在了每个开发人员的肩上，因此这样做的逻辑与每个分布式应用紧密耦合。

作为实现可重用解决方案的渐进步骤，出现了网络弹性库(如Netflix的Hystrix或Twitter的Finagle)。在我们的应用代码中包含这些库，现在您已经准备好了一组预先开发的工具。虽然这些解决方案取得了令人难以置信的飞跃，但它们对多语言应用的价值有限。不同的编程语言需要不同的库，然后我们会遇到管理两者之间集成的挑战。在这一模型中，不同应用endpoint之间的一致管理是一个固有的挑战。

对于Service Mesh，它旨在解决分布式系统编程的挑战，这意味着我们需要首先搞明白一个问题：我们应用基础结构中，是否有许多服务彼此通信？

当然，如果我们主要管理的是一体化架构应用，我们也可以从Service Mesh中获得些许价值。

如果我们管理的是较小的服务，那么处理分布式计算错误的工作不可避免。随着微服务架构应用的发展，新特性通常作为附加的外部服务引入，我们对于Service Mesh的需求也将不断增长。

Service Mesh的存在解决了可靠性(重试、超时、减轻级联故障)、故障诊断(可观察性、监视、跟踪、诊断)、性能(吞吐量、延迟、负载平衡)、安全性(管理机密、确保加密)、动态拓扑(服务发现、自定义路由)以及在生产中管理微服务时常见的问题。

如果我们目前正在面临这些问题，或者已经次啊用了云原生和微服务架构，那么我们应该研究一下Service Mesh工具，并确定它是否适用于我们的环境。想要避免被各种炒作迷乱了双眼，我们应该量化Service Mesh的价值，而办法就像我们刚才讨论的那样，关注这类工具的存在并探索它是否可以解决特定的问题。

• END -

关于Rainbond

Rainbond是一款以应用为中心的开源PaaS，由好雨基于Docker、Kubernetes等容器技术自主研发，可作为公有云或私有云环境下的应用交付平台、DevOps平台、自动化运维平台和行业云平台，或作为企业级的混合云多云管理工具、Kubernetes容器管理工具或Service Mesh微服务架构治理工具。

• Rainbond项目网站
• 试用Rainbond公有云
  • 注册或使用Demo账号/密码登录：rainbond-demo/rainbond-demo
• Github
• 码云
• 文档
• 微信群: 添加微信“zqg5258423”并接受邀请入群

阅读更多

• 技术 Service Mesh真的是云原生应用的绝配吗？
• 技术 Service Mesh微服务架构的崛起 2018/0706
• 技术 Service Mesh：什么是Sidecar模式 2018/06/21
• 技术 开源PaaS Rainbond v3.6.0正式发布，Service Mesh开箱即用 2018/06/20
• 技术 解读Rainbond ServiceMesh微服务架构_开源PaaS Rainbond 2018/05/15
• 技术 Pinpoint-java性能分析最佳实践_开源PaaS Rainbond 2018/05/08
• 技术 通过Minio搭建私有化对象存储服务_开源PaaS Rainbond 2018/04/26
• 技术 揭秘高可用负载均衡组件Rainbond-Entrance_开源PaaS Rainbond 2018/04/25
• 技术 Rainbond插件体系设计简介_开源PaaS Rainbond 2018/02/24
• 技术 Rainbond如何对接外部Maven仓库_开源PaaS Rainbond 2018/01/18
• 技术 Spring Boot框架配置MySQL_开源PaaS Rainbond 2018/01/10
• 技术 基于Midonet的多租户网络设计_开源PaaS Rainbond 2018/01/09