京东大促备战思路2.0大揭秘
|
一般有如下方法：
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. 保持可用性 为保持可用性,一般可以采取如下措施： （编辑：核心网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
