京東到家是達達集團旗下中國最大的本地即時零售平臺之一，目標就是實現一個小時配送到家的業務。一直到 2019 年京東到家覆蓋 700 個縣區市，合作門店近 10 萬家，服務數千萬消費者。隨著訂單量的增長、業務復雜度的提升，訂單系統也在不斷演變進化，從早期一個訂單業務模塊到現在分布式可擴展的高并發、高性能、高可用訂單系統。整個發展過程中，訂單系統經歷了幾個明顯的階段，通過不同的技術優化方案解決業務上遇到的問題。

下面我將為大家逐一介紹我們遇到了哪些問題及如何解決，主要分為以下三部分：

• 京東到家系統架構

• 訂單系統架構演進

• 訂單系統穩定性保障實踐

1

?

? ?

京東到家系統架構

1.1

?

? ?

業務架構

首先來看以下這張流程圖，這個系統架構主要由幾個部分構成：用戶端分別是 C 端用戶和 B 端用戶。B 端用戶針對的是像沃爾瑪、永輝超市等的一些商家，商家生產需要用到我們的一些揀貨 APP 和揀貨助手，后面商家履約完成會用到配送端，配送端就是給騎手接單搶單，最后是結算部分，分別給騎手和商家結算。

?C 端針對的是用戶，用戶進來瀏覽、下單到支付，整個過程是用戶的操作行為。基于用戶的操作行為，我們有幾大模塊來支撐，首先是京東到家 APP 的后端業務支撐的基礎服務，另外就是營銷系統、業務系統等等。基于上面這些，我們需要有很多系統來支撐，比如運營支撐系統、管理后臺的支撐系統、對商家的履約支撐系統。這些業務系統的底層大概有三塊的持久化，分別是緩存（LocalCache、Redis 等）、DB（MySQL、MongoDB 等數據庫）、ES。這就是京東到家簡版的業務架構圖。

1.2

?

? ?

運營支撐業務架構

京東到家的運營支撐業務架構主要分為商家管理、CMS 管理、營銷管理、財務管理、運營數據這五大模塊，每塊包含的內容具體如下圖所示：

1.3

?

? ?

后端架構

接下來是我們 C 端 APP 的一些網關后端的接口及基礎服務的支撐。首先所有的請求都會經過網關協議，網關下面分為業務系統，包括首頁、門店頁、購物車、結算頁以及提單系統、支付系統和個人訂單系統，這些系統的支撐都離不開我們的基礎服務的支撐，比如庫存、商品、門店、價格等等，這些是一些重要的基礎服務支撐，來保證用戶可以流暢的下單以及到結算。

業務支撐包含了很多業務系統，比如用戶、定位、地址庫、運費、promise、推薦、搜索、收銀臺、風控等。

上面說到了營銷的一些管理系統，其實營銷還有一些后端的基礎服務系統，比如優惠券、滿減、秒殺、首單等。

1.4

?

? ?

訂單數據入庫流程

用戶提單以后數據怎么流轉？提單其實是一個把用戶下單數據存儲到數據庫，提單系統做了一些分庫分表。那么提完單的數據怎么下發到訂單系統生產？首先我們會有一個管道，提單通過一個分布式異步任務來下發訂單管道里。所有的訂單下來都會放到管道里，我們通過一個異步的任務，按照一定的速率，均勻地把訂單下發到訂單生產系統。這樣設計有一個好處，比如像大促時可能會有大量數據一下子下發到訂單生產系統，對訂單生產庫有很大壓力，所以我們中間設計出一個管道，通過異步任務來分發生產訂單。

看了圖可能有人會問為什么要有一個個人訂單 DB？其實個人訂單 DB 跟訂單系統是不同維度的數據，因為個人訂單其實是基于用戶去做了一個分庫分表，它每一個查詢的訂單都是基于這種個人，跟訂單生產是不一樣的，所以每個維度的數據都是單獨的存儲，來提高系統的穩定性，以及適合它自身業務特性的設計。

那么訂單系統跟個人中心是怎么交互的？首先異步，我們是通過 MQ 來交互這些訂單狀態的變更。另外 C 端的訂單取消，是怎么同步到訂單生產系統的？我們是通過 RPC 的調用來保證訂單實時取消，有一個返回結果。

2

?

? ?

訂單系統架構演進

2.1

?

? ?

訂單系統業務流程

