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

导读

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

控制面的职责解析

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

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

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