在大型分布式系统与企业级 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 / EnvoyMySQL 8.4 (同城半同步双活)Milvus 2.5。这不仅能让交付部署人员第一时间确定环境兼容性更能让架构评审专家迅速研判方案的技术选型是否成熟可靠。2. 状态存储与无状态计算必须物理分离在容器图中严禁出现将计算逻辑与本地文件状态强绑定的设计。所有的业务容器都应被设计为无状态Stateless支持随时横向扩展HPA。任何需要持久化的数据必须清晰地指向专用的ContainerDb节点并且每个数据库应当拥有明确的主属业务所有权杜绝底层数据库的越权跨服务直接裸查。3. 异步通信与同步调用的视觉区分同步 RPC 阻塞调用如gRPC / mTLS与基于消息队列的异步事件驱动如Kafka 事务消息具有完全不同的故障传播特征。在容器图中必须清晰地将异步 Worker 与消息总线单独成组呈现。一旦发生上游高并发流量洪峰评审者可以直观地通过容器图确认哪些操作会被排队缓冲哪些操作必须承受实时并发压力。4. 保持容器颗粒度与组织分工一致容器图中的一个微服务原则上应当与团队的一个敏捷发布单元或一个独立的 Git 代码仓库相对应。如果把过细的代码模块如某一个工具类或内部包作为容器画出来容器图就会退化成混乱的组件图反之若把 10 个功能差异极大的服务打包成一个巨大的“后端服务”图纸就丧失了指导分布式部署与容器容量编排的实际工程价值。掌握了标准 C4 容器图的工程化表达规范架构师就能在方案文档中构筑起坚实可靠的骨架支撑。无论是指导研发人员划分微服务边界还是向客户运维专家解释容灾拓扑这套清晰严谨的图纸都将成为团队最高效的工程通行证。
