极光笔记 | 极光推送业务无中断迁移上云实践

​

​​作者：极光推送后台技术专家 —— 曾振波

为什么要上云

关于企业上云，业内已经有了非常多的讨论和论述。这里主要是从极光自身的实际情况阐述几个理由。

1、传统自建机房在扩充底层软硬件资源时，需要进行选型、采购、参数测试验证、实施部署等流程，整个过程需要消耗很多的人力和时间，对于快速发展的业务来说是很大的负担。云服务可以极大的缩减整个流程，对于部分云服务例如云主机可以实现分钟级别的资源交付。

2、自建机房需要投入高额的硬件资源准备，包括机房配套基础设施、服务器、网络、安全设备等，大量的冗余资源闲置，整体资源利用率不高。上云可以实现按需购买使用，实现更高的资源利用率。

3、基础设施建设和维护需要投入大量的人力和精力，往往还吃力不讨好。特别是虚拟化方面一直以来都是极光的痛点，资源隔离做得不好很容易受到其他虚拟机的影响，往往因为某个业务的突增影响同一个物理机上的所有虚拟机。云厂商有庞大的专业团队进行建设和维护，各方面相当可靠。

4、云厂商提供成熟稳定的 PaaS 层服务可以进一步释放我们的精力，让我们更专注在我们的业务，例如天然支持多 AZ 的 RDS 可以为我们在考虑同城双机房架构时提供很大的助益。

极光机房架构变迁历史

早期极光只有一个单一的机房，随着业务的发展，系统规模越来越庞大，单一机房的资源不足以支撑极光的业务。因此我们将业务系统迁移到了新建的机房，数据业务继续保留在原有机房，整个过程磕磕碰碰历时一年左右。

​

后来业务系统所在的机房再进一步优化，在同城增加一个机房，并用专线进行互通，迟延在 1ms 到 2ms 之间，并将部分子系统迁移到新的 AZ。由于我们的业务量级非常大，部分子系统的 QPS 超过了百万，在业务峰值偶尔出现延迟增加的情况，因此也做了相关的调整，访问量大的子业务系统尽量不跨 AZ 进行访问。此时的多 AZ，并不是每个 AZ 都有完整的业务流程，仅仅形成一个大内网，在部署的时候进行优化处理。

​

由于机房仅有单一的网络出入口，带宽也有限，很容易受到同机房的其他客户的影响。曾经出现过出口带宽用满甚至整个出口中断的情况，业务受到严重的影响。我们也考虑了异地双机房、单机房多网络出口方案，但是这些方案仅仅是针对性的解决我们的一些问题，没有系统性的解决我们当时的困境，因此这两个方案并没有真正意义的实行。同时内部也在考虑上云的方案，外加一些外部因素，上云的方案就推到了首位。至于云厂商的选型此处就不做陈述，最终选择了华为云。

极光推送的业务特征分析

极光推送为开发者提供服务，一个开发者可以有多个 Appkey 也就是多个应用，每个 Appkey 的全部数据互不相关，一个 Appkey 有多个终端设备用户。累计终端用户超过 500 亿，同时还有各个维度的数据，例如 tag、alias 等等，单副本数据总量超过 80TB；月活跃终端用户超过 5 亿，各个 API 接口请求总量超过 5 万 QPS。使用超过 2 万核 CPU，超过 2500 台虚拟机来支撑这些业务。

对外有 2 类网络通信：极光推送业务和开发者服务的通信，主要形式是 RestfulAPI；极光推送业务和应用的通信，主要形式是基于 TCP 长链接的自定义协议。

自建机房/华为云基础设施分析

推送业务部署在虚拟机和 K8S 上，这里主要分析对比虚拟机的 CPU、网络、磁盘的相关指标，以及 K8S 网络的指标。

从物理机看，自建机房的物理机相对华为云目标 AZ 的物理机性能低一些，例如华为云的物理机使用更高主频更高配的 CPU。在虚拟化层面，华为云的虚拟化做得更好，资源隔离更加严格，提供各种规格的云主机和磁盘，从整体上来说计算能力更加强，但是在网络和磁盘 IO 吞吐和 QPS 有严格的限制，需要做好规划。经过测试对比，选择了相关规格的云主机和磁盘。

