網易數據運河系統NDC設計與應用

作者：馬進

【導語】NDC是網易近一年新誕生的結構化數據傳輸服務，它整合了網易過去在數據傳輸領域的各種工具和經驗，將單機資料庫、分散式資料庫、OLAP系統以及下游應用通過數據鏈路串在一起。除了保障高效的數據傳輸外，NDC的設計遵循了單元化和平台化的設計哲學，本篇文章將帶大家近距離了解NDC的設計思路和實現原理。

NDC簡介

NDC全名Netease Data Canal，直譯為網易數據運河系統，是網易針對結構化資料庫的數據實時遷移、同步和訂閱的平台化解決方案。

在NDC之前，我們主要通過自研或開源軟體工具來滿足異構資料庫實時遷移和同步的需求，隨著雲計算和公司業務的大力推進，公司內部，尤其是運維團隊開始對數據遷移工具的可用性、易用性以及其他多樣化功能提出了更多要求和挑戰，NDC平台化解決方案便應運而生。NDC的構建快速整合了我們之前在結構化數據遷移領域的積累，於2016年8月正式立項，同年10月就已上線開始為我們的各大產品線提供在線數據遷移和同步服務。

業界中與NDC類似的產品有阿里雲的DTS、阿里開源產品DataX、Canal、Twitter的Databus，在傳統領域有Oracle的GoldenGate、開源產品SymmetricDS。從產品功能、成熟度來看，NDC與阿里雲DTS最為相似，都具有簡、快、全三大特性：

簡，使用簡單，有平台化的Web管理工具，配置流程簡潔易懂。

快，數據同步、遷移和訂閱速度快，執行高效，滿足互聯網產品快速迭代的需求。

全，功能齊全，NDC支持多種常用的異構資料庫，包括Oracle、MySQL、SQLServer、DB2、PostgreSQL以及網易分散式資料庫DDB，除了可以滿足不同資料庫之間在線數據遷移、實時同步之外，NDC也可以實現從資料庫到多種OLAP系統的實時數據同步和ETL，目前同步目標支持的OLAP系統包含Kudu和Greeplum。另外，NDC支持對資料庫做數據訂閱，通過將資料庫的增量數據丟入消息隊列，使應用端可以自由消費資料庫的實時增量數據，從而實現由數據驅動業務，複雜業務之間調用解耦。

提煉場景和需求是做好產品的第一步，本文先通過三種典型應用場景介紹NDC的使用價值，之後從產品形態和系統架構兩方面闡述NDC在產品交互、集群管理、資源調度以及跨機房部署上的設計理念，最後介紹NDC實現數據遷移、同步和訂閱的一些原理和關鍵特性，可以為開發者在實現類似功能時提供思路和參考。

應用場景

下面通過三個真實案例分別說明NDC在數據遷移和數據訂閱上的應用場景。

DDB數據遷移

分散式資料庫DDB自2006年就開始為網易各大互聯網產品提供透明的分庫分表服務，在我們的知名互聯網產品背後，幾乎都可以看到DDB的身影，如考拉、雲音樂、雲閱讀、教育等。

DDB作為分庫分表的結構化資料庫，一張表的數據一般存儲在多個數據節點中，每張表會選擇一個或多個欄位作為分區鍵，來決定數據在數據節點上的分布方式。以用戶表為例，有用戶ID作為主鍵，電話號碼和郵箱作為唯一健，分區鍵一般會選擇這三個欄位中的任意一個或組合。分區鍵的選擇決定了數據分布均勻與否，隨著業務數據量的增長，可能會發現之前選擇的分區鍵區分度不夠高，而需要更改分區鍵的需求，分區鍵的修改涉及到數據重分布，並且修改過程要與業務的線上服務同時進行，這就要求DDB提供在線數據遷移的解決方案。

與此類似，在業務發展過程中可能遇到表擴容或機房遷移的情況，都需要DDB的在線數據遷移功能，以表擴容為例，NDC解決DDB在線數據遷移方式如圖1所示。

圖1 NDC解決DDB數據遷移問題

當DBA發起一個修改分區鍵或擴容請求時，管理工具會統一將其解析成一個數據遷移命令，並向NDC服務發起相應的調度請求，NDC則根據調度規則選擇一組執行節點執行具體遷移過程，每個源端數據節點都會有對應一個遷移進程來拉取該節點上的全量數據和增量數據，並將這些數據通過DDB的分庫分表驅動重新應用到目標表。當目標端和源端的數據延遲在追趕到毫秒級範圍內後，通過在DDB管理工具上執行切換表操作完成最後的遷移工作。

