微服务框架控制面的介绍和ServiceComb全新ControlPanel的概要设计

导读

本文介绍了微服务框架中”控制面”要解决哪些问题，跟”数据面”在职责上如何分工，并提出了一个较为简单清晰的框架设计。
阅读本文，可以便于理解ServiceComb, Spring Cloud，Istio的”控制面”的功能和架构原理。
同时，Apache ServiceComb社区希望整合改造现有的控制面组件，提供一个，开源的，强扩展性强，开箱即用的，高性能的，用户友好的Control Panel整合组件。我们也热切的希望 有兴趣的同学能加入ServiceComb社区，我们一起完成该项目。

控制面的职责解析

现在主流的分布式微服务架构，把微服务的架构分为数据面+控制面，其中控制面功能较为复杂，通常包含多个组件。数据面和控制面的职责划分如下：

另外一个角度观察控制面的职责。所谓”控制”，其核心的流程无外乎 采集信息->根据某个规则引擎进行分析决策->反馈控制。这一套流程按照空间和时间进行划分将包括3个层次。

1. In-process的实时控制。适用于对性能要求较高，逻辑简单的控制流程。某一个微服务仅采集自身的信息，根据控制面下发的治理规则，在进程内部进行分析判断，并进行控制。举例：RPC失败重试机制。
2. 跟历史事件相关的控制。比如如果在最近1小时内超时的比例大于10%，则进行限流。这个可以在in-process中发生，也可以在控制面中发生。
3. 跟全局相关的控制。比如某一个Service的下游的Service所有的实例的平均响应时间超过了某一个阈值，则对该Service进行降级。

目前的微服务框架对1支持的成熟度较高，对2，3的提供更好的支持是微服务的一个发展方向。建议在发展2，3的时候，充分借鉴1的框架，流程，概念。这样能极大简化2，3的开发和使用。

按照工作流查看各个组件

工作流的概要说明：

1. 探针会不停的监控进程的状态，所有的监控消息，会交给in-process的实时规则引擎和执行机构处理。部分关注的监控消息，会包装成一个监控事件，并异步的通过网络发送给 “上报事件网关”进行处理。
2. “上报事件网关” 把所有的上报事件转化成统一格式，并缓存所有的上报事件，把上报事件发送给时序数据库进行持久化并处理后续可能的查询操作。
3. 进过时序数据库的”事件”会被复制3份，分别发送给，前端，自动控制器，报警器。
4. 前端有多个监控组件构成，每一个监控组件，接受一个事件流作为输入，并绘制相应的监控图形界面。
5. 自动控制器被构造成handler链的形式，每个handler被某一个事件触发，可能还会产生一个对时序数据库的查询，根据触发事件，和查询结果，对数据面发送控制指令。该指令同样需要经过时序数据库保存，和网关转化（图上为了简化未画出） 这个流程统一的用于实现”跟历史事件相关的自动控制”和”跟全局相关的自动控制”。
6. 报警可以看成一种特殊的”自动控制”，前半段是一样的，后半段不是给数据面发送控制消息，而是给报警的组件（如邮件系统，短信系统）发送消息，通知运维人员相应的报警事件。
7. 前端中有人工的控制界面。即运维人员，能通过前端页面方便快速的给数据面发送控制消息，并查看控制反馈。
8. 前端中有录入in-process实时规则引擎的前端组件，用于录入规则（一般是以配置的形式），并下发给数据面。

组件的详细介绍

1. 网关
   • 描述
     • 网关主要作用有3个 a:监控对象寻址。b:对接探针。c:控制协议的转化
     • 其中协议转化又包括2方向:
       Event: 从监控对象上报的信息的抽象成一个事件（event)，包括产生事件的源头，事件类型，事件发生时间，事件参数等信息。
       Cmd: 对于从后端向监控对象发送命令抽象为指令，也可以抽象成一个remote call或Http Api调用,可以用contract（open api)描述该接口，主要包括参数和返回。
       多个Cmd可以组合成一个复合Cmd。
     • 无论Event还是Cmd均需要进过时序数据库持久化，方便后续的查询和审计。
   • 关键点
     • 性能, NOI, 多实例部署。
     • 可用性，故障自动切换和恢复。
     • 不停机可扩充协议。Envoy的webAssembly是比较好的技术选型。
     • QOS。吞吐量保证。
2. 事件和指令队列和持久化-时序数据库
   • 概述 缓存事件，提供事件顺序和持久化。接受后端指令产生非原始事件（可带有定时器）。缓存，持久化指令。
   • 关键点 使用时序数据库持久化，事件和指令。 需要在事务性，性能，可用性之间找平衡。
3. 自动控制器
   • 自动控制器（规则引擎）。按规则链设计。每个规则，由一个事件触发。编程的范式如下：
     • step1 事件的参数的进行运算
     • step2 用事件的参数+一个查询模版对时序数据库的查询。
     • step3 对时序数据库查询的结果进行运算。
     • step4 通过前3步中的参数和结果生成cmd的参数，发起一次cmd的调用。
   • 报警器类似
4. 页面（前端），包括前端控制组件和前端显示组件，这2个组件应该结合呈现。 所谓控制面板，就是”监视”+”控制”。这个在真实世界有很多例子。如发电站的控制台，飞机的控制面板，汽车的导航+中央控制系统。
   这里有一个例子如下图： 仪表是”监视机构”，而按钮，旋钮，滑动条是”控制机构”。有几个设计原则
   • 对同一类，或者相关信息的”监视机构”和”控制机构”应放在一起。形成一个”监控组”。举例：温度表和温度调节器就应该放在一起，”看见”温度升高，就马上调整温度， 符合用户习惯。
   • 不同的”监视机构”适合与展示不同种类的信息。比如：如果关心温度的历史变化，应该是曲线图+当前温度的页面比较合适。如果是关心温度的变化范围，是否 太高超过了警戒线或太低影响效率（类似汽车的水温表），那么带有范围的指针式仪表比较合适，可以加上带有颜色数字方便阅读，指针可以清晰的显示当前值距离范围界限的距离。 要构建一个好的”监视前端”，我们需要积累多种”范式”,或者说”组件”。同样的逻辑也适合”前端控制机构”。
   • 不同的监控组也应该按组间的相关性组织空间和逻辑的关系。
   • “监视机构”— “前端展示块”，对应一个事件流+一个时序数据库的查询。
   • “控制机构”— “前端控制块”，就是手动控制器, 由用户设置的参数。并发起CMD调用，参数可以有默认值。
   • “控制机构”— “前端控制块”— “手动控制器” 的编程范式为： step1 用户输入参数 step2 时序数据库查询结果(可选) step3 组合1，2生成Cmd的参数。
5. In-Process的实时治理规则的下发，通常是以”配置中心”下发配置的方式进行。重点是配置项目的组织和管理，可参考流行的配置中心的设计。

关于以上设计的实现

1. 个人觉得Istio相对来说有更加”现代化”的控制面实现。ServiceComb在实现”控制面”时，可以多参考Istio.
2. 充分利用开源社区的力量，”控制面”涉及的组件众多，比如时序数据库，自己在开发一个不现实，充分利用开源社区的已有的组件。把开发力量利用投入到最有创新性的点上去。