自建机房-云环境架设专线，云主机和自建机房机器之间的 RTT 在 5ms 以内，常规情况下为 2-3ms，自建机房内网机器之间 RTT 为 0.2ms 左右，同一 AZ 云主机之间 RTT 为 0.2-0.3ms。

在 K8S 网络方面，自建机房做了相关的优化，通过专用的网络设备能够使用 Underlay 的路由模式，可以说是目前可用的原生网络模式中性能最好的模式。华为云自建 K8S 集群仅仅支持 Overlay 模式，性能相对差了一些；同时也提供了 K8S 服务，通过硬件加速等优化提供了较好的网络性能。

上云方案的选型

上云有几个需要考虑的要素：

• 业务无中断迁移，尽量不影响客户的使用，尽量不需要客户做任何变更。

• 迁移前后业务功能一致，需要保证数据和业务的完整性。

• 需要考虑切换过程中极端情况导致的回滚操作，并且需要保证数据和业务的完整性。

基于以上几点，在方案选型方面，我们主要考虑 2 个方案：

01、自建机房和云环境是 2 套独立、隔离的环境，关联的仅仅是自建到云环境的数据同步，业务上相互隔离。以 Appkey 为单位，迁移 Appkey 所有的数据和业务。数据通过专线进行迁移同步，同时尽量保证原有自建机房数据完整，最好能够数据双向同步/或者数据双写，方便极端异常情况下的业务回滚，至少保证能够回滚后业务正常。 

02、自建机房和云环境通过专线连接起来后，形成一个大内网。将数据耦合度比较低的子业务单独切换到云环境；对数据耦合度比较高并且访问量/访问迟延要求高的子业务，需要都跟随数据一起迁移。内部业务系统逐渐迁移切换完成后再对入口进行整体切换。

​

2 个方案均能实现业务无中断，同时各有优缺点，方案一需要额外开发少部分数据同步/恢复工具，前期准备工作充分的情况下，可以比较简单快速的切换；方案二不需要开发额外工具，但是需要操作的模块多，操作时间长，切换相对复杂，容易出现差错；综合考虑下选择了方案一，尽量保证切换过程简单无差错。

上云的详细方案

自建机房和云环境拉通专线进行数据同步，从业务层面来说，两个机房各自承载全部的业务数据，为了方便故障回滚，各个数据项尽可能的保持双向同步，保持数据最终一致性即可；两个环境的推送业务是相互独立的，先保证全量数据同步到云环境，以 Appkey 为单位进行流量迁移，将 Appkey 的流量迁移到云环境，迁移期间各自承担一部 Appkey 的推送业务，最终将全部流量迁移到云环境。

​

部署方案

为了快速迁移，采用 1:1 对等资源部署的方式即云环境部署一套和自建机房同等资源的系统，涉及业务模块、存储集群、依赖组件、监控体系等。同时新建另一套内部域名跟原有域名作区分，对外域名不进行变更，在迁移的最后阶段再进行变更切换。

在系统入口的部署做了特殊的处理：

• API 入口 - 部署同等规模的 API 服务器以及前端 Nginx，由于对外域名只有一套，只能在自建机房和云环境做二选一，请求流量都进入到自建机房，在 Nginx 的 Lua 代码中判断请求信息，根据 Appkey 归属信息决定是否转发到云环境；同时新建备用域名指向云环境的入口以备异常情况使用。

• SDK 接入网关入口 - 接入网关分成 2 个集群，各自服务自建机房和云环境，同时接收另一个机房的下行数据；SDK 先连接到调度服务，根据 Appkey 归属信息分配到相应的接入网关集群，同时调度服务跟自建机房互通，最后再迁移到云环境。

​

为了快速部署，并且避免遗漏某些业务模块或者组件缺失，也为了避免配置错误，我们整理了所有的机器列表以及相关信息例如 IP，将自建机房的机器信息和云环境的机器信息一一对应起来，当然还包括域名信息也进行一一对应，在部署的时候对着这些信息进行配置和部署。

数据迁移方案

推送业务的数据存储涉及 ES、CouchBase、Redis、PIKA、MySQL，需要把全部存量数据同步到云环境，同时建立实时同步通道进行同步增量数据，保证云环境的数据最终一致性。

数据同步方式为组件工具同步、业务双向同步，确保迁移整个过程数据在 2 个机房的完整性和最终一致性。专线的拉通，使得 2 个机房之间 RTT 为 2-3ms，为数据全量迁移和增量同步提供了非常强的支撑。