應用緩存更新

應用緩存更新是NDC數據訂閱一類非常典型的應用場景，在沒有使用數據訂閱做緩存更新的應用環境中，緩存數據通常由應用伺服器自己維護，但是由於緩存操作和資料庫操作不具有事務性，簡單的緩存操作可能帶來數據不一致的情況，如圖2所示。

圖2 緩存資料庫不一致問題

在圖2場景中，線程2在將緩存更新到最新數據後，又被線程1非同步滯後地更新成老數據，由於線程1和線程2沒有任何狀態共享，資料庫中後操作的數據可能在緩存中被先操作的數據覆蓋掉，導致緩存和資料庫數據不一致。若這種情況出現，除非緩存主動淘汰，否則應用將始終讀到臟數據。

對上述的數據不一致問題，業界也有一種基於CAS的解決方案，但會對緩存增加至少一倍以上的壓力。而通過NDC的數據訂閱，可以比較完美地解決上述問題，NDC數據訂閱將資料庫中的增量數據丟入消息隊列，應用讀取消息隊列的內容，並將其同步到緩存系統，在這個過程中，NDC執行節點和消息隊列保障高可用，而資料庫增量數據具有唯一性和時序性，可以避免緩存和資料庫的狀態不一致。

如果說使用數據訂閱只是緩存更新的一種優選方案的話，那對下面的多機房緩存淘汰，NDC的數據訂閱功能就是必選方案了。

圖3中，應用部署有主機房和備機房兩套環境，兩套環境各有一套應用服務，緩存和資料庫，為了保障主備機房數據一致，數據寫入只能走主機房，備機房資料庫是主機房資料庫的只讀從庫，這種架構普遍適用於讀多寫少的應用系統。

圖3 NDC解決多機房緩存淘汰問題

在業務不適用數據訂閱來更新緩存的情況下，從機房在執行刪除數據時，先刪除主機房數據，再刪除從機房緩存，而從機房的資料庫同步具有一定的滯後性，在滯後的這段時間，從機房應用服務可能會將從機房資料庫的臟數據重新載入緩存，導致從機房應用依舊能看到刪除後的數據。為此，我們的方案是使用NDC訂閱從機房資料庫的刪除操作，保障從機房資料庫和緩存在刪除操作上具有一致性。

OLAP系統整合/ETL

業務資料庫與OLAP系統的數據整合，是互聯網產品架構中非常重要的一環。比較傳統的應用一般採用定時從OLTP庫中將數據全量導入OLAP系統，比如每天凌晨1點開始把線上MySQL中所有數據通過Sqoop導入到Hive。這種做法有極大限制性：首先，ETL的時間完全不可控，這對於時效性比較敏感的數據尤為重要；其次ETL過程中對源庫負載壓力非常大，尤其對數據量大的應用，而控制ETL對源端負載影響就意味著ETL時間更加失控。

在NDC這樣的系統出現後，架構師們有了更加明智的選擇：通過NDC實現結構化數據的增量ETL。首先使ETL從小時級延遲降低到秒級，其次NDC的增量數據拉取對源端影響非常小。對直接支持數據更新的OLAP系統而言，可以直接通過NDC實現ETL，如Kudu、HBase。對於不支持數據更新的系統，如Hive，可以通過NDC的數據訂閱功能將資料庫增量數據發布到消息隊列，再定時從消息隊列中獲取增量數據，並通過MR合併到存量數據，當然這裡的定時要比原先定時全量的時間間隔小很多，比如每小時、每15分鐘——通過這種方式實現准實時的ETL。

圖4 通過NDC實現OLAP系統整合與ETL

產品形態

在產品形態上，NDC具有平台化、可插拔和單元化三大特性。

平台化

往前追溯幾年，各種PaaS和SaaS服務還未如現在這般舉目皆是，運維小夥伴還比較習慣以部署軟體的方式為業務方提供各種服務，比如在NDC之前，我們有軟體包Hamal來支持DDB的各種數據遷移工作，DBA在實施DDB擴容時，需要經歷以下步驟：

準備一定數量的物理機或雲主機跑遷移任務；

在這些節點上部署Hamal進程，配置源端目標端，並發度等參數；

