Partition架构

优质博文：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】增加监控和库存不足告警通知，除了自动资源调配，对活动上线后进行机房间的库存情况实时观测和实时手动调配；