大型 ERP 云架构的隔离与协作
最近在思考一个问题:大型 ERP 云产品做数据库灰度发布时,业务规模、组织架构、发布安全这几件事该怎么统一起来考虑。查资料的过程中发现,业界其实早就把这个问题从不同角度拆解过很多遍,只是术语分散在不同的理论体系里。整理一下,算是给自己捋一条主线。
一条底层原则
所有下面要讲的概念,本质上都是同一条设计原则的不同应用:隔离是手段,服务契约是协作方式。
具体说是两条铁律:
- 数据和逻辑物理上独占一份,别人不能绕过接口直接碰它。
- 单元之间只通过服务/接口/事件交换数据,禁止跨单元直连数据库。
这两条规则最早出现在软件设计理论里,分别叫 DDD(领域驱动设计)的 Bounded Context(边界上下文)和微服务架构的 Database-per-Service(每个服务独占数据库)。后面所有的架构模式,不管名字叫什么,骨子里都是把这条原则套用到不同的颗粒度和场景上。
容易混淆的原因:三个维度
发现自己一开始会把几个概念绕在一起,是因为它们分布在三个不同的维度上,但用的都是同一个物理手段——独立部署一份完整副本。维度不同,要解决的问题也不同:
| 维度 | 解决的问题 | 对应概念 |
|---|---|---|
| 版本/阶段 | 代码变更如何安全验证发布 | Environment |
| 容量/故障 | 系统怎么水平扩展、故障怎么不扩散 | Cell-based Architecture |
| 组织/业务 | 不同业务单元的数据主权与协作方式 | Data Mesh、Federated Architecture、MDM |
分别展开记一下。
维度一:Environment,解决版本问题
最基础也最熟悉的概念。同一套业务逻辑部署多份,按发布阶段区分:dev、test/QA、staging、production。数据互不影响,代码逐级晋升,目的是让新版本在上线前有机会被充分验证。
但 Environment 的局限也很明显:它只能验证”新代码能不能跑”,无法验证”新代码在生产真实流量和真实数据规模下表现如何”。这就是为什么大型系统还需要另一个维度的能力。
维度二:Cell-based Architecture,解决容量与故障问题
这个概念来自 AWS Well-Architected Framework 里讲可靠性的部分(REL10-BP03)。它要解决三件事:
- 生产流量太大,单实例扛不住,需要水平扩展。
- 故障(bug、过载、误操作)发生后,影响范围要被限制住,不能全员遭殃。
- 新版本上线想先小范围验证,再逐步扩大。
做法是把整个服务——应用、数据库、缓存等全部依赖——复制成多份完全独立的副本,每份叫一个 Cell,容量固定。用户按某个 Partition Key(通常是租户 ID)被路由到某个 Cell,Cell 之间互不依赖、互不共享状态。
关键认知是:扩容靠加新 Cell,不是让单个 Cell 变大;灰度发布靠先升级一个小 Cell 验证,再推广到其他 Cell;故障隔离靠一个 Cell 出问题只影响该 Cell 内的用户。
这里有个容易搞混的点需要单独标注一下:Cell 和 Environment 长得很像(都是”独立部署的完整副本”),但轴完全不同。Environment 是同一批用户、不同版本阶段;Cell 是同一版本、不同用户分组。两者是正交关系,完全可以同时存在,比如 staging 环境里也可以切多个 Cell 来做压测。
ADP(HR/payroll SaaS 巨头)和 AWS 自家的 EKS 参考方案都用了这套架构。国内很多按租户分组发布的做法(业内也叫 cohort/pod-based release),本质上就是 Cell-based architecture 在发布管理这一层的具体应用,只是命名不同,原理是一致的。
维度三:组织/业务维度,这里最容易混,拆成三层看
前两个维度解决的是技术运维问题,这一层解决的是另一个问题:大型组织内部,不同业务单元(分公司、部门)的数据主权怎么分配、又怎么协同。这块内容最杂,拆成三层记录。
3.1 理论框架:Data Mesh
传统做法是把所有分公司/部门的数据都搬进一个中央数据仓库,由一个中央团队统一管理。规模大了以后,中央团队变成瓶颈,而且他们并不真正理解每个业务域的数据含义。
Zhamak Dehghani 在 2019 年提出的 Data Mesh 给出了四条原则来解决这个问题:
- 域驱动的去中心化所有权:每个业务域自己拥有和管理自己的数据,不强行集中。
- 数据即产品:每个域把自己的数据包装成可被订阅调用的”产品”(API、数据集、事件流),而不是任由别人直接查库。
- 自服务数据平台:中央团队只提供通用基础设施,不代替业务域做数据决策。
- 联邦式计算治理:全局数据标准由各域共同协商制定,不是中央说了算。
这是一套理论/方法论,后面两层可以看作是它在具体系统上的落地。
3.2 具体落地:Federated Architecture / Hub-and-Spoke
Data Mesh 讲的是原则,落到具体系统架构,业界常见的实现范式是联邦式/中枢-分支结构:各分公司保留完整独立的业务系统,自己闭环处理本地交易,上级设立一个”Hub”,通过近实时数据复制或事件订阅把需要汇总的数据同步过来,做合并报表、跨主体分析。Hub 只读汇总,不接管分公司的业务写操作。
SAP 的 Central Finance (CFIN) 是这个模式的典型案例:分公司各自跑自己的 ERP,甚至可以是不同系统、不同版本,财务数据近实时复制到中央 Hub,做集团级报表和集中支付,分公司业务系统完全不受影响。
3.3 公共数据的特殊处理:MDM 实现风格
客户、物料、组织架构这类公共主数据,各分公司都要用,但要在”一致性”和”分公司数据主权”之间找平衡。业界总结了四种风格,集中度依次递增:
- Registry(登记式):主数据中心只存索引/映射关系,数据留在原地,中心只负责识别”这是不是同一个客户”。
- Consolidation(汇聚式):定期抽取汇总成黄金记录,主要用于报表分析,不回写。
- Coexistence(共存式):主数据中心是权威源,但各系统仍可本地录入,双向同步。
- Centralized(集中式):所有主数据增删改必须在中心完成,各系统只读。
如果要让主数据服务保持权威地位,同时又不强制各分公司放弃本地操作能力,Coexistence 风格是最常见的选择——分公司拿到的是本地缓存副本,通过接口和主数据服务保持同步,而不是跨库联表查询。
一张表理清所有概念
| 概念 | 所属维度 | 解决什么问题 | 关键词 |
|---|---|---|---|
| Environment | 版本/阶段 | 代码/schema 安全发布 | dev/test/staging/prod |
| Cell-based Architecture | 容量/故障 | 水平扩展、故障隔离、分组灰度 | 固定容量、Partition Key、Bulkhead |
| Data Mesh | 组织理论 | 大规模组织下数据所有权如何分配 | 域自治、数据即产品、联邦治理 |
| Federated / Hub-and-Spoke | 组织架构落地 | 分公司业务闭环 + 集团汇总分析 | 近实时复制、只读 Hub |
| MDM 实现风格 | 主数据管理 | 公共数据一致性 vs 各域自主权 | Registry/Consolidation/Coexistence/Centralized |
| Bounded Context + Database-per-Service | 底层设计原则 | 以上所有概念共同的技术基石 | 数据隔离 + 服务契约协作 |
小结
整理完之后,发现一个挺有意思的规律:不管是发布安全、系统容量,还是组织数据主权,业界的答案惊人地一致——先把边界划清楚,让每个单元自己管好自己的数据,单元之间只通过服务契约交流,不搞跨界直连。区别只在于”边界”划在哪个维度上:按版本划就是 Environment,按容量/故障划就是 Cell,按业务组织划就是 Data Mesh 和 Federated Architecture。理解了这条主线,再看各家云厂商、各个 ERP 大厂的具体实践,基本都能对号入座,不会再被一堆新词绕晕。