Partition架构
【1】结构： Region至少3个Zone，Zone内至少两个Partition，Partition内至少1个K8S Member Cluster；
【2】故障域： 故障域及核心链路至少Zone内收敛，甚至Partition收敛。故障域之间不应该有交互（状态流等）；
【3】变更规范： 不同时变更多个Zone，甚至不同时变更多个Partition；
【4】Federation：Regional调度及控制面，负责Region内资源、容量调度；
【5】应用部署： 应用副本根据可用性级别分布在多个Zone内的多个Partition；
故障域隔离FederatedHPA： 场景梳理并分级，匹配不同故障域隔离要求。
【1】应用扩容链路： 高频+核心，Partition(Cluster)故障域内收敛，单个Partition故障不影响其他Partition正常扩容；
【2】HPA参数变更链路： 低频+非核心，Region故障域内收敛，故障会影响整个Region的HPA发布变更；
【3】Cluster间Rebalance链路： 低频+非核心，Region故障域内收敛，故障会影响整个Region的容量Rebalance；
方案：
【1】HPA系统组件在Partition(Cluster)内完整部署并封闭，扩缩容链路与其它Partition完全隔离；
【2】FederatedHPA只负责Partition/Zone间的Rebalance协调与变更分发；
效果： 单个AZ、Partition及Federation的故障不影响其它AZ、Partition的应用扩缩容。
应用部署的Group(Rollout)为Region级别。由Federation控制与分发到多个Zone内的Partition。Group不同时变更多个Zone。
容量调度问题
【1】流量上涨，Zone A扩容成功率下降（其他系统正在扩容等），需要降低Zone A流量比例，扩容成功率恢复后，需要恢复流量比例关系；
【2】Zone流量比例发生倾斜，如果单个Zone故障，Zone的Capacity会比非倾斜时高，需要主动触发提前扩容Node;
【3】混合云场景，私有云Zone容量不足，将部分应用容量公有云Zone倾斜，过峰后，因成本因素，恢复原有状态；
方案：
【1】Autopilot监听各Zone的资源用量、容量、扩容成功率以及SRE运营规则；
【2】Autopilot生成流量调度结果，并下发调度；
【3】HPA感知负载变化进行扩缩；
【4】Autopilot根据当前各Zone用量更新Capacity，并指导提前Node扩容；
多机房库存问题
用户的请求保证在同一机房内完成闭环，但部分场景并不适合划分单元化，比如多机房库存扣减问题。面对多机房库存扣减问题目前的策略如下：
【1】业务扣库存逻辑不调整，还是同步扣库存，但事先根据流量分配好每个机房库存；
【2】增加库存调配机制，当库存不足时触发库存调配，从有多余库存的机房进行调配；
【3】增加监控和库存不足告警通知，除了自动资源调配，对活动上线后进行机房间的库存情况实时观测和实时手动调配；