服务网格是专注于基础设施层，让服务可以更安全、更快、更可靠地通信。如果构建云应用，你就需要服务网格。
在过去一年，服务网格已经呈现出,并在云原生栈中起着决定性的作用。像一些高流量的公司，比如说Paypal,Lyft，Ticketmaster, 还有Credit Karma，在今年一月份就已经在自己的产品中使用了服务网格。Linkerd,一个开源的为云原生应用而生的服务网格，成为了云原生计算设施的官方项目。精确地来说，什么是服务网格呢？为什么和它有关系呢？
在本文中，通过过去十年的应用架构,给服务网格定义和它的组织体系。从有关系的但是不同的API网关、边缘代理、服务总线的组成，来区分服务网格。描述哪里是服务网格顶层，还有期待它是由什么组成的，并使得云计算基础设施进化的？
什么是服务网格？
服务网格，是在基础设施层，让处理服务间可以通信。它的责任是通过服务里复杂的技术组成的云基础设施层，来保证请求的可靠性。在实践中，服务网格是有代表性地实现了一组，在服务代码之外的轻量级网络代理，而不需要服务来唤醒它。（但正如我们所看到的，这是奇怪想法）
服务网格作为一个独立的层与云原生应用相联系。在云原生模型里，单个应用可能由数以百个服务组成，甚至是几千个实例。因为它们是动态被调度（类似于Kubernetes），所以每个实例可能不断地改变状态。在非常复杂的世界中，不仅是服务通信，这是普遍基本运行行为的一部分。管理它是至关重的，要确保端对端的性能和可靠性。
服务网格是网络模型？
服务网格是一个网络模型，它是在TCP/IP之上的抽象层。假设在L3/L4网络下是即时的，并可以从点对点中发送字节。(这也可以假设这个网络，有其他环境东西，是不可靠的。因此服务网格必须可以处理网络失败的)
在其他方式中，服务网格是类似TCP/IP。因为在网络之间，TCP栈抽象了字节传输的可靠结构；而在服务间，服务网格抽象了请求传输的可靠结构。类似于TCP,服务网格不关心实际负荷和具体如何编码的。应用有高级别的目标（从A发送一些东西给B），而服务网格的工作就像是TCP，当任何失败在其中的时候，也要完成目标。
不像TCP，在“可以工作之外”，服务网格是有一个主要目标的：提供一个统一的,为了介绍可见的广泛应用的点，并控制应用的运行时。服务网格的明确目标是让服务间通信移动到不可见的领域中，隐秘的基础设施，成为生态系统中的首要成员，你在这里监控，管理和控制。
服务网格实际上是做什么的?
在云原生应用，可靠的传输请求可以非常复杂的。服务网格中，比如 Linkerd ，它管理着复杂的一组有能量的技术：熔断，负载均衡，最终的服务发现(咨询)，重试,截止日期。特性必须结合地工作和交互，在复杂的环境中，它们的处理是很微妙的。
作为例子，当一个请求通过Linkerd创造一个服务，是简单的时间轴事件，如下:
- Linkerd提供动态的路由规则来决定哪个服务来准备。在生产中和预上线，请求应该被路由哪个服务呢？服务在本地中心还是在云上呢？为了获取最新版本的服务来测试，或者在生产环境检验一个比较老的服务。所有路由规则是动态配置的，而且可以设置为全局和有任意分片运输。
- 可以找到正确的目的地，Linkerd从相关的服务发现中，恢复实例的通信池，而且可能有几个。在实践中，如果信息分别来自Linkerd的观察，会让源信息更真实。
- Linkerd选择实例并快速返回，这基于许多因素，包括默默地观察最近的请求。
- 意图发送请求到实例中，记录潜在因素和结果的相应类型。
- 如果实例挂载了，没有响应，或者请求失败，会重试发送请求给另外一个实例（但是请求是要幂等的）。
- 如果实例持续返回错误，会从负载均衡池里面把它给踢掉,而后会偶尔重试（在例子中，实例可能会有短暂的失败）。
- 如果请求在截止时间没有响应，将会主动放弃请求而不是进行重试。
- 它捕获了上面各种行为，获取到了指标和踪迹，可以集中系统指标数据。
在简易版本中，Linkerd可以初始化和终止TLS,协议更新，动态迁移，和在数据中心之间故障切换。
服务网格管理着服务间通信，而从程序代码中分离。
这是重要的笔记，这些特性是包含逐步恢复和应用广泛恢复。大规模分布式系统，无论是它们是怎么样的架构，有典型的特征：提供很多。服务网格必须设计得安全，当系统接近极限的时候，要增加限流和速失败。
为什么服务网格至关重要？
服务网格是根本上没有介绍新的功能，而是功能定位改变了。web应用总是管理这服务通信的复杂性。服务网格模型的起源，可以在这些应用过去十年半演变过程追溯.
想起了在2000年的经典中型web项目架构：三层应用。在这个模型下，应用逻辑、web服务逻辑、储存逻辑都是按层分开的。两个层次之间通信，是复杂的，在作用域里有限制，只有两个地方可以跳。这不是“网格”，但是在节点中这样的通信，由每一层的代码自身处理。
在这个架构形式可以提供很大的规模，并开始破裂。一些公司：Google、Nerflix、Twitter面对着大量传输需求，实现了有效的云原生方法的前身：应用层分布了多个服务（有时候称为“微服务”），这些排列的层次变成技术。在这些系统，广义上的通信层变得有关系了,但是代表性地拿到了“胖客户端”库代码——Twitter的Finagle, Netflix的Hystrix, 还有Google的Stubby 成为了这个方面的例子。
在很多方式中，库像Finagle、Hystrix、Stubby是第一个服务网格。当它们指定了周边环境的细节，需要使用指定的语言和框架，专注于基础设施并用于管理服务间通信，（在案例中，开源的例子有Finagle 和 Hystrix libraries）起源于它们公司的外部使用。
快进到现代的云原生应用。云原生模型组合了很多微服务方法，使用了两个额外的因素：容器(例如Docker),它可以提供资源的隔离和依赖管理;还有协调层，（例如Kubernetes）,它可以抽象下层的硬件到一个资源池里。
这三个组件可以让应用适应原生机制的收缩，和处理云环境经常出现的局部错误。但是成千上百的服务实例，而管理层时时刻刻地重新调度实例，一个请求路径通过服务使用的技术可以变得非常复杂，在容器里可以容易地让每个服务可以使用不同的语言编写，类库的使用不再可行。
在复杂的组成和临界点的驱动下，需要专注的层来实现服务间通信，使得代码分离开了应用，能够获取更高的动态原生的环境。这一层就是服务网格。
服务网格的未来
在云原生应用的生态中，服务网格的使用在迅速地增长，广泛的让人兴奋的学习路依旧在探索中。无服务器计算的需求（例如Amazon的Lambda）适合使用服务网格模型来命名和连接，在云原生生态中它是其中的延伸。在服务原生环境中，服务的角色身份和权限依然很初级，服务网格可以很自然地成为这个故事的一部分。最终，服务网格，像之前的TCP/IP,将继续默默地推进基础设施的发展。例如Linkerd和Finagle一样，就是从系统中逐步形成，当前服务网格典型工作是，隔离，用户空间代理，这些必须明确加入到云原生栈中并继续发展。
结论
服务网格是云原生栈决定性的组件。它启动已经超过一年，Linkerd是云原生计算基础设施的一部分，而它的社区里有活跃的贡献者和用户。从启动到接管像Monzo,那时候英国的银行业很混乱。对于高流量的互联网公司，像Paypal、Ticketmaster、Credit Karma,像公司一样Houghton Mifflin Harcourt已经有数百年的业务了。
