Shekhar Gulati

讀完需要

10

分鐘

速讀僅需 3 分鐘

作者 | Shekhar Gulati@Medium

譯者 |?Sambodhi

策劃 | Tina@infoq

微服務(wù)“很香”，它有許多優(yōu)勢(shì)，比如更快的開發(fā)、更好的可擴(kuò)展性、更小的獨(dú)立團(tuán)隊(duì)等等。但是，很多團(tuán)隊(duì)卻在微服務(wù)上舉步維艱，沒有很好利用其優(yōu)勢(shì)。原因到底是什么？這是本文作者試圖回答的。

過去幾年，我對(duì)推進(jìn)數(shù)字化轉(zhuǎn)型的多家產(chǎn)品團(tuán)隊(duì)進(jìn)行了架構(gòu)審查。我發(fā)現(xiàn)：大多數(shù)團(tuán)隊(duì)都是遵循微服務(wù)架構(gòu)來構(gòu)建產(chǎn)品。更快的開發(fā)、更好的可擴(kuò)展性、更小的獨(dú)立團(tuán)隊(duì)、獨(dú)立部署和使用正確的技術(shù)來完成工作等等，這些優(yōu)勢(shì)讓他們有充足的理由采用微服務(wù)架構(gòu)。

但是，我經(jīng)常發(fā)現(xiàn)：很多團(tuán)隊(duì)在微服務(wù)上舉步維艱。他們并未充分利用微服務(wù)的優(yōu)勢(shì)。為什么許多團(tuán)隊(duì)在微服務(wù)之路上“舉步維艱”？這是我試圖回答的。

如果你是微服務(wù)新手，我推薦你閱讀 Martin Fowler 關(guān)于微服務(wù)的文章。

https://martinfowler.com/articles/microservices.html

這篇文章闡釋了何為微服務(wù)架構(gòu)：

微服務(wù)架構(gòu)的風(fēng)格是一種將單個(gè)應(yīng)用程序開發(fā)成一套小型服務(wù)的方法，每個(gè)應(yīng)用程序都在自己的進(jìn)程中運(yùn)行，并與輕量級(jí)機(jī)制（通常是 HTTP 資源 API）進(jìn)行通信。這些服務(wù)是圍繞業(yè)務(wù)功能而構(gòu)建的，并且可以由完全自動(dòng)化的部署機(jī)制來獨(dú)立部署。這些服務(wù)只有最低限度的集中管理，可以用不同的編程語言編寫，并使用不同的數(shù)據(jù)存儲(chǔ)技術(shù)。

1

? ?

管理層低估開發(fā)微服務(wù)的復(fù)雜性

我曾與許多非常看好微服務(wù)的客戶一起合作過。對(duì)他們來說，微服務(wù)就是解決他們所有問題的靈丹妙藥。在與我討論中，我發(fā)現(xiàn)大多數(shù)團(tuán)隊(duì)及其管理層低估了微服務(wù)開發(fā)的復(fù)雜性。

要開發(fā)微服務(wù)，開發(fā)人員需要一個(gè)高效的本地環(huán)境設(shè)置。

隨著系統(tǒng)中的服務(wù)數(shù)量開始增加，在一臺(tái)機(jī)器上運(yùn)行應(yīng)用程序的子集變得越來越困難。特別是當(dāng)你使用消耗較多內(nèi)存的語言（如 Java）構(gòu)建應(yīng)用程序時(shí)，更是如此。

下面是與本地開發(fā)設(shè)置相關(guān)的要點(diǎn)。

