前言

负责 CloudDM 这个产品有一段时间了终于抽出一点时间，准备把产品里一些值得讨论的设计陆续整理出来。今天聊一下 Console + Sidecar 分布式架构。主要思路很简单：Console 负责统一控制，Sidecar 部署在目标资源附近负责执行。

User Pain Point: 在传统方案中。往往需要在每个内部网络上开放外部入口，导致安全风险与运维成本激增。

架构总览

Console + Sidecar 可以理解为控制面与执行面的拆分：

• #Console： 负责使用者侧的任务调度、权限校验和全局状态管理。
• #Sidecar： 负责所在网络环境内的任务执行、资源访问还有本地日志收集。

被访问的资源环境无需额外开放网络入口。只需与 Console 机器建立单向通道，即可从外部访问完全内网的资源。

再看使用者痛点，网络入口难以开放

公司往往禁止任何入站流量到内部网络。传统代理方案需要在每个子网内配置堡垒机或VPN，既增加了管理层级，又降低了可用性。Console+Sidecar 的单向通道方式彻底消除了这一瓶颈，让内部服务可以安全、透明地被外部调用。

一次任务如何完成

1. #Sidecar 启动并主动与 Console 建立长连接；
2. #Console 保存并返回 Sidecar 信息；
3. #Sidecar 持续发送心跳，报告当前状态；怎么说呢，
4. #使用者请求资源 A；
5. #Console 将请求下发给对应区域的 Sidecar；
6. #Sidecar 在本地网络中直接请求资源 A；
7. #Sidecar 将资源 A 返回给 Console；
8. #Console 将结果返回给使用者；

从使用者痛点来看，长连接不稳定导致任务失败或重试爆炸性增长

每个 Sidecar 与 Console 的长连接可能因网络抖动、节点宕机或防火墙断开而失效。 若未做好心跳检测和重连策略，会出现“半成品”状态。导致业务层面对同一请求进行多次重试，从而造成性能浪费甚至服务级别协议违约。合理设计心跳频率、超时阈值还有幂等操作，是保证程序稳定性的关键。说起来，

灵活部署方式

• #本地体验或小规模场景： 合并部署 Console 与 Sidecar。可减少运维成本和部署复杂度。按理说，
• #跨区域 ： 将 Console 独立部署。再在各区域分别部署一个或多个 Sidecar，即可覆盖全公司范围内的所有资产。不过，

两种模式共享同一套职责划分。区别仅在于组件是否拆开部署。 Pain Point: 当业务规模突增时从单体到微服务切换需要重新规划容器编排和监控程序，导致短期内运维团队压力倍增。

至于使用者痛点。合并部署与分布式部署切换成本高

切换到独立模式后需要为每个 Region 配置独立的 Helm chart 或 Terraform 模板，而且监控链路必须同时覆盖两端。这一步骤往往耗费数周甚至数月的人力，也增加了故障恢复时的认知负担。老实说，建议使用统一的 IaC 工具包和版本化策略，以降低转换风险。

优缺点

• #优点：
  • Conection 保留统一入口和全局状态，可快速实现多租户隔离。说起来，
  • Siderbar 可靠近目标资源。无需穿越 NAT 或 VPN，提高 IO 性能。
  • Add new region by adding one or more sidecars;no need to duplicate entire control plane.
  ` `}
` ` <`/ li>` `

` ` <` ul>` ` ` `

缺点 ： ` ` `

` `` `

• 连接和节点状态需要持续管理
• 任务必须考虑重复、超时和不确定状态

• 日志、指标和链路追踪要覆盖两个组件
`

---