什麼是微服務？什麼是服務注冊與發現

本文位址http://yangjianyong.cn/?p=657轉載無需經過作者本人授權

現在最為流行的軟體架構就是微服務，也确實微服務帶來的生産效率更加的提高了。什麼是微服務，就是将傳統整體大型的系統，根據功能的不同拆分成多個小型的且能夠獨立運作的服務，再通過有組織的明确定義的

API

在各個不同的小型的服務間進行通信。這些多個小型的服務可以由獨立的團隊管理。

通俗的了解：例如在福特汽車還沒發明出流水線這種工作模式之前，一個勞工在生産一輛汽車先要從發動機，再到變速箱再到底盤等等最後一輛車的組裝完成都會參與到。但是有了流水線的工作模式後，在一條生産線上，按照各個汽車零件的功能劃分，分成了不同的生産工廠中的房間。這些不同的工廠中的房間按照規定的技術标準生産出零件，最後再組裝到一塊。

在我們開發一個電商系統時，電商系統有分使用者子產品 / 商品子產品 /訂單子產品 / 财務子產品等等。整個電商系統就是就是在生産一輛車，車上的不同零件就是電商系統中不同的子產品。傳統的開發模式就是先把使用者子產品開發出來讓使用者可以注冊，再開發商品子產品可以上線商品，再開發訂單子產品可以讓使用者購買等等，在這個過程中程式員會涉及到整個系統的開發，并且都是使用的統一的技術棧。而使用微服務的架構模式，就是類似于流水線。不同的子產品将由不同的團隊開發，每個團隊使用的技不必統一。隻需要在對外提供統一标準協定的API接口即可。

微服務的特性

顆粒度小

每個服務隻專注做一件事。例如負責使用者子產品的團隊，就隻專注處理使用者問題，其他的訂單問題 / 商品問題不聞不問。

自主性

每個獨立的服務都可以擁有自己的技術棧，部署環境，獨立運作，互不依賴。例如使用者子產品可以用

php

語言開發部署在阿裡雲；訂單子產品可以用

java

語言開發部署在華為雲。

輕量化的通信機制

各個不同的服務之間，通常使用

REST / HTTP

協定的接口進行通信。

微服務的優點

靈活性

微服務促進若幹小型獨立團隊形成一個組織，這些團隊負責自己的服務。各團隊在小型且易于了解的環境中行事，并且可以更獨立、更快速地工作。這縮短了開發周期時間。您可以從組織的總吞吐量中顯著獲益。

靈活擴充

通過微服務，您可以獨立擴充各項服務以滿足其支援的應用程式功能的需求。這使團隊能夠适當調整基礎設施需求，準确衡量功能成本，并在服務需求激增時保持可用性。

輕松部署

微服務支援持續內建和持續傳遞，可以輕松嘗試新想法，并可以在無法正常運作時復原。由于故障成本較低，是以可以大膽試驗，更輕松地更新代碼，并縮短新功能的上市時間。

技術自由

微服務架構不遵循“一刀切”的方法。團隊可以自由選擇最佳工具來解決他們的具體問題。是以，建構微服務的團隊可以為每項作業選擇最佳工具。

可重複使用的代碼

将軟體劃分為小型且明确定義的子產品，讓團隊可以将功能用于多種目的。專為某項功能編寫的服務可以用作另一項功能的建構塊。這樣應用程式就可以自行引導，因為開發人員可以建立新功能，而無需從頭開始編寫代碼。

彈性

服務獨立性增加了應用程式應對故障的彈性。在整體式架構中，如果一個元件出現故障，可能導緻整個應用程式無法運作。通過微服務，應用程式可以通過降低功能而不導緻整個應用程式崩潰來處理總體服務故障。

微服務解決了什麼問題

縮短開發時間

微服務可以通過分布式部署，大幅的提升團隊的開發效率。相較傳統的線性開發，微服務架構下可以并行開發。

快速上線産品

縮短了開發時間，等同于加快産品面市，可幫助企業快速搶占市場。

高度可擴充

在服務獨立的背景下，在原有的系統上新添加功能子產品比傳統單體架構顯得更加容易。

更加穩定

傳統的單體架構下，一旦某一個子產品出問題，整體服務将停擺。而微服務可以将各個獨立的服務重複部署，這樣将大大的增加整體系統的穩定性。

易于部署

由于各個服務的獨立化，可以使用不同的技術棧。不用再去操心部署的問題。

