4. CDE平台架构设计

CDE（Common Data Environment，公共数据环境）不是一套“网盘+权限”的简单组合，而是承载工程项目全生命周期模型、文档、流程与协同数据的生产级平台。当项目规模从单体建筑扩展到园区、线性工程乃至多标段集群时，平台需要同时面对成千上万个模型文件、数十种专业格式、跨组织权限隔离以及7×24小时的协同访问。因此，CDE的架构设计必须从“能跑起来”走向“跑得稳、扩得动、坏不了”。本节围绕分层架构、微服务与模块化、云原生部署、高可用设计与可扩展性五个方面展开，重点说明每一层解决什么问题、关键实现如何落地，以及如何判断设计是否达标。

一、分层架构：把“数据、服务、交互”拆开

CDE平台最忌讳把所有逻辑塞进一个应用。推荐采用五层结构：接入层、应用服务层、领域服务层、数据层、基础设施层。接入层负责统一入口、身份认证、限流与路由，通常由API网关承担；应用服务层面向具体业务场景，如模型轻量化、文档审批、问题追踪；领域服务层沉淀可复用的核心能力，如文件解析、版本管理、权限校验、工作流引擎；数据层区分结构化数据（项目、用户、权限、流程实例）与非结构化数据（模型、图纸、PDF、点云）；基础设施层提供计算、存储、网络与可观测能力。

分层的价值在于依赖方向单一：上层依赖下层，下层不感知上层。例如“模型轻量化”应用服务调用“文件解析”领域服务，领域服务只依赖对象存储与转换引擎，不关心前端是Web还是移动端。这样当轻量化算法升级时，只需替换领域服务实现，应用层接口保持不变。判断分层是否合理，可以看一个指标：跨层调用是否被禁止。如果应用服务直接写SQL访问数据库，或接入层直接调用对象存储，说明分层已经名存实亡。

二、微服务与模块化：按业务能力切分，而非按技术切分

微服务的切分原则是围绕业务能力，而不是“一个表一个服务”。CDE中相对稳定的服务边界包括：身份与权限服务、项目空间服务、文档与版本服务、模型转换服务、工作流服务、通知服务、检索服务、审计服务。每个服务拥有独立的数据存储与生命周期，通过API或事件通信。例如文档上传成功后，文档服务发布“DocumentUploaded”事件，模型转换服务订阅后触发轻量化，通知服务订阅后推送消息。这种事件驱动方式避免了服务间的同步强耦合。

模块化则体现在服务内部：即使是一个转换服务，也应划分为“格式识别、几何解析、轻量化、缩略图生成、结果回写”等模块，模块之间通过明确接口交互。微服务不是越小越好，过度拆分会导致分布式事务、链路追踪和运维成本急剧上升。对于中小型CDE，可以采用“模块化单体+关键服务独立”的过渡策略：先将权限、转换、检索拆出，其余保持单体，待团队与流量成熟后再逐步拆分。

三、云原生部署：容器、编排与声明式交付

云原生部署的核心是容器化、编排化、声明式。每个微服务打包为容器镜像，镜像中包含运行时与依赖，保证开发、测试、生产环境一致。使用Kubernetes进行编排时，关键对象包括Deployment（无状态服务）、StatefulSet（有状态服务，如检索集群）、Service（服务发现）、Ingress（入口路由）、ConfigMap/Secret（配置与密钥）、HPA（水平自动扩缩）。

一个典型的部署单元可以这样描述：模型转换服务以Deployment运行3个副本，每个副本限制CPU 2核、内存4GB，通过HPA在CPU利用率超过70%时扩容到6个副本；对象存储使用兼容S3的分布式存储，模型文件按“项目ID/专业/版本”路径组织；数据库采用主从架构，读写分离。配置通过ConfigMap注入，密钥通过Secret管理，避免硬编码。判断云原生是否落地，可以看两个问题：能否在5分钟内从零拉起一套完整环境？能否在不改代码的前提下调整副本数与资源限额？如果答案是否定的，说明还停留在“虚拟机+手工部署”阶段。

四、高可用设计：消除单点，明确恢复目标

高可用的第一步是识别单点。CDE中常见的单点包括：单台API网关、单节点数据库、单实例转换服务、单可用区对象存储。消除单点的手段包括多副本、多可用区部署、负载均衡、故障转移与健康检查。例如API网关至少2个副本跨可用区部署；数据库采用一主两从，主库故障时由哨兵或编排器自动提升从库；对象存储使用多副本或纠删码策略。

高可用必须用RTO与RPO来量化。RTO（恢复时间目标）指故障后多久恢复服务，RPO（恢复点目标）指允许丢失多少数据。对于CDE，建议核心协同服务RTO≤30分钟、RPO≤5分钟；模型转换等异步服务RTO≤2小时、RPO≤30分钟。实现RPO的关键是备份与复制策略：结构化数据每小时增量备份、每日全量备份，并异地保存；非结构化模型文件开启跨区域复制。此外，必须定期做故障演练，例如主动下线一个数据库从库、模拟可用区断网，观察服务是否自动切换、告警是否触发、数据是否一致。没有演练的高可用方案只是纸面承诺。

五、可扩展性考量：从“能扩”到“扩得划算”

可扩展性分为垂直扩展与水平扩展。垂直扩展提升单机配置，简单但有上限；水平扩展增加实例数量，是云原生的主要方向。CDE中，无状态服务（网关、应用服务、转换服务）天然适合水平扩展；有状态服务（数据库、检索集群）需要分片、读写分离或分布式架构。扩展性设计要提前考虑数据分区：按项目ID分库分表，避免单表过亿；模型文件按项目与时间分目录，避免单目录文件过多导致列举缓慢。

另一个关键是异步化与削峰。模型转换、批量导出、全文索引更新等耗时操作应放入消息队列，由消费者按能力拉取，避免请求堆积拖垮平台。例如使用Kafka或RabbitMQ，设置重试与死信队列，保证失败任务可追踪、可重放。判断可扩展性是否达标，可以观察：当并发上传量增加3倍时，系统是线性扩容还是出现瓶颈？瓶颈出现在哪一层？如果瓶颈在数据库连接数或单点转换服务，说明扩展设计尚未闭环。

六、把架构落到可检查的配置上

架构设计最终要落到可执行的配置与检查项。以下是一份面向CDE核心服务的部署检查表示例，参数为教学假设值，实际项目应按压测与业务SLA调整。

综上，CDE平台架构设计的关键在于：用分层隔离变化，用微服务与模块化控制复杂度，用云原生实现弹性与一致性交付，用高可用消除单点并量化恢复目标，用可扩展性设计应对项目规模增长。五者不是并列选项，而是相互支撑的整体——分层是骨架，微服务是器官，云原生是运行方式，高可用是底线，可扩展性是未来空间。