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低估了自動測試需要，沒有一個測試端對端流量的好辦法。前期如果在這些方面多花心思，開發速度會更快。