摘要：?最近大家都在談微服務，隨著越來越多的在線業務需要提供更大并發的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、成本升高，引入微服務架構，需要對原來單一系統進行拆分，1到100以后多服務的部署會帶來成本的升高**

2、解決分布式事務一致性問題

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

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

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

原子服務

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

服務組合

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

業務編排

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

4、運維管理的復雜度提升

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

實踐：
目前很多微服務通過DevOps和Docker來落地， 也可以借助云上FAAS平臺來實現，如AWS的Lambda，阿里云的Bazaar，都可以把Function發布成一個Service，結合云效系統來進行服務整個生命周期的編排，可以極大的提高工程效率，實現應用微服務。

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。