- 服務如何注冊
- consumer如何知道provider
- 服務注冊中心如何高可用
- 服務上下線，消費端如何動态感覺
文章目錄
- 1.服務注冊
- 2.服務消費
- 3.注冊中心高可用
- 4.動态感覺服務上下線
1.服務注冊
當我們把服務資訊注冊上去後，就應該是：
服務清單儲存通常有三種方式：本地記憶體、資料庫、第三方緩存系統
注冊上去後，consumer需要服務位址的時候，就可以用相應key去注冊中心擷取對應的服務清單。
同一個服務注冊中心，我們可以注冊多個服務，比如
使用者服務
、
商品服務
、
訂單服務
…
2.服務消費
consumer如何知道provider
consumer端通過key擷取指定的服務位址清單。
3.注冊中心高可用
高可用無非就是做叢集，我們可以對注冊中心部署多個節點。在消費端consumer隻需要知道一個服務注冊中心叢集位址cluster-url即可。
4.動态感覺服務上下線
consumer拿到服務清單後，會把服務清單儲存起來，儲存到本地緩存裡。
consumer通過一定的負載均衡算法，選擇出一個位址，最後發起遠端的調用。
如果我們的服務節點挂掉一個了，怎麼辦
我們的
服務注冊中心
需要知道哪個服務節點挂了，然後從對應服務清單裡删除。
有種辦法叫做
心跳檢測heartBeat
，即就是服務注冊中心，每隔一定時間去監測一下provider，如果監測到某個服務挂了，那就把對應服務位址從服務清單中删除。
但是服務注冊中心的服務清單和consumer端的服務清單不一樣了。
動态的感覺: 拉取或者推送push和pull
- push：服務注冊中心主動推送服務清單給consumer。
- pull：consumer主動從注冊中心拉取服務清單。
Question:
- 不管是push還是pull，都會存在consumer和服務注冊中心的通信管道。如果他們之間斷開了，那就無法擷取服務清單了。
- push有個不好點，那就是服務注冊中心需要維護大量的會話，而且還需要對每個會話維持一個心跳，一遍知曉這些會話狀态，得確定這些consumer能收到資料，
- pull因為是定時去拉取，是以會存在一定的資料延遲，比如consumer剛剛拉取服務清單，但就在拉取結束的後，某個服務provider挂了，consumer就要等下次拉取才知道對應服務provider挂了。
RA:
還有一種方式
long-pull
，也叫
長輪詢
，是上面兩種方案的優化方案，consumer發起拉取請求時，先把這個請求hold住，當服務注冊中心有發生變化後，consumer端能立馬感覺。
優點：實作也不複雜，同時相對輪詢，節約帶寬