服务网格：数据面板 VS  控制面板

近两年来，服务网格（service mesh）的思想越来越受欢迎，随着学习该技术的人数激增，我发现所有技术社区里都产生了大量关于如何比较不同工具间差异的问题。

   这种情况可以用我在7月份写的一系列推特来总结：

服务网格的困惑#1：linkerd ~=nginx ~= haproxy ~= envoy.它们都不等同于
istio，istio完全是个别的东西

前面提到的只是数据面板，仅通过它们无法工作，需要将它们配置到其他工具中

istio是实现一致性控制面板的一个实例，可以在该面板的不同层次上，用一
致的方式将一些东西连接在一起

在上面的这些推特上，我提到几个不同的项目（Linkerd,NGINX,HAProxy,Envoy,和 Istio），但重点介绍了服务网格数据面板和控制面板。在这篇文章中，我会回顾一下，并深入讨论我对数据面板和控制面板的看法，以及它们是如何与我之前在推特中提到的其他项目相关联的。

什么才是真正的服务网格？

上图在基础层面上说明了服务网格的含义。图中有4个服务集群（A-D），每一个服务实例用sidecar网络代理进行部署。所有网络间的通信（HTTP,REST,gRPC,Redis等）都通过自己的服务实例，这些实例通过本地sidecar代理找到响应的目标实例。因此，外部网络对于服务实例是不可见的，它只知道本地代理的存在。实际上，分布式系统网络已经被服务程序设计人员抽象出来。

数据面板

在服务网格中，sidecar代理执行如下任务：

• 服务发现：在所有的前后端服务实例中，哪些是可用的？

• 健康检查：服务发现的前端服务实例是健康并且可以接受网络通信的么？这
  可能包括主动（例如外部ping一个到/healthcheck   endpoint的连接）和被动（比如使用3个连续的5xx作为一个不健康声明的指示）的健康检查。

• 路由：向本地服务实例发送一个rest风格的请求/foo，路由决定该请求应该向
  哪个前端服务集群发送。

• 负载均衡：一旦路由选择了一个提供前端服务的集群，那么请求应该发送给
  哪个服务实例？怎么配置超时？熔断怎么设置？如果请求失败了需要重试么？

• 认证与授权：对于访问的请求，访问者需要使用mTLS或者其他方法加密验
  证么？如果验证通过，访问者可以访问请求的endpoint或者收到一个未认证通过的响应么？

• 可观测性：对于每一个请求，都会生成详细的统计数据，日志信息，和分布式操作记录数据，以便操作者可以理解分布式通信流并对他们发现的问题进行调试。

• 以上这些都是服务网格数据面板的职责。实际上，sidecar代理本身就是数据面板。换句话说，数据面板对条件转换，转发，和监控每一个由服务实例提供并在服务间传递的网络包负责。

控制面板

sidecar代理数据面板提供的网络抽象是非常奇妙的。然而，这些代理怎么知道
将/foo路由到服务B？怎么处理查询到的服务发现数据？负载均衡，超时，熔断机制等是如何按指定配置的？使用蓝/绿或者逐步通信移动语义是如何完成部署的？谁配置全系统的认证和授权？

这些都是服务网格控制面板的职责。控制面板将一些独立无状态的代理构成
集合，并把它们转换成一个分布式系统。

我认为许多技术人员觉得数据面板和控制面板划分概念难以理解，是因为多
数人熟悉数据面板，而对控制面板是陌生的。我们接触物理网络路由器和交换机已经有很长时间了。我们理解包/请求需要由节点A发送到节点B，这可以用硬件或软件来现实。软件代理这一新类型只是我们以前长期使用的工具的升级版。

   然而，我们使用控制面板也已经很长时间了，尽管大多数的网络操作者可能
不太知道系统模块的技术成分。原因很简单—现在使用控制面板的人大多数是我们自己。

上图描述了我所说的“人类控制面板”。这种类型的部署工作依旧非常普遍，一个（可能烦躁的）操作人员手动完成静态配置，可能会借助一些脚本工具，然后使用一些特定的进程部署到代理中。然后这些代理会更新配置并继续用它来处理数据面板的任务。

