共计 2766 个字符,预计需要花费 7 分钟才能阅读完成。
小马正在经营一个在线购物网站,名叫 TT 猫,有商品管理、订单管理、用户管理、支付管理、购物车等模块,每个模块部署到独立的云服务主机。
现在,程序员小明同学浏览 TT 猫,想买一款牛逼的 cherry 机械键盘来提升自己的工作效率。于是他打开 TT 猫首页、搜索商品、浏览详情以及评论、添加购物车、下单、支付等一系列操作。小明同学一气呵成,流畅地完成了购物,当然也花费了不少银子。
但系统又是如何进行这一系列操作,如下图错综复杂的调用关系 (自行忽略部分细节)。用户看不见、摸不着,但整个下单过程却行走在网络之间。
TT 猫把所有功能模块分布部署在不同的地方,最终完成了用户一系列的请求,这大概就是一个分布式系统吧。
博主认为微服务是一种架构,也是在分布式范畴之内的。多微才叫微?在分布式系统中,微服务更加强调单一职责、轻量级通信(HTTP)、独立性并且进程隔离。好了,没什么好说的了,实践出真知,建议大家多多了解 Spring-Cloud 相关微服务组件。
TT 猫,每年都会搞一些活动,比如女生最爱的光棍节 (双 11),夜深人静的时候会瞬间涌入大量用户,指不定就会把某个服务打趴下。
这时候,问题来了用户下单超时,或者直接 500 错误,如何去解决?
这种事情怎么可以在如此重要的活动中出现?其实马爸爸提前购买了多台服务器,工程师们已分别把各个业务功能模块复制部署了多份。
每个相同功能的模块,它们构成了一个组,并以单一系统的模式加以管理。当妹子进行下单操作时,实际上是跟一个集群组发生关系,但系统会确保只跟其中一个发生了关系,具体跟谁,集群组有自己的调度算法,不要担心跟妹子发生不了关系。
举个古代猥琐而不淫荡的例子吧,如果你生活在古代,年 18,未婚,高富帅,急需解决个人生理问题。故,你来到了传说中的风月场,咳咳,这个古代可是合法的。这时候老鸨或者大茶壶过来招呼你了,如果没有特殊要求,你会被带进一个屋里,里面有个风尘女子……
画风一转,有没有闪瞎自己的程序员万年钛合金狗眼。你可以这么理解,老鸨就是负载均衡器,内置调度算法,风尘女子就是集组其中的一个。
好了,言归正传,省略号自行脑补,小伙伴们看到这里可能会问了,平时生产环境中我们都用什么做负载均衡器?
财大气粗的用硬件 F5
不差钱的使用 DNS 负载均衡
技术牛逼的用 LVS
苦逼的创业型小公司只能使用 Nginx
当然,负载均衡器不止以上几种,有兴趣的同学自行谷歌了解。
《论知行》篇中说:知其然知其所以然,简单说下这几种负载均衡器到底是如何行走于网络中的吧,学过网络的朋友大概都清楚七层网络模型。
首先一张图,让大家重温一下大学基础课程。
有没有瞬间课堂书本的感觉,不过瘾?再来一张 TCP/IP 五层模型。
在每一层都工作着不同的设备,比如财大气粗,不差钱的国企使用的 F5 工作在 4 - 7 层,一般互联网企业使用的 LVS 工作在传输层,使用最广泛的 Nginx 工作在应用层。
最后来聊一下 DNS 负载均衡,虽然 DNS 最原始也是最简单的方法,但是 DNS 负载均衡的控制权在域名服务商手里,NDS 存在多级解析,缓存 A 记录的问题,以及网站自身无法做更多的管理。这样导致了一般中小公司很少使用。
当然,自身实力够硬,DNS 负载均衡也是个不错的选择。下图是检测 TT 猫域名的 A 记录得到的部分信息,仅供参考,自行领悟。
既然是集群,就不能够出现单点故障,如果大家关注云服务,可能会接触到以下词汇,“双机热备”,“两地三中心”等等词汇。
双机热备是高可用的一种体现形式,如上图所示,生产环境中我们存在两个负载均衡节点,主节点处于激活状态,另一个节点处于备用状态,当主节点意外宕机,可以通过 keepalived 检测并迅速切换到备用服务,保障业务正常运转。至于两地三中心,下图可能会让大家理解得更加透彻,图片源于网络。
小马哥为了准备双十一,购置了大量服务器,但活动一过,平时的用户访问量并不能满足服务器的接客能力,导致大量服务器处于空窗期。
这还了得,不能闲着啊,精明的小马哥一拍脑袋,组建了 TT 云团队。通过多年的努力开发了按量付费云、弹性 IP、共享带宽等等产品为中小企业开源节流。
小明同学觉得这款键盘不错,美滋滋的点击购买按钮,突然跳到了登陆页面。
什么鬼,裤子我都脱了,你就给我看这个?普通用户可能不会觉得有什么问题,重新登陆一次就是了。但小明作为一只严谨的程序猿,他想弄明白其中到底发生了什么。
到这里,各位看官应该明白到底是个什么鬼了吧。就拿我们比较熟悉的 Tomcat 来说,我们的用户信息一般存储在 session 中,而 session 存储在 Tomcat 内存中。浏览器通过 cookie 中的 JSESSIONID 来与服务器进行认证。
然而服务器挂了,下单请求被分发到另一台服务,自然小明再也找不到他的 session 了。
小明同学把问题反馈给了 TT 猫,小马哥一看这还得了,集群都做了还差这点,于是赶紧叫工程师们拿出解决方案。
工程师最终提出了两种方案:
服务器用户状态复制 (成本大,需要软硬件支持,有延迟,存在失败的风险)
统一存储用户状态 (我不说话,我就笑笑)
最终,工程师们采用第二种方案,使用 Redis 存储用户状态数据。
最近接触并使用了阿里云的负载均衡 SLB,大体了解了一下 TT 猫的负载均衡实现,以下架构实现源于 TT 猫。
负载均衡采用集群部署,可实现会话同步,以消除服务器单点故障,提升冗余,保证服务的稳定性。阿里云当前提供四层(TCP 协议和 UDP 协议)和七层(HTTP 和 HTTPS 协议)的负载均衡服务。
- 四层采用开源软件 LVS(Linux Virtual Server)+ keepalived 的方式实现负载均衡。
- 七层采用 Tengine 实现负载均衡。
如下图所示,各个地域的四层负载均衡实际上是由多台 LVS 机器部署成一个 LVS 集群来运行的。采用集群部署模式极大地保证了异常情况下负载均衡服务的可用性、稳定性与可扩展性。
LVS 集群内的每台 LVS 都会进行会话,通过组播报文同步到该集群内的其它 LVS 机器上,从而实现 LVS 集群内各台机器间的会话同步。如下图所示,当客户端向服务端传输三个数据包后,在 LVS1 上建立的会话 A 开始同步到其它 LVS 机器上。图中实线表示现有的连接,图中虚线表示当 LVS1 出现故障或进行维护时,这部分流量会走到一台可以正常运行的机器 LVS2 上。因而负载均衡集群支持热升级,并且在机器故障和集群维护时最大程度对用户透明,不影响用户业务。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)