稳定性保障需要一定的架构设计能力，又是微服务架构比较核心的部分。
一、极端业务场景
1、可预测性场景
什么是可预测性？简单来说，就像电商每年的大促，如 618、双 11、双 12 等等。这类业务场景是可预测的，业务峰值和系统压力峰值会出现在某几个固定的时间点，我们所做的所有准备工作和稳定性应对措施，都是针对这些固定时间点的，比如零点时刻。
峰值压力可预测，就意味着可以提前评估用户访问模型，并根据模型进行压测调优。发现系统中的瓶颈就调优或者扩容，调整完成之后，继续压测，继续调整，直至系统容量达到原来设定的目标。由此可见，在可预测的场景下，从准备过程上来说会更加从容。
这里采取的策略是在系统承诺容量内，保证系统的核心功能能够正常运行。以电商为例，就是要确保整个交易链路是正常的，用户可以正常登陆，访问商品，下单并最终支付。对于非核心功能，就会通过预案执行功能降级。对于超出系统承诺容量的部分进行流量限流，并确保在某些异常状况下能够熔断或旁路，比如缓存故障，就要马上限流并将请求降级到数据库上。
2、不可预测性场景
那不可预测的场景就更为复杂。社交类业务就具有这种明显的特征，比如微博、朋友圈、空间等等。以微博为例，明星婚变突发事件等等，这些事情什么时候发生，对于平台来说事先可能完全不知道，而且极有可能是大 V 的即兴发挥。当然，现在因为商业合作上的原因，某些大 V 的部分营销活动也会与各类社交业务平台提前沟通，确保活动正常执行，但是即使是提前沟通，周期也会非常短。
对于不可预测性的场景，因为不知道什么时候会出现突发热点事件，所以就无法像电商大促一样提前做好准备。社交类业务没法提前准备，就只能随时准备着，这个挑战还是非常大的。
二、要应对的技术挑战
1、运维自动化
应对极端场景下的系统压力，一定要有资源支持，但是如何才能将这些资源快速扩容上去，以提供业务服务，这一点是需要深入思考的。标准化覆盖面是否足够广泛，应用体系是否完善，持续交付流水线是否高效，云上资源获得是否足够迅速，这些都是运维自动化的基础。特别是对于不可预测的场景，考验的就是自动化的程度。
2、容量评估和压测
要时刻对系统容量水位做到心中有数，特别是核心链路，比如电商的交易支付链路。我们只有对系统容量十分清楚，才能针对特定场景判断出哪些应用和部件需要扩容，扩容多少，扩容顺序如何。同时，系统容量的获取，需要有比较完善的自动化压测系统，针对单接口、单应用、单链路以及全链路进行日常和极端场景下的模拟压测。
3、限流降级
业务在峰值时刻，系统是无论如何也抵御不住全部流量的。这个时候，我们要做的就是保证在承诺容量范围内，系统可用；对于超出容量的请求进行限流，请用户耐心等待一下。如何判断是否需要限流呢？这时我们要看系统的各项指标，常见的指标有 CPU、Load、QPS、连接数等等。
同时，对于非核心的功能，在峰值时刻进行降级，以降低系统压力。这里有两种方式，分别是主动降级和被动降级。主动降级就是在峰值时刻，主动把功能关掉，如商品评论和推荐功能等等。对于被动降级，也就是常听到的熔断。某个应用或部件故障，我们要有手段将故障隔离，同时又能够保证业务可用，所以会涉及故障判断和各类流量调度策略。
4、开关预案
比如当缓存故障时，我们就需要将请求转发到数据库上，目的也只有一个，让系统可用。但是问题来了，数据库的访问效率没有缓存高，所以缓存可以支撑的流量，数据库肯定是支撑不了的，怎么办呢？这时，就要与限流策略结合起来，先限流，限到数据库能够支撑的容量，再做降级。这样几个策略组合在一起，就是应急预案的执行了。当然，预案里面还会有业务预案。
5、故障模拟
上述预案，需要在日常，甚至是从经历过的故障中提炼出场景，制定好策略，然后不断进行模拟演练。只有这样，等到真正出现问题时，我们的预案才可以高效执行。我们知道 Netflix 的 Chaos Engineering，其中的 Chaos Monkey，就是专门搞线上破坏，模拟各种故障场景，以此来看各种预案执行是否到位，是否还有可以改进的地方。
6、监控体系
监控的重要性就不言而喻了，因为所有的指标采集和统计，异常判断，都需要监控体系的支持。监控体系和前面介绍的运维自动化一样，都是最为基础的支撑平台。
三、不确定因素
对于稳定性保障而言，最困难的部分，不在技术层面，而是在业务层面，也就是用户的业务访问模型。从技术层面来说，还有一些确定的套路可以去遵循，但是访问模型就是个极不确定的因素了。
对于稳定性而言，用户访问模型才是关键，这个摸不准，只有技术是没用的，这就更需要我们能够深入业务，理解业务。
