關于Aliware
Aliware是阿里巴巴中間件技術品牌，包含5個中間件產品，主要是：EDAS、DRDS、MQ、ARMS、CSB。Aliware從2007年開始，經歷了8年多的雙11大促，每次大促都能使產品體系更上一個臺階。像JStorm、Dubbo、Rocketmq等等一系列的開源產品，無論在GitHub還是Apache這些頂級項目上，都是非常火的項目。
服務化緣起
在2007年的時候，阿里技術研發團隊大概是500人左右，主要業務是淘寶網站點，都是都在一個單一的WAR包進行部署，基于傳統JAVA EE應用開發架構，使用的是Oracle數據庫和JBoss服務器。當時整個淘寶網就是兩個WAR包，一個是前臺的，就是淘寶網；還有一個是后臺的CRM系統，是給所有的客戶支持人員使用的。
在當時那個階段，我們面臨著非常多的問題：第一個問題，是系統的研發成本非常高。
首先，上百人維護一個核心工程，源代碼沖突嚴重，協同成本極高。淘寶網當時是單獨的一個WAR包，在運行的時候，就是一個工程，都是一份代碼。無論是以前的SVN，還是今天用了Git等一系列工具，代碼沖突的問題是逃不掉的。
其次，項目發布周期太長。當年的淘寶網，是一個煙囪式的網站。它底層就是一個數據庫，然后上層是所有業務邏輯的一個DAO層，專門負責訪問數據庫，再上層可能是業務層。所有模塊的邏輯都在一個系統里面，都在一起部署。這樣會因為某幾個模塊的開發效率低，影響整個站點的發布。
然后，錯誤難以隔離。這個是當時比較致命性的問題。比如說一個大的活動，我如果對時間的一個模塊或者其中的一個if判斷邏輯進行一些變更的話，整個活動頁面會出問題，會導致整個站點都不可用。
第二個問題，是數據庫能力達到上限。
淘寶早期是用oracle數據庫，單機的oracle數據庫連接數捉襟見肘，單機IOPS達到瓶頸，每天數據庫CPU90%的負載運轉，每年Down機最少一次。
第三個問題，是數據孤島。
當時淘寶、天貓、聚劃算，萬網等業務系統之間，數據是完全隔離的，數據不一致，無法復用，賬號不統一，不能進行關聯推薦，也無法進行大數據分析。
微服務架構的形成
在這三大問題出現之后，淘寶網開始做一些服務化探索。從2007年開始，進行了一些微服務架構改造。
RPC框架：微服務架構的核心基礎
在阿里內部做服務化的最底層、最核心的是兩個框架，首先是Dubbo框架。Dubbo框架2010年誕生，2011年對外開源。現在阿里發展到了第三代RPC框架，在內部代號叫HSF的框架，目前90%以上的應用，都在使用這樣一個框架。每年雙11大促也在用。
消息隊列：異步調用實現系統解耦
前面說到的RPC框架，重點是幫助我們解決，一個網站在進行服務化拆分的時候，各個模塊之間的聯系，需要通過RPC框架來進行一個同步化的調用，那么還有一些場景，它其實是不需要同步化調用的，是可以用異步去解決。
比如淘寶網平臺上的手機充值業務，看似是一個串行的充值流程，其實可以通過異步結構來解決。首先，通過同步調用幫助用戶確保他的下單在電商平臺已經完成；其次，通過消息組件進行異步解耦，使得那些耗時長的不是核心鏈路的一些東西，能夠不占據消費者在使用網站、App上面的主流程時間，優化用戶體驗。
基于此，我們消息中間件主要會去解決三大類的問題。
第一個是可靠同步，它的消息是可靠并且有序的，這是在所有需要穩定性、提高交易鏈路上用到的。第二個是可靠異步，當有穩定性的訴求，也有吞吐量訴求的時候，可以采用異步的這些邏輯，通過異步反饋，讓消息中間件反復去投遞，確保穩定性。最后一個是單向，不關注穩定性，只關注吞吐量是否大。
大規模配置推送
在進行服務化拆分之后，需要將每一個服務使用的配置進行集中式管理。因此，我們研發了可靠的配置推送服務，能夠在毫秒級時間內完成配置推送，同時支持變更歷史記錄和推送軌跡的查詢。
立體化監控
監控是我們非常關注的事情，對于系統整體的性能指標也非常重要，所以，我們會嘗試從不同層面收集信息，實現對應用立體化的監控，包括資源、容器和服務，具體包括以下三大方面：
系統資源：負載，CPU、內存、磁盤、網絡
容器：堆內存、類加載、線程池、連接器
服務：響應時間、吞吐率、關鍵鏈路分析
服務監控
當原本在集中式的系統架構里面，每個頁面會貫穿非常多的模塊，每個模塊都耦合在一個系統中，最終監控出的是表象，無法知道頁面打開慢是哪個模塊哪個功能邏輯上慢?，F在，我們會對每一個服務接口、方法的實時調用情況進行監控，能夠細致地將每一個服務的生命周期，每一個服務運行時的監控指標非常細化的監控出來，還會調用QPS、響應時間進行統計，同時快速感知系統流量變化。
淘寶網圍繞EDAS技術體系進行了一整套的服務化改造，在這個改造過程中，首先將數據復用度最高的數據進行拆分，剝離出用戶中心這樣的共享型的服務層，對上層所有業務進行用戶相關的所有邏輯，接下來又陸續有千島湖項目、五彩石項目，這些項目的背后都是一系列的服務化中心拆分出來的產物，后來經過6-7年的服務化演進，目前服務中心數已達50多個。
自主創新走出技術困境，沉淀一大批成熟中間件技術，最底層為共享型中間件和組件，以及阿里云沉淀下來的技術支撐型產品；共享服務體系打破應用“煙囪式”建設方式，支撐業務快速創新；云化基礎架構高效支撐業務增長，靈活的彈性伸縮帶來巨大的成本節約。
大規模服務化挑戰
隨著服務化的拆分，所有的系統會變得越來越多，箭頭指向就是底層的服務化中心，上層調用過來就是前端的業務系統。很多系統調用很多的服務中心，這時已經沒有架構師能夠人為的幫助我們進行服務依賴和架構梳理。
EDAS鷹眼監控系統
我們在排查一些線上問題的時候，其實不要求說能夠非?？焖僦悄芑膸臀胰ソ鉀Q問題，只要有這樣一套系統能夠幫我快速的去定位問題就可以，于是阿里內部做了EDAS鷹眼監控這樣一個系統。
圖中從上至下可以看出，鷹眼監控系統能夠非?？焖俚亩ㄎ还收显谀睦?，并且通過可視化的手段，能夠在系統上面發現是由于哪臺機器上的哪一段日志導致的。這是鷹眼監控做的第一個事情。
鷹眼監控做的第二個事情是什么呢？當我們把類似的請求調用鏈路全部匯總起來進行分析后，就可以在很短時間內進行數據采集，并且有數據化的運營出來。峰值的QPS是指今天在某一個業務高峰時，某一個業務的服務，在分鐘級別的服務化的調用過程中，達到的最大的QPS。如圖中標記可以看出，即使頁面暴露在最前端，但不一定是壓力最大的，這就算數據可視化帶給我們的價值。我們還要對數據進行決策上的幫助，數據最大的價值在于可以精準化的通知我們最大壓力點。
某個頁面打開經過一系列的系統調用時，總會在某一個點出現問題，稱之為易故障點。我們可以直觀的看到在過去的一天里，到底所有的請求在哪一個組件的出錯率最高，就可以針對性的解決。
EDAS容量規劃
阿里內部如何去做一些容量性的一些規劃？首先我們會去制造一些流量，通過真實流量壓測部分單機性能，然后根據設定的運行水位計算系統承載的最高容量，從而到最后可以實現機器按需的上線和下線，把這些系統融會貫通在一起，就是整體的容量規劃提供的功能。所有的壓測在單機上都會定一些指標,當我們進行集群中把一半機器流量全部引到另一半時候，所有流量的QPS就會翻倍，當單機性能如果沒有達到運行水位時，就會繼續引流，直到達到指標為止。
EDAS限流降級
在整個雙11期間，在不同的時間點，我們所面臨服務的核心和非核心是不一樣。比如在雙11零點的時候是流量高峰，基本上來自于所有的支付環節，因此在那個階段，我們要把所有的資源全部傾向于交易、傾向于支付。而到了第二天早上起床的時候，物流服務會成為核心。今天我們會從業務的角度，去發現網站的核心和非核心。EDAS里面會有一個可視化的配置界面，去幫助你在某個階段，哪個服務是核心服務，那么這個核心服務能夠去調用更多的底層資源，但在其它點的時候，它就會被限流住。
