?

在過去的幾年中，我已經(jīng)對處于數(shù)字化轉(zhuǎn)型過程中的多個產(chǎn)品團隊進行了架構(gòu)審查。大多數(shù)團隊都在按照微服務架構(gòu)構(gòu)建產(chǎn)品。他們有使用基于微服務的體系結(jié)構(gòu)的所有正確意圖-更快的開發(fā)，更好的可伸縮性，更小的獨立團隊，獨立的部署，使用正確的技術(shù)來完成工作，等等。但是，我經(jīng)常發(fā)現(xiàn)團隊在微服務方面苦苦掙扎。他們未能充分利用微服務的優(yōu)勢。在這篇文章中，我將分享我認為團隊在微服務方面苦苦掙扎的原因。

微服務架構(gòu)風格是一種將單個整體應用程序開發(fā)為一組小服務的方法，每個小服務都在自己的進程中運行并與輕量級機制（通常是HTTP資源API）進行通信。這些服務圍繞業(yè)務功能構(gòu)建，并且可以由全自動部署機制獨立部署。這些服務的集中管理幾乎沒有，它可以用不同的編程語言編寫并使用不同的數(shù)據(jù)存儲技術(shù)。

?

原因1：管理層低估了開發(fā)微服務的復雜性

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

要開發(fā)微服務，開發(fā)人員需要高效的本地環(huán)境設置。

隨著系統(tǒng)中服務的增加，越來越難在一臺計算機上運行應用程序的子集。當您使用消耗相對較多內(nèi)存的語言（例如Java）構(gòu)建應用程序時，尤其會發(fā)生這種情況。

以下是與本地開發(fā)設置有關(guān)的要點。

?

本地開發(fā)的第一個重要方面是好的開發(fā)機器。我發(fā)現(xiàn)大多數(shù)組織都很難使用所有最新和最先進的技術(shù)，但是他們不想替換性能低下的Windows開發(fā)機器。開發(fā)人員受其開發(fā)機器的限制。我已經(jīng)看到開發(fā)人員使用VDI映像或配置較差的機器來構(gòu)建基于微服務的系統(tǒng)。這降低了他們的生產(chǎn)力，他們無法完全應用自己。使用性能不佳的開發(fā)機器的副作用是開發(fā)人員無法獲得快速反饋。如果您知道必須等待幾分鐘才能運行集成測試套件，那么您寧愿不編寫更多內(nèi)容也不會增加工作量。不良的開發(fā)機器會導致不良的開發(fā)實踐。

一旦有了合理的機器開發(fā)人員就可以工作。接下來的事情是確保所有服務都使用構(gòu)建工具。應該能夠在無需太多配置的情況下在一臺新計算機上構(gòu)建整個應用程序。以我在微服務方面的經(jīng)驗，使用一個root構(gòu)建腳本來構(gòu)建整個應用程序是有幫助的。

下一個重點是使開發(fā)人員能夠輕松地在系統(tǒng)上運行應用程序的某些部分。您應該使用多個docker-compose文件在配置了所有端口和卷的情況下啟動不同的服務。

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

如果組織不了解微服務的開發(fā)復雜性，那么團隊速度將隨著時間下降。

?

原因2：沒有將庫和工具更新到最新版本的過程

新平臺已經(jīng)成為歷史。團隊無法確保依賴關(guān)系保持最新狀態(tài)，或者數(shù)據(jù)庫等工具是否為最新版本。因此，兩年前開始的現(xiàn)代化工作如今已經(jīng)有數(shù)月的技術(shù)債務。

幾年前，許多團隊開始將Spring Cloud Netflix OSS項目用于微服務。他們使用的是Kubernetes之類的容器編排工具，但是由于它們是從Netflix OSS開始的，因此并未使用Kubernetes提供的所有功能。當Kubernetes內(nèi)置服務發(fā)現(xiàn)時，他們?nèi)詫ureka用作服務發(fā)現(xiàn)。此外，借助Istio之類的服務網(wǎng)格，您可以擺脫Netflix OSS提供的大多數(shù)功能。這有助于降低復雜性，并將很多交叉問題轉(zhuǎn)移到平臺上。

