加入收藏 | 设为首页 | 会员中心 | 我要投稿 济南站长网 (https://www.0531zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 服务器 > 安全 > 正文

京东大促备战思路2.0大揭秘

发布时间:2021-01-10 07:56:19 所属栏目:安全 来源:网络整理
导读:副标题#e# 《京东大促备战思路2.0大揭秘》要点: 本文介绍了京东大促备战思路2.0大揭秘,希望对您有用。如果有疑问,可以联系我们。 文经授权转自公众号:开涛的博客(kaitao-1234567) 作者简介: 林世洪 毕业于北京交通大学,2011年加入京东,先后负责京东订

一般有如下方法:

  1. 线上服务的性能一般可以通过 UMP 来查看响应时间、吞吐量;
  2. 对于 worker,则可以根据其实际输入输出的数据量来统计;
  3. 线下压力测试.梳理出所有开放的接口,进行接口压力测试,线下进行.测试用的数据可以根据业务逻辑进行编制,也可以利用 TCP Copy等技术获取;
  4. 线上读接口压力测试;
  5. 线上写接口压力测试.这种测试应该非常小心,注意不要产生垃圾数据,对业务造成影响.常用的避免影响业务的方法有:a)?给数据打上测试标签,所有参与测试的系统都要根据此标签识别出正式数据和测试数据;b)?设计好数据处理流程,在这个流程的最后一步才是真正地把数据提交到正式的主业务库,而测试流程不执行这一步,或者结合标签的方法,在这一步过虑掉测试数据;
  6. 减少线上服务器数量,让更少的服务器承担不变的压力,从而增大单台服务器的负载;
  7. 如果面临大促,则可以考虑跨系统主流程压测:在上游积压一定量的数据,以设计好的速度下发请求,验证后面的流程在设计的并发请求量下是否畅通.这种方法不但需要跨研发团队沟通,也需要和业务团队进行沟通,因为可能会影响到生产时效,同时可能会影响团队绩效.

1.3. SLA确认

上下游系统之间进行 SLA 确认,是非常有必要的,如果被依赖的系统达不到性能需求,则依赖方的系统100%达不到性要求.因为问题影响首先会在依赖方显现,所以依赖方更有动力去推动这项工作,如果没有达成 SLA,则需要承担责任.当然被依赖方也有义务配合,如果有分歧,则需要协商一个可以接受的 SLA.

这一个步骤,需要及早进行,只要指标确定,就可以开展了.下面是一个样例:

其中,”是否可降级”,指的是当服务不可用或者性能下降,影响了调用方的可用性和响应时间到一定程度时,可以不调用或者有限调用.如果可降级,应该还要有具体的降级措施和补偿措施.

“超时”指服务调用方的超时设置,超过这个时间将认为本次调用无效,调用方可以重试.如果存在多级依赖关系,如 A 调用 B,B 调用 C,则超时设置应该是 A>B>C,否则可能引起 DDOS 攻击效果.

1.4. 系统改造

关于如何进行架构升级,不是本文的重点,建议大家去参考架构委员会的架构白皮书,白皮书系统地介绍了架构的原则和方法,非常有指导意义.这里只强调下大促备战最常用的内容,并且主要从应用角度来阐述.

1.4.1. 提高系统处理能力

在评估阶段,我们强调过,最主要的系统改造目标是提高系统处理能力,对应的主要措施是:

第一,?硬件升级,使用配置更高的硬件.但是,有的情况下即使硬件配置上去了,但分配给应用本身的资源没变,这样处理能力没有得到提升,资源利用率很低,这点尤其要注意.

第二,扩容.系统要扩容,首先要使系统具备水平扩展能力,应用的每一层都要能水平扩展,不能留有瓶颈.系统到了一定规模后,可以考虑以集群为单位进行扩容,每一个标配的集群的有定量处理能力.而且线上系统出现瓶颈时,可以扩容或者替换若干个集群,这样简单高效.数据访问层的扩展能力尤其重要,从京东系统现状上来看,这一层往往是瓶颈,而且瓶颈一旦出现,解决起来时间比较长,建议大家引入公司内部的 JDAL 等中间件来实现.

第三,将系统进行拆分,从而将负载分摊,同时也降低问题影响面.可以按自顶向下,自业务到技术的线路去考虑对系统进行拆分,首先看是不是可以从业务域上切分,然后再从功能的相互依赖关系上分析,将相互依赖紧密但与其它应用交互很少的功能作为一个子系统拆分出来.当然,对于有用户界面的系统,出于客户体验的考虑,系统拆分后,要注意尽量保持UI的统一.

第四,提高响应速度.详见保持响应速度一节.

第五,使用编程技巧.如串行变并行、单个处理变批量处理等.

1.4.2. 保持响应速度

大促备战一般不会提出更高响应速度的要求,主要是能保持原来的响应速度,甚至允许有一定程度的下降.主要是因为系统负载增大后,处理过程中可能出现等待资源的情况,传输过程中也可能出现阻塞情况,从而增大了处理时长.提高响应速度的方法一般有:

第一,Review系统.对系统的每一层,甚至硬件都进行审查,低性能的代码和 SQL,低性能的中件间,有问题的硬件,都会影响性能,都需要改造或者替换.

第二,使用缓存.首先描绘出从客户端发请求到接到服务端应答的全路径,然后分析这条路径上的每一个节点,是否有必要增加缓存.实际上,缓存的本质就是把内容存到离客户端更近、访问速度更快的节点上;缓存的内容可以整个网页、一个完整的请求-应答、一个对象、一个变量值,等等.常用的缓存技术有:

第三,优化依赖.如果一个系统服务对外有依赖,则有必要对其进行分析,看是否要以优化.首先要进行流程分析,识别出主流程,对不是主流程中的逻辑,通常有优化的余地.常用的方法有:

第四,系统分解.涉及到的方法有很多,例如:

1.4.3. 保持可用性

为保持可用性,一般可以采取如下措施:

(编辑:济南站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!