推薦閱讀：
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 發現公司的軟體架構受限於其組織結構。
其實在現在，這個觀點依然正確。
如果一個組織想使用微服務架構，那麼就應該調整好團隊的大小。
兩個披薩餅原則：如果兩個披薩不足以餵飽一個專案團隊，那麼這個團隊可能就顯得太大了。
而且，團隊成員應該是多元化的，有前端、後端、測試、運維。
只有高層領導者轉變思維方式，微服務架構才有可能發揮作用。
翻譯整理自：
https://towardsdatascience.co...
原文連結：https://segmentfault.com/a/119000002156224...
本作品採用《CC 協議》，轉載必須註明作者和本文連結
