趣文:3分钟读懂何为分布式、微服务和集群!

张志朋 2017-11-02 15:03:52
作者介绍


张志朋,资深Java爱好者,深耕于在线教育领域,个人博客: https://blog.52itstyle.com。

编者按

在上一篇文章《吃透这套架构演化图,从零搭建Web网站也不难!》中有同学留言,希望可以再分享微服务和分布式方面的具体知识,于是便有了这篇新文章的“问世”。在阅读本文之前,请确保有一定的网络基础,熟练使用Linux,浏览大概需要3-5分钟的时间。

一、分布式

小马正在经营一个在线购物网站,名叫TT猫,有商品管理、订单管理、用户管理、支付管理、购物车等模块,每个模块部署到独立的云服务主机。

现在,程序员小明同学浏览TT猫,想买一款牛逼的cherry机械键盘来提升自己的工作效率。于是他打开TT猫首页、搜索商品、浏览详情以及评论、添加购物车、下单、支付等一系列操作。小明同学一气呵成,流畅地完成了购物,当然也花费了不少银子。

但系统又是如何进行这一系列操作,如下图错综复杂的调用关系(自行忽略部分细节)。用户看不见、摸不着,但整个下单过程却行走在网络之间。

有没有瞬间课堂书本的感觉,不过瘾?再来一张TCP/IP五层模型。

什么鬼,裤子我都脱了,你就给我看这个?普通用户可能不会觉得有什么问题,重新登陆一次就是了。但小明作为一只严谨的程序猿,他想弄明白其中到底发生了什么。

经过仔细的查阅资料分析,小明得出了以下结论:

发生以上故障,小明以为自己下单的那台服务挂机了,请求被分发到另一台服务上,但为什么会跳到登陆页面呢?作为一名程序员,小明清楚的知道服务分为有状态和无状态的,尽管我们平时的HTTP请求是无状态的,但是一般会通过cookie或者session来确定用户状态。

到这里,各位看官应该明白到底是个什么鬼了吧。就拿我们比较熟悉的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上。因而负载均衡集群支持热升级,并且在机器故障和集群维护时最大程度对用户透明,不影响用户业务。

 
活动预告