本文根據阿里高級技術專家趙林(花名：丹臣)的演講整理。趙林在演講中主要為大家詳細介紹了阿里企業級分布式應用服務器EDAS產品和背后技術實踐。

企業級分布式應用服務(EDAS，Enterprise Distributed Application Service)是一個以阿里中間件團隊多款久經歷練的組件產品作為核心基礎，所組建的企業云計算解決方案。其充分利用阿里云現有的資源管理和服務體系，引入中間件整套成熟的分布式計算框架——包括分布式應用核心框架，分布式數據化運營，大型應用全生命周期管理等，以應用為中心，集成到EDAS平臺上，幫助企業級客戶輕松構建并托管分布式應用服務體系。

企業級分布式應用服務與傳統IOE架構的區別

傳統IOE架構

 

傳統IOE架構

隨著時間推移，在出現新業務時，開發人員有兩種應對辦法。

• 在原應用上增加新業務，將原本較小的應用慢慢擴充成很大的應用;
• 另起爐灶，重新創建針對新業務的新應用。

第一種只適用于業務較少的情況，而在新業務不斷增加的情況下，增加新應用也就成了必須。而在這種傳統架構中，新增的應用需要一一與原有的底層數據庫相連，導致每個應用都需要連接多個數據庫。

此外，在傳統IOE架構中：

• 每個應用彼此沒有太大關系，按煙囪式排列，唯一的共通點在于都與底層的數據庫相連;
• 所能處理的應用個數通常比較少，從幾個到幾十個不等。

總結：在傳統IOE架構中，每個應用都比較龐大，同時需要連接多個數據庫;架構中的應用數量較少，應用與應用之間的關系簡單。

大型分布式應用

 

大型分布式應用

• 應用彼此間存在復雜的調用關系;
• 架構中可管理的應用多，可能達到成百上千個應用。

其優點在于：這種架構具有良好的可擴展性;而缺點在于管理與運維比較困難，另外由于應用數量多，隨著業務增長，應用服務器從十臺增加到上百臺上千臺，這時業務系統故障與機器故障就一定會成為常態。

傳統“中心化”系統與阿里的“去中心化”系統架構的區別

傳統“中心化”(ESB)系統架構

 

傳統中心化系統架構

• 服務調用者與服務提供者通過企業服務總線相連接;
• ESB成為瓶頸：無論在性能上還是成本消耗上，ESB都會導致瓶頸出現。

阿里“去中心化”系統架構

 

阿里“去中心化”系統架構

開發這個架構的初衷是為了支撐分布式應用，為了讓整個業務系統的擴展沒有瓶頸，只需按照業務發展需要進行擴展;上圖是最早的雛形。后面為了完善該架構，又做了很多工作，下面將詳細說明。

EDAS服務調用

服務接口可視化：讓分布式應用不再是黑盒

在最初的架構中，由于看不到任何的數據或者發布了什么服務，開發人員也并不明確每個應用具體包含什么服務，這就像一個黑盒子，所有內容都是一團迷霧。

 

EDAS在線平臺

將服務接口可視化之后，在應用啟動時將自動完成服務注冊，所發布和消費的服務可以在EDAS平臺在線查看，所有內容一目了然。

EDAS服務調用的安全性

 

EDAS服務調用結構

普通框架是沒有安全性可言的，任何人只要知道地址就可以通過服務接口隨意進行調用。為此我們針對三種維度的安全性做出了控制：在發布、訂閱和調用服務時必須使用合法的安全令牌(access key/secret key)。

• 服務提供者在服務注冊中心發布，需要權限AK;
• 服務調用者獲得服務提供者的IP，需要授權;
• 服務調用者知道IP，需要調用時，需要正確的AK。

此外，授權數據會下發到服務機器中，避免造成性能瓶頸。

EDAS應用發布

傳統集中式模式：

 

傳統的應用包下載模式

l 應用包通過中間文件服務器下載，需受限于其網絡帶寬;

l 能夠發布的機器數量較少

P2P流式應用包分發模式：

 

P2P應用包分發模式

• 通過EDAS發布控制中心下載;
• 類似P2P下載模式，可快速提供任何一個下載點;
• 支持大規模應用集群發布。

效率對比

隨著所發布的應用實例增多，兩種發布方式的效率對比如下：

 

 

兩種發布方式的效率對比

傳統集中式(黃色)：隨著發布集群規模擴大，耗時急劇增長;P2P流式：采用EDAS燎原發布系統，隨著應用實例的增加，發布的時間幾乎保持不變。

EDAS擴容

EDAS提供簡單方便高效的應用擴容服務。在傳統模式中，擴容需運維或開發人員手動布置環境、安裝GDP等等;而在P2P流式中，一鍵即可擴容，只要機器資源足夠，在EDAS平臺點擊“應用擴容”即可完成。

 

