[[285723]]

 微服務架構是什么?

這是筆者自己整理的定義：

微服務架構是將軟件系統分解為自主模塊，這些自主模塊可獨立部署，并通過輕量級，與語言無關的方式進行通信，共同實現業務目標。

軟件系統很復雜。由于人腦只能接受一定程度的復雜性，因此大型軟件系統的高度復雜性會帶來許多問題。大規模、復雜的軟件系統難以開發、增強、維護，難以實現現代化以及擴大規模。

多年來，人們做了許多嘗試，以解決軟件系統的復雜性問題。20世紀70年代，David Parnas和Edsger W引入了模塊化軟件開發。Dijkstra解決了軟件系統復雜性這一問題。在90年代，引入了分層軟件架構，解決業務應用程序的復雜性。自21世紀初以來，面向服務的架構(SOA)脫穎而出，以開發復雜的業務應用程序。微服務架構是處理現代軟件應用程序復雜性的新方法。

此時可能會出現一個問題：為什么突然需要一種新的軟件開發方法?

簡單來說，軟件開發所處的整個生態系統在過去十年里發生了巨大變化。如今，軟件會通過Agile方法開發，利用CI / CD法在Container + Cloud上進行部署，然后保留在NoSQL數據庫上，最后呈現在瀏覽器或智能手機上，而且這些設備在高速網絡下會連接在一起。基于這些因素，微服務架構于2012年應運而生。

微服務或Monolith

對于微服務與Monolith，主要有兩類人群持相反的觀點。

對一類人群而言，微服務架構就是一種貨物崇拜(Cargo-Cult)或一種趨勢驅動開發(Hype Driven Development)，這對于喜歡技術的開發人員來說，就像是游樂場。

而另一類人群表示，微服務架構是“統治一切的架構”，會消除任何軟件系統的復雜性。筆者看來，微服務和Monolith架構互為補充。對于長期精簡的應用程序，Monolith 架構更為合適。另一方面，對于大型且復雜的應用程序或可能變得大型和復雜的應用程序，微服務架構這一解決方案更好。

如今的軟件開發是十分龐大的工程，可以實現微服務架構和Monolith架構的共存，就如SQL和NoSQL并存一樣。

10個優秀實踐

使用正確的方法設計微服務架構非常具有挑戰性和難度。微服務架構不同于Monolith架構，可以提供一勞永逸的解決方案，微服務體系結構針對不同問題提供不同的解決方案。如果選擇了錯誤的解決方案，那么微服務架構將是一顆定時炸彈，注定會引爆。設計欠佳的微服務架構要比Monolith更加糟糕。定義一套微服務架構的優秀實踐也十分困難。筆者在一些會議演講上聽到過一些著名且受人尊敬的軟件工程師曾提出適得其反的微服務架構優秀實踐。

本文提出了一些微服務架構的優秀實踐，有助于開發有效的微服務應用程序，在該應用程序中，目標項目可以存在6個月以上，并且團隊規模為中型到大型(6名以上的開發人員)。以下幾篇文章全面呈現了有關Microservice Architecture的優秀實踐，例如Martin Fowler撰寫的文章《微服務架構的特征》或Chris Richardson撰寫的《微服務模式》或Netflix的《微服務運用》：Tony Mauro撰寫的《架構設計的若干教訓》。也有一些很棒的演講，例如Stefan Tilkov的演講《微服務模式和反模式》，David Schmitz的演講《應對微服務嚴重失敗的10條技巧》，Sam Newman的演講《微服務原理》。

1. 微前端

不幸的是，大多數后端開發人員對前端開發的看法比較落后，認為前端開發很簡單。由于大多數軟件架構師都是后端開發人員，因此幾乎不關心前端，并且前端通常在架構設計中被忽略。在微服務項目中，后端數據庫常常會高度模塊化，但是有一個Monolith前端。在合適的情況下，開發人員會考慮使用最熱門的SPA(React，Angular，Vue)之一來開發Monolith 前端。

但主要問題在于，前端Monolith與筆者在文章《微服務架構：簡介與在項目中應用的必要性》(MicroserviceArchitecture: A brief overview and why you should use it in your next project)描述的后端Monolith一樣糟糕。

