京东11.11：京麦服务市场交易平台备战实践

京东11.11：京麦服务市场交易平台备战实践

序

每年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价格。

三、上线

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

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

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

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

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

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

四、复盘

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

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

总结

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

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

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