微服务实现负载均衡的三种架构模式

一、服务提供者端集中式负载均衡模式  

      这种模式在微服务之前的架构模式中普遍采用,一般都是用nginx或者lvs来做的

微服务实现负载均衡的三种架构模式_第1张图片

二、客户端负载均衡模式   

      微服务流行之后,目前主流的模式变成了下面这样,通过服务注册中心将服务地址发布出去,客户端得到地址后在消费者端进行负载均衡,比如 dubbo

微服务实现负载均衡的三种架构模式_第2张图片

三、边车负载均衡模式   service mesh

      下一代微服务架构中将对负载均衡进行沉淀到独立的进程中,最大的变化就是和业务应用完全解耦了

微服务实现负载均衡的三种架构模式_第3张图片

四、总结

       目前的微服务发展阶段主流的模式还是第二种(在消费者进程内的客户端代理实现的负载均衡),按照目前的发展趋势,下一代的微服务架构中将采用边车代理的模式(独立进程,和消费者分离)实现负载均衡,将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。

集群内所有流量的自动量度,日志和跟踪,包括集群入口和出口。

安全的服务到服务身份验证,在集群中的服务之间具有强大的身份标识。

你可能感兴趣的:(公众号:,老吕架构,容器化部署,网络,java,linux,分布式,nginx)