去年有人提出了微服務(wù)將瘋狂至死，微服務(wù)的爭論從未停止過。

今天，小芯給大家?guī)淼氖遣荒懿惶嵯盗?mdash;—正確實施微服務(wù)架構(gòu)的10條技巧(也是10個優(yōu)秀實踐)。

[[285730]]

微服務(wù)架構(gòu)是什么?

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

微服務(wù)架構(gòu)是將軟件系統(tǒng)分解為自主模塊，這些自主模塊可獨立部署，并通過輕量級，與語言無關(guān)的方式進行通信，共同實現(xiàn)業(yè)務(wù)目標。

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

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

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

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

微服務(wù)或Monolith

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

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

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

如今的軟件開發(fā)是十分龐大的工程，可以實現(xiàn)微服務(wù)架構(gòu)和Monolith架構(gòu)的共存，就如SQL和NoSQL并存一樣。

10個優(yōu)秀實踐

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

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

1. 微前端

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

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

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

2. 連續(xù)交付

微服務(wù)架構(gòu)的一個關(guān)鍵USP是每個微服務(wù)都可以獨立部署。如果系統(tǒng)有100個微服務(wù)，要求更改一個微服務(wù)，那么可以僅更新一個微服務(wù)，而無需更改其他99個微服務(wù)。

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

3. 微服務(wù)優(yōu)先

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

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

4. 庫的基礎(chǔ)設(shè)施

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

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

5. 域驅(qū)動設(shè)計

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

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

• 軟件開發(fā)團隊應(yīng)與業(yè)務(wù)部門或領(lǐng)域?qū)＜揖o密合作。
• 架構(gòu)師或開發(fā)人員和領(lǐng)域?qū)＜覒?yīng)首先進行戰(zhàn)略設(shè)計：查找有界上下文以及相關(guān)的核心域、通用語言、子域、上下文映射圖。
• 然后，架構(gòu)師或開發(fā)人員應(yīng)進行戰(zhàn)術(shù)設(shè)計，將核心領(lǐng)域分解為細粒度的構(gòu)建基塊：實體、值對象、聚合、聚合根。

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

6. 可觀察性

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

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

7. 統(tǒng)一技術(shù)棧

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

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

8. 每個微服務(wù)的數(shù)據(jù)庫

將復(fù)雜應(yīng)用程序拆分為微服務(wù)模塊后，接下來的挑戰(zhàn)出現(xiàn)了——如何處理數(shù)據(jù)庫?

是否應(yīng)該在微服務(wù)之間共享數(shù)據(jù)庫。這個問題的答案是雙刃劍，有利有弊。

• 一方面，在微服務(wù)之間共享數(shù)據(jù)庫將帶來強大耦合，這與微服務(wù)架構(gòu)的目標恰恰相反。即使數(shù)據(jù)庫中出現(xiàn)微小變化，也需要團隊之間的同步操作。同樣，在一項服務(wù)中，管理事務(wù)和鎖定數(shù)據(jù)庫也具有挑戰(zhàn)性。但是在多個分布式微服務(wù)之間管理事務(wù)或鎖定數(shù)據(jù)庫是一項艱巨的任務(wù)。
• 另一方面，如果每個微服務(wù)都有自己的數(shù)據(jù)庫或?qū)Ｓ帽恚瑒t在微服務(wù)之間交換數(shù)據(jù)就會帶來會打開潘多拉魔盒式的挑戰(zhàn)。因此，許多杰出的軟件工程師都提倡在微服務(wù)之間共享一個實用的解決方案。但是，筆者認為，微服務(wù)完全是一個可持續(xù)和長期的軟件開發(fā)過程。因此，每個微服務(wù)都應(yīng)具有自己的數(shù)據(jù)庫(或?qū)Ｓ帽?。

9. 異步通訊

微服務(wù)架構(gòu)中最具挑戰(zhàn)性的一個設(shè)計決策是服務(wù)之間如何進行通信和共享數(shù)據(jù)。當每個微服務(wù)都有自己的數(shù)據(jù)存儲時，這一點尤為重要。

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

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

10. 組織注意事項

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

希望大家可以閱讀完以上技巧后，可以正確實施微服務(wù)架構(gòu)~