本地開發(fā)的第一個(gè)重要方面是要有一個(gè)好的開發(fā)機(jī)器。我發(fā)現(xiàn)，大多數(shù)組織想要使用所有最新的、最先進(jìn)的技術(shù)，但卻不想替換掉糟糕的 Windows 開發(fā)機(jī)器。開發(fā)人員受限于他們的開發(fā)機(jī)器。我曾見過開發(fā)人員使用 VDI 映像或配置交叉的機(jī)器來構(gòu)建基于微服務(wù)的系統(tǒng)。這降低了他們的工作效率，使他們無法完全投入工作。使用糟糕的開發(fā)機(jī)器帶來的副作用就是，開發(fā)人員無法得到快速的反饋。如果你知道必須等待數(shù)分鐘才能運(yùn)行集成測(cè)試套件，那么你就不會(huì)編寫更多的集成測(cè)試套件，免得給你帶來痛苦。糟糕的開發(fā)機(jī)器將會(huì)導(dǎo)致糟糕的開發(fā)實(shí)踐。

一旦你為開發(fā)人員配備了合適的開發(fā)機(jī)器，那么下一步就是確保所有服務(wù)都使用構(gòu)建工具。你應(yīng)該能夠在一臺(tái)新機(jī)器上構(gòu)建整個(gè)應(yīng)用程序，而不需要進(jìn)行太多配置。根據(jù)我在微服務(wù)方面的經(jīng)驗(yàn)，使用能夠構(gòu)建整個(gè)應(yīng)用程序的根構(gòu)建腳本也會(huì)有所幫助。

下一個(gè)要點(diǎn)就是要讓開發(fā)人員能夠輕松地在他們的系統(tǒng)上運(yùn)行應(yīng)用程序的各個(gè)部分。在配置了所有端口和卷的情況下，你應(yīng)該使用多個(gè)?docker-compose?文件來提供不同的服務(wù)。

接下來，如果你使用的是類似于 Kubernetes 的容器編排工具，那么你應(yīng)該投資類似于 Telepresence 這樣的工具，以便輕松調(diào)試 Kubernetes 集群中的應(yīng)用程序。

如果組織對(duì)微服務(wù)開發(fā)的復(fù)雜性缺乏理解，那么團(tuán)隊(duì)的速度將會(huì)隨著時(shí)間的推移而下降。

2

? ?

沒有將庫和工具更新到最新版

在我看來，我發(fā)現(xiàn)一個(gè)新的平臺(tái)已經(jīng)成為一種遺產(chǎn)。團(tuán)隊(duì)沒有確保依賴項(xiàng)是最新的版本，或者將像數(shù)據(jù)庫這樣的工具升級(jí)到最新版本。因此，兩年前開始的現(xiàn)代化改造，如今已經(jīng)背負(fù)了長(zhǎng)達(dá)數(shù)月的技術(shù)債務(wù)。

幾年前，許多團(tuán)隊(duì)開始將 Spring Cloud Netflix OSS 項(xiàng)目用于微服務(wù)。他們使用像 Kubernetes 這樣的容器編排工具，但是因?yàn)樗麄兪菑?Netflix OSS 開始的，所以他們沒有使用 Kubernetes 提供的所有功能。當(dāng) Kubernetes 內(nèi)置了服務(wù)發(fā)現(xiàn)時(shí)，他們?nèi)匀皇褂?Eureka 作為服務(wù)發(fā)現(xiàn)。此外，通過類似 Lstio 這樣的服務(wù)網(wǎng)格，你就可以擺脫 Netflix OSS 提供的大部分服務(wù)。這有助于降低復(fù)雜性，并將許多“橫向關(guān)注點(diǎn)”（cross cutting concerns）轉(zhuǎn)移到平臺(tái)上。

需要記住的另一點(diǎn)是，要使所有服務(wù)的依賴項(xiàng)版本保持同步。我最近在幫助一個(gè)客戶，他使用 Spring Boot 來構(gòu)建微服務(wù)。在過去兩年中，他們已經(jīng)構(gòu)建了 20 多個(gè) Spring Boot 服務(wù)。在他們的環(huán)境中，他們使用的 Spring Boot 版本從 1.5 到 2.1 不等。這意味著當(dāng)有人設(shè)置他們的機(jī)器時(shí)，他們必須下載多個(gè)版本的 Spring Boot。此外，他們還缺乏自版本 1.5 以來在 Spring Boot 中所做的許多改進(jìn)。

