微服务是架构的一种，也属于分布式范畴。微多少钱？在分布式系统中，微服务强调单一责任、轻量级通信(HTTP)、独立性和进程隔离。嗯，没什么好说的。实践出真知。建议你多了解一下Spring-Cloud相关的微服务组件。
第一，分布式
小马正在运营一家名为TT猫的网购网站，网站有商品管理、订单管理、用户管理、支付管理、购物车等模块。每个模块都部署到一个独立的云服务主机上。
现在，程序员小明浏览TT猫，想买一个牛逼的樱桃机械键盘来提高工作效率。于是他打开TT猫的主页，搜索商品，浏览详情，评论，添加购物车，下单，支付等等。小明同学一气呵成顺利购物完，当然也花了不少钱。
但是系统是如何进行这一系列操作的，如下图:错综复杂的调用关系(忽略一些细节)。用户看不到也摸不到，但整个订购过程都是在网络间游走。
图1分布式解释
TT将所有的功能模块分布在不同的地方，最终完成用户的一系列请求。这很可能是一个分布式系统。
第二，微服务
博主微服务是架构的一种，也属于分布式范畴。微多少钱？在分布式系统中，微服务强调单一责任、轻量级通信(HTTP)、独立性和进程隔离。嗯，没什么好说的。实践出真知。建议你多了解一下Spring-Cloud相关的微服务组件。
TT猫，每年都会搞一些活动，比如女生最爱的光棍节(双11)。夜深人静的时候，会有大量用户瞬间涌入，某个时候会把一些服务敲下来。
这时候问题来了，用户订单超时，或者直接500错误。怎么解决？
图2 TT猫***
第三，负载均衡集群
这么重要的活动怎么会发生这种事？其实爸爸马提前买了几台服务器，工程师已经***部署了几个业务功能模块。
具有相同功能的每个模块组成一个组，并作为一个单独的系统进行管理。妹子下单的时候其实是和一个集群群有关系的，但是系统会保证只和其中一个有关系。跟谁，集群组有自己的调度算法，不用担心跟妹子没关系。
图3负载平衡调度
我们举一个古代淫而不淫的例子。如果你生活在古代，18岁，未婚，在高富帅，你急需解决你个人的生理问题。所以，你来到了传说中的浪漫场。咳咳，这个古代是合法的。这个时候，老鸨或者大茶壶就会过来迎接你。如果没有特殊要求，你会被带进一个房间，里面有一个满身灰尘的女人。......
风向转的时候，你有没有眨一下你程序员的眼睛？你可以这样理解。老鸨是负载均衡器，内置调度算法，***是***组之一。
图4花月圆。
好了，言归正传。省略号会自动填充。朋友们看到这里可能会问，生产环境下我们一般用什么做负载均衡器？
如果资金雄厚，请使用硬件F5
如果资金雄厚，请使用硬件F5
用DNS负载均衡不差钱。
用令人敬畏的技术使用LVS
被逼的小创业公司只能用Nginx。
当然，不止以上的负载平衡器。感兴趣的同学可以通过谷歌了解一下。
《论知行》一文说:知其所以然，知其所以然。先简单说一下这些负载均衡器在网络中是怎么走的。学过网络的朋友大概都知道七层网络模型。
首先一张图，让大家回顾一下大学的基础课程。
首先一张图，让大家回顾一下大学的基础课程。
没有即时课堂书的感觉，不过瘾？另一个TCP/IP五层模型。
每层楼都有不同的设备。比如国企用的F5，财大气粗，不缺钱，在4-7层上班。互联网公司常用的LVS工作在传输层，而应用最广泛的Nginx工作在应用层。
图5
最后说一下DNS负载均衡。虽然DNS是最原始最简单的方法，但是DNS负载均衡的控制权掌握在域名服务商手中。NDS存在多级解析、缓存A记录的问题，网站本身也做不了更多的管理。因此，中小型公司很少使用它。
当然，自身实力足够硬，DNS负载均衡也是不错的选择。下图是测试TT猫域名A记录获得的部分信息。仅供参考，可自行了解。
图7
四。高可用性集群
图表高可用性集群
因为它是一个集群，所以不可能有单点故障。如果你关注云服务，可能会接触到以下几个词，比如“双机热备”、“两地三中心”等等。
热备用是高可用性的一种形式。如上图所示，生产环境中有两个负载平衡节点。主节点处于活动状态，另一个节点处于备用状态。当主节点意外宕机时，可以通过keepalived检测到，并快速切换到备用服务，保证业务的正常运行。至于两地三中心，下面这张图可能会让你理解的更透彻。图片来自网络。
图8
动词 （verb的缩写）弹性云
为了备战双十一，Mark购买了大量的服务器，但是活动结束后，平时的用户访问量无法满足服务器的容量，导致空窗口期出现大量的服务器。
太好了。不能闲着。精明的马克拍了拍脑袋，组建了TT云团队。通过多年的努力，我们开发了按量付费云、弹性IP、共享带宽等产品。，为中小企业开源节流。
不及物动词故障切换
图9故障转移
小明觉得这个键盘不错。他点击了购买按钮，突然跳到了登录页面。
图10
搞什么鬼？我脱了裤子，你就给我看这个？普通用户可能觉得没什么问题，重新登录就行了。但作为严格的程，小明想弄清楚到底发生了什么。
经过仔细的数据分析，肖明得出了以下结论:
上述失败后，小明以为自己点的服务挂了，请求被分发到了另一个服务，但为什么会跳转到登陆页面？作为程序员，小明清楚地知道服务分为有状态和无状态。虽然我们通常的HTTP请求是无状态的，但用户状态通常是由cookie或会话确定的。
在这里，各位读者应该明白这是什么鬼。就拿我们熟悉的Tomcat来说吧，我们的用户信息一般都存储在session中，session存储在Tomcat内存中。通过浏览器cookie中的JSESSIONID向服务器进行身份验证。
但是，服务器挂起，订单请求被分发到另一个服务。自然，小明再也找不到他的会话了。
小明把问题交还给了TT猫。马克见没事了，集群还缺，赶紧让工程师想办法。
工程师最终提出了两个方案:
用户状态***(高成本、硬件和软件支持、延迟和故障风险)
用户状态统一存储(我不说话，只是笑笑)
图11
最后，工程师采用第二种方案，使用Redis存储用户状态数据。
知识补充
最近接触并使用了阿里云的负载均衡SLB，大致了解了TT猫的负载均衡实现。以下架构实现来自TT卡特彼勒。
负载均衡采用集群部署，可以实现会话同步，消除服务器单点故障，增强冗余，保证服务稳定性。阿里云目前提供四层(TCP和UDP)和七层(HTTP和HTTPS)的负载均衡服务。
第四层采用开源软件LVS (Linux虚拟服务器)+keepalive实现负载均衡。
第七层采用Tengine实现负载均衡。
图12
如下图所示，各个地区的四层负载均衡实际上是通过将多台LVS部署到一个LVS集群中来实现的。集群部署模式极大地保证了负载均衡服务在异常情况下的可用性、稳定性和可扩展性。
图13
LVS集群中的每个LVS都会有一个会话，通过组播消息同步到集群中的其他LVS机器，从而实现LVS集群中机器之间的会话同步。如下图所示，客户端向服务器发送三个数据包后，LVS1上建立的会话A开始与其他LVS机器同步。图中实线表示已有连接，图中虚线表示当LVS1出现故障或维护时，这部分流量会去往一台可以正常运行的机器LVS2。所以负载均衡集群支持热升级，在机器故障和集群维护的情况下，对用户最大程度的透明，不影响用户的业务。
图14
本文来自习惯有你投稿，不代表舒华文档立场，如若转载，请注明出处：https://www.chinashuhua.cn/24/532517.html
微信扫一扫 
