# 一、业务层改造原则
【1】业务单元化闭环改造： 按照不同区域进行用户分区和每个单元内可以独立运作的原则。对项目业务进行改造，业务上尽可能保证所有业务在单元内可以独立完成，每个IDC可以独立承担部分用户的业务处理的能力。
【2】请求链路改造： 尽可能保证在同Region执行，减少跨洋请求造成的网络耗时过长等问题。
【3】跨Region场景改造： 1、跨Region耗时请求下，由原来的串行调用外部接口的业务处理逻辑调整为异步并发处理和数据预加载优化。比如获取用户优惠券场景下，需要跨Region获取，则采取提前请求优惠券的方式，去除掉跨Region的影响。2、多次跨Region的场景通过接口改造减少跨Region的次数从而达到减少跨洋的效果。3、当核心业务中的非核心跨Region业务时：采用非即时性处理原则，通过业务拆分对非核心业务进行异步MQ改造处理。
# 二、整体架构
# 三、中间件
# 四、应用出海部署流程
【1】梳理依赖： Mysql(确定群集列表、创建海外集群、MySql打通双向同步链路)/Redis(常用的缓存场景，无需数据同步)/SOA(确定依赖服务，配置虫洞路由)/QConfig(梳理配置内容，按需设置子环境)/QMQ(梳理生产者与消费者，配置双向同步，设计消费策略)；
【2】部署验证： 测试和生产搭建SIN IDC，通过Captain创建SIN环境，验证SOA/SLB/TCP Gateway/H5 Gateway/QMQ......；
【3】接入流量： 不同的流量入口，具体的操作会有差异；SLB(外网域名流量，使用HTTP协议。如：站点页面请求)/TCP Gateway(移动端APP请求，使用SOTP协议)/H5 Gateway(移动端、网页端请求，使用HTTP协议)/SOA(内网服务请求，使用HTTP或Dubbo协议)；
# 五、流量如何进入各个应用
【1】站点页面请求；【2】站点前端服务请求；
【3】移动端应用服务请求；【4】内容SOA服务请求；
# 六、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】增加监控和库存不足告警通知，除了自动资源调配，对活动上线后进行机房间的库存情况实时观测和实时手动调配；