Dns、负载均衡、微服务的那些事儿

Dns、负载均衡、微服务的那些事儿

这张图中展示了互联网公司中使用的服务架构

不得不说的Dns

Dns 的作用就是将Ip 和域名进行对应。人们只要记住一个简单的名称就可以了类似Baidu
Dns 在整个架构中充当了很重要的作用。自Ip 和域名以来就一直存在。Dns的维护需要又大型的互联网公司进行维护。全世界有13台根服务器。
Dns 从早期的Ip-Host的域名对应。现在也逐渐广泛的定义一系列的翻译概念。现在在云架构中我们可以通过服务名-对应服务的方式。来代替早期一个Ip到一个地址的时代

负载均衡器

负责均衡器的作用就是将网络上的请求按照一定的规则分配到不同的处理节点上去。保证资源的合理利用
负责均衡的种类分为软件负载均衡和硬件负载均衡等

常见的硬件负载均衡


软件负载均衡和硬件负载均衡的区别

优点:能够直接通过智能交换机实现,处理能力更强,而且与系统无关,负载性能强,更适用于一大堆设备、大访问量、简单应用。
缺点:成本高,除设备价格高昂,而且配置冗余,很难想象后面服务器做一个集群,但最关键的负载均衡设备却是单点配置,无法有效掌握服务器及应用状态。
硬件负载均衡,一般都不管实际系统与应用的状态,而只是从网络层来判断,所以有时候系统处理能力已经不行了,但网络可能还来得及反应(这种情况非常典型,比如应用服务器后面内存已经占用很多,但还没有彻底不行,如果网络传输量不大就未必在网络层能反映出来)
/
优点:基于系统与应用的负载均衡,能够更好地根据系统与应用的状况来分配负载。这对于复杂应用是很重要的,性价比高,实际上如果几台服务器,用F5之类的硬件产品显得有些浪费,而用软件就要合算得多,因为服务器同时还可以跑应用、做集群等。
缺点:负载能力受服务器本身性能的影响,性能越好,负载能力越大。

常见的软件负载均衡
– Haproxy:天生负载均衡技能,全面支持七层代理,会话保持,标记,路径转移;
– Nginx:只在Http协议和Mail协议上功能比较好,性能与Haproxy差不多;
– Apache:功能较差
– Mysql Proxy:功能尚可。

云服务的负载均衡



负载均衡中说的层是什么概念

层代表着负载均衡能够探知的级别。

1)二层负载均衡(Mac)
根据Osi模型分的二层负载,一般是用虚拟Mac地址方式,外部对虚拟Mac地址请求,负载均衡接收后分配后端实际的Mac地址响应.
2)三层负载均衡(Ip)
一般采用虚拟Ip地址方式,外部对虚拟的Ip地址请求,负载均衡接收后分配后端实际的Ip地址响应. (即一个Ip对一个Ip的转发, 端口全放开)
3)四层负载均衡(Tcp)
在三次负载均衡的基础上,即从第四层”传输层”开始, 使用”Ip+Port”接收请求,再转发到对应的机器。
4)七层负载均衡(Http)
从第七层”应用层”开始, 根据虚拟的Url或Ip,主机名接收请求,再转向相应的处理服务器。

负责均衡的术语(黑话)
Https://Www.F5.Com.Cn/Services/Resources/Glossary

负载均衡算法

linux负载均衡总结性说明(四层负载/七层负载)
1)轮循均衡(Round Robin):每一次来自网络的请求轮流分配给内部中的服务器,从1至N然后重新开始。此种均衡算法适合于服务器组中的所有服务器都有相同的软硬件配置并且平均服务请求相对均衡的情况。
2)权重轮循均衡(Weighted Round Robin):根据服务器的不同处理能力,给每个服务器分配不同的权值,使其能够接受相应权值数的服务请求。例如:服务器A的权值被设计成1,B的权值是 3,C的权值是6,则服务器A、B、C将分别接受到10%、30%、60%的服务请求。此种均衡算法能确保高性能的服务器得到更多的使用率,避免低性能的服务器负载过重。 3)随机均衡(Random):把来自网络的请求随机分配给内部中的多个服务器。
4)权重随机均衡(Weighted Random):此种均衡算法类似于权重轮循算法,不过在处理请求分担时是个随机选择的过程。
5)响应速度均衡(Response Time):负载均衡设备对内部各服务器发出一个探测请求(例如Ping),然后根据内部中各服务器对探测请求的最快响应时间来决定哪一台服务器来响应客户端的服务请求。此种均衡算法能较好的反映服务器的当前运行状态,但这最快响应时间仅仅指的是负载均衡设备与服务器间的最快响应时间,而不是客户端与服务器间的最快响应时间。
6)最少连接数均衡(Least Connection):客户端的每一次请求服务在服务器停留的时间可能会有较大的差异,随着工作时间加长,如果采用简单的轮循或随机均衡算法,每一台服务器上的连接进程可能会产生极大的不同,并没有达到真正的负载均衡。最少连接数均衡算法对内部中需负载的每一台服务器都有一个数据记录,记录当前该服务器正在处理的连接数量,当有新的服务连接请求时,将把当前请求分配给连接数最少的服务器,使均衡更加符合实际情况,负载更加均衡。此种均衡算法适合长时处理的请求服务,如Ftp。
7)处理能力均衡:此种均衡算法将把服务请求分配给内部中处理负荷(根据服务器Cpu型号、Cpu数量、内存大小及当前连接数等换算而成)最轻的服务器,由于考虑到了内部服务器的处理能力及当前网络运行状况,所以此种均衡算法相对来说更加精确,尤其适合运用到第七层(应用层)负载均衡的情况下。
8)Dns响应均衡(Flash Dns):在Internet上,无论是Http、Ftp或是其它的服务请求,客户端一般都是通过域名解析来找到服务器确切的Ip地址的。在此均衡算法下,分处在不同地理位置的负载均衡设备收到同一个客户端的域名解析请求,并在同一时间内把此域名解析成各自相对应服务器的Ip地址(即与此负载均衡设备在同一位地理位置的服务器的Ip地址)并返回给客户端,则客户端将以最先收到的域名解析Ip地址来继续请求服务,而忽略其它的Ip地址响应。在种均衡策略适合应用在全局负载均衡的情况下,对本地负载均衡是没有意义的。

微服务环境下的负载均衡应该怎么做

  • 多服务下服务如何和负载均衡感知
  • 多服务下服务挂掉了怎么办
  • 多服务怎么和负载均衡集成

服务注册和服务发现的概念提出

  • 服务注册和服务发现提供一种动态的机制来监听服务的状态和位置。
  • 和负载均衡解耦。只负责服务相关的任务

Eureka 一个服务注册的实现

非常简单看Git eureka

一个Eureka客户端存在的位置

  • 必须和服务共生死
  • 一个服务放置一个客户端就好。
  • Eureka 注册的服务要有隔离性。多进程和一个其实毫无区别 负载均衡器无法作出转发隔离

Eureka 的问题

服务挂掉了怎么办,服务的延续性怎么保证
代码耦合的问题(依赖Http)

K8s。。。。。。

发表评论

邮箱地址不会被公开。 必填项已用*标注