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),最终达到通过自动化的流量调度来隔离故障。


相关文章
|
8月前
|
弹性计算 NoSQL 关系型数据库
全网都在讨论阿里云降价,这波操作给跪了!
全网都在讨论阿里云降价,这波操作给跪了!百款产品直降,平均降幅20%,阿里云希望通过此次大规模降价,让更多企业和开发者用上先进的公共云服务,加速云计算在中国各行各业的普及和发展。这次降价包括云服务器ECS、对象存储OSS、云数据库都降价了,真降价,直降价:百款产品直降,平均降幅20%,阿里云百科分享阿里云2024年降价信息汇总表
|
8月前
|
消息中间件 缓存 双11
阿里巴巴如何对抗淘宝双11亿级流量?这本P9纯手打并发手册送给你
淘宝双11,京东618,滴滴打车高峰如何抗住亿级的并发量? 这一份阿里P9纯手打的高并发系统设计手册帮你解决!这份手册分为基础篇、数据库篇、缓存篇、消息队列篇、分布式服务篇、维护篇、实战篇
|
Web App开发 缓存 负载均衡
阿里技术官面鹅厂,被高并发问蒙,含泪整理全网最全线程并发文档
当你开始开始去跳槽面试的时候,明明只是一份15K的工作,却问你有没有高并发、分布式经验,火箭造的让你猝不及防,结果就是凉凉。现如今市场高并发编程、分布式、负载均衡、集群等可以说是现在高级架构后端求职的必备技能。
|
缓存 负载均衡 网络协议
前中电技术总监精讲高频面试题:谈谈你对负载均衡的理解
最近有小伙伴来问我,说让我分享一起关于负载均衡的理解,我说,网上有这么多资料了, 怎么还需要我来分享,他说网上的很多资料不系统,难理解。因此就做了这个视频。
134 0
|
Java 程序员 测试技术
不吹不黑!阿里新产微服务架构进阶笔记我粉了!理论实战齐飞
目前微服务是非常火的架构或者说概念,也是在构建大型互联网项目时采用的架构方式。随着业务需求的快速发展变化,需求不断增长,迫切需要一种更加快速高效的软件交付方式。而微服务可以弥补单体应用不足,是一种更加快速高效的软件架构风格。
化繁为简!阿里新产亿级流量系统设计核心原理高级笔记(终极版)
不管是初入职场的小菜鸟还是有一些工作年限的老司机,系统设计问题对他们来说都是一大困扰。前者主要是在于面试;面试官来一个如何从零到一设计一个完整的系统?大多数人都会直接懵了,因为系统设计覆盖面广,而网上资料又不能面面俱到,单独背背文章肯定是不行的;后者主要在于晋升;想要从程序员进阶到架构师,系统设计是必须要踏入的一道坎,他对你的技术广度跟深度都会有一定程度的考察。
|
缓存 监控 算法
34.【学习心得】学习心得-限流
【学习心得】学习心得-限流
34.【学习心得】学习心得-限流
|
新零售 缓存 运维
32.【学习心得】学习心得-熔断场景
【学习心得】学习心得-熔断场景
32.【学习心得】学习心得-熔断场景
|
缓存 NoSQL 中间件
31.【学习心得】学习心得-全链路日志
【学习心得】学习心得-全链路日志
31.【学习心得】学习心得-全链路日志
|
缓存 监控 架构师
33.【学习心得】学习心得-熔断技术选型
【学习心得】学习心得-熔断技术选型
33.【学习心得】学习心得-熔断技术选型