Context路径(服务接口相关)： 相对Http服务根的路径，比如/ma/put/mdf，/hm/cache/q，/rtntf/oper等等。
它们共同构成服务接口名，例如：
healthmanager-HealthMangerServerWorker-/hm/cache/q
runtimenotify-RuntimeNotifyServerWorker-/rtntf/oper
hbserveragent-HeartBeatServerListenWorker-/heartbeat
2 )服务发现
服务发现的本质是通过服务接口名查询服务注册中心，服务注册中心基于某些策略返回服务接口可用地址列表，服务调用方也可以基于某些策略来使用地址列表。
微服务计算平台的服务发现过程如下：
业务服务能力X以服务接口名为参数，调用组件API(每个服务能力组件都具备)。
组件API内部是调用心跳客户端向服务注册中心查询该服务接口。值得注意的是，除了第一次获取某服务接口信息外，出于性能考虑，这个过程是独立的，心跳客户端可以通过下行心跳不停更新已经用过的服务接口信息，通过TTL机制自动过期哪些长时间不使用的服务接口信息。
服务注册中心根据某种策略(授权访问策略，隔离策略等等)返回地址列表
业务服务能力X获取服务接口地址列表后，可按照某种轮询策略(Round Robin，权重等)使用。
在心跳级联代理模式下的服务发现与常规模式类似，这里不做详述。
多级服务中心模式下的服务发现：
上文提到在多级服务注册中心模式下，可以获得更快的服务发现。从心跳客户端的角度来看，其实没有差别，但是如果是查询同级的服务接口，在1级中心立刻查到，无须去2级中心;对于查询跨级的服务接口，则需要从2级中心获取，并会在1级中心缓存，从而加快跨级查询。有一点注意，1级中心的缓存也是TTL的，并且生存周期要短于2级中心，这是性能和时效性的互相适应的结果。因为从1级查缓存虽然快，但是1级中心无法判断跨级服务的存活，所以长时间的缓存可能是错误的信息，缩短TTL时长是为了更快更新跨级服务的地址信息。
服务接口失效的快速反馈：
当业务服务能力X调用Http服务能力A遇到异常时，服务能力实现框架会自动捕获异常信息，并将系统性异常(Timeout，SocketException等等)以及某些业务异常(基于策略)提交到服务注册中心， 这个过程不必等到心跳周期到达而是立即触发的，从而服务注册中心可以实现对这些服务接口的快速隔离。而其他打算调用该服务接口的其他服务能力，通过心跳下行获得地址列表更新。这样的方式可以弥补TTL机制可能的延迟。
另外说明一下为什么没有使用Zookeeper类似的长连接(尽管时效性更好)，主要有如下原因：
长连接对服务注册中心的压力大，长连接意味着要支持大量的连接，常规的PC服务器能够支持数千个长连接已经是极限了，在微服务架构下，如果实例个数在这个数量级尚可接受，但是如果是万级实例，对硬件的配置要求太高，而且系统层面大量的长连接也存在管理问题。
长连接难以实现跨大网段，跨机房，甚至跨IDC中心，甚至由于某些IP安全策略(隔离)会变得不可用。
长连接的超时机制难以把控，太短会造成“中断”假象，太长会造成”假存活”，而且受网络层影响很大。
长连接也无法支持级联来实现扩展服务规模的能力。