菜鳥下一代分散式體系架構的設計理念

二十年來，整個分散式系統架構的演進，從 C/S 到 B/S，再到分散式系統，當前廣泛使用的是網格計算和雲端計算，包括目標、定位、場景。

菜鳥乃至阿里在全球化程式中，也面臨著全球分散式架構問題，以及倉儲系統中獨特場景下雲端計算能力的不足。菜鳥資深技術專家 黃浩 老師目前帶領團隊在設計規劃菜鳥下一代分散式系統架構，結合傳統雲端計算 PaaS/BaaS 以及邊緣計算能力，將其應用在全球多域體系中。

黃浩老師工作了 17 年，目前是 TOGAF 認證架構師，菜鳥程式設計師聯合會首任主席，現為菜鳥倉儲技術部及自動化技術團隊負責人。2001 年起就在 Java 中介軟體、分散式系統架構浸染多年，在企業架構、中介軟體、分散式系統設計與雲端計算架構有非常豐富的經驗。2016 年主導推進菜鳥混合雲架構，建立全球多域混合雲架構，成為整個阿里巴巴雲化模式的樣板和方向。

當前分散式技術架構舉例 - 微服務

常見微服務架構，其前端流量入口採用負載分片模式。應用層常見是採取一級網路 (通過配置推送的軟負載) 或者二級網路 (通過應用閘道器負載隔離) 模式。阿里是使用前者，百度、新浪使用後者，主要取決於微服務的展現形式 (RPC or Rest-API)，差異是是否需要一個專職配置中心。為保證請求無狀態地實現遷移，所以使用共享資料節點 (儲存各種形式的臨時或中間資料) 的形式實現。資料節點往往採用分片的主備模式。

當前分散式應用架構舉例 - 應用分層架構

這是比較廣泛採用的架構模式，前面使用 CDN，後面有分散式快取，服務端使用前後端分離，或者 Node.js / Rest-ful。應用層通過 ElasticSearch 讓資料庫去刷索引，實現大量的查詢和讀服務。中間使用大量訊息系統進行相互的聯絡。這種架構模式的優點是可以應用橫向擴張，都是獨立的應用，很容易 Docker 化。

阿里分散式系統架構舉例 - 單元化、混合雲

阿里全國多站點的佈局帶來一個問題，例如廣州的站點出現問題，所有訪問廣州的客戶都會受到影響。這就需要多活的站點，多地可以自由無感切換。單元化架構使用到了配置資料同步，每個單元扮演對等節點，為所有的節點提供服務，從業務服務角度，所有站點均對等隔離，按照流量分離的方式分別不同的使用者提供服務。開始的時候通過流量負載的方式，底層通關管理節點把配置資料之間、核心資料之間進行同步。從管理配置角度，中心站點擔任管理節點，負責管理單元節點及分發配置。

菜鳥混合雲架構 - 雙寫雙機房

在 2015 年的時候，推出了菜鳥混合雲架構，它和傳統混合雲有點不同。菜鳥混合雲分為兩個部分，一是獨立的混合雲機房；二是雙寫雙機房，再加一套混合雲就是同城三機房。其策略是保證本身的叢集應用呼叫，在預設情況下是本機房呼叫。但是在資源緊張的情況下，要做彈性，擴容雲上機房，說明有些應用要訪問雲上機房，而底層進行配置的資料同步，以及資料庫之間強一致同步寫。整個菜鳥在阿里是第一個實現基於混合雲的同城三機房模式。

關於微服務的困局挑戰

阿里算是最早踐行微服務理念的公司，僅菜鳥就有超過 1000+ 的單體應用，並且還在逐年增多。黃浩老師說，阿里從微服務架構裡獲得了很多好處，也踩過很多不可避免的坑。微服務並非是一種架構或者架構理念（或者說它只是一個技術架構應用方法），它的初心是降低複雜度提高系統的柔性，而實際是，如果缺乏清晰的架構理念和設計 (包括業務架構與應用架構)，它帶來的結果只會是沒有架構。

菜鳥在實踐微服務架構過程中也遇到過很多問題，例如資源繫結與限制，效率瓶頸，缺乏總體架構。實際業務場景的跨多個服務訴求；網狀的呼叫及同步依賴關係；容器化背後開發與資源的繫結；極大量的遠端呼叫；爆炸式增長的碎片化應用；

黃浩老師也說，跨服務之間的應用橫向排程，微服務廣泛應用，應用是網狀架構，密密麻麻的節點，很難分清楚。其中最大的效能問題就是遠端呼叫問題，

下一代架構的目標與挑戰

在反思之後，下一代架構的要解決什麼問題呢？黃浩老師說主要有 5 點：

1. 應用的開發與部署環境和位置無關性 (Cloud Foundry)

2. 更大範圍分散式資料可信儲存及一致性保障 (Block Chain 最核心的技術加密，分散式賬本，分散式異地儲存，阿里目前也在實踐)

3. 容器化技術，網格計算能力 (Edge/Grid Computing)

4. 事件驅動架構的迴歸 (阿里在嘗試 Reactive Stream)

5. 全球化網路化對等架構模式

Reactive- 淘寶應用架構實踐

Reactive 是引導淘寶未來 10 年發展的技術架構，它的特點是響應式的程式設計方式，另一個特點是事件驅動的架構。同時也能看到 EDA 的迴歸，基於事件響應模式和非同步處理。通過事件框架實現應用依賴間解耦。

流式程式設計處理也是架構的未來方向，符合 Reactive-Stream 規範的流式呼叫，傳統序列應用呼叫和開發模式的升級。

微服務升級 - 菜鳥應用實踐

對於菜鳥來說，首先要做的事情的是解耦，將開發和資源的分離。關於 Application Container 的定義，它不是簡單的使用 Spring Cloud 或者 Spring Boot。例如定義模組，模組是可以獨立地進行服務，也可以組合。在分散式框架中間，當遠端呼叫服務的時候，是可以判斷遠端應用是不是在本地環境內，如果是，就可以不用經過網路，只經過網路埠；只經過資料層，但不經過物理層；實際上是不佔用整個頻寬的。另外，如果能識別出這兩個應用都在一個環境內，就可以本地方法呼叫。網路狀態下可以清清楚楚將模組組成架構，耦合關係不緊密，而且是分層的，第一個域是 Business domain，此業務域裡各應用之間是分散式的網狀關係。

異地多活 - 菜鳥基礎架構實踐

去年菜鳥做的異地多活完全改變了主從模式，主從模式是 masters load 是活的，slave load 是備份的。而異地多活則是對等節點，用到了資料庫層面的 X-Cluster 同步，正所謂三地五副本，有些內容是強一致性寫到其他幾個副本里。此外還有異地非同步備份副本。通過訊息路由跨域傳輸實現多機房異地多活，可以在任意時間秒級切換系統。

雲 + 端 - 菜鳥網格計算方向

黃浩老師最後指出，IoT 很火，但真正意義的 IoT，是每個物體都像一臺電腦，每臺電腦的關係是，能相互之間可控組網，二是逐級聯絡。菜鳥物流分為線上和線下兩部分，線上應用和線下行為的不一致，線下端的資料不可能全部放到雲端。菜鳥現在在做邊緣計算節點利用網格計算的思路，成為計算容器，既能承擔區域網的路由和閘道器，同時成為萬物計算節點，它和中心節點的差異只是計算能力的差異，而不是它自身的環境、架構、結構上的差異，這就是菜鳥網格計算正在推進的方向。

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31562044/viewspace-2221585/，如需轉載，請註明出處，否則將追究法律責任。