Service Mesh服务网格：是什么和为何

Service Mesh（服务网格）会是今年微服务生态的主角吗？从趋势来看，众多企业正在将这项理微服务复杂性的技术/工具，搬进他们的IT“火药库”之中。

什么是Service Mesh？

根据Linkerd CEO William Morgan定义，Service Mesh是用于处理服务间通讯的基础设施层，用于在云原生应用复杂的服务拓扑中实现可靠的请求传递。在实践中，Service Mesh一般是一组与应用一块儿部署，但对应用透明的轻量级网络代理。

Service Mesh与传统基础设施层不一样之处在于，它造成了一个分布式的互连代理网络，以sidecar形式部署在服务两侧，服务对于代理无感知，且服务间全部通讯都由代理进行路由。

为何须要Service Mesh？

“Smart endpoint and dumb pipes”是微服务架构在集成服务时采用的一个核心理念，这一理念改变了过去臃肿集中的ESB（企业服务总线），无疑是正确方向上的一大进步，但同时也给咱们出了一些难题——多智能才不会过于智能，而服务轻重大小的程度如何拿捏？咱们应该如何处理微服务系统中服务间交互的复杂性？放在服务内部仍是外部？若是是内部，如何处理业务逻辑关系，或者应该与基础设施更为相关？若是是外部，如何避免重蹈ESB的覆辙？

皮的不谈，先来看看处理服务间通讯时须要关注的点：

• 服务发现
• 负载均衡
• 路由
• 流量控制
• 通讯可靠性
• 弹性
• 安全
• 监控/日志

彷佛都是老生常谈，存在于任何须要处理网络的分布式系统之中，区别在于，当所涉及微服务数量呈指数级增长，这些问题也会被相应放大。

一个已经被普遍应用的解决方案是利用api网关来处理服务外部和服务之间的请求，提供例如服务发现、路由、监控、流量控制等。

然而，api网关有一个比较致命的缺陷，它容易出现单点故障而且实践不当颇有可能会变得异常臃肿。另外一方面，api网关核心是面向用户，也就是说它能够解决从用户到微服务的流量问题，但不能解决全部问题，而咱们须要的是一个完整的方案，或者至少是一些可以与api网关互补的方案和工具。

另外一种选择是在网络堆栈的较低层级（4/3）进行可靠性、监控、流量控制等方面处理。这种选择的问题是，在较低较低的操做难易知足应用层的问题。联想end-to-end（端到端）的理论，咱们前面提到的那几个关注点实际上仍是集中在应用层，也只能在应用层成功实现。

像Netflix、Twitter等SOA/微服务的早期采用者，他们经过创建内部库的方式处理这些问题，而后提供给全部服务使用。这种方法的问题在于，把库扩展到成百上千个微服务中难度极高，并且这些库相对来讲是比较”脆弱“的，咱们很难保证他们能够适应全部的技术堆栈选择。

程度上来讲，Service Mesh与这些库很相似，但Service Mesh是与服务相邻的独立进程。服务链接到代理，代理反过来又与其余代理（HTTP1.1/二、GRPC）进行通讯。它们是相对独立的进程，在应用层或应用层之下分布和运行，进而解决了上述两个方案存在的缺陷。

Service Mesh架构

Service Mesh由data plane构成，其中全部服务经过sidecar代理进行服务通讯。（全部代理相互链接造成一个Mesh，Service Mesh由此得名）网格同时包含一个control plane——能够将全部独立的sidecar代理链接到一个分布式网络中，并设置网格还包括一个控制平面——它将全部独立的sidecar代理链接到一个分布式网络中，并设置由data plane指定的策略。

Control plane定义服务发现、路由、流量控制等策略。这些策略能够是全局的，也能够是限定的。Data plane负责在通讯时应用和执行这些策略。

最后

总结来讲，Service Mesh是“时间的产物”，Docker、Kubernetes等容器技术直接推动了对于Service Mesh的需求，让复杂的系统能够被轻松部署和管理。

将来Service Mesh将如何发展还未可知，或许会像TCP/IP同样造成标准，或许不一样工具和平台会独具一格……但有一点是确认的，Service Mesh对于微服务生态的价值使人难以忽视，可以将繁重的服务治理工做变得简单高效，何乐而不为？

---

相关阅读

• 技术解读Rainbond ServiceMesh微服务架构_开源PaaS Rainbond 2018/05/15

开源PaaS Rainbond原生支持Service Mesh，在线体验请注册公有云（新用户7天免费）