一、服务提供者端集中式负载均衡模式
这种模式在微服务之前的架构模式中普遍采用，一般都是用nginx或者lvs来做的
二、客户端负载均衡模式
微服务流行之后，目前主流的模式变成了下面这样，通过服务注册中心将服务地址发布出去，客户端得到地址后在消费者端进行负载均衡，比如 dubbo
三、边车负载均衡模式 service mesh
下一代微服务架构中将对负载均衡进行沉淀到独立的进程中，最大的变化就是和业务应用完全解耦了
四、总结
目前的微服务发展阶段主流的模式还是第二种（在消费者进程内的客户端代理实现的负载均衡），按照目前的发展趋势，下一代的微服务架构中将采用边车代理的模式（独立进程，和消费者分离）实现负载均衡，将RPC过程中服务的注册、发现、负载均衡、服务治理等通用的功能进一步沉淀出来和业务解耦。最大的好处是和业务彻底解耦，跨平台，不管你的应用服务使用的什么语言开发的，我一套方案都支持，完全降低了开发人员的工作量，直接将应用部署到k8里，然后根据Istio的要求简单配置下，就实现了服务的注册与发现、限流熔断、安全验证、灰度发布、各种监控等等 众多功能都直接有了，爽不爽。
五、Istio简介
Istio：一个连接，管理和保护微服务的开放平台。
按照isito文档中给出的定义:
Istio提供一种简单的方式来建立已部署的服务的网络，具备负载均衡，服务到服务认证，监控等等功能，而不需要改动任何服务代码。简单的说，有了Istio，你的服务就不再需要任何微服务开发框架（典型如Spring Cloud，Dubbo），也不再需要自己手动实现各种复杂的服务治理功能（很多是Spring Cloud和Dubbo也不能提供的，需要自己动手）。只要服务的客户端和服务端可以进行简单的直接网络访问，就可以通过将网络层委托Istio，从而获得一系列的完备功能。可以近似的理解为：
Istio = 微服务框架 + 服务治理。
Istio的关键功能:
HTTP/1.1，HTTP/2，gRPC和TCP流量的自动区域感知负载平衡和故障切换。
通过丰富的路由规则，容错和故障注入，对流行为的细粒度控制。
支持访问控制，速率限制和配额的可插拔策略层和配置API。
集群内所有流量的自动量度，日志和跟踪，包括集群入口和出口。
安全的服务到服务身份验证，在集群中的服务之间具有强大的身份标识。