請原諒我使用了鏈家的圖示，小編真不是給房產中介來打廣告的。
什麼是服務發現？
服務發現並沒有怎樣的高深莫測，它的原理再簡單不過。只是市面上太多文章將服務發現的難度妖魔化，讀者被繞的雲裡霧裡，頓覺自己智商低下不敢高攀。
服務提供者是什麼，簡單點說就是一個HTTP伺服器，提供了API服務，有一個IP埠作為服務地址。服務消費者是什麼，它就是一個簡單的程式，想要訪問服務提供者提供的服務來幹一些事情。一個HTTP伺服器既可以是服務提供者對外提供服務，也可以是消費者需要別的服務提供者提供的服務，這就是服務依賴，沒有你我就不是我自己。複雜的服務甚至有多個服務依賴。
服務發現有三個角色，服務提供者、服務消費者和服務中介。服務中介是聯絡服務提供者和服務消費者的橋樑。服務提供者將自己提供的服務地址註冊到服務中介，服務消費者從服務中介那裡查詢自己想要的服務的地址，然後享受這個服務。服務中介提供多個服務，每個服務對應多個服務提供者。
服務中介就是一個字典，字典裡有很多key/value鍵值對，key是服務名稱，value是服務提供者的地址列表。服務註冊就是呼叫字典的Put方法塞東西，服務查詢就是呼叫字典的Get方法拿東西。
當服務提供者節點掛掉時，要求服務能夠及時取消註冊，比便及時通知消費者重新獲取服務地址。
當服務提供者新加入時，要求服務中介能及時告知服務消費者，你要不要嘗試一下新的服務。
Redis作為服務中介
Redis裡面有豐富的資料結構，拿來儲存服務字典再合適不過了。對每一個服務名稱，我們用一個set結構儲存服務的IP:Port字串。如果服務提供者加入，呼叫sadd命令加入服務地址，如果服務掛掉，呼叫srem命令移除服務地址。對服務消費者使用smembers指令獲取所有服務地址然後在消費程式裡隨機挑一個，或者使用srandmemember指令直接獲取隨機服務地址。
這個時候你也許會表示懷疑，服務發現真這麼簡單麼？答案是還差一點，關於上面的這個解決方案有幾個問題。
第一個問題是服務提供者程式如果被kill -9暴力殺死，不能主動呼叫srem命令怎麼辦？
這個時候服務列表中多了一個黑地址指向了不存在的服務而消費者完全不知道，這個時候服務中介就成了黑中介了。那該怎麼辦呢？
我們引入服務保活和檢查機制，並更換資料結構。服務提供者需要每隔5秒左右向服務中介彙報存活，服務中介將服務地址和彙報時間記錄在zset資料結構的value和score中。服務中介需要每隔10秒左右檢查zset資料結構，踢掉彙報時間嚴重落後的服務地址項。這樣就可以準實時地保證服務列表中服務地址的有效性。
第二個問題是服務列表變動時如何通知消費者。有兩種解決方案。
第一種是輪詢，消費者需要每隔幾秒查詢服務列表是否有改變。如果服務很多，服務列表很大，消費者很多，redis會有一定壓力。所以這時候可以引入服務列表的版本號機制，給每個服務提供一個key/value設定服務的版本號，就是在服務列表發生變動時，遞增這個版本號。消費者只需要輪詢這個版本號的變動即可知道服務列表是否發生了變化。因為服務列表比較穩定，僅在網路嚴重抖動的情況下才會頻繁發生變動，所以redis幾乎沒有壓力。
第二種是採用pubsub。這種方式及時性要明顯好於輪詢。缺點是每個pubsub都會佔用消費者一個執行緒和一個額外的redis連線。為了減少對執行緒和連線的浪費，我們使用單個pubsub廣播全域性版本號的變動。所謂全域性版本號就是任意服務列表發生了變動，這個版本號都會遞增。接收到版本變動的消費者再去檢查各自的依賴服務列表的版本號是否發生了變動。這種全域性版本號也可以用於第一種輪詢方案。
第三個問題是redis是單點的，如果掛掉了怎麼辦？
這是個大問題。正是因為這個問題的存在，流行的服務發現系統都是使用分散式資料庫zookeeper/etcd/consul等來作為服務中介，它們是分散式的多節點的，掛掉了一個節點沒關係，系統仍然可以正常工作。
那redis作為服務中介就真的不靠譜了麼？其實還有個redis-sentinel可以消除redis的單點問題，redis-sentinel可以在主節點掛掉的時候，自動升級從節點為主節點。所以拿redis幹這件事也是可以的。用redis幹服務發現確實非常簡單，雖然這種方式非常不流行。
服務提供者不只是HTTP服務
上面提到服務提供者簡單來說就是HTTP伺服器，其實服務多種多樣。可以是資料庫服務，可以是RPC服務，可以是UDP服務等等。
如果是MySQL資料庫，那如何將MySQL服務註冊到服務中介呢？原生的MySQL可沒有提供這樣功能。一般做法是提供一個Agent代理去註冊。這個代理除了將服務地址註冊到服務中介外，還需要監控MySQL的健康狀況，以便當MySQL當機時能及時切換到新的MySQL服務地址。一般這個Agent為了節省資源而不止監控一個資料庫，它可以同時監控多個資料庫，甚至是多種資料庫。
服務配置重載入
服務發現一般只是用來註冊和查詢服務列表這樣一個比較單純的功能。不過現代的服務發現系統還會整合服務配置管理功能。這樣可以實現服務配置的實時重載入。原理也很簡單，就是對於每一個服務項，服務中介還會儲存一個單獨的key/value用來儲存這個服務的配置資訊。當這個配置項在後臺被修改時，服務中介會實時通知相關伺服器變更配置資訊。比如資料庫地址變動，業務引數修改等。
服務管理後臺
為了便於服務管理，一般服務發現還會提供一個服務管理後臺，用於管理人員檢視服務叢集的狀態。如果服務註冊和彙報時提供冗餘的配置資訊，服務管理後臺就可以呈現更為詳細的服務資訊。服務管理後臺還可以將所有的服務依賴組織起來，呈現出一顆漂亮的服務依賴樹。
服務發現的一個簡單實現
小編在閒暇之餘基於Redis實現了一個簡單的服務發現系統Captain。讀者可以去github上下載這個專案進行學習。我除了編寫了服務發現的伺服器之外，客戶端sdk也一塊做了開發，可能不太穩定，希望讀者體諒，不要用於線上的業務系統。
在Captain這個專案裡，我的服務發現伺服器將Redis提供的服務做了一層封裝，對外提供HTTP API進行服務的註冊和查詢，沒有使用上文提到的pubsub功能。
閱讀相關文章，關注公眾號【碼洞】