上图描述了一个高级的服务网格控制面板。它由下面的部分构成：

• 人：仍然存在一个（希望没那么烦躁）人在这个循环中，并由他制定整个系统的决策。

• 控制面板的用户界面：这个人与某些类型的用户界面交互来控制系统，可能
  是一个网站入口，一个命令行界面，或者其他一些接口。通过UI，操作者可以获取全局系统配置设置，比如部署控制（蓝/绿和（或者）通信移动），认证和授权设置，路由表详情（比如服务A何时访问/foo，会发生什么），和负载均衡设置（例如超时，重试，熔断机制等）。

• 任务调度器：服务通过一些调度系统（比如Kubernetes或者Nomad）来运行在设备上。调度器负责将一个服务连同它的sidecar代理绑定在一起。

• 服务发现：当调度器启动或停止服务实例时，它将服务的生命状态报告给一
  个服务发现系统。

• sidecar代理配置APIs:在需要操作员参与下，sidecar代理能够以最终一致地方式动态地从系统组件中获取声明。整个系统由所有正在运行的服务实例和sidecar代理聚合组成。envoy的通用数据面板API就是这样一个应用于实践的例子。

  控制面板的根本目的是设置最终由数据面板发布的策略。许多优秀的控制面
  板将把系统的更多部分对操作者抽象，且需要更少的操作（假定他们是正常工作的状态）。

数据面板 VS 控制面板小结

• 服务网格数据面板：接收系统中每一个包或请求。提供服务发现，健康检
  查，路由，负载均衡，保证服务认证/授权，以及监控的功能。

• 服务网格控制面板：为正在网格中运行的数据面板提供策略和配置。不接受系统中的任何包或请求。控制面板将所有的数据面板转变为一个分布式系统。

当前项目概览

经过上面的解释，现在看一下服务网格的现状

• 数据面板：Linked，NGINX，HAProxy，Envoy，Traefik

• 控制面板：Istio，Nelson，SmartStack

这里简要的讨论造成现在许多生态系统问题的一些因素，就不对每个产品进行深入的分析了。

Linkerd是2016年初第一批出现的服务网格数据面板代理之一，它在提高人们对服务网格设计模式的意识和积极性方面做出了很大的贡献。Envoy则在6个月后发布（虽然在2015年末已经开发完成）。Linkerd和Envoy是人们讨论服务网格时最多提到的2个项目。

Istio在2017年5月宣布完成。它的主要原理与上图描述的优秀控制面板很相似。Istio的默认代理是Envoy。因此，Istio是控制面板，而Envoy是数据面板。很快，Istio获得了许多人的青睐，其他的数据面板开始集成Istio作为Envoy的替代物（Linkerd和NGINX都集成了Istio）。事实上，单一的控制面板使用不同的数据面板可能意味着控制面板和数据面板并不必须紧密的组合使用。一个像Envoy通用数据面板API的API可以在2个系统间建立一个桥梁。

Nelson和SmartStack有利于更进一步地说明控制面板和数据面板的区别。Nelson使用Envoy作为它的代理，并且在HashiCorp堆栈旁构建了一个健壮的服务网格控制面板（Nomad等）。SmartStack也许是服务网格的首批新浪潮。SmartStack组成了像HAProxy或者NGINX这样的控制面板，进一步说明了服务网格控制面板和数据面板解耦的可能性。

服务网格微服务通信体系现在获得许多的关注（就是现在！），任何时刻都有很多项目和供应商参与进来。在接下来的几年内，我们将会看到数据面板和控制面板的许多创新，并更好的集成了不同的组件。最终的结果应该是微服务通信体系对操作者（希望不那么烦躁）来说更加令人惊讶并简单易懂。

要点

• 一个服务网格有两个不同部分组成：数据面板和控制面板。二者是必须的。缺少任何一个，系统都无法工作。

• 每个人都熟悉控制面板，虽然控制面板可能是你。

• 所有的数据面板比较是通过各自的特点，性能，可配置性和可扩展性。

• 所有的控制面板比较是通过各自的特点，可配置性，可扩展性和可用性。

• 单一的控制面板可能包含合适的抽象和APIs，以便更多的数据面板可以使用。