我們的建議是，組織應(yīng)該在其積壓中為這些升級(jí)創(chuàng)建技術(shù)債務(wù)項(xiàng)。這些技術(shù)債務(wù)項(xiàng)應(yīng)作為架構(gòu)委員會(huì)會(huì)議的一部分加以討論，并定期予以解決。在我的上一個(gè)項(xiàng)目中，我們每三個(gè)月設(shè)置為期一周的 sprint，將所有依賴項(xiàng)更新到最新版本。

3

? ?

利用共享服務(wù)促進(jìn)本地開發(fā)

由于本地開發(fā)狀況不佳，大多數(shù)團(tuán)隊(duì)開始依賴于共享環(huán)境來獲得關(guān)鍵服務(wù)。開發(fā)人員機(jī)器中的第一件事就是數(shù)據(jù)庫。大多數(shù)年輕的開發(fā)人員并沒有意識(shí)到基于共享數(shù)據(jù)庫的開發(fā)是“邪惡的”。下面，是我在共享數(shù)據(jù)庫中看到的主要問題：

團(tuán)隊(duì)成員必須建立一個(gè)工作的社會(huì)契約，以避免最后寫入者勝出（Last write wins，LWW）問題。一個(gè)開發(fā)人員可以刪除其他開發(fā)人員為他們的工作編寫的數(shù)據(jù)。這種工作方式既痛苦又容易失敗，遲早會(huì)影響整個(gè)團(tuán)隊(duì)。

開發(fā)人員害怕實(shí)驗(yàn)，因?yàn)樗麄兊墓ぷ鲿?huì)影響其他團(tuán)隊(duì)成員。我們都知道，更好的學(xué)習(xí)方法是實(shí)驗(yàn)和快速反饋。有了共享數(shù)據(jù)庫，就可以進(jìn)行實(shí)驗(yàn)了。我們需要進(jìn)行實(shí)驗(yàn)，以提出數(shù)據(jù)庫模式，并執(zhí)行任務(wù)，如性能調(diào)優(yōu)之類。

另一個(gè)副作用就是，很難單獨(dú)測(cè)試更改。你的集成測(cè)試將變得不可靠，從而進(jìn)一步降低了開發(fā)速度。

共享數(shù)據(jù)庫必須像寵物一樣對(duì)待，因?yàn)槟悴幌Ｍ霈F(xiàn)不一致和不可預(yù)測(cè)的狀態(tài)。你可能會(huì)遇到這樣一種場(chǎng)景，開發(fā)人員希望在表是空的時(shí)候測(cè)試邊緣情況，但其他開發(fā)人員需要一個(gè)表來記錄。

只有共享數(shù)據(jù)庫擁有系統(tǒng)工作所需的所有數(shù)據(jù)。隨著時(shí)間的推移，團(tuán)隊(duì)成員失去了更改的可追溯性，因此沒有人知道，他們?cè)撊绾卧谒麄兊臋C(jī)器上復(fù)制相同的設(shè)置。唯一的方法是獲取完整的數(shù)據(jù)庫轉(zhuǎn)儲(chǔ)并使用它。

如果未連接到網(wǎng)絡(luò)，就很難開展工作。這種情況通常發(fā)生在你通勤時(shí)間過長(zhǎng)或乘飛機(jī)的時(shí)候。

數(shù)據(jù)庫只是共享服務(wù)的一個(gè)示例，但它也可以是消息隊(duì)列、集中緩存（如 Redis）或任何其他服務(wù)可以發(fā)生改變的服務(wù)。

解決這一問題的最好方法是，讓開發(fā)人員可以輕松地在他們的機(jī)器上運(yùn)行數(shù)據(jù)庫（作為 Docker 容器），并投資創(chuàng)建 SQL 腳本來設(shè)置模式和初始主數(shù)據(jù)。這些 SQL 腳本應(yīng)該保存在版本控制中，并像維護(hù)任何其他代碼一樣進(jìn)行維護(hù)。

4

? ?

版本控制托管平臺(tái)缺乏可見性

