构建高可用云原生应用，如何有效进行流量管理？

Posted 2023-05-25 华为云开发者社区

摘要：对于那些希望使用华为云的云原生服务的人来说，这篇文章提供了很好的指导，让他们了解如何通过容错来保证他们的服务的可用性和稳定性。

本文分享自华为云社区《构建高可用云原生应用，如何有效进行流量管理？》，作者： breakDawn。

随着云原生的概念越来越火，服务的架构应该如何发展和演进，成为很多程序员关心的话题。大名鼎鼎的《深入理解java虚拟机》一书作者于21年推出了新作《凤凰架构》，从这本书中可以看到当前时下很多最新的技术或者理念。

因此本文以及后续都将持续沉淀发布这本书的学习笔记和思考，也欢迎购买该书进行详细学习，或者关注后续的学习笔记内容发布，了解精华内容和总结思考。

流量治理

1 服务容错

1.1 容错策略

文章中介绍了故障转移、快速失败、安全失败、沉默失败、故障恢复、并行调用、广播调用等几种容错策略，我用表格的形式直观呈现一下这几种策略的区别，方便理解和选型：

1.2 容错设计模式

1.断路器模式

即服务中发请求的地方都通过一个断路器模块来转发发送
当10秒内请求数量达到20，且失败阈值达到50%以上（这些参数都可以调整）， 则认为出现问题， 于是主动进行服务熔断， 断路器收到的请求自动返回错误，不再去调用远程服务， 这样可避免请求线程各种阻塞，能及时返回报错。
中间会保持有间隔的重试直到恢复后，关闭断路。

2.舱壁隔离模式

如果一个服务中，可能要同时调用A\\B\\C三个服务，但是却共用一个线程池。
如果调用C服务超时，而调用C的请求源源不断打来，会造成C服务的请求线程全在阻塞，直接把整体线程池给占满了，影响了对A\\B服务的调用。

一种隔离措施是对每个调用服务分别维护一个线程池。缺点是额外增加了排队、调度、上下文切换的开销，据说Hystrix线程池如果开启了服务隔离，会增加3~10ms的延迟。

另一种隔离措施是直接自己定义三个服务的计数器，当服务线程数量到达阈值，自动对这个服务调用做限流。

3.重试模式

故障转移和故障恢复这2个策略一般都是借助重试模式来处理的，进行重复调用。

重试模式应该满足以下条件才能使用：

• 仅在主路核心逻辑的关键服务上进行同步的重试， 而非关键的服务
• 只对瞬时故障进行重试，对于业务故障不进行重试
• 只对幂等型的服务进行重试

重试模式应该有明确的终止条件，例如：

• 超时终止
• 次数终止

重试一定要谨慎开启， 有时候在网关、负载均衡器里也会配置一些默认的重试， 一旦链路很长且都有重试，那么系统中重试的次数将会大大增加。

2 流量控制

流量控制需要解决以下3个问题

• 依据什么指标来限流
• 如何限流
• 超额流量如何处理

2.1 流量统计指标(依据什么指标来限流)

• 每秒事务数TPS： 事务是业务逻辑上具有原子操作的业务操作，对于对买书接口而言， 买书就是一个事务， 背后的其他请求是不感知的。
• 每秒请求数HPS： 就是系统每秒处理的请求数， 如果1事务中只有1个请求， 那么TPS=HPS， 否则HPS>TPS
• 每秒查询书QPS： 是一台服务器能够响应的查询次数。 对于单节点系统而言，QPS=HPS，对于一个分布式系统而言HPS>TPS

通过限制最大TPS来限流的话，不能够准确反映出系统的压力， 因此主流系统倾向使用HPS作为首选的限流指标。

2.2 限流设计模式（如何限流）

流量计数器模式

统计每秒内的请求数是否大于阈值
缺点：

1. 每秒是基于1.0s-2.0这样的区间统计， 但如果是0.5-1.5 和1.5-2.5分别超出阈值，但是1.0-2.0没有超过阈值，则会出现问题。
2. 每秒的请求超过阈值，也不代表系统就真的承受不住，导致五杀

滑动时间窗模式

滑动时间窗专门解决了流量计数器模式的缺点。准备一个长度为10的数组，每秒触发1次的定时器。

1. 将数组最后一位的元素丢弃，并把所有元素都后移一位，然后在数组的第一位插入一个新的空元素；
2. 将计数器中所有的统计信息写入第一位的空元素；
3. 对数组中所有元素做统计，清空计数器数据。可以保证在任意时间片段内，只通过简单的调用计数比较， 控制请求次数不超过阈值

缺点在于只能用于否决式限流， 必须强制失败或者降级，无法进行阻塞等待的处理。

