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

  • Netflix
  • 侠天

2016 年 7 月 7 日

话题:语言 & 开发架构

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

思考

Netflix 的支付生态系统迁移到 AWS 上可谓相当顺利,但现在回过头来再看,仍然有些事情可以做得更好。作者低估了自动测试的需要,并未很好的进行端对端的测试。在这些方面如果足够努力,可以更好的提高开发的速度。

迁移一些像支付这样大规模的、关键的遗留系统,需要做很多工作。迁移和简单化使 Netflix 获得了无数的好处。迁移之后的软件架构更加高效、更加轻便,Netflix 平台服务提供的工具、警报和监控能够完全利用云服务能力。Netflix 的应用能按需横向扩展,这能很好的匹配现在订阅者高速增长的趋势。

最后总结,支付系统的迁移是所有相关部门工程师共同的努力。使用 AWS 云服务会进一步加强 Netflix 的服务。

译者介绍:侠天,专注于大数据、机器学习和数学相关的内容,并有个人公众号:bigdata_ny 分享相关技术文章。

英文原文:Netflix Billing Migration to AWS

语言 & 开发架构