最近又经历了一次线上服务的 BUG，原因是服务内部的代码逻辑问题，比较简单。

在此记录下来是为了提醒不要再犯。

Vert.x 的官方 Web 开发包 Vert.x-Web 中 提供了内置的 Authentication&Authorisation 支持；通过扩展的 Auth Common 模块和 JDBC auth MongoDB auth Shiro auth JWT auth OAuth 2 等模块，可以覆盖大部分的用户认证与验权的支持。

在实际的项目中，遇到了一个支持多用户提供方的需求：项目的用户是从多个其他项目导入的；项目的逻辑比较简 单，不想维护自己的用户信息数据和外部映射。

比如，项目需要支持主站用户、视频网站等入口登录访问。正常情况下，只需要项目维护一套内部用户表、一个外 部项目表以及内部用户和外部用户的映射表；在用户导入或用户绑定请求时，建立外部项目 ID 和外部项目用户 ID 与内部用户 ID 的对应关系；在登录请求时，根据外部项目 ID 和外部项目用户 ID 调用用户认证回调，通过 后再寻找到内部用户的 ID 即可。

实际在项目的设计和实现过程中，采用了一个比较好玩的方法：在内部用户表的基础上，对用户使用 JWT 的认证模型；用户登录时，根据外部项目 ID 和外部项目用户 ID 调用用户认证回调，发 放 JWT token，在 token 中限定用户的访问权限。

最近经历了一次由于线上 DNS 解析大范围失效引发的问题排查，并且由于应对不当导致的 MySQL 连接数打满。由于问题发上在周末，网络访问和内部沟通都不方便，整个问题的处理大概花费了 14 个小时（上午 10：00 左右到晚上 03：00）。

事故的起因是由于网络 DNS 解析失效，导致服务里面的一段发送 UDP 消息的代码超时，导致接口访问时长增加，导致后续请求在任务队列中排队并超时。排查发现问题之后紧急上线，导致所有服务节点重启之后连接 MySQL 出现域名解析问题，在处理请求的过程中不断创建连接，在域名解析恢复之后把 MySQL 的服务器的连接打满导致部分请求超时。连接打满之后再创建新连接就会失败，触发了一个连接池的 BUG，导致连接池会不断地创建连接，重启也不能解决问题。

负责的服务在线上环境出现了丢弃请求的现象。经排查是由于请求队列中的若干请求处理时间过长，导致队列之后的请求等待以致超时，而在队列中超时的请求会被框架直接抛弃掉。

排查服务日志，发现访问 Cache 超时的量有明显增加；较多的 Cache 超时导致更多的不必要 DB 访问，以致请求的响应时间变长；同时，更多的 DB 访问压力也会对 DB 的平均响应时间有影响；Cache 访问和 DB 访问超时导致请求响应超时，从而导致抛弃量。

问题在于 Cache 访问为什么会出现大量超时？一路排查下去发现有可能是 TCP 丢包导致的快速重传(fast retransmission)引起的。

在负责的一个项目迁移到公司内部私有云的过程中，发现迁移过后的服务的监控数据不理想，具体表现为：平均响应时间増大、响应时间抖动、cache 访问出现部分超时等，与原本物理机上面部署的服务性能有差异。经过排查发现问题的导火索可能是 JVM GC 导致的暂停；经过几轮对比调参之后，基本上保证了服务的较好状态。