微服務架構：優缺點

微服務是將大型應用程式分解為鬆散耦合的模組的一種方法，這些模組透過簡單的 API 相互通訊。 最近，只有啞巴不談論微服務。這正變得越來越流行。模組化架構風格似乎特別適合基於雲端的環境，並且越來越受歡迎。在討論細節之前，讓我們先鳥瞰一下一切。因此：微服務是將大型專案分解為小型、獨立且鬆散耦合的模組的一種方式。獨立模組負責明確定義的離散任務，並透過簡單且可存取的 API 相互通訊。換句話說，微服務只是一種用於設計複雜的、主要是 Web 應用程式的不同架構風格。但是現有的架構解決方案（例如 SOA（服務導向的架構））有什麼不好呢？大多數使用 SOA 編寫的現代企業解決方案似乎都運作良好。現在可能是討論該行業目前面臨的一些挑戰的好時機……讓我們從一個簡單的例子開始。假設我需要運行一個用 Java 編寫的經典應用程式。首先，我將開發使用者介面，然後是業務邏輯層，其中包含幾個與 UI 互動的元件，最後是資料庫層，持久資料庫可以存取該層。現在根據我想要運行應用程式的事實，我將創建一個 WAR/EAR/JAR 並將其安裝在伺服器上（例如 JBoss、Tomcat 或 WebLogic）。由於這是全部完成的，我得到了一個整體應用程序，這意味著所有組件都在一個地方......圖中的示例： 您很可能已經熟悉並使用過這種方法，但我們的想法是使用此範例來展示開發人員在使用此架構解決方案時將面臨哪些挑戰。 單體應用：挑戰挑戰

• 隨著應用程式的成長，編寫的程式碼量也會增加，每次需要開啟它時，這很可能會使開發環境超載。這無疑降低了開發人員的效率。
• 由於所有東西都必須安裝在一個地方，這導致切換到另一種程式語言或切換到其他技術是一個大問題。例如，你用 Java 編寫了一個應用程序，過了一段時間 Kotlin 出現了，你渴望重寫它，因為它被宣傳為更酷、更好、更快。對於整體應用程序，即使考慮重構也會帶來真正的痛苦，更不用說這個過程本身了。目前有許多應用程式都是這樣製作的，程式碼行數簡直令人難以置信。
• 如果任何元件因任何原因停止運作，整個應用程式也會崩潰。試想一下，有一個Web應用程序，有授權、付款、歷史記錄等模組。由於某種原因，其中一個壞了。這對企業以及開發人員來說簡直是個衝擊。
• 擴展單一應用程式只能透過提升同一類型的另一個應用程式來實現。但是，如果您只需要擴展一個元件，而不是整個應用程序，該怎麼辦？會浪費多少資源？...
• 這會對應用程式的開發過程和安裝過程產生很大影響。應用程式越大，開發人員將應用程式劃分為更小的工作部分就越重要。由於單體應用程式中的所有模組都是相互連接的，因此開發人員無法彼此獨立地工作/安裝這些模組。由於開發人員相互依賴，因此開發時間會增加。

同時，我們準備考慮和理解微服務的含義，即如何使用它們來恢復 SOA 風格所失去的靈活性。 God Microservices 來救援 任何架構解決方案中最重要的特徵之一就是可擴充性。當我第一次學習微服務時，我發現一切都與《可擴展性的藝術》一書中的引述如此相似。這是一個很好的開始和討論的地方。本書定義了所謂的「Scalability Cube」模型，它描述了一個三維的可擴展性系統： 正如你所看到的，X軸描述了「水平擴展」（我們已經看到這也適用於單體架構），Y軸表示分離不同服務組件 意義上的擴展。當資料被劃分並且應用程式將請求發送到資料所在的確切位置時，就了解Z軸的想法。也就是說，它們並不都在一處。Y 軸的想法是我們將更詳細地關注的一個。此軸代表功能分解。在該策略中，不同的功能可以被視為獨立的服務。因此，透過僅在一切完成後才安裝整個應用程序，開發人員可以獨立地安裝各個服務，而不必等待其他人完成其模組的工作。這不僅可以縮短開發時間，還可以靈活地進行更改和重新連線，而無需擔心應用程式元件的其餘部分。讓我們將此圖與先前的單片圖進行比較： 微服務：優勢 微服務的優勢似乎足以說服 Amazon、Netflix、Ebay 等企業開發人員開始使用這種方法。與整體架構應用程式不同，微服務：

• 改進組件故障隔離：即使單一模組發生故障，大型應用程式也可以繼續有效運作。
• 消除應用程式對一種技術堆疊的承諾：如果您想在某些服務上嘗試新技術堆疊，請繼續。依賴關係將比單體依賴程度輕得多，並且回滾所有內容也會更容易。一個應用程式中的程式碼越少，工作起來就越容易。
• 讓新進員工更容易了解服務的功能。

微服務：掛載和虛擬化的特色 現在我們了解了什麼是微服務。而且最大的優點是它可以被多個WAR/EAR/JAR 歸檔檔案掛載。但它是如何安裝的呢？在容器內安裝微服務的最佳方式。容器是一個完全配置的虛擬作業系統，配置了必要的環境，這有助於隔離對安裝容器的硬體系統資源的存取。市場上最有名的解決方案當然是Docker。AWS等IaaS（基礎架構即服務）的虛擬機器也可以很好地用於掛載微服務，但相對輕量級的微服務可能不會使用虛擬機器中的所有資源，這會降低使用的獲利能力。您也可以使用OSGI（開放服務閘道計畫）套件掛載微服務。在這種情況下，所有微服務都將在單一 JVM 中運行，但這涉及控制和隔離之間的權衡問題。 微服務：缺點 僅僅​​因為「這很酷」和「我們以前沒有見過這個」並不意味著沒有缺點。以下列出了微服務架構可能帶來的痛點：

• 開發分散式系統可能很困難。我的意思是，所有元件現在都是獨立的服務 - 您需要非常仔細地處理模組之間傳遞的請求。可能存在一種情況，其中一個模組沒有響應，迫使您編寫額外的程式碼以避免系統崩潰。如果遠端呼叫對延遲敏感，這可能會更加困難。
• 多個資料庫和事務管理可能是一個真正的痛苦。
• 測試微服務應用程式可能很麻煩。使用單體應用程序，我們只需要在伺服器上運行 WAR/EAR/JAR 存檔並確保它連接到資料庫。在微服務中，每個單獨的服務都必須在測試開始之前啟動。
• 安裝應用程式可能很棘手。它們可能需要圍繞多個服務進行協調，而這些服務可能不像 WAR 容器那樣容易安裝。

....當然，透過正確的工具和方法，這些缺點是可以避免的。但他們本身需要支持，並不能完全解決所有問題。文章翻譯自雲學院網站。免費翻譯。每個人都可以在評論中自由表達自己的想法。他們一定會被閱讀。 原文文章 我的Github帳戶