基于阿里企業級分布式應用服務(EDAS)的敏捷服務開發與架構實踐

摘要： 8月30日～31日2016螞蟻金服&阿里云在線金融技術峰會拉開帷幕，阿里云中間件技術部資深專家沈詢帶來了“基于阿里企業級分布式應用服務(EDAS)的敏捷服務開發與架構實踐”的重要演講。

本文主要從高速增長的阿里業務開始談起，講述當年面對的業務場景和背景，碰到了什么樣的技術挑戰，且用什么樣的思路去解決它，最后和大家分享了解決后產生的產品Aliware中非常重要的EDAS。

PDF下載： 點此進入

以下是演講內容整理：

高速業務增長帶來的挑戰

大型電子商務平臺吸引了大量賣家和買家，圖為2014年IPO時候截得的圖，可以看到在阿里上有10億多件商品等，現在仍然以非常高的速度在增長。

圖為2003年到2010年淘寶網注冊用戶數，用戶數從非常低的值逐漸漲到近40000萬人，這些用戶突然來到我們的網站，就會給網站非常多的訪問壓力。2003年到2006年我們主要是想盡方法以業務為核心積累技術，到后來互聯網人群在高速增長，整個體系面臨的技術挑戰就會非常多，具體有以下四點：

• 業務需求爆發式增長
• 開發人員快速擴張
• 系統代碼量越來越多
• 系統壓力越來越大

綜合來看，一個技術性網站最重要的技術挑戰在于考慮業務的高速增長、用戶數量的高速增長導致下層原來看不見的問題變成了新的問題。

挑戰與解決之道

阿里前期技術團隊規模500人左右，單一War應用，是以PHP為核心構建的系統，PHP+MySQL+Linux+Apache標準的LAMP的系統架構，后來逐漸用一些開源的技術替換掉了原來的商業產品，隨著業務的不斷發展，不斷的把新的代碼加入到系統中，我們研發了一套分布式存儲架構，搜索也是自己構建的。

技術問題

隨著技術快速增長和演進，隨著人員的增加，我們發現很多嚴重的問題展現出來。

業務支持緩慢，牽一發而動全身

很多人同時維護一個核心工程，不同人有不同的理解，會導致源代碼沖突嚴重，很難做項目管理，協同成本非常高，進而項目發布周期就會很長，迭代速度變慢，且錯誤難以隔離。

數據庫能力達到上限

只有一個數據庫的問題是很大的，發布一個新的系統可能會導致宕機，由于數據庫里本身的索引建錯了，建錯是因為庫是重建的，Oracle的索引重建機制還沒有來得及更新柱狀圖。所以，只有一個Oracle數據庫時，連接數捉襟見肘，單機IOPS達到瓶頸，CPU 90%以上，每年宕機最少一次。

數據孤島

多套用戶體系導致用戶不知道到底在哪個網站登錄，我們想知道用戶的畫像，分析用戶的購買行為，但兩個不同網站的相同用戶名不確定是否為同一用戶，所以沒辦法進行后續的大數據分析。隨著系統越來越多，我們發現大量的用戶在系統出現時，比如查詢用戶的方法，在不同的業務系統里出現多次，每一次都不完全一樣，數據隔離、重復建設，數據不一致，這是項目管理和代碼管理的亂象。

基于EDAS進行服務化改造

沒有任何服務化的經驗去借鑒，我們只能一步一步的摸著石頭過河。我們做了幾個關鍵性的努力，首先是用戶中心遷出，從一個大的系統里拆出一小塊放到外面，這就是用戶中心，用戶中心是一個比較簡單純粹的處理用戶登錄的系統，當時在內部就有六、七種登錄方式，我們把這些方式全部代理出來，變成一個單獨的服務中心。如果我們不把系統代碼進行革新，就沒有辦法支撐，緊接著，我們就開始做自己的中間件的研發，千島湖項目產生時，EDAS、MQ、DRDS就隨著它一步步的演進到現在。交易中心是整個系統里最復雜的業務流程，幾乎和所有業務系統有關聯，當它用一些中間件完成整個系統的突破時，我們就可以認為看起來中間件和應用都準備好了。接著我們進行了第三個五彩石項目，商城和淘寶各有一套購買流程，我們需要用EDAS進行服務化改造，把這兩套流程融合到一起，使之能同時支撐兩個不同的出口，完成下一步的延伸。

服務化以后的架構演進

服務化以后，開始時業務應用很少，隨著系統往下延伸，很多人開始做服務化系統，服務之間也會進一步的復雜，從而會形成一個復雜的網狀結構，那么，依賴很多，如何進行準確的梳理呢？

當系統變成網狀結構后，一定會有一些業務系統是重要業務，一些業務系統是非重要業務，這些非重要業務突然出現小的故障時，整個系統就會宕機，我們成立了穩定性小組進行業務梳理，以交易流程為核心，哪些系統劃成重要系統，哪些系統為非重要的業務系統，但是，系統在不斷的變化，我們沒有辦法準確知道每一次變化后它的依賴關系是怎樣的，很難進行梳理，必須通過系統的方式來解決問題。

