2016年1月4日，就在Netflix向130个新国家进行业务扩展之前，Netflix Billing(计费系统)基础设施成为100% AWS云原生架构。Billing基础设施完成了由Netflix数据中心向AWS云的迁移。
对于一家企业而言，它的计费方案是金融命脉，与此同时，它还是一家公司对待客户态度的可见表现形式。而极好的客户体验是Netflix的核心价值之一。考虑到Billing会直接影响Netflix与会员的财务关系和自身财报这样的敏感性，此次迁移要尽可能巧妙处理。Netflix的主要目标是为其迁移到云定义一个安全，弹性，细化的路线，且对会员体验无影响。
我们对Billing生态系统从Netflix数据中心到AWS云的迁移方案进行了深入探讨。
Billing架构的组成
Billing基础设施负责管理Netflix会员的计费状况。这包括追踪开始/已支付周期，会员账户上的信贷额，管理会员的支付状态，发起费用请求以及会员的支付时间。除了这些之外，计费数据会导入财务系统中用于Netflix的营收和纳税申报。为实现上述功能，计费工程包括：
批量作业，为全球用户群构建经常性更新订单，汇总数据反馈至总账(GL)用于所有支付方式包括礼券，读取并发布到税务引擎的税务服务等日常营收。产生的消息事件和流媒体/DVD基于客户的账单状态保留事件。
Billing API向客户服务平台和网站提供计费和礼券信息。除此之外，Billing API也是发起如会员注册，变更计划，注销，更新地址，拒付和退款请求等，处理用户操作流程部分。集成了各种如会员账户服务，支付处理，客户服务，客户信息，DVD网站和发货服务。
Billing系统在数据中心和云内采用云原生系统进行了集成。从高层次上来讲，Netflix的预迁移架构可能如下图被抽取出来：
考虑到代码和数据与Oracle进行交互的数目，Netflix的宗旨之一就是将基于Oracle系统的解决方案分离到一个基于服务的架构中。Netflix的API其中一些需要跨区域性和高可用性。因此它们决定将数据分离到多个数据存储库。用户数据被迁移到Cassandra数据库。支付处理集成需要ACID事务操作.因此所有相关数据都被迁移到MYSQL。以下是Netflix贴出的迁移架构表现形式。
挑战
随着Netflix着手迁移这项庞大任务，也意味着它要所面临许多挑战。
迁移最好不要影响到面向用户的流量。
为了迅速发展用户群，AWS内的新架构必须要进行扩展。
自1997年Netflix成立以来，产生了几十亿行数据，不断地改变和组成历史数据。Oracle内Netflix的大型共享数据库数据分分钟都在增长。将这些数据迁移到AWS，首先要传输并将其实时同步到云内两位数TB的RDBMS。
作为一个SOX系统这又增加了一层复杂性，因为整个迁移和工具作业需要遵循Netflix的SOX流程。
Netflix正是向全球扩展业务的时候，Billing的迁移绝不能影响为自身迁移和全球发布忙的焦头烂额地其它团队。
方案
Netflix迁移方案是按照简单的原则进行——帮助Netflix确定前进的方向。以下概述了最重要的部分：
挑战复杂性与简化：虽然简单接受复杂的传统系统比挑战它要容易得多，但当你“仰望”海量数据和代码的时候，简化就成了关键。Netflix耗费了几天时间开发并且反复要求自身进行简化。
清理代码：Netflix开始将现有代码清理到更小的有效模块中，并率先迁移一些重要的相关方案——将税务解决方案迁移到云。
接下来，Netflix不再从Oracle系统表格中提取会员计费历史记录，而是构建了一个新的应用程序捕获计费事件，只将所需数据迁移到新的Cassandra数据库，然后开始在云内提供全球计费历史记录。
Netflix花了大把时间编写数据迁移工具，以便将会员计费属性跨Oracle系统内表格转换为更简单的Cassandra数据结构。之后与DVD技术团队合作进一步简化集成，然后清除过时的代码。
清除数据：Netflix认真审查了所有表格，确保迁移所需数据。历史计费数据对法律和客户服务团队很有价值。Netflix的目标是仅将所需数据迁移到云。因此需要与受影响的团队合作找出它们真正需要的历史数据部分。Netflix还确定了另一种数据存储方案来服务这些团队的旧数据。之后再开始清除无意义数据。
构建工具来实现弹性与兼容性：Netflix的目标是零宕机迁移应用程序。为了实现这一目标而构建了代理和重定向工具以便将数据传输回数据中心，帮助Netflix保持数据中心内的应用程序不受变化影响，直到Netflix准备迁移这些数据。
Netflix必须要构建工具，支持SOX系统与Billing云基础设施兼容，并确保应对意料之外的开发者操作和操作审核。
Netflix的云部署工具Spinnaker提高了对Chronos和大数据平台捕获部署信息和通道事件的能力以便审核。Netflix还强化了Cassandra客户端用于身份验证和审核操作。此外，采用Atlas写入新通知用于监控云内应用程序和数据。
在数据分析团队的帮助下，Netflix针对Oracle内的数据制作了比较器，根据国家和报告不匹配度来协调Cassandra数据库里用户数据。为了实现以上目标，Netflix频繁使用其大数据平台捕获部署事件，采用sqoop将它的Oracle数据库和Cassandra集群传输到Hive。Netflix还写入了Hive查询和MapReduce工作用于所需报告和仪表盘。
首先是用有限的新数据集进行测试。随着Netflix向新的国家进军，虽然提供了一个利用新数据测试Netflix云基础设施的机会，不会降低权重,但仍伴随着很多挑战。因此Netflix在云里针对所有面向用户功能构建了一个新的计费基础架构，集成了数据中心应用程序来完成这个计费流程。一旦新的国家数据在云内被成功处理，那么向大型传统国家拓展云业务也就信心十足了。尤其是在美国，Netflix不仅支持流媒体还有DVD计费。
分离面向用户的流量避免宕机或其它迁移影响客户体验：Netflix在准备将现有会员数据导入Cassandra时，需要停机来暂停处理同时将用户数据从Oracle迁移到Cassandra用于API和云内批处理更新。所有的工具都是围绕按需迁移一个国家隧道流量的能力构建的。
Netflix致力于电子商务和会员服务将用户工作流程集成改变为一种异步模式。Netflix构建重试能力，重新运行失败处理然后按需重复此步骤。Netflix增加了积极的客户状态管理确保在处理被中止时，会员不受影响。
以上，Netflix迁移了数百万行数据，且用户未受到任何明显的影响。
迁移一个数据库需要自身策略规划：规划数据库迁移，同时还要以最终目标为准绳，否则可能会出错。迁移有很多决策制定，从存储预测到吸收至少一年的数据增长——转化成若干所需实例，认证成本用于产品和测试环境，采用RDS服务对应管理大型EC2实例，确保数据库架构可解决数据的扩展性，可用性以及可靠性。构建灾备计划，计划可能的最低迁移宕机时间等等。作为迁移的一部分，Netflix决定从认证的Oracle迁移到开源MYSQL数据库，运行Netflix管理的EC2实例。
虽然Netflix的订阅处理采用了Cassandra数据库数据，但支付处理器需要RDBMS 的ACID功能进行处理费用交易。Netflix仍有一个多TB型数据库由于TB局限性不适用于AWSRDS。借助Netflix平台核心和数据库工程，在不同区域内利用DRBD复制和多个可读取副本定义了一个多区域，可扩展架构进行MYSQL控制。Netflix将所有的ETL处理迁移到副本避免主资源争用。数据库云工程针对MYSQL实例构建了工具和通知，确保监控和恢复需求。
其它大的挑战是无宕机向AWS 内MYSQL迁移不断变化的数据，经过多种选择探索，Netflix采用了Oracle GoldenGate进行处理，它能伴随不断地递增变化，跨不同数据库复制表格。当然，这是一个非常大的数据迁移，需要几个月时间并行生产运营和其它迁移。Netflix进行了反复测试然后针对MYSQL发布固定周期，运行应用。最后，经过几周，Netflix开始在MYSQL上运行测试数据库，在对Oracle系统做最终确认和发布生产之前，测试和解决所有MYSQL代码分支问题。然后对MYSQL运行测试环境，不断构建反馈循环。
1月4日，Netflix正式对MYSQL迁移处理流程和数据ETL。
Netflix的反思
虽然Netflix向云迁移相对顺利，但回想一下，一些事可以做的更好。Netflix低估了自动测试需要，没有一个测试端对端流量的好办法。前期如果在这些方面多花心思，开发速度会更快。
