图解分布式架构：一个 Console，一群 Sidecar
前言
负责 CloudDM 这个产品有一段时间了，终于抽出一点时间，准备把产品里一些值得讨论的设计陆续整理出来。今天聊一下 Console + Sidecar 分布式架构，核心思路很简单：Console 负责统一控制，Sidecar 部署在目标资源附近负责执行。
架构总览
Console + Sidecar 可以理解为控制面与执行面的拆分：
- Console 负责用户侧的任务调度
- Sidecar 负责所在网络环境内的任务执行
被访问的资源环境无需额外开放网络入口，只需与 Console 机器建立单向通道，即可从外部访问完全内网的资源。
一次任务如何完成
一条完整链路大致分为八步：
- Sidecar 启动并主动与 Console 建立长连接
- Console 保存并返回 Sidecar 信息
- Sidecar 持续发送心跳，报告当前状态
- 用户请求资源 A
- Console 将请求发送给 Sidecar
- Sidecar 请求资源 A
- Sidecar 将资源 A 返回给 Console
- 返回给用户资源 A
灵活部署方式
本地体验或小规模场景下，Console、Sidecar 可以合并部署，降低运维成本。
当资源分散在不同网络区域时，将 Console 独立部署，再在各区域分别部署一个或多个 Sidecar 即可。
两种模式共享同一套职责划分，区别仅在于组件是否拆开部署。
优缺点
优点：
- Console 保留统一的入口和全局状态
- Sidecar 可以靠近目标资源部署
- 新增区域时，主要增加 Sidecar，不必复制整个控制系统
缺点：
- 连接和节点状态需要持续管理
- 任务必须考虑重复、超时和不确定状态
- 日志、指标和链路追踪要覆盖两个组件
组件拆开以后，网络问题会变成业务状态问题，这是 Console + Sidecar 架构里最值得投入设计的地方。
最后
Console + Sidecar 的核心并不复杂： Console 决定应该执行什么，Sidecar 负责让它真正执行。
💬 评论区