京东11.11:京麦服务市场交易平台备战实践
您目前处于:  2017-12-18

每年618或11.11大促都是一场技术团队大练兵的时候。京麦平台随京东发展至今,已经历了4次618,3次11.11,今年618备战的场景还记忆犹新,11.11战鼓声却已早早的敲响。那半年的时间里,京麦服务市场又有哪些蜕变呢?


正文

京麦服务市场(fw.jd.com)是为第三方软件服务商和京东商家提供服务的交易平台。京麦服务市场是一个业务极度复杂的系统,在业务上涵盖了服务类商品、促销、计费、订购、订单、支付、结算、退款、发票等逻辑,几乎涉及到电商所有元素。

京麦服务市场架构

大战在即,要保障11.11的平稳度过。首先要整理自己的备战思路,大致整理为几个阶段:梳理薄弱点,系统改造,上线和复盘。

详细来说,备战开始要对系统做一次全面的梳理诊断,其目的就是要找到系统薄弱点。而梳理方法可以从系统部署耦合、UMP 报警 & 日志、慢 SQL & 外部依赖等不同层面作为切入点进行。

在系统改造阶段,通过对系统薄弱点的梳理,进行系统架构改造方案的设计,利用二八原理,集中精力到最重要的环节,即黄金流程的优化,最后制定计划排期。当然,我们可以利用敏捷的思想,小步快跑,持续优化改进。

上线就是临门一脚,台上一分钟,台下十年功。为了保证上线成功,要进行充分的上线筹备。首先要整理上线计划和切流方案,其中包括分阶段上线、灰度上线等。计划准备好之后就要进行反复的压测和演练,包括极端情况的降级和预案的启用等等。经验来讲,大多数上线失败,反复回滚的案例,大多一无计划,二无预案。

即使进行了周密的上线筹备,上线仍然出现意想不到的问题,所以我们要对每一次上线进行复盘总结,从教训中成长,并总结出快速定位问题的技能,以及提升工具使用的能力。

我们以此为思路,通过京麦服务市场进行逐一介绍。


一、梳理薄弱点

找出薄弱点的方法有很多,服务市场作为一个前台系统,我们从最影响用户感知和体验的角度进行梳理。

二、系统改造

通过梳理系统薄弱点,甄别出确认的改造点。

1. UMP 监控报警 & 日志

人常说,研发人员有两只眼睛,一只是监控报警,另一只就是日志,所以无论什么情况监控报警日志一定不能少。本次11.11备战通过采用AOP的方式,对工程所有层进行统一切面添加监控报警和日志。

特别要说的,设置了报警一定要即时处理和优化,无论是性能报警还是可用率报警,需专人跟进推动优化,如果改动量很大或风险很高,可调整报警阈值备注后期优化,警醒狼来了的故事。

2. 确认大流量页面超时时间(少超时,多重试)

超时时间的设置采用少超时、多重试,这实际上是一种快速失败策略,如第三方接口调用超时,如果设置过长,在访问量大的时候,就会导致请求线程积压、CPU飙高等问题。

超时设置一是全面检查MySQL、JimDB、JSF等RPC调用的超时设置,尤其是大流量入口的调用链路,二是根据压测结果结合具体业务场景进行设置调整。

3. 慢SQL

慢SQL问题大多数情况下都是没有索引引起的,还有就是索引使用错误,如索引字段是varchar类型,但是程序中请求DB的时候传的是long类型,造成索引失效等。

首先通过DBA找出慢SQL,其中重点关注调用次数高和响应速度慢的SQL,通过Query ID找到对应的SQL,然后通过EXPLAIN执行计划查看SQL命中的索引。添加索引一定要结合MySQL执行计划来判断,同时添加Index要注意区分度,区分度=count(Distinct索引值)/总条数,区分度越接近1,说明区分度越高,查询的时候就越会过滤掉更多的行数据。还有如果某些SQL操作有大量的JOIN操作,就要想办法拆分SQL,修改代码逻辑,这也是一种平衡的过程。

4. 降级开关

降级开关可以防止实际情况发生的时候准备好的功能不可用。以下图Solr降级开关为例,当so出问题时,我们可以关闭so的写逻辑,sa和sb不影响继续写,同时将读逻辑切换sa,做到平滑切换。当so恢复之后,开启so的写逻辑,将读逻辑开关切换到so,也能做到平滑恢复。当然,要注意so故障时段可能出现的数据不一致问题。

5. 读写分离+多级缓存策略

缓存策略可以有效防止请求直达数据库,造成数据库压力大问题。本次11.11备战采用的缓存策略是JVM+JimDB+DB,缓存的数据主要是列表页/频道页和单品页的服务类目和服务信息。在启动缓存策略的过程中,也要考虑缓存的穿透率,以此来调整缓存最优的过期时间。

不仅如此,我们还要将缓存JImDB中间件的不稳定因素的考虑放到备案中,如多机房的部署采用几主几从,主从之间是否支持自动切换等等。

服务信息多级缓存策略架构

在使用JimDB缓存要注意大Key问题,否则量一上来很容易引起缓存集群的单片热点问题,如服务信息可以根据SpuId的纬度来设置Key,但缓存服务信息会造成实时价格延迟,可以通过数据异构的方式同步价格数据。要注意缓存过期的问题,不建议使用JimDB的过期设置,而是自定义timestamp由应用程序判断是否过期,这样可以解决DB宕机不确定恢复时间的情况下,可以仍从缓存获取数据。对于那些“尺寸较小”、“高频的读取操作”、“变更操作较少”的数据应全部由JimDB来抗量,如服务类目,每个类目ID作为缓存Key,可以通过双写或数据异构的方式。

6. Solr灾备策略(列表页/频道页)

