[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挂了，则整个主机上的容器全部受影响。