# 微服務 – 定義，原理和好處 > 原文： [https://howtodoinjava.com/microservices/microservices-definition-principles-benefits/](https://howtodoinjava.com/microservices/microservices-definition-principles-benefits/) 微服務是業界最新的流行語，似乎每個人都以一種或另一種方式談論它。 讓我們了解**什么是微服務**？ 在本教程中，我們將嘗試了解微服務的定義，概念和**原理**。 ```java Table of Contents 1\. Definition of Microservices 2\. Principles of Microservices 3\. Benefits of Microservices 4\. Conclusion ``` ## 1\. 微服務的定義 如今，微服務是繼 SOA（[面向服務的架構](https://en.wikipedia.org/wiki/Service-oriented_architecture)）之后越來越流行的架構模式之一。 如果您遵循行業趨勢，那么您會意識到，如今的企業不再像幾年前那樣對開發大型應用來管理其端到端業務功能感興趣，而是選擇了快速而敏捷的應用，而這些應用的成本很高 他們的錢也減少了。 微服務有助于打破大型應用的界限，并在系統內部構建邏輯上獨立的小型系統。 例如。 使用 [Amazon AWS](https://aws.amazon.com/)，您可以毫不費力地構建云應用。 這是微服務可以做什么的一個很好的例子。  整體與微服務架構 如上圖所示，每個微服務都有其自己的業務層和數據庫。 這樣，對一種微服務的更改不會影響其他微服務。 通常，**微服務使用廣泛采用的輕量協議**（例如 HTTP 和 REST）或消息傳遞協議（例如 [JMS](https://howtodoinjava.com/jms/jms-java-message-service-tutorial/) 或 AMQP）相互通信。 在特定情況下，它們也可以使用更專業的協議。 ## 2\. 微服務的原理 現在，讓我們研究微服務的“必備”原則。 1. #### 單一責任原則 單一責任原則是定義為 [SOLID 設計模式](//howtodoinjava.com/best-practices/5-class-design-principles-solid-in-java/#SRP)一部分的原則之一。 這意味著一個單元（一個類，一個函數或一個微服務）應該只承擔一個責任。 在任何時候，一項微服務都不應承擔一項以上的責任。 2. #### 圍繞業務功能構建 **微服務應專注于某些業務功能**，并確保其有助于完成任務。 微服務絕不能限制自己采用最適合解決業務目的的適當技術棧或后端數據庫存儲。 當我們設計整體應用時，這通常是約束條件，在這些應用中，我們試圖解決多個業務解決方案并在某些方面做出一些妥協。 微服務可讓您選擇最適合當前問題的方法。 3. #### 您創建它，就擁有它！ 這種設計的另一個重要方面與職責的前后發展有關。 在大型組織中，通常會有一個團隊來開發應用位置，并且在進行一些知識轉移之后，會將項目移交給維護團隊。 在微服務中，構建服務的團隊擁有它，并負責將來維護它。 > [您構建它，就擁有它！](https://aronatkins.github.io/2014/12/23/you-build-it-you-own-it.html) 這種所有權使開發人員可以接觸到其軟件的日常操作，并且他們可以更好地了解現實世界中客戶如何使用其內置產品。 4. #### 基礎設施自動化 為微服務準備和構建基礎架構是另一個非常重要的需求。 **服務應是可獨立部署的**，并且應捆綁所有依賴項，包括庫依賴項，甚至捆綁抽象物理資源的執行環境，例如 Web 服務器和容器或虛擬機。 微服務和 SOA 之間的主要**差異之一在于它們的自治程度**。 雖然大多數 SOA 實現都提供服務級別的抽象，但是微服務卻走得更遠，并且抽象了實現和執行環境。 在傳統的應用開發中，我們先構建一個 WAR 或 EAR，然后將其部署到 JEE 應用服務器中，例如使用 JBoss，WebLogic，WebSphere 等。 我們可能將多個應用部署到同一個 JEE 容器中。 在理想情況下，在微服務方法中，每個微服務將構建為[胖 JAR](//howtodoinjava.com/maven/maven-shade-plugin-create-uberfat-jar-example/)，嵌入所有依賴項并作為獨立的 Java 進程運行。 5. #### 失敗的設計 微服務的設計應考慮到故障情況。 如果服務失敗或停頓了一段時間該怎么辦。 這些是非常重要的問題，必須在實際編碼開始之前解決 - 清楚地估計**服務故障將如何影響用戶體驗**。 快速故障是用于構建容錯，彈性系統的另一個概念。 這種哲學提倡的系統應該是失敗的，而不是構建永遠不會失敗的系統。 由于服務隨時可能發生故障，因此重要的是能夠迅速檢測到故障，并在可能的情況下自動恢復服務。 微服務應用非常重視應用的實時監視，同時檢查架構元素（數據庫每秒收到多少請求）和業務相關指標（例如每分鐘有多少訂單） 收到）。 語義監視可以為發生錯誤的情況提供預警系統，從而觸發開發團隊進行跟進和調查。 ## 3\. 微服務的好處 與傳統的多層單片架構相比，微服務提供了許多*優勢。 讓我們列出它們：* * 借助微服務，架構師和開發人員可以為每種微服務選擇適用于特定架構和技術的（[多語言架構](https://www.infoq.com/articles/paradigm-based-polyglot-prog)）。 這樣可以靈活地以更具成本效益的方式設計更適合的解決方案。 * 由于服務**相當簡單且規模較小**，因此企業可以承受嘗試新流程，算法，業務邏輯等的費用。 它通過提供實驗和快速失敗的能力，使企業能夠進行顛覆性創新。 * 微服務能夠實現**選擇性可伸縮性**，即每個服務都可以獨立地按比例放大或縮小，并且按比例縮放的成本要比單片方法小。 * 微服務是**自包含的獨立部署模塊**，當第二個微服務未按我們的需要運行時，它可以用另一個類似的微服務代替。 它有助于做出正確的買進建造決策，而這通常是許多企業所面臨的挑戰。 * 微服務可幫助我們**構建本質上是有機的系統**（有機系統是通過向其添加越來越多的功能而在一段時間內橫向增長的系統）。 因為微服務都是關于獨立可管理的服務的，所以它可以根據需要添加越來越多的服務，而對現有服務的影響卻很小。 * 技術變革是軟件開發的障礙之一。 使用微服務，可以單獨為每個服務**更改或升級技術**，而不是升級整個應用。 * 由于微服務**將服務運行時環境與服務本身**打包在一起，因此可以在同一環境中共存多個版本的服務。 * 最后，微服務還使**小型，專注的敏捷團隊**得以開發。 將基于微服務的邊界組織團隊。 ## 4 總結 通常，您做出架構決策的真正后果只有在您做出決策后的幾年才會顯現出來。 在本文中，我僅列舉了一些關于微服務的正面評價，而這些知識在我有限的知識中已在許多組織中看到。 具有強大設計和出色編碼人員支持的單片應用也可以證明是一個不錯的決定，并且產品可以保留足夠長的時間來支持該決定。 與微服務類似，糟糕的設計決策將被證明是昂貴的。 它們似乎在簡化組件，但它們可能會增加它們之間的通信復雜性，并且更難控制和管理。 最后，**好的設計和熟練的團隊將為您帶來勝利**。 技術水平低下的團隊總是會創建一個糟糕的系統，很難說微服務在這種情況下是減少混亂還是使其變得更糟。 我建議您從整體應用設計開始，并且當您覺得它使系統變得復雜時，請嘗試使用微服務，以檢查它們是否使應用變得不太復雜。 這樣，您將有一個更明智的決定。 學習愉快！ 資源： [Martin Fowler 關于微服務](http://martinfowler.com/articles/microservices.html)