微服務是業界最新的流行語，似乎每個人都在以這樣或那樣的方式談論它。讓我們理解一下什么是微服務？通過這篇教程我們將理解微服務的定義，概念以及微服務的原理。
微服務的定義
如今，微服務是SOA(面向服務的架構)之后越來越流行的架構模式之一，如果您正在跟蹤行業趨勢，那么您會發現，現在的企業不再像幾年前那樣對開發大型應用程序來管理端到端業務功能感興趣。相反，他們選擇快速和敏捷的應用程序，這也使他們花費更少的錢。
微服務有助於打破大型應用程序的邊界，並在系統內部構建邏輯上獨立的較小系統，例如，使用Amazon AWS，你可以輕松構建雲應用程序。這是微服務的一個很好的例子。
如上圖所示，每個微服務有它自己的業務層以及數據庫，改變其中一個微服務不會對另外的微服務有任何的影響。
總之，微服務之間使用廣泛的輕量級協議進行通信，例如 HTTP 和 REST，TCP, 或者 消息協議, 例如 JMS 和 AMQP。在特定的場景，他們也可以選擇更專業的協議。
微服務的原理
現在我們來看一下微服務必須需要的原則。
1，單一功能職責
單一功能職責是SOLID設計模式之一，它意味着一個單元，無論是類、函數還是微服務，都應該有且只有一個職責。在任何時候，一個微服務都不應該有一個以上的職責。
2，圍繞着業務功能設計
微服務應該專注於特定的業務功能，並確保它有助於完成任務。微服務絕不應限制自己采用最適合解決業務目的的適當技術棧或后端數據庫存儲。當我們設計單個應用程序時，這常常是一個約束，我們試圖在某些領域中使用一些折衷來解決多個業務解決方案。微服務使您能夠選擇最適合當前問題的解決方案。
3，你建造它，你擁有它。
這種設計的另一個重要方面與開發前后的職責有關。在大型組織中，通常由一個團隊開發app location，經過一些知識轉移會議后，將項目移交給維護團隊。在微服務中，構建服務的團隊擁有它，並負責在將來維護它。這使開發人員能夠接觸到他們的軟件的日常操作，並且他們能夠更好地理解他們構建的產品在現實世界中是如何被客戶使用的。
4，基礎設施自動化
准備和構建微服務的基礎設施是另一個非常重要的需求，服務應該是可獨立部署的，並且應該捆綁所有依賴項，包括庫依賴項，甚至是執行環境，如抽象物理資源（web服務器和容器或虛擬機）。
微服務和SOA之間的一個主要區別在於它們的自治級別。雖然大多數SOA實現提供了服務級抽象，但是微服務更進一步抽象了實現和執行環境。
在傳統的應用程序開發中，我們構建一個WAR或EAR，然后將其部署到JEE應用程序服務器中，例如使用JBoss、WebLogic、WebSphere等等。我們可以將多個應用程序部署到同一個JEE容器中。在理想的場景中，在微服務方法中，每個微服務將構建為一個胖Jar，嵌入所有依賴項，並作為獨立的Java進程運行。
5，容錯設計
微服務的設計應考慮到故障情況。如果服務失敗，或者宕機一段時間，該怎么辦?這些都是非常重要的問題，必須在實際編碼開始之前解決——以便清楚地估計服務故障將如何影響用戶體驗。
快速故障是另一個用於構建容錯、彈性系統的概念。這種哲學提倡預期失敗的系統，而不是構建永遠不會失敗的系統。由於服務在任何時候都可能失敗，因此能夠快速檢測故障並在可能的情況下自動恢復服務非常重要。
微服務應用程序非常重視應用程序的實時監控，檢查體系結構元素(數據庫每秒接收多少請求)和業務相關指標(例如每分鍾接收多少訂單)。語義監視可以提供出錯的早期預警系統，從而觸發開發團隊進行跟蹤和調查。
微服務的優點
微服務有許多優點相比傳統的多層架構（單體龐大應用），微服務的優點如下：
1，使用微服務，架構師和開發人員可以為每個微服務選擇適合於特定用途的架構和技術(通曉多種語言對應的熟悉語言的架構)。這為以更經濟有效的方式設計更適合的解決方案提供了靈活性。
2，由於服務相當簡單，而且規模更小，企業可以試驗新的流程、算法、業務邏輯等等。它通過提供快速試驗和失敗的能力，使企業能夠進行顛覆性創新。
3，微服務能夠實現選擇性的可伸縮性，即每個服務都可以獨立地伸縮，而且伸縮的成本相對於單體應用方面要低。
4，微服務是自包含的、獨立的部署模塊，當第二個微服務沒有按照我們的需要執行時，可以使用另一個類似的微服務替換一個微服務。它有助於做出正確的“購買構建”決策，而這通常是許多企業面臨的挑戰。
5，微服務幫助我們構建本質上是有機的系統(有機的系統是通過添加越來越多的功能在一段時間內橫向增長的系統)。因為微服務都是關於獨立可管理的服務——它允許在需要時添加越來越多的服務，而對現有服務的影響最小。
6，技術變化是軟件開發中的障礙之一。使用微服務，可以單獨更改或升級每個服務的技術，而不是升級整個應用程序。
7，由於microservices將服務運行時環境和服務本身打包在一起，因此允許在同一環境中共存多個版本的服務。
8，最后，微服務還支持更小、更專注的敏捷開發團隊。團隊將根據微服務的邊界進行組織。
總結：
在本文中，我僅列出了在我有限的知識范圍內在許多組織中看到的微服務的一些優點。由強大的設計和出色的代碼支持的單體應用程序也可以證明是一個好的決策，並且產品可以停留足夠長的時間來支持決策。
與微服務類似，糟糕的設計決策將被證明代價高昂。它們可能看起來簡化了組件，但是它們可能增加了組件之間通信的復雜性，並且更難控制和管理。
最后，好的設計和熟練的團隊才能帶來勝利。