一鍵擴容界面

EDAS數據化運營

立體監控服務

 

立體監控服務

EDAS監控服務三個層面的監控數據：資源、容器和應用。

• 系統資源：負載、CPU、內存、 磁盤、網絡
• 容器：堆內存、類加載情況、線程池、連接器
• 應用：響應時間、吞吐率、關鍵鏈路分析

其中：

系統資源監控

 

系統資源監控界面

以應用/單機的視角來對基礎資源消耗進行監控：

• 可以看到應用下所有節點的平均負載
• 通過技術監控，及時發現問題
• 可以配置報警規則，有異常時快速報警

容器監控

 

容器監控界面

實時采集容器運行的監控指標，為應用運行環境問題診斷提供依據：

• 堆內存與非堆內存使用情況
• 類加載情況
• 線程運行情況
• 連接器情況

應用實時監控

 

應用監控界面

監控服務接口的調用量，分布式系統服務的承載能力等，并將其數據化：

• 監控所有服務接口、方法的實時調用情況，調用鏈的實時查詢
• 快速感知系統流量變化，找出系統瓶頸
• 執行實時鏈路分析

服務綜合治理

分布式應用的難點在于集成分布式應用一體化監控、數據化運營以及高效的服務治理。其中，服務有兩種角色，服務提供者以及鏈路負責人。

服務提供者關心：

誰調用了我的服務? 在什么鏈路下調用，調用是否合理?調用趨勢怎樣?產生的瞬間峰值有多少?我的系統是否能支撐，是否需要擴容。

所能采取的應對措施：分組、限流、鑒權、壓測。

鏈路負責人關心：

我依賴了哪些應用、哪些服務? 整個鏈路的依賴路徑是怎樣的?哪些容易出錯，哪些是鏈路的處理瓶頸? 這些依賴如果出錯，會有什么影響?

所能采取的應對措施：捕獲異常;降級：對于不穩定的服務，是否需要降級;開關：系統壓力很大的話，需要關閉不必要的操作;優化：利用服務治理，對瓶頸進行優化。

鷹眼監控

 

鷹眼監控界面

阿里鷹眼監控平臺能夠提供應用的響應時間和吞吐量信息，并提供全鏈路分析功能，從而找出系統熱點和瓶頸：

• 完整記錄所有故障
• 準確定位故障源

所解決的問題：在開發者參差不齊的情況下，快速完成上層業務目標，完成開發任務;提供透明化的觀察方式：快速找出對依賴的壓力、易故障點與瓶頸點。

 

快速找出對依賴的壓力、易故障點與瓶頸點

容量壓測

 

容量壓測界面

自動計算前端的關鍵請求與后端機器數量的對應關系，針對機器是否需要加減進行預測：

• 在真實線上的環境基礎上，通過調整服務器權重，真實模擬壓測情況，評估單機的最大服務能力，從而提供吞吐能力數據以供性能優化參考;
• 用自動化平臺，相對科學的精確手段將服務能力數據化;

限流降級

容量是任何一個系統天然存在的上限。客觀上講，不管性能如何，都有可能在業務上超出預期容量。

限流是服務接口提供方對消費方的設置，降級則是服務消費方對服務提供方的設置。通過降級設置，對服務消費方進行保護，一旦超過某個時間，便允許強行斷開。通過現有的能量對服務提供方進行保護，在出現超過流量最大能力的時候斷開，避免將系統整個拖垮。

彈性伸縮

 

 

擴容界面

應用擴容規則和縮容規則一站式設置：根據CPU、LOAD、RT三個指標設置應用的自動擴容或縮容。

EDAS配置推送

 

大型分布式系統應用配置推送

• 對大型分布式應用配置進行集中管理：修改更容易，通知更及時，配置變更也更安全;
• 對應用配置變更進行歷史記錄：讓應用配置可以輕松回退到前一版本;
• 追蹤應用配置推送軌跡：讓配置推送所到達機器變得可視化;
• 應用集群推送的規模更大、效率更高。

EDAS灰度系統

 

EDAS灰度系統

能夠允許一部分用戶使用新功能，一部分用戶使用原有功能，再通過實際測試作出最正確的決定。在業務系統層面，讓現有的系統可以平滑升級。http://click.aliyun.com/m/24591/

EDAS——世界級優秀PAAS平臺

 

應用客戶案例

• 適用于各行各業;
• 高性能、高彈性、高容錯;
• 打造以應用為中心的平臺服務，讓開發人員專注于業務邏輯;
• 構建360度的應用運維服務平臺，集成各種運維管控工具。