顺序
每年，618或11.11升级都是技术团队培训的时间。京麦平台JD。组件对象模型到目前为止，它已经经历了四次618，三次11.11。今年六一八战备的情景我记忆犹新，但11.11的战鼓已经提前敲响。在那半年里，京麦的服务市场发生了什么变化？
文字
京麦服务市场（FW.JD.Com）是一个为第三方软件服务提供商和京东商户提供服务的交易平台。京麦的服务市场是一个极其复杂的商业系统，涵盖了服务商品、促销、计费、订购、订购、支付、结算、退款、发票等逻辑，几乎涉及电子商务的所有要素。
京麦服务市场结构
战争迫在眉睫。我们应该确保11.11的顺利通过。首先要理清自己的战备思路，大致可以分为几个阶段：理清薄弱环节、体制转换、上线恢复。
具体来说，在战争准备之初，我们应该对系统进行全面的梳理和诊断，其目的是找出系统的弱点。梳理方法可以从系统耦合、UMP报警和；慢点SQL&；不同程度的外部依赖作为切入点。
在系统改造阶段，通过梳理系统的薄弱环节，设计系统架构改造方案，运用28条原则，关注最重要的环节，即黄金流程的优化，最终制定计划和进度。当然，我们可以利用敏捷思维，采取小步骤快速运行，并继续优化和改进。
门前有一只脚在排队。在台上一分钟，在台下十年。为了确保发射成功，我们应该做好发射的充分准备。首先，我们应该整理在线计划和流量切割方案，包括分阶段在线、灰色在线等。在计划准备好后，应该进行重复的压力测试和演习，包括极端条件的退化和计划的激活。就经验而言，大多数在线故障和重复回滚的情况都没有计划或计划。
即使在为发射做了精心准备之后，发射中仍然出现了意想不到的问题。因此，我们应该回顾和总结每一次发布，从中吸取教训，总结快速定位问题的技能，并提高使用工具的能力。
基于这个理念，我们逐一介绍京麦的服务市场。
1、理清薄弱环节
找出缺点的方法有很多。作为一个前台系统，我们从最能影响用户感知和体验的角度来梳理服务市场。
2、制度变迁
通过梳理系统的弱点来识别识别出的转换点。
1.UMP监控报警和报警；杂志
人们常说，研发人员有两只眼睛，一只是监控报警，另一只是日志。因此，无论在什么情况下，监控报警日志都不能少。在11.11战争准备中，采用AOP来统一切割项目的所有层，并添加监控警报和日志。
特别是，如果设置了报警，必须立即对其进行处理和优化。无论是性能报警还是可用性报警，都需要专人进行跟踪和优化。如果变化量大或风险高，可以调整报警阈值。注意后面的优化，以提醒狼的故事。
2.确认大流量页面超时时间（超时越少，重试次数越多）
超时时间的设置采用更少的超时和更多的重试，这实际上是一种快速失败策略。例如，第三方接口调用的超时。如果设置得太长，在访问量大的情况下，会导致请求线程积压和CPU速度高。
超时设置：一是全面检查MySQL、根据压力测试结果和具体业务场景，设置和调整NicholasTse和JSF等RPC调用的超时设置，尤其是大流量入口的调用链接。
3.慢SQL
慢SQL问题基本上不存在索引还有一个索引使用错误。例如，索引字段是varchar类型，但在程序中请求dB时会传递long类型，导致索引失败等。
首先，通过DBA找出慢SQL，DBA主要关注调用次数高、响应速度慢的SQL。查询 ID找到相应的SQL，然后通过解释执行计划查看SQL的索引。添加索引必须结合MySQL执行计划来判断。同时，在添加索引时，要注意区分。区别=计数（不同的索引值）/总数。判别值越接近1，判别值越高，在查询过程中过滤掉的数据行越多。此外，如果一些SQL操作有大量的连接操作，我们必须找到一种方法来拆分SQL并修改代码逻辑，这也是一个平衡的过程。
4.降级开关
降级开关可以防止在实际情况发生时准备好的功能不可用。下图以Solr的降级开关为例。当so出现问题时，我们可以关闭so的写入逻辑，SA和sb不会影响连续写入，并将读取逻辑切换到SA以实现平滑切换。so恢复后，打开so的写逻辑，将读逻辑开关切换到so，也可以实现平滑恢复。当然，我们应该注意so故障期间可能出现的数据不一致。
五读写分离+多级隐藏物策略
缓存策略可以有效地防止请求直接到达数据库，对数据库造成巨大压力。11.11准备中采用的缓存策略是JVM+NicholasTse+dB。缓存的数据主要是列表页/渠道页和单品页的服务类别和服务信息。在启动缓存策略的过程中，还应考虑缓存的穿透率，以调整缓存的最佳过期时间。
不仅如此，我们还应该考虑缓存JIMDB中间件进入记录的不稳定因素，如部署多个计算机机房，使用多个主从，主从支持自动切换等。
服务信息多级缓存策略体系结构
使用NicholasTse缓存一注意大钥匙的问题。否则，很容易在缓存集群中引发单芯片热点问题。例如，服务信息可以根据spuid的纬度设置密钥，但缓存服务信息会导致实时价格延迟。价格数据可以通过异构数据进行同步。二请注意缓存过期的问题。建议不要使用NicholasTse的过期设置，而是定制时间戳以确定应用程序是否会过期。这可以解决在数据库停机和恢复时间不确定的情况下仍然可以从缓存中获取数据的问题。三对于“小尺寸”、“高频读取操作”和“少量更改操作”的数据，JimDB应该抵制数量。例如，对于服务类别，每个类别ID都用作缓存键，可以用双数据或异构数据写入。
6.Solr灾难恢复策略（列表页/频道页）
Solr的使用主要服务于列表页面的搜索和多维检索，但Solr的集群情况并不乐观。如果Solr倒下，不仅搜索不可用，服务市场的列表页面也将完全不可用。因此，Solr的灾难恢复已成为一项紧迫的任务。当然，Solr的灾难恢复策略可以参考服务类别和服务信息的多级缓存策略，但列表页面中可能涉及的热点问题和分页逻辑将使问题复杂化。事实上，Solr的最佳替代方案应该是es，但首先，它仅限于资源问题。第二，原始的检索逻辑很复杂，转换仅限于时间条件，这可能非常危险。因此，11.11之前主要考虑DB+NicholasTse灾难恢复。
Solr搜索数据库；JimDB拖到了底部。如果Solr降级了dB，不管你怎么想，dB是否有足够的抗压能力来支持多维检索都不是一个好主意，经验告诉我们dB不是用来抵抗的。如果Solr贬低JimDB，如何设计JimDB的多维检索键？过多的密钥不仅会产生大量数据，而且要确保数据的一致性，还需要相当大的成本。因此，JimDB拖底是一个过度的计划。当Solr降级JimDB时，它也降低了纬度，只是确保了正常的检索方法。
总而言之，虽然sorl可以降级jimdb，但Solr的单机问题必须得到解决。因此，Solr的集群部署采用了两主一备的灾难恢复架构。当Solr在廊坊机房的主S0或Solr在马驹桥的主S1出现问题时，Solr的备用可以切换。如果在此过程中Solr的待机被流量直接破坏，则直接降级并切换相应机房的jimdb从机。如果仍然无法携带，请启动静态页面底部。
7.拆分加载主页
官方网站的主页是网站的门户。如果无法访问主页，则列表页面、单一产品页面或结算页面不能作为交易平台访问。因此，应特别注意主页的加载性能和打开天窗的问题。在此基础上，主页加载采用异步分流加载，在不同区域调用不同的请求，不同的请求数据相互隔离，分流加载提高了加载速度。同时，鸡蛋不会放在一个篮子里，以确保灾难恢复和页面降级。
8.单产品页面加载优化
拆分加载的思想也可以应用于单个产品页面，以确保细粒度的降级。单一产品页面的特殊性在于实时价格。直接使用缓存可能会导致价格延迟，导致单个产品页面上的价格与结算页面上的价格不一致。因此，在向单产品页面添加缓存时，需要进行双写操作来处理实时价格，以确保单产品页面的实时价格。
发布服务更新价格，编写mysql，通过异步任务更新主NicholasTse价格数据。服务信息显示了主NicholasTse中的价格。如果没有过期，将直接退回。如果过期或丢失，它将访问主Mysql获取最新数据并返回给用户。同时，它将异步更新主jimdb价格。
3、上网
1.压力测量
在梳理系统薄弱环节，进行系统上线改造部署后，需要对上线的实际承载能力进行压力测试。通过压力测试，我们可以知道系统的极限值。当系统无法承受访问时，瓶颈会再次暴露，如服务器CPU、数据库、内存、响应速度等，从而促使我们再次优化。在线压力测试是在凌晨1:00从在线剥离一小部分集群。所有服务器和配置都使用真实的在线场景进行压力测试。压力测试场景分为读业务和写业务。
首先，我们在优化之前进行了两次压力测试和一次压力测试。通过对试压结果的分析，可以看出系统瓶颈主要出现在哪里。第一次压力测试结果显示，大量请求渗透并直接调用dB，导致dB性能急剧下降，数据库服务器CPU多次飙升，这成为我们准备和优化的重点。我们优化了慢速SQL、分离数据库读写、添加多级缓存、优化系统调用等。
根据第一次试压的结果进行优化后，第二次试压的性能有了很大提高。
2.操练
在试压演练过程中，也暴露出许多问题，如未经验证的数据配置不正确、服务器内存未调整、新扩容机试压等，导致了一系列问题。压力测试开始时，服务器cpu90%不会响应数据库，因为数据库配置错误导致服务器根本无法连接到数据库。服务器内存1g导致频繁满 GC，性能无法提高。由于新服务器的存在，许多配置未同步，权限未应用，这需要花费大量时间来解决，并影响压力测量的主要过程。
3.计划
该计划的实施包括发现问题、定位问题和解决问题。应结合软件和硬件问题来发现问题。问题定位包括监控报警和日志分析。这取决于之前添加的监控粒度和日志是否有用。最后，问题解决了。
11月11日0:00，京东主站。com迎来了交通的洪峰，8:00，它是商人的主战场。接口调用量是平时的3~10倍，系统性能负载也稍高，UMP报警也随之而来。通过监控和日志记录，快速调查在线隐患和风险，并在不同程度上启用降级计划。
4、双倍报价
11.11服务市场仍然非常稳定。在整个过程中，暴露出了许多问题。上面没有提到的一件事是心理因素的训练。例如，在试压演习期间，由于早期遇到的各种问题，结果未能达到预期效果。整个团队开始不耐烦，处理操作开始变形，出现了问题和自我否定。幸运的是，这个过程在后期立即进行了调整，过程逐渐走上正轨，大家开始慢慢恢复正常。因此，在11.11真正开始之前，我们开始了小范围的恢复，调整和训练了心理状态，完善了计划等内容。
在11.11当前的问题中，团队保持了良好的态度来处理在线问题，整个系统非常棒。
总结
最后，我将总结之前的促销活动。无论是今天向您介绍的AndyLau服务市场，还是稍后向您介绍的AndyLaugateway，最重要的技术难题是服务治理。因为我们要建立的不是一个系统或一堆系统，而是一个平台生态，可以不断提高系统的运行能力。
以下是京麦服务市场的结论，用“精打细算，简单易行”这句话。
原Po所有者：张松然/linkedkeeper
最新评论