共计 1193 个字符，预计需要花费 3 分钟才能阅读完成。
我的项目背景
产生故障的零碎是基于 spring cloud 和 Vue 搭建的一套前后端拆散的零碎，次要是用来对接小程序来应用的，后端分为两个根底服务、四个核心服务以及三个对端服务，所有的流量都是从网关打到对端服务，再通过对端服务去调用核心服务和根底服务。会员注册数是四千万左右。
遇到的挑战与解决办法
先说说第一个吧，第一个挑战产生在企业会员日当天的下午三点钟，这天经营人员在小程序中开启了一个秒杀流动，就是有一万张买一送一卷，当三点达到时大量用户同一时间涌入小程序中，这一时间的申请数大略是平时的五倍左右，但就在这时小程序呈现了长时间的卡顿和白屏景象，一个申请的响应工夫比平时慢了三倍左右，这段时间继续了五分钟，也就是当这一万张卷抢完后流量迅速下滑才复原。
在后续考察时发现上一次迭代的时候在小程序首页退出了一个新的查问接口，这个接口是在用户进入小程序时会主动触发，这也就导致在流量过高时，店铺零碎就会存在大量申请拜访数据库使得零碎响应工夫变长。零碎性能降落又导致用户反复点击操作，这又加深了零碎累赘，进而更加好转。
解决方案也很简略，就是在首页加一个交互，当用点击后才去触发当初的那个接口，并且在接口中减少缓存，防止数据库压力过大，这其实在开发中很常见，本人写的接口进行测试发现就几十毫秒的响应工夫，然而当用户申请数霎时暴增时数据库接受了他不该接受的分量而被压垮。
再来说说第二个，这次是在某天中，零碎忽然频繁奔溃，在重启后不到半小时就解体，在阿里云平台的 ARMS 监控中能够能够看到零碎在某个工夫节点内频繁的进行 FULLGC, 查看零碎谬误日志发现存在大量 OOM 异样，首先想到的就是会不会又是在搞什么经营流动，申请量暴增导致，然而在查看零碎申请数后发现曲线平缓，并没有峰值。
当临时没有脉络时就从第一个解体的服务开始查，发现其中有个发卷的接口响应工夫间接超时了，查看起因发现有个经营本人创立了一个扫码领劵的流动，每扫一次码就支付一百万张卷，他扫了四次，也就是给他发放了四百万张卷，最初一次扫码时接口就超时了，之后这个人去小程序中查看本人的卷包时导致的 OOM，因为用户的卷最多也就几百张，所以在查问优惠券时没有进行分页，导致一次将几百万的对象存到内存中导致内存溢出。这也就导致当他进行查看一次优惠券，咱们零碎就会解体一次。
解决办法就是先在优惠券发放上加上限，以及分页查问优惠券，并且优化数据库连贯超时工夫，以前将超时工夫设置的太长，导致某个慢 SQL 长期霸占数据库资源，导致系统卡顿。
总结
当遇到零碎解体时，不要慌乱，先从谬误日志以及对应的性能监控平台进行查看，收集有用的信息，友盟的性能监控平台目前还没有应用过，等有机会应用过再来谈谈其与别的监控平台的应用感触。
代码是不会有“灵异事件”的，如果有只能阐明是你还没有学到位，对于某些中央还存在缺点，所以不必胆怯，标准编码以及勤加思考和学习能力写出高质量的零碎。