根据各存储组件，我们先预研了通用的迁移方案：

• ES 同步方式 1：云环境新建集群，拷贝源集群的数据文件到新集群，完成存量数据的迁移；增量数据由程序写入（即由业务实现数据在 2 个集群的双写）；使用脚本工具补充切换窗口的数据。

• ES 同步方式 2：新增云环境节点加入到集群，逐步剔除自建机房节点，即云环境和自建机房当成同一个内网，简称大内网模式。

• CouchBase 同步方式 1：使用自带集群同步工具 XDCR 进行同步。

• CouchBase 同步方式 2：存量数据使用业务工具导入，增量数据由程序写入（即由业务实现数据在 2 个集群的双写）。

• CouchBase 同步方式 3：大内网模式。

• Redis 同步方式 1：存量数据使用 redis-shake 或者主从同步，增量数据由程序写入（即由业务实现数据在 2 个集群的双写）。

• Redis 同步方式 2：存量数据使用业务工具导入，增量数据由程序写入（即由业务实现数据在 2 个集群的双写）。

• PIKA 同步方式 1：存量数据使用主从同步，增量数据由程序写入（即由业务实现数据在 2 个集群的双写）。

• PIKA 同步方式 2：存量数据使用业务工具导入，增量数据由程序写入（即由业务实现数据在 2 个集群的双写）。

• MySQL 同步方式 1：存量数据使用主从同步，增量数据由程序写入（即由业务实现数据在 2 个集群的双写）。

• MySQL 同步方式 2：双主复制

以上为几种通用的迁移方式，但是每个数据集群实例的特性不一样，从业务依赖程度、数据量、读请求量、写请求量几个维度评估，最终采取的迁移方案也不一样，我们梳理了自建机房的所有数据集群实例列表，对存量数据迁移、增量数据同步、切换方式、数据一致性需要的时间、切换操作、数据验证等都做了详细的评估和说明。

测试方案

测试分为功能测试和性能测试两部分，这两部分都使用我们自己的内部账号进行测试，先进行功能测试，在功能都完备的情况下再进行压力测试。

在平时的开发过程中我们积累了大量的测试用例，覆盖到了全功能和内部细节，整理这些测试用例构造测试数据并执行，从而实现功能测试的目的。

一对于压力测试，原计划的压力测试方案是：

1.在压力测试的过程中，切断云环境写入数据机房以及自建机房的数据链路，避免测试数据污染线上系统。

2.执行压力测试，确认压力测试的结果满足要求。

3.清理云环境由于测试过程导致的脏数据。

4.恢复第一步被切断的数据链路。

5.重新进行相关数据的数据同步。

6.由于第四步和第五步造成了数据和系统的变更，需要再次进行功能测试。

这个方案比较复杂，并且执行时间会比较长，特别是数据同步消耗比较多的时间，因此我们根据业务特性重新调整了压力测试的方案。测试以 Appkey 为单位，并且系统中各个 Appkey 是相互独立的，基于测试 Appkey 进行测试产生的测试结果数据仅属于 Appkey 本身，并且只对系统的整体运营数据有影响；测试 Appkey 也当做正常的 Appkey 存在在系统中，相关数据也不需要进行清理，后续如果有需要可以继续使用这些测试 Appkey。因此决定在功能测试之后，构造压力测试数据，然后直接进行测试，并且对整体运营数据做清洗过滤。压力测试场景和测试用例由业务团队和测试团队根据业务特征和系统特性来构造，覆盖所有的核心功能和核心模块，压测结果数据至少不低于当前业务的峰值。

整个测试在存量数据同步完成并持续同步增量数据之后进行，主要是考虑在做压力测试的时候存储集群有等量的数据量才能使压测结果更加接近原有系统。

流量切换方案

在功能完备、数据完整的情况下，迁移操作非常简单，执行脚本，修改 Appkey 归属信息就可以了，具体内部逻辑如下：

• 修改 Appkey 归属信息。

• 在 API 请求入口判断 Appkey 的信息，将流量转发到云环境的入口，后续所有流程都在云环境执行。

• 调度服务器获取 Appkey 归属信息，SDK 新的请求返回新的接入网关集群信息，连接到正确的接入网关服务器。

• 调度服务器通知接入网关服务器断开不属于该集群的 Appkey SDK 链接。