要記住的另一點是，要使所有服務的依賴項版本保持同步。我最近在幫助一個使用Spring Boot構(gòu)建微服務的客戶。在過去的兩年中，他們已經(jīng)構(gòu)建了20多個Spring Boot服務。在他們的環(huán)境中，他們使用的Spring Boot版本范圍從1.5到2.1。這意味著當有人設置他們的機器時，他們必須下載多個版本的Spring Boot。此外，他們?nèi)鄙僮?.5以來在Spring Boot中所做的許多改進。

我們的建議是組織應在積壓的訂單中為這些升級創(chuàng)建技術(shù)債務項目。這些技術(shù)債務項目應在架構(gòu)委員會會議上進行討論并定期解決。在我的上一個項目中，我們每三個月設置一個星期的沖刺，以將所有依賴項更新到最新版本。

此外，團隊應該花時間在升級工具上，例如數(shù)據(jù)庫，消息隊列和緩存，以升級到最新版本。

?

原因3：將共享服務用于本地開發(fā)

由于本地開發(fā)環(huán)境不佳，大多數(shù)團隊開始依靠共享環(huán)境提供關(guān)鍵服務。開發(fā)人員機器中的第一件共享就是數(shù)據(jù)庫。大多數(shù)年輕的開發(fā)人員都沒有意識到基于共享數(shù)據(jù)庫的開發(fā)是邪惡的。以下是我在共享數(shù)據(jù)庫中遇到的主要問題：

?

團隊成員必須建立工作的社會契約，以避免最后的寫入勝出問題。開發(fā)人員可以清除另一位開發(fā)人員為其工作編寫的數(shù)據(jù)。這種工作方式既痛苦又容易失敗。遲早這會咬傷團隊。

開發(fā)人員擔心實驗會影響他們的其他團隊成員。我們都知道，更好的學習方法是實驗和快速反饋。有了共享數(shù)據(jù)庫，就可以進行實驗了。我們需要進行實驗以提出數(shù)據(jù)庫架構(gòu)并執(zhí)行性能調(diào)整之類的任務。

另一個副作用是很難單獨測試更改。您的集成測試變得不穩(wěn)定。從而進一步降低了顯影速度。

共享數(shù)據(jù)庫必須像寵物一樣對待，因為您不希望共享數(shù)據(jù)庫具有不一致且不可預測的狀態(tài)。您可能有一個開發(fā)人員想要在表為空但其他人需要表具有記錄的情況下測試邊緣情況。

僅共享數(shù)據(jù)庫具有系統(tǒng)正常工作所需的所有數(shù)據(jù)。隨著時間的流逝，團隊成員失去了更改的可追溯性，因此沒人知道他們?nèi)绾卧谟嬎銠C上復制相同的設置。唯一的方法是獲取完整的數(shù)據(jù)庫轉(zhuǎn)儲并使用它。

未連接到網(wǎng)絡時很難工作。通勤時間長或乘飛機時，通常會發(fā)生這種情況。

數(shù)據(jù)庫只是共享服務的一個示例，但它也可以是消息傳遞隊列，像Redis這樣的集中式緩存或服務可以改變的任何其他服務。

解決此問題的最佳方法是使開發(fā)人員可以輕松地在其本地計算機上運行數(shù)據(jù)庫（作為docker容器），并投資創(chuàng)建SQL腳本來設置架構(gòu)和初始主數(shù)據(jù)。這些SQL腳本應保留在版本控制中，并像其他任何代碼一樣進行維護。

?

原因4：版本控制托管平臺缺乏可見性

一個版本控制系統(tǒng)中具有1000多個存儲庫。他們正在使用Gitlab版本控制平臺。他們有5個產(chǎn)品，每個產(chǎn)品都由多個微服務組成。我問他們的第一個問題是幫助我們了解哪些服務及其各自的代碼存儲庫是產(chǎn)品A的一部分。他們的首席架構(gòu)師不得不花一天的時間弄清楚構(gòu)成產(chǎn)品A的所有存儲庫。不知道她是否涵蓋了所有服務。