通過Hamal日誌或監控程序實時查看遷移進度；

數據遷移追趕上線上的數據增長後，完成切表或切庫操作；

回收Hamal進程，釋放相關資源。

隨著負責的產品越來越多，規模越來越大，管理員在不同產品的機器、配置之間疲於奔命，大量重複性工作增加了犯錯可能，更要命的是遇到資源不足，可能還要經歷漫長的採購周期。對於DBA一類的運維人員，迫切需要一套幫助他們解決採購、部署、調度以及任務完成後的資源回收等一系列運維工作的平台化管理工具，這便是NDC。

NDC提供有跨IDC的平台化Web管理界面和類似雲計算的租戶管理概念，產品管理員在使用NDC時，在產品相關租戶下創建、修改和刪除具體的數據遷移、同步和訂閱任務，由NDC調度中心將任務調度到相關的執行節點。另外配有專門的平台管理員對NDC整個平台做容量規劃，NDC管理界面如圖5所。

圖5 NDC管理界面

圖中可以看到，NDC除了提供基本的任務管理之外，還為管理員提供了大量運行時的監控統計數據，幫助管理員更好地把控任務進度和狀態。

可插拔

NDC除了向產品管理員和開發者直接提供服務外，同時也是DDB數據遷移、猛獁（網易大數據系統）數據同步的依賴組件，如圖6所示。

圖6 NDC平台可插拔特性

在DBA通過DDBAdmin做表擴縮容，更改分區欄位等操作時，DDBAdmin會把請求解析成多個數據遷移任務提交給NDC。類似的，未來NDC可能還會支持其他自身有認證功能的平台系統，比如公有雲，為此，NDC 需要做到其他平台的輕鬆插拔。

NDC的平台插拔特性，本質上是要支持不同租戶認證的可插拔，因為依賴於NDC之上的其他平台大都實有自己的租戶認證功能，要求NDC支持這些不同的認證方式是不現實的，我們的做法是「認證服務」，具體的租戶認證交由上層平台自己完成。與此同時，我們可以按照上層平台的租戶名對任務做物理隔離和任務視圖的劃分。租戶可插拔的另外一個要點，是NDC自帶的租戶認證需要在API服務內實現，從NDC的調度中心來看，API服務與其他平台是同一個架構層的不同接入平台。

NDC可插拔的另一個含義是「功能可插拔」。立項至今，NDC前前後後支持了六種關係型資料庫、三種OLAP系統，每種源端和目的端都是通過實現統一的Extractor和Applier介面來支持，而且我們在JAR包上做了合理拆分，以便一些功能修改可以獨立上線。未來對新的源端目的端的支持也可以通過實現介面和新增JAR包在不重啟任何進程的前提下完成擴展。

單元化

可以通過NDC實現跨機房的數據同步解決方案，尤其對體量比較大的應用，如網易考拉、雲音樂，普遍需要在同城甚至異地機房之間做服務冗餘、擴展和容災。相對應地，這些應用所依賴的底層服務也需要具備多機房冗餘和擴展的功能，如圖7所示。

圖7 NDC跨機房的單元化解決方案

在一個機房內的系統架構中，應用服務無狀態，緩存、大數據，這些有狀態系統的數據來自於資料庫的數據同步和訂閱，而資料庫的數據除了本機房內應用產生外，也可以來自NDC從其他機房的數據同步。從這套架構中可以看出，通過NDC同步機房間的資料庫數據，再由NDC將資料庫的變更同步到大數據、緩存、消息隊列，由此驅動業務在機房間無縫擴展和冗餘。

在圖7中，每個機房內從應用服務到資料庫，具有一套完整的數據鏈路，機房內部的網路、IT資源，相關的各種調度都具有高度自治性，機房間的耦合模塊只有通過NDC共享資料庫數據，業界目前將這種具備完整服務鏈路，且高度自治的跨機房方案稱之為「單元化」，NDC的單元化要求在每個機房內部署獨立的調度中心和執行節點組，需要注意的是，單元化並不包含NDC的API服務，API服務具有無狀態、請求離散等特性，沒有必要獨立部署，同時跨單元的API才能提供平台化的管理服務。

值得一提的是，所謂「單元」是一個邏輯概念，一個單元具有物理隔離和高度自治的特性，我們也可以在一個機房內部署多個NDC單元，以區別和隔離不同業務線，比如我們可以為DDB和猛獁部署一套獨立單元來支撐他們的平台依賴，不過一個單元基本不會跨機房部署。

