本文主要從高速增長的阿裡業務開始談起，講述當年面對的業務場景和背景，碰到了什麼樣的技術挑戰，且用什麼樣的思路去解決它，最後和大家分享了解決後産生的産品aliware中非常重要的edas。
以下是演講内容整理：
高速業務增長帶來的挑戰
大型電子商務平台吸引了大量賣家和買家，圖為2014年ipo時候截得的圖，可以看到在阿裡上有10億多件商品等，現在仍然以非常高的速度在增長。
圖為2003年到2010年淘寶網注冊使用者數，使用者數從非常低的值逐漸漲到近40000萬人，這些使用者突然來到我們的網站，就會給網站非常多的通路壓力。2003年到2006年我們主要是想盡方法以業務為核心積累技術，到後來網際網路人群在高速增長，整個體系面臨的技術挑戰就會非常多，具體有以下四點：
業務需求爆發式增長
開發人員快速擴張
系統代碼量越來越多
系統壓力越來越大
綜合來看，一個技術性網站最重要的技術挑戰在于考慮業務的高速增長、使用者數量的高速增長導緻下層原來看不見的問題變成了新的問題。
挑戰與解決之道
阿裡前期技術團隊規模500人左右，單一war應用，是以php為核心建構的系統，php+mysql+linux+apache标準的lamp的系統架構，後來逐漸用一些開源的技術替換掉了原來的商業産品，随着業務的不斷發展，不斷的把新的代碼加入到系統中，我們研發了一套分布式存儲架構，搜尋也是自己建構的。
<b>技術問題</b>
随着技術快速增長和演進，随着人員的增加，我們發現很多嚴重的問題展現出來。
<b>業務支援緩慢，牽一發而動全身</b>
很多人同時維護一個核心工程，不同人有不同的了解，會導緻源代碼沖突嚴重，很難做項目管理，協同成本非常高，進而項目釋出周期就會很長，疊代速度變慢，且錯誤難以隔離。
<b>資料庫能力達到上限</b>
隻有一個資料庫的問題是很大的，釋出一個新的系統可能會導緻當機，由于資料庫裡本身的索引建錯了，建錯是因為庫是重建的，oracle的索引重建機制還沒有來得及更新柱狀圖。是以，隻有一個oracle資料庫時，連接配接數捉襟見肘，單機iops達到瓶頸，cpu 90%以上，每年當機最少一次。
<b>資料孤島</b>
多套使用者體系導緻使用者不知道到底在哪個網站登入，我們想知道使用者的畫像，分析使用者的購買行為，但兩個不同網站的相同使用者名不确定是否為同一使用者，是以沒辦法進行後續的大資料分析。随着系統越來越多，我們發現大量的使用者在系統出現時，比如查詢使用者的方法，在不同的業務系統裡出現多次，每一次都不完全一樣，資料隔離、重複建設，資料不一緻，這是項目管理和代碼管理的亂象。
基于edas進行服務化改造
沒有任何服務化的經驗去借鑒，我們隻能一步一步的摸着石頭過河。我們做了幾個關鍵性的努力，首先是使用者中心遷出，從一個大的系統裡拆出一小塊放到外面，這就是使用者中心，使用者中心是一個比較簡單純粹的處理使用者登入的系統，當時在内部就有六、七種登入方式，我們把這些方式全部代理出來，變成一個單獨的服務中心。如果我們不把系統代碼進行革新，就沒有辦法支撐，緊接着，我們就開始做自己的中間件的研發，千島湖項目産生時，edas、mq、drds就随着它一步步的演進到現在。交易中心是整個系統裡最複雜的業務流程，幾乎和所有業務系統有關聯，當它用一些中間件完成整個系統的突破時，我們就可以認為看起來中間件和應用都準備好了。接着我們進行了第三個五彩石項目，商城和淘寶各有一套購買流程，我們需要用edas進行服務化改造，把這兩套流程融合到一起，使之能同時支撐兩個不同的出口，完成下一步的延伸。
<b>服務化以後的架構演進</b>
服務化以後，開始時業務應用很少，随着系統往下延伸，很多人開始做服務化系統，服務之間也會進一步的複雜，進而會形成一個複雜的網狀結構，那麼，依賴很多，如何進行準确的梳理呢？
當系統變成網狀結構後，一定會有一些業務系統是重要業務，一些業務系統是非重要業務，這些非重要業務突然出現小的故障時，整個系統就會當機，我們成立了穩定性小組進行業務梳理，以交易流程為核心，哪些系統劃成重要系統，哪些系統為非重要的業務系統，但是，系統在不斷的變化，我們沒有辦法準确知道每一次變化後它的依賴關系是怎樣的，很難進行梳理，必須通過系統的方式來解決問題。
<b>鷹眼系統</b>
我們把整個系統現象成一個高速公路的路網，流量進來就如同行駛的汽車，如何能夠知道汽車從哪裡進來又從哪裡出去呢？在高速公路上做很多的關卡，這樣可以準确的追蹤到所有連接配接的道路和通信，這樣，哪裡有問題都可以通過非常簡單的方式得到檢測，而這個檢測對于發現和解決問題是非常簡單的一件事，才有可能擺脫在服務化以後，複雜的系統運維和管控。
阿裡經過驗證的件——edas
<b>高性能服務架構</b>
edas是一個高性能的服務架構，edas是由很多技術體系組成的一個整體包，如果想寫一個web應用，使用這個開發套件，所有在業務開發需要的功能都內建在裡面，所有和業務中間件相關的應用也內建到裡面了，最關鍵之一就是hsf，hsf在阿裡90%以上應用上使用，相對比較成熟，支援分布式事務，經曆過七次雙十一大促的考驗，日均有千億級的調用量。
同時，我們也支援dubbo，dubbo也是阿裡開發出來的市面上應用非常廣泛的開源軟體，已經有4000多個開源分支。
<b>分布式事務</b>
在服務架構之上，還有分布式事務，在分布式應用裡應該怎樣完成單機應用中常見的一些事務操作呢？此時就需要使用分布式事務元件，它能夠将服務和服務之間多個不同庫之間的資料集中到一起去，進而提供一個整體的服務能力，看起來像寫單機業務系統一樣去寫分布式事務服務架構。去中心化服務化架構，隻是一個簡單的開始。
<b>分布式配置管理</b>
可以在網站查詢配置哪些機器收到、哪些機器沒有收到，毫秒級推送，可以變更曆史記錄，推送軌迹追蹤等。
<b>立體化監控服務</b>
資源+容器+應用 = 立體化監控服務
監控是我們非常關注的事情，對于系統整體的性能名額也非常重要，是以，我們會嘗試從不同層面收集資訊，具體包括以下三大方面：
系統資源：負載，cpu、記憶體、磁盤、網絡
容器：堆記憶體、類加載、線程池、連接配接器
應用：響應時間、吞吐率、關鍵鍊路分析
<b>容器監控</b>
容器監控要監控堆記憶體與非堆記憶體使用情況，類加載情況（對于排查線上啟動問題非常友善），線程運作情況，連接配接器情況。
<b>應用監控</b>
應用監控主要從服務接口、方法的實時調用情況進行分析，以及調用qps、響應時間分析，
快速感覺系統流量變化，進而讓我們知道系統的問題所在。監控和報警在這裡得到很好的展現，但這僅僅算是剛剛進階。
<b>edas</b><b>鷹眼跟蹤</b>
鷹眼監控就是解決内部非常複雜的多樣鍊路的時候，怎樣進行持續的收集、跟蹤、統計，以幫助我們進行鍊路梳理的工具。比如從前面開始調用鍊路時有哪些異常，出現故障的地方都可以從這個調用鍊路上得到展現。
同時，通過海量調用鍊進行統計分析，得到鍊路各個依賴的穩定性名額。比如，某個地方的qps很高，但這個系統不該有這麼高的qps，就可以認為這是一個依賴壓力問題。
除了鍊路分析功能，edas還有容量規劃的重要功能。通過線上真實引流到系統内進行壓測分析，然後根據設定的運作水位計算系統承載的最高容量，進而到最後可以實作機器按需的上線和下線，把這些系統融會貫通在一起，就是整體的容量規劃提供的功能。
<b>edas</b><b>限流降級</b>
限流降級是阿裡最有特色的功能之一，我們會面對非常強大的挑戰就是雙十一網購狂歡節，我們需要在成本和體驗中選擇一個好的平衡點，要利用這個平衡點我們必須要保證系統的可用性，不能因為使用者多導緻系統無法服務，就像排隊買票一樣，我們需要對自己的系統進行優化，具體表現在一下兩方面：
限流：針對非核心服務調用者限制請求量
降級：針對系統的非核心服務依賴
<b>應用釋出和管理系統</b>
以前是集中化的釋出方式進行管理的，這對于一、二百台機器是沒有問題的。然而，現在需要同時釋出五、六百台機器甚至更多，釋出就會成為瓶頸。對此，我們内部引入edas燎原p2p釋出系統，它能夠讓系統内進行p2p多點式的多host釋出，使整個系統的應用釋出能力得到快速提升。
edas燎原實作超大規模叢集閃電釋出，圖中可以看出釋出耗時随着機器數量增加變化趨勢。采用edas燎原釋出系統，随着應用執行個體的增加，釋出的時間幾乎保持不變。有利于進行緊急釋出時候的業務處理，實作快速復原。
<b>阿裡十年技術精華沉澱</b>
綜合來說，edas并不是簡單的服務化工具，它希望在整個應用的編寫周期裡都可以進行操作，是以它結合了hsf、鷹眼、燎原等等。現在，它在公有雲和專有雲裡都有輸出。
阿裡巴巴核心技術架構
自主創新走出技術困境，沉澱一大批成熟中間件技術；
共享服務體系打破應用“煙囪式”建設方式，支撐業務快速創新；
雲化基礎架構高效支撐業務增長，靈活的彈性伸縮帶來巨大的成本節約。