注：本文為我最近閱讀《微服務架構設計模式》的一點感悟，我不準備詳細去寫對該書的讀書筆記記錄，而是結合我們自己所做的一些微服務架構實踐情況做一些總結和覆盤。

從單體應用到微服務

任何一個新的架構模式或方法的出現，一定是傳統架構模式遇到了問題。而對於單體應用來說常說的問題主要包括瞭如下幾個點。

單體應用規模太大，導致複雜度劇增，難以開發和管理

單體應用開發，交付和變更週期變長，敏捷性跟不上

單體應用本身在效能，擴充套件性上出現了問題

在軟體架構設計裡面，分而治之始終都是解決複雜性的一個關鍵思維方法。包括在傳統軟體架構設計裡面對於大系統會進行子系統或元件劃分，會進行介面設計，整合設計等。

架構的核心思維仍然是：分解+整合

但是傳統架構在分解的時候沒有做到單個元件的高度獨立自治和徹底解構。這個高度獨立自治實際上要求元件或模組從開發，設計，測試，上線執行，後期運維全生命週期都做到高度獨立；同時還要求配合的開發團隊，組織結構設計也獨立。

也正是這個原因進一步發展出了微服務架構。也就是說微服務架構實際是傳統元件化架構設計思想的進一步強化，強化的核心就是獨立和解耦。

微服務架構思想的一個重點就是單體應用的拆分。

講微服務一定會談到擴充套件立方體。

對於傳統單體應用一般來講擴充套件的方法只能是X座標軸的透過擴充套件例項方式的水平擴充套件。而另外兩個重要的擴充套件一個是功能拆分，一個是資料庫拆分。

對於功能拆分實際不是新鮮東西，在很早元件化架構設計我們就做過將不同的應用元件部署到不同的App Server伺服器上，對於應用層你只需要考慮解決類似Session會話儲存，全域性配置和分發等問題即可，不會涉及到複雜的資料持久化問題。

而真正難的是在資料庫拆分。因為資料庫拆分引入了兩個大問題，其一是分散式事務問題，其二是大量操作跨庫帶來的分散式事務問題。

資料庫為何要拆分？

在單體應用發展到一定階段後，出現的效能問題往往都是DB層面的難以解決。資料庫叢集很難做到水平彈性擴充套件，即使對於類似Oracle RAC等商用叢集軟體，本身也有效能擴充套件瓶頸。效能擴充套件到2到3倍後已經無法再擴充套件。

因此單純從擴充套件例項擴充套件來說，後面衍生了讀寫分離叢集，讀寫分離叢集在應對讀操作佔比大的業務場景下實際是最佳的一種擴充套件方式，在這種方式下資料庫本身並沒有拆分為多個例項，不會引入前面遇到的兩個大問題。只要在資料庫上搭建一個DaaS資料庫訪問中介軟體，那麼資料庫底層的這種拆分和變化完全可以做到對上層應用開發透明。

當談到這裡的時候，再來回顧一下微服務的一些核心點自然就更加清楚。

微服務是傳統單體的拆分，而且需要做到高度獨立自治

微服務的拆分不僅僅是功能拆分，更加重要是資料庫拆分

非同步和解耦是微服務架構設計的重要指導思想

微服務間透過輕量高效的Http API介面互動協同

微服務實踐需要開發組織，持續整合，測試，交付方式配套支撐

場景和問題驅動

在前面談微服務的時候我就談到過，微服務架構本身將導致開發，整合，運維複雜度全部增加。即使對於常說的高可用性，也僅僅是高可用性和彈性擴充套件能力增加，但是對於高可靠性反而是降低。

那麼一個企業或團隊是什麼原因實踐微服務？僅僅是微服務是一種架構發展趨勢，是技術熱點，是網際網路大廠都在用嗎？

而實際對於很多企業應用微服務可以看到，更多是團隊裡面總有一些技術狂熱份子，熱衷於新架構，新技術，但是對於這些技術究竟解決了哪些業務場景下的問題並不關心。這直接就導致了大量技術在不恰當的時候被應用。

並不是說微服務不好，而是說對於架構師來說應該基於業務，技術，團隊資源，成本等多個維度來綜合考慮究竟應該在什麼時候用什麼樣的技術最合適。

類似阿里的電商平臺，一天訪問量上億，接近百萬的TPS，高峰秒級成交都幾十萬筆，這種業務場景下各個模組拆分為獨立中心，獨立資料庫是必然。不是說什麼技術先進了必須使用，而是為了滿足和支撐業務必須微服務化。

那麼傳統企業實踐微服務就一定要思考微服務究竟能解決什麼問題。如果這個問題沒有想清楚就不要輕易去搞微服務。其次就是透過其他傳統方式能解決的也不要輕易去理想化的實踐微服務架構。

