有效的微服務：10 個最佳實踐

推薦閱讀：

• 架構設計原則 - 高併發
• 使用 Canal 實現數據異構
• MySQL中一條SQL語句是如何執行的？
• 阿里開源的分佈式事務框架 Seata
• ZooKeeper 並不適合作註冊中心

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...