An Overall Plan of Dubbo Console and Dubbo CP

[robocanic]

架构及说明

组件架构

如上图，dubbo的服务治理大致包括四个部分：console-frontend前端，console-backend后端，dubbo application数据面，control plane控制面。

console-frontend是前端，负责数据展示与用户交互。console-backend是后端，负责将control plane的数据和行为进行功能封装，还需要与一些组件如prometheus，grafana等进行交互，为前端提供服务。control plane需要与k8s apiserver，register center进行交互获取数据并进行缓存，并向上提供统一的查询与操作接口。dubbo application作为数据面，在上图中的第一种部署形态下，需要对control plane上报service mapping与下发规则的过程进行适配。

其中，console-backend和control plane逻辑上是两部分，在项目前期这两部分融合为单个服务，后面会看实际情况进行拆分。拆分的主要目的在于

1. 更适用于k8s多集群。每个集群需要有一个control plane对k8s resource进行watch和reconcile。如果control plane和console-backend合在一起，则console-frontend则需要对接多个后端，且缺乏一个全局的视角来聚合各个集群的数据，对于多集群部署应用的形式不太友好。而在分拆的情况下，console-frontend只需要对接一个后端，console-backend会有一个全局的视角，更加适配于多集群部署的形态。
2. 更容易进行二次开发。我们也注意到企业用户对权限，安全等功能有更高的要求，在console-backend和control plane分开的情况下，企业可以基于console-backend进行二次开发，而核心的control plane则无需改动，部署形式上更加灵活。

由于dubbo集群的部署形式的不同，control plane需要适配三种不同的集群部署形式：

1. “全托管”k8s，应用的调度和服务发现都依赖于k8s，对应于上图中的第一种部署形态。
2. “半托管”k8s，应用的调度依赖于k8s，服务发现依赖于nacos或zk等注册中心，对应于上图中的第二种部署形态。
3. 经典dubbo集群架构，只需要关注注册中心即可，对应于上图中的第三种部署形态

可观测架构

基于opentelemetry的监控与链路追踪的端到端的方案如上图所示。metric和trace从dubbo application到console-frontend需要经过四个步骤：

1. 数据从dubbo application发送到opentelemetry collector。
2. opentelemetry collector经过一系列处理将数据转发到监控后端prometheus，链路追踪后端jaeger（可选）。
3. 在grafana中将prometheus和jaeger作为数据源，配置相应的视图。
4. console-frontend以嵌套iframe的形式进行展示。

上图中的方案不是唯一的，有很多组件，很多种方法去把可观测数据完成端到端的展示，我们需要尽可能适配主流组件。

RoadMap

一期

1. 总览：集群概览，展示集群状态，应用数据统计等
2. 应用详情：展示应用的标签，应用的实例信息(包含workload信息)等数据
3. 接口详情：展示接口的方法信息，接口的生产者消费者等数据
4. 流量治理：提供流量路由，动态配置等规则的展示和操作
5. 在线调试：提供泛化客户端转化http请求对dubbo接口进行调试
6. 可观测：应用的metric和trace的展示

二期

1. 流量治理方面：更丰富的流控规则，比如限流降级，流量预热等
2. k8s方面：k8s更深度结合，如提供类KPA(Knative Horizontoal Pod AutoScaler)能力，能够基于请求量自动伸缩
3. 可观测方面：增加基于RT，QPS等指标的告警规则，提供基于prometheus的告警接口
4. 事件中心（new）：提供pod事件，应用事件，操作事件等融为一体的事件详情
5. 多集群dubbo调用支持（new）：提供类 egressgateway的跨k8s集群调用的能力，refer to #94
6. 更多......