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