记一次Consul服务出现故障的处理

背景

• 服务器类别：线下团队开发服务器。
• 部署类型微服务：Docker 1.10.2
• Consul部署方法：Docker
• Consul参数： -dev -client=0.0.0.0 -ui
• 微服务数量：5
• RPC： GRPC
• golang 微服务发现包： DNS-CLB-GO

服务层关系

NGINX->REST API Gateway -> Microservice -> database

问题的发现

首先来自后端开发人员提供的服务返回信息。微服务的内容无法访问，查看日志没有分析出来具体出错位置，第一感觉是部分微服务的问题。所以去查看微服务的日志发现并没有问题。才意识到所有的微服务无法连接。检查速度过慢的原因如下：

1. 不敢轻易重启服务怕就起不来，造成更大面积的报错
2. GRPC 的微服务重连时间步长是逐渐边变长的，我盯着日志几分钟不可能看出来关键问题在哪里。
3. 很长时间才反应过来应该自己做抓日志做测试。
4. 几个HTTP测试的结果来自Gateway不是微服务，耽误了不少分析时间。

上面的问题如何避免再次花这么长时间去发现

1. 从报文的报错去分析系统错误。如果是很明显从错误直接解决它就可以了。
2. 如果感觉找不到问题，就从头开始抓，首先是NGINX，然后是Gateway ，然后是微服务的server端。多发几次错误的case总是能找到问题的。
3. 如果还是找不到要追到更久远的日志，工作量会变大，所以要从上到下重启。

暴露出我的不足

1. 每次部署成功做自动化测试。
   • 首先是代码正确性的测试。CI里面解决它。
   • 然后是线上业务联通测试。调用所有模块里面的Ping。
2. 关键参数的日志输出不到位也是我吃亏的原因。
   • 关键数据库的参数
   • 服务启动的参数
3. 紧急单容器启动方案没提前准备好。
4. 团队关键服务没有做热备。我应该准备一个热备开发服务器。（因为公司人力成本每人每小时一百元左右而一个热备服务器一个月只有一百元）

核心原因

Consul的bug

解决问题

当我发现这个问题的时候已经大概使用了2个小时的时间，非常紧张，当时我就想着解决问题本身了。但是我这么做事错的。我应该想办法以最快的速度来让服务恢复。而不是尝试Fix来自上游的bug。 经过ISSUE的提示我马上使用了HTTPGet的方法来获取。所有的微服务的地址。到时候想办法再切换回来使用dns做服务发现，毕竟有自己的NS服务器比较方便。