系統架構

一個單元內的NDC系統架構如圖8所示。

圖8 NDC架構圖

最上層無狀態的API服務，是一套直接面向用戶的平台化Web管理工具，API節點通過RPC向調度中心Center發起請求，除了API節點外，Center也會接受來自DDB管理工具、猛獁管理工具等其他平台的RPC調用請求。

Center是NDC的大腦，所有管理、調度、監控、報警工作都需要通過Center來執行，Center目前在一個單元內屬於單點服務，通過高可用組件做冷備，由於元數據統一存儲在NDC的系統庫中，主備Center之間無需數據同步。Center會定期收集單元內所有Engine節點的負載狀況、任務執行狀態等信息，以實現均衡的任務調度，在任務失敗時自動重試或重新調度，保障任務執行具有高可用特性。

Engine是NDC系統中數據遷移、同步和訂閱的任務執行者，它接收來自Center的調度請求，並維護一組實際任務執行進程Executo。在任務執行過程中，Engine負責收集每個執行進程的任務狀態、進度信息，並實時上報給Center。Center不知道任何Executor的存在，任務執行進程全權託管於Engine，並由Engine全程監控。

「單元」是NDC物理資源隔離的最大單位，除了基於單元的隔離之外，NDC還提供了租戶級別的物理隔離，管理員可以為租戶分配獨佔的任務執行節點。在配置任務屬性時選擇「獨佔型」任務，則任務只會調度到屬於該用戶的資源池中，以確保任務執行具有節點級別的隔離性，而普通共享型任務只具備進程級別的隔離性。

實現簡述

NDC是面向結構化資料庫的數據遷移、同步和訂閱的解決方案，而數據同步可以看做一種「永不結束」的數據遷移，下面我們就NDC在數據遷移、數據訂閱以及一些關鍵特性上的實現方式做個簡要介紹。

NDC的訂閱和遷移都以表為單位，如無特別說明，下文中的遷移對象均指要遷移的表。

數據遷移

與通常的「遷移」概念不同，NDC的「數據遷移」並不是將源端的數據挪到目標端，而是在保障對源端數據影響儘可能小的前提下，將源端的數據「複製」或「同步」到目標端。比如線上資料庫到數據倉庫的ETL，需要在不影響線上服務質量的情況下將數據實時同步到數據倉庫。又如DDB的在線擴容，也需要在擴容的過程中不影響原有的數據節點。

當用戶通過Web工具啟動一個數據遷移任務後，NDC調度服務會根據任務類型、調度演算法和節點負載，在相關的Engine資源池中選擇一個或多個節點下發任務，一個遷移任務對應一個源端資料庫實例。

數據遷移引擎中任務執行流程如圖9所示。

圖9 NDC數據遷移執行流程

從圖中可以看出，全部的數據遷移流程包含以下四個步驟：

預檢查：檢查資源、網路可用性、Schema兼容性、用戶許可權等；

全量遷移：源庫、表中存量數據的遷移過程；

增量遷移：遷移過程中，源庫、表增量數據的遷移過程；

數據校驗：對源端和目標端同步的數據做抽樣校驗。

預檢查階段，NDC會檢查源端和目標端的網路連通性、空餘資源可用性、遷移使用的源端目標端用戶在相關庫表上的許可權、白名單、要遷移的Schema是否兼容等。NDC不要求遷移對象在源端目標端的Schema嚴格一致，但要求目標端對源端兼容，比如源端欄位類型int到目標端可以為bigint，反之則預檢查報錯，源端目標端在索引結構上允許有差異。

預檢查完成後，NDC任務執行進程會立即啟動增量數據拉取模塊，在開始拉增量數據之後，啟動全量遷移流程。顧名思義，全量遷移是將遷移對象的存量數據同步到目標端。NDC的全量數據遷移採用「快照讀」，而判斷遷移對象中哪些數據是存量數據，哪些是增量數據的依據，是在開始全量遷移的時候獲取遷移表的最小主鍵和最大主鍵，在獲取到的最小主鍵和最大主鍵之間的所有數據，被認為是存量數據，以外則作為增量數據處理。之所以沒有像MySQLDump一類的遷移工具使用大事務來劃分存量數據，是為了避免大事務令源端回滾段不斷累加的影響（這是針對MySQL而言，對不同類型的源端資料庫，大事務都會造成一定的不良影響），而使用快照讀，會使全量遷移過程中引入一部分增量數據，但這部分增量的「臟數據」最終會被增量遷移修正，不影響數據的最終一致性。

