在 微服務的基建工作 中提到過，在雲原生、微服務時代，如果還是手動修改服務地址，是幾乎不可完成的工作，需要一種機制完成自動上報和獲取服務地址的支撐組件，可以保障服務的快速上線和下線，這就是服務註冊/發現組件。
爲了表述方便，從系統規模定義幾個階段：
- 巨型應用架構時期：很多應用都是一個巨型服務，一個應用包含所有功能，部署在小型機和大型機上，或者直接部署在物理服務器上。
- 單體架構時期：應用體量縮小，服務增多，而且出現虛擬化技術，物理服務器被連接成虛擬化平臺，應用部署在虛擬機中。
- SOA架構時期：應用通用功能逐漸沉澱，業務應用藉助沉澱的通用組件逐漸解耦，微服務的很多組件也是從這個時期開始成型。
- 微服務架構時期：這個時期承接模塊化時期，甚至有一種說法是微服務只是SOA的一種特殊形式。系統進一步解耦，根據業務角色不同，應用以業務爲分界，縮小爲業務單元。
- 函數架構時期：應用進一步分割爲函數，實現serverless架構，不需要具體的服務器概念，只需要執行函數的服務即可。目前來看，這個時期是比較理想的時期，因爲不同人相互協作定義的函數，可能重複或者衝突，不利於架構的演進。
隨着大家對在微服務或者函數架構中趟坑，很多人開始提出迴歸單體應用架構，這應該也是架構螺旋進步的一種方式。
在微服務中，還有一種角色是根據調用關係定義的：
- 客戶端服務（簡稱客戶端）：調用其他服務的實例
- 服務端服務（簡稱服務端）：被其他服務實例調用的實例
微服務中客戶端和服務端只對一個調用定義的，客戶端在其他調用關係中，角色可能會轉變爲服務端。
服務註冊表
說到服務發現時，必須要說一個重要組件：服務註冊表，它是服務發現的核心，是一個包含了所有服務實例的網絡位置和監控狀態的數據庫，通過服務註冊組件將信息寫入服務註冊表，通過服務發現組件獲取有效的服務實例的網絡位置信息。目前常用的服務註冊表有：Eureka、etcd、Consul、Zookeeper，Kibernetes等鏡像調度服務沒有明確的服務註冊表組件，是通過內置的服務註冊功能實現。對於比如F5和Nginx這種代理器，其中的upstream配置也屬於服務註冊表。
服務發現
在微服務架構中，服務之間通過輕量級協議互相調用，一般是HTTP請求，爲了完成一次請求，服務需要知道目標服務實例的網絡位置（IP和端口）。
在巨型應用架構時期，配置一個符合要求的服務器環境需要花費大量的時間，也就意味着服務地址發生變動的概率和頻率都非常低，而且很多應用部署在一臺小型機或者大型機上。到了單體架構時期，應用體量大數量少，發生地址變動所需要修改的地方就比較少，所以對於服務發現也就沒有那麼強的需求。換句話說，在單體架構之前，服務實例的相對位置固定，變動頻率低，可以通過硬編碼到代碼中。
但是到了雲時代，服務器環境配置變得簡單，數量逐漸增多，擴展和遷移逐漸頻繁。而且，隨着虛擬化和容器的應用，服務器地址都是根據規則動態分配，由於服務升級、擴展、失敗回滾等情況增多，服務的網絡位置甚至不可預知。這個時候必須使用服務發現機制保證客戶端服務能夠自動獲取服務端服務的地址。
通常，服務發現有兩種模式：客戶端發現模式、服務端發現模式。
客戶端發現模式
客戶端發現模式通過客戶端組件根據負載均衡算法決定相應服務實例的網絡位置，也就是說，客戶端組件保存有服務端所有實例的服務註冊表，調用發生時，根據負載均衡算法，從服務註冊表中選擇一個網絡位置，向服務端發起請求，完成調用。由於網絡的不可靠性，有的客戶端組件還會實現訪問失敗重試、訪問超時時間設定等功能。
這種模式的架構如圖：
具體的過程爲：
- 服務實例向服務註冊器上報網絡位置，即註冊
- 客戶端服務發現組件定時拉取服務註冊器中服務實例的網絡位置信息及健康狀態，保存在服務註冊表中
- 客戶端服務調用服務端服務時，通過客戶端服務發現組件，根據負載均衡算法，選取可用一個服務實例，發起調用
在Spring Cloud（或者說是Netflix開源組件）中，組件Eureka Server組件相當於服務註冊器，Eureka Client組件實現了服務註冊表，Ribbon實現了負載均衡算法和重試策略。
客戶端發現模式優缺點兼備。優點是對已有服務友好，除了客戶端組件外，其他部分無需改動。而且，客戶端存有所有服務實例信息，可以有針對性的定義負載均衡算法。缺點是客戶端與服務註冊器綁定，需要針對每種語言實現不同的客戶端組件。
服務端發現模式
服務端發現模式是有一個單獨的服務發現組件，這個實例持有服務註冊表，同時也起到負載均衡器的作用，客戶端調用服務端時，直接調用服務發現實例，通過服務實例代理到後端服務實例中，所以服務端發現模式也被稱爲代理模式。
這種模式的架構如圖：
具體的過程爲：
- 服務實例向服務註冊器上報網絡位置，即註冊
- 服務發現實例定時通過某種機制獲取服務註冊器中服務實例的網絡位置信息及健康狀態，保存在服務註冊表中
- 客戶端服務調用服務端服務時，直接調用服務發現實例，服務發現實例根據內部實現，查詢服務註冊表，將請求代理到後端服務實例
服務端發現模式中的服務發現組件有兩種實現方式：
- 第一種，集中式代理，服務發現組件是單獨的服務實例，這個實例是高可用高吞吐的系統組件，代理後端服務實例，代表性的是F5和Nginx。
- 第二種，主機進程代理，服務發現組件由系統環境提供，集成在主機上或者集成在操作系統中，代表性的是Istio ServiceMesh。
兩種實現方式的優點是語言無關，客戶端不需要關心任何服務發現的細節，只需要將原有的調用實例的請求修改爲向服務發現實例發送請求。集中式代理的缺點是，存在單點問題，需要單獨部署一個高可用、高吞吐的系統服務，由原來的一次調用增加爲兩次調用，有性能開銷。主機進程代理的缺點是運維複雜，需要能力強的運維團隊做支持。
服務註冊
服務註冊是將服務實例的網絡信息和健康狀態寫入服務註冊表中，有兩種方式：自注冊模式、第三方註冊模式。
自注冊模式
這種模式是服務實例主動向服務註冊表上報網絡位置和健康狀態，有的實現中，服務實例還會通過心跳保障註冊信息不會過期。
Eureka就是採用的這種方式，服務實例通過Eureka Client組件主動上報自己的網絡位置信息和健康狀態。
這種模式實現相對簡單，但是把服務實例和服務註冊表耦合，優缺點明顯。
第三方註冊模式
第三方註冊模式是服務實例不需要直接向服務註冊表註冊信息，而是藉助被稱爲註冊器的組件進行註冊。服務註冊器是通過掃描部署環境或者訂閱事件的方式，跟蹤服務實例的變更。當監測到服務實例有變化，會向服務註冊表上報變化信息。
這種方式可以將服務實例與服務註冊表解耦，同時也引入另外的問題。即註冊器需要內置在部署環境中，增加了運維複雜性。或者註冊器需要部署一個集中式的管理組件，成爲系統約束點。
未完待續
在微服務中，服務實例的運行環境會動態變化，實例網絡位置也是如此，因此，客戶端爲了訪問服務必須要使用服務發現機制。
服務發現有客戶端發現模式和服務端發現模式，服務註冊有自注冊模式和第三方註冊模式。服務發現和服務註冊通過服務註冊表鏈接在一起。
後面有時間，會再補充目前比較常用的服務發現、服務註冊的相關組件。
個人主頁: https://www.howardliu.cn
個人博文: 微服務中服務註冊和發現的可行性方案
CSDN主頁: https://blog.csdn.net/liuxinghao
CSDN博文: 微服務中服務註冊和發現的可行性方案
