搭建网站服务,九度互联网站推广公司,哪些网站使用wordpress,怎么上传软件到网站阿里妹导读#xff1a;双十一的零点#xff0c;整个电商系统的请求速率到达峰值。如果将这些请求流量只分配给少部分 server#xff0c;这些机器接收到的请求速率会远超过处理速率#xff0c;新来的任务来不及处理#xff0c;就会产生请求任务堆积。 今年的中间件性能挑战… 阿里妹导读双十一的零点整个电商系统的请求速率到达峰值。如果将这些请求流量只分配给少部分 server这些机器接收到的请求速率会远超过处理速率新来的任务来不及处理就会产生请求任务堆积。 今年的中间件性能挑战赛就围绕“挑战双11零点流量洪峰”展开。自2015年开始中间件性能挑战赛已经成功举办了四届被历年大赛选手称为“中间件技术的风向标”。接下来跟随阿里巴巴中间件团队的郭浩一起来围观赛题解读赛题。 在现代分布式应用中服务请求是由物理机或虚拟机组成的 server 池进行处理的。 通常server 池规模巨大且服务容量各不相同受网络、内存、CPU、下游服务等各种因素影响一个 server 的服务容量始终处于动态变动和趋于稳定的状态如何设计和实现这种系统的负载均衡算法是一个极具挑战的难题。
自适应负载均衡的需求背景
负载均衡有两个主要目标
保持较短的请求响应时间和较小的请求阻塞概率负载均衡算法的 overhead 在可控级别不占用过多的 CPU 、网络等资源。
自适应负载均衡是指无论系统处于空闲、稳定还是繁忙状态负载均衡算法都会自动评估系统的服务能力进行合理的流量分配使整个系统始终保持较好的性能不产生饥饿或者过载、宕机。
这种算法对于现在的电商系统、数据中心、云计算等领域都很有必要使用自适应负载均衡能够更合理的利用资源提高性能。
对用户而言一旦产生任务堆积请求会变慢甚至超时体验严重下降甚至导致服务不可用。而处理请求的机器也会由于堆积的任务越来越多而发生严重过载直到被打垮。剩余的尚未宕机的其它机器会逐渐重复这个过程直至整个应用不可用发生系统故障。
为了避免这种情况发生我们可能会想到一种常用的办法在服务上线前提前进行压测使用压测的容量作为限流值当线上服务的请求速率大于限流值的时候服务拒绝新到的服务从而保障服务始终可用。但是这种方式也存在问题压测时测试的容量进行限流通常会趋于保守不能充分发挥异构系统的全部性能也无法智能地应对由于网络、下游服务变化而导致的容量下降等问题系统仍然存在宕机风险。
因此我们需要具备自适应能力的负载均衡算法来更好地进行流量分配调度以及稳定性保障追求极致性能挑战大促等场景下的流量洪峰。
结合中间件性能挑战赛的赛题 我们结合「第五届中间件性能挑战赛」中的初赛场景来一起探讨一下设计和实现一个自适应的负载均衡的基本思路。 本次挑战赛的场景由施压程序(阿里云性能测试PTS)、服务调用方(Consumer)和三个规格不同的服务提供方(Provider) 组成。在评测过程中每个程序都部署在不同的物理机上以避免因 CPU、网络资源的竞争导致评测程序抖动影响最终评测成绩。
Becnhmarker 负责请求 Consumer, Consumer 收到请求后从三台物理规格不同、服务响应时间和最大并发都不同的 Provider 中选择一个进行调用并返回结果。选择哪一个 Provider 进行调用的流程就是本次挑战赛需要实现的负载均衡算法。
为了简化环境部署和提升性能本次挑战赛没有使用服务注册和发现机制。三个 Provider 对应的 URL 都已经被直接配置在了 Consumer 中选手在开发和测试时可直接通过 Provider-small 等 hostname 访问相应的 Provider。
赛题分析
题目描述很简单不考虑 Consumer 直接拒绝的情况下场景可以简化为 3 选 1 的问题但如何进行这个决策则是本次挑战赛考察的难点和重点。
官方题目组提供了 Random 算法作为默认实现从 3 个 Provider 中随机取任意一个。对于单 dispatcher 在本次赛题中是 Consumer) 同构系统的场景Random可以达到渐近负载均衡 每个 Provider 接收到的总请求数接近。但是对于多 dispatcher 或异构系统而言Random 算法由于缺少全局状态无法保证全局随机极端条件下多个 dispatcher 可能将请求同时分配到一台 Provider 上导致系统存在服务过载和宕机的风险异构系统中不同 Provider 服务容量实际是不同的即使每个 Provider 请求速率相同也会产生空闲、稳定、过载等不同的服务状态无法实现最优流量分配更不能做到响应时间最小。显而易见Random 并不是符合赛题要求的自适应算法。
那么如何实现自适应负载均衡呢接下来我们将利用题目给出的条件由浅入深的描述这个算法的设计过程。
自适应算法首先要解决如何对服务进行容量评估的问题。
本次比赛按照硬件规格不同Provider 被分为 small、medium、和 large 三种CPU 和内存对应的比例为 1:2:3 。在评测过程中每个 Provider 的处理能力都会动态变化主要体现在单次响应时间的变化和允许的最大的并发数上。来自 Consumer 的请求速率过快时 Provider 端新到的请求会排队等待处理当排队线程数和工作线程数量之和达到最大线程数时Provider 返回线程池用尽异常。在算法的实现和调优过程中应该尽量避免产生线程池异常减少排队。如何结合好程序和硬件的限制区分出不同阶段的瓶颈做出符合实际的容量评估是赛题的第一个难点。对于本次题目所采用的参数和变化过程仅凭现有的理论和实践很难达到最优所以需要选手充分理解题意和各参数配置设计出更适合实际场景的算法。
第二个需要考虑的问题是如何应用容量评估结果即如何维护代表 Provider 服务能力的状态又如何在选择 Provider 阶段根据这些状态进行决策
传统的单 Dispatcher 负载均衡模型由一个 Dispatcher 维护所有 Provider 的状态在同构系统中这种方式能够达到渐进最优负载均衡。但是它存在的问题也很明显单 Dispatcher 性能存在天然瓶颈可扩容性较差当 Provider 数量成倍上升时Dispatcher 需要维护的状态也在成倍上升通信成本也在上升。本次挑战赛中为了降低难度没有基于多 Dispatcher 模型构建题目但多 Dispatcher 、多 Provider 才是 Dubbo 等微服务框架在实际生产环境中最常见的情况。因此若能实现高性能且可扩展性良好的均衡算法会是一个不错的加分项。
第三点是辅助接口的使用。为了不限制算法设计思路赛题提供了多个可能用到的辅助接口包括双向通信、Provider 限流等支持。但是这些接口都是非必选项是否使用这些接口取决于算法实现的需要。
在评测环境中任意一个 Provider 服务处理速率都小于评测程序的请求速率。三个 Provider 总的处理速率会在请求速率上下浮动。最终成绩由请求成功数和最大 TPS 组成失败的请求不计入成绩。对于这个限制可以有两种解读方式一是为了保证服务不严重过载可以适当拒绝请求。第二点是需要充分利用每个 Provider 的服务容量保证性能最优的 Provider 请求数合理适当的过载也是允许的。
以上仅作为一个主要的算法设计思路优秀的负载均衡算法在工程上的实现也是很关键的一点需要选取合适的数据结构充分利用好内存和 CPU压榨出比赛环境的每一点性能。当然评测成绩并不代表一切良好的代码结构、编码风格以及通用性也在最终初赛成绩中占据很大比例。
关注“阿里技术”官方公众号并在对话框内回复“中间件”即可获得初赛赛题。
赛题评测
评测环境由 1 台 4 核 8G 的施压机1 台 4 核 8G 的网关机和 3 台 4 核 8G 的 Provider组成。Consumer 和 Provider 程序都会限制 CPU 和内存使用每个评测任务都会独占五台机器。
准备跑分环境创建并锁定工作区根据提交的 Git 地址从代码仓库中拉取代码构建代码生成最终执行的 fat JAR启动三个 Provider 并验证服务可用性启动 Consumer 并验证服务可用性对系统进行预热持续 30 秒正式评测 1 分钟取正式评测的总成功请求数和最大 TPS 作为最终成绩上报天池系统按顺序依次停止 Consumer、三个 Provider清理 Docker 实例及镜像收集日志并上传到 OSS解锁工作区清理环境。
总结
本文结合第五届中间件性能挑战赛的赛题背景、题目场景、题目分析和评测环境与过程的角度介绍了自适应负载均衡算法的基本设计思路希望对即将参加比赛的同学们能有所帮助也欢迎更多的技术同学报名参加我们的挑战赛分享你在算法方面的思考和实践。
原文链接 本文为云栖社区原创内容未经允许不得转载。
