22.【学习心得】学习心得-流量调度

简介: 22.【学习心得】学习心得-流量调度

文档参考:书名:《企业it架构转型之道》-钟华 

网络异常,图片无法展示
|


前文如下:

15.【学习心得】学习心得-传统分布式事务

16.【学习心得】学习心得-cap,base理论

17.【学习心得】学习心得-柔性事务

18.【学习心得】学习心得-柔性事务落地

19.【学习心得】学习心得-大促秒杀活动催生缓存技术的高度使用

20.【学习心得】学习心得-链路日志及埋点

21.【学习心得】学习心得-限流和降级

流量调度

1.背景

       今天阿里巴巴的淘宝平台都运行在云平台上,在云平台中不可忽略的一个问题是为了最大程度地增加机器的利用率,会采用超配的方式,即一台物理机上创建的虚拟机CPU核数的总和会超过物理机实际的CPU核数。超配本身并不是一件坏事,淘宝平台包含了上千个大小应用,大部分都是长尾应用,即使在双十一零点,有些应用的流量也是非常低的。这些应用所在的服务器计算能力其实是有剩余的。合理的超配,可以提升机器的资源利用率。但从目前的部署结构来看,同样是核心的应用在虚拟机资源分配上并没有避免超配的现象,这就造成在业务繁忙时,这些部署在超配服务器上的应用就会出现资源争抢,这样很可能导致个别或局部的应用出现服务响应慢甚至挂起,给整个业务链路带来更大的影响。


       这些因为单机或者局部问题而导致的故障,在阿里巴巴淘宝的线上环境中是普遍存在的,尤其是当我们应用机器数达到几百到几千台的时候,非常容易出现个别或者局部的机器服务状态恶化甚至服务不可用的情况。原因是在分布式环境中,软件、硬件、网络等因素导致机器的实时服务能力是有差异的。


       大家可能会认为只要每台服务器的CPU和内存配置一样,这些机器的服务能力都是一样的,但实际在生产环境中,所有机器的实时服务能力都是有差异的。可能因为一次网络抖动导致这台机器实时服务能力下降,也可能因为CPU超配导致资源争抢,从而最终导致实时服务能力下降。


       除了机器超配之外,还有其他各种原因也会造成这些单点或局部应用出现故障:

❑超卖问题带来的资源争抢问题。

❑部分应用、部分机器启动的时候,容易出现个别机器负载飙高,导致这部分机器响应时间变长。

❑JVM假死、VM假死等问题。

❑受宿主机影响,负载飙高问题。

❑JVM垃圾回收影响请求响应时间的问题。

❑网络抖动导致RT抖动。


       对于机器数达到一定数量级的应用来说,大家往往不会太关注单台机器的服务能力,大家的关注点都是这个应用的服务能力是多少,能否抗住流量高峰。但从前面列举的种种故障来看,一旦单机、局部服务能力出现问题,带来的影响远比我们预估得要严重。

为什么上述单机、局部问题会带来这么大的影响?原因如下:


分布式服务环境调用链路局部问题会被放大到整个链路。 在今天这么大流量的情况下,任何单个系统,都无法处理如今这么复杂的业务逻辑。我们在淘宝上的任意一个请求,涉及的决不仅仅是一个系统,而是一整条链路。链路中任何一个单点出现问题,比如任意一台机器的RT变长、或者调用链路上的单点不可用,会直接导致整个调用链路RT变长或者调用链路不可用。

单点、局部问题会被放大成面。 生产环境中所有的服务调用链路其实是网状结构,我们的一个应用会有着多个上、下游应用,因而一旦单点、局部出现问题,可能导致的是下游的应用都将受到影响。1%的机器出现故障,可能导致100%的业务出现问题。

面对这种影响整体服务体系稳定性的隐患,阿里巴巴中间件团队实现了针对分布式服务系统的流量调度平台,用于屏蔽所有机器的软硬件差异,根据机器的实时服务能力来分配机器的实时流量。对实时服务能力好的机器多分配流量;对实时服务能力差的机器减少流量分配;对实时服务能力不可用的机器迁移流量。让因为软件或者硬件带来的单点、局部问题发生时,不会影响整体业务的稳定运行。