比如一個業務系統執行過程中資料庫出現效能瓶頸，這個時候你可以考慮的是將歷史資料進行遷移到備庫，增加備庫單據查詢能力；或者是前面談到的構建資料庫的讀寫分離叢集或者在資料庫上構建二級索引快取庫來解決效能問題。

再比如一些業務系統出現瓶頸，並不是常規的OLTP場景出現問題，而是單個業務系統資料庫同時在支撐OLTP和OLAP能力。這個時候你應該做到是將大量的查詢統計和資料分析功能移出，而不是對整個業務系統進行資料拆分。

這方面的例子還有很多，實際是想說明一點，很多業務系統的複雜度和效能問題遠遠沒有到必須進行功能拆分和資料庫拆分才能夠解決的地步。

微服務拆分策略

當聊微服務拆分的時候先談下傳統軟體架構設計裡面的元件拆分。

對於元件拆分可以看到常規的元件拆分實際是在應用層而沒有到具體的資料庫。這就導致了元件拆分後，底層資料庫仍然是一箇中心點和緊耦合點。包括元件拆分後，實際架構規劃的時候希望透過元件間透過介面呼叫協同的，後續在開發實現中往往也出現偏差，即常說的仍然是透過底層資料庫的關聯sql查詢等來解決問題。所以你看到情況是元件間並沒有什麼介面呼叫，而大量的耦合都轉到底層資料庫的耦合上面。

到了微服務階段的拆分，實際上變成了兩個重要的事情，一個是資料庫的拆分，一個是基於資料庫拆分後的功能拆分。

對於拆分我前面寫過兩篇文章可以參考：

不論是採用的是傳統的結構化分析方法，還是當前類似DDD領域驅動建模裡面的子域劃分，上下文邊界識別等。拆分的重點仍然是在資料庫拆分上面，只是DDD方法裡面將其理解為核心領域物件拆分，領域物件拆分出來自然對應的資料庫和功能都進行了拆分。

先梳理清楚邊界並進行服務拆分，再基於業務協同和業務功能實現來梳理和定義API介面，也就是說微服務拆分工作實際包括了三個方面的事情。

即資料庫拆分，功能拆分，API介面識別和定義。

對於微服務拆分來說，真正的困難點是在微服務拆分的顆粒度上，當重新讀這本書的時候再次慶幸我們沒有按書裡面這麼理想化的方法去實踐微服務，去將微服務拆分的如此細，否則真正是思路一條。

因此在這裡需要重申一個重要觀點。

微服務拆分不應該是按標準理論理想化的拆分到哪個顆粒度，而是應該根據實際的業務場景和擴充套件性需求，開發團隊管理需求拆分到一個合適的顆粒度。

比如你現在做的是一個外賣訂餐系統，如果是類似美團APP這種規模進行細粒度的微服務拆分勢在必然。但是如果你的系統面對的市場僅僅是類似社群，園區等私有云部署場景。那麼這個系統從業務場景和併發量上都沒有必要做大的微服務拆分，實際架構上進行前後端分離，獨立快取庫，讀寫分離基本完全可以解決問題。

因此微服務拆分到哪個程度，跟業務系統面對的業務場景和問題有關，而不要用標準的類似拆分方法策略去做拆分。

類似面向物件的分析設計，DDD領域驅動和領域物件分析識別，這些方法都沒有問題，這些完全可以應用到應用內部，應用內部也需要元件化拆分，而不是說元件化後每個元件就必須拆分為獨立的高度自治的微服務。

從API介面到非同步解耦

對於微服務架構中的API介面設計，在前面我專門寫過文章來進行描述。在這裡還是想重新來說明對API介面設計和暴露裡面的兩個重要觀點。

對Http Rest API標準規範的理解

要知道Rest API更多的是一種面向資源的API介面設計方法。在早期我自己也堅持一個觀點即需要安裝理想化的Rest介面設計方法來設計介面。但是當前我更傾向於僅僅將Http API作為介面實現方式，是否Rest風格並不是重點。

即在介面實現中完全可以將所有介面實現POST介面方法，而不用去區分哪些必須用GET，哪些還得用PUT方法。雖然都實現為POST方法後會對一些介面的線上訪問和測試帶來一些不方便，但是這個完全可以透過其它方式去解決掉。

前後端分離和大量API介面暴露

API介面本身應該是粗粒度的，但是實際在很多專案裡面看到往往將資料庫表的CRUD方法全部暴露為了API介面方法。這個一方面是領域物件層的貧血，一個是前後端分離導致原來資料訪問層的內部API介面全部都需要透過Http API介面方式暴露。

