小记--生产服务优化过程

本文记录了一次生产环境问题的排查和处理过程，虽然是件小事，但主要是由此引申出DevOps的意义和所需技能。

一、问题回顾

线上有钱用是一个在线注册、在线提交资料、自动审核、自动放款的的小额信贷产品。

1. 首先是进件压力上升

6月28在线投放稍微放量，当天注册用户是平时自然流量的10倍，认证资料进件压力大增，风控处理缓慢，由于风控是公司公共基础服务，所以对其他产品也造成了延迟响应影响。公司的一个产品期望风控优先处理他们的进件，因为他们是线下销售获客。于是我们临时暂停了有钱用注册业务和进件业务，直到晚上凌晨才放开。接着是风控加机器以应对突增峰值。

2. 服务接口响应缓慢

第二天早上一切正常，准备找找需要优化的点进行优化，中午正在去去吃饭路上，突然服务告警，根据健康检测告警提示，服务接口响应缓慢(监控检测要求5秒内响应)，并且一直告警，于是乎赶紧会公司排查处理。查了一下最近访问响应耗时(目前监控还不完善)，发现普遍耗时较多(从几秒到几十秒)，已经远远超出正常耗时(几十毫秒)。初步判断是某些请求耗时较多，导致很多连接被长时间占用，从而其他请求也都进入了队列等待，导致延迟，趋向于DOS攻击情况。

幸好前一阵将http和dubbo接口调用情况都写入了ElasticSearch，于是使用ES查询了下平时耗时比较多的几个接口，发现都与公共服务的几个dubbo接口有关，于是乎基于dubbo方法维度配置了一下这几个dubbo接口的最大并发线程数量。上线完成后，效果很明显，平时耗时较少的接口也都恢复正常服务了，监控检测也正常了。为了应对更多的请求，有钱用业务前置也适当的扩增了实例。

3. 数据库IO压力上升，数据同步延迟严重

自从扩增了实例，优化了接口，后台服务所能承载的请求就更多了，表面一切正常。但是第二天早上10点一放开提现接口，运维就说数据库压力上升，主从同步延迟很严重，并且是从10点开始，但是没有更具体的描述了，只能自己排查。为了不影响其他业务，暂停了提现业务，然后等数据库压力下降，据说主从同步恢复执行了1个小时。

初步排查提现接口，发现就是插入了3条数据，发了一个MQ消息，就没有了，并且没有数据更新。然后查询ES，发现提现接口响应也很快，这就有点奇怪。然后怀疑是有攻击，于是通过ES筛选了下访问量大的IP和用户，然后分别查看每个IP下以及每个用户的访问详情信息，经过仔细分析也没有异常，频率正常，频次稍多点，耗时正常。然后就开始怀疑人生了…

经过上面的分析，提现接口上下都有几个其他接口请求，并且很有规律(我们的提现额度每天有限，需要用户抢的~>_<~)。既然数据库IO压力上升，那就与数据写入有关，并且应该是大量数据频繁写入。为了探明这几个接口是否真有问题，需要知道请求流量情况，但是晚上了，都下班了(包括运维)，自己又没有权限查看生成环境nginx日志进行分析。既如此，自己动手丰衣足食，在请求入口拦截器将请求体大小写入ES。

写是写入了，但是一个个的数据值，我怎么分析走势和对比啊(ES数据还没配置可视化分析工具，近期准备自己写可视化工具呢，但是还没来得及写就需要用了)。

现在写也来不及，幸好有Excel，然后将数据导出到Excel，利用Excel的图标工具将请求流量和PV进行了可视化，经过可视化分析发现在今天早上10点流量暴涨。

然后自己将手机连上代理，自己就开始点提现，发现每次点发送提现验证码，除了会请求提现接口，还会附带其他5个数据上传接口，试了好几次都是这样。因为这几个接口上传的数据，后天都会进行异步处理，所以http耗时很少，响应很快。并且有几个都是全量上传，我也是醉了。现在修改客户端APP也来不及了，一个是都下班了，一个是发版还需要很多个小时。只能从服务器着手处理，于是乎采取了一个简单粗暴的方式，基于用户维度，半小时内重复请求直接丢包。

第二天早上效果很明显啊，数据库压力不再暴涨了，只有小幅上升。

4. 进一步的优化

• 耗时较长的接口限制并发量(基于用户、IP、设备维度)，防止DOS攻击。
• 数据上传的接口限制并发量和请求流量(基于用户、IP、设备维度)，防止DOS攻击。
• 客户端APP优化数据上传，减少带宽占用，以便应对流量峰值或流量攻击。
• 完善监控服务。

---

二、DevOps意义和所需技能

上面的问题排查和处理都是当天几乎是自己一个人在处理。如果自己只会业务功能开发，估计需要好几天才能处理完成。在快速发展的互联网+时代，有个众所周知的名词“敏捷开发”，在研发的世界中还有名次是“DevOps”。DevOps是一种互联网公司结合自身业务本质构思出全新工作方式的过程中所采用的实践，而他们的业务需求也很直接：以史无前例的节奏对自己的系统进行演进，有时候可能还需要以天为单位对系统或业务进行扩展。

如何做到快速高效处理生产服务紧急问题呢，又需要哪些技能呢?

1. 全局观

从业务需求出发点到研发实现，从研发实现到运维部署，以及服务基础设施，从业务前置到各个公共基础服务的业务和架构，都要做到心中有数，才能在关键时刻想到多种处理方式。

2. 工欲善其事必先利其器

• 首先会使用第三方工具和脚本，不一定深入其髓，但是至少需要涉猎，最好能自己动手操作过。
• 需要自己拥有开发工具和写脚本的能力，第三方工具和脚本不一定能找到，及时找到了，也不一定完全符合自己的所需，需要修改。
• 工作中实现更多的自动化运维和监控工具，推荐使用开源的，同时期望自己写的工具也能开源共享。

3. 自信力+折腾

如果想实现好的DevOps需要让开发人员更多地控制生产环境。要想学会和拓展技能需要敢折腾，敢折腾才有机会。还要能折腾，折腾过程中会遇到前所未有的各种困难，你需要有足够的自信力和耐心克服。最终走向会折腾，熟能生巧，一方面是技能上熟练了，另一方面心理也被磨练的成熟稳重了，在后期的折腾中会更加高效。

4. 共享

自己再牛，也是有极限的，并且提升速度会越来越慢，一个团队都牛才叫牛。将技能和经验进行无私传递和共享，让更多的人学会，让更多的人超越自己，自己就又有了学习的榜样，前进的动力。

---

三、防患于未然

上面讲解了开发和运维，同时期望开发人员平时注重对业务的深入理解和拓展。另外在平时工作中期望大家能做到“防患于未然”或趋向于“防患于未然”，有时候只是一个顺手的事情，注重安全防范工作内容，“辛辛苦苦大半年，一下回到解放前”，起码还有点本钱东山再起，如果安全漏洞导致数据全部被删掉…呵呵哒

---