注：本文爲我最近閱讀《微服務架構設計模式》的一點感悟，我不準備詳細去寫對該書的讀書筆記記錄，而是結合我們自己所做的一些微服務架構實踐情況做一些總結和覆盤。
從單體應用到微服務
任何一個新的架構模式或方法的出現，一定是傳統架構模式遇到了問題。而對於單體應用來說常說的問題主要包括瞭如下幾個點。
單體應用規模太大，導致複雜度劇增，難以開發和管理
單體應用開發，交付和變更週期變長，敏捷性跟不上
單體應用本身在性能，擴展性上出現了問題
在軟件架構設計裏面，分而治之始終都是解決複雜性的一個關鍵思維方法。包括在傳統軟件架構設計裏面對於大系統會進行子系統或組件劃分，會進行接口設計，集成設計等。
架構的核心思維仍然是：分解+集成
但是傳統架構在分解的時候沒有做到單個組件的高度獨立自治和徹底解構。這個高度獨立自治實際上要求組件或模塊從開發，設計，測試，上線運行，後期運維全生命週期都做到高度獨立；同時還要求配合的開發團隊，組織結構設計也獨立。
也正是這個原因進一步發展出了微服務架構。也就是說微服務架構實際是傳統組件化架構設計思想的進一步強化，強化的核心就是獨立和解耦。
微服務架構思想的一個重點就是單體應用的拆分。
講微服務一定會談到擴展立方體。
對於傳統單體應用一般來講擴展的方法只能是X座標軸的通過擴展實例方式的水平擴展。而另外兩個重要的擴展一個是功能拆分，一個是數據庫拆分。
對於功能拆分實際不是新鮮東西，在很早組件化架構設計我們就做過將不同的應用組件部署到不同的App Server服務器上，對於應用層你只需要考慮解決類似Session會話保存，全局配置和分發等問題即可，不會涉及到複雜的數據持久化問題。
而真正難的是在數據庫拆分。因爲數據庫拆分引入了兩個大問題，其一是分佈式事務問題，其二是大量操作跨庫帶來的分佈式事務問題。
數據庫爲何要拆分？
在單體應用發展到一定階段後，出現的性能問題往往都是DB層面的難以解決。數據庫集羣很難做到水平彈性擴展，即使對於類似Oracle RAC等商用集羣軟件，本身也有性能擴展瓶頸。性能擴展到2到3倍後已經無法再擴展。
因此單純從擴展實例擴展來說，後面衍生了讀寫分離集羣，讀寫分離集羣在應對讀操作佔比大的業務場景下實際是最佳的一種擴展方式，在這種方式下數據庫本身並沒有拆分爲多個實例，不會引入前面遇到的兩個大問題。只要在數據庫上搭建一個DaaS數據庫訪問中間件，那麼數據庫底層的這種拆分和變化完全可以做到對上層應用開發透明。
當談到這裏的時候，再來回顧一下微服務的一些核心點自然就更加清楚。
微服務是傳統單體的拆分，而且需要做到高度獨立自治
微服務的拆分不僅僅是功能拆分，更加重要是數據庫拆分
異步和解耦是微服務架構設計的重要指導思想
微服務間通過輕量高效的Http API接口交互協同
微服務實踐需要開發組織，持續集成，測試，交付方式配套支撐
場景和問題驅動
在前面談微服務的時候我就談到過，微服務架構本身將導致開發，集成，運維複雜度全部增加。即使對於常說的高可用性，也僅僅是高可用性和彈性擴展能力增加，但是對於高可靠性反而是降低。
那麼一個企業或團隊是什麼原因實踐微服務？僅僅是微服務是一種架構發展趨勢，是技術熱點，是互聯網大廠都在用嗎？
而實際對於很多企業應用微服務可以看到，更多是團隊裏面總有一些技術狂熱份子，熱衷於新架構，新技術，但是對於這些技術究竟解決了哪些業務場景下的問題並不關心。這直接就導致了大量技術在不恰當的時候被應用。
並不是說微服務不好，而是說對於架構師來說應該基於業務，技術，團隊資源，成本等多個維度來綜合考慮究竟應該在什麼時候用什麼樣的技術最合適。
類似阿里的電商平臺，一天訪問量上億，接近百萬的TPS，高峯秒級成交都幾十萬筆，這種業務場景下各個模塊拆分爲獨立中心，獨立數據庫是必然。不是說什麼技術先進了必須使用，而是爲了滿足和支撐業務必須微服務化。
那麼傳統企業實踐微服務就一定要思考微服務究竟能解決什麼問題。如果這個問題沒有想清楚就不要輕易去搞微服務。其次就是通過其他傳統方式能解決的也不要輕易去理想化的實踐微服務架構。
比如一個業務系統運行過程中數據庫出現性能瓶頸，這個時候你可以考慮的是將歷史數據進行遷移到備庫，增加備庫單據查詢能力；或者是前面談到的構建數據庫的讀寫分離集羣或者在數據庫上構建二級索引緩存庫來解決性能問題。
再比如一些業務系統出現瓶頸，並不是常規的OLTP場景出現問題，而是單個業務系統數據庫同時在支撐OLTP和OLAP能力。這個時候你應該做到是將大量的查詢統計和數據分析功能移出，而不是對整個業務系統進行數據拆分。
這方面的例子還有很多，實際是想說明一點，很多業務系統的複雜度和性能問題遠遠沒有到必須進行功能拆分和數據庫拆分才能夠解決的地步。
微服務拆分策略
當聊微服務拆分的時候先談下傳統軟件架構設計裏面的組件拆分。
對於組件拆分可以看到常規的組件拆分實際是在應用層而沒有到具體的數據庫。這就導致了組件拆分後，底層數據庫仍然是一箇中心點和緊耦合點。包括組件拆分後，實際架構規劃的時候希望通過組件間通過接口調用協同的，後續在開發實現中往往也出現偏差，即常說的仍然是通過底層數據庫的關聯sql查詢等來解決問題。所以你看到情況是組件間並沒有什麼接口調用，而大量的耦合都轉到底層數據庫的耦合上面。
到了微服務階段的拆分，實際上變成了兩個重要的事情，一個是數據庫的拆分，一個是基於數據庫拆分後的功能拆分。
對於拆分我前面寫過兩篇文章可以參考：
對領域模型和上下文邊界分析來劃分微服務的再思考
聊聊DaaS數據庫即服務和微服務下數據庫拆分
不論是採用的是傳統的結構化分析方法，還是當前類似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接口的組合，這個時候如何實現解耦。
對於查詢操作一般來講都是同步操作，用戶端點擊查詢後會等待數據的返回，這個時候如果需要調用多個微服務API接口數據進行組合，那麼底層某個微服務模塊如此異常，將直接導致整個查詢功能持續異常。
即如果存在查詢操作，那麼微服務間仍然是緊耦合在一起的。我們希望的微服務間通過消息和異步來徹底解耦這個目標並沒有達到。
當然實際上可以考慮兩個方法來解決這個問題。
其一就是將常用數據緩存，查詢的時候直接訪問緩存庫。
其二就是將微服務底層數據庫需要共享數據進行同步，同步到一個大的共享ODS讀庫專門來提供查詢服務能力。
在一些項目的CQRS命令查詢職責分離實踐中，基本即採用的這個思路。通過這種方式來實現微服務間的徹底解耦。當然也引入了另外兩個依賴點，一個就是消息中間件，一個就是緩存庫或分佈式ODS讀庫。這兩個點的穩定性就直接影響到整個系統的穩定性。
採用CQRS模式最大的一個問題點就是無法實現命令和查詢兩部分內容的強一致性保障，即很可能你界面上查詢到的數據不是最新的持久化數據庫裏面的數據，這個本身和消息管道異步寫入的實時性又關係。
其次在使用CQRS模式的時候，有一個重要假設就是在事件和命令發出後，無特殊情況在事件接收方都必須要能夠接收事件成功處理，否則就存在大量的異常錯誤消息的異步回寫，反而增加系統的複雜度。
實施CQRS引入的整體複雜度，也不是一般的小項目能夠玩得起的。
同時對於CQRS框架的實施，不是簡單的設計模式和開發複雜度問題，更加重要的仍然是是否能夠接受最終一致性要求，同時在該要求下將傳統的同步請求下業務功能和邏輯處理機制轉變爲異步事件價值下的事件鏈驅動模式。要實現這種轉變就必須能夠拆分出獨立，自治的命令和事件，同時確保這些事件在朝後端業務功能和邏輯模塊發送的時候能夠處理成功（即該做的校驗必須提前做完）。
微服務網關和API網關
對於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架構在微服務轉型過程中更多應該基於業務場景和問題驅動，借鑑微服務拆分和解耦的思想，充分考慮敏捷交付，彈性擴展和性能，開發難度和資源成本投入，後期管控治理多方面的平衡。
來源：
https://www.toutiao.com/i6925193987997696516/
本文分享自微信公衆號 - JAVA高級架構（gaojijiagou）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。