一個內部的IT系統，本身僅僅內部區域網使用，只提供PC端的BS瀏覽介面也沒有對APP端的支撐需求，在這種情況下前後端分離沒有任何必要。前後端分離反而帶來了後端API介面大量暴露，前端和後端整合協同等大量問題。

在這種場景下如果IT系統劃分為5個微服務模組，這5個微服務模組之間的API介面設計和整合，才是我們真正需要去關注的問題點。

在當前微服務架構設計裡面，微服務間的介面協同，微服務本身前後端介面協同全部混雜在一起，實際導致了後續整個微服務體系裡面的API管控治理完全失控。

基於Saga分散式事務

前面談分散式事務的時候，更多談的是事物補償或者事務最終一致性保障，但是很多長週期的事務仍然是API介面的同步呼叫方式來實現。即當API介面同步呼叫的時候，微服務間並沒有徹底解耦。要解耦必須是基於事件或訊息模式的非同步呼叫方式。

Saga即是一種非同步訊息事件機制下的分散式事務解決方案。Saga是由一系列的本地事務構成。每一個本地事務在更新完資料庫之後，會發布一條訊息或者一個事件來觸發Saga中的下一個本地事務的執行。如果一個本地事務因為某些業務規則無法滿足而失敗，Saga會執行在這個失敗的事務之前成功提交的所有事務的補償操作。

Saga的實現有很多種方式，其中最流行的兩種方式是：

基於事件的方式。這種方式沒有協調中心，整個模式的工作方式就像舞蹈一樣，各個舞蹈演員按照預先編排的動作和走位各自表演，最終形成一隻舞蹈。

基於命令的方式。這種方式的工作形式就像一隻樂隊，由一個指揮家（協調中心）來協調大家的工作。協調中心來告訴Saga的參與方應該執行哪一個本地事務。

當重新來思考分散式事務的時候，再次印證我的一個觀點，即微服務拆分太細導致引入了很多完全沒有必要的分散式事務問題，增加了開發，整合，測試和後續監控運維的工作量和複雜度。

比如書裡面談到的一個例子，對於一個線上訂餐系統提交一個訂單，這個本身是一個很容易實現的功能，但是在微服務化後，訂單提交涉及到使用者校驗，賬戶校驗，廚房工單生成多個獨立API服務介面呼叫。這個就涉及到這些API介面的事件編排，同時在編排中你還需要考慮出現異常時候的補償回退，考慮訊息執行順序等諸多問題。

這些急劇了增加了一個功能實現的複雜度。當你本身開發的系統就不存在海量併發和高效能需求的時候，我實在難以找到任何理由將微服務拆分的如此細，引入這麼多的複雜度。

實際上以上的分散式事務場景應該更多地應用到大系統間的分散式事務協同上面，比如採購系統提交訂單的時候，同時涉及到工作流平臺中的工作流例項啟動，涉及到預算系統的預算校驗，這個時候才要分散式事務來實現是有必要的。

跨系統出現上面這種分散式事務處理和協同場景，這個量完全可控。但是你微服務拆分得太細，你在實現應用中任何一個功能都引入上面這種分散式事務問題，基於事件的編排和補償問題，可想而知已經不是簡單的複雜度問題，而是後期的系統可靠性和可運維問題。

如何徹底解耦？

前面談到了如果是CUD操作可以非同步方式來實現解耦，那麼對於查詢操作如何處理。如果一個查詢查詢本身還涉及到多個微服務API介面的組合，這個時候如何實現解耦。

即如果存在查詢操作，那麼微服務間仍然是緊耦合在一起的。我們希望的微服務間透過訊息和非同步來徹底解耦這個目標並沒有達到。

當然實際上可以考慮兩個方法來解決這個問題。

其一就是將常用資料快取，查詢的時候直接訪問快取庫。

其二就是將微服務底層資料庫需要共享資料進行同步，同步到一個大的共享ODS讀庫專門來提供查詢服務能力。

在一些專案的CQRS命令查詢職責分離實踐中，基本即採用的這個思路。透過這種方式來實現微服務間的徹底解耦。當然也引入了另外兩個依賴點，一個就是訊息中介軟體，一個就是快取庫或分散式ODS讀庫。這兩個點的穩定性就直接影響到整個系統的穩定性。

採用CQRS模式最大的一個問題點就是無法實現命令和查詢兩部分內容的強一致性保障，即很可能你介面上查詢到的資料不是最新的持久化資料庫裡面的資料，這個本身和訊息管道非同步寫入的實時性又關係。

其次在使用CQRS模式的時候，有一個重要假設就是在事件和命令發出後，無特殊情況在事件接收方都必須要能夠接收事件成功處理，否則就存在大量的異常錯誤訊息的非同步回寫，反而增加系統的複雜度。