解決此問題的最佳方法是從一開始就以某種方式對微服務進行分組，以使您始終對產(chǎn)品生態(tài)系統(tǒng)具有可見性。Gitlab提供了一種創(chuàng)建組，然后在其中創(chuàng)建項目存儲庫的方法。Github沒有組功能，因此您可以使用主題或命名約定來實現(xiàn)它。

我個人更喜歡mono repos，因為我發(fā)現(xiàn)它們真的很方便。我遇到的大多數(shù)開發(fā)人員都將其視為反模式。我同意Dan Lua的帖子，他在文章中提到了mono repo的以下好處

*簡化的組織

*簡化的依賴關(guān)系

*工具

*跨項目變更

?

原因5：沒有明確的服務定義

大多數(shù)團隊都不知道應該將什么視為服務。關(guān)于實際上構(gòu)成單個微服務的東西有很多困惑和困惑。

讓我們舉一個例子，您的應用程序具有類似于插件的架構(gòu)，您將在其中與多個第三方服務集成。每個集成都應該是微服務嗎？我已經(jīng)看到多個團隊正在為每個集成創(chuàng)建一個微服務。隨著集成數(shù)量的增加，這很快變得難以管理。這些服務通常太小，以至于它們作為單獨的進程運行會增加更多的開銷。

我認為擁有少量大型服務總比擁有太多小型服務好。我將首先創(chuàng)建一個對業(yè)務組織中整個部門建模的服務。這也符合DDD。我將一個域分為子域和有界上下文。有界上下文表示公司內(nèi)部的部門，例如財務和市場營銷。您可能認為這可能會導致大型微服務，這是正確的。但是，以我的經(jīng)驗來看，將單體重構(gòu)為微服務總是比反之容易。隨著您獲得更多的知識，您可以轉(zhuǎn)向代表較小關(guān)注點的細粒度微服務。您可以應用“單一責任原則”來了解您的微服務是否變得太大而做太多的事情。然后，您可以將其分解為較小的獨立服務。任何服務都不應直接與另一個服務的數(shù)據(jù)庫對話。他們只能通過已發(fā)布的服務合同進行溝通。

我也遵循后端文檔中提到的建議。該建議可以幫助限制服務之間的服務通信，這是基于微服務的系統(tǒng)性能低下的首要原因。

如果兩條信息相互依賴，則它們應屬于一臺服務器。換句話說，服務的自然邊界應該是其數(shù)據(jù)的自然邊界。

?

原因6：沒有明確的代碼重用策略

我正在與一個客戶一起工作，該客戶已在其所有基于Java的微服務中復制了四個與特定問題相關(guān)的Java文件。因此，如果在該代碼中發(fā)現(xiàn)錯誤，則需要將其應用到所有地方。我們都知道，在時間壓力下，我們會錯過將更改應用于一項或多項服務的機會。這將浪費更多時間并增加挫敗感。

不是說開發(fā)團隊不知道正確的事情。但是，組織的結(jié)構(gòu)化方式人們總是默認使用簡單且容易出錯的做事方式。

正確的方法是使用工件管理器（如Bintray或Nexus）并在其中發(fā)布依賴項。然后，每個微服務都應依賴該庫。您需要構(gòu)建工具，以便在發(fā)布新版本的庫時，應更新并重新部署所有微服務。

使用微服務并不意味著您不應使用迄今為止對我們有用的最佳實踐。您需要在工具上進行投資，以使其易于升級微服務。

在沒有適當工具和自動化的情況下使用微服務是災難的根源。

?

原因7：多種語言編程

我碰到了使用多種編程語言，多個數(shù)據(jù)庫，多個緩存的團隊，這是工作的最佳工具。所有這些都在項目的初始階段起作用，但是當您的產(chǎn)品投入生產(chǎn)時，這些選擇就開始顯示出它們的真實色彩。諸如我們在構(gòu)建Java Spring Boot應用程序之類的原因，但我們意識到Java消耗了更多的內(nèi)存，并且性能很差，因此我們決定切換到Node.js。在上一個任務中，我向團隊解釋說他們的推理能力很弱。

?

