微服務架構在阿里的演化

摘要： 3 月 10 日，2017 阿里雲網站行業熱點問題和解決方案線下研討會在上海舉行。阿里雲產品專家銀時為大家帶來《微服務架構如何實現網站服務垂直化拆分》精彩演講。主要從服務化的緣起、微服務架構的形成，以及在大規模的服務化過程中所面臨的一些挑戰以及解決方案，跟大家分享整個微服務。

3 月 10 日，2017 阿里雲網站行業熱點問題和解決方案線下研討會在上海舉行。阿里雲產品專家銀時為大家帶來《微服務架構如何實現網站服務垂直化拆分》精彩演講。主要從服務化的緣起、微服務架構的形成，以及在大規模的服務化過程中所面臨的一些挑戰以及解決方案，跟大家分享整個微服務。

以下內容根據現場分享和講師 PPT 整理而成。

關於講師：

倪超，阿里花名銀時，阿里巴巴企業網際網路架構平臺產品專家、國家認證系統分析師、IT 暢銷書作者，著有《從 Paxos 到 ZooKeeper》一書，2015 年國內新書暢銷榜 Top10。2010 年，以實習生身份加入阿里，入職中介軟體技術團隊，經歷了阿里中介軟體技術從 1.0 到 3.0 的變革，目前負責商用軟體 EDAS。

關於 Aliware

Aliware 是阿里巴巴中介軟體技術品牌，包含 5 箇中介軟體產品，主要是：EDAS、DRDS、MQ、ARMS、CSB。Aliware 從 2007 年開始，經歷了 8 年多的雙 11 大促，每次大促都能使產品體系更上一個臺階。像 JStorm、Dubbo、Rocketmq 等等一系列的開源產品，無論在 GitHub 還是 Apache 這些頂級專案上，都是非常火的專案。

服務化緣起

在 2007 年的時候，阿里技術研發團隊大概是 500 人左右，主要業務是淘寶網站點，都是都在一個單一的 WAR 包進行部署，基於傳統 JAVA EE 應用開發架構，使用的是 Oracle 資料庫和 JBoss 伺服器。當時整個淘寶網就是兩個 WAR 包，一個是前臺的，就是淘寶網；還有一個是後臺的 CRM 系統，是給所有的客戶支援人員使用的。

在當時那個階段，我們面臨著非常多的問題：
第一個問題，是系統的研發成本非常高。

首先，上百人維護一個核心工程，原始碼衝突嚴重，協同成本極高。淘寶網當時是單獨的一個 WAR 包，在執行的時候，就是一個工程，都是一份程式碼。無論是以前的 SVN，還是今天用了 Git 等一系列工具，程式碼衝突的問題是逃不掉的。

其次，專案釋出週期太長。當年的淘寶網，是一個煙囪式的網站。它底層就是一個資料庫，然後上層是所有業務邏輯的一個 DAO 層，專門負責訪問資料庫，再上層可能是業務層。所有模組的邏輯都在一個系統裡面，都在一起部署。這樣會因為某幾個模組的開發效率低，影響整個站點的釋出。

然後，錯誤難以隔離。這個是當時比較致命性的問題。比如說一個大的活動，我如果對時間的一個模組或者其中的一個 if 判斷邏輯進行一些變更的話，整個活動頁面會出問題，會導致整個站點都不可用。

第二個問題，是資料庫能力達到上限。

淘寶早期是用 oracle 資料庫，單機的 oracle 資料庫連線數捉襟見肘，單機 IOPS 達到瓶頸，每天資料庫 CPU90% 的負載運轉，每年 Down 機最少一次。

第三個問題，是資料孤島

當時淘寶、天貓、聚划算，萬網等業務系統之間，資料是完全隔離的，資料不一致，無法複用，賬號不統一，不能進行關聯推薦，也無法進行大資料分析。

微服務架構的形成

在這三大問題出現之後，淘寶網開始做一些服務化探索。從 2007 年開始，進行了一些微服務架構改造。

RPC 框架：微服務架構的核心基礎

在阿里內部做服務化的最底層、最核心的是兩個框架，首先是 Dubbo 框架。Dubbo 框架 2010 年誕生，2011 年對外開源。現在阿里發展到了第三代 RPC 框架，在內部代號叫 HSF 的框架，目前 90% 以上的應用，都在使用這樣一個框架。每年雙 11 大促也在用。

訊息佇列：非同步呼叫實現系統解耦

前面說到的 RPC 框架，重點是幫助我們解決，一個網站在進行服務化拆分的時候，各個模組之間的聯絡，需要通過 RPC 框架來進行一個同步化的呼叫，那麼還有一些場景，它其實是不需要同步化呼叫的，是可以用非同步去解決。

比如淘寶網平臺上的手機充值業務，看似是一個序列的充值流程，其實可以通過非同步結構來解決。首先，通過同步呼叫幫助使用者確保他的下單在電商平臺已經完成；其次，通過訊息元件進行非同步解耦，使得那些耗時長的不是核心鏈路的一些東西，能夠不佔據消費者在使用網站、APP 上面的主流程時間，優化使用者體驗。

基於此，我們訊息中介軟體主要會去解決三大類的問題。

