目录
一、什么是服务网格
Service Mesh 又译作“服务网格”，作为服务间通信的基础设施层。Buoyant 公司的 CEO Willian Morgan 在他的这篇文章 WHAT’S A Service Mesh? AND WHY DO I NEED ONE? 中解释了什么是 Service Mesh，为什么云原生应用需要 Service Mesh。
下面是 Willian Morgan 对 Service Mesh 的解释。
A Service Mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the Service Mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
翻译成中文是：
服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。
二、微服务架构概述
微服务架构可谓是当前软件开发领域的技术热点，在各种博客、社交媒体和会议演讲上的出镜率非常之高，无论是做基础架构还是做业务系统的工程师，对微服务都相当关注，而这个现象与热度到目前为止，已经持续了近 5 年之久。
尤其是近些年来，微服务架构逐渐发展成熟，从最初的星星之火到现在的大规模落地与实践，几乎已经成为分布式环境下的首选架构。微服务成为时下技术热点，大量互联网公司都在做微服务架构的落地和推广。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。
而在这个技术转型中，国内有一个趋势，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。然而软件开发没有银弹，基于这些传统微服务框架构建的应用系统在享受其优势的同时，痛点也越加明显。这些痛点包括但不限于以下几点：
- 侵入性强。想要集成 SDK 的能力，除了需要添加相关依赖，往往还需要在业务代码中增加一部分的代码、或注解、或配置；业务代码与治理层代码界限不清晰。
- 升级成本高。每次升级都需要业务应用修改 SDK 版本，重新进行功能回归测试，并且对每一台机器进行部署上线，而这对于业务方来说，与业务的快速迭代开发是有冲突的，大多不愿意停下来做这些与业务目标不太相关的事情。
- 版本碎片化严重。由于升级成本高，而中间件却不会停止向前发展的步伐，久而久之，就会导致线上不同服务引用的 SDK 版本不统一、能力参差不齐，造成很难统一治理。
- 中间件演变困难。由于版本碎片化严重，导致中间件向前演进的过程中就需要在代码中兼容各种各样的老版本逻辑，带着 “枷锁” 前行，无法实现快速迭代。
- 内容多、门槛高。Spring Cloud 被称为微服务治理的全家桶，包含大大小小几十个组件，内容相当之多，往往需要几年时间去熟悉其中的关键组件。而要想使用 Spring Cloud 作为完整的治理框架，则需要深入了解其中原理与实现，否则遇到问题还是很难定位。
- 治理功能不全。不同于 RPC 框架，Spring Cloud 作为治理全家桶的典型，也不是万能的，诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。而这些功能往往是企业大规模落地不可获缺的功能，因此公司往往还需要投入其它人力进行相关功能的自研或者调研其它组件作为补充。
以上列出了传统微服务框架的局限性，但这并不意味着它们就一无是处了。在中小企业，采用 Spring Cloud 这样的传统微服务框架已经可以满足绝大部分服务治理的需求，并且借此快速推进微服务化改造。这些痛点往往是技术发展到一定的程度必然要经历的阶段，这些痛点促使技术不断发展、不断前进。
在众多热门技术趋势中，云原生的关注度居高不下，很多开发者都对由此兴起的一众技术十分追捧，众多企业又开始探索云原生架构的转型与落地。这一年，中国的开发者们经历了从关注“云原生概念”到关注“云原生落地实践”的转变。而 Service Mesh 技术也因此越来越火热，受到越来越多开发者的关注，并拥有了大批拥趸。那么 Service Mesh 是什么呢？它为什么会受到开发者的关注？它和传统微服务应用有什么区别？
三、微服务与服务网格
微服务架构可让开发人员更改应用的服务，而无需全部重新部署。与其他架构的应用开发不同，每个微服务都是由小型团队来构建，他们可以灵活地选择自己的工具和编码语言。总体而言，微服务是独立构建的，它们之间彼此通信，出现故障也只是单独情况，而不会升级为整个应用的中断。
服务间的通信，令微服务成为可能。在没有服务网格层时，逻辑管理的通信可以编码到每个服务中，但随着通信变得越来越复杂，服务网格的价值也就愈发显著。对于以微服务架构构建的云原生应用而言，利用服务网格，可以将大量离散服务整合为一个功能应用。
四、服务网格是如何运作的？
服务网格不会为应用的运行时环境加入新功能，任何架构中的应用还是需要相应的规则来指定请求如何从 A 点到达 B 点。但服务网格的不同之处在于，它从各个服务中提取逻辑管理的服务间通信，并将其抽象为一个基础架构层。
要这样做，服务网格会以网络代理阵列的形式内置到应用中。代理的概念在企业 IT 中并不陌生，如果您从一台工作计算机访问网页，很可能就会使用代理：
- 对该网页的请求发出后，首先会被公司的 Web 代理收到……
- 通过了代理的安全措施检查后，它会被发送到托管此网页的服务器……
- 接下来，该网页将返回代理并再次进行安全措施检查……
- 之后，网页就会从代理发送给您。
在服务网格中，请求将通过所在基础架构层中的代理在微服务之间路由。正因如此，构成服务网格的各个代理有时也被称为"sidecar"（挎斗），这是因为它们与每个服务并行运行，而非在内部运行。总之，这些"sidecar"代理（与每项服务分离）构成了网格式网络。
sidecar 代理与微服务并肩协作，用于将请求路由给其他代理。这些 sidecar 共同构成了网格式网络。
如果没有服务网格，每项微服务都需要进行逻辑编码，才能管理服务间通信，这会导致开发人员无法专注于业务目标。同时，这也意味着通信故障难以诊断，因为管理服务间通信的逻辑隐藏在每项服务中。
五、服务网格是如何优化通信的？
每向应用中添加一项新服务或为容器中运行的现有服务添加一个新实例，都会让通信环境变得更加复杂，并可能埋入新的故障点。在复杂的微服务架构中，如果没有服务网格，几乎不可能找到哪里出了问题。
这是因为服务网格还会以性能指标的形式，捕获服务间通信的一切信息。随着时间推移，服务网格获取的数据逐渐累积，可用来改善服务间通信的规则，从而生成更有效、更可靠的服务请求。
例如，如果某个服务失败，服务网格可以收集有关在重试成功前所花时间的数据。随着某服务故障持续时间的数据不断积累，开发人员可编写相应的规则，以确定在重试该服务前的最佳等待时间，从而确保系统不会因不必要的重试而负担过重。
六、服务网格的价值是什么？
在构建微服务的过程中，您可能会预见到某些需求，例如快速扩展和添加新的功能以满足业务需求。与刚刚启动时相比，一年后的微服务架构很可能大不相同。首先，微服务中构建的库，在处理服务间通信时也许能够将操作中断次数降至最低。要想发挥微服务的潜力，单纯通过增加规模和功能绝非长久之计。随着时间推移，服务会遭遇请求超载，开发人员需要花费越来越多的时间为每项服务编写请求逻辑，所以各种问题也随之而来。
而借助服务网格：
- 开发人员可以专注于增加业务价值，不再在连接服务上消耗精力。
- Jaeger 分布式跟踪请求与服务一起呈现了一目了然的基础架构层，更便于识别和诊断问题。
- 应用更容易抵御停机影响，因为服务网格可以从发生故障的服务中重新路由请求。
- 性能指标可建议改良方案，从而优化运行时环境中的通信。
开始规划未来在红帽® OpenShift® 服务网格上进行服务网格的试验。体验以统一的方式连接、管理和观察基于微服务的应用，获得对服务网格中联网微服务的行为洞察和控制。OpenShift 服务网格可供红帽 OpenShift 免费使用。
七、Service Mesh 可以做什么？
在云原生应用中传输服务请求是一项非常复杂的任务。以Linkerd为例，它使用了一系列强大的技术来管理这种复杂性：回路断路器、负载均衡、延迟感知、最终一致性服务发现、重试和超时。这些技术需要组合在一起，并互相协调，它们与环境之间的交互也非常微妙。
举个例子，当一个请求流经 Linkerd 时，会发生如下的一系列事件。
-
Linkerd 根据动态路由规则确定请求是发给哪个服务的，比如是发给生产环境里的服务还是发给 staging 环境里的服务？是发给本地数据中心的服务还是发给云端的服务？是发给最新版本的服务还是发给旧版本的服务？这些路由规则可以动态配置，可以应用在全局的流量上，也可以应用在部分流量上。
-
在确定了请求的目标服务后，Linkerd 从服务发现端点获取相应的服务实例。如果服务实例的信息出现了偏差，Linkerd 需要决定哪个信息来源更值得信任。
-
Linkerd 基于某些因素（比如最近处理请求的延迟情况）选择更有可能快速返回响应的实例。
-
Linkerd 向选中的实例发送请求，并把延迟情况和响应类型记录下来。
-
如果选中的实例发生宕机、没有响应或无法处理请求，Linkerd 就把请求发给另一个实例（前提是请求必须是幂等的）。
-
如果一个实例持续返回错误，Linkerd 就会将其从负载均衡池中移除，并在稍后定时重试（这个实例有可能只是临时发生故障）。
-
如果请求超时，Linkerd 会主动放弃请求，不会进行额外的重试。
-
Linkerd 以度量指标和分布式日志的方式记录上述各种行为，然后将度量指标发送给中心度量指标系统。
除此之外，Linkerd 还能发起和终止 TLS、执行协议升级、动态调整流量、在数据中心之间进行失效备援。
八、什么是自动化网格？
红帽 Ansible 自动化平台的自动化网格组件为扩展自动化提供了简单可靠的服务网格框架。通过灵活的多向通信层，自动化网格增强了企业在全球范围内运维的能力。与当今市场上的任何其他自动化平台相比，Ansible 自动化平台可降低对延迟和连接中断的敏感性，并提供原生对等连接功能，因此提高了可靠性，让您进一步实现目标。借助 TLS 身份验证和加密以及其他访问控制等安全功能，您可以依靠红帽 Ansible 自动化平台来最大程度扩展整个企业的 IT 资产。
九、Service Mesh 是一种网络模型吗？
Service Mesh 实际上就是处于 TCP/IP 之上的一个抽象层，它假设底层的 L3/L4 网络能够点对点地传输字节（当然，它也假设网络环境是不可靠的，所以 Service Mesh 必须具备处理网络故障的能力）。
从某种程度上说，Service Mesh 有点类似 TCP/IP。TCP 对网络端点间传输字节的机制进行了抽象，而 Service Mesh 则是对服务节点间请求的路由机制进行了抽象。Service Mesh 不关心消息体是什么，也不关心它们是如何编码的。应用程序的目标是“将某些东西从 A 传送到 B”，而 Service Mesh 所要做的就是实现这个目标，并处理传送过程中可能出现的任何故障。
与 TCP 不同的是，Service Mesh 有着更高的目标：为应用运行时提供统一的、应用层面的可见性和可控性。Service Mesh 将服务间通信从底层的基础设施中分离出来，让它成为整个生态系统的一等公民——它因此可以被监控、托管和控制。
十、为什么我们需要 Service Mesh？
Service Mesh 并非新出现的功能。一直以来，Web 应用程序需要自己管理复杂的服务间通信，从过去十多年间应用程序的演化就可以看到 Service Mesh 的影子。
2000 年左右的中型 Web 应用一般使用了三层模型：应用逻辑层、Web 服务逻辑层和存储逻辑层。层与层之间的交互虽然也不算简单，但复杂性是很有限的，毕竟一个请求最多只需要两个跳转。虽然这里不存在“网格”，但仍然存在跳转通信逻辑。
随着规模的增长，这种架构就显得力不从心了。像 Google、Netflix、Twitter 这样的公司面临着大规模流量的挑战，他们实现了一种高效的解决方案，也就是云原生应用的前身：应用层被拆分为多个服务（也叫作微服务），这个时候层就变成了一种拓扑结构。这样的系统需要一个通用的通信层，以一个“富客户端”包的形式存在，如 Twitter 的 Finagle 、Netflix 的 Hystrix 和 Google 的 Stubby。
一般来说，像 Finagle、Stubby 和 Hystrix 这样的包就是最初的 Service Mesh。云原生模型在原先的微服务模型中加入了两个额外的元素：容器（比如 Docker）和编排层（如 Kubernetes）。容器提供了资源隔离和依赖管理，编排层对底层的硬件进行抽象池化。
这三个组件让应用程序在云环境中具备了伸缩能力和处理局部故障的能力。但随着服务和实例的数量增长，编排层需要无时不刻地调度实例，请求在服务拓扑间穿梭的路线也变得异常复杂，再加上可以使用任意语言来开发不同的服务，所以之前那种“富客户端”包的方式就行不通了。
这种复杂性和迫切性催生了服务间通信层的出现，这个层既不会与应用程序的代码耦合，又能捕捉到底层环境高度动态的特点，它就是 Service Mesh。
十一、Service Mesh 的未来
尽管 Service Mesh 在云原生系统方面的应用已经有了快速的增长，但仍然存在巨大的提升空间。无服务器 (Serverless) 计算（如 Amazon 的 Lambda）正好需要 Service Mesh 的命名和链接模型，这让 Service Mesh 在云原生生态系统中的角色得到了彰显。服务识别和访问策略在云原生环境中仍显初级，而 Service Mesh 毫无疑问将成为这方面不可或缺的基础。就像 TCP/IP 一样，Service Mesh 将在底层基础设施这条道上更进一步。
十二、结论
Service Mesh 是云原生技术栈中一个非常关键的组件。Linkerd 项目在启动一年多之后正式成为 CNCF 的官方项目，并拥有了众多的贡献者和用户。Linkerd 的用户横跨初创公司（如 Monzo）到大规模的互联网公司（如 PayPal、Ticketmaster、Credit Karma），再到拥有数百年历史的老牌公司（如 Houghton Mifflin Harcourt）。
325
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
