统一的设计方案，适用于所有客户。云特有的差异——例如连接产品、关键服务、数据库引擎——都属于配置选择，而非重新设计。正因如此，我们才能在五个工作日内通过代码构建环境。
从上往下读这幅图。
- 用户和集成都通过同一个名称 erp.<客户域名> 访问，并经由 HTTPS、TLS 1.2 或更高版本协议连接到带有 Web 应用防火墙 (WAF) 的负载均衡器。这是唯一的公开访问途径。
- 至少有三个工作节点（每个可用区一个），运行 Web 和 API、发布引擎、ASK 操作员以及工作节点和任务。丢失一个节点或整个可用区会导致可用容量不足，无法继续为用户提供服务。
- 托管数据库（引擎和大小由客户选择）在另一个区域中有一个同步备用数据库。区域故障不会造成任何损失：RPO ≈ 0。
- 文档和附件存储在版本化对象存储中，而不是数据库中。
- 出站流量通过NAT发送到允许列表：银行、税务和电子发票、工资系统、电子邮件、人工智能引擎。仅此而已。
- 备份文件单向推送至独立账户中的物理隔离存储库。
私有端点和内部负载均衡器以虚线表示，因为它们仅在使用私有访问时才存在。如果仅使用 HTTPS 访问，则不会构建它们。
五个旋钮，仅此而已
节点大小；节点数量（至少三个）；数据库引擎及其大小；Live DR区域；环境数量。其他所有内容均基于参考架构。
配置、集成，然后才能编写代码
如果超出标准要求，则可通过配置满足——即通过平台升级来实现。否则，则通过运行在集群外部的 TRANXACT API 进行集成。只有在经过安全性和工程审查后，才会考虑在集群内部部署代码或代理；如果获得批准，则予以容忍并提供客户支持；如果被拒绝，则在集群外部运行。
客户无法直接访问数据库——此功能已标记为不提供 (DB_3.1.09)。报表和集成均通过 TRANXACT API 和数据提取实现，这也是为什么 BI 工具通过 API 或定时数据提取连接，而不是通过数据库登录的原因。
Calderwood Group ——实例分析
Calderwood 的 BI 团队请求为其数据仓库创建一个只读数据库用户。解决方案是通过私有链接进行定时数据提取——他们接口列表中的 BI 行是“保留、定时提取、私有链接”。
试试看 Calderwood 2 区的一个工作节点在月末发生故障。用户会受到什么影响？这是否会影响服务级别协议 (SLA)？
其 pod 被重新调度到区域 1 和 3 的节点上，这些节点的大小已根据负载进行了调整；除非区域 2 持有主数据库，否则数据库不受影响，在这种情况下，它会故障转移到同步备用数据库，RPO ≈ 0。只有当月的可用性未达到层级目标时，才会计入 SLA。