我在《技術架構演進的思考》一文中提到，“當前成熟火熱的微服務架構，後續會單獨總結梳理”，本文便是此“單獨總結”
微服務的what
微服務是2012～2014年間提出和興起的，這時分散式的各種理論體系基本成熟，虛擬化技術更加成熟易用，軟硬體基礎設施與生態進一步完善/完備，這是微服務能夠取代如今成績的客觀條件，否則微服務恐怕只是噱頭，無法在複雜龐大的業務場景中有效落地。
對微服務的認識，我覺得可以從“業務”和“技術”兩個角度展開。
業務上，微服務是SOA的延伸，與SOA相通，微服務也是面向服務的，得益於其相關技術，微服務能比SOA把服務拆解的更小，因此服務治理更容易，可擴充套件性更好
技術上，微服務是SOA的下一代技術，區別於SOA的架構方案，它提供一套新的面向服務的架構，解決了SOA中的痛點，讓系統具備更好的彈性伸縮的能力，服務的效能、穩定性、可維護性、可用性都能勝過SOA。
此外，微服務可大可小，可伸可縮。大，微服務能取代SOA，支撐起億級業務量的系統；小，微服務能代替單機/單體，讓這些系統帶來微服務的優勢。
微服務的why
本節主要回答能解決什麼問題，和微服務適用於什麼場景兩個問題。
從“複雜度”這個視角來審視業務，可以從“業務複雜度”和“技術複雜度”兩個維度，把業務劃分到四個象限中，即：
- 業務複雜度低，技術複雜度低
- 業務複雜度低，技術複雜度高
- 業務複雜度高，技術複雜度低
- 業務複雜度高，技術複雜度高
微服務擅長適用於業務複雜度高的兩類場景，主要解決的正是“業務複雜度高”這個問題。
技術複雜度，反應到業務層面是業務的量級，指標上反應為效能、可用性、可擴充套件性、可維護性等，技術複雜度低的系統，單體/單機架構也能搞定，而技術複雜度高的系統，需要依賴分散式技術帶來的水平擴充套件能力。因此，對於業務複雜度高、技術複雜度低的系統，微服務是對單機/單體架構的取代，對於業務複雜度高、技術複雜度也高的系統，微服務是對SOA的取代。
微服務應對“業務複雜度高”的難題，解決方案是合理的微服務拆分及協作，其本質上，是工作分解和任務分配，微服務的技術保證了工作分解的粗或細都能落地，保證了任務分配、協作的可靠性，所以解此難題是微服務的長項。另外，微服務解決此難題也有方法論為依託，業務層面可以應用DDD理論，技術層面可以借鑑物件導向的思想和原則。
對於技術複雜度低的系統，由於其業務量級本來就在單機/單體能力範圍內，轉型微服務，服務的拆分相對簡單，可以按照實際場景做合理拆分，儘量避免服務間的呼叫，避免分散式事務，同時轉型微服務後，系統的可擴充套件性只增不減，可用性大大提高，效能具備了水平擴充套件能力，且這裡的業務量級並不要去依賴全套的微服務基礎設施，技術複雜度也不會提高太多，因此這是微服務架構很好的一個應用場景。
對於技術複雜度高的系統，技術成本已經為系統開發增加了不少難度，若業務複雜度不高，沒必要引入微服務進一步拔高開發難度；若業務複雜度也很高，引入微服務，雖然有可能侵入原有業務邏輯，增加冪等設計、分散式事務、呼叫鏈追蹤等開發複雜度，和維護微服務基礎設施的運維成本，但選用其他分散式架構，很多相同或相似的技術也不可避免，且這些架構對於拆解“業務複雜度”的能力可能弱於微服務，故綜合權衡，微服務是應對業務複雜度高、技術複雜度高系統的首選方案。
綜上，
- 業務複雜度低，技術複雜度低的系統，沒必要引入微服務增加無謂的成本
- 業務複雜度低，技術複雜度高的系統，不應引入微服務提高研發的難度
- 業務複雜度高，技術複雜度低的系統，若涉及到異構系統整合，或對系統的效能、可用性等有進一步要求時，轉型微服務是有效解決方案
- 業務複雜度高，技術複雜度高的系統，微服務是首選架構方案
微服務的how
這裡主要考慮三個方面：
- 微服務基礎設施的選擇
- 微服務框架的選擇
- 服務的拆分
微服務基礎設施的選擇
微服務把SOA的ESB打散為一系列的基礎設施，有些以獨立服務的形式存在，為防止單點需要實現叢集部署，有些可以嵌入到程式碼框架中，天然暗含了分散式高可用的特性，這是基礎設施選擇時需要決策的一個點。
這些基礎設施按應用可以分層劃分，自底向上，可以分為基礎設施層、技術支撐層、服務執行層和服務接入層，每一層均有多項不同角色的設施；在微服務建設中，並不需要一開始就把全套基礎設施一股腦用起來，而是根據實際情況，如業務量級、複雜度等，選取恰當的設施應用；這是基礎設施選擇時的另一個決策點。
微服務的基礎設施全貌，稍後用腦圖梳理，其接入的取捨或優先順序如下：
- 服務執行層設施，如服務註冊、服務發現
- 服務接入層設施，如服務閘道器，服務流控
- 基礎設施層設施，如配置中心，日誌中心
- 技術支撐層設施，如服務監控，服務追蹤
微服務框架的選擇
微服務的框架，有三種模式：
- 嵌入式SDK
- 反向代理式
- Service Mesh
現在最成熟應用最廣泛的，當屬嵌入式SDK模式，如Spring Cloud和Dubbo，而這三類模式的發展，也正是從微服務走向雲原生的演化。
如果微服務開發的語言單一，如統一用Java，首選SDK模式，多語言共存時，可以考慮方向代理模式，如APISIX，而叢集規模超大時，則可以首選Service Mesh
服務的拆分
微服務的拆分，既可以按業務複雜度來拆分，也可以按技術複雜度來拆分。
若按業務複雜度來拆分，可以借鑑DDD的理論或物件導向的思想；若按技術複雜度來拆分，可以考慮按效能拆分、按穩定性拆分，或按可用性拆分。
微服務實踐
微服務可用於老系統的改造或新系統的建設。
（1）老系統改造
用微服務去改造老系統時，實際工作是個見招拆招的過程，沒有統一的方法論指導。只有在思想準備方面，如何做充足準備有章可循：
- 需要從老系統的痛點出發，否則可能執行不下去，如果痛點比較多，那就從最痛的一個點下手，一個點一個點的來，貪多嚼不爛
- 如果要改造的老系統，是業務邏輯特別複雜的單體系統，改造可能非常痛苦，痛點也可以無法一刀切下去，需要深入梳理分析業務
- 做老系統改造，首先是確定目標，然後基於目標做深入到位的變更影響分析，如果老系統業務複雜，可能需要在變更分析的基礎上，對老系統做一定的初步改造，才能把目標切出來，而對目標的改造，也有可能會在一定程度上打破原有業務邏輯，需要對老系統再做一些適配才能把新成果移植上去。
所以老系統改造，業務分析、影響分析、方案稽核務必慎重、嚴謹，想不清楚，不要草率動手，至少要留有回滾餘地。
（2）新系統建設
把微服務應用於新系統建設，由於沒有包袱，會自由很多，這時最好遵循一定章法，基於行之有效的套路來開展。
我覺得把微服務應用於新系統建設，一定要腳踏實地，切記好高騖遠。即按照實際的業務複雜度和量級做架構設計，不必為中遠期的業務規劃做太多過度設計，不要增加非必需的業務或技術複雜度，保持架構演化心態。
微服務架構設計階段，可以按照上文的優先順序逐步接入基礎設施，重點做好微服務的拆分工作，總體拆分原則是先總後分，儘量避免過早草率的把微服務拆的太細。
以我個人經驗，微服務拆分不合理是實踐中最突出的問題。不合理的拆分，可能是出於無意識的草率，也可能是面向不熟悉的領域時，對業務的理解深度不夠，或對未來業務的發展動向判斷不足導致的。不合理的拆分，可能會造成指數級增長的微服務間相互呼叫，也可能過早的引入分散式事務、冪等設計等技術複雜度。微服務拆分時，先整體後拆分總是比先拆分後合併簡單，所以微服務的拆分務必慎重。
What more
歡迎查閱本文的微信公眾號連結，歡迎關注我的公眾號～
注：轉載本文，請與Gevin聯絡
歡迎關注我的微信公眾賬號