實施CQRS引入的整體複雜度，也不是一般的小專案能夠玩得起的。

同時對於CQRS框架的實施，不是簡單的設計模式和開發複雜度問題，更加重要的仍然是是否能夠接受最終一致性要求，同時在該要求下將傳統的同步請求下業務功能和邏輯處理機制轉變為非同步事件價值下的事件鏈驅動模式。要實現這種轉變就必須能夠拆分出獨立，自治的命令和事件，同時確保這些事件在朝後端業務功能和邏輯模組傳送的時候能夠處理成功（即該做的校驗必須提前做完）。

微服務閘道器和API閘道器

於API閘道器和微服務閘道器實際實現的核心功能基本一致，但是要注意到微服務閘道器一般是在微服務架構體系裡面的內容。而API閘道器一般是可以獨立在微服務架構體系之外的內容。

也就是說API閘道器和微服務整體框架體系更加的松耦合。

API閘道器一般具備獨立的服務註冊接入，負載均衡和路由能力，而微服務閘道器一般則是透過和服務註冊中心的整合來實現服務註冊發現，負載均衡和路由。

應用範圍的區別

在這裡重新強調下，微服務閘道器和API閘道器實際在應用範圍上有明顯的區別。即微服務閘道器一般應用在單個微服務應用內部，特別是在存在前後端分離情況下。而對於API閘道器則是應用在組織級，實現多個微服務應用之間的整合和協同能力。

單個微服務應用，完全沒有必要採用API閘道器，直接使用微服務閘道器。比如當你採用SpringCLoud框架體系的時候，你直接採用框架裡面的Zuul或SpringCLoud Gateway即可。

但是當你在做組織級的多個微服務應用間整合的時候，這個時候需要的脫離單個微服務框架體系的的一個外部整合中介軟體，因此不能和微服務框架繫結太死。其次你會看到跨應用間的整合管控的粒度不是到微服務元件，而是要細化到一個個的API介面。因此這個時候啟用API閘道器就是必須的。

當你在組織級啟用API閘道器的時候發現一個新問題。

即對於整個組織級來說，遺留系統和單體應用的微服務化本身有個過程，在這個過程中一定是傳統架構和微服務架構共存。新的Rest API介面和老的SOAP介面和訊息協議共存階段。而API閘道器本身對老的介面協議適配能力並不好。對於類似ESB匯流排來說雖然偏重，但是可以完全相容和覆蓋API閘道器具備的能力。

因此在這種情況下API閘道器反而變得雞肋。

API閘道器是否該做類似服務編排組合的事情？

簡單來說API閘道器不應該做這件事情，傳統的ESB匯流排往往具備這個能力，但是API閘道器不適合來承載這個能力。如果做了服務編排的事情一個是讓API閘道器本身從單純的技術中介軟體變成了承載業務邏輯的中介軟體，其次就是該能力本身也將讓API閘道器變得更加重。

因此最好的方法仍然是獨立一個微服務來實現服務組合和編排，釋出組合後的領域服務或組合服務能力，這個在我前面文章專門有談到過。

API閘道器本身的中心化問題

不要簡單地認為中心化架構就一定不好，中心化架構本身透過集中管控和攔截的方式，可以很方便地實現類似API介面安全，日誌，路由，流控等各種管控能力。

在談微服務管控治理的時候，中心化的API閘道器是一個重要的實現思路和手段，當然在前面我也提到了整體的發展趨勢應該ServiceMesh化，實現完全的去中心化架構。這個ServiceMesh化本身又可以和DevOps，容器雲等雲原生技術形成一個完整的整體。

但是要意識到的點仍然是在於組織管控和標準化推進的力度，如果在組織級很多技術標準推進不一致，應用系統改造存在前後逐步演進，那麼這個時候你很難簡單的去實現ServiceMesh化架構。簡單來說即是：

對於傳統IT架構的逐步微服務化，本身並不適合採用ServiceMesh。

在談微服務架構的時候，經常有人談到完全的去中心化，但是沒有搞清楚為啥要去中心化。即使非同步訊息整合，訊息中介軟體仍然是中心點。當組織級標準規範，技術要求不統一的時候，管控能力達不到時候很難完全去中心化，這個時候中心化方式反而是一個好的選擇。

最後，做下簡單總結如下：

按照理想化的微服務方法來設計和實施微服務，對於大部分傳統企業資訊化來說不適用，同樣照搬網際網路微服務架構化方法同樣不適用。企業IT架構在微服務轉型過程中更多應該基於業務場景和問題驅動，借鑑微服務拆分和解耦的思想，充分考慮敏捷交付，彈性擴充套件和效能，開發難度和資源成本投入，後期管控治理多方面的平衡。