传统部分业务机房迁移

父文章 : 安全生产 - 稳定性建设的方法论 架构师应该做什么? []_个人渣记录仅为自己搜索用的博客-CSDN博客

数据迁移不停服设计借鉴concurrentHashMap chm 和 redis 渐进式rehash_个人渣记录仅为自己搜索用的博客-CSDN博客

最新一代垃圾回收也是渐进式,可以把原来的引用,更换到新地址上去. 建立在kv,无遍历的基础上.

代驾迁移总结 : 应用迁移,流量切换,数据切换. mysql 同步. 同构,异构两种情况分析.

代驾支付迁移总结 系统业务进化重构之数据迁移--落地思考

	应用流量迁移中	DB流量迁移(DB平替)
整体迁移机房不互通(DB层不通,但接入层肯定要通)	1. 验证后清理线上数据. 2. 无流量验证,停服后,全部流量打入. 缺点: 无真实流量验证. 需要清理数据.	1. 切DB 同时2.切接入层, 3.切DNS 无.  注意自增id的上跳, 不然会出事.
整体迁移机房可互通(推荐) 业务无感知.	流量切,DB流量打回. 1. 部分流量验证.	停服,事务限制,按整库,1.切DB 2.同时切接入层,3.切DNS 缺点: 应用切流过程中导致耗时比较高. 损耗部分
部分迁移		迁移应用:         1.回调不迁移应用需改造. 改成到gw         2. 外部回调流量需转发. mq/rpc.   不迁移应用:    老订单的调用, rpc调用下游    1.1 内部本来的rpc调用到迁移应用, 无接入层, 中间件改造需要转发到rpcGw上.   1.2. 如果是调用的是部分迁移, 需要根据接口里的Type进行流量转发.  近端包需要迁移应用改造.  新流量来源   1. 收到迁移应用的mq流量是否需处理. 特别是新机房中自建了对标应用/双部署. 别新老应用都处理topic.

分三种 无状态/缓存/有状态 上云不停服，自顶向下的平滑机房迁移方案！！！_58沈剑的博客-CSDN博客

切流

        1.应用层计算层切流, 2.然后再停服, 3.然后DB平替切流. 前提是DB能够双主同步.

      (  不停服的只能是基于userId粒度进行停服和控制. 和业务强相关,确保写操作的所有数据都是userId粒度的. 对数据的停服和正反迁移也基于userId粒度. 反向迁移考虑的是回滚. 或者 分布式双写,做好幂等穿透. )

        消息如何切流,才能避免不丢,不重复投递? 在broker上增加配置,符合某些条件的消息,只允许新group拉取,不允许老group拉取. 配置在topic粒度,而不是配置在订阅方.  消息和rpc不同的点是, rpc知道了数据流该给谁, 不需要记录来源system. 但是消息却不知道消息该还给谁, 已经丢失了上游信息. 只能根据业务上进行区分. 但其实是不够的. 消息本质上是解耦的方式.

   

整个链路应用和数据迁移, 包括状态型的账户数据,也包括订单型数据.

难点

相关业务的相关的表梳理, 很容易梳理漏.

核心

1. 双主同步, 避免id冲突.

解法

方案1: 整表迁移

一张表部分迁移的要先隔离.

   1. 测试, 创建全新账号. id要确保不冲突. 每个表的id自增要播高, 分布式id要新增一个版本. 哪怕回滚, 填充也要不冲突. ( 务必确保 )
   2. 仿真回放验证[网关关闭防重放验证]
        需要通过覆盖率反向收集case. mock方法.
   3. 测试数据全部删除
   4. 数据同步
   5. 断流量 [全站迁移] -

   6. 观察各库读/写流量. 看看有哪些没有考虑到,没有迁移.

   7. 停写. 避免定时任务启动写入数据
   8. 剩余增量数据同步 [by中间件]  [全站表要一次性迁移完成] 部分迁移/或者按业务迁移也行. 只是多次影响到用户.
   9. 切流[放入部分流量]

  各个数据 双机房的计算层都要判断,哪个数据id在机房A,哪个在机房B.  回流还是transfer
    不然就会出现必须全域一起停服. 

方案2 - 渐进式不停服迁移

1. 遍历读写中间件改造. -sql改造- 或者业务无遍历读写需求

2. id键改造,需要有机房位. 迁移时使用. [id键大有乾坤,还能进行zone判断, 单元化, 异地多活. 多活仅仅针对流水型数据, 状态型数据只能拆 或者 paxos算法 ]

案例

不然就模仿redis ,双写(区别点是,插,双插, id要去重),双读. 双写要确保分布式事务一致. 要计算层整体路由. 而不是DB层双写,双读. 这样才能利用柔性分布式事务,保证双写在一个分布式事务内.

双写要吃掉id不存在异常. 读的时候 两边都null.

双写的另外一个问题是, 并发问题. 因为有分布式事务一致性. 肯定是能成功的. 无非有可能乱序,流水id不同. 账号仅一份,同步后才能双向操作. 有个锁的时间.

同时做好 kv读写 和 遍历读写分离

因为redis渐进和最新垃圾回收渐进都是只限于kv模式. 遍历读写的话,就需要读双库. 也不是不可以. 改造sql中间件即可. 存在中间状态.

另外渐进式操作,不能依赖DB自增. 需要有一个自增id 表. 新老机房自增id进行 跳跃. 确保切流完毕的时候. 两边自增不会冲突. 更简单的是设置一个机房id位. 仅供迁移用.

架构设计借鉴

uid 加上 vpc的概念. 专有网络VPC . 路由转发的时候 计算层, 应用层.