微服務架構下的服務註冊中心

1. HTTP & RPC:

二者出發點不一樣: ①.http是爲了解決網絡通訊的問題; ②.RPC是爲了解決服務與服務之間的調用

2. 爲何要使用服務註冊中心:

例如一個大型的電商系統要叫進行若干個子系統的拆分(e.g. 訂單服務,卡券服務,會員服務, 庫存服務等),那麼每一個服務又有N多臺機器: ①.那麼經過http的形式去調用服務那麼勢必須要記錄不少個URL地址,若是某一個服務須要擴容那麼全部須要用到的地方都要改,地址管理是一個問題(因此須要一個組件去統一的管理這麼多的地址信息,而後對外只須要暴露註冊中心組件的地址便可.); ②.負載均衡如何作: 負載均衡算法(e.g. 隨機、輪詢). ③.服務的動態感知: 能夠經過定時器輪詢的方式進行健康檢查, e.g. 每隔3s檢查一次,若是服務掛了須要修改相應的服務的健康狀態,而且將狀態同步給客戶端

3. 註冊中心技術選型:

• zookeeper(分佈式協調組件,基於Google的 chubby (非開源)實現)

主要是爲了解決分佈式一致性問題,分佈式瑣。

分佈式一致性:
每一個節點都發出一個請求最終選擇一個請求.
分佈式一致性所面臨的問題(拜占庭將軍問題): e.g. 有N個將軍分散在各個方位,若是須要攻打某一個國家須要全部將軍贊成方可進行,由於須要遠程通訊因此可能會面臨有叛軍的狀況致使傳遞虛假信息.所以須要一種協議.
分佈式一致性協議:(paxos).

Google一致性解決方案->服務(chubby):
多個節點須要選擇一個節點(每一個節點作一個分佈式一致性協議算法), Google是將這一步抽取出來作成一個服務(chubby),先來先服務, e.g. A,B,C三個節點若是A建立節點成功,B,C都會失敗.那麼A即master. 由於chubby不開源,因此雅虎也面臨着相似的場景作了一個相似的服務最後捐獻給apache(即zookeeper)。

分佈式鎖:
①. 數據結構 : A.B.C三個節點基於chubby的理論只能有一個節點註冊成功(e.g. 寫數據<具備惟一性>),例如A成功,其餘等待,直到A處理完並刪除相關的.其餘節點繼續搶佔, 那麼若是有1000個節點的話那麼就會很是耗時及消耗流量,(i.e. 驚羣效應).
zookeeper是怎麼作的: 全部節點往zookeeper上寫數據(e.g. 寫數據編號),例若有N個節點那麼A先寫成功(10001),那麼B緊接着(10002)......10000N, 只須要下一個節點監聽上一個節點便可,不須要排隊等待再搶佔.(樹形結構). ②.單點故障:

• 帶中心節點的集羣(kafka , elasticsearch) 好處在於事務性的請求由master處理,非實物的請求由slave處理 NOTE : 若是全部的節點都能處理事務請求的話那麼全部節點信息須要保持同步 (A的數據同步給B,B的同步給A....).
• 不帶中心節點的集羣(redis-cluster)

• eureka:

• consul