2016年1月4日，完成全球化服务，新增130个国家。 此前，支付生态已100%迁移至AWS云服务。 将支付架构从数据中心 (DC) 迁移到 AWS 云服务只是云之旅的一部分。 《关于迁移到AWS云服务的具体目的和方向》可以参见之前的文章。

对于公司来说，付款是其财务生命线。 这也体现了公司对待客户的态度。 良好的用户体验是核心价值之一。 支付的本质是直接影响会员及其财务关系，因此该支付系统的迁移需要尽可能优雅地完成。 主要目标是在不影响用户体验的情况下建立安全、弹性和细粒度的云服务迁移解决方案。

本文讨论将复杂的支付生态系统从数据中心 (DC) 迁移到 AWS 云服务的方法。

支付系统架构

支付架构负责管理会员支付状态。 这包括跟踪未结/已付付款周期、会员帐户信用卡号、会员付款状态、付款初始化请求和会员付款日期。 此外，支付数据需要输入财务系统，以计算公司账户的财务和税务报告。 为了完成这些任务，付费开发工程师需要执行以下操作：

支付遗留生态系统结合了数据中心（DC）和云服务。 在更高的层面上，迁移前的架构抽象如下：

考虑到需要交互的代码和数据太多，下一个目标是将原来臃肿的解决方案分解为微服务架构。 部分API需要跨地域、高可用。 因此决定将数据拆分到多个数据存储中。 用户数据迁移到存储。 付费数据处理需要支持ACID事务，因此所有相关数据都会迁移到。 下图是迁移后的架构图：

面临的挑战

前面提到的庞大的迁移任务是一个非常大的挑战。

解决方案

使用这些简单的原则来帮助定义您的前进道路：

构建工具具有弹性且一致：目标是在不停机的情况下增量迁移应用程序。 工程师构建代理，然后将数据管道重定向回数据中心 (DC)。 这将保持应用程序从 DC 读取数据，并且不会受到更改的影响，直到数据迁移完成后再处理应用程序。

构建工具需要支持SQX的支付云架构。 为了遵守 SQX，需要规避开发人员行为的例外情况和审核。

云发布工具可以增强细节的捕获，例如软件发布和管道事件的记录以及大数据平台的审核。 更进一步，客户需要加强认证和审计。 用于开发新的警报系统来监控云服务上的应用程序和数据。

为了帮助数据分析团队，开发了一个比较器来排除数据库中存储的数据之间的相似性和差异。 利用大数据平台获取发布事件，并将数据从数据库和集群迁移到Hive。 编写 Hive 查询和作业以生成报告并创建仪表板显示。

首先用干净的、有限的数据集进行测试：一些新的国家市场已经开放，这带来了巨大的挑战。 它还提供新的、干净的数据来测试支付云架构。 因此，在云服务上构建小额支付架构来测试续费批量处理，并与数据中心应用程序集成以完成支付工作流程。 一旦新增国家的数据能够在云服务中成功处理，将为大量原有国家尤其是美国推广新的支付系统带来信心。

最大限度减少停机或其他迁移的影响，保证客户体验：现有会员数据迁移到数据库时需要停机，同时将订阅数据从数据库迁移到服务于云服务上的支付API模块和续费模块。 每个构建工具必须确保处理失败后的恢复，并提供成员状态管理，以确保迁移终止时成员数据可用。 通过前期准备工作，数千行数据从DC数据库迁移到AWS云服务，对用户没有造成明显影响。

数据库迁移必须按计划有序进行：数据库迁移必须按照事先的计划进行，并且最终的结果必须是可预测的，否则就会出现错误。 确保数据库架构能够解决数据的可扩展性、可用性和可靠性，制定灾难恢复计划，并最大限度地减少迁移停机时间。 作者决定从商业数据库迁移到在托管 (EC2) 实例上运行的开源数据库。

订阅数据存储在数据库中。 存储支付数据，支持ACID，可以处理支付交易。 由于AWS的RDS有TB限制，但有些数据库超出了TB限制，因此在核心平台和数据库工程师的帮助下，使用分布式块设备复制（DRBD副本）构建了多区域、可扩展的数据库。 架构，适合不同地区阅读的副本。 所有 ETL 处理都在副本上执行，以避免资源连接。 数据库云工程师开发工具来监控实例警报并在必要时恢复它们。

思考

我们的支付生态系统向 AWS 的迁移非常顺利，但现在回想起来，仍然有一些事情可以做得更好。 作者低估了自动化测试的需求，没有很好地进行端到端测试。 如果在这些方面足够努力，就能更好的提高开发速度。

迁移一些大规模且关键的遗留系统（例如支付）需要大量工作。 迁移和简单性可以带来无数的好处。 迁移后的软件架构更加高效、轻便，平台服务提供的工具、警报和监控可以充分利用云服务能力。 该应用可以按需横向扩展，很好地契合了当前用户快速增长的趋势。

综上所述，支付系统的迁移是各相关部门工程师的共同努力。 使用AWS云服务将进一步增强服务。

译者介绍：夏天，专注于大数据、机器学习和数学相关内容，拥有个人公众号：分享相关技术文章。

英文原文：致AWS