微服务架构下，如何打造别具一格的服务治理体验？(上)(4)

在大规模部署服务计算节点时,往往还会遇到跨大网段,跨IDC中心,白名单IP策略等问题.所以心跳系统还支持“心跳级联代理”模式,其作用是允许建立多级的心跳群,每个群由若干“代理”心跳服务端组成,它们只负责转发心跳信息,所以服务注册信息也依靠这个过程进行转发到服务注册中心.

在某些特殊业务场景下,对服务注册信息更新延迟容忍度较低,这时,让心跳级联的计算节点也作为服务注册中心.如下图,节点B是1级服务注册中心(以下简称1级中心),节点C是2级服务注册中心(以下简称2级中心).1级中心会存储向自己提交的服务注册信息,也会把这些信息转发到上级服务注册中心.2级中心上可见所有下级中心的服务注册信息.这种模式可以获得更快的服务发现,因为同级的节点发现其他节点服务能力只需经过本级服务注册中心即可,下文会结合服务发现做详细解释.

服务注册中心依靠TTL的方式对服务接口注册信息进行生命周期管理.我们定义生命状态如下：

另一个关键点是服务接口名的定义,它应该是全局唯一的命名,因为在多个服务能力之间互相调用时是以服务接口名为目标的.在服务画像时,会自动生成服务接口名,它提取以下三类信息：

它们共同构成服务接口名,例如：

2)服务发现

服务发现的本质是通过服务接口名查询服务注册中心,服务注册中心基于某些策略返回服务接口可用地址列表,服务调用方也可以基于某些策略来使用地址列表.

微服务计算平台的服务发现过程如下：

在心跳级联代理模式下的服务发现与常规模式类似,这里不做详述.

多级服务中心模式下的服务发现：

上文提到在多级服务注册中心模式下,可以获得更快的服务发现.从心跳客户端的角度来看,其实没有差别,但是如果是查询同级的服务接口,在1级中心立刻查到,无须去2级中心；对于查询跨级的服务接口,则需要从2级中心获取,并会在1级中心缓存,从而加快跨级查询.有一点注意,1级中心的缓存也是TTL的,并且生存周期要短于2级中心,这是性能和时效性的互相适应的结果.因为从1级查缓存虽然快,但是1级中心无法判断跨级服务的存活,所以长时间的缓存可能是错误的信息,缩短TTL时长是为了更快更新跨级服务的地址信息.

服务接口失效的快速反馈：

当业务服务能力X调用Http服务能力A遇到异常时,服务能力实现框架会自动捕获异常信息,并将系统性异常(Timeout,SocketException等等)以及某些业务异常(基于策略)提交到服务注册中心,这个过程不必等到心跳周期到达而是立即触发的,从而服务注册中心可以实现对这些服务接口的快速隔离.而其他打算调用该服务接口的其他服务能力,通过心跳下行获得地址列表更新.这样的方式可以弥补TTL机制可能的延迟.

（编辑：ASP站长网）