我曾與一個(gè)客戶進(jìn)行合作，當(dāng)時(shí)，他們的版本控制系統(tǒng)中有 1000 多個(gè)倉庫。他們使用的是 Gitlab 版本控制平臺(tái)。他們有 5 個(gè)產(chǎn)品，每個(gè)產(chǎn)品都由多個(gè)微服務(wù)組成。我問他們的第一個(gè)問題是幫助我們了解哪些服務(wù)及其各自代碼庫是產(chǎn)品 A 的一部分。他們的首席架構(gòu)師不得不花一天時(shí)間弄清楚所有產(chǎn)品 A 的倉庫。一天過去了，她還是不能確定是否弄清楚了所有的服務(wù)。

解決這個(gè)問題的最好方法是，從一開始就以某種方式對(duì)你的微服務(wù)進(jìn)行分組，這樣，你就可以隨時(shí)了解產(chǎn)品的生態(tài)系統(tǒng)。Gitlab 提供了一種方法來創(chuàng)建一個(gè)組，然后在其中創(chuàng)建項(xiàng)目倉庫。Github 并沒有組功能，因此你可以使用主題或命名約定來實(shí)現(xiàn)它。

我個(gè)人更喜歡 mono repos，因?yàn)槲野l(fā)現(xiàn)他們真的很方便。我遇到的大多數(shù)開發(fā)人員都認(rèn)為它是一種反模式。我同意 Dan Lua 的觀點(diǎn)，他提到了 mono repo 的以下好處：

• 簡(jiǎn)化的組織

• 簡(jiǎn)化的依賴關(guān)系

• 工具

• 跨項(xiàng)目變更

5

? ?

服務(wù)沒有明確定義

大多數(shù)團(tuán)隊(duì)并不知道什么應(yīng)該被視為服務(wù)。關(guān)于究竟是什么構(gòu)成一個(gè)單一的微服務(wù)，人們對(duì)此存在很多混淆的認(rèn)識(shí)和困惑的概念。讓我們舉一個(gè)例子，假設(shè)你的應(yīng)用程序具有類似插件的架構(gòu)，在這個(gè)架構(gòu)中，你集成了多個(gè)第三方服務(wù)。每個(gè)集成應(yīng)該是一個(gè)微服務(wù)嗎？我看到很多團(tuán)隊(duì)，都在為每個(gè)集成創(chuàng)建一個(gè)微服務(wù)。隨著集成數(shù)量的增加，這種情況很快就會(huì)失控，以至于無法管理。這些服務(wù)通常太小，以至于將它們作為單獨(dú)的進(jìn)程運(yùn)行，會(huì)增加更多的開銷。

我認(rèn)為，哪怕只擁有少量的大型服務(wù)，總比提供太多的小型服務(wù)要好得多。我將從創(chuàng)建一個(gè)服務(wù)開始，該服務(wù)對(duì)業(yè)務(wù)組織中的整個(gè)部門進(jìn)行建模。這也符合 DDD（領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)， Domain Driven Design）。我將一個(gè)域分為子域和有界上下文。有界上下文表示公司內(nèi)部的一個(gè)部門，如財(cái)務(wù)部門和營(yíng)銷部門。你可能認(rèn)為，這會(huì)導(dǎo)致大型服務(wù)的出現(xiàn)，你是對(duì)的。但是，以我的經(jīng)驗(yàn)來看，將整體重構(gòu)為微服務(wù)總之比反之更容易。隨著你的知識(shí)經(jīng)驗(yàn)越來越多，你可以轉(zhuǎn)向代表更小問題的細(xì)粒度微服務(wù)。你可以應(yīng)用單一責(zé)任原則（Single Responsibility Principle）來了解你的微服務(wù)是否變得過大，做的事情是否過多。然后，你可以將它分解成更小的獨(dú)立服務(wù)。任何服務(wù)都不應(yīng)該直接與其他服務(wù)的數(shù)據(jù)庫通信。他們應(yīng)該只通過已發(fā)布的合同進(jìn)行溝通。你可以在 Microservices.io 網(wǎng)站上關(guān)于按子域模式分解?的內(nèi)容。

