Service Mesh 是什么？为什么我们需要它。

  原文：https://dzone.com/articles/whats-a-service-mesh-and-why-do-i-need-one

## service mesh 有的翻译成服务网格化，在这里不作翻译直接使用英文感觉可以正确的理解。

     在过去的几年中，service mesh 已经云化（微服务）本地应用堆栈中重要组件。许多公司也开源的相应本地云化Service mesh组件，并且成为微服务化项目组织的和重要项目。但是什么是Service Mesh？我们要做如何正确的理解？

     下面，我们会探索service mesh 应用架构。认识service mesh 在应用中的关系。在认识之前我们要有API gateways, edge proxies, 和 the enterprise service bus 的概念。

什么是Service Mesh?

     Service Mesh处理服务到服务通信的专用基础层。它负责云本地应用复杂网络可以的传递请求。在实践中，service mesh 通常会实现一序列的轻量网络代理，单独应用代码部署，并且不用关心应用代码。

     Service Mesh作为独立层的概念，和云本地应用的兴起有很大的关系。在本地云模型中，一个应用会和其它的上百个服务有联系;每个服务有上百个实例,每个实例的状态是动态变化的，它们类似使用Kubernetes进行编排器动态调度的。在实际中，服务之间的通信是异常复杂的，服务的运行时状态和基础层的管理，是确保端到端性能和可靠性的保证。

 Service Mesh是一个网络模型？

Service Mesh是一个工作矸TCP/IP之上的一个抽象网络模型。它假设存在L3/L4网络，并且能够进行点到点的字节传输。

 在某些方面，service mesh和TCP/IP是有些相似的。如：TCP是一个抽象模型用来确保网络节点之间字节传输，service mesh是一个抽象模型用来确保各个服务之间的相互请求。如TCP 一样，service mesh 不关心实际的负载或者它是如何编码的。应用有一个高层的目标，和service mesh的工作，和TCP有些相似，处理任何失败时实现该目标的一种方式。

 

     和TCP不同的是：sevice mesh 除了“让它工作”之外，还有一个重要的目标，为应用的可见性和运行时应用的控制提供一种机制。service mesh的一个明确目标是：把服务通信从不可见，隐形的基础层，转移到生态系统的一级成员在这里可以被监控，管理和控制。

service mesh 实际是做什么的？

      在云本地应用可靠的交付请求蛱非常复杂的。servcie mesh 像 Linkerd 这样的网络广泛的强大的技术来管理 管理这种复杂性。这些广泛的强大技术如：circuit-breaking, latency-aware load balancing, eventually consistent (“advisory”) service discovery, retries, deadlines。这些功能必须协同工作，并且这些功能运行在复杂环境它们之间的交互是非常微妙的。

 

例如，通过Linkerd发送一个请求，它的简单时间顺序事件如下：

       1，Linkerd 根据动态路由规则来确定请求需要的服务。确定请求是路由到一个服务还是中转到转换中的服务？请求的服务是本地的数据中心还是云端服务？是最近发布的服务还是已经过审核的生产服务？这些所有的路由规则都是可以配置的，可以全局应用、也可以应用于流片段。

      2，找到正确的目标，Linkerd 会从服务发现节点的实例池检索，可能会有多个服务。如果这些信息和Linkerd检索到的信息有不同，将由它决定那些信息是可靠的。    

      3，Linkerd 会根据各种因素选择响应最快的一个实例，包括观察到最近请求的延时。

      4，Linkerd 会尝试发送一个请求给这个实例，记录延时和响应的结果类型。

      5，如果该实例已经挂了，没有响应，或者请求失败，Linkerd 会尝试请求其他实例。

      6，如果一个实例总是返回错误，Linkerd 会把它从负载均衡池中移出，稍后在进行重试（如：一个实例出现短暂性的失败。）

      7，请求截止日期已过，Linkerd 会主动让请求失败，而不是添加到负载进一步重试。

      8，Linkerd 可以捕获上述行为的各个方面，并将这些信息提交到一个集中的度量系统。

 

     上面这些只是一个科化版的Linkerd 初始化到终止的TLS，执行协议的升级，动态转流，以及数据中心间的故障转移。

     需要注意的是：这些特性旨在提供点的弹性和应用应用范围的弹性。大型的分布式系统，无论如何构建，都有一个共同的特征：为小的，局部的故障升级为系统范围的灾难事故提供机。当底层系统接近极限时，service mesh必须设计通过减少负载和快速故障防止这些故障升级。

为什么需要Service Mesh

 

       service mesh 最终不是新功能的引入，而是功能位置的转变。web应用总是需要管理服务通信的复杂性。service mesh 的起源可以追溯到过去这些年的应用演变。

       考虑下之前web应用程序的典型体系结构：三层应用程序。在这个模型中，应用程序逻辑、web服务逻辑和存储逻辑都是一个单独的层。层之间的通信虽然复杂，但范围有限毕竟只有两个跳。没有“网格”，但是跳之间有通信逻辑，在每个层的代码中处理。

      当这种架构被推广到非常大的规模，就会开始崩溃。Google, Netflix, and Twitter，面对巨大的流量需求，实现云本地方法的前身：把应用层切分成多个服务（有时称作“微服务”），这样应用层就变成了一个拓扑结构。在这些系统中，一个通用的通信层突然变得相关起来，通常采用胖客户端的形式设计比较洽当的例子如：Twitter 的 Finagle, Netflix 的 Hysterix, 和oogle的 Stubby 。

     在许多方面，Finagle, Stubby, and Hysterix是第一个网格服务。虽然它们特定周围环境的细节，并且需要使用特定的语言和框架，它们用于管理服务之间通信的基本形式，（如开源Finagle 和 Hysterix 库）在源公司之外找到应用。

 

     快速进行现在代云主机应用，云本地结构结合了许多小微服务方法和两个额外的附加因素：容器（如：Docker,提供了资源隔离和依赖管理，以及编排层。 Kubernetes)把底层的硬件抽象成一个同质池。

     这三个组件允许具有自然机制应用程序在负载下扩展，并且处理云环境下的部分故障。但是，由于成千上万的服务，以及在同一个时刻重新安排实例编排层，单个请求经过服务拓扑可能非常复杂，而且由于容器的服务很容易使用不同语言来实现，所以库方法是不可行的。

这种复杂性和临界性的结合促成需要一个专用来来处理服务间的通信和应用代码分离的服务通信。这个一层就是service mesh。

Service Mesh的未来。

     当云原生系统中采用service mesh正在讯带的增长，未来仍是一个广泛而令人兴奋的路线值得探索 。无服务器计算的需求（Amazon 的 Lambda），直接符合service mesh 命名和链接模型，并且自然的扩展到云原生生态系统的作用。在云原生环境中，服务要标识和访问策略处于初始阶段，并且service mesh 已经做好充分的准备可以在这里扮演基础角色。最后，sevice mesh 如之前的TCP/IP，它会继续深入基础应用层。就像Linkerd 从Finagle进化而来一样，当前服务作为一个单独，必须显式添加到云主机空间堆栈中的用户空间代理的化身也将继续进化。

总结

     service mesh 是云主机堆栈的关键组件。Linkerd 经过一年多的成长，已经成为Cloud Native Computing Foundation 组织的一部分。拥有繁荣的贡献者和广泛的用户社区采用者包括正在扰乱英国银行业的Monzo等初创公司、Paypal、Ticketmaster和Credit Karma等高规模互联网公司，以及Houghton Mifflin Harcourt等已经营数百年的公司。