服務發現與負載均衡
來自專欄服務端技術雜談
服務提供方要註冊通告服務地址，服務調用方要能發現目標服務，同時服務提供方一般以集群方式提供服務，也就引入了負載均衡監控檢查問題；
- 集中LB
在服務消費者和服務提供者之間有一個獨立的LB，通常是專門的硬體設備：f5，或基於LVS，HAproxy等。LB上有所有服務的地址映射表，通常由運維配置註冊，當服務消費方調用某個目標服務時，它向LB發起請求，由LB以某種策略做複雜後將請求轉發；
LB一般具備健康檢查能力，能自動摘除不健康的服務實例；
消費方如何發現LB？
通常做法是DNS，運維人員為服務配置一個DNS域名，這個域名指向LB，LB方案簡單，也容易做集中式訪問控制；
問題：
- 單點問題，所有的服務調用流量都經過LB，當服務數量和調用量大的時候，LB容易成為瓶頸，一旦LB故障，影響整個系統；
- 服務消費放，提供方之間增加了一級，有一定的性能開銷；
- 進程內LB
也被稱為軟負載，或客戶端負載方案；這一方案需要一個服務註冊表配合支持，服務自註冊和自發現；
服務提供方啟動時，首先將服務地址註冊到服務註冊表，同時定期報心跳到服務註冊表以表明服務的存活狀態，服務消費方要訪問某個服務時，它通過內置的LB組件向服務註冊表查詢目標服務地址列表，然後以某種負載均衡策略選擇一個目標服務地址，最後向目標服務發起請求；
對服務註冊表的可用性要求很高，一般採用能夠滿足高可用分散式一致的組件來實現；
LB和服務發現能力被分散在每一個服務消費者和進程內部，同時服務消費方和服務提供方之間直接調用，沒有額外的開銷；
問題：
由於以客戶庫的方式集中在服務調用方進程中，當客戶庫升級時勢調用方需要同時升級；
- 獨立LB進程
原理和第二種方案一樣，不同在於，將LB和服務發現功能從進程中移出來，變成主機上一個獨立進程，主機上一個或多個服務要訪問目標服務時，會通過同一主機上的獨立LB進程做服務發現和負載；
是一種分散式的方案，沒有單點問題，一個LB進程掛了隻影響該主機上服務調用方，服務調用方和LB之間是進程內調用，性能好，同時簡化了服務調用方，不需要為不同語言開發客戶庫，LB升級不需要服務調用方改代碼；
問題：
部署較複雜，環節多，出錯不易調試；
推薦閱讀：