什麼是微服務架構？什麼是服務註冊與發現

本文地址http://janrs.com/?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://janrs.com

本作品採用《CC 協議》，轉載必須註明作者和本文連結