优质博文：IT-BLOG-CN
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】增加监控和库存不足告警通知，除了自动资源调配，对活动上线后进行机房间的库存情况实时观测和实时手动调配；
版权归原作者 程序猿进阶 所有， 如有侵权，请联系我们删除。