转载

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

思考

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

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

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

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

英文原文: Netflix Billing Migration to AWS

原文  http://www.infoq.com/cn/news/2016/07/Netflix-aws
正文到此结束
Loading...