微服務的優(yōu)秀實踐有哪些

本篇內容介紹了“微服務的優(yōu)秀實踐有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！

1. 領域驅動設計

微服務開發(fā)的首要挑戰(zhàn)：

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

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

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

•  開發(fā)團隊要和業(yè)務部門、業(yè)務領域專家緊密合作。

•  架構師、開發(fā)人員、領域專家應該先做出戰(zhàn)略設計：找出邊界上下文、核心域、子域、上下文映射關系。

•  架構師、開發(fā)人員根據(jù)戰(zhàn)略設計梳理出一套核心構造塊：實體、值對象、聚合等等。

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

2. 每個微服務一個數(shù)據(jù)庫

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

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

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

所以，很多人主張共享數(shù)據(jù)庫。

但是，微服務是持續(xù)的、長期的軟件開發(fā)，每個微服務應該有其自己的數(shù)據(jù)庫。

3. 微前端

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

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

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

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

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

4. 持續(xù)交付

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

比如你的系統(tǒng)包含 100 個微服務，現(xiàn)在有一個需要更新，那么你可以只需要發(fā)布這一個，而另外 99 個不需要動。

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

5. 可觀察性

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

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

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

幸運的是已經(jīng)有成熟的解決方案，例如，使用 ELK/Splunk 處理日志，使用 Prometheus/App Dynamics 處理監(jiān)控。

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

微服務間會產(chǎn)生級聯(lián)調用，為了分析系統(tǒng)延遲，就需要測量每個服務的延遲，Zipkin/Jaeger 提供了這個能力。

6. 統(tǒng)一技術棧

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

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

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

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

7. 異步通信

服務間的通信問題是微服務架構的重要挑戰(zhàn)，比是否共享數(shù)據(jù)庫那個問題還麻煩。

為了實現(xiàn)業(yè)務需求，需要多個微服務的協(xié)同工作，服務間需要進行數(shù)據(jù)交換，一個服務需要觸發(fā)其他服務。

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

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

•  增加了系統(tǒng)延遲。

•  每個服務可能會故障，這就產(chǎn)生了級聯(lián)性的錯誤。

•  服務間緊耦合。

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

8. 微服務優(yōu)先

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

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

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

9. 基礎設施優(yōu)于類庫

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

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

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

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

10. 組織考慮

50 年前，Melvin Conway 發(fā)現(xiàn)公司的軟件架構受限于其組織結構。

其實在現(xiàn)在，這個觀點依然正確。

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

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

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

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

“微服務的優(yōu)秀實踐有哪些”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注億速云網(wǎng)站，小編將為大家輸出更多高質量的實用文章！