此外，由于更改瀏覽器也要保持前端的同步，就需要進行大爆炸式的現代化(這就是許多公司仍在使用過時的Angular 1框架的原因)。網絡簡單但功能強大，并本身提供嵌入。基于微前端開發SPA有很多方法：使用iFrame、Web組件或通過Elements(Angular / React)。

2. 連續交付

微服務架構的一個關鍵USP是每個微服務都可以獨立部署。如果系統有100個微服務，要求更改一個微服務，那么可以僅更新一個微服務，而無需更改其他99個微服務。

但是，在沒有自動化的情況下獨立部署100個微服務(DevOps，CI / CD)是一項艱巨的任務。要充分利用此微服務功能，需要CI / CD和DevOps法。使用不帶CI / CD，DevOps的微服務架構，自動化就像購買最新的保時捷，然后手動剎車駕駛。不足為奇的是，CI / CD被微服務專家馬丁·福勒(Martin Fowler)列為使用微服務架構的三個先決條件之一。

3. 微服務優先

許多專家認為，對于未開發的(新的)項目，最好從松耦合的單片架構開始，因為微服務架構需要大量的初始工作來設置操作。

專家認為，一旦該項目變得足夠成熟，就可以將“精巧”設計的Monolith輕松地轉換為微服務。但是，筆者認為這種方法在大多數情況下將以失敗告終。實際上，Monolith內部的模塊緊密耦合，這使其難以轉換為微服務。同樣，一旦應用程序正式投入生產，要在不中斷應用程序的情況下轉換為微服務將變得更加困難。因此，如果最終有計劃使用微服務架構，建議一開始就使用微服務。

4. 庫的基礎設施。

在微服務軟件開發的早期，Netflix主要使用Java編程來開發微服務。Netflix還開發了許多庫(包括Hystrix，Zuul的Netflix OSS Stack)。許多公司效仿Netflix，并開始使用Netflix OSS庫。后來，許多公司(包括Netflix)發現Java并不是開發微服務的事實語言，因為Java體積龐大且存在冷啟動問題。

Netflix后來轉向Polyglot微服務范式，并決定不再進一步開發Netflix OSS，這導致追隨Netflix的公司陷入困境。因此，與其大量投資于特定語言的庫(例如基于Java的Netflix OSS)，使用框架(例如服務網格，API網關)更為明智。

5. 域驅動設計

開發微服務較大的挑戰是將大型、復雜的應用程序拆分為小型、可管理且可獨立部署的模塊。如果微服務沒有以正確的方式對應用程序進行拆分，那么將存在緊密耦合的微服務，這些微服務將具有Monolith的所有缺點以及微服務(又名分布式Monolith)的所有復雜性。

幸運的是，在這方面已經有一個可以提供許多幫助的解決方案。埃里克·埃文斯(Eric Evans)是一名軟件工程顧問，曾在不同公司中多次遇到有關業務應用程序中復雜性的問題，并在2004年出版的書籍《域驅動設計：解決軟件核心中的復雜性》中總結了很有價值的見解。該書的核心概念可分為以下三類：

• 軟件開發團隊應與業務部門或領域專家緊密合作。
• 架構師或開發人員和領域專家應首先進行戰略設計：查找有界上下文以及相關的核心域、通用語言、子域、上下文映射圖。
• 然后，架構師或開發人員應進行戰術設計，將核心領域分解為細粒度的構建基塊：實體、值對象、聚合、聚合根。

域驅動設計的詳細討論超出了本文的范圍，但是大家應該讀讀原書埃里克·埃文斯(Eric Evans)《域驅動設計：解決軟件核心中的復雜性》(藍皮書)或沃恩·弗農(Vaughn Vernon)所著書籍《實施域驅動設計》(紅皮書)。如果將一個大型系統分為核心域和子域，再將核心域和子域映射到一個或多個微服務，那么可以獲得理想的松耦合微服務。

6. 可觀察性

微服務架構的一個主要缺點在于以運營為代價使軟件開發變得簡單。使用Monolith監視應用程序要更為簡單。但是，由于許多微服務在容器上運行，因此整個系統的可觀察性變得非常關鍵和復雜。甚至日志記錄也變得很復雜，無法將來自許多容器或機器的日志聚合到一個中心位置上。

