服务稳定性
对于一个服务来说，服务的稳定性是高于一切的，如果出现问题很有可能会给企业带来直接的经济损失。举个栗子，亚马逊的“Prime Day”当天出现的一个故障，给亚马逊带来了高达9900万美元的损失。
从架构层面来说，保障稳定性的手段一般包含以下措施：
- 限流
- 降级
- 熔断
- 超时
- 重试
- 集群
这些措施都直接或间接的有损保障了我们服务能够正常运行，而不会出现整体崩溃的情况
服务限流
服务限流其实是指当系统资源不够，不足以应对大量请求，即系统资源与访问量出现矛盾的时候，我们为了保证有限的资源能够正常服务，因此对系统按照预设的规则进行流量限制或功能限制的一种方法。
其主要作用是保护服务节点或者集群后面的数据节点，防止瞬时流量过大使服务和数据崩溃（如前端缓存大量实效），造成不可用；还可用于平滑请求。
常用的限流算法有两种：
- 简单请求总量计数
- 时间窗口限流：令牌桶算法和漏桶算法
限流的不确定性
一般限流我们常指的是静态的限流--即通过上线前配置一个压测值。
但随着项目的不断演进，代码的复杂度、代码性能、机器的部署等都会促使我们不断要去更新这个限流阈值；这些不确定性都会加重我们的工作，细分下来总共有以下几种场景：
- 不同容器实例容量引起的不确定性
- 云上 vs 云下
- 独占 vs 混部
- 不同单元
- 同单元不同宿主机
- 业务演进/依赖变化引起的不确定性
- 新功能、架构变更等导致服务的资源消耗高
- 依赖服务变重变慢影响自身系统稳定
- 流量模型发生变化引起的不确定性
- 大促态 vs 日常态
- 热点数据
- 同一服务不同分支
- 流量突变
柔性架构解决不确定性
上面说到的不确定性问题，服务的状态变更会导致信息的熵增，而通过上面的静态阈值手段，是无法应对动态的变更情况。
而如果消除这种不确定性，有如下策略：
- 故障容忍
- 单元化：异地多活，机房隔离
- 微服务化：服务/链路隔离
- 全异步化：上下游故障隔离
- 过载保护：自适应负载调节
- 高负载保护系统 依赖变慢自身稳定
- 无需人工限流配置 减压之后一秒恢复
- 实时调节提升吞吐 快速兜底体验提升
通过自适应负载调节来应对上述不确定性，使得应用能够就地实时的评估自身负载，让接受的 QPS 与处理能力同步，防止限流评估出错而导致的稳定性问题和资源利用率问题；同时，在应用接收到超高压时，单机压垮的 QPS 可提到更高。从而能够应对更高的突发流量，加固应用自身的稳定性。
