在大型分布式系统与企业级 AI 平台的架构评审会现场，我们常常会遭遇这样一份令人崩溃的方案文档：
前一页刚讲完系统的宏观业务价值，后一页就直接贴出了厚厚的数据库建表 DDL 和几十个 RPC 接口的方法签名；中间至关重要的“系统由哪些独立运行的服务组成？状态存在哪里？微服务之间用什么协议通信？”却完全是一片语焉不详的黑盒。
研发团队不知道自己的服务该找谁拉取数据，运维团队不知道需要准备多少个独立的数据库实例，安全合规团队更是找不到跨服务的数据加密边界。
在 Simon Brown 提出的 C4 架构模型中，容器图（Container Diagram）正是填补这一巨大认知鸿沟的核心支柱。需要特别澄清的是：C4 模型中的“Container（容器）”并非专指 Docker 或 OCI 容器，而是指**“任何可以独立部署、独立执行的应用程序、微服务单元或数据存储进程”**。
一张规范、严谨的 C4 容器图，是整个技术团队在编码与部署阶段最权威的工程作战地图。
容器图的核心表达使命与三大边界
系统上下文图（Context）回答了“系统外部给谁用”，而容器图（Container）则将视距拉近，回答“系统内部由哪些高内聚组件协同支撑”。
在绘制容器图时，架构师必须清晰刻画三大工程边界：
- 执行边界（Execution Boundary）：明确区分哪些是前端 Web/SPA 单页应用、哪些是无状态 API 微服务、哪些是常驻的后台异步消费 Worker 进程。
- 数据与状态边界（State & Data Boundary）：哪些数据属于只读缓存？哪些数据必须强一致性落盘到关系型数据库（如 MySQL/PostgreSQL）？哪些非结构化向量数据归属于专用的向量数据库（如 Milvus）？严禁出现“多服务共享直连同一个数据库”的架构反模式。
- 通信协议边界（Protocol Boundary）：每一条微服务之间的连接线，都必须明确标注传输协议（gRPC / HTTPS / WebSocket / AMQP）以及安全信道类型（如 mTLS 内部双向加密）。
PlantUML C4-Container 声明式实战代码
我们以一个典型的企业级智能协同与多智能体服务中台为例，采用版本化管理的 PlantUML 代码进行标准化表达：
@startuml "c4-container-system" !include https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Container.puml LAYOUT_WITH_LEGEND() title [C4 容器图] YueJoy 企业级智能服务中台运行时拓扑 (2026.10 生产基线) Person(business_user, "企业坐席 / 运营人员", "通过现代浏览器使用管理中台") System_Ext(crm_system, "企业核心 CRM", "管理客户履约与主数据") System_Ext(llm_upstream, "大模型推理集群", "提供基础大语言模型算力支持") System_Boundary(c1, "YueJoy 智能服务中台系统边界") { Container(web_app, "前端单页应用 (SPA)", "Vue 3.6 / TypeScript / Vite", "提供富交互式工作台、知识库标注、工单监控与可视化大盘") Container(api_gateway, "统一流量 API 网关", "Go 1.27 / Envoy", "负责全局 JWT 鉴权、动态限流熔断、WAF 规则过滤与反向代理路由") Container(agent_service, "Agent 编排引擎", "Go 1.27 / gRPC", "执行多智能体任务拆解、上下文装配与动态工具调用（Tool Calling）") Container(rag_service, "RAG 知识检索服务", "Python 3.12 / FastAPI", "负责文档语义切片、混合重排序（Hybrid Rerank）与召回过滤") Container(audit_worker, "审计风控异步 Worker", "Go 1.27 / 常驻进程", "从消息队列消费工具调用日志，执行敏感行为打标与证据链固化") ContainerDb(redis_cluster, "全局缓存集群", "Redis 7.2 Cluster", "存储高频会话状态、语义缓存切片、动态分布式锁与限流计数器") ContainerDb(relational_db, "业务核心数据库", "MySQL 8.4 (同城半同步双活)", "存储租户配置、权限矩阵、持久化工单流转数据与账单明细") ContainerDb(vector_db, "向量知识库集群", "Milvus 2.5", "存储企业私域知识切片的高维稠密向量与标量元数据") ContainerQueue(event_bus, "内部高吞吐消息总线", "Kafka 3.8", "异步解耦审计日志流、工单状态变更事件与长任务执行通知") } Rel(business_user, web_app, "使用浏览器 HTTPS 访问", "HTTPS / TLS 1.3") Rel(web_app, api_gateway, "发起异步 API 请求", "JSON / HTTPS") Rel(api_gateway, agent_service, "转发核心对话与任务请求", "gRPC / mTLS") Rel(api_gateway, rag_service, "转发知识管理与搜索请求", "gRPC / mTLS") Rel(agent_service, rag_service, "获取召回支撑文档切片", "gRPC / 内网 mTLS") Rel(agent_service, redis_cluster, "读写多轮会话状态与分布式锁", "TCP / Redis RESP") Rel(agent_service, relational_db, "更新工单状态与租户计费", "TCP / SQL (连接池)") Rel(agent_service, event_bus, "投递工具调用审计事件", "TCP / Kafka 事务消息") Rel(agent_service, llm_upstream, "发起模型推理调用", "HTTPS / 内网专线") Rel(rag_service, vector_db, "检索高维向量相似度", "gRPC / 内网直连") Rel(rag_service, redis_cluster, "查询语义缓存 (命中率 > 25%)", "TCP / 缓存代理") Rel(audit_worker, event_bus, "持续批量消费审计日志", "Kafka Consumer Group") Rel(audit_worker, relational_db, "持久化合规审计证据链", "TCP / 批量写连接池") Rel(agent_service, crm_system, "实时同步工单履约流水", "HTTPS / 专线认证") @enduml绘制高质量 C4 容器图的四大黄金法则
在对技术方案进行严密工程化落地的过程中，架构师应严格遵循以下四项原则：
1. 严格标明具体技术栈与主版本号
在容器标签中，绝不能仅仅写一个抽象的名字如“数据库”或“网关”。必须明确注明技术实现栈及其主版本号（例如：Go 1.27 / Envoy，MySQL 8.4 (同城半同步双活)，Milvus 2.5）。这不仅能让交付部署人员第一时间确定环境兼容性，更能让架构评审专家迅速研判方案的技术选型是否成熟可靠。
2. 状态存储与无状态计算必须物理分离
在容器图中，严禁出现将计算逻辑与本地文件状态强绑定的设计。所有的业务容器都应被设计为无状态（Stateless），支持随时横向扩展（HPA）。任何需要持久化的数据，必须清晰地指向专用的ContainerDb节点，并且每个数据库应当拥有明确的主属业务所有权，杜绝底层数据库的越权跨服务直接裸查。
3. 异步通信与同步调用的视觉区分
同步 RPC 阻塞调用（如gRPC / mTLS）与基于消息队列的异步事件驱动（如Kafka 事务消息）具有完全不同的故障传播特征。在容器图中，必须清晰地将异步 Worker 与消息总线单独成组呈现。一旦发生上游高并发流量洪峰，评审者可以直观地通过容器图确认：哪些操作会被排队缓冲，哪些操作必须承受实时并发压力。
4. 保持容器颗粒度与组织分工一致
容器图中的一个微服务，原则上应当与团队的一个敏捷发布单元或一个独立的 Git 代码仓库相对应。如果把过细的代码模块（如某一个工具类或内部包）作为容器画出来，容器图就会退化成混乱的组件图；反之，若把 10 个功能差异极大的服务打包成一个巨大的“后端服务”，图纸就丧失了指导分布式部署与容器容量编排的实际工程价值。
掌握了标准 C4 容器图的工程化表达规范，架构师就能在方案文档中构筑起坚实可靠的骨架支撑。无论是指导研发人员划分微服务边界，还是向客户运维专家解释容灾拓扑，这套清晰严谨的图纸都将成为团队最高效的工程通行证。