我們的訂單履約分為兩大塊，商家生產和配送履約，具體步驟如下圖所示：

整個訂單履約的流程是怎么樣的？在用戶支付完成后，訂單會有一個補全的過程，補全完后，我們會根據一些門店的設置，把訂單下發到商家。下發商家后，有幾種對接模式：有開發能力的商家可以通過開放平臺，一些小商家可以通過商家中心以及我們的京明管家來完成訂單的生產履約。在商家拿到新訂單后，通過打印出小票進行揀貨。揀貨會分為幾個業務場景，因為有可能商家有貨也有可能沒貨，如果缺貨的話，我們有一個調整的功能，讓商家通過訂單調整來保證有商品的訂單可以繼續履約。

在商家完成揀貨時，我們訂單會分為分區揀貨、合單揀貨、前置倉揀貨這幾塊業務上的操作，其實在系統里我們有一個揀貨的池子，會通過不同維度的數據來完成高效的揀貨。揀貨完成后，我們的配送主要分為兩個模塊，一種是單個訂單的配送，另一種是集合單的配送。集合單就是把發單地址和配送地址在兩個相近的格子里的訂單合并起來，基本上都是基于將同一個門店的配送目的是同一個相近格子里的訂單，進行合單后讓一個騎士完成配送。配送會下發到一些配送系統，分為兩種模式，集合單和單個訂單的配送，以及和配送系統的整個運單交互的一個流程。

2.2

?

? ?

RPC 微服務化集群

說完業務后，接下來介紹一下我們應用的一些微服務的拆分過程。先講一下微服務理論方面的知識，比如為什么要拆分微服務？微服務拆分后可以解決哪些問題？這是接下來一個重點內容，大家可以思考一下，系統架構必須具備哪些條件才能達到高可用？

簡單總結來說，微服務可以降低系統的復雜度，可以獨立部署，并且有很好的擴展性：

• 降低復雜度：把原來耦合在一起的業務，按領域拆分為不同的微服務，拆分原有的復雜邏輯，每個微服務專注于單一業務邏輯。明確定義領域職責與邊界；

• 獨立部署：由于微服務具備獨立部署運行能力，當業務發生變更升級時，微服務可以單獨開發、測試、部署升級。提高了迭代效率，降低了研發風險；

• 擴展性：拆分后的微服務架構獨立部署，可以根據流量預估或壓測評估獨立進行擴容升級。

我們訂單系統的架構演進如上圖所示，最左邊是最初的一個模型，所有的業務都耦合在一個應用里面，這個應用可能就有一個 service 來支撐，數據庫也是一個單點的數據庫。隨著這些年的迭代升級變更，逐步演進到一個應用有多個服務支撐，數據庫也在不斷升級變更，以及到后面把應用按微服務拆分成多個模塊，拆成多個領域的支撐，按不同的系統邊界去拆分。并且拆完后，隨著業務量越來越大，其實我們也在做一些升級，比如 Redis 的接入。

Redis 的接入解決了什么問題？數據庫為什么要分庫？ES 為什么在接下來一些系統架構升級里會被引入進來？為什么 DB 要拆成多個集群？這背后的一些根本問題，以及解決業務系統的一些背景，接下來我們逐一探討。

在最初搭建項目時，其實我們是要保證業務的快速試錯。這個模型會有什么問題？就是系統會有一些單點風險，以及系統發布是一個短暫停，所有請求都是一個主觀的操作，并發能力很差，稍微有一些業務量時，系統接口就會超時比較嚴重。這是最初 2015-2016 年的情況。

接下來 2016-2017 年，隨著業務的快速迭代，系統復雜度也慢慢高了起來，系統邏輯耦合會比較嚴重，改動一塊的邏輯影響就會比較大，導致線上問題頻發，因為所有的邏輯都耦合在一起，一次發布可能就會影響范圍比較大。

按微服務拆分成多個系統，如果發布有問題也只會影響其中的一些很小的部分。在后面隨著業務量越來越大，RPC 這種框架的引入，解決故障的自動下線，保證高可用，比如單臺服務器有問題時，能做到自動下線來保證不影響業務。

2.3

?

? ?

訂單系統架構升級 - Redis 集群

2017-2018 年，我們根據 2016 年遇到的問題做了一些拆分，比如按領域拆分不同的 APP 應用。這樣拆分做到的就是系統沒有單點，負載均衡可以橫向擴展，多點部署。包括引入 Redis，其實我們用到了 Redis 的分布式鎖、緩存、有序隊列、定時任務。