漏桶模式

漏桶和令牌桶可以适用于阻塞等待的限流。漏桶就是一个以请求对象作为元素的先入先出队， 队列程度等于漏桶大小，当队列已满拒绝信的请求进入。比较困难的原因在于很难确定通的大小和水的流出速度，调参难度很大。

令牌桶模式

每隔一定时间，往桶里放入令牌，最多可以放X个，每次请求消耗掉一个。

可以不依赖定时器实现令牌的放入，而是根据时间戳，在取令牌的时候当发现时间戳满足条件则在那个时候放入令牌即可

2.3 分布式限流

前面的4个限流模式都只是单机限流，经常放在网关入口处，不适用于整个服务集群的复杂情况，例如有的服务消耗多有的服务消耗少，都放在入口处限流情况其实很多。

可以基于令牌桶的基础上，在入口网关处给不同服务加不同的消耗令牌权重，达到分布式集群限流的目的

总结

流量治理技术对云原生场景的重要性

以上主要介绍了服务容错和容错设计模式，涉及到不同的容错策略和容错设计模式，如故障转移、快速失败、安全失败、沉默失败、故障恢复、并行调用和广播调用。

这2个设计可以保证系统的稳定性和健壮性。这篇文章涉及的话题与云原生服务息息相关，因为云原生应用程序之间会频繁通过进行请求和交互，需要通过容错和弹性来保证高可用性。

因此，对于那些希望使用华为云的云原生服务的人来说，这篇文章提供了很好的指导，让他们了解如何通过容错来保证他们的服务的可用性和稳定性。

华为云如何在流量治理中体现作用

如果能通过将服务API注册到华为云提供的APIG网关上，似乎能够很方便地达成上述2个设计。

比如APIG支持断路器策略，是API网关在后端服务出现性能问题时保护系统的内置机制。当API的后端服务出现连续N次超时或者时延较高的情况下，会触发断路器的降级机制，向API调用方返回固定错误或者将请求转发到指定的降级后端。当后端服务恢复正常后，断路器关闭，请求恢复正常。APIG-断路器策略

同时APIG还提供了流量控制策略，支持从用户、凭据和时间段等不同的维度限制对API的调用次数，保护后端服务。支持按分/按秒粒度级别的流量控制，阅读了上文中提到的几个流量策略，再去看APIG里配置的流量策略值，则会很容易理解。APIG-流量控制策略

可以看到对于这些常见的经典服务设计策略，无需再重复造轮子，使用已有云服务，可以很快地实现相关功能，提升产品的上线速度和迭代效率。

 

点击关注，第一时间了解华为云新鲜技术~

云原生｜SpringCloud 在Kubernetes 上的最佳实践

作者 | 牛兔

导读：本文是《SpringCloud 应用在 Kubernetes 上的最佳实践》系列文章的第 11 篇，从前面两期开始我们进入到了高可用专题，分别介绍了流量防护和故障演练相关内容。本文将从另一个视角介绍如何保障业务高可用性：即业务准备阶段，提前进行线上的瓶颈定位和容量评估，以便更低成本、更高效/真实的发现系统瓶颈点，做到最精确的容量评估。

高可用体系介绍

首先来介绍下高可用体系，应用生命周期的高可用都有哪些策略、分别可以实现什么能力呢？

从上图示意中可以看出，应用生命周期的整个过程中，都有相应的高可用策略，如前面 2 篇文章介绍的流量防护即为线上运行时的线上管控相关策略，混沌工程即为系统演练的相关策略，而全链路压测即为规划阶段的重要策略，其包括线上压测（即环境选择）、容量规划（即压测实施）、弹性伸缩（即生态内联动）。

以下将重点介绍容量评估的重要性，以及如何实施压测来实现容量评估。

为何要进行容量评估？

关于容量评估的重要性及必要性已经是个老生常谈的问题了，分别从技术角度和业务战略角度总结如下：

容量评估的目的自然是解决容量问题，如新业务上线前的准备，大型营销活动的准备等等。大型活动中洪峰流量引起的系统表现不确定性，是最经典的适用场景。一个理想的营销活动周期应该是有如下闭环流程：

性能测试是容量评估的核心手段，性能测试之后通过客户端-应用系统-基础负载一系列的监控分析，最终可得出瓶颈点位于何处、应如何有针对性地优化。上图可以看出，性能测试通过真实、高效的压测方式进行容量评估/瓶颈定位&解决，最终来保障活动稳定进行。

如何进行性能测试？

