鷹眼跟蹤、限流降級，EDAS的微服務解決之道

本文主要從服務化的起源開始講起，圍繞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，是國內最活躍開源軟件之1、開源分支達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。