我們數據庫為什么升級？因為數據庫的數據量越來越大，比如添加一些字段，它其實會做一些鎖表操作，隨著數據量越大，單表的數據越來越多，數據主從延遲以及一些鎖表的時間會越來越長，所以在加字段的時候對生產影響特別大，我們就會對數據做一個分離，把一些冷的數據單獨做一個歷史庫，剩下的生產庫只留最近幾天的一些生產需要的數據，這樣生產庫的訂單數據量就會很小，每次修改表的時間是可控的，所以我們會把數據按照冷備進行拆分。

至于為什么引入 ES，是因為訂單在生產方面會有一些很復雜的查詢，復雜查詢對數據庫的性能影響非常大，引入 ES 就可以很好地解決這個問題。

2018-2019 年，我們發現之前在引入數據庫時，用數據冗余來保證一些數據應用可互備互降。比如我們之前在用 ES 低版本 1.7 的時候，其實就是一個單點，當集群有問題時是會影響生產的。我們后來引入了一個雙集群，雙 ES 集群互備，當一個集群有問題時，另一個集群可以直接頂上來，確保了應用的高可用和生產沒有問題。

另外，引入 Redis 雙集群，Redis 其實有一些大 key 的問題，當一些核心業務和非核心業務都用到 Redis 的時候，我們會把一些核心業務拆到一個集群，非核心業務拆到另一個集群，來保證 Redis 集群的穩定性，能穩定支撐訂單生產。

注：大 key（線上看到過 list 的 elements 超過百萬的）刪除時會阻塞比較長的時間，大 key 的危害：

OPS 低也會導致流量大，比如一次取走 100K 的數據，當 OPS 為 1000 時，就會產生 100M/s 的流量；

如果為 list,hash 等數據結構，大量的 elements 需要多次遍歷，多次系統調用拷貝數據消耗時間；

主動刪除、被動過期刪除、數據遷移等，由于處理這一個 key 時間長，而發生阻塞。

單個應用怎么保證高可用？其實我們這邊從最初的一個單機房單實例單 IP，一步步演進為單機房的單服務、單機房的多服務，最終是多機房的多服務，比如某個機房某些 IP 有問題，我們能確保應用可以正常請求響應，來保證系統的高可用。

2.4

?

? ?

訂單系統數據架構 - MySQL

下面來介紹一下我們主從架構的演進。最初我們就是一些主從的架構，并且主讀和寫都會請求到一個主庫，這樣就會給主庫帶來非常大的壓力。而像訂單生產這種天然性就是讀多寫少，主庫的壓力會比較大。所以基于這個問題，我們就做了數據庫架構的升級。

我們做了讀寫分離，就能很好地解決了這個問題。比如很多查詢，我們就會直接查詢到從庫的，主庫只是用來承載一些寫的流量，這樣主庫就減少了很多壓力。但這樣就會遇到上面說到的問題，因為我們是一個生產表和歷史表的結構，在每次加字段時，數據量很多的話，鎖表時間就會很長，導致在這種讀寫分離的架構下數據延遲就會比較大。

基于這種場景，我們又做了一些升級和改造。我們把數據拆出來了，拆成歷史庫，當所有的生產數據都很小的時候，對于提高性能是非常有幫助的。我們把生產完的一些數據全部都歸檔到歷史中，減輕主庫的整個壓力，以及在添加表字段修改的時候，其實就沒有太大影響了，基本上都很穩定。

數據的演進最終結構如上圖，當這是基于目前業務的一個支撐，在未來業務不斷發展的情況下，這個數據庫架構是原因不夠的。基于以上架構，我們主要是做到了一主多從的主備實時切換，同時確保主從在不同機房來保證數據庫的容災能力。同時通過業務隔離查詢不同的從庫給主庫減輕壓力，以及冷備數據的隔離的一個思路來保證訂單數據庫的穩定性。

2.5

?

? ?

訂單系統架構升級 - ES 集群

最開始我們是單 ES 集群，DB 會通過一個同步寫寫到 ES 集群。這個時候我們的 ES 是一個單機群，如果寫失敗的話，我們會起一個異步任務來保證數據的最終一致性，是這樣的一個架構。在 ES 集群沒問題的情況下，這個架構也是沒問題的，但當集群有問題時，其實就沒有可降級的了。