鷹眼系統

我們把整個系統現象成一個高速公路的路網，流量進來就如同行駛的汽車，如何能夠知道汽車從哪里進來又從哪里出去呢？在高速公路上做很多的關卡，這樣可以準確的追蹤到所有連接的道路和通信，這樣，哪里有問題都可以通過非常簡單的方式得到檢測，而這個檢測對于發現和解決問題是非常簡單的一件事，才有可能擺脫在服務化以后，復雜的系統運維和管控。

阿里經過驗證的件——EDAS

高性能服務框架

EDAS是一個高性能的服務框架，EDAS是由很多技術體系組成的一個整體包，如果想寫一個web應用，使用這個開發套件，所有在業務開發需要的功能都集成在里面，所有和業務中間件相關的應用也集成到里面了，最關鍵之一就是HSF，HSF在阿里90%以上應用上使用，相對比較成熟，支持分布式事務，經歷過七次雙十一大促的考驗，日均有千億級的調用量。

同時，我們也支持Dubbo，Dubbo也是阿里開發出來的市面上應用非常廣泛的開源軟件，已經有4000多個開源分支。

分布式事務

在服務框架之上，還有分布式事務，在分布式應用里應該怎樣完成單機應用中常見的一些事務操作呢？此時就需要使用分布式事務組件，它能夠將服務和服務之間多個不同庫之間的數據集中到一起去，從而提供一個整體的服務能力，看起來像寫單機業務系統一樣去寫分布式事務服務框架。去中心化服務化框架，只是一個簡單的開始。

分布式配置管理

可以在網站查詢配置哪些機器收到、哪些機器沒有收到，毫秒級推送，可以變更歷史記錄，推送軌跡追蹤等。

立體化監控服務

資源+容器+應用 = 立體化監控服務

監控是我們非常關注的事情，對于系統整體的性能指標也非常重要，所以，我們會嘗試從不同層面收集信息，具體包括以下三大方面：

系統資源：負載，CPU、內存、磁盤、網絡

容器：堆內存、類加載、線程池、連接器

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

容器監控

容器監控要監控堆內存與非堆內存使用情況，類加載情況（對于排查線上啟動問題非常方便），線程運行情況，連接器情況。

應用監控

應用監控主要從服務接口、方法的實時調用情況進行分析，以及調用QPS、響應時間分析，

快速感知系統流量變化，從而讓我們知道系統的問題所在。監控和報警在這里得到很好的體現，但這僅僅算是剛剛進階。

EDAS鷹眼跟蹤

鷹眼監控就是解決內部非常復雜的多樣鏈路的時候，怎樣進行持續的收集、跟蹤、統計，以幫助我們進行鏈路梳理的工具。比如從前面開始調用鏈路時有哪些異常，出現故障的地方都可以從這個調用鏈路上得到展現。

同時，通過海量調用鏈進行統計分析，得到鏈路各個依賴的穩定性指標。比如，某個地方的QPS很高，但這個系統不該有這么高的QPS，就可以認為這是一個依賴壓力問題。

除了鏈路分析功能，EDAS還有容量規劃的重要功能。通過線上真實引流到系統內進行壓測分析，然后根據設定的運行水位計算系統承載的最高容量，從而到最后可以實現機器按需的上線和下線，把這些系統融會貫通在一起，就是整體的容量規劃提供的功能。

EDAS限流降級

限流降級是阿里最有特色的功能之一，我們會面對非常強大的挑戰就是雙十一網購狂歡節，我們需要在成本和體驗中選擇一個好的平衡點，要利用這個平衡點我們必須要保證系統的可用性，不能因為用戶多導致系統無法服務，就像排隊買票一樣，我們需要對自己的系統進行優化，具體表現在一下兩方面：

• 限流：針對非核心服務調用者限制請求量
• 降級：針對系統的非核心服務依賴

應用發布和管理系統

以前是集中化的發布方式進行管理的，這對于一、二百臺機器是沒有問題的。然而，現在需要同時發布五、六百臺機器甚至更多，發布就會成為瓶頸。對此，我們內部引入EDAS燎原P2P發布系統，它能夠讓系統內進行P2P多點式的多host發布，使整個系統的應用發布能力得到快速提升。

EDAS燎原實現超大規模集群閃電發布，圖中可以看出發布耗時隨著機器數量增加變化趨勢。采用EDAS燎原發布系統，隨著應用實例的增加，發布的時間幾乎保持不變。有利于進行緊急發布時候的業務處理，實現快速回滾。

阿里十年技術精華沉淀

綜合來說，EDAS并不是簡單的服務化工具，它希望在整個應用的編寫周期里都可以進行操作，所以它結合了HSF、鷹眼、燎原等等。現在，它在公有云和專有云里都有輸出。

 

來自：http://jm.taobao.org/2016/09/01/59932/