服务网格的概述和工具选择

要使一个应用的功能运用到最佳，它的应用堆栈的每个部分都需要进行优化和更新（modernized）。容器和容器编组（container orchestration）工具等都在堆栈的基础结构层使用了这种更新技术。应用程序在构建和分布式部署后，代码部署的方式也会发生变化。微服务架构在软件的交付上引入了这种去中心化的方法。

不过，在基础架构层和代码之间，需要无缝工作的是网络层。现在的容器化应用中，人们更多地聚焦在代码的基础架构，打包和发布上，而不像传统的那样聚焦在网络。

随着服务网格的出现，这种方式也发生了变化。

“Containerized app development focuses on infrastructure and code but not as much on networking.”*

什么是服务网格?

网络通信以前是很简单的。网络中继客户机和服务器之间的消息。我们可以很容易地跟踪到路由消息及在网络中的触点，也可以很容易地调试延迟问题或错误，这些使用简单的监控 工具 如Nagios就可以做到。

在一个容器化的应用中，多个松耦合的微服务组成一个应用。每一个微服务由多个容器或Kubernetes系统中的pods组成。每个请求会涉及到多个服务，而且每个服务都是动态的。在系统发生改变和发布时，容器会自动进行创建和销毁。

这些服务之间仍需要无缝的通信，这正是服务网络的任务。

服务网格是服务间的通信层，它负责处理微服务间的横向通路。微服务中，服务网格很重要，因为在分布式应用中，应用之间的通信的复杂度远远超过独立软件之间的通信。

虽然复杂，不过微服务架构在性能、每个服务的控制、系统适应变化的能力以及网络间的可视化等方面有很大的优势。也因此，我们可以接受复杂系统所引入的管理工作。

服务网格简化了微服务间的网络管理工作。

服务网格的角色定义

服务网格最根本的职责是执行网络的核心任务，比如负载均衡和服务发现。另外，服务网格还引入了先进的方法，比如熔断机制、错误诱导（failure-inducing），来提供云原生应用程序所需要的网络性能。在一个复杂的微服务系统中，发生错误很常见，但重要的是网络需要具备可以重新路由、重试、主动失效和报告这些错误的能力。

服务网格的负载均衡

在云原生应用程序中，负载均衡是动态调整的，各个变化的部分会引起不同的性能。服务网格中的负载均衡器在发送请求到各独立的实例前，需要考虑到它们不同的状况。针对状况不佳的实例，负载均衡器可以阻止或路由其网络流量，避免紧急事件的发生并提供更可靠的服务。

负载均衡器可以主动调整服务网格的各个部件，检查它们的健康状况，也可以主动响应失败的请求，并根据性能关闭实例的流量。

除了这些，服务网络的负载均衡算法，会根据网络状况进行流量路由。过去，路由算法比较简单，如轮询调度算法和随机路由算法。在服务网格中，均衡负载算法还考虑了后端实例的延迟和可变负载。

服务网格中的服务发现

服务发现是定义新实例的过程，如实例创建以及从网络中删除时保留记录。这个记录对于功能间的负载均衡很重要，请求需要由状态良好且可用的实例来进行处理。

在一个动态的多服务应用中，服务发现是自动运行的。针对每个事件，它都有负责启动和停止系统报告的工具。在Kubernetes系统中，ReplicationController负责实例的整个生命周期。

搭档代理（Sidecar proxy）

通常，负载均衡器处于客户机和服务器之间，但现在，先进的服务网格是在客户端附加了一个搭档代理（side-car proxy）。这样，不仅可以确保每个客户机能平等的访问负载均衡器，还能避免单点失效（传统负载均衡器的最大缺陷）。

搭档代理成为分布式系统中实现服务网格的首选方案。

服务网格的监控

可视化对于云原生应用的网络管理很关键。它可以把和网络性能相关的数据，如延迟、带宽和运行时间等组合起来，并在栈的每一层都进行监测，包括hosts、 containers、 pods和 clusters，也提供了事件的详细日志信息来帮助我们进行问题解决。

分布式的跟踪是可视化的重要方面。它给每个通过网络的请求都会分配一个ID，并显示每个请求在网络中的路径。这样，我们可以知道网络中那个部分或那个实例速度慢或是没有响应，从而采取相应的方法去解决这些问题。

随着微服务应用复杂度的增加，我们越来越难重现一个实例的错误。我们需要有力的监控工具来了解请求的路径，识别问题产生的区域（不止一个）。

服务网格工具

服务网格最重要的两个工具分别是Linkerd和Istio。Linkerd是把服务网格方法带入网络的第一个工具，在生产环境中得到了广泛的应用。Istio在随后的一年发布，目前在分布式网络中增加了额外的管理层。

Istio把其它的服务网格工具看作数据平面，而自身为数据平面和控制平面的结合。Istio使用另一个和Linkerd类似的流行工具Envoy作为它的数据平面。这些工具之间兼容性很多，Istio也把Linkerd作为自己的数据平面。Istio带来的是先进的拟合策略（policy-based）管理和抽象层，抽象层可以给网络化带来更有力的分布式方法。

Buoyant公司最近发布了面向Kubernetes的Conduit。相对于功能大而全的Linderd，Conduit采用一种不同的路由，提供更简单的轻量级方案。理想情况下，对于组织而言，这意味着在Kubernetes上，它就是一切，从而需要一种能快速启动和方便管理的方法。

安全是网络的关键。Project Calico是使用拟合策略安全技术的一个工具。和以前只依赖于作用在整个应用外围的防火墙的单层软件不一样，Calio的策略是为微服务应用的每个服务建立防火墙。这样，可以使服务和其它服务进行隔离，进行细小颗粒度的管理控制，从而加强我们的安全策略。在这样的设计中，假如一个服务出现问题，另外的服务不会受到影响。

从单个软件过渡到微服务模式，我们怎样管理应用网络至关重要。服务网格比传统网络模型相比，是更好的解决方案，也是在更先进的云原生应用中的一个基础。

“An Overview of the Service Mesh and Its Tooling Options” via @twaintaylor

感谢张婵对本文的审校。