[TOC] # 傳統,基于LB模式  有獨立的LB,負載均衡 比如:硬件F5,軟件nginx 當服務提供方上線會向運維申請域名,然后把域名配置到負載均衡,把域名指向后臺服務,服務多份 然后請求來通過DNS解析,解析后到LB上,根據域名負載均衡到后臺服務上 **特點** 成本低,需要運維介入,集中的一個LB,LB掛了損失會很大 性能損失,需要服務必須穿透LB # 進程內LB模式  把LB移到應用進程內 服務提供方通過服務注冊方式(服務注冊表),并且定期發送心跳,告訴服務注冊表我還活著 <br> 服務消費者用了個客戶端,帶了服務發現和負載均衡功能,可以用LB調用后臺服務 LB定期同步服務注冊表中功能 **特點** 把LB移到進程內,性能消耗少 沒有集中LB,單點故障少 多語言,為每個消費者都要開發一個這個客戶端,升級成本比較高 # 主機獨立LB模式  在前面2個基礎做個折中 把LB以獨立進程部署,但是在一個主機上 其他和第2個一樣 支持多語言,不同語言都可以介入 運維部署比較麻煩,因為每個主機都要部署 <br> 如果是采用容器的部署方式，那么這個LB是部署在容器內被獨享呢，還是部署在容器的宿主機中被多個容器中的微服務共享呢？ 容器部署的話，建議每個容器部署一個獨立進程LB（或者說Service Mesh Proxy），這樣隔離性更好，容器內的LB掛了，只影響那個容器，主機上其它容器不受影響。如果容器共享主機上的獨立進程LB的話，則如果主機上的LB掛了，則整個主機上的容器全部受影響。