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

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

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

2)服务发现

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

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

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

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

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

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

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

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!