为什么我们需要服务网格Service mesh？
服务网格是一种使微服务之间通信更安全、更快速且更可靠的专用基础架构层。如果您正在构建云应用程序，那么你就需要一个服务网格。
在过去的一年中，服务网格已经成为云技术栈中的关键组件。Paypal，Ticketmaster和Credit Karma 等高流量公司都在其生产应用程序中增加了服务网格，2017年1月诞生的Linkerd是基于云应用程序的开源服务网格，成为云计算基金会的官方项目。但是，什么是服务网格？为什么它突然很热？
本文将定义服务网格，并通过过去十年中软件架构的变化来追踪它的发展轨迹。我将区分服务网格与API网关、边缘代理和企业服务总线的相关但不同的概念。最后，我将描述服务网格的前进方向，以及随着云应用这一概念的发展而接下来的趋势。
什么是服务网格？
服务网格是用于处理服务与服务通信的专用基础架构层。它负责通过建构基于现代云应用的复杂拓扑结构来可靠地传递请求。实际上，服务网格通常作为轻量级网络代理的阵列实现，这些代理与应用程序代码一起部署，而不需要应用程序需要事先知道。（Sprin cloud需要在代码中配置，但是我们会看到，这个想法有些不同。）
服务网格的概念作为一个单独的层与云应用的兴起息息相关。在云模式中，单个应用程序可能由数百个服务组成; 每项服务可能有数千个实例; 并且这些实例中的每一个实例都可能处于不断变化的状态，因为它们是由诸如Kubernetes之类的协调器动态调度的。这个世界中的服务通信不仅非常复杂，而且是这是运维的最基础部分。管理它对于确保端到端的性能和可靠性至关重要。
服务网络是一个网络模型吗？
服务网格是位于TCP / IP之上的抽象层的网络模型。它假设底层的L3 / L4网络存在并且能够从点到点传送字节。（它也假定这个网络和环境的其他方面一样不可靠;因此服务网格也必须能够处理网络故障。）
在某些方面，服务网格类似于TCP / IP。正如TCP堆栈抽象了网络端点之间可靠地传递字节的机制一样，服务网格也抽象了在服务之间传递可靠地请求的机制。与TCP一样，服务网格不关心实际有效负载或其编码方式。应用程序有一个最高目标（“从A发送到B的某样东西”），而服务网格的工作就像TCP一样，是为了在处理任何故障的同时完成这个目标。
与TCP不同，服务网格已经超越了“仅仅能运行即可”的目标：它提供了一个统一的、应用程序级别的切入角度，将可见性和控制引入运行时的应用程序。服务网格的明确目标是将服务通信从无形的、隐含的基础设施的领域中移出，并转化为生态系统中第一等公民的角色 - 在这个位置可以对其进行监控，管理和控制。
服务网格实际上做了什么？
在云应用程序中要实现可靠地传送请求可能非常复杂。像Linkerd 这样的开源服务网络产品是通过各种强大的技术来管理这种复杂性：断路器、负载平衡延迟感知、服务发现的最终一致性，重试和死期等。这些功能都必须协同工作，并且这些功能与其运行的复杂环境之间的交互可能非常微妙。
例如，当通过Linkerd向服务发出请求时，一个非常简化的事件时间表如下：
1. Linkerd应用动态路由规则来确定请求者想要的服务。应该将请求路由到生产服务还是测试服务？是针对本地数据中心或云中的服务？对于正在测试的服务的最新版本还是在生产中已经过审查的较旧版本的服务？所有这些路由规则都是可动态配置的，并且可以在全局和任意切片中应用。
2. 找到正确的目的地后，Linkerd从相关服务发现端点检索相应的实例池，其中可能有几个实例。如果这些信息与Linkerd在实践中观察到的不同，Linkerd会决定要信任哪些信息来源。
3. Linkerd根据各种因素选择最有可能返回快速响应的实例，包括观察到的最近请求的延迟。
4. Linkerd会尝试将请求发送到实例，记录结果的延迟和响应类型。
5.如果实例关闭，无响应或无法处理请求，则Linkerd会在另一个实例上重试请求（但只有当它知道请求是幂等的时）。
6.如果一个实例始终返回错误，则Linkerd会将其从负载平衡池中剔除，以便以后定期重试（例如，某个实例可能正在经历一个瞬时故障）。
7.如果请求的死期已到，则Linkerd主动发出失败请求，而不是在进一步重试，给系统添加额外负载。
8.Linkerd以度量和分布式跟踪的形式捕获上述行为的各个方面，并将这些数据发送到集中式度量系统。
这只是简化的版本 - Linkerd还可以启动和终止TLS，执行协议升级，动态切换流量，并在数据中心之间进行故障切换！
需要注意的是，这些功能目标是提供逐点的恢复能力和应用程序范围的恢复能力。大型的分布式系统，不管它们是如何架构的，都有一个明确的特征：存在各种小型局部的故障，从而可能升级为全系统的灾难性故障(banq注：比如云宕机)。服务网格必须设计成通过在底层系统接近极限时减少负载和快速失败来防范故障升级或扩大化。
为什么需要服务网格？
服务网格不是引入新功能，而是功能定位的转变。Web应用程序一直必须管理服务通信的复杂性。服务网格模型的起源可以追溯到过去十五年来这些应用的发展。
想想2000年代中型Web应用程序的典型架构：三层应用程序。在这个模型中，应用程序逻辑，Web服务逻辑和存储逻辑都是独立的层。层之间的通信虽然复杂，但范围有限 - 毕竟只有两次层层调用。虽然没有“网格”，但是这种层之间有通信逻辑，在每层的代码中处理。
当这种架构方法被推到非常大的规模时，它开始出现问题。像谷歌，Netflix和Twitter这样的公司面临着巨大的流量需求， - 应用层被分成许多服务（有时称为“微服务”），层级成为拓扑结构。在这些系统中，广义的通信层变得瞬间相关，但通常采用“胖客户”库的形式，例如Twitter的Finagle，Netflix的 Hystrix和Google的Stubby就是这样的例子。
在许多方面，像Finagle，Stubby和Hystrix这样的库包是第一种服务网格。虽然它们服务于特定的周围环境，并且需要使用特定的语言和框架，但它们是用于管理服务到服务通信的专用基础架构的形式，以及（对于开源Finagle和Hystrix库）在其原公司之外还有使用。
快速转向现代云应用程序，云模式将许多小型服务的微服务方法与两个附加因素结合在一起：容器（例如 Docker）（提供资源隔离和依赖性管理）以及编排层（例如 Kubernetes），将底层硬件抽象为均匀池。
这三个组件激活了应用程序自适应的自然机制，这样能在负载下进行动态扩展并处理云环境中不断出现的部分故障。但是，数百个服务或数千个实例以及编排层不时重新调整实例，单个请求通过服务拓扑结构遵循的路径可能非常复杂，并且由于容器使得每个服务都可以轻松用另一种语言编写，库包的方法已不再可行。
这种复杂性和重要性一旦结合，激发了对与应用程序代码分离，需要将服务到服务通信专门从应用代码中分离一个专用层，并能够捕获底层环境的高度动态性。该层就是服务网格。
服务网络的未来
虽然云生态系统中服务网格的使用量正在迅速增长，但还有一个广泛而令人兴奋的路线图仍有待探索。无服务器计算Serverless的要求（例如亚马逊的 Lambda）可直接使用服务网格的命名和链接模型，并在云生态系统中形成其角色的自然延伸。服务身份和访问策略的作用在云环境中仍然非常新颖，服务网格很好地扮演着这个故事的基本组成部分。最后，像它之前的TCP / IP一样，服务网格将继续推进到底层基础架构中。就像Linkerd从Finagle这样的系统演变而来，目前作为单独的用户空间代理的服务网格化体系必须明确添加到云堆栈中，这个代理也将继续发展。
结论
服务网格是云堆栈的关键组件。从推出起仅一年多的时间里，Linkerd就是云计算本地计算基金会的成员，并且拥有一个蓬勃发展的贡献者和用户社区。从像Monzo这样正在颠覆英国银行业的初创公司到像Paypal，Ticketmaster和Credit Karma这样的高规模互联网公司，也还有像Houghton Mifflin Harcourt这样经营了几百年的公司。