转载

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

在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实例报警，在必要时能恢复。