记博客服务被压垮的历程

我们有个博客服务，用WordPress做的，最初的目的就是给内部使用，所以当时设计的时候支持的qps很低，而且线上只用了一台机器部署。

​ 虽然服务被压垮是个悲伤的事情，但是整个过程却是十分有趣。在此需要深深的感谢一下我们的运维团队。

1. 运维团队发现博客服务压力过大，导致机器CPU到达100%。迅速通知到我们团队

2. 运维团队迅速将机器扩容，从一台变为五台，但是五台机器的CPU迅速达到100%

3. 运维团队对博客请求进行限流，服务和机器稳定下来

​ 我们开始查看高流量的来源

1. 查看日志，找到了最高请求的URL

2. 查看日志，从15：30开始访问量急剧增加。怀疑该URL被发送了APP PUSH或者放在了高流量入口位置。

3. 查看日志，确认都是手机访问的，但是没有refer，通过检查客户端IP，大多来源于印度，日志无法提供更多信息

4. 找产品、策划、运营团队负责人，都表示没有做过相关操作

5. 通过查看这个URL的内容，怀疑可能是集团其他团队做了什么事情。四处发动关系，找到该团队负责人，因为负责人在开会，一直没有回应

6. 打开该团队的APP，发现启动页为博客的URL。至此确定了来源。

​ 告知运维后，运维决定将流量导到商城首页 - 凡是打开该团队APP的用户，最先看到的是商城首页。服务得以正常运行，我们也收割了一些流量。

​ 后来该团队负责人看到了我们联系的内容，表达了歉意，并把启动页移除。

​ 这次查找问题的历程还是蛮有意思的，从服务被压垮到收割流量，很大的一个反转。但是也暴露了很多问题：

1. 使用其他组的服务，仅仅和业务方确认不够，一定要和服务所有人进行确认。因为业务方可能缺乏技术方面的一些思考，而且容易产生这种流量被收割，给他人做嫁衣的情况
2. 没有常备机器资源。机器资源有限，虽然扩容了4台机器，仍然满足不了需求，而当时只有4台适合扩容。机器资源问题在使用容器后会被解决。
3. 处理方案并不是最优的。机器扩容并非首，。以当时的流量来看，机器扩容后也撑不住，最好的做法是限流，同时知道URL后做nginx层缓存。因为扩容后，这些库容的机器CPU也到100%，影响了这些机器上面的服务。
4. 突发情况没有应急预案。对于所有服务，高并发情况下，都应该有一套应急预案，按照预案走，可以处理的更加有章法一些。
5. 缺乏降级、熔断等能力，这是一个成熟的IT公司必备技能之一，需要后面进行补齐。