下载掌阅APP，畅读海量书库
立即打开
引入服务治理后，通过服务注册和服务发现已经解决了微服务架构下的不少问题。比如，前文中提到的维护困难和加入代理后无法直接调用的问题，完善了服务间的通信过程。但是“治理”可不是简简单单地维护服务清单和保证通信正常，还需要有一定的纠错能力，保证服务清单中内容的可用性，也就是健康检查和服务纠错的机制。
如果被调用服务的集群中，某几个服务实例因为网络故障或服务器问题无法提供稳定的服务，如菜品服务集群中192.168.1.102:9009、192.168.1.102:9010两个服务实例因为服务器断电导致无法继续提供服务，这时订单服务向菜品服务发起了多次服务调用，根据注册中心返回的实例清单访问了这两个实例，一定会发生访问超时的异常情况。
在服务治理的产品和框架中是如何规避这种问题的呢？业界常用的解决方案是“探活”，或者叫作“心跳检查”。服务中心可以通过这种机制筛选出不健康的服务实例或异常的服务实例，然后将其“踢出”服务清单。等到服务实例正常后，再将其维护到服务清单中。这种机制能够尽可能地保证调用方在发送请求时直接到达正常的节点。
将健康检查机制添加到服务注册和服务发现的流程后，就得到了图5-14所示的步骤图。
图5-14 添加健康检查机制后的步骤
在图5-14中，健康检查相关的步骤都使用虚线来表示。
所有的服务实例在注册中心注册成功后，每个服务实例都需要定时发送请求，告知注册中心自己的状态，业界一般称这个过程为heartbeat，即“心跳”。如果服务实例能够持续发送“心跳”信息，则表示一切正常，服务会被标记为可用的、可发现的。如果注册中心在一段时间内没有收到某个服务实例的“心跳”信息，就会将这个服务实例标记为不可用或不可达的状态，进而从可用的服务列表中剔除该服务实例的信息，在调用方查询可用的服务实例清单时，该服务实例的信息不会返回给调用方。
健康检查和异常服务的剔除操作不需要开发人员太过关注，使用的开发框架和服务中心产品都会集成这部分功能且自动处理。
在微服务架构中服务通信和服务治理是非常核心的知识点，本章由为什么需要服务通信这个问题讲起，之后介绍服务通信究竟是什么，并结合实际的编码介绍基于HTTP的服务通信实践。接着对服务治理知识点进行讲解，对服务治理出现的原因、服务注册、服务发现和健康检查机制进行分析，希望读者能够有所收获。介绍完服务通信与服务治理后，在接下来的章节中笔者将使用Nacos搭建服务中心，并通过实际的编码和项目示例讲解服务通信与服务治理在代码层面是如何体现的。