戏说系列-从生活例子看基于流量的架构设计

    上边黄色的圆孔是出水口，上边的水龙头一直的在滴水，那么大家看看哪个水桶先漏水？ 这个问题可能每个人回答的都不同，一般情况下水流不大而且比较平稳的话，应该是D水桶先漏水，因为D水桶的出水口最低 。但如果说水流量瞬时急速增大，那么有可能是A桶先满了。为什么呢？因为A桶往下边的流速是一定的，瞬时的急速流量瞬间就把A桶填满了。如果水流量增大，但是增加的不是特别大，那么B和C有可能先漏水吗？这个需要你们自己去思考一下了。

    如果大家把A,B,C,D 看成是4个服务的话，那么4个服务的吞吐量都是不相同，那么如果设计不挡的话，这4个服务哪一个都有可能先出现问题，因为流量的特点不同，对这4个服务的影响可能是不同的，大家深入的思考下如何考虑流量控制吧。

    下边让大家看一个生活中的虚构的一个例子：

    

    上图是小白在国外参加一个技术会议的例子，这个会议是在一个景区的一个会场举行，他进入景区要先通过安检，因为当时流感盛行，所以安检会进行体温检测，如果发现有体温升高的会先请到隔离区，在隔离区进行详细的检查，如果确实是发烧了，那么工作人员会进行劝离。如果通过安检了，需要先买票，当时有两个售票口，买到了票后需要通过大门进入景区，但是景区只有一个大门，所以很多人排队，后台发现检票的工作人员态度还不好，所以就增加了排队的时间。好不容易小白进入了大门，发现还有个二门，二门竟然比大门还小，所以二门也拥堵了，好不容易进入了二门，小白发现时间还早，就想去景区的科技馆参观一会，但是发现科技馆也是很多人在排队，后来发现原来里边有人在打架，正在这时候，景区的一个工作人员跑出来告诉大家，今天科技馆不营业了，让大家明天再来。大家一看，别傻等了，该干啥干啥吧。然后小白就直接去会场了。。。。。

    啰嗦了大半天，这个生活例子与流量，架构，有什么关系呢。我们再来看一个图：

    在安检部分其实是做了限流的工作，隔离区主要是隔离流量，和减流的作用。科技馆其实是起到的一个分流的作用，当科技馆有人打架，工作人员马上出来告诉大家今天科技馆关闭了，其实是起到了熔断和降级的功能，同时也是合流的作用，一次批处理降级告诉了大家结果。后来科技馆的工作人员把大家最想看的“月光宝盒”直接抬到了二门口，直接方便了大家，很多来看完宝贝的人看完立马就直接回去了，这个也起到了数据前置的作用。

    那么我们总结一下，这个日常生活中的例子，哪些是做的好的部门，哪些是需要改进的呢？先看看做的好的地方：

    1.  流控是做好的地方，比如隔离流量，减流，限流，熔断，分流，合流等。

    2.  数据前置，把大家想看的东西前置了，减少了路程。

    再看看哪些地方做的不好：

    1.  售票口两个，但是大门只有一个。

    2.  二门比大门还小，通道不畅。

    3.  售票员态度不好，团队管理有问题。

    我们再来看一看我们平时生产环境中可能出现的一个蝴蝶效应：

    如上图1，现在有3个应用，分别是抽奖，券，支付。抽奖应用服务器里边有抽奖服务，券应用服务器里边部署了活动服务和券服务，支付应用服务器里边部署了支付服务，抽奖服务会调用活动服务，支付服务会调用券服务。

    上图2，券服务调用DB出现了慢查询，因为大量的请求来访问券服务，造成券应用服务器的资源被券服务占用（请求的连接，线程都要占用CPU和内存），这个时候券服务已经几乎不能对外进行相应。

    上图3，因为券服务占用大量的服务器资源，造成在同一个服务器上的活动服务没有资源可用，活动服务也宣告挂掉。

    上图4，因为抽奖和支付都分别调用了活动服务和券服务，但是这两个服务又分别挂掉了，那么造成抽奖和支付服务出现大量的超时，如果此时抽奖和支付有大量请求过来，那么抽奖服务和支付服务的大量请求会阻塞，同时会占用大量的资源（CPU,内存），时间不久抽奖和支付也双双的挂掉了。那么至此，整个集群的所有应用全部报销。那么我们再来总结一下：线上事故一般很有可能是因为一个服务器上的一个服务引起的。

    从这个生活中的例子，我们可以看出来，如果想要对付流量的话，我们可能需要从几个方面去考虑：

    1.  流量控制。

    2.  通道优化

    3.  资源管理（团队管理）

    下一篇继续吧，今天太晚了，该睡觉了。。。。