微服務的服務治理

服務治理可以說是微服務架構中最為核心和基礎的子產品，它主要用來實作各個微服務執行個體的自動化注冊和發現。為什麼在微服務架構中需要服務治理子產品呢？微服務系統沒有它會有什麼不好的地方？ 在最開始建構微服務系統的時候可能服務并不多，我們可以做一些靜态配置來完成服務的調用。比如，有兩個服務A和B，其中服務A需要調用服務B來完成一個業務操作時，為了實作服務B的高可用，不論采用服務端負載均衡還是用戶端負載均衡，都需要手工維護服務B的具體執行個體清單。但是随着業務的發展，系統功能越來越複雜，相應的微服務應用也不斷增加，我們的靜态配置就會越來越難以維護。并且面對不斷發展的業務，我們叢集的規模、服務的位置、服務的命名等都可能發生變化，如果還是通過手工維護的方式，那麼很容易發生錯誤或命名沖突問題。同時，對于這類靜态内容的維護也必将消耗大量的人力。 為了解決微服務架構中的服務執行個體維護問題，産生了大量的服務治理架構和産品。這些架構和産品的實作都圍繞着服務注冊和服務發現機制來完成微服務應用執行個體的自動化管理。 一 服務注冊 在服務治理架構中，通常都會建構一個注冊中心，每個服務單元向注冊中心登記自己提供的服務，将主機與端口号、版本号、通信協定等一些附加資訊告訴注冊中心，注冊中心按服務名分類組織服務清單，比如，我們有兩個提供服務A的程序分别運作在192.168.0.100:8000和192.168.0.101:8000位置上，另外還有三個服務B的程序分别位于192.168.0.100:9000、192.168.0.101:9000、192.168.0.102:9000的位置上。當這些程序均啟動，并向注冊中心注冊自己的服務之後，注冊中心就會維護類似下面的一個服務清單。另外，服務注冊中心還需要以心跳的方式去監測清單中服務是否可用，若不可用需要從服務清單中剔除，達到排查故障服務的效果。

二 服務發現 由于在服務治理架構下運作，服務間的調用不再通過指定具體的執行個體位址來實作，而是通過服務名發起請求調用實作。是以，服務調用方在調用服務方接口的時候，并不知道具體的服務執行個體位置。是以，調用方需要向服務注冊中心咨詢服務，并擷取所有服務的執行個體清單，以實作對具體服務執行個體的通路。比如，現有服務C希望調用服務A、服務C就需要向注冊中心發起咨詢服務請求，服務注冊中心就會将服務A的位置清單傳回給服務C，如按上來服務A的情況，C便獲得了服務A的兩個可用位置192.168.0.100:8000和192.168.0.101:8000。當服務C要發起調用的時候，便從該清單中以某種輪詢政策取出一個位置來進行服務調用，這就是用戶端負載均衡。這裡隻是列舉一種簡單的服務治理邏輯，以友善了解。實際架構為了性能等因素，不會采用每次都向服務注冊中心擷取服務的方式，并且不同的應用場景在緩沖和服務剔除等機制上也會有一些不同的實作政策。