简称：
健康检查机制、consul的服务健康检查机制方式、设备端服务注册到中间件方式。
参照：
这里简单梳理一下consul的服务健康检查机制
网上关于consul健康检查的说明有很多，基本都是根据官方文档的说明来的，基本上就是一下几种。
- Script+ Interval
- HTTP+ Interval
- TCP+ Interval
- Timeto Live（TTL）
- Docker+ interval
因为这里是人对设备进行管控，所以基于http的健康检查机制足矣。这里只分析HTTP+ Interval方式。
consul的HTTP+ Interval方式，基本上就是，微服务把自身提供的用于健康检查的服务终结点url注册到数据中心，然后consul的agent会在启动的定时器里面在指定Interval对注册的微服务的健康检查url进行请求，根据http status返回码判断服务是否在线，如果不在线则会更新数据中心的服务在线状态信息。下面的步骤应该就是按照某种机制将在线的服务下发到客户端负载均衡模块的客户端，然后微服务发起服务间调用请求的时候，只会调用存活的服务。
要点：
- 终端设备程序需要编写http服务器，编写健康检查和接收下发的消息指令的终结点。
- 中间件需要提供设备注册的终结点，设备注册信息包括设备识别号、健康检查终结点、接收指令终结点
- 中间件固化存储设备注册信息
- 中间件将所有设备注册信息维持到内存中
- 中间件开启定时器，在设定的Interval对健康检查终结点发起健康检查，如果返回的http状态不是200，则判断设备离线，如果是200，则判断设备在线，并与内存中缓存的状态进行比较，相同则无需变更，不同则需要变更缓存和中间件提供给消费者的状态数据。（设备在线和离线给中间件消费方数据的更新时机）
合理性分析：
我们可以使用这种方式，但是这种方式用在设备上，每个设备将会开启一个http服务端口，由于不能预知是否能够允许在每个设备端开启端口，以及开启端口后，每秒接收健康检查的请求的开销，设备是否都能承受。所以这种方式，目前无法判断是否是最合适的。
当然设备上开启了http服务，那么也能更加方便增加接收下发指令的终结点。这也算优势。
简称：健康汇报机制
要点：
- 服务端需要在内存中维持一个数据集合，用来存储前一次健康汇报的信息，包括设备识别号和汇报时间
- 服务端开启一个集中接收所有设备汇报健康的服务终结点，并在这个终结点的处理逻辑中判断是否有内存设备信息集合中不存在的设备汇报出现，如果有，则需要更新给中间件消费方查询的数据（设备上线给中间件消费方数据的更新时机）。
- 服务端需要开启一个定时器，维持监测的Interval，在定时器中检查当前时间和健康汇报最新记录的时间间隔是否超过了Interval，如果超过了，则判断设备离线，这里数据操作无需加锁。如有设备离线，则更新数据库中的设备状态信息（设备离线给中间件消费方数据的更新时机）。
合理性分析：
当设备数量大的时候，服务端承载的压力变大。如果设备状态的消费是从数据库查询状态信息，那么状态的变化必然要及时的更新到数据库，这里假设200个设备同时离线，那么定时器中是在同一个线程中依次判断和写入数据库，貌似合理。
合理性分析的方面：
- 并发数量
- 中间件和设备中资源占用
- 状态获得的及时性，状态变更的反馈速度，和信息必达
- 下发指令的通畅必达，下发指令执行结果反馈的必达和合理性