當今科技的發展正在推動著產業格局的演進，而產業變革的核心則是資訊科技的運用。比方說物聯網、5g、人工智慧等等。那麼資訊時代的這種資料的爆炸性增長，給企業業務的連續性帶來了巨大的挑戰，而傳統的災備中心存在著建設成本高，切換時間長，以及災備中心的資源不能充分利用等一些不足。所以目前多雲多活的這種技術正在逐漸興起，那麼為什麼多雲多活被稱為技術皇冠上的明珠呢？下面我想分享一下京東在這方面的一些實踐，京東是如何去做這種多雲多活的以及京東的一些產業實踐案例，我將分為以下4個方面來講。
第一個就是說我們多雲多活的一個產業價值，第二個是講我們技術皇冠上的打磨之旅，我們有哪些困難，以及我們京東科技是如何克服這些困難的。第三個講的是說從技術的理念構建到產品的標準化，我們是如何把這樣一個複雜的流程進行串聯起來，並且作為一個標準化產品，讓客戶能夠簡單的去使用。
最後再分享一下我們在具體的一些產業實踐的案例。
1.多雲多活的產業價值是什麼？
科技讓我們生活變得更加美好，我們可以足不出戶的進行購物支付，那坐在家中就可以等著我們快遞送上門，但是如果說我們的系統發生故障，社會或者個人會造成一些巨大的損失。以下是我們近期全球所發生的一些影響比較重大的一些案例。
在2020年，東京證券交易所由於軟體故障，導致於全日本的交易所停業了，一天影響達到數千億日元，同年的10月，那麼法國的一個IT公司也是由於勒索導致它的全球服務的中斷，公司的損失到達了這種4,000萬歐元，公司的CEO也引咎辭職。
有機構做過一個統計，統計了每個行業在遭受到這種IT系統中斷情況下的平均損失。在金融服務和信用卡授權我們能看到都是上百萬美元，那麼在其他的購物影片點播等等，它的損失達到了10萬美元，這是幾年前美國的一個資料，在我們中國可能損失就更大了。
我們有什麼辦法來抵禦？那麼方法就是建立一個災備系統，災備系統能夠有效的降低企業遇到一些意外故障的時候的業務中斷。
我們中國的一個聯盟做過一個調查報告，在建設了容災體系的情況下，業務停機的損失降低了3.4倍，那麼損失的金額從以前的102萬美元降低到30萬美元，資料丟失的損失降低了3.5倍，從平均的78萬美元降低到了23萬美元。
雖然容災體系的建立能夠有效的降低企業的損失，但是企業業務連續性的提升其實並不是一件容易的事情，IDC曾經做過一個調查，發現企業在建設提高它的業務連續性方面遇到了一些挑戰，比方是說傳統的的災備中心，它的資源利用率不足，不能直接帶來生產力的提升，透過災備中心進行業務切換，那麼切換的時間比較長，很難滿足一些對業務連續性要求比較苛刻的這種行業的需求，比方說金融保險等等。
其次這種災備系統建立，還有成本過高，建設困難，管理困難，使用困難等一系列的問題，所以這種企業建設這種災備中心也不是一件容易的事情。
我們看一下這種業務連續性的演進。
最開始我們可能就是一個單體應用，業務不是在一個機器上，那麼如果這個機器出現故障或者業務發生bug，掛了之後，那麼整個系統就停止了，是最原始的一個應用。
隨後我們把應用進行了拆分，我們把應用部署在多個機器上面，這樣即使機器發生故障也不影響，同時我們應用的例項還可以部署多套，即使有一套發生故障之後也不影響整體的對外服務。同時為了進一步提升這種效率，我們還把這種機器或者應用去跨機架去部署，如果機架發生問題，也不會導致我們整個業務中斷。這是後來引進的一個單機機房的SOA架構，這種架構並不能去抵禦我們整個機房的一個故障，比方說整個機房的電源發生故障了，或者它的網路發生故障了等等，這個時候又衍生出一種同城雙活的這種架構。
我們把應用部署在兩個機房裡面去，資料做主從同步，應用去寫主叢集，這種方式可以規避我們機房的故障，在面對一些對業務要求性更高的一些行業，比方說這種銀行證券等行業，這種方式它沒法去抵禦自然災害，比方說我們整個城市受到了地震或者受到了這種暴風的襲擊，導致這種業務中斷，所以後面我們又衍生出兩地三中心架構，在異地建立第三個災備中心，做異地的備份和業務的備份。
那麼在這種情況下，災備中心往往是不提供服務的，只是在同城業務發生困難的情況下進行切換，這種情況時間比較長，難以滿足很多業務的要求。
近些年由於雲端計算技術的興起，所以我們又開始這種多雲多活的這種建設，把資料進行分片進行拆分，每個機房分片資料，然後業務要進行流量劃分，那麼當某一個機房出現故障之後，它的業務流量能夠在分鐘級之內切換到其他機房裡面去，對於使用者來說，甚至說可能感受不到這種故障的發生，就是我們最近的這種多雲多活的一個架構。
好，為什麼我們要做多雲多活？因為我們經過透過調查發現，多雲現在是全球IT的主流的趨勢， Flex調查發現，全球已經有92%的企業已經採用了多雲的戰略。
多雲戰略是未來企業的主要的方向，企業要充分去利用多雲所提供的這種種能力去發展它的業務，沒有任何一朵雲能夠去滿足所有業務，使用者就發生了多雲需求。
IDC調查也同樣表明了，未來的使用者的業務會急劇的上升，它建議使用者關注跨雲或者邊緣的連線，以及整合。工信部下面的信通院的調查也表明，無論是使用者還是企業，都希望能夠有融合多個雲廠商提供多雲服務的一個產品出現，幫助使用者進行多雲的部署和數字化戰略。
我們能夠看到：多雲不僅是全球的一個趨勢，多雲在國內已經逐漸的興起了，從大型企業到很多政務雲，他們都已經採用這種多雲的架構，對於單一的雲廠商來說，採用多雲的戰略，它的收益會更加明顯。
我們看一下企業的用雲現狀。
那麼最左邊是一個單雲，使用者的所有的業務都跑在一朵雲上，這種情況下使用者就跟這種雲強繫結，往往喪失了議價權，成本會比較高昂，同時也受到這種單雲故障的風險，如果雲發生故障，那麼它整個業務就是一個停滯狀態，所以這種情況下使用者的風險性比較高。
很多企業認識到了單雲的風險，又採用多個雲的這種方式，把他們的多種業務分佈在多個雲上，但是每個業務只在一朵雲上，這種情況下他們業務還是會承受到一定的威脅，比方說我們某個核心業務在某個雲上，如果說這朵雲發生故障，那麼這一部分業務同樣會陷於停滯狀態，這種情況下，使用者的議價權和成本也受到一定程度的繫結，所以各個業務形成一種煙囪狀，不能協同作戰。
那麼第三種我們稱之為真多雲，這種方式下多個雲做了一個抽象，提供統一的執行的資源，使用者會在上面建立統一PaaS元件和使用入口，各個業務可以根據它的業務的選擇或需要分佈在多個雲上，任何一朵雲發生故障的話都不影響整體服務，這個我們稱之為多雲，這也是最理想的一種方式，但這種方式存在著成本投入大，技術門檻高這樣一個問題。
我們曾經做過一個調查，採用這種多個雲的企業這種方式，他們其實也認為他們在雲的使用方面也不是特別滿意。
比方說在價格維度，他們議價權會比較弱，雲廠商往往會跟他們繫結這種資源的用量，
其次在政策維度可能受到監管合規、反壟斷或者、安全的因素，在技術維度如果你跟一個營銷商繫結的越久，那麼技術棧的深度繫結其實不利於它的創新和發展，同樣業務維度的豐富度和質量也比較受限，對於一些中小客戶來說，在它的受重視的程度會比較低，它在運維方面響應的速度會比較慢，同樣也會降低使用者本身的一個業務連續性。
從出海維度，業務覆蓋與開通方面也受到一定限制，那麼繫結的越久，那麼技術與企業的這種風險的在不斷加劇，這是採用多個雲的企業的一些觀點和痛點。
我們看一下我們京東認為的多雲應該是什麼樣的一種方式，我們認為真正多雲應該是在以下5個層面進行打通。
第一個我們稱之為機房通，機房通不僅僅是指機房之間，還有網路互通，而且還要指我們如果在機房之間部署各種監控去監控你這種網路的質量，你的延遲你的頻寬等等，並且可以在這種機房的基礎之上和多雲基礎之上，去劃分我們的各種AZ可用區和Region進行進一步的這種抽象。
其次是網路通，網路通常指的是我們不但要Underlay的網路，Overlay的網路，包括我們的容器網路，也要彼此打通，方便我們的應用進行各種層次的訪問。
第三個是指資料通，通指的是我們的資料在雲上能夠去自由的去漂移，自由的去移動，我們的資料能夠從一朵雲同步到另外一朵雲去，而不受限制，這個資料通其實也是我們跨雲應用多活的一個基礎。
那麼第四個是應用通，指的是我的應用能夠去跨雲的去釋出、去部署，我們的應用多活也是處於這種應用通這樣一個層次，可以把握應用部署在多個雲上並行的去進行管理。
第五個是指的是管理通，管理通指的是說我們的資源從資源層面的管理，從我們的運維層面、運營層面以及安全層面都有一個統一的管控措施。
所以我們認為只有實現了在機房通、網路通、資料通、應用通和管理通這5通，才能是一個真正的多雲的架構。
我們再看一下多雲多活的價值。
首先來說多雲多活對於使用者來說，它能夠使使用者的業務連續性有保障，還能夠控制使用者的故障半徑，減少因為單一機房或者單一雲廠商發生故障，而給業務帶來業務中斷的風險。
第二個是多雲多活，可以做我們多雲戰略的一個很好的支撐，當你的業務分散在不同雲上，那麼就可以根據各種不同雲的技術和技術棧，它的優勢採用不同的方式，可以很好的去支撐多雲戰略，業務就更加靈活。你不會被雲廠商進行某個方面的繫結，同時你還可以去避免它的定價束縛、技術的繫結等等。
第三個是可以幫助使用者進行有效成本的控制。那麼傳統的災備中心，災備只是提供這種冷備的方式，通常不提供生產力，或者說只用於一些這種只讀的方式。多雲多活，它的多個資料中心可以同時對外提供服務，能夠讓我們這種資源利用率得到最大程度的提升。其次它還可以根據不同廠商的價格和策略，動態的在多個雲裡面去調整它的流量，而且這種調整代價極低，所以我們可以根據各個流量價格去動態去分配我們流量，充分去實現我們成本的一個最最佳化。
第四個還可以很方便的進行業務的彈性伸縮，那麼各個資料中心那麼都是可以讀寫的，都是可以隨時進行擴容的，而且流量的這種調整支援各種的分流策略，可以很靈活的根據業務的需求進行調整。
2.要實現“多雲多活”，需要解決哪些核心難題？
那麼第二點我們看一下，為什麼說我們是技術皇冠上的明珠？
多雲多活的打磨之旅是怎麼樣的？
多雲多活雖然有上面我們所提及的種種優點，但是多雲多活的建設其實也面臨著很大的困難。
第一個就是說異構多雲的資源，我們怎麼去統一的去納管？每朵雲對外介面、API、產品形態都是不一樣的，如果要去適配的話難度會比較大。
其次是說多雲多地域，它的之間的資料實際性如何進行漂移的，資料時效性怎麼保證，一致性怎麼去保證，這是第二個問題。
第三個就是說多雲之間我們能夠做流量去怎麼去進行排程，有些什麼樣的糾錯和保護措施。
第四個是說我們現在是很多企業採用這種微服務的方式，我們的微服務框架是怎麼去支援多雲方面等等。這4個問題是我們在多雲多活建設所面臨的4個主要問題。
先看一下多雲的統一管控問題，對於多雲的管控，我們進行了一個把整個多雲管控抽象出一個我們稱之為Open Cloud的這樣一個抽象層，由抽象層負責去對接下面底層的各個雲廠商，而Open Cloud對上提供統一的介面和API對接各種應用，包括我們這種企業的應用，包括我們這種多雲多活，都是在Open Cloud上進行統一的介面對接的。
這樣的好處就是說使用者不用再去逐一的去適配每個雲廠商的千差萬別的介面了，而只需關注業務的自身發展就可以了。除此之外，我們的Open Cloud也幫助使用者可以重新替換規劃能力，。當然從管控層面進行統一抽象之後，對於使用者來說就管理管控更加容易了，也降低了使用者的這種運維成本。
看一下具體的一個圖。
使用者有兩個自建的IT機房，然後業務分佈在兩個不同的雲上，這種情況下我們就可以把這4個機房做1個抽象，比方說我們既可以把機房123把它抽象成1個VPC，也可以把第一個機房作為1個VPC，23機房和A雲統一成為一個VPC，透過這種方式向上去做它這種資源的整合，在上面再去搭建我們統一的這種PaaS元件，進行這種跨雲的多活釋出等等。
透過Open Cloud這個層次遮蔽底層各多元的複雜度，構建一個物理分離，邏輯統一的這樣一個層次去滿足使用者的執行時環境。
那麼使用者的業務在使用的時候，就不用感知多雲的技術差異了，對於它來說像是一個單一的雲一樣去部署釋出和運維，同時這種方式使用者也可以把公有云作為一個彈性池，如果說當某個業務這種峰值到來的時候，我本地的機房不能滿足負荷，那麼它就可以很容易的把這種需要的資源彈到公有云上去，由公有云來承接一部分流量，從而滿足整個業務的一個峰值。
透過這種方式，我們使用者這種業務規劃也能夠更靈活，那麼成本也能夠得到降低，因為你不用去維護很多這種機房，而隨時可以去往公有云上去彈資源。
目前我們Open Cloud支援這種公有云、私有云以及虛擬化等各個平臺以及各種雲服務商的接入了，目前已經支援了10多個雲服務商的接入，而且也支援VMWare這種方式，這種方式之下，使用者可以去這種統一的 Open cloud上去構建自己的VPC實現網路的隔離，去劃分自己的子網。
同時我們還提供虛機和物理匯入能力，也可以把自己目前在機房或者在雲上的主機透過匯入的方式放到我們的平臺裡面去，而且還提供統一的介面和介面在各個雲上去建立我們的虛機。透過open cloud我們可以實現對我們的運維和使用帶來極大的便利。
第二個就是資料在多個雲之間是如何做漂移的，資料的一致性和安全性怎麼來解決？
那麼資料複製其實是多雲中的一個很大難點，那麼我們京東為了解決在資料在不同地域不同機房裡的這種複製問題，我們專門做了一套我們稱之為資料複製中心DRC這樣一個平臺，來進行我們的資料複製。它可以支援多種同構或者異構的資料庫的單向或雙向同步，同時它能夠支援快取以及訊息佇列的同步訂閱。DRC其實目前已經成為我們京東零售和京東科技進行單元化應用多維的一個基石。
DRC有一個三高一低的特點，三高，它具有高可用、高可靠、高效能以及低延遲這個特點，可以看它這個架構圖，而這個圖裡 DRC它其實會分為生產者和消費者兩個方式，生產者負責從源資料庫抽取了全量、增量資料，進行資料過濾一些這種策略，這些資料透過GRPC的方式傳送給消費者，然後消費者會對資料進行一些最佳化處理，比方說執行一些並行策略，進行SQL合併等等，把這個資料寫到目標庫裡面去。透過生產者與消費者的這種方式，我們就能夠在源端和目標端分別進行各自的最佳化，透過這種方式我們能實現很高的效能和可靠性。
好，下面我們看一下DRC的幾個核心特性，就是剛才我們說的三高一低。
第一個是資料高可靠，我們可以支援全量校驗，資料抽取的時候可以做資料進行一一校驗，同時還具備一定的修復功能。第二個也可以對在增量同步的時候，增量實時的進行資料的一個比對。第三個也是特有的它提供一個資料軌跡的功能，針對一些重要業務的資料，它可以開啟這種資料軌跡，這個資料是從哪同步到哪來的，同步的情況怎麼樣？
第四個它還具有比較完善的這種資料衝突檢測的手段，如果說資料發生衝突之後，還可以我們去制定以什麼樣的這種策略來解決這種衝突。
第二個是說的是鏈路高可用。你整個DRC它實際上是一個叢集的模式，它任意一個節點的故障之後，都可以把上面的任務快速的切換到工作任務正常節點去，同時我們還支援斷點續傳，把整個任務切換之後能夠迅速的去自動去繼續有上次的這種任務，而不需要去重新執行。
第三個是高效能。在雲端和目的端都採用了種種方式來進行這種效能這種提升。比方說我們採用了SQL合併，而且這種並行技術複製效率比通常的這種方式會高很多，同時它還能夠根據我們的任務的不同特點，線上擴縮容，而且擴容期間是不影響整個資料傳輸的。
那麼第四個是一個低延遲，那麼整個DRC能夠做到一個很低的資料延遲， 延遲能夠小於50毫秒。在我們京東內部的一個實際環境下，比如說我們從北京到宿遷兩個機房，那麼TP99只有20毫秒這樣一個延遲。
我們下面看一下主要架構。
主要分為前面的控制檯，排程引擎以及雙活管道三個部分構成。前面的控制檯我們提供資料來源的配置，我們的agent這些管理，並且提供種種監控，我們的欄位對比等等，同時還可以去進行一些操作記錄，異常記錄等等。
好，第二部分就是我們的引擎，我們可以分為消費者與生產者，那麼消費者生產者是透過這種鏈路進行同步，另外我們的採集模組還會對任務的進度進行監控，去看看這種任務的執行情況怎麼樣，你的任務是什麼樣的，如果發生異常之後還會產生告警，通知我們的管理員進行處理。
下面是它的資料管道，資料管道它專門針對多活提供了特殊的配置，有專門的多活管道，還有這種處於日常的遷移同步的資料管道，以及給大資料用的ETL管道，它會針對每一種管道的特性做一定程度的最佳化，去滿足不同管道的場景的特徵。
那麼我們底層目前也支援很多這種資料庫，包括常見的My SQL，MongoDB、Clickhouse等等，包括Oracle都可以支援，包括還可以支援我們的快取，以及Kafka這種中介軟體都可以步，功能非常強大，是我們目前京東零售和京東科技做應用的異地多活的一個基石。
我們具體看一下DRC-MySQL為例，看一下具體怎麼去做的。
首先來說他會去做一個源端的資料抽取，由consumer做目標端的資料插入，那麼在抽取的時候它可以有多種方式，可以進行這種全量的抽取，全量加增量順序抽取，還有一種特有的全量加增量這種交替的方式，為什麼會有這種方式？因為在我們的源端的這種資料庫裡面，可能由於資料過多，bin-log比較大，所以bin-log我們會及時的透過一種交替的方式把bin-log及時的抽取過來，然後存到本地進行緩衝。
那麼當全量這種資料抽取完成之後，我們再把它的整個資料傳送給consumer，這樣就避免了我們歷史資料過大，抽取時間很長，導致bin-log被覆蓋的問題，同時在這種consumer端，我們也採用了這種多種方式進行這種效能的提升，比方說我們針對多個表，我們可以以表的維度進行這種併發的去進行寫入。這種方式就能夠極大的提升效率，但這種方式適用於表之間的業務關聯性不強，它可以滿足這種最終一致性。對於資料一致性要求比較高，我們還可以進行事務之間的並行。
那麼第二種可以去根據你的事務的執行特點，去找出可以去併發執行的事務。比如說我們下面看這個例子，12345這5個事務分別去執行，我們透過分析這個事務就發現，那麼1和23和45這兩個事物是可持續並行執行的，我們再去進行這種寫入的時候，這兩個事務就會並行寫入，透過種種的一系列並行策略，我們就能夠達到一個很高的吞吐量，同時一個很低的延遲去滿足我們在多雲多活或異地多活這樣一個對資料同步的高吞吐量低延遲這樣一個場景。
在很多場景裡面，其實就是在一些金融場景裡面對事務的一致性要求比較高，所以我們這邊還提供分散式事務。
它可以去支援這種XA、TCC和TAC這幾種模式，去滿足在微服務呼叫下，跨單元或者跨異地呼叫的一致性，同樣它也具有很高的可靠性，它也是一個分散式的這種叢集。
比如說事故發生故障之後，它可以去自動的就去回滾，並且去進行超時的檢測，同時它具有很高的觀測性，提供事務、各種管理後臺、監控指標以及日誌等等。
好，我們看一下第三個挑戰，流量是如何進行這種切分和排程的，以及在這種過程當中，我們有些什麼樣的保護措施等等。
流量的切分我們是透過我們稱之為一個流量閘道器這樣一個元件來實現的，那麼使用者的流量從最上面我們可以看到到達流量閘道器，那麼流量閘道器之後，流量閘道器會根據我們的配置或者策略，將流量根據指定的演算法分分到不同的單元裡面去，同時它的管理模組還可以去進行日誌的採集，監控、告警以及運維管理等等。
除此之外，我們流量閘道器還具有流量這種糾錯功能。如果它發現流量發錯了，它會自動的把流量根據我們策略轉發到正確的單元裡面去，同時流量閘道器我們還可以支援限速熔斷以及支援應用的各種釋出模式，比方說藍綠髮布、灰度、權重等等，它提供這種Prometheus這種監控指標，比如說單元維度，host維度的糾錯統計等等，這些資料治理的一些能力它都能夠提供。
這邊是它的一個功能全景圖
最右邊我們可以看到其他主要功能還是在這種流量的路由方面，比方說它在HTTP路由，就提供URL重寫、重定向等等功能，左邊是那些管理功能，包括還能提供一些我們日誌管理監控管理，能夠對業務進行一些分組，所以流量閘道器是我們進行整個流量劃分，流量這種糾錯，流量管理的一個核心的元件。
那麼第二個我們稱之為應用閘道器Phevos。
應用閘道器本質上是一個API閘道器，它負責把前端發過來的http的這種請求轉發成對應的API呼叫，然後發給後面的微服務，它分為三層，有前端的font，後端的 server負責各種處理，以及的規則中心進行各種規則的這種管理和排程。
我們講的是應用閘道器的一個功能全景圖.
我們可以看到在前端它可以負責這種節點的伸縮，API的分發、流量控制、負載控制等等,在後端的它主要就進行流量的控制，比方說能進行協議的轉換，引數的轉換，報文的對映，同樣它有熔斷、降級的這種功能。
第三個是它的控制檯，它既然是個API閘道器，那麼在控制檯上就提供整個API全生命週期的管理，比如說API的一些配置，API的部署授權等等，同樣它還提供運維管理功能，比方說叫許可權管理，配置管理的這種叢集管理等等，都會透過我們的後置臺進行很方便進行配置，這是我們的應用和應用閘道器。
好，第四個就是微服務的單元化支援，就是我們如果在多雲的環境下，並如何進行滿足我們的微服務的這樣一個呼叫。
微服務我們稱之為JMSF它當時採用了雙模技術，同時支援我們的微服務和網格，為使用者提供統一的一個微服務的能力，它是將服務的註冊與發現，服務的負載均衡，服務的治理、服務的路由、服務的鑑權等等統一的進行平臺化，提供給使用者一個統一的服務治理能力。
我們在微服務平臺支援這種常用的istio，spring cloud、dubbo這些常用的元件，並且還可以去對接 Nacos、SGM這些元件。
我們看一下微服務是怎麼支援多雲的。
首先在部署方面，我們可以採用一種多叢集的部署方式，那麼使用者的流量從我們DNS或者CDN分發到各個不同的機房裡面去，由LB和我們前面說的流量閘道器轉發到後端上面去。那麼雲的這種lb這種流量轉發的功能，它會把這種流量轉發到後面的這種應用閘道器以及這種微服務裡面去。那麼JMSF也同樣的具備這種流量控制能力，跨雲同步和跨雲訪問的能力。
其次我們的這種多雲服務，它具備多雲的註冊的能力，每一個這種雲服務中心都可以有一個獨立的這種註冊中心，同樣每個註冊中心它也可以去聚合多雲區的各個服務，並且把它相應的自動標識所屬的雲區域，那麼服務例項也可以去拉取我們雲上的這種呼叫，進行相關這種策略的配置及呼叫等等。
在多雲的服務呼叫方面，我們有三種不同的策略進行這種配置，比方說預設的就是說我們不分割槽域提供一個全域性的呼叫服務。第二個是說進行只是進行本地呼叫，只呼叫處於同一個雲地域或者機房裡的這種服務。第三個我們還可以配置首先是本地優先，那麼服務優先選擇本地域或者本地的服務，如果說本機房或本機房的機器沒有或者發生故障之後，再去其他地域去尋找，透過這種方式我們就能夠去滿足我們多雲的呼叫服務，在多雲和效能之間做一個很好的平衡。
我們看一下我們JMSF的主要特性。
第一個是說它可以相容我們的主流的開源的服務框架，包括Istio、Sprintcloud、Dubbo等等，都可以去支援
第二個它可以去支援已有的微服務進行這種遷移的方式。第一個，那麼你的新應用是透過Sidecar模式，實現無侵入遷移，那麼進行這種方式，無需做更多的工作。再一個是你的微服務，可以透過我們的服務同步機制參與到這種新架構裡面去。
第三個就是說我們還可以支援複雜的業務場景，我們可以支援支援網格與註冊中心相互同步、呼叫，支援同一服務下混合架構部署，支援Sidecar和SDK的虛機，容器混合場景，支援多叢集服務網格，支援星鏈容器網路模式，支援容器Host網路模式，支援多控制面網格服務。我們的這種微服務可以進入各種服務框架，支援這種已有的應用服務的簡便的接入，支援各種複雜應用場景。
好，我們下面看一下我們是如何把那些技術理念這種碎片化的東西是如何進行標準化，形成一個產品化的。我們介紹一下京東單元化的這樣一個實踐。
3.從技術理念構想到標準產品化，京東是如何做的？
這是京東單元化和應用多活的一個簡版，實際比較複雜。
我們京東大概是會有大概三個這樣一個資料中心，分別是北京中心，北京我們稱之為中心單元另外還有兩個是宿遷和廣州，我們稱之為普通單元。
那麼中心單元是有全量的資料，所有資料都在北京中心單元，而普通單元分別是有部分的一些買家，我們說使用者的一些資料，使用者資料會從這種普通單元往中心單元裡面去同步，而商家資料只是從中心單元往普通單元裡面去同步，這樣的話我們每個單元裡面都有了這種相應的商家和使用者的資料，所以說能夠做到一個請求，能夠在每個單元裡面進行閉環的呼叫，避免跨單元呼叫，變成效能的延遲。
當然有一些特定的資料，比方說我們的庫存等等。庫存這個意思是說全域性的統一的管控，那麼對於一些這種庫存，那麼所有的這種資料我們還是要路由到中心單元去進行統一管控的，那麼對於中心單元來說它是一個核心，所以中心單元我們做雙機房的一個熱備，透過這種方式我們實現了這種應用的跨地域的多活，無論是宿遷單元還是廣東單元發生故障之後，它的流量能夠在分鐘之內往中心單元或者說往其他單元去切換，中心單元有額外的核心的機房的熱備。
好，我們再看一下我們的多雲多活系統。
多雲應用多活系統，它是以使用者的應用為中心，以混合雲的雲艦為底座的一個產品，它能夠幫助使用者在同城或者異地建立一套與本地的這種生產系統完全相對應的一個多活系統，分佈在多個雲端的多個機房，能同時對外提供服務。
當故障發生的時候，那麼多活系統可以在幾分鐘之內實現業務流量的切換，最大程度的降低故障的影響，那麼使用者在幾分鐘時間之內，甚至可能感受不到業務發生故障了，那麼這個系統有什麼樣特點？這個一是我們實現了這種跨雲的多活模組，不僅僅是分佈在我們一朵雲裡面，而且可以劃分在不同的雲平臺裡面，那麼業務流量我們可以按需的進行泳道式的路由。
第二個我們可以實現這種跨雲的釋出，可以透過我們統一的管控平臺進行這種多雲之間的統一的釋出和部署。
三這種請求，我們透過一定的合適的配置，我們能夠實現各個元件和服務，能夠在一個單元之內請求閉環，減少跨機房當中單元排程，從而避免效能的損失。
第四個是資料一致性，透過DRC實現資料的毫秒級同步，有完備的資料路由、異常檢測機制，在資料路由的每個層次，我們都具有這種防寫措施，防止我們資料的異常
這是我們透過了一個信通院的最高機制的認證，叫做“先進級”，也是說國內第一個能提供這種多雲多活力的一個廠商。
其他廠商可能透過這種資質，它只是在自己的單一的公有云上透過這種資質，而我們是能夠在多雲這個環境裡面下提供這種多活能力，那麼這個是目前國內是唯一的一個。
我們看一下我們整個多活的一個架構，我們整個多活目前是支援單元多活，我們稱之為異地多活和同城多活兩種方式，這種方式下你的RTO就是你的系統切換時間能小於兩分鐘，那麼RPO根據我們的網路情況和部署的架構不同，最高能夠做到0，整個架構就是最左邊的，我們稱之為一個多活的管控層，最上面是雲艦這樣一個平臺構成的，那麼雲上我們有了這種流量閘道器進行流量的分發配置，還有應用閘道器把流量轉化成這種API，然後是後面的微服務，下面還有資料庫和中介軟體等等，那麼整個平臺它具有這種流量保護的功能，那麼就是說每一次的服務請求之後，它都會根據最新的路由規則進行計算，如果是這種非法流量就拒絕處理。
其次它這種流量糾錯的功能，在流量閘道器應用閘道器及微服務過程都可以進行流量衝突檢測。如果發現流量打到錯誤單元，那麼它重新會將流量路由到正確單元裡面去。第二個時候它可以有本地優先的這種呼叫策略，優先呼叫本單元的服務，從而減少這跨單元呼叫給我們帶來的新效能損失。
同時它也進行鏈路透傳，把一些關鍵的路由資訊透傳下去，這個主要是給我們後面SGM監控提供支援的。
剛才我們說了我們整個應用多活，實際上是基於京東云云艦這樣一個混合多雲作業系統之上的。
我們為什麼要基於混合多雲作業系統？因為雲艦它有幾個特點，第一個是說它向下會融合一個多雲的環境，它能夠遮蔽下面多種雲的差異，向上提供一個統一的介面，那麼實現多雲一體應用一致的執行，就極大的去降低了我們應用多雲多活需要分別適配每朵雲這樣一種特性，那麼這種適配工作交給雲艦去做了。
第二，雲艦能夠向上去提供業務的所需的能力，它提供這種常見的 PaaS元件，包括資料庫、中介軟體、微服務，同時還包括各種鏈路追蹤監控，運維管理等等各種措施，幫助應用多活把整個元件串成一塊，提供一個整體的生態能力。
雲艦的使用者使用跨雲多活像使用一朵雲一樣，使用者不需要去面對各種不同的雲，它有相同的這種介面，同樣的操作同樣介面去管理，那麼雲艦目前已經在我們京東內部已經是使用了多年的，包括我們在雙11、618、春晚裡面，都是透過這種雲艦進行跨雲的這種跨機房這種多活以及這種管控的。
我們看一下我們這個稱之為單元多活動異地多活單元的一個架構。
使用者的流量從最上面來到我們GDNS裡面去，我們GDNS會隨機的根據它的策略，把流量分流到不同的單元裡面去，那麼流量再到我們的流量閘道器之後，流量閘道器會根據我們的配置或者路由規則進行計算，如果說它發現當前打過來的流量不屬於本單元，那麼它會把流量會轉發到對應的單元裡面去，進行一個單元的糾錯，把正確流量然後向後轉發給應用閘道器Phevos，Phevos同樣它也會去進行一個單元的這種流量的這樣一個判斷。
如果他同樣也發現有些逃逸流量不屬於本單元，那麼同樣他也會進行一個流量糾錯，把這種流量轉發到對應單元裡面去。
那麼流量閘道器現在是一個HTTP層的糾錯，那麼應用閘道器是RPC這樣的糾錯，當流量到達到後面的這種微服務之後，那麼微服務各個單元微服務的註冊中心會形成一個雙向的同步，保證我們每個微服務的配置都是一致的，那麼使用者的應用在微服務裡面去訪問本單元內部的，包括像資料庫快取訊息佇列這樣的服務，做到整個鏈路在本單元這型別閉環，我們把這種資料層包括這種資料庫快取或訊息，透過我們DRC進行一個雙向同步。好，這是這個異地單元的一個多活架構。
那麼下面管控層它會部署在一個三機房高可用的管控層裡面，底下是我們的一個雲艦。
這個是一個同城多活的架構。
總體架構跟單元都非常類似，它的差別就是說首先我們的流量它不是根據規則，是一個比例按比例進行劃分的，因此不需要一個糾錯功能。
其次它的這種主備單元裡的這種業務是寫主單元裡面的資料庫、訊息和快取，這個資料再同步到我們的備單元裡面去，備單元裡面的資料通常情況下不對外提供服務，或者說只提供只讀的服務，這是同城多活和異地多活的一個最重要的區別。
我的這種被佔面積的這種服務是寫主站裡面的資料。（這句話不明白，如有的話，刪除掉吧）
好，為了滿足我們這種同城、異地多活這種場景，同時為了滿足各種雲裡面千差萬別的設施，我們把整個應用多活抽象和提煉出一套單元化的模型，來支援業務的靈活的配置。
比如說我們有多活空間，分為這種同城多活和單元化異地多活兩種空間，每個空間我們還有單元的這種模型，有路由變數的模型，有單元規則的模型，有域名的模型，每個模型裡面還有具體的一些屬性，透過這一整套的模型的完整定義，就能透過應用多活去適配使用者的各種複雜場景，以及多雲環境下的一個差異。
好，我們定義了模型之後，然後我們的這種管控端會根據我們的模型去實時監控我們的模型配置，如果說發現我們的配置發生了變化，那麼這個時候它會把我們當前的最新的配置或者模型推送到我們的各個元件裡面去，傳送給流量閘道器、應用閘道器、微服務，或資料的這種訪問代理裡面去，元件根據最新的流量規則進行應用或者禁流等等。
整個元件為了去滿足使用者的各種環境裡的複雜的場景的，我們提供可插拔能力，定製的一些標準的介面。那麼在各個不同的這種環境下，我們只要按這種標準的介面去對接相應的元件就可以了。
那麼當如果我們某個單元發生故障或者說我們需要做流量調整的時候，我們提供單元流量快速這種切換能力。
它可以在我們的這種工作臺上透過web介面進行控制，也可以調動API進行控制。那麼在切換任務的時候會自動生成一個工單，只要透過流程審批之後，把工單自動的轉成切換任務，進行這種切換。
那麼切換任務我們主要分成這4個階段。
第一個就是準備階段，第二個是禁流階段，第三個是同步階段，第四個是切換階段。那麼準備階段我們會去做一些校驗的措施，包括這種元件是否可用，它的健康度怎麼樣，包括這種使用者的流量是否發生了這種遷移或者變化，進行前置性的這種判斷和處理。
第二個是禁流，如果說使用者的流量在這種切換過程當中，使用者的流量發生了變化，那麼它會有這種禁流規則，防止在切換過程當中，由於資料打到不同單元，把資料寫亂這種情況，禁流不僅是上層的流量閘道器禁流，在流量閘道器、應用閘道器、微服務等等各個層面，它都會進行一個禁流處理。
那麼第三個是一個同步階段，那麼他會去檢測每個單元的資料的一個同步情況，如果說發現資料有積壓，會根據我們的配置進行切換，或者說等待的這種資料同步完成之後再進行切換，這個是可以根據我們的業務場景進行配置的。
然後第四個就是切換階段，它會根據我們的新的規則釋出出去，去調整使用者的流量，最後完成一個切換的過程。
好，剛才說的大致階段，這就是一個多活釋出的一個詳細流程了。比如我們看最開始的前置，他會去進行一一的校驗，然後對元件進行一個禁流，這樣每個操作都是可以對它超時時間、等待時間、並行度等等都是可以去配置的。同時我們也提供這種預設的策略，預設策略可以去適合絕大多數的切換場景，那麼對於一些特殊場景，我們可以進行各種各樣的調整和配置。
如果說我們流量要發生變化怎麼樣？比方說我今天發現其中一朵雲就發生降價了，有優惠了，我想把它流量更多的去切換到這個雲上，這時候我們怎麼做？這是我們現在的這種變更方案。
分流流量這種變化很簡單，我們只需要在我們管控層面設定一個新的這種單元規則，比如說我們可以指定，打個比方說把單元4的流量調整成50%，那麼其他的單個單元並分50%，這種單元規則配置完成之後，釋出一個新的規則就可以了。
如果說我們擴容，要去擴充一個新的單元，或者一個類似於說新的機房的這個時候，我們首先要做到準備好一個新單元，在新單元裡面部署好應用，然後把這個資料從其他單元裡面同步到我們新單元裡面去，等資料同步完成之後，我們再配置一個新的單元規則，在那單元新的單元規則釋出出去，就完成了一個新的單元的接入了。
那麼下線單元就比較簡單的，我們只需要把要下線單元的流量切成0，然後再釋出一個新的規則，就可以把這個單元比較容易的進行下線。那麼無論是這種分流策略的變化，還是做這種新增單元的策略的釋出，你都是可以在分鐘級甚至秒級直接實現。
整個這種操作無論是這種釋出還是說這種切換，其實對使用者來說其實都是比較很複雜的一個操作，所以我們專門提供視覺化介面，幫助使用者去管理。
那麼我們可以定義我們的各個空間以及單元，是可以去定義各種單元流量的劃分方式，劃分比例，可以去在微服務裡面去定義我們單元化的路由策略，轉發策略等等，可以去在資料同步裡面配置保護策略。
第二是DRC裡面去配置我們的資料同步的策略、鏈路以及檢視我們資料同步的狀態。這是一個怎麼去釋出配置，我們是透過一個這種yaml檔案進行釋出的，這是切換。
然後這是一個例子，我們可以看到最開始兩個單元都是同時有流量的，然後某一個點由於某種故障，我們就把黃色的流量把它切走了，切到這種藍色流量裡面去，我們看到在某個時間點裡面黃色流量變為0的。
那麼過一段時間我們把故障處理完成之後，去把流量切回來，你就看到流量就重新的恢復到原先的這種正常情況。就透過這種監控我們可以很容易的去觀察我們整個流量的一個變化措施。
好，下面我們來看一下全鏈路監控。
全鏈路監控我們稱之為SGM，它支援從移動端、前端、服務端一個整體的全鏈路監控，並且能夠把三種鏈路的監控做一個串聯的分析，幫助使用者定位問題，讓使用者整個鏈路上的各種執行情況的一目瞭然、非常清楚。
那麼除了它能提供這種整個鏈路的一個監控之外，它還可以去讓使用者從一個開發者的角度，透過一些配置完成一些業務層面的監控。
比方說你不需要透過去做一些埋點，就能完成類似於比如說像渠道轉換這樣一個監控，類似一種BPM監控的功能。整個前端的監控，它對使用者的監控是一個無程式碼無侵入的，使用者不需要修改程式碼，只需要進行一些配置，就能夠進行這種整個鏈路的監控了。SGM的監控也是在我們京東內部大規模使用。
SGM監控在應用多活方面，我們可以提供進行監控的流量的指標，比如說TPS耗時，介面成功率等等，同時它還可以進行一些呼叫鏈的分析，分析每一筆這種呼叫的耗時狀態等等，還可以進行一些這種呼叫鏈的拓撲圖的劃分，提供不同時期的這樣圖表的對比能力，幫助我們去發現某一個點的一些異常的原因，並且還可以自從這種告警日誌和告警的能力。
4.多雲多活的產業實踐
下面講一下我們多雲多活的產業案例的一個分享。
第一個是達達集團的一個分享。
好，我們第一個案例是達集團的一個跨雲多活的一個案例，達達以前是把業務分佈在某個公有云和他自己的IDC機房裡面的，達達跟到家合併之後，它需要跟到家的業務做一個上下端打通。同時以前由於達達使用這種單雲的時候，大概是在2017年到2018年的時候，網路發生過好幾次故障，給到他的業務造成一些困惑，所以達達到後來決定採用這種跨雲多活的這種方式。
首先達達把他原先在機房裡面自建的一些PaaS遷到我們京東雲上，改用京東雲的PaaS元件，同時完成一些雲原生的改造。
第二個它把微服務的註冊中心遷移到雲上，去實現了一個跨雲的多雲的部署，它的業務可以去在多雲裡面去就近的部署和排程。
第三步是進一步去實現資料的一個雙向的同步，進行業務的拆分，完成它的單元化的改造。
最後，它完成了流量的排程策略和分發特性的升級，完成流量排程方案的最佳化和各種措施。
那麼在他完成這種跨雲雙活的改造，到當年它的雙11就成功的支撐了每日1,000萬訂單這樣一個處理。
同時在這個過程當中達達的業務和到家以及這物流進行了一個無縫的整合和打通，整個鏈路都非常順暢，同時在到從它原先的這種架構到跨雲多活架構的這種整個過程當中，它還實現了傳統的架構到雲原生架構的一個升級，實現了技術的升級換代。
同時在雲上它還能夠更好的去執行資源層面的一個彈性伸縮的管理。達達在2020年的時候就實現了，除了大資料之外就實現成本節約這種上千萬元。
達達集團的部門負責人也說，透過這種跨雲雙活的能力，他把這種算力和資源都遷移到了雲上，在整個計算資源層的彈性方面，成本壓縮以及業務穩定性方面都得到了提升。同時在過程當中也實現了技術架構的梳理與升級，並且實現全鏈路業務的打通，取得非常好的收益。這是達達的一個案例。
下面我們再看一下這種愛回收的一個多雲建設。
愛回收它原來是在一朵單雲上，那麼後來他由於種種原因，他決定需要去建立一個跨雲多活的這種方式。
那麼愛回收的這種跨雲多活，它分為幾個批次來進行的，第一首先說它把應用進行了一個分類，它把應用分為普通的這種應用，以及需要高頻次去調動的基礎應用，把應用梳理完進行分類之後，再根據各個應用的這種呼叫關係和依賴關係進行一個批次的劃分，按批次進行遷移。
那麼在每個批次進行遷移的時候，它首先進行這種資料庫的改造，把資料庫完成一個跨雲的部署，然後兩邊的資料做一個單向的同步。那麼完成了資料庫的部署之後，還得把它的應用做一個雙雲的跨雲的部署。首先讓資料寫原先的主叢集，那麼然後備叢集就是隻讀。那麼完成了這種基礎應用的雙活之後，還再進一步的做應用的跨雲的多活。透過這種分批制的跨雲和遷移的這種實現方式，愛回收很好的完成了這種同城多活場景下的一個雙活的場景。
那麼透過這種同城雙活，它很好的實現了它的業務的一個彈性，同時它整體成本跟原先相比整體下降了20%。
同時在這種過程當中，他也完成了這種對於整個它的業務的一個梳理，實現了業務的架構解耦。它原來的一些可能就要去迴圈調動的一些這種方式改成了單次呼叫，整個業務更加輕便和靈活。
透過應用多活進行同城雙活的案例。我們可以看到無論是達達還是愛回收，透過實施多雲多活，取得業務連續性的提升和一個成本的整體下降。多雲多活，之所以被稱為技術皇冠上的明珠，除了是說它具有巨大的價值，能夠極大的去提高使用者的業務連續性之外，還因為它具有巨大的實現難度。我們京東根據多年內部實踐和打磨的這種技術，把它整理抽象出來，進行了一個產品化，像我們應用多活產品能夠幫助使用者在較短的時間之內去搭建一個跨多雲多活的系統，幫助使用者在業績連續性方面得到有效的提升，謝謝大家。