版權宣告： https：//blog。csdn。net/shenso/article/details/80259595
一、微服務概述
1、什麼是微服務？
微服務就是一些可獨立執行、可協同工作的小的服務。
從概念中我們可以提取三個關鍵詞：可獨立執行、可協同工作、小。這三個詞高度概括了微服務的核心特性。下面我們就對這三個詞作詳細解釋。
可獨立執行
微服務是一個個可以獨立開發、獨立部署、獨立執行的系統或者程序。
可協同工作
採用了微服務架構後，整個系統被拆分成多個微服務，這些服務之間往往不是完全獨立的，在業務上存在一定的耦合，即一個服務可能需要使用另一個服務所提供的功能。這就是所謂的“可協同工作”。與單服務應用不同的是，多個微服務之間的呼叫時透過RPC通訊來實現，而非單服務的本地呼叫，所以通訊的成本相對要高一些，但帶來的好處也是可觀的。
小而美
微服務的思想是，將一個擁有複雜功能的龐大系統，按照業務功能，拆分成多個相互獨立的子系統，這些子系統則被稱為“微服務”。每個微服務只承擔某一項職責，從而相對於單服務應用來說，微服務的體積是“小”的。小也就意味著每個服務承擔的職責變少，根據單一職責原則，我們在系統設計時，要儘量使得每一項服務只承擔一項職責，從而實現系統的“高內聚”。
2、微服務的優點
易於擴充套件
在單服務應用中，如果目前效能到達瓶頸，無法支撐目前的業務量，此時一般採用叢集模式，即增加伺服器叢集的節點，並將這個單服務應用“複製”到所有的節點上，從而提升整體效能。然而這種擴充套件的粒度是比較粗糙的。如果只是系統中某一小部分存在效能問題，在單服務應用中，也要將整個應用進行擴充套件，這種方式簡單粗暴，無法對症下藥。而當我們使用了微服務架構後，如果某一項服務的效能到達瓶頸，那麼我們只需要增加該服務的節點數即可，其他服務無需變化。這種擴充套件更加具有針對性，能夠充分利用計算機硬體/軟體資源。而且只擴充套件單個服務影響的範圍較小，從而系統出錯的機率也就越低。
部署簡單
對於單服務應用而言，所有程式碼均在一個專案中，從而導致任何微小的改變都需要將整個專案打包、釋出、部署，而這一系列操作的代價是高昂的。長此以往，團隊為了降低釋出的頻率，會使得每次釋出都伴隨著大量的修改，修改越多也就意味著出錯的機率也越大。
當我們採用微服務架構以後，每個服務只承擔少數職責，從而每次只需要釋出發生修改的系統，其他系統依然能夠正常執行，波及範圍較小。此外，相對於單服務應用而言，每個微服務系統修改的程式碼相對較少，從而部署後出現錯誤的機率也相對較低。
技術異構性
對於單服務應用而言，一個系統的所有模組均整合在一個專案中，所以這些模組只能選擇相同的技術。但有些時候，單一技術沒辦法滿足不同的業務需求。如對於專案的演算法團隊而言，函式試程式語言可能更適合演算法的開發，而對於業務開發團隊而言，類似於Java的強型別語言具有更高的穩定性。然而在單服務應用中只能互相權衡，選擇同一種語言，而當我們使用微服務結構後，這個問題就能夠引刃而解。我們將一個完整的系統拆分成了多個獨立的服務，從而每個服務都可以根據各自不同的特點，選擇最為合適的技術體系。
當然，並不是所有的微服務系統都具備技術異構性，要實現技術異構性，必須保證所有服務都提供通用介面。我們知道，在微服務系統中，服務之間採用RPC介面通訊，而實現RPC通訊的方式有很多。有一些RPC通訊方式與語言強耦合，如Java的RMI技術，它就要求通訊的雙方都必須採用Java語言開發。當然，也有一些RPC通訊方式與語言無關，如基於HTTP協議的REST。這種通訊方式對通訊雙方所採用的語言沒有做任何限制，只要通訊過程中傳輸的資料遵循REST規範即可。當然，與語言無關也就意味著通訊雙方沒有型別檢查，從而會提高出錯的機率。所以，究竟選擇與語言無關的RPC通訊方式，還是選擇與語言強耦合的RPC通訊方式，需要我們根據實際的業務場景合理地分析。
——————————-
作者：河灣
原文：https：//blog。csdn。net/shenso/article/details/80259595
版權宣告：本文為博主原創文章，轉載請附上博文連結！
說完了理論，我們來看看實實在在的應用，看圖瞭解
微服務架構
