服務發現與負載均衡
拓展閱讀 : dubbo 原理概念圖
內容整理自文章“實施微服務,我們需要哪些基礎框架”
作者楊波
微服務架構是由一系列職責單一的細粒度服務構成的分布式網狀結構，服務之間通過輕量機制進行通信
這時候必然引入一個服務注冊發現問題，服務提供方要注冊通告服務地址，服務的調用方要能發現目標服務，同時服務提供方一般以集群方式提供服務，也就引入了負載均衡和健康檢查問題
根據負載均衡LB所在位置的不同，目前主要的服務注冊發現和負載均衡方案有三種
01
集中式LB
在服務消費者和服務提供者之間有一個獨立的LB，通常是專門的硬件設備如 F5，或者基於軟件如 LVS，HAproxy等實現
LB上有所有服務的地址映射表，通常由運維配置注冊，當服務消費方調用某個目標服務時，它向LB發起請求，由LB以某種策略(比如Round-Robin)做負載均衡后將請求轉發到目標服務
LB一般具備健康檢查能力，能自動摘除不健康的服務實例
服務消費方如何發現LB呢？
通常的做法是通過DNS，運維人員為服務配置一個DNS域名，這個域名指向LB集中式LB方案實現簡單，在LB上也容易做集中式的訪問控制，這一方案目前還是業界主流
主要問題：
（1）單點問題，所有服務調用流量都經過LB，當服務數量和調用量大的時候，LB容易成為瓶頸，且一旦LB發生故障，影響整個系統
（2）服務消費方、提供方之間增加了一級，有一定性能開銷
02
進程內LB
針對上個方案的不足，此方案將LB的功能集成到服務消費方進程里，也被稱為軟負載(Soft Load Balancing)或者客戶端負載方案
這一方案需要一個服務注冊表配合支持服務自注冊和自發現
服務提供方啟動時，首先將服務地址注冊到服務注冊表，同時定期報心跳到服務注冊表以表明服務的存活狀態，相當於健康檢查，服務消費方要訪問某個服務時，它通過內置的LB組件向服務注冊表查詢(同時緩存並定期刷新)目標服務地址列表，然后以某種負載均衡策略選擇一個目標服務地址，最后向目標服務發起請求
這一方案對服務注冊表的可用性要求很高，一般采用能滿足高可用分布式一致的組件(例如Zookeeper、Consul、Etcd等)來實現。
LB和服務發現能力被分散到每一個服務消費者的進程內部，同時服務消費方和服務提供方之間是直接調用，沒有額外開銷，性能比較好
但是，該方案以客戶庫的方式集成到服務調用方進程里頭，如果企業內有多種不同的語言棧，就要配合開發多種不同的客戶端， 有一定的研發和維護成本
另外生產環境中，后續如果要對客戶庫進行升級，勢必要求服務調用方修改代碼並重新發布，所以升級較復雜
案例是Netflix的開源服務框架，對應的組件分別是:Eureka 服務注冊表，Karyon服務端框架支持服務自注冊和健康檢查，Ribbon客戶端框架支持服務自發現和軟路由
另外，阿里開源的服務框架 Dubbo 也是采用類似機制
03
獨立 LB 進程
該方案是針對第二種方案的不足而提出的一種折中方案，原理和第二種方案基本類似
不同之處是，他將LB和服務發現功能從進程內移出來，變成主機上的一個獨立進程，主機上的一個或者多個服務要訪問目標服務時，他們都通過同一主機上的獨立LB進程做服務發現和負載均衡
該方案也是一種分布式方案，沒有單點問題，一個LB進程掛了只影響該主機上的服務調用方，服務調用方和LB之間是進程內調用，性能好，同時該方案還簡化了服務調用方，不需要為不同語言開發客戶庫，LB的升級不需要服務調用方改代碼
不足是部署較復雜，環節多，出錯調試排查問題不方便
典型案例是Airbnb的SmartStack服務發現框架，對應組件分別是:Zookeeper 作為服務注冊表，Nerve 獨立進程負責服務注冊和健康檢查，Synapse/HAproxy 獨立進程負責服務發現和負載均衡
點擊 閱讀原文 查看 文章列表