我也遵循了?Backendlore 文檔中提到的建議。這個(gè)建議可以幫助將服務(wù)限制在服務(wù)通信上，而服務(wù)通信是微服務(wù)系統(tǒng)性能低下的首要原因。如果兩條信息相互依賴，那么它們應(yīng)該屬于同一個(gè)服務(wù)器。換句話說，服務(wù)的自然邊界應(yīng)該是其數(shù)據(jù)的自然邊界。

6

? ?

代碼重用策略不明確

我曾經(jīng)和一個(gè)客戶合作，該客戶在他們所有基于 Java 的微服務(wù)復(fù)制了四個(gè)與特定問題相關(guān)的 Java 文件。因此，如果在該代碼中發(fā)現(xiàn) bug 的話，就需要將其修復(fù)應(yīng)用到所有地方。我們都知道，在時(shí)間緊迫的情況下，我們會(huì)錯(cuò)過將更改應(yīng)用于一個(gè)或多個(gè)服務(wù)。這樣會(huì)浪費(fèi)更多的時(shí)間，增加挫敗感。

這并非說開發(fā)團(tuán)隊(duì)不懂正確的事情。但是，按照組織結(jié)構(gòu)，人們總是默認(rèn)采用簡(jiǎn)單且容易出錯(cuò)的做事方式。

正確的方法是，使用像 Bintray 或 Nexus 這樣的工件管理器，并在那里發(fā)布依賴項(xiàng)。然后，每個(gè)微服務(wù)都應(yīng)該依賴于這個(gè)庫。你需要構(gòu)建工具，以便在發(fā)布新版本的庫時(shí)，所有的微服務(wù)都應(yīng)該進(jìn)行更新和重新部署。

使用微服務(wù)并不意味著你不應(yīng)該使用迄今為止對(duì)我們有用的最佳實(shí)踐。你需要對(duì)工具進(jìn)行投資，使微服務(wù)的升級(jí)變得更容易，這樣人們就不必這樣做了。

在沒有適合的工具和自動(dòng)化的情況下，使用微服務(wù)會(huì)導(dǎo)致災(zāi)難。

7

? ?

多語言編程設(shè)計(jì)

我發(fā)現(xiàn)團(tuán)隊(duì)使用多種編程語言、多種數(shù)據(jù)庫、多種緩存，并以最佳工具的名義進(jìn)行工作。所有這些都在項(xiàng)目的初始階段起作用，但隨著你的產(chǎn)品投入生產(chǎn)，這些選擇開始顯露出它們的本色。原因就像我們?cè)跇?gòu)建 JavaSpringBoot 應(yīng)用程序，但是我們意識(shí)到 Java 占用了更多的內(nèi)存，且性能也很差，所以我們決定改用 Node.js。在我上一次任務(wù)中，我向團(tuán)隊(duì)解釋說他們的推理能力很弱。

Note.js 比 Java 性能更好。?如果你的工作負(fù)載是基于 I/O 的，Node.js 通常會(huì)表現(xiàn)的更好。但在任何計(jì)算密集型的工作負(fù)載上，Java 都勝過?Node.js。通過響應(yīng)式范式（reactive paradigm），你可以使用 Java 為 I/O 工作負(fù)載提供更好的性能。在 I/O 工作負(fù)載方面，Spring Boot Reactor 的性能相當(dāng)于 Node.js。

Node.js 比 Java 消耗更少的內(nèi)存。?這在一定程度上是正確的說法。Java Spring Boot 應(yīng)用程序并不像大多數(shù)想象的那么糟糕。我在一個(gè) Spring Boot Java 微服務(wù)上運(yùn)行了負(fù)載測(cè)試，內(nèi)存消耗仍然沒超過 1 GB。你可以通過 OpenJ9 JVN，限制對(duì)類路徑的依賴，并通過調(diào)優(yōu)默認(rèn)的 JVM 參數(shù)來優(yōu)化 Java 內(nèi)存利用率。此外，在 Java 中還有 Spring Boot 的新替代品，如 Micronaut 和 Quarkus，它們消耗的內(nèi)存相當(dāng)于 Node.js。

