1. 領域驅動設計

微服務開發的首要挑戰：

把大的、復雜的應用拆分為小的、自治的、可獨立部署的模塊。

如果沒有正確的拆分，那么結果就是一堆漿糊，有著單體結構的缺點，和微服務結構的復雜度，可以稱之為分布式單體。

幸運的是，Eric Evans 為領域驅動設計提出了大量的最佳實踐和經驗技巧，有3個核心思維：

•  開發團隊要和業務部門、業務領域專家緊密合作。
•  架構師、開發人員、領域專家應該先做出戰略設計：找出邊界上下文、核心域、子域、上下文映射關系。
•  架構師、開發人員根據戰略設計梳理出一套核心構造塊：實體、值對象、聚合等等。

把一個大型系統劃分為核心域、子域，再把核心域、子域映射為微服務，這樣我們就可以得到一個理想的松耦合微服務體系。

2. 每個微服務一個數據庫

微服務模塊結構設計好了，下面一個重要問題就是怎么處理數據庫，各個微服務是否共享數據庫呢？

如果共享，將導致微服務之間緊耦合，違背了微服務的松耦合原則。數據庫中一個小小的變動就需要各個團隊同步修改。

如果每個微服務都有自己的數據庫，那么微服務之間的數據交換將非常麻煩，就像打開了潘多拉魔盒，跑出一堆問題，例如在多個服務中管理事務。

所以，很多人主張共享數據庫。

但是，微服務是持續的、長期的軟件開發，每個微服務應該有其自己的數據庫。

3. 微前端

很多后端開發者輕視前端，認為太簡單。

大多數架構師也是后端出來的，在架構設計中對前端不夠重視。

導致現狀就是，后端模塊化做的很好，而前端還是一整坨。

前端單體結構和后端單體有一樣的問題，所以前端也需要進行現代化的改造。

現在的 web 技術簡單、強大，例如 web 組件、Angular/React。

4. 持續交付

每個微服務可以獨立部署，是微服務架構的核心優勢之一。

比如你的系統包含 100 個微服務，現在有一個需要更新，那么你可以只需要發布這一個，而另外 99 個不需要動。

這就需要 CI/CD 和 DevOps，如果沒有這套自動化流程的話，就像拉著手剎開法拉利。

5. 可觀察性

微服務架構簡化了開發，但復雜了運維。

單體結構是非常便于監控的，但在微服務架構中，服務很多，而且通常是跑在容器中，對整個系統的監控就變得非常復雜。

需要把所有容器、機器中的日志聚合到一起。

幸運的是已經有成熟的解決方案，例如，使用 ELK/Splunk 處理日志，使用 Prometheus/App Dynamics 處理監控。

還有一個比較重要的方面：調用跟蹤。

微服務間會產生級聯調用，為了分析系統延遲，就需要測量每個服務的延遲，Zipkin/Jaeger 提供了這個能力。

6. 統一技術棧

微服務體系中，不同服務有不同的特性，例如有的服務是 CPU 密集型操作，使用 C++/Rust 比較合適；有的服務是做機器學習的，使用 Python 比較合適。

所以，可以使用不同的技術處理相應的需求，但是，一定要注意合理性，不要毫無根據的混合使用不同的技術。

想象一下，在一套系統中，有的微服務使用 Spring Boot + Kotlin+ React + MySQL，有的使用 JakartaEE + Java + Angular + PostgreSQL，有的使用 Scala + Play Framework + VueJS + Oracle。

這會不會讓人很崩潰，太難維護了。

7. 異步通信

服務間的通信問題是微服務架構的重要挑戰，比是否共享數據庫那個問題還麻煩。

為了實現業務需求，需要多個微服務的協同工作，服務間需要進行數據交換，一個服務需要觸發其他服務。

最簡單的就是通過 REST 接口直接調用，但這種同步調用方式問題比較大。

例如 A -> B -> C -> D，這種多級調用主要的3個問題：

•  增加了系統延遲。
•  每個服務可能會故障，這就產生了級聯性的錯誤。
•  服務間緊耦合。

最好是使用異步通信的方式，例如通過消息隊列（如 kafka）、異步的 REST（ATOM）、CQRS。

8. 微服務優先

很多人認為新項目應該使用單體結構，這樣起步快，比微服務簡單，當發展大了之后再改造為微服務。

然而，這個改造是非常困難的，因為單體中模塊的耦合度太高了。

而且產品成熟后，對在線可用性要求很高，那個時候再改造的話，一定會中斷產品運行。

9. 基礎設施優于類庫

Netflix 早期開發微服務時，主要使用 java 來開發，Netflix 開發出了很多優秀的庫，如 Hystrix, Zuul，很多公司都使用他們。

后來，包括 Netflix 在內的很多公司都發現 java 其實并不擅長微服務開發，例如 java 體積過于龐大。

Netflix 轉向了 Polyglot，并停止了之前那些庫的維護，這就讓很多公司被動了。

所以，不要過度依賴特定語言的類庫，可以使用更底層的基礎框架，例如 Service Meshes。

10. 組織考慮

50 年前，Melvin Conway 發現公司的軟件架構受限于其組織結構。

其實在現在，這個觀點依然正確。

如果一個組織想使用微服務架構，那么就應該調整好團隊的大小。

兩個披薩餅原則：如果兩個披薩不足以喂飽一個項目團隊，那么這個團隊可能就顯得太大了。

而且，團隊成員應該是多元化的，有前端、后端、測試、運維。

只有高層領導者轉變思維方式，微服務架構才有可能發揮作用。