机房平滑迁移方案与多机房多活架构设计

Posted 2021-04-10 程序技术分享

        这是一篇总结文，总结阿里云栖2020大会，快狗打车cto分享的机房迁移方案

单机房架构：

        上图就是单机房架构图，如果要用一个词描述，就是“全连”，如上层nginx有三台，每一台都可以对下层做业务的转发，如果下层应用服务有三台机器，就是3*3；每一层都是全连接，通过连接池技术，做到性能的高效，通过层与层之间的随机连接做到高可用性和高可用性。

机房迁移的目标与难点：

        机房迁移就是把一个机房的所有东西，如lvs,nginx,业务服务，数据库，缓存等内容在另一个机房或者云端，弄出来一个一模一样的。

我们能先想到的技术就是先部署一套一样的集群环境，在某一时刻平滑的切流量，其实这样是不行的，平滑的切流量，不一定保证两个机房的数据完全一致，而且当你考虑跨机房部署系统，你的集群架构很复杂，机器数量也很多，当一部到位的切流量肯定会造成很多问题，不可能一步完成。

所以，要完成一个机房迁移的任务，难点就在于如何做到不停服务，平滑的迁移，如何做到蚂蚁搬家式的迁移，避免一步到位产生的大量问题。对于一个大集群架构，迁移要做到以下几点。

        1 分业务迁移，分子业务迁移

        一个大的系统分很多业务，如淘宝，有天猫超市，阿里健康，咸鱼等业务，迁移要能分业务

        ，分业务的子业务迁移。

        2 分层迁移

        对某个业务要能够分层迁移，如天猫超市，集群架构也类似上图，分了负载均衡层，业务逻辑层，数据访问层和Bb或cache。迁移时候要能做到分层迁移。

        3 可回滚

        对于某一部分的迁移，迁移成功，皆大欢喜，如果出错，要能够迅速的回滚，不能影响业务。

        4 不停服务

        在迁移的过程中不能停服务，要保证线上高可用性。

多机房架构：

        对于多机房架构，跨机房的全连接是不允许的，如下图，因为跨机房全连接，会造成50%的请求跨机房，两个机房之间传输数据的时间就可能几十毫秒，

理想的多机房多活：

        上面的图片，我们分为南京和广州两个机房，通过技术实现就近访问，让南京和周边的访问去南京机房，广州的及其周边的去广州机房。每个机房的请求只在本机房内完成，避免跨机房的调用，这种场景是理想化的，但是存在数据的一致性问题，即使有异步数据同步方案，也会出问题，如一个人余额一共一百元，在南京花了70元，在异步同步时候，可能几秒几十秒数据还没同步完成时候，他家人在广州花了80元，当两个请求在独立机房去操作时候，都会查到余额充足，其实这里数据存在一定的延时，才会出现这种问题，这种理想型的多机房架构，不适合面对全国的业务场景，适合地域性的场景，比如，滴滴打车，这种业务，在全国都有，但是他的业务是分城市的，南京用户下的单子接车司机也是南京，因此只在一个城市在一个机房进行数据的读写是没任何问题，即使数据有延时也不影响业务。你可能会说，两个人用一个账号，在两个城市，产生的订单分布两个机房呢？其实这也是一个小概率问题，同时一个订单未结束是不允许产生第二个订单的，这样就有效的规避了数据不一致。

        理想型的场景，很多业务是不满足的，大多数实现都是伪多机房多活。对数据库的写操作，只允许写一个机房里，另一个机房 的数据库值提供读操作，同时为另一个机房的主库的从库，跨机房主从同步数据延时也是毫秒级别，走专用网络会更快。这样也避免了数据延时不一致性。

自顶向下的平滑迁移方案：

        机房的迁移方案，是一个机房迁移另一个机房，一般是自建机房迁移到阿里云，在迁移的过程为多机房多活架构，满足两个机房同时对外服务，迁移成功后还是一个机房，只有阿里云对外提供服务，迁移步骤如下

1 反向代理+服务层迁移

        搭建服务，逐步切换流量，比如美团业务，首先先把美团外卖业务模块的负载层和应用服务在新机房部署，数据库和缓存的访问通过专有网络访问旧机房的数据，然后切百分之一的流量，去新机房，观看服务是否健康，然后在逐步加流量，一直到流量百分之百，然后老机房的外卖服务和负载就可以停下了。

2 缓存层迁移，

        在新机房搭建缓存，避免高峰期大量的cache miss造成缓存雪崩，建议在低峰期一次性切换缓存的连接，让缓存慢慢预热。这样关于外卖的旧缓存就可以停用了，

3 数据库层迁移

然后在低峰期，旧机房的数据库设置为read only，然后切换数据库访问的域名和端口访问新机房的数据库

‍