Node.js 比 Java 效率更高。?這取決于編寫代碼的開發(fā)人員。使用靜態(tài)類型和靜態(tài)分析工具的 Java 可以幫助在開發(fā)生命周期的早期發(fā)現(xiàn)問題。

大多數(shù)情況下，這完全取決于上下文。如果你的開發(fā)人員還不夠成熟的話，那么無論你使用什么編程語言，你開發(fā)的都將是糟糕的產(chǎn)品。

我建議一家組織要發(fā)布一個(gè)團(tuán)隊(duì)可以使用的語言列表。我認(rèn)為 2~3 就是個(gè)很不錯(cuò)的數(shù)字。另外，要列出一種語言比另一種語言更適合的理由。

在選擇一門語言之前，你應(yīng)該考慮以下一些問題：

找到成熟的企業(yè)軟件開發(fā)人員有多容易？

重新培訓(xùn)開發(fā)人員掌握新技術(shù)有多容易？我們發(fā)現(xiàn) Java 開發(fā)人員可以相對(duì)容易地學(xué)習(xí) Golang。

初始團(tuán)隊(duì)之外的開發(fā)人員貢獻(xiàn)、轉(zhuǎn)移和維護(hù)其他人編寫的代碼有多容易？

就工具和庫的方面而言，生態(tài)系統(tǒng)有多成熟？

這不僅僅局限于編程語言，也適用于數(shù)據(jù)庫領(lǐng)域。如果你的系統(tǒng)中已經(jīng)有了 MongoDB，那么你為什么要在生態(tài)系統(tǒng)中使用 ArangoDB 呢？它們都主要是文檔數(shù)據(jù)庫。

要始終考慮使用多種技術(shù)的維護(hù)和操作方面。

8

? ?

人員的依賴性

這并非微服務(wù)特有的現(xiàn)象，但在微服務(wù)生態(tài)系統(tǒng)中卻變得更加普遍。原因是，大多數(shù)團(tuán)隊(duì)專注于他們的特定服務(wù)，因此他們并不了解完整的生態(tài)系統(tǒng)。在我與不同客戶的工作中，我發(fā)現(xiàn)，只有一群架構(gòu)師了解整體情況。但是，這些架構(gòu)師的問題在于，他們并不積極參與日常活動(dòng)，因此他們對(duì)開發(fā)的影響力是有限的。

我認(rèn)為最好的辦法是，確保所有團(tuán)隊(duì)都有一個(gè)架構(gòu)團(tuán)隊(duì)的代表，這樣他們就可以使他們的團(tuán)隊(duì)與整個(gè)架構(gòu)團(tuán)隊(duì)的路線圖和目標(biāo)保持一致了。要成為一個(gè)成熟的組織，你需要投資于建立一個(gè)輕量級(jí)的治理。

9

? ?

文檔的缺乏

在過去幾年里，我們接觸過的大多數(shù)組織都在文檔方面遇到了困難。大多數(shù)開發(fā)人員和架構(gòu)師要么不去編寫文檔，要么編寫的文檔毫無用處。即使他們想寫，他們也不知道應(yīng)該如何記錄他們的架構(gòu)。

我們至少應(yīng)該記錄以下內(nèi)容：

設(shè)計(jì)文檔。

C4 模型中的上下文和容器圖。

以架構(gòu)決策記錄的形式跟蹤關(guān)鍵架構(gòu)決策。

開發(fā)人員入門指南。

我建議在版本控制系統(tǒng)中維護(hù)所有的文檔。

10

? ?

功能超過平臺(tái)成熟度

