dubbo provider服务自检与监控系统的一种实现方案
一、项目背景
最近项目组在进行数据库迁移的过程中，出现了一个比较严重的线上问题，导致整个系统大部分功能无法使用（因为服务器资源有限，dubbo服务器进行了复用），通过排查原因，为线上的某个dubbo provider服务全部堵死。根本原因在于程序中创建了一个队列（BlockingQueue），插入队列时使用的是put方法（这里如果对数据的准确性要求不高，推荐使用offer方法），同时启动了一个线程不断的取队列里面的数据并写入数据库，由于修改了数据库迁移相关的功能后，导致该线程在某种特定场景下被异常杀掉了，当程序运行一段时间后，队列完全阻塞，从而导致整个服务无法使用。
最初我们发现问题主要是通过线上的异常告警服务被动的获取到很多接口调用失败了，但是由于很多服务复用部署，且服务之间的调用很多，只能通过log来排查出现问题的服务，但是出问题的点无法通过log分析得到，由于线上调用量很大，为了不影响用户使用功能，我们只能立即重启服务来解决。
后面通过查找dubbo的相关资料发现，dubbo在线程池不够用时，会每隔十分钟输出一份dump文件到用户目录。但是，如果多个provider部署在同一台服务器，通过查看该dump文件，要快速定位具体的服务还是需要很长时间的。另外，对于生产环境的服务，如果公司运维力量不够的话，出现问题如不能及时发现并解决，则会酿成很大的线上故障，所以需要快速恢复服务。
如何快速检测类似这种线程被使用完，或某些程序分支由于开发与测试不到位引起的死循环、死锁引起的线程耗光的问题，并在检测到程序异常时自启动服务并主动告警，下面是一种实现方案。
二、系统总体方案
总体方案如图所示，主要由四大部分组成：dubbo agent、dubbo agent service、tomcat monitor daemon（tomcat守护进程）、管理后台。
- dubbo agent
启动一个线程，定时调用dubbo agent service进行服务状态探测，如果服务异常，则定时按服务生成trace dump文件和heartbeat异常标识文件，并上报给管理后台，并从管理后台取一些个性化差异的配置数据，如有些服务异常时，可以设置服务是否需要重启，以便运维及开发进行现场排查问题（当然，可以通过dump文件进行排查）。
- dubbo agent service
处理收到的探测包，并更新服务状态数据。
- tomcat monitor daemon
守护tomcat进程，定时检测heartbeat标识文件，如果发现heartbeat文件，则重启tomcat服务。
- 管理后台
进行所有服务的异常状态管理、告警，当收到异常上报时，发送邮件和短信给运维和开发人员。
- 服务接入
由于已经服务众多，若要接入dubbo provider的自检与监控，应尽可能少的改动原有服务代码，这里只需在服务的bubbo配置文件中加入如下配置即可：
- 管理后台业务看板
以上为设计的简单的方案，如有更好的替代方案欢迎赐教！