第一個是可靠同步，它的訊息是可靠並且有序的，這是在所有需要穩定性、提高交易鏈路上用到的。第二個是可靠非同步，當有穩定性的訴求，也有吞吐量訴求的時候，可以採用非同步的這些邏輯，通過非同步反饋，讓訊息中介軟體反覆去投遞，確保穩定性。最後一個是單向，不關注穩定性，只關注吞吐量是否大。

大規模配置推送

在進行服務化拆分之後，需要將每一個服務使用的配置進行集中式管理。因此，我們研發了可靠的配置推送服務，能夠在毫秒級時間內完成配置推送，同時支援變更歷史記錄和推送軌跡的查詢。

立體化監控

監控是我們非常關注的事情，對於系統整體的效能指標也非常重要，所以，我們會嘗試從不同層面收集資訊，實現對應用立體化的監控，包括資源、容器和服務，具體包括以下三大方面：

系統資源：負載，CPU、記憶體、磁碟、網路

容器：堆記憶體、類載入、執行緒池、聯結器

服務：響應時間、吞吐率、關鍵鏈路分析

服務監控

當原本在集中式的系統架構裡面，每個頁面會貫穿非常多的模組，每個模組都耦合在一個系統中，最終監控出的是表象，無法知道頁面開啟慢是哪個模組哪個功能邏輯上慢。現在，我們會對每一個服務介面、方法的實時呼叫情況進行監控，能夠細緻地將每一個服務的生命週期，每一個服務執行時的監控指標非常細化的監控出來，還會呼叫 QPS、響應時間進行統計，同時快速感知系統流量變化。

淘寶網圍繞 EDAS 技術體系進行了一整套的服務化改造，在這個改造過程中，首先將資料複用度最高的資料進行拆分，剝離出使用者中心這樣的共享型的服務層，對上層所有業務進行使用者相關的所有邏輯，接下來又陸續有千島湖專案、五彩石專案，這些專案的背後都是一系列的服務化中心拆分出來的產物，後來經過 6-7 年的服務化演進，目前服務中心數已達 50 多個。

圖為阿里巴巴核心服務化架構。自主創新走出技術困境，沉澱一大批成熟中介軟體技術，最底層為共享型中介軟體和元件，以及阿里雲沉澱下來的技術支撐型產品；共享服務體系打破應用“煙囪式”建設方式，支撐業務快速創新；雲化基礎架構高效支撐業務增長，靈活的彈性伸縮帶來巨大的成本節約。

大規模服務化挑戰

隨著服務化的拆分，所有的系統會變得越來越多，箭頭指向就是底層的服務化中心，上層呼叫過來就是前端的業務系統。很多系統呼叫很多的服務中心，這時已經沒有架構師能夠人為的幫助我們進行服務依賴和架構梳理。

EDAS 鷹眼監控系統

我們在排查一些線上問題的時候，其實不要求說能夠非常快速智慧化的幫我去解決問題，只要有這樣一套系統能夠幫我快速的去定位問題就可以，於是阿里內部做了 EDAS 鷹眼監控這樣一個系統。

圖中從上至下可以看出，鷹眼監控系統能夠非常快速的定位故障在哪裡，並且通過視覺化的手段，能夠在系統上面發現是由於哪臺機器上的哪一段日誌導致的。這是鷹眼監控做的第一個事情。

鷹眼監控做的第二個事情是什麼呢？當我們把類似的請求呼叫鏈路全部彙總起來進行分析後，就可以在很短時間內進行資料採集，並且有資料化的運營出來。峰值的 QPS 是指今天在某一個業務高峰時，某一個業務的服務，在分鐘級別的服務化的呼叫過程中，達到的最大的 QPS。如圖中標記可以看出，即使頁面暴露在最前端，但不一定是壓力最大的，這就算資料視覺化帶給我們的價值。我們還要對資料進行決策上的幫助，資料最大的價值在於可以精準化的通知我們最大壓力點。

某個頁面開啟經過一系列的系統呼叫時，總會在某一個點出現問題，稱之為易故障點。我們可以直觀的看到在過去的一天裡，到底所有的請求在哪一個元件的出錯率最高，就可以針對性的解決。

EDAS 容量規劃

阿里內部如何去做一些容量性的一些規劃？首先我們會去製造一些流量，通過真實流量壓測部分單機效能，然後根據設定的執行水位計算系統承載的最高容量，從而到最後可以實現機器按需的上線和下線，把這些系統融會貫通在一起，就是整體的容量規劃提供的功能。所有的壓測在單機上都會定一些指標, 當我們進行叢集中把一半機器流量全部引到另一半時候，所有流量的 QPS 就會翻倍，當單機效能如果沒有達到執行水位時，就會繼續引流，直到達到指標為止。

EDAS 限流降級

在整個雙 11 期間，在不同的時間點，我們所面臨服務的核心和非核心是不一樣。比如在雙 11 零點的時候是流量高峰，基本上來自於所有的支付環節，因此在那個階段，我們要把所有的資源全部傾向於交易、傾向於支付。而到了第二天早上起床的時候，物流服務會成為核心。今天我們會從業務的角度，去發現網站的核心和非核心。EDAS 裡面會有一個視覺化的配置介面，去幫助你在某個階段，哪個服務是核心服務，那麼這個核心服務能夠去呼叫更多的底層資源，但在其它點的時候，它就會被限流住。

在公有云和專有云提供商業化服務