阿里雲王牌架構師一問開發者：系統要改形成微服務嗎

摘要： 最近你們都在談微服務，隨着愈來愈多的在線業務須要提供更大併發的scale-up 和 scale out能力，微服務確實提供了比較好分佈式服務的解決方案。

阿里雲高級解決方案架構師 楊旭

世界最大混合雲的總架構師，4年前，開始做爲雙11阿里雲技術負責人，負責搭建全球最大的混合雲結構，把 「雙11」的電商業務和技術場景在阿里雲上實現，並保障這個混合雲在雙11當天可以知足全球客戶的購物需求。

正文：

最近你們都在談微服務，隨着愈來愈多的在線業務須要提供更大併發的scale-up 和 scale out能力，微服務確實提供了比較好分佈式服務的解決方案。

微服務並不陌生，知道SOA其實也就很容易理解微服務，能夠把微服務當作去除了ESB的SOA。ESB是SOA企業服務架構中的總線，而微服務是去中心化的分佈式軟件架構，我的認爲最大的設計區別在於設計初衷：

1. SOA是爲了最大化的實現複雜系統代碼的可複用性
2. 而微服務是爲了最大限度的解耦，不一樣業務系統甚至能夠是不一樣語言之間的通訊

沒有最優的架構，只有最合適的架構，一切系統設計原則都要以解決業務問題爲最終目標，脫離實際業務的技術情懷架構每每會給系統帶入大坑。全部問題的前提要搞清楚咱們今天面臨的業務量有多大，增加走勢是什麼樣，並且解決高併發的過程，必定是一個按部就班逐步的過程。

網上的一張圖很經典，總結的很是好：

整個系統進化分爲三個階段：

x軸，水平擴展階段，經過負載均衡服務器不斷的橫向擴充應用服務器，水平擴展最重要的問題是須要注意不用服務器之間的如何保持session和會話同步，不能讓用戶在不通服務器之間切換時有感知應用擴展後天然遇到的問題就是DB的瓶頸：鏈接數，iops等。

z軸，就是對數據庫的拆分，難度上了一個臺階，Sharding的基本思想就要把一個數據庫如何進行切分，能夠分爲水平切分和垂直切分，水平切分相對簡單，一主多從，多主均可以，根據業務的須要，多主切分設計時須要注意主鍵的關係，解決多寫在進行數據同步時候的衝突問題，垂直拆分更加複雜，通常都會涉及到架構邏輯的改造，須要引入中間件，來進行數據源的管理，垂直拆分時把關係緊密（好比同一模塊）的表切分出來放在一個庫上，或者經過hash進行拆分，從而將原有數據庫切分紅相似矩陣同樣能夠無限擴充的隊列。

y軸擴展，最後就是功能分解了，也就是咱們講的微服務切分。微服務拆分將巨型應用按照功能模塊分解爲一組組不一樣的服務，淘寶的系統當年也經歷了這樣的過程，經過五彩石項目從單一的war包拆分紅了今天的你們看到買家，賣家中心，交易等系統。

引入微服務前你要知道的兩三事：

一、成本升高，引入微服務架構，須要對原來單一系統進行拆分，1到100之後多服務的部署會帶來成本的升高

二、解決分佈式事務一致性問題

之前單一的系統好處不少，一條sql解決完成全部業務邏輯，微服務作完一件事情須要涉及多系統調用，系統間網絡的不肯定性給結果帶來不少不肯定性，現在天淘寶的系統，完成一次交易下單須要在上百個系統之間調用，如何保證系統的可靠性，以及核心數據如錢的最終一致性是設計之初就要想明白的，這裏大多都要藉助中間件來實現。

三、微服務的邏輯設計原則

隨着不斷拆分微服務，以及業務的迭代發展，系統之間極有可能出現混亂調用，因此微服務的頂層設計顯得尤其重要，架構師須要搞清楚微服務的架構模型。那核心的設計思想就在於如何進行服務的分層，以及服務的重用，經過分層將服務進行分配，上層服務包裝下層服務，下層服務負責原子性的操做，上層服務對下層服務進行業務性的組合編排，必定要理解業務，微服務拆分不是簡單的系統組合，再說一遍必定要理解業務，不然上層服務必定會出現大量的交叉調用，系統複雜度會指數級上升，好的微服務架構師必定是業務架構師，基於業務的建瓴，微服務設計三部曲，遵循自下而上的設計原則：

原子服務

首先確認最基本業務最維度的原子服務，原子服務定義就是你們都會最大化重用的功能，須要在應用內的閉環操做，沒有任何跨其餘服務的分支邏輯，杜絕對其餘服務的調用，有本身獨立的數據存儲，做爲最底層服務抽象存在，以淘寶爲例，賣家數據，賣家數據，訂單數據就屬於最基本的原子服務。

服務組合

在業務場景下，一個功能都須要跨越多個原子服務來完成一個動做。組合服務就是將業務邏輯抽象拆成獨立自主的域，域之間須要保持隔離，服務組合會使用到多個原子服務來完成業務邏輯，如淘寶的交易平臺會調用用戶，商品，庫存等系統。

業務編排

最外層就是面向用戶的業務流程，一個產品化的商業流程須要對組合服務進行邏輯編排來完成最終的業務結果，這個編排服務能夠徹底是自動化的，經過工做流引擎進行組合自動化來完成特定SOP定義，這對企業應用的自動化流程改進也頗有意義。如淘寶類目的雙十一活動，經過對不通服務組合進行重用實現不通的營銷活動邏輯。

四、運維管理的複雜度提高

微服務讓應用數量增長不少，鏈路的集成、測試、部署都成爲新的挑戰，之前一個war包解決的問題，須要經過多應用發佈來完成，發佈時服務之間的依賴影響，會致使功能不可用，測試階段的依賴性可能會讓用例跑不下去，這些都會是須要新考慮的問題，須要有平臺化的工具來支撐，目前阿里經過aone產品來保證從平常到預發到線上的持續集成交付。

實踐：

目前不少微服務經過DevOps和Docker來落地， 也能夠藉助雲上FAAS平臺來實現，如AWS的Lambda，阿里雲的Bazaar，均可以把Function發佈成一個Service，結合雲效系統來進行服務整個生命週期的編排，能夠極大的提升工程效率，實現應用微服務。

更多幹貨內容盡在阿里雲總監課，戳連接報名：http://click.aliyun.com/m/100...

阿里雲總監繫列課重磅上線！聚焦人工智能、彈性計算、數據庫等熱門領域，首次集齊12位阿里雲技術高管，耗時半年精心打磨，從理論到實踐傾囊相授，從零開始繪製技術大牛成長路徑，限時直播課程免費報名中！

本文做者：雲攻略小攻

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。