• API 入口和接入网关入口变更有个时间差，2 个机房的业务逻辑都能够完整执行，并且有数据同步，不管是 SDK 连接到哪个接入网关集群，都能够接收相关数据。

执行迁移操作后，需要进行验证，包括但不限于以下部分：

01、基础监控是否正常（网络/CPU/内存/磁盘等）

02、Prometheus 业务监控是否正常

03、推送业务运营数据是否正常

整个推送业务体量非常大，很难一次性全部切换，为了保证迁移过程有序稳定的进行，我们按照一定的策略和迁移比例制定迁移计划，分批次逐步迁移整个系统，每批次操作完成后都进行验证和观察一定的时间。优先测试账号并进行回滚验证，其次是非 VIP，最后是 VIP。

​

迁移实施管理

整个迁移过程，我们建立了实施过程跟踪，每天跟进当前的进度，下一计划步骤的工作任务，有哪些依赖工作，当前有哪些风险并且由谁来跟进解决等等，尽量确保迁移工作计划持续有序的执行。

​

迁移过程的一些问题

尽管我们做了详细的方案，在实施过程中难免会碰到一些问题，我们尽量快速分析定位问题，直接解决问题或者方案微调，在风险可控的范围内解决问题，这里摘选几个问题陈述一下。

1、有一个 CouchBase Bucket 实例在实施过程中发现有分钟级别的数据不一致。经过分析发现不一致的数据都有主动删除的操作，CouchBase 在删除时并不是真正的删除，仅仅是标记为删除，然后在后端线程异步执行数据删除。CouchBase 采用 XDCR 进行跨集群数据同步，可能是在数据同步过程中，删除操作未能及时同步。考虑到该实例的数据访问量级并不大，跨专线的访问时延并不影响到业务，因此进行方案的调整，仅保留云上的实例，自建机房和云上的系统共同访问。

2、有一个 Redis 实例偶尔出现 CPU 负载增高的情况，自建机房的实例观察正常。在此期间 Redis 没有进行数据备份，业务访问量也相对平稳，虚拟机并未受到同台物理机的其他虚拟机的影响；分析日志发现 CPU 负载增高时，Redis 有内存碎片清理的动作，比对相关的配置发现配置不一样。怀疑内存碎片清理消耗过多 CPU，经过调整 Redis 配置，该情况不再出现。

3、业务操作 MySQL 时偶尔出现迟延增加甚至超时。通过监控发现期间有业务突增，但是业务量属于正常范围内，并且自建机房的 MySQL 访问正常；虚拟机/物理机负载正常，业务机器/MySQL 机器的网络 IO/磁盘 IO 均正常，MySQL 各项数据也正常；再细看业务机器的基础监控发现网络丢包重传相对增加，怀疑网络链路有异常，经过华为云团队排查发现网络设备的光模块异常。更换光模块后业务恢复正常，该情况不再出现。

上云后的规划

上云不是终点，而是另一个起点。虽然已经将业务迁移上云完成，但是依然有很多工作需要做。云厂商提供了稳健的 IaaS 层，也提供了很多 PaaS 层服务，充分利用云资源的优势，拥抱云原生，持续演进优化我们的架构，为我们的客户通过更加优质的服务。以下是上云后的一些工作：

01、持续优化现有运行在虚拟机上的系统，提升系统资源利用率。

02、继续推进全面容器化，在尽量保证业务互不影响的情况下，采用混合部署的方式，进一步提升资源利用率。

03、采用云厂商的服务优化替换现有自建服务，例如文件存储等等。

04、进一步考虑多 AZ 甚至多 Region 的架构。

写在后面的话

从 2020 年 12 月底到 2021 年 3 月底，历时 3 个月左右完成了包括推送业务在内的整个机房迁移。寥寥几千字仅仅覆盖了推送业务在技术层面的一些实践，还有很多工作没有表述，例如前期的资源盘点梳理、CMDB 对接、网络规划、数据安全等等；大大小小的会议开了上百个，仅仅是数据迁移方案的评审及实施计划制定会议，业务开发团队和运维团队就一起开了 3 个多小时的会议。我们力求前期制定的方案足够详细、考虑周全，实施过程尽量按照预定计划进行，风险可控，所有过程都精细化到每个细节。在此期间公司内部多部门团队相互协调，华为云的专家团队全程驻场，提供了非常多宝贵的意见和建议，大家共同协作，才能在短时间完成了这项工作。