咱们真的须要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