阿里巴巴全链路压测从 2013 年到现在也已经是第 7 个年头了，在这 7 年间我们不断积累、总结、优化进步，进行这样一种大规模的项目活动，离不开有效的流程把控及分工管理。关于全链路压测的前期准备，这边将不做赘述，有兴趣的同学可以参考文章。以下将重点介绍压测执行阶段操作。

进行全链路压测之前，单应用会进行内部压测，以便能提升全链路压测的效率，即解决内部问题之后再解决联动问题。故以下将分别介绍 Spring Cloud 应用的压测以及全链路压测分别如何执行。

1. 单应用压测 Spring Cloud 应用

单应用的压测不少开发者会选择开源 JMeter 进行压测，甚至还会进行自建平台以便实现高并发能力。这两者都不推荐，他们都有较为明显的劣势。阿里云性能测试服务（PTS Performance Testing Service）提供了云端压测服务，其完美兼容了 JMeter，只需把脚本上传上来即可发起压测。

同时，目前 PTS 上已经支持直接进行微服务压测，不需要自己设置进行插件管理和升级，只需直接在 PTS 中选择对应的集群等信息，即可快速发起压测。

2. 全链路压测

如前面介绍性能压测流程中所属，整个全链路压测包括的前期事宜较多，如环境选择与改造、数据准备、安全策略等，这部分内容在此不做赘述，有兴趣的可以查阅《Performance Test Together》主题相关介绍。本处主要介绍全链路压测的实施：即配置与线上业务模型一样的业务场景，从公网发起真实流量进行多维度和场景的压测，验证容量能力和瓶颈问题的定位。

一般正式压测会按照压测计划，执行多种压测策略。淘宝的 双11 大促压测，一般包含这样几步：

• 峰值脉冲：即完全模拟 0 点大促目标峰值流量，进行大促态压测，观察系统表现；

• 系统摸高：取消限流降级保护功能，抬高当前压测值（前提是当前的目标压测值已经达到，则可以进行摸高测试），观察系统的极限值是多少，可进行多轮提升压力值压测，直到系统出现异常为止。简化摸高测试的提升信息；

• 限流降级验证：顾名思义，即验证限流降级保护功能是否正常，修改限流降级的作用与验证方法，更简化，（AHAS 引入）商业化产品AHAS(应用高可用服务，Application High Availability Service）提供了全面的限流降级能力，可进行全链路的降级保护；

• 破坏性测试：这个主要是为了验证预案的有效性，类似于容灾演练时的预案执行演练。即为持续保持大促态压测，并验证预案的有效性，观察执行预案之后对系统的影响。修改破坏性测试的内容。

3. 在 PTS 上压测

上述压测场景的实施，均可以在 PTS 上操作实现，且配置不同的压测量级数据，来进行多轮压测，并观察其系统表现。压测不应该是一次性的操作，而应该是反复的、多轮验证的操作。以下以峰值脉冲为例，介绍如何在 PTS 上实施压测。

首先是场景的构建。PTS 提供了丰富的创建场景方式，包括 JSON、JMX、YAML 脚本的导入，纯交互 0 编码 UI 创建、云端录制器录制结果导入、完美兼容 JMeter 脚本等。下图作为示例：

业务场景构建完成之后，以 PTS 自研原生引擎（即纯交互 UI 编排模型）为例，提供了丰富的压力来源定制化能力，可实现多地域/运营商的来源定制，更真实地模拟真实流量情况。

同时，可通过 SLA + 定时任务能力，实现“无人值守”压测，对核心业务链路进行周期性的性能摸顶。

压测结束后，PTS 提供了可下载的压测报告，有详细统计数据及趋势图数据，采样日志以及添加了的监控数据，可快速进行问题方向的定位于分析。

4. 在 EDAS 上压测 Spring Cloud 应用

EDAS 的微服务治理能力，同时打通了与 PTS 服务的相应的压测能力，进入到服务查询页面之后点击压测按钮即可开始在 PTS 的性能测试，如下图：

结尾

本文简单介绍了下业务高可用体系的相关策略，容量评估的重要性以及核心手段-性能测试的实施方式，同时在 Spring Cloud 下的快速应用。此外，PTS 还提供了更多功能：

• 全链路压测的流量隔离改造

• JMeter 的环境管理及本地化插件

• 压测过程中，云上业务的架构监控

• JMeter 的高级流量定制

• ......

以性能压测为主线，进行应用系统规划期的容量验证，并以压测数据结果为参考，通过应用高可用服务 AHAS 中流量防护进行从网关到应用多维度的系统防护，以此来实现业务系统上线后的高可用性。后续 PTS 和 AHAS 会提供更多的智能化功能，来更好地帮助实现线上业务在各种极端场景下的连续性。

相关文章推荐：