Netflix的支付生态系统迁移到AWS的实践-InfoQ

QCon 全球软件开发大会（北京站）门票 9 折倒计时 4 天，点击立减 ¥880 了解详情 



 写点什么

在 2016 年 1 月 4 号，Netflix 完成了它的全球化服务，同时新增加了 130 个国家。在这之前，Netflix 的支付生态系统已经 100% 迁移到 AWS 云服务。Netflix 的支付架构从 Netflix 数据中心（DC）迁移到 AWS 云服务只是 Netflix 入云之旅中的一部分。“关于具体的 Netflix 迁移到 AWS 云服务的目的和方向”可参见以前的文章。

对于一家公司来说，支付是其的金融生命线。同时也折射出公司对顾客的态度。好的用户体验是 Netflix 核心价值观之一。支付的天性是直接影响会员和 Netflix 的财务关系，所以这种支付系统的迁移要尽可能优雅地完成。首要目标是建立一个安全、弹性和细粒度的迁移到云服务上的方案，而且不能影响用户体验。

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

支付系统架构

支付架构是负责管理 Netflix 会员支付状态的。这包括跟踪打开 / 付费付费周期，会员账号信用卡数量，会员付费状态，付费初始化请求，会员付费的日期。除此之外，付费数据需要灌入金融系统来计算 Netflix 公司账户的财报和税费报告。为了完成这些工作，支付开发的工程师需要做到以下几点：

批量作业生成 Netflix 全球会员的续费订单，按天聚合所有付费方式（包括，礼品卡，税收等）的数据流进入分类总账（General Ledger(GL)）来计算收益。消息事件和 DVD 事件的生成都是依赖于客户的支付状态；
支付 API 为用户服务平台和网站提供支付信息和礼品卡信息。除此之外，支付 API 也是处理用户行为（会员注册，撤单，地址更新，退款等）的工作流初始化的一部分；
整合不同的服务，比如，会员帐户服务，付款处理，客户服务，客户消息，DVD 网站和运费。

支付原有生态系统结合 Netflix 数据中心（DC）和云服务。更高层次上来说，Netflix 预迁移的架构抽象如下：

考虑到和 Oracle 交互的代码和数据太多，Netflix 接下来的目标是分解原有基于 Oracle 的臃肿方案为微服务架构。一些 API 需要跨区域和高可用。所以 Netflix 决定把数据分割成多数据存储。用户数据迁移到 Cassandra 存储。Netflix 的付费数据处理需要支持 ACID 事物，因此所有相关的数据迁移到 MySQL。下面的架构图是迁移之后的架构：

面临的挑战

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

理想情况下，迁移过程对用户体验是无宕机的；
AWS 上的新支付架构对会员的快速增长是可扩展的；
Netflix 从 1997 年开始的亿万行历史数据在不断的变化。这些数据在分库的 Oracle 中每分钟都在增长。为了迁移所有的数据到 AWS，Netflix 工程师需要首先迁移 2 TB RDBMS 数据到云服务并做实时同步；
作为 SOX 系统，增加另外一个复杂层，所有的迁移和工具都要支持 SOX 过程；
Netflix 已经开启许多新国家市场，迅速迈向全球化；
支付系统的迁移对其他着手全球化拓展的团队要做到无感知。

解决方案

Netflix 采用如下简单的原则来辅助定义前进的路程：

化繁为简：接受固有的复杂遗留系统容易但改造起来就异常艰巨。当你畅游在大量数据和代码中，简单化变得很重要。经过几天的梳理才慢慢得以清晰理解，并进行简化；
- 清理代码：将现有代码分解为更小、更高效的模块，率先把一些关键依赖移动到云服务上。Netflix 首先把税务方案移到 AWS；
  
  紧接着，从 Oracle 大表里移除会员支付历史，许多不同的代码直接访问这些表。现在仅仅迁移必要的数据到新的 Cassandra 数据库，建立新的应用来捕获支付事件，并开始在 AWS 云服务上提供全球的支付历史信息；Netflix 工程师花了大量时间开发数据迁移工具。原有会员支付属性分布在 Oracle 的多张表，迁移到简单的 Cassandra 数据结构中；
- 清洗数据：确保只迁移每个表中真正需要的数据，其它数据留下不用处理。历史支付数据对客户服务团队价值很大。因此，积极与各相关团队沟通找到他们实际需要的历史数据，然后将相应的数据提取出来进行存储。
构建工具是弹性的和一致的：迁移应用的目标是增量无宕机。Netflix 工程师通过构建代理，然后将数据管道重定向回数据中心（DC）。这会保持应用一直在读取 DC，并不会因为改变而受到影响，一直到数据迁移完再处理应用。

构建工具需支持具备 SQX 的支付云架构。为了符合 SQX，需要规避开发者行为的异常和审核。

云发布工具 Spinnaker 能够加强细节的捕捉，比如软件发布和管道事件的日志记录到 Chronos 以及大数据平台的审计。更进一步，Cassandra 客户端需要加强认证和审计。Netflix 使用 Atlas 开发新警报系统来监控云服务上的应用和数据。

为了帮助数据分析团队，开发了一个比较器来排除 Cassandra 数据库存储与 Oracle 中数据的异同。使用 Netflix 大数据平台来获取发布事件，使用 sqoop 从 Oracle 数据库和 Cassandra 集群迁移数据到 Hive。写 Hive 查询和 MapReduce 作业来生成报告并做成仪表板展示。
拿干净、有限的数据集先测试：Netflix 新开拓了一些国家市场，这带来了巨大的挑战，同时也为测试支付云架构提供了新的、干净的数据。所以，在云服务上搭建一套微型支付架构来测试续费批量处理，与数据中心的应用整合，完成支付工作流。一旦能够在云服务中成功处理新加入国家的数据，这将会为推广新的支付系统应用到大量原有的国家带来信心，特别是美国。
尽量减少宕机或者其它迁移的影响，保证客户体验：现有的会员数据迁移到 Cassandra 数据库时需要停机，同时从 Oracle 数据库迁移订阅数据到 Cassandra，为云服务上的支付 API 模块和续费模块服务。每个构建工具要保证处理失败后能恢复，提供会员状态管理确保迁移终止时会员数据可用。通过前面的准备，Netflix 从 DC 的 Oracle 数据库中迁移成千上万行数据到 AWS 云服务的 Cassandra 中，并且对用户未产生明显的影响。
数据库迁移要按计划有序进行：数据库移动要按事先的计划操作，并对最后的结果可预见，否则会出错。保证数据库架构能够解决数据的可扩展、可使用和可靠性，制定灾难性恢复计划，尽可能减小迁移停机时间。作者决定从商业的 Oracle 数据库迁移到开源的 MySQL 数据库，其运行在 Netflix 管理的亚马逊弹性计算云（EC2）实例上。

订阅数据存储在 Cassandra 数据库。支付数据存储在 RDBMS，支持 ACID，可以处理付费事物。因为 AWS 的 RDS 有 TB 量级的限制，但 Netflix 有数据库超过 TB 限制，因此，在 Netflix 核心平台和数据库工程师的帮助下，Netflix 使用分布式块设备复制（DRBD copy）为 MySQL master 构建了一个多区域、可扩展的架构，在不同的区域可以读到合适的副本。所有的 ETL 处理都在副本进行，为了避免 Master 的资源连接。数据库云工程师开发工具监控 MySQL 实例报警，在必要时能恢复。