service registrar是一个部署环境的内置组件，由Autoscaling Group创建的EC2实例可以被ELB自动注册。Kubernetes服务也可以自动注册。

　　third-party registration模式主要的优势在于解耦了服务和服务注册表。不需要为每个语言和框架都实现服务注册逻辑。服务实例注册由一个专用的服务集中实现。缺点是除了被内置到部署环境中，它本身也是一个高可用的系统组件，需要被启动和管理。

　　总结

　　在一个微服务应用中，服务实例在运行时的配置也会动态变化，包括他们的网络地址。为了满足客户端向服务发送请求的需要，必须要实现服务发现机制。

　　服务发现的关键部分是服务注册表。服务注册表是一个可用的服务实例的数据库。服务注册表提供了一个管理API和一个查询API。服务实例的注册和注销通过管理API实现，查询API用来寻找可用的服务实例。

　　有两种主要的服务发现模式：客户端服务发现和服务器端服务发现。客户端服务发现系统中，客户端查询服务注册表，选择一个可用的实例，响应一个请求;在服务器端服务发现系统中，客户端通过一个路由器发送请求，这个路由器会去查询服务注册表，并将请求发送给可用的实例。

　　有两种形式可以实现服务实例的注册和注销，一种是self-registration模式，一种是third-party registration模式。

　　一些部署环境中，需要通过类似Netflix Eureka，etcd或Apache Zookeeper的组件，启动自己的服务发现基础设施。其它的部署环境中，服务发现是内置的。比如，Kubernetes和Marathon处理服务实例的注册和注销，还会在每个集群host上运行一个代理，作为服务器端服务发现路由器的角色。

　　一个HTTP反向代理和Nginx也可以被用做服务器端服务发现负载均衡器。服务注册表可以推送路由信息到Nginx，引起配置更新，比如可以用Consul Template。Nginx Plus支持动态的重配置机制，可以从注册表中拉取服务实例相关的信息，还提供了远程配置的API。