Solr的使用主要服务于搜索和列表页多维度的检索,但是Solr集群情况非常不乐观,如果Solr宕机,不仅搜索不可用,更糟糕的事服务市场列表页就完全不可用,所对Solr的灾备成为当务之急。当然Solr的灾备策略可以参考服务类目和服务信息的多级缓存策略,但是列表页可能涉及到的热点问题和分页逻辑都将问题变得复杂。其实Solr的最优替换方案应该是ES,但一是限于资源问题,二是原检索逻辑复杂,改造限于时间条件可能风险极大,所以11.11之前主要考虑用DB+JimDB进行容灾。

Solr搜索切DB&JimDB拖底,如果Solr降级DB,DB是否有足够的抗压能力支持多维度的检索,无论怎么想,这都不是一个好主意,而且经验告诉我们,DB就不是用来抗量的。那如果Solr降级JimDB,如何针对多维度检索设计JimDB的Key,过多的Key不仅会产生大量的数据,还会有相当的成本保证数据一致性,所以JimDB拖底作为一个过度方案,当Solr降级JimDB时,同时也进行了降纬,只保证通常检索方式。

综上,虽然Sorl可以降级JImDB,但Solr的单机问题是必须解决的问题,所以Solr集群部署采用二主一备的灾备架构,当廊坊机房Solr主s0或马驹桥的Solr主S1出问题,可以切换Solr备,如果此过程中,Solr备直接被流量击垮,则直接降级切换对应机房的Jimdb从,如果还是扛不住,就启动静态页托底。

7. 首页分流加载

官网首页是一个网站的门户,如果首页进不去,那作为一个交易平台更不能进入列表页、单品页或结算页了,所以特别需要注意首页的加载性能和开天窗的问题,也正基于此,对首页的加载采用异步分流加载,不同的区域调用不同的请求,不同的请求数据又是相互隔离,并通过分流加载提升加载速度,同时不把鸡蛋都放在一个篮子里,保证页面的容灾和降级。

8. 单品页加载优化

分流加载的思想也可以应用在单品页中,以保证可以细粒度的降级。单品页的特殊性在于实时价格,直接采用缓存可能会造成价格延迟,导致在单品页看到的价格与结算页不一致,所以对单品页添加缓存时处理实时价格需要进行双写操作,以此保证单品页价格的实时性。

发布服务更新价格,写MySQL,通过异步任务更新主JimDB价格数据。服务信息读取主JimDB中价格,无过期则直接返回,过期或未命中则访问主MySQL,获取最新数据返回用户,同时异步更新主JImDB价格。

三、上线

1. 压测

通过梳理系统薄弱点并进行系统改造部署上线之后,我们就要对线上真正能承载能力进行压测,通过压测知道系统的极限值是多大,当系统承受不住访问时,就会再暴露出瓶颈,如服务器CPU、数据库、内存、响应速度等,从而促使我们再进行优化。线上压测是在凌晨一两点,从线上剥离出一小部分集群,所有服务器和配置使用的都是线上真实的场景进行压测,压测场景分为读业务和写业务。

首先,我们进行了两次压测,在未优化前进行了一次压测,通过对压测结果的分析,看看系统瓶颈主要出现在哪里。第一次压测结果发现大量请求穿透直接调用DB,造成DB的性能急剧下降,数据库服务器的CPU多次飙高,这成为我们备战优化的重点,优化慢SQL,进行数据库读写分离,添加多级缓存,优化系统调用等。

根据第一次压测结果结果进行优化后,第二次压测性能有了很大的提升。

2. 演练

在压测演练过程中,也暴露出很多问题,如数据配置错误未校验、服务器内存未调整、使用新扩容机器压测等,这导致出现了一连串的问题。压测开始服务器CPU90%,数据库无任何响应,因为数据库配置错误导致服务器根本没有连接到数据库。服务器内存1G造成频繁Full GC,性能总是提升不上去。新服务器造成很多配置未同步、权限未申请,花费很多时间解决,影响压测主流程。

3. 预案

预案的执行包括发现问题、定位问题和解决问题。发现问题要结合软硬件问题能够即时发现问题,定位问题包括监控报警和日志分析,这就要看之前添加监控的粒度和日志是否打的有用,最后就是解决问题。

11.11零时大促,京东主站迎来流量洪峰,而到8时才是商家的主战场,接口调用量是平时的3~10倍,系统性能负载也略有飘高,UMP报警也接踵而至,通过监控和日志迅速排查线上隐患和风险,共不同程度启用降级预案。


四、复盘

11.11服务市场还是非常平稳的度过了。而在整个过程中也暴露出了很多问题,有一点是上述没有提到的,那就是心理因素的培训。如在压测演练时,前期时由于遇到各种问题导致结果迟迟不能到达预期效果,整体团队开始出现急躁,处理操作开始变形,出现质疑声音进行自我否定等问题,还好后期即时调整,过程逐渐进入正轨,大家开始慢慢恢复常态。所以,11.11真正开始前我们就开始进行了小复盘,针对心理心态进行了调整和培训,并完善了预案等内容。

在11.11当前出现的问题,团队保持很好的心态处理线上的问题,而整个系统也非常给力的稳定运行。


总结

最后,总结历次的大促,无论是今天给大家介绍的京麦服务市场,还是后期会给大家介绍京麦网关,所面临的技术难点,最重要的还是服务治理。因为我们要打造的不是一个系统,也不是一堆系统,而是一个平台生态,能够持续地提高系统的运营能力。

这里还是以“精打细算,大道至简”这句话结束此次京麦服务市场的总结。


本文受原创保护,未经作者授权,禁止转载。 linkedkeeper.com (文/张松然)  ©著作权归作者所有