我已經(jīng)在其他觀點(diǎn)中簡(jiǎn)要地提到了這個(gè)原因，但我認(rèn)為，它值得作為一個(gè)頂級(jí)原因來提及。微服務(wù)要比傳統(tǒng)的單體式應(yīng)用（monolithic application）更為復(fù)雜，因?yàn)槟阏跇?gòu)建一個(gè)包含許多活動(dòng)部件的分布式系統(tǒng)。大多數(shù)開發(fā)人員還不了解系統(tǒng)的不同故障模式。大多數(shù)微服務(wù)在構(gòu)建時(shí)都考慮了令人快樂的路徑。因此，如果你的管理層只想僅僅關(guān)注功能，那么你注定會(huì)失敗。因?yàn)樵诒∪跗脚_(tái)上構(gòu)建的功能是無法提供價(jià)值的。

組織需要有平臺(tái)思維。平臺(tái)思維可不僅僅意味著使用容器和 Kubernetes。它們是解決方案的一部分，但本身并非完整的解決方案。你還需要考慮分布式跟蹤、可觀察性、混沌測(cè)試、函數(shù)調(diào)用與網(wǎng)絡(luò)調(diào)用、服務(wù)間通信的安全服務(wù)、可調(diào)試性等等。這需要在構(gòu)建正確的平臺(tái)和工具團(tuán)隊(duì)方面付出認(rèn)真的努力和投資。

如果你是一家資源有限的初創(chuàng)公司，我的建議是，你要重新考慮微服務(wù)戰(zhàn)略。了解你所面臨的問題是什么。

11

? ?

缺乏自動(dòng)化測(cè)試

大多數(shù)團(tuán)隊(duì)都知道自動(dòng)化測(cè)試對(duì)產(chǎn)品的整體質(zhì)量有多重要，但是他們?nèi)匀粵]有做到。微服務(wù)架構(gòu)為測(cè)試地點(diǎn)和測(cè)試方式提供了更多的選擇。如果你不進(jìn)行徹底的自動(dòng)化測(cè)試，那么你將會(huì)失敗得很慘。關(guān)于這一點(diǎn)，我不會(huì)再贅述，因?yàn)榫W(wǎng)上很多人都寫過這方面的內(nèi)容了。下圖是我從微服務(wù)測(cè)試的文章找到的，這篇文章來自 Martin Fowler 的網(wǎng)站，討論了基于微服務(wù)的系統(tǒng)的測(cè)試金字塔。

微服務(wù)測(cè)試金字塔

參考鏈接：

https://medium.com/xebia-engineering/11-reasons-why-you-are-going-to-fail-with-microservices-29b93876268b

想要加入中生代架構(gòu)群的小伙伴，請(qǐng)?zhí)砑尤汉匣锶?strong>大白的微信

申請(qǐng)備注（姓名+公司+技術(shù)方向）才能通過哦！

? ?END ? ?? #接力技術(shù)，鏈接價(jià)值#精彩推薦1.?業(yè)務(wù)上云后，58到家運(yùn)維平臺(tái)的演進(jìn)之路（含成本規(guī)劃與監(jiān)控建議）2.?為什么阿里巴巴禁止使用存儲(chǔ)過程？ 3.?停！你不需要微服務(wù) 4.?手哥架構(gòu)寶典系列：支付系統(tǒng)2.0架構(gòu)演進(jìn)漫畫推薦1.?漫畫：程序員和產(chǎn)品經(jīng)理撕得真是太太太太厲害了 2.?漫畫：程序員真的是太太太太太太太太難了！3.?漫畫：普通程序員 vs 優(yōu)秀程序員 4.?漫畫：35歲的IT何去何從？ 5.?漫畫：從修燈泡來看各種 IT 崗位，你是哪一種？ 6. 漫畫：一批90后已經(jīng)30歲了，更扎心的是…7. 圖解：這才是程序員加班的真正原因！8.?漫畫：中國互聯(lián)網(wǎng)往事(2000-2020)有愛心的你會(huì)點(diǎn)在看么？ 點(diǎn)擊閱讀原文跳轉(zhuǎn)infoq原文譯文

總結(jié)

以上是生活随笔為你收集整理的导致微服务失败的 11 个原因的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。