全量遷移以表為單位進行，不同表之間可並發遷移，增量遷移則以源端實例為單位（想想MySQL的binlog），所以在一個遷移任務中，所有遷移對象都完成全量遷移後，才會進入增量遷移階段。

增量遷移至少包含兩個線程，第一個是增量數據拉取線程，在全量遷移開始之前啟動，負責將源端所有（相關）增量數據緩存在本地磁碟；另一個是增量回放線程，在增強遷移過程開始時啟動，它的作用是不斷讀取本地緩存的增量數據，並按照時間順序回放到目標端。

由於全量遷移是在增量拉取開始之後才進行的，NDC可以保障全量遷移過程中引入的增量數據最終會在目標端回放出來。

全量遷移和增量遷移過程中會有一部分增量數據被重複導入，NDC會保障增量數據導入具有冪等性。

隨著增量遷移的進行，目標端增量數據和源端增量數據的時間延遲會逐漸縮短，最終這個延遲控制在1s內之後，我們將這個遷移任務定義為同步狀態。對同步狀態下的遷移任務，管理員可以選擇實施數據校驗，一般建議採用源端5‰到100‰的隨機數據校驗源端和目標端的數據一致性。

NDC數據遷移中的全量遷移、增量遷移以及數據校驗都是可選流程，不過NDC要求管理員至少勾選全量遷移和增量遷移中的一種，數據校驗是遷移任務進入同步狀態後的可選操作，不是在提交任務時選擇，可反覆執行。

在實踐中，當數據遷移任務進入同步狀態後，一般會先執行一次數據校驗，再執行相關的切庫切表操作。而對數據同步場景，一般會定期執行全量數據校驗。

數據訂閱

數據訂閱是將資料庫的數據變更實時拉取出來，並交付給下游應用執行相應業務邏輯的過程。與數據遷移相比，數據訂閱邏輯較為簡單——相當於數據遷移中的增量過程，而在應用場景方面，數據訂閱可以應對更加多樣化的業務需求，例如：

通過數據訂閱維護全文索引一類的第三方索引庫

基於數據訂閱維護緩存

通過數據訂閱實現複雜業務非同步解耦

實現更加複雜的ETL

數據訂閱的執行邏輯如圖10所示。

圖10 數據訂閱執行流程

數據訂閱任務由NDC的調度服務選擇合適的訂閱引擎節點執行，與數據遷移增量過程不同的是，數據訂閱引擎不會將增量變更數據緩存在本地，而是直接丟入消息隊列中（使用了我們的消息隊列服務），SDK通過消費消息隊列的數據實現增量數據回放。

之所以用消息隊列代替本地磁碟，是因為SDK的數據回放過程完全由應用方把持，速度不可控，若業務邏輯處理過慢，或下游節點意外宕機，可能導致增量數據大量堆積，這裡消息隊列可以當做一個容量足夠大的消息緩存，使SDK端的非同步消息回放更加優雅。

數據訂閱中Engine必須嚴格按照增量數據的時間順序串列發布消息，無法做到類似數據遷移增量過程中的並發複製，這是因為訂閱任務Engine無法感知應用端SDK消費數據，並發發布消息最終必然導致SDK消費數據亂序執行。

在實踐中，要特別注意消息隊列對發布消息的速率瓶頸以及訂閱任務Engine到消息隊列的網路開銷。

關鍵特性

對NDC的實現部分，再分享三點關鍵特性給大家：

並發遷移

斷點續傳

多源適配

對數據遷移和同步，速度是生命線：如果遷移速度不夠快，任務永遠無法進入同步狀態，遷移和同步也無從談起。NDC的全量和增量過程都支持並發遷移，保障遷移任務能夠儘快地進入同步狀態。

全量遷移並發較為簡單，首先可以在不同的表上做並發遷移，其次數據導入目標端的過程也可以並發執行，select數據和insert數據線程解耦在實踐中能夠極大縮短遷移時間，另外NDC的全量遷移可以配置一次導入操作的數據批量數，減少遷移進程和源端目標端的交互次數。

