但它也有如下问题：
需要编写专门的代码埋点，与服务注册中心客户端的紧耦合：如果使用Zookeeper，需要依赖它的jar包。
服务注册代码与服务接口代码上下文紧耦合：必须在特定位置去使用服务注册的代码，而且可能还会包含特定服务的信息，这些信息可能是人工编排进去的。
由于不同系统是由不同团队开发的，需要行政制度，“TopDown”规定服务注册的编程，一旦有“不按套路出牌”的情况就会出现各种运维问题。
基于前文的计算节点模型，我们的微服务注册过程如下：
以HTTP方式对外暴露功能的服务能力(如图Http服务能力A)基于计算节点提供的Http服务框架实现。统一技术栈的目的之一，也是为服务注册做准备。
在Http服务能力A装配时，基础服务能力“服务能力画像”会对其进行画像。画像的过程实际是对编程模型的解析过程。提取的信息包括IP，Context路径，服务接口的URL，服务接口对应的实现方法，方法输入参数的Pattern等等。这个过程就实现了服务的自动发现。
服务能力画像完成画像后会将画像数据转交给基础服务能力“心跳客户端”。
心跳客户端通过心跳上行将服务接口数据发送到服务注册中心。
我们的服务注册过程是以心跳系统为基础的，服务注册是心跳事务中的一种。实际上服务注册中心是基础服务能力“心跳服务端”的功能，而它的载体是另一个计算节点(如图服务计算节点B)，这也是 计算节点的对等性体现 ，因为任何一个具备心跳服务端能力的计算节点都可以作为服务注册中心。
服务注册：常规模式
服务注册：“心跳级联代理”模式
在大规模部署服务计算节点时，往往还会遇到跨大网段，跨机房，跨IDC中心，白名单IP策略等问题。所以心跳系统还支持“心跳级联代理”模式，其作用是允许建立多级的心跳群，每个群由若干“代理”心跳服务端组成，它们只负责转发心跳信息，所以服务注册信息也依靠这个过程进行转发到服务注册中心。
服务注册：多级服务注册中心模式
在某些特殊业务场景下，对服务注册信息更新延迟容忍度较低，这时，让心跳级联的计算节点也作为服务注册中心。如下图，节点B是1级服务注册中心(以下简称1级中心)，节点C是2级服务注册中心(以下简称2级中心)。1级中心会存储向自己提交的服务注册信息，也会把这些信息转发到上级服务注册中心。2级中心上可见所有下级中心的服务注册信息。这种模式可以获得更快的服务发现，因为同级的节点发现其他节点服务能力只需经过本级服务注册中心即可，下文会结合服务发现做详细解释。
服务注册中心依靠TTL的方式对服务接口注册信息进行生命周期管理。我们定义生命状态如下：
存活(Alive)：服务接口健康，可被查询
可疑死亡(Dying)：由于网络延迟等原因的假死状态，服务接口健康状态存疑，可被查询。有可能经过1~2个生命周期收到上行心跳，可恢复至Alive状态
死亡(Dead)：超过了较大的TTL，基本认为服务接口死亡，其接口信息被隔离不能查询
消失(Disappear)：超过了一个铁定死亡的TTL，认为服务接口可以抹去，最终会从服务中心消息掉，其接口信息被隔离不能查询
另一个关键点是 服务接口名 的定义，它应该是全局唯一的命名，因为在多个服务能力之间互相调用时是以服务接口名为目标的。在服务画像时，会自动生成服务接口名，它提取以下三类信息：
计算节点类型名(服务计算节点相关)： 计算节点的类型由业务语义决定，比如MonitoAgent，SMSGateway，HealthManager等等
Http服务组件类型名(服务能力相关)： 对外提供Http服务组件的简写类名，比如MDFListenServer，NodeOperHandleServer，DigitSignServer等等