终身学习、乐于分享、共同成长!
什么是负载均衡?
负载均衡,英文名称为Load Balance,是高可用网络基础架构的关键组件,通常用于将工作负载分布到多个服务器来提高网站、应用、数据库或其他服务的性能和可靠性。
负载均衡构建在原有网络结构之上,它提供了一种透明且廉价有效的方法扩展服务器和网络设备的带宽、加强网络数据处理能力、增加吞吐量、提高网络的可用性和灵活性。
负载均衡有哪些分类?
常见的负载均衡系统包括:DNS负载均衡、硬件负载均衡和软件负载均衡。
DNS是最简单也是最常见的负载均衡方式,一般用来实现地理级别的均衡。例如,北京的用户访问北京的机房,深圳的用户访问深圳的机房。 DNS负载均衡的本质是 DNS 解析同域名可以返回不同的 IP 地址。
例如,同样是www.baidu.com,北京用户解析后获取的地址是61.135.165.224(这是北京机房的IP),深圳用户解析后获取的地址是110.242.68.66(这是南方机房的IP)。
硬件负载均衡是通过单独的硬件设备来实现负载均衡功能,这类设备和路由器交换机类似,可以理解为一个用于负载均衡的基础网络设备。目前业界典型的硬件负载均衡设备有两款,F5和A10。
这类设备性能强劲,功能强大,但价格都不便宜,一般只有土豪公司才会考虑使用此类设备。普通业务量级的公司一是负担不起,二是业务量没那么大,用这些设备也是浪费。
软件负载均衡是指通过负载均衡软件来实现负载均衡功能,常见的有Nginx和LVS,其中Nginx是软件的7层负载均衡,LV是Linux内核的4层负载均衡。
4层和7层的区别就在于协议和灵活性。 Nginx支持HTTP、HTTPS、Email协议;LVS是4层负载均衡,和协议无关,几乎所有应用都可以做,例如聊天、数据库等。
在微服务架构中我们用到是软件负载均衡。
这种模式在微服务架构模式之前普遍使用,指的是在消费者和服务提供方中间使用独立的代理方式进行负载,一般都是使用Nginx来实现。
在微服务架构中普遍使用,通过服务的注册中心将服务提供者的访问地址发送出去,服务消费者得到地址后在消费者端进行负载均衡,一般使用Ribbo来实现。
下一代微服务架构中将对负载均衡进行沉淀到独立的进程中,最大的变化就是和业务应用完全解耦了。
在微服务架构中主流使用的软件负载均衡实现是Ribbon。
Spring Cloud Ribbon是基于Netflix Ribbon 实现的一套客户端的负载均衡工具,Ribbon客户端组件提供一系列的完善的配置,如超时,重试等。通过Load Balancer获取到服务提供的所有机器实例,Ribbon会自动基于某种规则(轮询,随机)去调用这些服务。Ribbon也可以实现我们自己的负载均衡算法。
组件库丰富:整套负载均衡由7个具体的策略组成,无论你是什么特殊需求,都有合适的策略供你选择。 适配性强:给谁都能用,跟多个组件都能搭配,能跟Sprig Cloud里的多个组件(eureka、feign、gateway、zuul、hystrix)搭配使用; 此外,Ribbon可以脱离SpringCloud应用在一般项目中。
@Configuration
public class RestTemplateConfiguration {
@Bean
@LoadBalanced
public RestTemplate restTemplate() {
return new RestTemplate();
}
}
@RestController
@RequestMapping("/demo")
@AllArgsConstructor
public class ConsumerDemoController {
private final RestTemplate restTemplate;
@RequestMapping("/say")
public String say(){
// 使用RestTemplate调用服务
String msg = restTemplate.getForObject("http://service-provider/demo/hello?msg=Nacos", String.class);
return msg;
}
}
由@LoadBalancer注解标记RestTemplate后,Ribbon会将带有负载均衡功能的拦截器注入标记好的RestTemplate中,以此来实现负载均衡。
Ribbon拦截请求,获取应用名,LoadBalancerAutoConfiguration是Ribbon的自动配置类,在这个配置类里面配置了一个拦截器,该拦截器会拦截所有请求,这就是Ribbon的入口;
LoadBalancerInterceptor的intercept方法(当远程调用的时候都会被拦截器拦截)
官网 (opens new window)对Istio的介绍:
An open platform to connect, secure, control and observe services.
即“一个连接、安全加固、控制和观察服务的开放平台”。开放平台就是指它本身是开源的,服务对应的是微服务,也可以粗略地理解为单个应用。
中间的四个动词就是 istio 的主要功能,官方也各有一句话的说明。
上面对Istio介绍的四个动词看起来非常高级,功能非常强大,但从字面意思理解起来非常虚,要想搞清楚Istio,我们先来聊聊前面第0章里面提到的Service Mesh架构模式。
Service Mesh号称是下一代微服务架构模式,其实说起来也不是什么新技术,接地气的说,Service Mesh其实就是传统网络代理的升级版。说到代理大家应该就不陌生了,设计模式中的代理模式大家肯定都学习过。
网络代理可以简单类比成现实生活中的中介,在需要通信的双方加上一道关卡,在这道关卡中增加一些与业务无关但又非常重要的功能,例如:
Service Mesh是分布式的微服务代理。怎么理解呢?在传统模式下,代理一般是集中式的单独的服务器,所有的请求都要先通过代理,然后再流入转发到实际的后端。而在Service Mesh中,代理变成了分布式的,它常驻在了应用的身边(最常见的就是 kubernetes sidecar 模式,每一个应用的 pod 中都运行着一个代理,负责流量相关的事情)。这样的话,应用所有的流量都被代理接管,那么这个代理就能做到上面提到的所有可能的事情,从而带来无限的想象力。
边车负载均衡模式就是这样的原理。
理解了Service Mesh再来看Istio官方给出的架构图就很容易理解了。
Istio extends Kubernetes to establish a programmable, application-aware network using the powerful Envoy service proxy. Working with both Kubernetes and traditional workloads, Istio brings standard, universal traffic management, telemetry, and security to complex deployments.
翻译过来是:Istio 使用功能强大的 Envoy 服务代理扩展了 Kubernetes,以建立一个可编程的、可感知的应用程序网络。Istio 与 Kubernetes 和传统工作负载一起使用,为复杂的部署带来了标准的通用流量管理、遥测和安全性。
Istio看起来非常炫酷,功能也很强大,但是一个架构和产品出来都是要解决具体问题的。前面我们提到Istio是用来解决微服务中的难题的,具体是什么呢?
首先,原来的单个应用拆分成了许多分散的微服务,它们之间相互调用才能完成一个任务,而一旦某个过程出错(组件越多,出错的概率也就越大),就非常难以排查。
用户请求出现问题无外乎两个问题:错误和响应慢。如果请求错误,那么我们需要知道哪个步骤出错了,这么多的微服务之间的调用怎么确定哪个有调用成功?哪个没有调用成功呢?如果是请求响应太慢,我们就需要知道到底哪些地方比较慢?整个链路的调用各阶段耗时是多少?哪些调用是并发执行的,哪些是串行的?这些问题需要我们能非常清楚整个集群的调用以及流量情况。
Istio就是用来解决这些问题的。
好了,关于Istio的话题就聊到这里,我这里也只是抛砖引玉,感兴趣的同学可以继续深入研究。
页面更新:2024-04-25
本站资料均由网友自行发布提供,仅用于学习交流。如有版权问题,请与我联系,QQ:4156828
© CopyRight 2020-2024 All Rights Reserved. Powered By 71396.com 闽ICP备11008920号-4
闽公网安备35020302034903号