實作微服務涉及到的技術

服務注冊與發現

服務注冊就是把某個微服務的通信資訊注冊到一個公共的元件中心，比如常用的

zookeeper / consul

。服務發現就是跟服務注冊相反的，每一個在元件中心注冊的通信資訊要能夠及時的被其他微服務發現。要了解服務注冊與發現，要先來看下架構的發展史：

Web1.0架構:

從上圖就可以看出，傳統的

Web1.0

的架構是很簡單的，不同的請求

Web / Ios / Android

直接請求

Server

，甚至很多時候都是把

Server

跟

Database

放在一起的。這種架構對于小型的系統來講其實算是效率最高最穩定的，對于不複雜的系統來講，這種架構是最合适的。

Web2.0架構:

在雲計算時代，我們不必再獨立購買主機了，隻需要把所有的服務搬到雲上即可。當我們的請求越來越多，資料量也越來越多的時候，單台伺服器已經扛不住請求了，這時候就需要把增加處理請求的

Server

，然後再把所有的請求入口統一到一個負載均衡中心，利用負載均衡技術把請求平均到分發到每個

Server

。同時在資料庫也可以利用主從的方式來增加并發量。在

Web2.0

架構時代中，依然還不需要用到服務注冊與發現。

進入微服務架構:

注意：在這之前，多數人還是将所有的功能某塊放在同一台伺服器。但是在微服務架構中，是按照功能某塊來劃分的。這一點對于了解微服務是重要的。

随着使用者越來越多，業務也越來越複雜的之後，為了擺脫傳統架構中，牽一發而動全身的問題，現代采取的方式就是把不同功能劃分開，如圖中所示的，

Order / Goods / User

這些功能子產品劃分開來。這樣做的好處就是，每個功能子產品各司其職，進行了深度的解耦，能夠快速的實作更新，其中一個服務挂了也不會影響到其他服務。

同時也帶來了問題，從圖中就可以看出，服務之間的調用複雜度增加了、服務的管理難度變大了、各個服務之間調用的性能開銷也變大了[速度變慢了]、排查問題的難度增加了。在現在的雲時代，我們會把我們的産品直接上雲，會用 docker，會用 k8s，。在未使用服務注冊之前，我們在每個服務之間調用使用的方式就是把各個不同服務的 IP 位址和 Port 端口寫死在配置檔案裡，有的甚至寫死到代碼。這樣做随之而來的問題顯而易見，就是有增加或者減少服務時，就要到所有的服務更改 IP 和 Port 端口，這樣做明顯耗時耗力。

服務注冊的出現:

有了問題就會有人去解決。服務注冊的出現就是解決了服務管理的問題。圖中的

Register Server Cluster

就是服務注冊叢集。當有服務啟動或者增加的時候，例如圖中的

Order / User / Goods

的服務，就去服務注冊叢集中心注冊自己的相關資訊，也就是把自己所在的

IP

位址以及

Port

端口注冊上去。

服務發現:

從圖中就可以看出，所在服務需要擷取其他服務的位址資訊，隻需要發送請求給服務注冊中心，然後服務注冊中心再傳回就可以了。

這裡進行服務發現的方式有很多。有通過

HTTP

輪詢的方式，或者是通過

SUB/PUB

的方式，也有通過

RPC

的方式都可以。

通過以上的這種方式，把所有的服務資訊都放在注冊中心進行管理，這樣就可以讓我們不再繁瑣的不斷的去更新服務位址資訊了。

服務調用：

當某個服務從注冊中心拉取到其他服務的位址資訊後，就根據位址資訊去擷取資料。

健康檢查

看到這邊的童鞋，有的可能會好奇。難道一個服務注冊中心要做的事情其實就這麼簡單了嗎。其實不然，在上面提到的微服務的架構可以提高穩定性，就是可以重複部署。與重複部署相關的一個事件就是

健康檢查

。

健康檢查的進行是由注冊中心發起的，實作的方式同樣有很多種。最終的結果都是，如果有服務傳回的狀态碼不是約定的為健康的，例如

HTTP

協定的

200

，那麼就标記這台服務不可用。

如圖中所示，在一個使用者服務中，有多個不同的執行個體，當其中一個執行個體挂了之後，可以立馬部署。甚至可以部署多個，隻要其中一個執行個體挂了之後立馬啟用備份的執行個體。

歡迎來我的部落格逛一逛 楊建勇的個人部落格http://yangjianyong.cn