1.4 为什么服务网格是必要的

服务网格本身并不是一个新功能，而更像是功能所在位置的转变。Web应用程序始终必须管理服务通信的复杂性。在过去的十五年中，服务网格模型的起源可以追溯到这些应用程序的演变过程。

在本世纪初，中型Web应用程序的典型架构常见的是三层应用程序架构，分为应用程序逻辑层、Web服务逻辑层和存储逻辑层，都是单独的层。层之间的通信虽然复杂，但范围有限。这个时候的应用架构并没有网格，但是在每个层的代码处理逻辑之间存在通信逻辑。

当网络发展到非常高规模时，这种架构方法开始变得捉襟见肘。特别是一些大型互联网公司，都面临着巨大的流量需求，实现了有效的云原生方法的前身：应用层被分成许多服务，也就是现在通常所知的“微服务”，层之间形成拓扑的通信方式。在这些系统中，通常采用“胖客户端”库的形式，也就是前面讲述过的类似于Netf lix的OSS库，Hystrix的熔断能力就是很好的例证。这些代码库虽然与特定的环境相关，并且需要使用特定的语言和框架，但它们是用于管理服务之间通信的形式与能力，在当时的情况下是不错的选择，而且也在众多公司里被使用。

进入云原生时代之后，云原生模型有两个重要因素：容器（例如Docker）提供资源隔离和依赖管理，编排层（例如Kubernetes）将底层硬件抽象为同质的资源池。

尽管这些代码库组件在一定程度上允许应用程序具备一定的负载扩展能力，并处理云环境中始终存在的部分故障，但是，随着数百个服务或数千个实例的增加，以及存在不时重新调度实例的业务流程层，单个请求通过服务拓扑所遵循的路径可能非常复杂。同时随着容器技术的普及，且容器使每个服务都易于用另一种语言编写运行，程序库式方法在此时此刻就变得捉襟见肘了。

这种复杂性和关键性的诉求，使得应用越来越需要一个服务间通信的专用层，该专用层与应用程序代码分离并且能够捕获底层环境的高度动态弹性能力。该层就是我们需要的服务网格。

服务代理可以帮助我们在云环境服务架构中添加重要功能。每个应用程序都可以拥有自己的要求或配置，以了解代理在给定其工作负载目标时的行为方式。随着应用程序和服务越来越多，配置和管理大量代理可能非常困难。此外，在每个应用程序实例中使用这些代理可以为构建丰富的高级功能提供机会，否则我们将不得不在应用程序本身执行这些功能。

服务代理形成一个网状的数据平面，通过该数据平面处理和观察所有服务间的流量。数据平面负责建立、保护和控制通过网格的流量。负责数据平面如何执行的管理组件称为控制平面。控制平面是网格的大脑，并为网格使用人员提供公开API，以便操纵网络行为。