再谈心跳检测(10.15)

项目第一天上线，平稳顺利，今天整体平台接口服务调用量超过100万次，但是真正的考验还在后面，预计真正月结高峰时期，整体平台的服务调用量将达到1000到3000万次左右的水平。

对ESB服务总线而言，由于需要将业务系统提供的原始业务服务封装为代理服务再发布出去，因此代理服务的运行就和ESB总线引擎，以及源业务服务都相关。你有时候看到的是ESB总线提供的的服务无法正常访问或出现异常，但是可能原因往往确是业务系统提供的原始业务服务出现问题，因此心跳检查包括两方面内容：

1. 检查代理服务是否正常，如果不正常则继续检查原始业务服务

2. 检查业务服务是否正常，如果不正常则是业务服务本身问题，如果正常则是ESB总线出现问题

因此对于心跳检查，我们需要同时检查ESB引擎，同时还需要检查ESB引擎接入的后端业务系统。如果一个ESB服务总线最终接入了20个业务系统，那么实际上需要检查21个点提供的服务是否正常。

对源端业务系统的检测实际上包括两个方面的内容，其一是直接检查wsdl地址能否正常访问，其二是实际调用服务以确认接口服务能否正常响应。有时候业务系统提供的原始服务虽然WSDL地址可以正常访问，但是调用该接口服务可能直接抛出异常。

心跳检查范围本身包括两个方面：

1. 检查ESB总线上封装的每一个web service当前是否能够正常访问。

2. 检查业务系统本身状态是否正常，这个检查仍然通过调用业务系统提供的业务服务完成。

而实际上对于ESB服务总线，更加需要的是对于业务系统本身当前状态是否正常进行检查，但是又没有必要对该业务系统提供的所有业务服务都去实时监测，因此只需要检查该业务系统提供的一个服务即可。那么我们就可以选择一个查询服务来进行检查以避免进入脏数据。这种检查的目的是确保业务系统当前的App Server应用状态是正常的，服务本身能够正常响应而不是出现500, 400，各种连接超时错误或异常。

心跳检查可以灵活的配置检测频率，比如每10秒进行一次心跳检查。

如果一个ESB接入了50个业务系统，那么就需要对50个业务系统提供的服务接口进行心跳检查，这个需要启用多线程，能够并行的对50个业务系统进行探测并实时的返回探测结果。

心跳检查如果按业务系统粒度的话，那么对每一个业务系统就占用一个面板，那么就需要考虑在该面板上需要显示哪些内容。

1. 当前该业务系统提供服务的状态是否是正常的？

2. 一共探测了多少次，其中有多少次探测失败，点击可以进入到失败明细查看界面。

3. 技术连通是否正常？业务连通是否正常？网络连通性？

这个展示除了考虑面板外，实际上还可以考虑通过表格化方式进行展示，在表格中显示具体的指示灯。

对于这种心跳检查，正常探测成功的信息实际上只需要进行探测计数累加即可，但是对于探测失败的，则必须详细记录调用日志和异常日志，以方便后续对探测记录进行分析。