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