开发者学习笔记【阿里云云原生助理工程师认证（ACA）课程：消息队列和应用工具体系-高并发场景下的可靠性难题】
课程地址：https://edu.aliyun.com/course/3112075/lesson/190234
消息队列和应用工具体系-高并发场景下的可靠性难题
内容介绍：
一．高并发是互联网应用的重要特点和风险
二．不可预测的高并发流量会导致系统不可用
三．弹性伸缩不能完全解决问题
四．单个微服务出现问题会导致连锁问题
五．高并发流量需要更多的整体性能测试和监控
一．高并发是互联网应用的重要特点和风险
相较于传统企业的应用场景，在互联网应用场景下最大的特点之一就是应用流量的分布不平均。
以双11为例，下图是考拉中的某一个 double 接口在双11前后几个小时内的流量曲线，大家可以发现在双十一零点的时候，突发的并发流量突然增加到了之前流量的几十倍，这种情况在传统的企业应用场景中并不常见，因此也就对互联网的服务架构提出了更高的要求。
除双11外，典型的例子如铁道部订票网站12306，12306网站在设计之初选择了传统企业架构，这种架构在平时的流量下还可以正常运行，但是在春运等订票高峰时，一旦到放票时间点，突如其来的流量高峰远远超过了传统企业应用架构的负担能力，就会导致整个系统卡顿、延迟，甚至服务不可用，无法为大多数人提供服务，而用户为了能抢到票，又会加大请求速度，结果就是进一步增大请求的流量，从而陷入恶性循环。这就是因为架构设计的不合理，在高并发场景下造成了非常不好的社会影响。
经过了初期的阵痛之后，12306开始放弃了传统企业型的应用架构，转向了采用互联网软件的架构设计。经过几年的架构调整。重构之后的12306对高并发场景下的的流量宏峰有了更好的适应，现在不但可以轻松应对放票时间段、尖峰并发流量，甚至还有多余的计算资源提供更多的功能。
二．不可预测的高并发流量会导致系统不可用
互联网场景的另一个特点是会因为一些外部环境的因素导致不可预测的突发流量出现，例如2013年某明星离婚，2017年明星公开恋情，都导致微博等社交媒体出现瞬间激增的流量，从而导致微博服务出现无法正常刷新、无法评论等运营事故，给相关产品造成了相当不好的社会影响。虽然这种不确定流量的绝对值不见得有最高流量时刻的绝对流量高，但是因为突发流量无法预测，系统无法对资源做提前的调度和准备，对系统稳定性和可用性造成的影响不亚于绝对最高流量的场景。而传统单体应用的所有功能都集中在同一应用中，提升并发性性能主要通过提高应用所在服务器的性能来解决。这种方法对可预测流量还可以应付，但是对于突发流量则无法提前预测并准备资源，这种情况下遇到突发流量往往只能束手无策，而采用分布式微服务架构之后，根据服务架构的自我拓展能力，将应用布置在云上，并开启弹性伸缩功能，当突发流量到来时，快速增加服务实例个数，降低单台服务的平均并发量，可在一定程度上解决突发流量对系统带来的压力。
三．弹性伸缩不能完全解决问题
弹性伸缩可在一定程度上解决突发流量问题，但是在实际应用场合中，弹性伸缩也有它的局限性。
在上一章的课程中，在讲到 Serverless 理念时提到了 Serverless 理念的一个重要的设计思路：数据的计算和存储分离，即数据的计算可以放在弹性伸缩框架中，根据运算量的大小实时调整实例数目，但数据存储的能力要放在持久化的框架和产品中，以保证数据的安全和稳定。在这种架构中，数据的安全和稳定可以得到相对可靠的保障，但是数据的读取和写入能力往往成为限制系统高并发的瓶颈。也就是说，虽然数据可以得到快速的计算，但是会在写入和读取的时候被排队，导致整体的响应速度被拖慢。
虽然说在数据存储技术当中也有通过增加实例数来增加读取和写入速度的技术手段和框架，但是这些手段往往不具有像数据计算那样极速的弹性扩容能力。
对于突发型流量的响应速度往往不能达到用户所需要的速度。以微博流量为例，如果只是单纯的浏览微博，系统访问的压力并不大，但微博提供了转发、评论、点赞等功能，而这些功能都需要大进行大量的相关数据的修改操作，在这种情况下，一旦遇到突发流量，单单依靠弹性伸缩就不能完全的解决高并发问题。
四．单个微服务出现问题会导致连锁问题
在大型系统中，一个功能往往由多个模块组成，模块和模块之间的互相调用关系往往非常复杂，而数据模块通常处于整个调用链路的最底层，在这种情况下，一旦数据操作的排队读写请求过多，会导致请求的等待时间过长，继而在请求超时之后失败，这样不但会导致数据访问模块压力过大，同时，由于上层调用模块向数据访问模块发送请求而长时间没有返回，上层模块也不得不占用自身的系统资源，等待发往数据访问模块的请求结束。
一旦等待请求的数量过多，将会导致上层模块的资源也被迅速消耗殆尽，而这种情况又会导致再上一层次的模块的请求进入等待和资源消耗，从而进入恶性循环。
这种情况称为调用雪崩，在调用雪崩的状态下，大量的资源并不是在处理业务，而是在做无意义的等待和空转。
如图，
如果没有合适的异常处理手段，Service D 一旦出现异常，会蔓延到 Service G 和 Service F，最后导致最上的Service A 和Service B 完全不可用，而对用户来讲，就会表现出服务卡顿、错误甚至不可用的情况。
五．高并发流量需要更多的整体性能测试和监控
在互联网场景下，高并发流量是最容易导致服务不稳定甚至不可用的主要原因，此外，即使是服务可以正常使用，但如果因为并发量变大导致响应变慢，对用户体验的影响也是相当大的。
如图，根据 Aberdeen Group 公司的研究报告，在外部网站中，1秒的延迟会导致11%的用户流失，同时降低16%的用户满意度，而对于互联网应用来说，一秒的延迟甚至会带来超过16%的价值损失。因此，为了能对大型应用的性能和响应速度有一个直观的掌握，开发者一般会在应用上线之前进行性能测试。所谓性能测试就是指利用自动化的测试系统，模仿大量的用户对系统进行高并发式的访问，来检测系统在高并发流量压力下的反应情况的一种测试手段，所以性能测试又称为压力测试。性能测试不但可以反映系统的整体请求响应情况，同时配合内部的监控系统，性能测试还可以用来进行容量规划，发现模块之间的性能差异和性能瓶颈，以便进行有针对性的优化和调整。因此性能测试是检测系统高可用能力，降低成本、提升用户体验的重要手段，在新版本发布、大促场景准备、线上容量整体规划等场景下显得十分重要。