幸運的是，市場上已經有許多企業級的解決方案。例如，ELK / Splunk提供微服務的日志記錄。Prometheus / AppDynamics提供行業級的監視。在微服務領域，另一個非常重要的可觀察性工具是Tracing。通常，微服務的一個API請求會導致對其他微服務的多次級聯調用。要分析微服務系統的延遲，有必要測量每個微服務上的延遲度。Zipkin / Jaeger為微服務提供了出色的跟蹤支持。

7. 統一技術棧

微服務架構表明，需要采用對于微服務最適合的編程語言和框架。這不應從字面上理解。有時，微服務可能需要新的技術棧，例如對于CPU繁重或高性能的任務，可以選擇C ++ / Rust之類的編程語言。如果微服務可與機器學習一起使用，也許Python是更好的選擇。

但是，在沒有任何充分理由的情況下，使用不同的編程語言或框架可能會出現太多的編程語言和框架，而沒有帶來任何真正的好處。想象一個這樣的場景：使用Spring Boot + Kotlin + React + MySQL開發一種微服務，使用JakartaEE + Java + Angular + PostgreSQL開發另一種微服務，再使用Scala + Play Framework + VueJS + Oracle開發其他一種微服務，那么需要付出很多努力維護不同的編程語言、數據庫和框架，但收獲會很少。

8. 每個微服務的數據庫

將復雜應用程序拆分為微服務模塊后，接下來的挑戰出現了——如何處理數據庫?

是否應該在微服務之間共享數據庫。這個問題的答案是雙刃劍，有利有弊。

一方面，在微服務之間共享數據庫將帶來強大耦合，這與微服務架構的目標恰恰相反。即使數據庫中出現微小變化，也需要團隊之間的同步操作。同樣，在一項服務中，管理事務和鎖定數據庫也具有挑戰性。但是在多個分布式微服務之間管理事務或鎖定數據庫是一項艱巨的任務。

另一方面，如果每個微服務都有自己的數據庫或專用表，則在微服務之間交換數據就會帶來會打開潘多拉魔盒式的挑戰。因此，許多杰出的軟件工程師都提倡在微服務之間共享一個實用的解決方案。但是，筆者認為，微服務完全是一個可持續和長期的軟件開發過程。因此，每個微服務都應具有自己的數據庫(或專用表)。

9. 異步通訊

微服務架構中很具挑戰性的一個設計決策是服務之間如何進行通信和共享數據。當每個微服務都有自己的數據存儲時，這一點尤為重要。

通常，一個微服務可以單獨存在，但不能單獨滿足所有業務目標。所有微服務一起工作，實現業務目標，并繼續一起工作，這些微服務需要交換數據或觸發其他微服務來完成任務。微服務之間最簡單且最常見的通信方式是通過Synchronous REST API，這很實用，但不是長久之計。如果服務A調用服務B，服務B調用服務C，服務C同步調用服務D，那延遲就會疊加。

另外，由于微服務主要是分布式系統，因此可能會有故障。同步微服務通常會導致失敗的級聯，即一個服務中的故障可能導致其他服務出現故障。微服務之間的同步通信還導致微服務之間的緊密耦合。想要有個長久的解決方案，則微服務應該異步通信。微服務之間的異步通信有很多方法：例如，通過Message QueueKafka，通過異步REST(ATOM)或CQRS。

10. 組織注意事項

大約50年前(1967年)，梅爾文·康威(Melvin Conway)觀察到，公司的軟件架構受組織結構(康威法則)的限制。盡管這一發現已有50年歷史，但麻省理工大學和哈佛商學院最近發現該法律在現代仍然有效。如果某個組織計劃開發微服務架構，則應相應地擴大團隊規模(兩個“美式”比薩團隊：5人或9人)。此外，團隊應是跨職能的，并且理想情況下擁有前端或后端開發人員、Ops工程和測試人員。微服務架構僅在高級管理層也相應地改變觀點和愿景的情況下才起作用。

以上。

希望大家可以閱讀完以上技巧后，可以正確實施微服務架構。