2.实现原理


流量调度的核心是通过秒级获取服务器系统运行指标以及业务指标,通过流量调度平台设置的决策算法以及规则,当发现满足规则条件的指标状态发生时,对线上环境的服务器进行下线等操作,以屏蔽这些单点或局部出现故障的应用实例对整体平台产生扩展式的影响。流量调度架构如图8-8所示。

网络异常,图片无法展示
|


       通过服务器上暴露的指标信息接口(图中Restful API),流量调度的服务器定时(目前的收集频率大概是5s一次,每次指标集合大小1KB,对应用的性能没有任何影响)调用指标信息接口,目前采集的信息包括:


❑系统指标信息:CPU、Load等。

❑业务指标信息:HTTP响应时间、HSF服务调用响应时间、HTTP QPS、HSF QPS、Tomcat线程池使用信息、HSF线程池使用信息。


       目前淘宝平台后端流量基本都是HSF服务。此时,HSF服务框架中的ConfigServer就充当了“引路人”的角色。正如前文所描述的,服务的提供者和服务调用者在自身应用启动时会将服务的发布和订阅信息上传到ConfigServer中,因而,在进行流量调度时,只要ConfigServer推送给服务消费者的服务提供者列表带上服务调用的权重信息,服务消费者在选择服务提供者进行服务调用的时候,就能按照权重信息选择每次调用的服务提供者,从而就能控制所有服务提供者被服务请求的流量大小。 这样当发现某些服务提供者出现服务响应慢或系统资源负载飙高时,实时降低对该服务器的服务路由权重(甚至直接降为0),最终达到通过自动化的流量调度来隔离故障。


目录
打赏
0
0
0
0
76
分享
相关文章
潮玩宇宙大逃杀无聊猿卷轴模式系统开发详细规则丨步骤需求丨方案项目丨技术架构丨源码功能
确定游戏类型和规则:明确无聊猿卷轴模式游戏类型和游戏规则,包括敌人类型、地图设计、任务类型、战斗机制等。
发布、部署,傻傻分不清楚?从概念到实际场景,再到工具应用,一篇文章让你彻底搞清楚
部署和发布是软件工程中经常互换使用的两个术语,甚至感觉是等价的。然而,它们是不同的! • 部署是将软件从一个受控环境转移到另一个受控环境,它的目的是将软件从开发状态转化为生产状态,使得软件可以为用户提供服务。 • 发布是将软件推向用户的过程,应用程序需要多次更新、安全补丁和代码更改,跨平台和环境部署需要对版本进行适当的管理,有一定的计划性和管控因素。
2323 1
15张图超硬核讲解 Kubernetes 网络,我不信网工不会看!
15张图超硬核讲解 Kubernetes 网络,我不信网工不会看!
112 1
熟记这十几个知识点,基本算是半只脚踏入网工了!
熟记这十几个知识点,基本算是半只脚踏入网工了!
网传8月虾皮规模毁offer,程序员该如何做未来的规划和技术储备?
前言 正文开始之前,咱们先了解一下Shopee究竟是一家什么样的公司?给的薪资如何? Shopee(东南亚及中国台湾地区的电商平台)
不吹不黑!阿里新产微服务架构进阶笔记我粉了!理论实战齐飞
目前微服务是非常火的架构或者说概念,也是在构建大型互联网项目时采用的架构方式。随着业务需求的快速发展变化,需求不断增长,迫切需要一种更加快速高效的软件交付方式。而微服务可以弥补单体应用不足,是一种更加快速高效的软件架构风格。
《弹性升级诀窍分享:让双十一来的更猛烈些吧》电子版地址
弹性升级诀窍分享:让双十一来的更猛烈些吧
84 0
《弹性升级诀窍分享:让双十一来的更猛烈些吧》电子版地址

热门文章

最新文章

AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等