前言
微服務架構其實是為了服務可以獨立的開發、獨立的部署，快速迭代，並且技術多樣性。
然而我們經常在開發微服務的時候沒有弄清楚微服務的邊界，導致了一個更大的坑，由單體架構拆分成了微服務單體架構，帶來了更大的災難：開發單體的痛苦一個都沒少，面向服務的好處一點沒撈着。
如果不解決這些問題，隨着服務生態系統的增長，情況越來越糟。
一、好的微服務架構
- 職責單一，高內聚低耦合
- 可以獨立開發、獨立的部署、獨立擴縮容
- 有自己的數據存儲，獨立的數據庫、緩存、消息隊列等資源
- 加快迭代的速度
二、分布式單體架構
雖然微服務架構很好，很高級，但是開發的過程經常因為臨時緊急需求、業務開發人員不懂抽象等原因最終拆成了分布式單體架構。
這個可能有產品的原因，也可能有開發的原因。如果真的要追源頭，大部分還是開發人員的抽象能力不行，而抽象能力這東西就像算法一樣，是一種內功，無法速成
耦合示例
左：服務A調用服務B，服務B調用服務C，然后A再調用服務C獲取結果
右：服務A調用服務B，服務B依賴服務C，而服務C又依賴服務A。依賴產生了環
這樣的結構最終會變成分布式單體，產生如下問題：
- 同時更新兩個服務，不知道先更新哪個，因為相互依賴。
- 一個簡單的邏輯可能會跨多個服務。如果出了問題，只能由對多個服務都了解的人來診斷問題
糟糕的本地多服務開發模式
本地運行大部分的基礎設施，極有可能遇到“無法運行”的問題
- 開發人員不知道如何運行所有依賴的服務
- 開發人員的配置撐不起來運行的服務
這是明顯的單體架構的開發模式，本地需要跑所有的東西，拆成了微服務架構，還是需要本地跑所有的東西
糟糕的調試和測試策略
- 跨網絡難以診斷。平常的開發只要簡單的下斷點就可以了，變成了分布式單體后診斷非常困難，各種打開項目看日志，下斷點
- 多個服務之間數據同步有問題，准備數據需要花更多的時間和精力
- 不正確的配置，連接超時、讀寫超時、工作進程數量、伸縮配置等等。
- 難以模擬系統交互（消息代理、異步隊列等）
微服務架構的好處之一就是為了加快迭代速度，如果浪費了大量的精力在本地調試和測試上，已經失去了微服務的意義
高成本補償措施
- 大力投資基礎設施和測試，以確保數據正確同步
- 做大量可見性和異常檢測的工作，確保在同步異常和報警時，能及時診斷和解決。
- 給開發人員培訓，使他們不會意外引入會導致數據同步問題的更改
- 在多個服務之間同步足夠多的數據后，開發人員一定會犯錯（墨非定律）
三、解決思路
當前的架構已經出了問題，首要的應該是分析當前系統的維護成本、修改成本和新系統所節省的成本之間存在的關系。
這是一個難點，我們應該去關注一些核心的指標，例如
關注核心指標
- 交付時間
- Bug數量
- 宕機次數
- 受影響用戶數量
制定遷移計划
如果系統沒有設計好，已經出現了這樣的數據耦合架構， 制定架構調整計划，逐步將現有架構過度到目標架構
- 逐步合並耦合的服務
- 逐步合並耦合的數據庫
- 大而全的測試，例如黑盒、CICD自動化測試、單元測試、壓力測試等。