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