今天博友私信問我看我的etcd真的很難理解什麼是微服務的服務註冊與發現，當然也許這涉及到架構，接觸的比較少聽起來感覺牛逼哄哄非常嘎達上，但實際上也沒什麼！
今天我們來詳細聊聊到底什麼是服務註冊與發現！
天下文章一大抄抄抄抄抄抄！
RPC遠端過程呼叫中，存在2個角色，一個服務提供者、另一個服務消費者。那如何讓呼叫者知道，存在哪些服務可以呼叫呢？即如何讓別人使用我們的服務呢？
有同學說很簡單嘛，告訴使用者服務的IP以及埠就可以了啊。確實是這樣，這裡問題的關鍵在於是自動告知還是人肉告知。
人肉告知的方式：如果你發現你的服務一臺機器不夠，要再新增一臺，這個時候就要告訴呼叫者我現在有兩個ip了，你們要輪詢呼叫來實現負載均衡；呼叫者咬咬牙改了，結果某天一臺機器掛了，呼叫者發現服務有一半不可用，他又只能手動修改程式碼來刪除掛掉那臺機器的ip。現實生產環境當然不會使用人肉方式。
有沒有一種方法能實現自動告知，即機器的增添、剔除對呼叫方透明，呼叫者不再需要寫死服務提供方地址？當然可以，現如今zookeeper被廣泛用於實現服務自動註冊與發現功能！
成熟的服務治理框架中不止存在這兩個角色，一般還會有一個 Registry（註冊中心）的角色。一張圖就可以解釋註冊中心的主要職責。
- 註冊中心，用於服務端註冊遠端服務以及客戶端發現服務
- 服務端，對外提供後臺服務，將自己的服務資訊註冊到註冊中心
- 客戶端，從註冊中心獲取遠端服務的註冊資訊，然後進行遠端過程呼叫
目前主要的註冊中心可以藉由 zookeeper，eureka，consul，etcd 等開源框架實現。網際網路公司也會因為自身業務的特性自研，如美團點評自研的 MNS，新浪微博自研的 vintage。
服務註冊
顯然，要讓別人發現自己的服務，首先需要把服務註冊到服務中心。
把服務註冊到服務中心，其實就是在註冊中心進行一個登記，註冊中心儲存了該服務的IP、埠、呼叫方式(協議、序列化方式)等。在zookeeper中，進行服務註冊，實際上就是在zookeeper中建立了一個znode節點，該節點儲存了上面所說的服務資訊。該節點承擔著最重要的職責，它由服務提供者(釋出服務時)建立，以供服務消費者獲取節點中的資訊，從而定位到服務提供者真正網路拓撲位置以及得知如何呼叫。
服務發現
服務消費者在第一次呼叫服務時，會通過註冊中心找到相應的服務的IP地址列表，並快取到本地，以供後續使用。當消費者呼叫服務時，不會再去請求註冊中心，而是直接通過負載均衡演算法從IP列表中取一個服務提供者的伺服器呼叫服務。
感知服務的下線
服務上線時自然要註冊到註冊中心，但下線時也得從註冊中心中摘除。註冊是一個主動的行為，這沒有特別要注意的地方，但服務下線卻是一個值得思考的問題。服務下線包含了主動下線和系統當機等異常方式的下線。
臨時節點+長連線
在 zookeeper 中存在持久化節點和臨時節點的概念。持久化節點一經建立，只要不主動刪除，便會一直持久化存在；臨時節點的生命週期則是和客戶端的連線同生共死的，應用連線到 zookeeper 時建立一個臨時節點，使用長連線維持會話，這樣無論何種方式服務發生下線，zookeeper 都可以感知到，進而刪除臨時節點。zookeeper 的這一特性和服務下線的需求契合的比較好，所以臨時節點被廣泛應用。
主動下線+心跳檢測
並不是所有註冊中心都有臨時節點的概念，另外一種感知服務下線的方式是主動下線。例如在 eureka 中，會有 eureka-server 和 eureka-client 兩個角色，其中 eureka-server 儲存註冊資訊，地位等同於 zookeeper。當 eureka-client 需要關閉時，會傳送一個通知給 eureka-server，從而讓 eureka-server 摘除自己這個節點。但這麼做最大的一個問題是，如果僅僅只有主動下線這麼一個手段，一旦 eureka-client 非正常下線（如斷電，斷網），eureka-server 便會一直存在一個已經下線的服務節點，一旦被其他服務發現進而呼叫，便會帶來問題。為了避免出現這樣的情況，需要給 eureka-server 增加一個心跳檢測功能，它會對服務提供者進行探測，比如每隔30s傳送一個心跳，如果三次心跳結果都沒有返回值，就認為該服務已下線。
註冊中心對比
image.png
一般而言註冊中心的特性決定了其使用的場景，例如很多框架支援 zookeeper，在我自己看來是因為其老牌，易用，但業界也有很多人認為 zookeeper 不適合做註冊中心，它本身是一個分散式協調元件，並不是為註冊服務而生，server 端註冊一個服務節點，client 端並不需要在同一時刻拿到完全一致的服務列表，只要最終一致性即可。在跨IDC，多資料中心等場景下 consul 發揮了很大的優勢，這也是很多網際網路公司選擇使用 consul 的原因。 eureka 是 ap 註冊中心，並且是 spring cloud 預設使用的元件，spring cloud eureka 較為貼近 spring cloud 生態。
本作品採用《CC 協議》，轉載必須註明作者和本文連結