增量並發回放是NDC最重要的核心實現之一，NDC增量回放線程會根據增量數據之間的衝突關係構建一張或多張有向無環圖，圖中所有入度為0的數據節點都允許並發回放，增量數據導入目標端後會從圖中刪除，從而解鎖其他衝突數據。這種演算法理論上可最大限度發揮並發回放的優勢，在實際的性能測試中，NDC的增量並發回放效率遠高於MySQL 5.7基於Group Commit的並行複製。

斷點續傳是NDC任務漂移和高可用實現的基礎，是指遷移或訂閱任務異常退出，或進程、節點crash之後，可以從最近的位置點重新啟動任務。斷點續傳的實現有兩點前提：一是要求系統定期將任務的位置點信息持久化，在需要時可以從持久化過的位置點恢復任務，NDC的做法是Engine定期將位置點信息上報給Center，由後者將其持久化在系統庫；二是要求遷移和訂閱任務中所有數據導入操作（全量和增量）具有冪等性，對此我們可以採用具有replace語義的SQL實現導入操作，對不支持replace語法的目標端，可以使用delete+insert的組合SQL實現類似語義。在實踐中，保障冪等操作絕對是一項省時省力省心的做法。

多源適配的問題主要在於對不同的源端資料庫，採用怎樣的方式拉取增量數據最為實用和高效，目前主要有以下三種做法：

基於日誌：MySQL binlog、Oracle redo log；

基於CDC：Oracle、DB2、SQLServer；

基於觸發器：適用所有支持觸發器的資料庫。

三種做法各有優劣，觸發器用法較為簡單，對用戶許可權要求比較清晰，但性能較差，尤其是源端線上壓力比較大時，可能產生大量的鎖超時，因此不作為最優選擇；CDC全名Change Data Capture，是一些資料庫特有的功能，可以將資料庫產生的增量數據同步到一些視圖或表中，遷移或訂閱進程通過這些表和視圖來獲取增量數據，可以看出CDC在使用上與觸發器非常類似，區別在於CDC是一些資料庫獨特功能，可以在性能上做優化。以Oracle為例，可以通過解析redo log產生增量數據，比通過觸發器產生增量數據的做法對源端的影響要小很多，CDC的劣勢在於不同資料庫沒有統一規範，方言化嚴重，對許可權要求更加苛刻。

一般情況下，我們將第一種基於日誌的增量數據拉取方案列為最優。以MySQL為例，MySQL自帶的binlog功能可以直接將日誌同步到遠端，對用戶許可權、源端資料庫性能影響也都在可控範圍內。

總結

工欲善其事，必先利其器，NDC顧名思義，就是希望為公司打造一個可以容納各種結構化資料庫實時數據的「數據運河」，並通過運河將數據運輸到不同目的端，應用只需要在管理頁面中簡單地配置幾個參數，便可將資料庫的內容輕鬆整合到其他數據或應用系統中。

NDC的快速構建，很大程度上要歸功於我們團隊在分散式中間件、數據遷移工具等領域的成果和積累，如果開發者要設計和實現類似系統，建議多利用開源資源，比如調度模塊可以考慮集成或使用Apache Azkaban的實現，任務執行模塊也有很多開源工具和代碼可以參考。另外，在設計數據遷移和訂閱平台時要重點考慮以下幾個問題：

與其他平台集成，NDC具有平台可插拔特性，可以非常方便地與網易其他平台服務集成。

任務執行要快，對源端影響儘可能小。NDC具有非常高效的數據全量遷移和增量數據回放模塊，在實現增量數據拉取模塊時，儘可能選擇了同步日誌的方式，對源端影響很小。

要考慮到斷點續傳問題。在任務執行過程中，可能發生網路抖動、分區、節點故障等各類異常，這首先要求我們的任務具備從某個時間點或位置點重新開始執行的能力，其次要求調度中心可以快速發現異常，並使用合理的演算法實現任務漂移。

要考慮到灰度發布。由於NDC的平台化設計，隨著系統功能愈發繁多，一次平台全面升級的代價越來越高，為此我們需要通過灰度升級保障功能在全面上線之前得到充分驗證，另外通過功能「可插拔」的特性，保障一次上線對線上任務的影響儘可能小。

迄今為止，NDC上線半年多，承接應用40+，遷移、同步和訂閱實踐案例10000+，可以預見，在網易未來的雲計算、大數據布局，以及其他各類數據驅動的應用場景中，NDC都將發揮舉足輕重的作用。

End.

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！