為了解決這個問題，我們引入了 ES 的冷備兩個集群，熱集群只保存跟數據庫一樣的生產庫的數據，比如說我們現在保證的就是 5 天的生產數據，其它所有數據都歸檔在一個 ES 的冷集群里。通過這種異步跟同步寫，通過異步任務來保證最終的集群的數據一致性。這就是 ES 的架構升級。

其實 ES 這樣寫的話會帶來一些很大的侵入，每次我們數據庫的一個變更都會帶來一些要 RPC 調用去同步 ES 的數據。這種瓶頸以及侵入式的問題怎么解決？我們接入了開源的 Canal，通過監聽數據庫變更了 binlog，來通過 Canal、kafka，然后異步通過消息來同步到 ES 集群。這個集群目前已經應用到線上的一些業務，經過灰度發布、后期驗證沒有問題后，會逐步接入生產系統。

如上圖所示，是我們整個訂單系統的結構。整個過程我們是通過業務網關、RPC 高可用、業務聚合、DB 冗余、多機房部署，來保證整個訂單應用的一些系統架構高可用。上述就是整體的訂單架構演進過程。

3

?

? ?

訂單系統穩定性保障實踐

大家思考一下，如果你要負責一些核心系統，你怎么保證穩定性？接下來我會從訂單系統可用性建設、系統容災能力、系統容量能力、系統預警能力分享一下我們在穩定性保障上的實踐。

3.1

?

? ?

訂單系統可用性建設

業務的快速發展對可用性保證要求越來越高，在方法論層面，我們按照系統故障的時間順序提出了事前、事中、事后三個階段，同時提出了四方面的能力建設——預防能力、診斷能力、解決能力、規避能力。

具體在工作上，我們會劃分為流程和系統建設兩個方面。其實最開始我們是為了完成工作，保證的是結果，最后發現每一個過程我們會把它平臺化，來提升人效。以上是一個大概的框架，下面我們一項一項詳細分析一下。

3.2

?

? ?

系統容災能力

容災能力這塊，我們從 ES 冷熱集群互備、Redis 緩存集群業務隔離，到業務接口的可降級和可異步，再到多維度的灰度發布。

就像上面提到的，我們對開放平臺、商家中心、京明管家等業務系統的支撐怎么做到互備？其實就是通過 ES 的冷熱集群，冷集群存全量的數據，熱集群存最近幾天的生產數據。而 Redis 是做業務隔離，Redis 存儲有一些大 key 會影響核心業務，我們就會把非核心的業務拆出來，拆到另外一個 Redis 集群。這就是我們系統的業務隔離和集群的互備。

業務接口可降級，其實是在一些復雜的業務操作接口里，我們可以通過一些異步處理，比如在訂單狀態變更的操作接口、除了更新 DB 和 ES、發送 MQ，訂單狀態的變更通過消息去同步發送。那么我們哪些可降低？比如說我們在業務核心操作接口里有一些 push 消息和發送短信，像這樣的非核心操作就可以用異步可降級的方案來解決。

灰度發布其實很重要，線上如果有一些新業務或系統的架構升級、技術的迭代，我們這邊都會通過灰度發布，比如可以通過一些門店先做門店匯總，如果單個門店沒問題，再通過一些商家，如果商家沒問題，就會灰度到整個城市，如果城市也沒問題，我們就會通過全量。

另一個維度來看，我們也會先灰度單臺機器，再到單機房、多機房。當然這個很局限，因為跟你灰度的一些功能有關系，大家要酌情根據自己的業務借鑒這種方案思路。

3.3

?

? ?

系統容量能力

至于系統容量的能力，主要分為評估和擴容兩個方面。容量評估可以借助一些輔助的工具，然后進行場景的壓測和全鏈路的壓測；而擴容方面，可以分階段依次實施冗余備份（主從分離）、垂直拆分（拆分核心屬性與非核心屬性）、自動歸檔。

3.4

?

? ?

系統預警能力

最后是預警能力，我們這邊用的是京東自研的 UMP 監控。

在接口層面，我們可以監控到：

• 可用率；

• 響應時間；

• 調用量：當別人調用你的接口，你設置調用的一個量值，當超過閥值時就是進來了一些非正常的流量，當監控到這些異常流量，就可以做限流等相應操作；

