每日一读-以太极思想为基础的柔性服务架构方案

服务稳定性

对于一个服务来说,服务的稳定性是高于一切的,如果出现问题很有可能会给企业带来直接的经济损失。举个栗子,亚马逊的“Prime Day”当天出现的一个故障,给亚马逊带来了高达9900万美元的损失。

从架构层面来说,保障稳定性的手段一般包含以下措施:

  • 限流
  • 降级
  • 熔断
  • 超时
  • 重试
  • 集群

这些措施都直接或间接的有损保障了我们服务能够正常运行,而不会出现整体崩溃的情况

服务限流

服务限流其实是指当系统资源不够,不足以应对大量请求,即系统资源与访问量出现矛盾的时候,我们为了保证有限的资源能够正常服务,因此对系统按照预设的规则进行流量限制或功能限制的一种方法。

其主要作用是保护服务节点或者集群后面的数据节点,防止瞬时流量过大使服务和数据崩溃(如前端缓存大量实效),造成不可用;还可用于平滑请求

常用的限流算法有两种:

  1. 简单请求总量计数
  2. 时间窗口限流:令牌桶算法和漏桶算法

限流的不确定性

一般限流我们常指的是静态的限流--即通过上线前配置一个压测值。

但随着项目的不断演进,代码的复杂度、代码性能、机器的部署等都会促使我们不断要去更新这个限流阈值;这些不确定性都会加重我们的工作,细分下来总共有以下几种场景:

  1. 不同容器实例容量引起的不确定性
    • 云上 vs 云下
    • 独占 vs 混部
    • 不同单元
    • 同单元不同宿主机
  2. 业务演进/依赖变化引起的不确定性
    • 新功能、架构变更等导致服务的资源消耗高
    • 依赖服务变重变慢影响自身系统稳定
  3. 流量模型发生变化引起的不确定性
    • 大促态 vs 日常态
    • 热点数据
    • 同一服务不同分支
    • 流量突变

柔性架构解决不确定性

上面说到的不确定性问题,服务的状态变更会导致信息的熵增,而通过上面的静态阈值手段,是无法应对动态的变更情况。

每日一读-以太极思想为基础的柔性服务架构方案_第1张图片

而如果消除这种不确定性,有如下策略:

  1. 故障容忍
    • 单元化:异地多活,机房隔离
    • 微服务化:服务/链路隔离
    • 全异步化:上下游故障隔离
  2. 过载保护:自适应负载调节
    • 高负载保护系统 依赖变慢自身稳定
    • 无需人工限流配置 减压之后一秒恢复
    • 实时调节提升吞吐 快速兜底体验提升

通过自适应负载调节来应对上述不确定性,使得应用能够就地实时的评估自身负载,让接受的 QPS 与处理能力同步,防止限流评估出错而导致的稳定性问题和资源利用率问题;同时,在应用接收到超高压时,单机压垮的 QPS 可提到更高。从而能够应对更高的突发流量,加固应用自身的稳定性。

FYI

  • 淘宝应用柔性架构的探索
  • 服务限流
  • 架构设计之「服务限流」

你可能感兴趣的:(每日一读-以太极思想为基础的柔性服务架构方案)