基于单元的架构将服务划分为称为单元的独立实例，每个实例能够自主处理一部分流量。对于支付平台，每个单元包括一个完整的栈：负载均衡器、应用服务器、数据库和消息队列，分布在多个可用区域中，但在网络和数据层与其他单元隔离。流量路由依赖于使用客户标识符的确定性分片，确保单个客户专门映射到一个活动单元，同时维护在不干扰服务的情况下排出和轮换单元的能力。
跨单元的一致性通过使用变更数据捕获（CDC）流的异步事件复制来实现，以满足横向关联需求（例如，欺诈检测、合规报告），而单元内部的交易则通过本地数据库集群保持ACID保证。单元轮换利用单元边界内的蓝绿部署模式，以及在全球边缘CDN层域名实现电路断路器和健康检查基础的流量引导，以自动孤立降级单元。
某一层级支付处理机构在美国东部地区处理150亿美元的日交易，经历了一次灾难性的级联故障，当时数据库索引损坏传播到了多个可用区域。这导致了40分钟的全球停机，影响了4000万客户，并违反了PCI DSS可用性要求。事后检讨显示，共享基础设施组件创造了隐藏的故障依赖关系，违反了金融系统所需的独立故障域原则。
解决方案A：主动-主动多区域复制
这种方法将在多个区域部署相同的栈，使用多主数据库复制（如Galera Cluster或CockroachDB），允许任何区域进行写入。主要优势在于资源利用的充分性和地理位置带来的延迟降低。然而，财务交易的冲突解决复杂性在网络分割期间引入了不可接受的双重消费或不一致余额状态的风险，而管理向量钟和合并冲突的操作负担随交易量的增加呈指数级增长。
解决方案B：主动-被动带热备份
实施热备份架构保持一个次要区域通过同步复制与主区域保持持续同步，准备在主故障几秒内接管流量。这确保了强一致性，并通过显式故障转移编排消除了分脑场景。主要缺点是在正常操作期间资源浪费50%，并且无法在没有完整切换事件的情况下执行逐步轮换或更新，从而使常规维护窗口复杂化并增加部署风险。
解决方案C：基于单元的分区与确定性路由
所选架构将客户基础划分为20个不同的单元，每个单元处理5%的全球流量，具有独立的Kubernetes集群、专用的PostgreSQL主数据库和独立的Kafka经纪人。Envoy Proxy边车在customer_id上实现一致性哈希，以将请求路由到特定单元，而全球控制平面监控单元健康状态，并在轮换期间组织流量排出。这将用户的爆炸半径限制在5%以内，单元级故障期间实现零停机轮换，并通过金丝雀分析和自动回滚触发器逐步将流量转移到新的单元版本。
实施后，该平台实现了99.999%的可用性（每年停机时间少于5分钟），将事件的爆炸半径减少了95%，并且通过单元级金丝雀部署降低了部署风险，验证了变更在生产流量子集中的有效性，然后再进行全局推广。
你如何维护跨多个单元的实体（例如，在不同单元中分布的子账户的公司账户）的引用完整性？
候选人常常错误地假设严格的单元隔离防止任何跨单元交易。解决方案实现了一个事务模式，通过轻量级的Temporal或Camunda工作流引擎协调补偿交易。对于跨单元操作，系统仅在协调阶段使用两阶段提交（2PC），而实际变更仍保持在单元本地。幂等性密钥确保在分布式操作过程中发生部分失败时可以安全重试，而不会产生重复的财务影响。此外，全球只读缓存中的物化视图提供最终一致的跨单元查询，而不违反隔离边界。
当单元必须跨越地理政治界限以进行灾难恢复时，你将如何处理数据驻留合规性（例如，GDPR、PCI DSS）？
许多候选人忽视了单元位置的法律影响。架构实现了地理围栏单元，在主数据存储保持在主权边界内，同时次级单元充当具有加密温备份能力的加密热备份。同态加密技术允许欺诈检测算法在不解密外部司法管辖区的敏感PII的情况下对加密的跨境数据进行操作。单元流量路由结合了地理位置感知的DNS（Route 53 地理临近路由），确保欧盟客户在未明确授权进行灾难恢复场景之前，绝不会穿越美国单元，并通过基础设施即代码（IaC）扫描验证单元位置合规性进行自动数据驻留审计。
当失败单元恢复时，数千个客户端同时尝试重新连接，如何防止“雷鸣群”问题，压垮恢复的实例？
这个微妙的操作问题常常被忽视。解决方案在API网关层采用令牌桶速率限制，专门针对单元重新进入，并在客户端SDK中结合指数退避抖动。在单元恢复时，控制平面逐渐增加路由权重，从0%到100%使用线性插值增加，持续监控p99延迟和错误率。连接池与Envoy中的自适应并发限制结合使用，防止连接耗尽，而预热请求（合成交易）在接受客户流量之前验证单元健康。缓存预热作业主动填充恢复单元中的Redis集群，以防止冷存储上的缓存冲击。