Node.js的性能優(yōu)于Java。如果您有基于IO的工作負載，則Node.js通常會表現(xiàn)更好。Java?在任何計算密集型工作負載上均勝過?node.js。通過使用響應式范例，Java for IO工作負載可以具有更好的性能。Spring Boot Reactor在IO工作負載方面的性能與Node.js?相當。

Node.js消耗的內(nèi)存少于Java。這部分是正確的，因為Node.js應用程序通常使用的內(nèi)存少于Java。Java Spring Boot應用程序并不像大多數(shù)人想象的那樣糟糕。我在其中一個Spring Boot Java Microservice上進行了負載測試，并且內(nèi)存消耗仍然少于1 GB。您可以通過OpenJ9 JVM，限制對類路徑的依賴性以及通過調(diào)整默認JVM參數(shù)來優(yōu)化Java內(nèi)存利用率。另外，Java中的Spring Boot也有其他替代方法，例如Micronaut和Quarkus，它們消耗的內(nèi)存等于Node.js。

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

大多數(shù)時候，這全都取決于上下文。如果您的開發(fā)人員不成熟，則無論使用哪種編程語言，您都將開發(fā)出不良的產(chǎn)品。

我建議組織發(fā)布團隊可以使用的語言列表。我認為2–3是個好數(shù)字。另外，列出為什么應使用一種語言代替另一種語言的原因。

選擇語言之前，應考慮以下多種原因：

?

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

重新培訓開發(fā)人員使用新技術(shù)有多容易？我們發(fā)現(xiàn)Java開發(fā)人員可以相對輕松地學習Golang。

最初團隊之外的開發(fā)人員可以多么容易地貢獻，傳輸和維護他人編寫的代碼？

就工具和庫而言，生態(tài)系統(tǒng)的成熟程度如何？

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

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

?

原因8：人們依賴性

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

我認為最好的辦法是確保所有團隊在架構(gòu)小組中只有一個代表部分，以便他們可以使團隊與整體架構(gòu)團隊的路線圖和目標保持一致。要成為一個成熟的組織，您需要投資建立輕量級的治理。

?

原因9：缺少文檔

過去幾年中與我們互動的大多數(shù)組織都在文檔方面苦苦掙扎。大多數(shù)開發(fā)人員和架構(gòu)師要么不編寫文檔，要么他們編寫的文檔沒有用。即使他們想寫，他們也不知道應該如何記錄其體系結(jié)構(gòu)。

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

?

設計文件

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

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

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

我建議所有文檔都保留在版本控制系統(tǒng)中。

?

原因10：功能超過平臺成熟度

我在其他方面簡要地談到了這個原因，但是我認為值得一提的是頂級原因。微服務比傳統(tǒng)的單片單體應用程序更為復雜，因為您正在構(gòu)建具有許多活動部件的分布式系統(tǒng)。大多數(shù)開發(fā)人員尚未理解系統(tǒng)的不同故障模式。大多數(shù)微服務在構(gòu)建時都考慮了一條愉快的路。因此，如果您的管理層只想早于專注于功能，那么您將失敗。在弱平臺上構(gòu)建的功能無法帶來價值。

組織需要進入平臺心態(tài)。平臺心態(tài)不僅意味著使用容器和Kubernetes。它們是解決方案的一部分，但本身并不是完整的解決方案。您需要考慮分布式跟蹤，可觀察性，混亂測試，函數(shù)調(diào)用與網(wǎng)絡調(diào)用，服務間通信的安全服務，可調(diào)試性等。這需要大量的精力和投資來建立合適的平臺和工具團隊。

如果您是一家資源有限的初創(chuàng)公司，我的建議是重新考慮您的微服務策略。請了解您正在進入什么。

?

原因11：缺乏自動化測試

大多數(shù)團隊都知道自動化測試對產(chǎn)品的整體質(zhì)量有多重要，但他們?nèi)匀粵]有做到。微服務架構(gòu)為在何處以及如何進行測試提供了更多選擇。如果您不進行全面的自動化測試，那么您將嚴重失敗。

?

原因12：您甚至無法構(gòu)建結(jié)構(gòu)良好的單體架構(gòu)。

總結(jié)

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

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