應對618,京東到家訂單系統高可用架構的迭代實戰

大家好,我是京東到家後臺研發部的架構師閆文廣,今天將給大家分享京東到家訂單系統的高可用架構及演變過程。

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

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

  • 京東到家系統架構
  • 訂單系統架構演進
  • 訂單系統穩定性保障實踐

一、京東到家系統架構

業務架構

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

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

運營支撐業務架構

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

後端架構

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

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

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

訂單數據入庫流程

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

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

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

二、訂單系統架構演進

訂單系統業務流程

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

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

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

RPC微服務化集羣

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

簡單總結來說,微服務可以降低系統的複雜度,可以獨立部署,並且有很好的擴展性:

  • 降低複雜度:把原來耦合在一起的業務,按領域拆分爲不同的微服務,拆分原有的複雜邏輯,每個微服務專注於單一業務邏輯。明確定義領域職責與邊界;
  • 獨立部署:由於微服務具備獨立部署運行能力,當業務發生變更升級時,微服務可以單獨開發、測試、部署升級。提高了迭代效率,降低了研發風險;
  • 擴展性:拆分後的微服務架構獨立部署,可以根據流量預估或壓測評估獨立進行擴容升級。

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

Redis的接入解決了什麼問題?數據庫爲什麼要分庫?ES爲什麼在接下來一些系統架構升級裏會被引入進來?爲什麼DB要拆成多個集羣?這背後的一些根本問題,以及解決業務系統的一些背景,接下來我們逐一探討。

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

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

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

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有問題,我們能確保應用可以正常請求響應,來保證系統的高可用。

MySQL數據庫

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

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

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

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

ElasticSearch集羣

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

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

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

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

三、訂單系統穩定性保障實踐

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

訂單系統可用性建設

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

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

系統容災能力

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

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

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

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

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

系統容量能力

至於系統容量的能力,主要分爲評估和擴容兩個方面。容量評估可以藉助一些輔助的工具,然後進行場景的壓測和全鏈路的壓測;而擴容方面,可以分階段依次實施冗餘備份(主從分離)、垂直拆分(拆分核心屬性與非核心屬性)、自動歸檔。

系統預警能力

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

在接口層面,我們可以監控到:

  • 可用率;
  • 響應時間;
  • 調用量:當別人調用你的接口,你設置調用的一個量值,當超過閥值時就是進來了一些非正常的流量,當監控到這些異常流量,就可以做限流等相應操作;
  • 自定義:自定義一些報警;
  • 關鍵詞:當系統出現某種問題,需要關鍵字報出來然後進行人工介入;
  • 調用鏈:一個接口操作下來,誰調用了你?你調用了誰?哪個環節有問題?

在應用層面,我們可以監控到:

  • Young GC;
  • Full GC;
  • 堆內存;
  • 非堆內存;
  • CPU使用率;
  • 線程數。

下面是關於DB、ES、Redis的集羣監控,包括:

  • CPU使用率;
  • 系統負載;
  • 內存;
  • 線程數;
  • 讀寫IO;
  • 磁盤使用率;
  • TCP連接數。

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

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

四、總結

一個企業的架構師團隊,需要長期關注技術驅動業務、明確領域職責與邊界等關鍵問題,同時架構的演進過程也是不斷考慮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處理查詢的流程如下:

  1. Client需要第N到N+m條結果;
  2. 接到這個請求的ES server(後繼稱之爲協調者)向每一個數據分片所在的數據節點發送請求;
  3. 每一個數據節點都需要向協調者返回(N+m)個結果;
  4. 如果有n個數據分片,那麼協調者拿到n * (N+m)個結果,排序,扔掉(n-1) * (N+m)個結果,返回給client N+m個結果;
  5. 如果N是10W,100W,那麼協調者的內存壓力會非常大;
  6. 在我們目前維護的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: 基本有兩種場景:

  1. 日常業務流程是否有瓶頸 ;
  2. 大促期間根據流量預估系統是否有瓶頸。

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

  • 接口:

    • 響應時間,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。其工作原理,感興趣的同學可以網上搜下,很多資料。在這兒就不一一解答了。

作者介紹

閆文廣,京東到家後臺研發部架構師

  • 從事支付系統、計費系統和訂單履約系統等後臺領域的研發,現專注於訂單中心架構優化和研發相關的工作。

原文鏈接

應對618,京東到家訂單系統高可用架構的迭代實戰

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章