Netflix支付生态系统迁移到AWS的实践(part II)

本文是Netflix支付生态系统迁移到AWS的第二部分,主要讲解具体的支付应用和数据存储的技术细节。支付系统迁移的概览见第一部分《Netflix支付生态系统迁移到AWS的实践(part I)》。

随着Netflix全球各地的业务启动,带来了系统数据上的不断增长,进而意识到越早迁移到AWS云服务对Netflix越有利。因为现有对系统将不能继续扩展。

毋庸置疑,迁移如此高度复杂、敏感的应用和数据库并不能干扰线上的业务,是一项艰巨的任务。

Billing的职责和挑战

  • Billing team保障Netflix公司财务数据。每天生成订阅费,礼品卡,积分,退款等数据,汇报给财务和会计部门。数据处理严格遵循SLAs,并保证处理管道无延迟;
  • Billing对数据丢失零容忍;
  • 大部分情况下,支付数据是结构化存储成关系模型,并确保数据库操作是事务性的。换句话说,需要保证操作都具有ACID。但是,也有些场景支持跨区域低延迟的访问;
  • Billing集成DVD业务,但两者的架构不同,增加了集成的难度;
  • Billing team需要为Netflix客户服务中心提供数据支持,回答Netflix会员的支付问题。同时为客户支持提供数据预览。

现有支付系统的架构如下:

image

  • 数据中心有2个Oracle数据库:一个存储用户订阅信息,另外一个存储是付费数据;
  • 基于REST 的多个应用:从www.netflix.com到客户支持应用的服务调用;
  • 3个批量应用:
    • Subscription Renewal
    • Order & Payment Processor
    • Revenue Reporting
  • Billing Proxy应用(AWS云服务):从Netflix应用路由调用到数据中心;
  • Weblogic队列:进程间的通信。

迁移支付系统的目标是把所有这些入AWS云服务。

迁移步骤

整个过程分三步走:

  • Act I:新国家地区的支付数据直接上云,并把数据同步回数据中心以供批量作业工作;
  • Act II:面向用户的数据持久化到Cassandra,保证数据最终一致性,不需要保障操作的ACID;
  • Act III:最后迁移SQL数据库到AWS云服务。

Act I – 转发新国家的支付数据到AWS云服务,并同步数据到数据中心(DC)

Netflix新增加6个国家地区,并把部分国家的支付数据放在云上。这意味着面向用户的数据和应用将在云服务中,但同时也需要同步数据回数据中心。这些新增加的国家的用户数据在云服务上服务,同时批处理仍然运行在数据中心。关于Netflix数据中心可以见Part I。

所有的API都是基于云服务用Spring Boot 和Spring 集成开发的应用。Spring Boot提供了框架,使得作者能够快速的开发新应用,并把注意力更多的聚焦在业务逻辑上。Spring 集成一次编写、可重用。新增6个国家的会员数据的API调用可在AWS的任意区域处理,数据存储在Cassandra数据库。这使得即使整个AWS区域宕机,这些国家的支付数据仍可使用,这就是云服务的魅力所在。

Netflix在AWS云服务多个区域的EC2实例上发布应用。他们为云服务代理应用增加一个转发层,把新加的国家的用户支付调用转发到云服务上新的支付API,而老国家地区的支付调用还是继续到数据中心的老支付API。他们从AWS云服务区域之一直接连接到数据中心的Oracle数据库,然后开发一个应用通过SQS来同步其它三个区域的Cassandra数据到这个区域。

Netflix从数据中心迁移Subscription Renewal 应用到AWS云服务,所以他们不能把负载放在数据中心。对于新增的国家区域,他们写爬虫每天去Cassandra爬取会员数据,并追上会员付费数据。行迭代方法在新增的国家使用,但对于其它国家的数据,特别是美国数据量太大,不容易迁移到云服务。不过这事还得继续,只能试试水。

Netflix选择Cassandra作为数据存储是因为它可以写入到AWS任意区域并快速复制写入其它区域。作者设计数据模型如图所示:

image

Act I步骤实施后,支付系统架构如下:

image

Act II – 迁移所有应用和已有国家的数据到AWS云服务

步骤Act I成功完成后,Netflix支付团队开始迁移其它应用到AWS云服务上,此时Oracle数据库未迁移。大部分业务逻辑是批量应用,而且已经成熟的运行了好多年。此次借着迁移的机会把原有代码进行了重构。

Netflix开发Aegisthus从Cassandra SSTable来拉取数据,并转换成JSON格式的行。Pig脚本按天跑mapreduce来处理海量数据集。Sqoop作业从Cassandra 和Oracle 拉取数据写入Hive。为了验证海量数据的迁移,Netflix开发一个comparator tool来比较验证迁移前后的数据。

各项准备工作做好之后,Netflix支付团队首先拿会员数少的国家“开刀”,迁移的步骤大概如下:

  • 迁移时禁用non-GET的API。(这不会影响会员,但会造成支付的更新和订阅的延迟);
  • 使用Sqoop job从Oracle 获取数据,写入S3 和Hive;
  • 用Pig转换数据写入Cassandra格式;
  • 插入所有的会员记录到Cassandra;
  • 启用non-GET的API。

在验证迁移后的数据之后,开始迁移下一个国家,最后迁移的是美国,因为美国的会员量最大。

步骤Act II完成之后,支付系统的架构变为:
image

Act III – 和数据中心Say “Good bye”!

最后开始迁移剩下的Oracle数据库。考虑到Oracle高度的关系型,如果迁移到NoSQL的数据,将会比较麻烦。在支付团队忙于前两步时,云数据库工程师迁移Oracle数据库到EC2的MySQL实例。所以在迁移第三步时,MySQL数据库已准备好。接下来,对前期的代码做了部分兼容的优化。

现在的数据库架构包括一个MySQL Master数据库,一个容灾 DB (从MySQL Master复制,如果Master挂掉即可启用为Master),Slave数据库(用来做应用的访问)。

整个支付系统迁移完之后,架构图如下:

image

在路上

随着支付系统迁移到AWS云服务的完成,Netflix流式架构已全部运行在云端。Netflix可以按需扩展任意Netflix服务,基于用户量来做预测性扩容,使用Spinnaker单点发布和Netflix各应用的持续发布。

参考

[1] http://techblog.netflix.com/2016/07/netflix-billing-migration-to-aws-part-ii.html


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

若发现以上文章有任何不妥,请联系我。

image