• 自定義：自定義一些報警；

• 關鍵詞：當系統出現某種問題，需要關鍵字報出來然后進行人工介入；

• 調用鏈：一個接口操作下來，誰調用了你？你調用了誰？哪個環節有問題？

在應用層面，我們可以監控到：

• Young GC；

• Full GC；

• 堆內存；

• 非堆內存；

• CPU 使用率；

• 線程數。

下面是關于 DB、ES、Redis 的集群監控，包括：

• CPU 使用率；

• 系統負載；

• 內存；

• 線程數；

• 讀寫 IO；

• 磁盤使用率；

• TCP 連接數。

?

如果大家有排查過線上的問題，就應該能感受到比如像 IO 高、TCP 連接、重傳等，都會影響到線上一些核心接口的響應時間，包括你 CPU 高的時候，線程數是否飆高？系統負載是否飆高？當這些指標都發生異常變化時，對于接口的響應時間都會有很大影響。

另外，我們還要做一些積壓監控，比如一些異步任務正常來說一分鐘最多積壓 1000，就需要添加對應的監控，否則數據異常了都不知道；再比如訂單支付的狀態，當積壓到一定數量，可能是系統出了問題，就需要人工介入。

4

?

? ?

總結

一個企業的架構師團隊，需要長期關注技術驅動業務、明確領域職責與邊界等關鍵問題，同時架構的演進過程也是不斷考慮 ROI 的權衡取舍過程。技術的持續發展，有助于不斷提升用戶體驗、業務規模，降低運營成本，而架構在其中需要解決的問題就是化繁為簡，將復雜問題拆解為簡單的問題逐個攻破。隨著企業規模的持續增長、業務的持續創新，會給系統架構提出越來越高的要求，所以系統架構設計將是我們長期研究的課題。在這條架構演進之路上，希望能與大家共勉共進。

?

>>>>

Q&A

?

Q1：集群規模大概是什么樣的？各集群節點規模如何？

?

A：京東到家訂單中心ES 集群目前大約有將近30億文檔數，數據大小約1.3TB，集群結構是8個主分片，每個主分片有兩個副本，共24個分片。每個機器上分布1-2個分片，如果企業不差錢最好的狀態就是每個分片獨占一臺機器。這些集群規模和架構設計不應該是固定的，每一個業務系統應該根據自身實際業務去規劃設計。

?

這樣做確定分片數：

?

• ES是靜態分片，一旦分片數在創建索引時確定那么后繼不能修改；

• 數據量在億級別，8或者16分片夠用，分片數最好是2的n次方；

• 如果后繼數據量的增長超過創建索引的預期，那么需要創建新索引并重灌數據；

• 創建mapping是請自行制定分片數，否則創建的索引的分片數是ES的默認值。這其實并不符合需求；

• 副本數：一般設置為1，特色要求除外。

?

Q2：ES 優化做過哪些措施？

?

A：ES使用最佳實踐：寫入的數據考慮清楚是否會過期，ES擅長的不是存儲而是搜索，所以一般存入ES的數據難免會隨著時間刪除舊數據。刪除方法有兩種：①按記錄（不推薦）②按索引。推薦使用后者，所以需要業務根據數據特點，按天、月、季度等創建索引。分片數夠用就好，不要過多不要過少。ES不是數據庫，不建議做頻繁的更新。

?

Q3：集群可承受的 TPS 是多少？

?

A：這個沒有具體的數字，根據不同規模集群、不同的索引結構等不同，建議根據業務評估自己的流量，壓測雙倍流量，若ES無法承受或滿足，可以考慮擴容集群，不要流量暴增于平時的3倍、4倍，甚至更多的規模。

?

Q4：ES 主要是用于明細單查詢，還是聚合統計？Join 對資源耗用大嗎？如何控制內存及優化？

?

A：ES在訂單系統中的實踐主要是解決復雜查詢的問題，ES不建議使用聚合統計，如果非要使用那我也攔不住你，哈哈哈。

?

深分頁的問題【內存】

ES處理查詢的流程如下：

Client需要第N到N+m條結果；

接到這個請求的ES server（后繼稱之為協調者）向每一個數據分片所在的數據節點發送請求；

每一個數據節點都需要向協調者返回(N+m)個結果；

如果有n個數據分片，那么協調者拿到n * (N+m)個結果，排序，扔掉(n-1) * (N+m)個結果，返回給client N+m個結果；

