本文主要從服務化的起源開始講起，圍繞EDAS介紹這些年來，隨着阿里龐大的電商技術平臺流量和併發不斷攀升過程中，中間件的微服務技術面臨的一系列挑戰及解決方法。同時，也會向讀者介紹歷次雙十一背後，EDAS服務化技術的演進歷程。
服務化的起源
微服務的解決之道
海量微服務的挑戰
關於作者
以下爲精彩內容整理：
服務化的起源
阿里巴巴前期技術現狀
當時阿里巴巴技術團隊規模有500人左右，整個技術網站使用單一War應用，基於傳統應用開發架構，業務每年翻倍增長。
我們面臨着非常多的問題：
上百人維護一個核心工程會碰到很多問題。源代碼衝突嚴重、協同成本非常高等；項目發佈週期太長；所有的邏輯都是耦合的，錯誤難以隔離，如對淘寶網整個工程裏的某個模塊、某個系統功能進行一些改動時，整個系統都會面臨非常大的技術風險。
數據庫能力達到上限。淘寶早期用Oracle數據庫，單機的Oracle數據庫連接數捉襟見肘、單機IOPS達到瓶頸、CPU 90%以上，每年Down機最少一次。
數據孤島。數據隔離，重複建設，數據不一致；無法進行大數據分析。
基於EDAS進行服務化改造
淘寶網圍繞EDAS技術體系進行了一整套的服務化改造，在這個改造過程中，我們首先將數據複用度最高的數據進行拆分，剝離出用戶中心這樣的共享型的服務層，對上層所有業務進行用戶相關的所有邏輯，接下來又陸續有千島湖項目、五彩石項目，這些項目的背後都是一系列的服務化中心拆分出來的產物，後來經過6～7年的服務化演進，目前服務中心數已達50多個。
阿里巴巴核心服務化架構
自主創新走出技術困境，沉澱一大批成熟中間件技術，最底層爲共享型中間件和組件，以及阿里雲沉澱下來的技術支撐型產品；
共享服務體系打破應用“煙囪式”建設方式，支撐業務快速創新；
雲化基礎架構高效支撐業務增長，靈活的彈性伸縮帶來巨大的成本節約。
服務化解決之道
高性能服務框架
整個微服務架構落實到技術層面，就是把原本集中式的模塊分散到分佈式裏不同的機制上運行，並且希望有這樣一個框架能夠將不同機器、不同機房、不同模塊之間的服務化調用能夠順暢的構建起來，並且能夠幫助組織服務發佈、服務註冊以及服務發現等過程。目前阿里使用的是EDAS-RPC 3.0：HSF，阿里90%以上應用使用、 7次雙十一大促考驗、支持分佈式事務。而EDAS-RPC 1.0：Dubbo，是國內最活躍開源軟件之一、開源分支達4000多個。
分佈式事務
整個RPC過程中，將原本集中式的服務通過RPC拆分變成服務A和服務B，並分別訪問各自的數據庫，同時進行分佈式事務管控，當某一個服務出現問題需要回滾時，我們能夠將所有在一個分佈式組的服務都進行回滾，去中心化服務化框架，只是一個簡單的開始。
分佈配置管理
阿里內部有可靠的配置中心Diamond，配置中心能夠在毫秒級推送、變更歷史記錄、推送軌跡追蹤。
立體化監控服務
資源+容器+應用 = 立體化監控服務
監控是我們非常關注的事情，對於系統整體的性能指標也非常重要，所以，我們會嘗試從不同層面收集信息，具體包括以下三大方面：
系統資源：負載，CPU、內存、磁盤、網絡
容器：堆內存、類加載、線程池、連接器
應用：響應時間、吞吐率、關鍵鏈路分析
容器監控
阿里巴巴目前是架構在Java平臺上，作爲包含Java運行環境的Java容器，是監控的重要的點，我們會監控堆內存與非堆內存使用情況、線程運行情況（提前將線程情況全部顯示出來）、連接器情況，類加載情況尤複雜，很多時候一個類進行初始化時，層層依賴其它類，對此，我們在應用啓動時跟蹤加載的類。
應用監控
當原本在集中式的系統架構裏面，每個頁面會貫穿非常多的模塊，每個模塊都耦合在一個系統中，最終監控出的是表象，無法知道頁面打開慢是哪個模塊哪個功能邏輯上慢。現在，我們會對每一個服務接口、方法的實時調用情況進行監控，我們還會調用QPS、響應時間進行統計，同時快速感知系統流量變化。
海量微服務的挑戰
服務化的演進
隨着服務化的拆分，所有的系統會變得越來越多，箭頭指向就是底層的服務化中心，上層調用過來就是前端的業務系統。很多系統調用很多的服務中心，這時已經沒有能夠人爲的架構師幫助我們進行服務依賴和架構梳理。
EDAS鷹眼跟蹤
於是，阿里內部進行了EDAS鷹眼的研發。圖中從上至下，包括從頁面打開到頁面完整響應所經歷的分佈式各層系統調用。阿里內部就是依靠一整套的鏈路跟蹤系統，能夠在系統出現打開失敗時，可以非常清晰的故障根源在哪。
EDAS鏈路分析
當我們把類似的請求調用鏈路全部彙總起來進行分析後，就可以在很短時間內進行數據採集，並且有數據化的運營出來。峯值的QPS是指今天在某一個業務高峯時某一個業務的服務在分鐘級別的服務化的調用過程中達到的最大的QPS，如圖中標記可以看出，即使頁面暴露在最前端，但不一定是壓力最大的，這就算數據可視化帶給我們的價值所在。我們還要對數據進行決策上的幫助，數據最大的價值在於可以精準化的通知我們最大壓力點。
某個頁面打開經過一系列的系統調用時，總會在某一個點出現問題，稱之爲易故障點。我們可以直觀的看到在過去的一天裏，到底所有的請求在哪一個組件的出錯率最高，我們就可以針對性的解決。
EDAS容量規劃
在過去的6～7年時間，沉澱了一整套的容量規劃模型。首先我們希望在第一步將線上真實流量進行引流，通過真實流量壓測部分單機性能，然後根據設定的運行水位計算系統承載的最高容量，從而到最後可以實現機器按需的上線和下線，把這些系統融會貫通在一起，就是整體的容量規劃提供的功能。所有的壓測在單機上都會定一些指標,當我們進行集羣中把一半機器流量全部引到另一半時候，所有流量的QPS就會翻倍，當單機性能如果沒有達到運行水位時，就會繼續引流，直到達到指標爲止。
EDAS限流降級
爲了在大促時保證系統更穩定的運行，採用了限流和降級的手段。根據不同服務的優先級，不同服務的重要程度來執行限流和降級的措施。限流降級是阿里最有特色的功能之一，我們會面對非常強大的挑戰就是雙十一網購狂歡節，我們需要在成本和體驗中選擇一個好的平衡點，要利用這個平衡點我們必須要保證系統的可用性，不能因爲用戶多導致系統無法服務，就像排隊買票一樣，我們需要對自己的系統進行優化，具體表現在一下兩方面：
限流：針對非核心服務調用者
降級：針對系統的非核心服務依賴
阿里十年技術精華沉澱
早期淘寶網從一個單一的War包開始，慢慢通過RPC框架進行一系列服務化拆分，並且我們有能力在監控、問題診斷、分佈式事務配置等一系列中間技術上將分佈式系統進行可控的、可運維的監控，隨着服務化進行越來越深遠，完全靠人的挑戰會非常大，因此就有了EDAS鷹眼跟蹤系統以及限流降級等功能，最終在這個平臺上，我們能夠支撐海量高併發的系統，在中間件的架構下進行運營。
關於作者
倪超：花名銀時，阿里巴巴企業互聯網架構平臺產品經理、國家認證系統分析師、IT暢銷書作者，著有《從Paxos到ZooKeeper》一書，2015年國內新書暢銷榜Top10。2010年，以實習生身份加入阿里，入職中間件技術團隊，經歷了阿里中間件技術從1.0到3.0的變革，目前負責商用軟件EDAS。