579
微服務架構如何實現網站服務垂直化拆分
3月10日，2017阿裏雲網站行業熱點問題和解決方案線下研討會在上海舉行。阿裏雲產品專家銀時為大家帶來《微服務架構如何實現網站服務垂直化拆分》精彩演講。主要從服務化的緣起、微服務架構的形成，以及在大規模的服務化過程中所麵臨的一些挑戰以及解決方案，跟大家分享整個微服務。
以下內容根據現場分享和講師PPT整理而成。
關於講師：
倪超，阿裏花名銀時，阿裏巴巴企業互聯網架構平台產品專家、國家認證係統分析師、IT暢銷書作者，著有《從Paxos到ZooKeeper》一書，2015年國內新書暢銷榜Top10。2010年，以實習生身份加入阿裏，入職中間件技術團隊，經曆了阿裏中間件技術從1.0到3.0的變革，目前負責商用軟件EDAS。
關於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、內存、磁盤、網絡
容器：堆內存、類加載、線程池、連接器
服務：響應時間、吞吐率、關鍵鏈路分析
服務監控
當原本在集中式的係統架構裏麵，每個頁麵會貫穿非常多的模塊，每個模塊都耦合在一個係統中，最終監控出的是表象，無法知道頁麵打開慢是哪個模塊哪個功能邏輯上慢。現在，我們會對每一個服務接口、方法的實時調用情況進行監控，能夠細致地將每一個服務的生命周期，每一個服務運行時的監控指標非常細化的監控出來，還會調用QPS、響應時間進行統計，同時快速感知係統流量變化。
淘寶網圍繞EDAS技術體係進行了一整套的服務化改造，在這個改造過程中，首先將數據複用度最高的數據進行拆分，剝離出用戶中心這樣的共享型的服務層，對上層所有業務進行用戶相關的所有邏輯，接下來又陸續有千島湖項目、五彩石項目，這些項目的背後都是一係列的服務化中心拆分出來的產物，後來經過6-7年的服務化演進，目前服務中心數已達50多個。
圖為阿裏巴巴核心服務化架構。自主創新走出技術困境，沉澱一大批成熟中間件技術，最底層為共享型中間件和組件，以及阿裏雲沉澱下來的技術支撐型產品；共享服務體係打破應用“煙囪式”建設方式，支撐業務快速創新；雲化基礎架構高效支撐業務增長，靈活的彈性伸縮帶來巨大的成本節約。
大規模服務化挑戰
隨著服務化的拆分，所有的係統會變得越來越多，箭頭指向就是底層的服務化中心，上層調用過來就是前端的業務係統。很多係統調用很多的服務中心，這時已經沒有架構師能夠人為的幫助我們進行服務依賴和架構梳理。
EDAS鷹眼監控係統
我們在排查一些線上問題的時候，其實不要求說能夠非常快速智能化的幫我去解決問題，隻要有這樣一套係統能夠幫我快速的去定位問題就可以，於是阿裏內部做了EDAS鷹眼監控這樣一個係統。
圖中從上至下可以看出，鷹眼監控係統能夠非常快速的定位故障在哪裏，並且通過可視化的手段，能夠在係統上麵發現是由於哪台機器上的哪一段日誌導致的。這是鷹眼監控做的第一個事情。
鷹眼監控做的第二個事情是什麼呢？當我們把類似的請求調用鏈路全部匯總起來進行分析後，就可以在很短時間內進行數據采集，並且有數據化的運營出來。峰值的QPS是指今天在某一個業務高峰時，某一個業務的服務，在分鍾級別的服務化的調用過程中，達到的最大的QPS。如圖中標記可以看出，即使頁麵暴露在最前端，但不一定是壓力最大的，這就算數據可視化帶給我們的價值。我們還要對數據進行決策上的幫助，數據最大的價值在於可以精準化的通知我們最大壓力點。
某個頁麵打開經過一係列的係統調用時，總會在某一個點出現問題，稱之為易故障點。我們可以直觀的看到在過去的一天裏，到底所有的請求在哪一個組件的出錯率最高，就可以針對性的解決。
EDAS容量規劃
阿裏內部如何去做一些容量性的一些規劃？首先我們會去製造一些流量，通過真實流量壓測部分單機性能，然後根據設定的運行水位計算係統承載的最高容量，從而到最後可以實現機器按需的上線和下線，把這些係統融會貫通在一起，就是整體的容量規劃提供的功能。所有的壓測在單機上都會定一些指標,當我們進行集群中把一半機器流量全部引到另一半時候，所有流量的QPS就會翻倍，當單機性能如果沒有達到運行水位時，就會繼續引流，直到達到指標為止。
EDAS限流降級
在整個雙11期間，在不同的時間點，我們所麵臨服務的核心和非核心是不一樣。比如在雙11零點的時候是流量高峰，基本上來自於所有的支付環節，因此在那個階段，我們要把所有的資源全部傾向於交易、傾向於支付。而到了第二天早上起床的時候，物流服務會成為核心。今天我們會從業務的角度，去發現網站的核心和非核心。EDAS裏麵會有一個可視化的配置界麵，去幫助你在某個階段，哪個服務是核心服務，那麼這個核心服務能夠去調用更多的底層資源，但在其它點的時候，它就會被限流住。
在公有雲和專有雲提供商業化服務
最後更新：2017-04-19 20:58:45