如果N是10W，100W，那么協調者的內存壓力會非常大；

在我們目前維護的2.1版本中，ES已經不容許N>10000了。

?

深分頁的危害：導致打爆節點內存引起集群整體不可用。

?

Q5：應用 canal 同步數據，會有延遲嗎？

?

A：首先來說下ES 特點：Elasticsearch是一個接近實時的搜索平臺。這意味著，從索引一個文檔直到這個文檔能夠被搜索到有一個輕微的延遲（通常是1秒），這個參數也是可以調整的，根據業務場景調整。

?

可以肯定的是延遲是肯定的。其實延遲大小完全取決你整個同步流程中是否有瓶頸點，如果業務要求實時的，其實不建議在這種場景下使用ES。就好比數據庫查詢從庫不能接受延遲，那就不要做讀寫分離，或者都查詢主庫。

?

Q6：sqlproxy 具體用的哪個？

?

A：sqlproxy這個是指MySQL讀寫分離的實現，大家可以網上查詢下有很多資料。官網地址：https://dev.mysql.com/doc/connector-j/5.1/en/connector-j-master-slave-replication-connection.html

?

?

<mvn.jdbc.driver>com.mysql.jdbc.ReplicationDriver</mvn.jdbc.driver>

<mvn.jdbc.url>jdbc:mysql:replication://m.xxx.com:3306,s.xxx.com:3306/dbName</mvn.jdbc.url>

?

?

Q7：Redis 用于查詢緩存、分發任務緩存？

?

A：Redis在項目中的使用場景，緩存查詢，分布式鎖使用。其中還有一個異步任務是通過redis zset + tbschedule 定時或實時的去執行一些業務邏輯。

?

添加隊列數據方法：

?

public Boolean zAdd(String key, final double score, String value) ;

?

查詢獲取隊列數據：

?

public Set<String> zRangeByScore(String key, final double min, final double max) ;

?

Q8：容量評估可以講一些細節嘛？

?

A：基本有兩種場景：

?

日常業務流程是否有瓶頸 ；

大促期間根據流量預估系統是否有瓶頸。

?

京東到家內部系統是有一套完整的監控系統，基于接口，應用機器，集群的多維度監控。

?

• 接口：

• 響應時間，tp99，tp999，tp9999 等；

• 接口調用量，次數/分鐘；

• 可用率。

?

• 應用機器

根據監控可以查看單機器相關指標數據是否正常，比如：

• CPU使用率；

• 系統負載；

• 網絡IO；

• TCP連接數，線程數；

• 磁盤使用率。

  ?

• 集群

• Redis集群；

• ES集群；

• MySQL集群。

?

對于集群來說是根據集群下機器指標是否正常來評估整個集群是否正常。需要看集群可以承載業務流量的TPS、QPS等指標是否滿足業務需求，同時需要評估大促場景下是否可以滿足要求。這種情況就需要根據大促流量評估壓測，看集群以及應用，接口是否可以滿足需求。

?

每個公司可以根據自身規則進行擴容，及架構升級。比如日常CPU超過60%考慮應用擴容，負載遠大于機器核數等等。

?

Q9：異步定時任務用的是什么中間件？

?

A：tbschedule是一個支持分布式的調度框架，讓批量任務或者不斷變化的任務能夠被動態的分配到多個主機的JVM中， 在不同的線程組中并行執行，所有的任務能夠被不重復，不遺漏的快速處理。基于ZooKeeper的純Java實現，由Alibaba開源。

?

Q10：在云上部署還是物理服務器？

?

A：應用都部署在云服務器上，首先即時，幾分鐘即可完成，可一鍵部署、也可自主安裝操作系統。安全性方面因為服務分布在多臺服務器、甚至多個機房，所以不容易徹底宕機，抗災容錯能力強，可以保證長時間在線。彈性以及可擴展性方面云主機基本特點就是分布式架構，所以可以輕而易舉地增加服務器，成倍擴展服務能力。

?

Q11：RPC 高可用怎么實現？

?

A：RPC高可用基本都是借助于分布式框架，阿里開源dubbo，Spring全家桶的SpringCloud，包括我們使用的京東自研的JSF。其工作原理，感興趣的同學可以網上搜下，很多資料。在這兒就不一一解答了。

總結

以上是生活随笔為你收集整理的京东订单系统高可用架构及演变过程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。