微服務與服務治理的區別（什麼是服務註冊與發現）

2023-09-27 07:36:18 1

什麼是微服務本文地址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，那麼就標記這臺服務不可用。如圖中所示，在一個用戶服務中，有多個不同的實例，當其中一個實例掛了之後，可以立馬部署。甚至可以部署多個，只要其中一個實例掛了之後立馬啟用備份的實例。

原文連結：https://www.cnblogs.com/yangjianyong-bky/p/15318941.html