摘要：?最近大家都在談微服務，隨著越來越多的在線業(yè)務需要提供更大并發(fā)的scale-up 和 scale out能力，微服務確實提供了比較好分布式服務的解決方案。

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

世界最大混合云的總架構師，4年前，開始作為雙11阿里云技術負責人，負責搭建全球最大的混合云結構，把 “雙11”的電商業(yè)務和技術場景在阿里云上實現(xiàn)，并保障這個混合云在雙11當天能夠滿足全球客戶的購物需求。

正文：

最近大家都在談微服務，隨著越來越多的在線業(yè)務需要提供更大并發(fā)的scale-up 和 scale out能力，微服務確實提供了比較好分布式服務的解決方案。

微服務并不陌生，知道SOA其實也就很容易理解微服務，可以把微服務當做去除了ESB的SOA。ESB是SOA企業(yè)服務架構中的總線，而微服務是去中心化的分布式軟件架構，個人認為最大的設計區(qū)別在于設計初衷：

1. SOA是為了最大化的實現(xiàn)復雜系統(tǒng)代碼的可復用性

2. 而微服務是為了最大限度的解耦，不同業(yè)務系統(tǒng)甚至可以是不同語言之間的通信

沒有最優(yōu)的架構，只有最合適的架構，一切系統(tǒng)設計原則都要以解決業(yè)務問題為最終目標，脫離實際業(yè)務的技術情懷架構往往會給系統(tǒng)帶入大坑。所有問題的前提要搞清楚我們今天面臨的業(yè)務量有多大，增長走勢是什么樣，而且解決高并發(fā)的過程，一定是一個循序漸進逐步的過程。
網(wǎng)上的一張圖很經(jīng)典，總結的非常好：

整個系統(tǒng)進化分為三個階段：

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

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

y軸擴展，最后就是功能分解了，也就是我們講的微服務切分。微服務拆分將巨型應用按照功能模塊分解為一組組不同的服務，淘寶的系統(tǒng)當年也經(jīng)歷了這樣的過程，通過五彩石項目從單一的war包拆分成了今天的大家看到買家，賣家中心，交易等系統(tǒng)。

引入微服務前你要知道的兩三事：
**
1、成本升高，引入微服務架構，需要對原來單一系統(tǒng)進行拆分，1到100以后多服務的部署會帶來成本的升高**

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

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

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

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

原子服務

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

服務組合

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

業(yè)務編排

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

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

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

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

原文鏈接

本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。