三分钟读懂TT猫分布式、微服务和集群之路

针对新手入门的普及，有过大型网站技术架构牛人路过，别耽误浪费了时间，阅读之前，请确保有一定的网络基础，熟练使用Linux，浏览大概需要3-5分钟的时间，结尾有彩蛋。

目录

• 分布式
• 微服务
• 负载均衡集群
• 高可用集群
• 弹性云
• 故障转移
• 总结

分布式

小马正在经营一个在线购物网站，名叫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、共享带宽等等产品为中小企业开源节流。

故障转移

小明同学觉得这款键盘不错，美滋滋的点击购买按钮，突然跳到了登陆页面。

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

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

发生以上故障，小明以为自己下单的那台服务挂机了，请求被分发到另一台服务上，但为什么会跳到登陆页面呢？作为一名程序员，小明清楚的知道服务分为有状态和无状态的，尽管我们平时的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上。因而负载均衡集群支持热升级，并且在机器故障和集群维护时最大程度对用户透明，不影响用户业务。

总结


如果您对这篇总结感兴趣请 回复

感谢小编厚爱和各位博友的推荐，这篇文章包括配图也是花了近一下午的时间才搞定的，由于自身认知的局限性，可能有些地方并不能满足各位看官，还请见谅。

以后TT猫系列会以更加通俗易懂的风格展示给大家，感谢，同时我也不应该"骗"大家，后面的总结回复也是自己抖了个小机灵，然而博客园把弹出层屏蔽了。

三分钟深入TT猫之故障转移：http://www.cnblogs.com/smallSevens/p/7535139.html