服务注册核心

在微服务的架构中，服务注册核心是一个外围的概念。就像上节所讲，服务注册核心是服务发现中不可短少的一部分。

服务注册核心，艰深来讲，是一个存储网络实例的网络地址和数据库，一个服务注册核心应该是高可用的，而且其数据是最新的。

客户端在查问服务注册核心后，会缓存一部分网络地址的数据，然而，这些信息须要设置过期工夫，因为数据会实时的发生变化。

因而，一个服务注册核心，应蕴含一个服务器的集群，在这个集群中，各个机器中的数据须要保持一致，机器之间通过 replication 协定来实现这个性能。

Netflix Eureka 是服务注册核心的一个很好的实例。它提供了一个用于注册和查问服务实例的 REST API。服务实例应用 POST 申请注册其网络地位。每 30 秒，它必须应用 PUT 申请刷新注册。通过应用 HTTP 删除申请或实例注册超时来删除注册。客户端能够应用 HTTP GET 申请检索已注册的服务实例。

Netflix 通过在多个 Amazon 服务器上运行多个 Eureka 来保障服务注册核心的高可用性，每个 Eureka 服务器运行在一个 EC2 实例上, 而且具备一个可变 IP 地址。DNS TEXT 用于存储 Eureka 集群配置，这个是个映射关系，用来失去可用的 Eureka 服务器的网络地位列表。

当 Eureka 服务器启动时，它查问 DNS 来检索 Eureka 集群配置，定位它的对应节点，并为本人调配一个未应用的 IP 地址。

Eureka 客户端通过查问 DNS 来发现 Eureka 服务器的网络地址，客户端更偏向于拜访雷同区域的 Eureka 服务器，当然，如果没有找到服务器，也会拜访其余区域的服务器。

其余的比拟好的服务注册核心是：

• etcd：一个高可用的，分布式的，一致性 key-value 构造，用于共享配置信息和服务发现，Kubernetes 应用了 etcd。
• consul：一个发现和配置服务的工具，提供 API 供注册和发现服务，为了确保可用性，consul 会执行健康检查。
• zookeeper：一个被宽泛应用的分布式的高性能服务。

上面探讨下服务注册核心的实现机制：

次要有两种模式：一种是 自注册模式 ；另一种是 第三方的注册模式。

自注册模式

自注册模式，就是每个服务实例都须要负责向服务注册核心来注册和解除注册，同时，还须要发送心跳来放弃注册信念不被过期。

Netflix OSS Eureka Client 应用了这种模式。

Eureka Client 负责注册和解除注册，在 Spring Cloud 工程中，向 Eureka 注册服务是很不便的，只须要加个注解即可 @EnableEurekaClient

自注册模式的益处是：简略，不须要其余的组件。

不过，毛病就是：耦合度比拟高，须要和服务注册核心适配，应用编程语言和框架会
受到限制。

第三方注册模式

应用第三方的注册模式，服务实例将不再负责间接向服务注册核心注册和解除注册，实际上，另外一个第三方的零碎组件来做这个注册的操作。

这个第三方组件通过轮询部署环境或者订阅一个事件来实现对运行实例集群的监控，当它发现有新的实例呈现的时候，它会注册到服务注册核心，同样，也会解除注册。

有一个开源软件叫 Registrator，就实现了这个注册组件的性能，它会主动注册和解除注册部署在 Docker 环境中的服务实例。反对 etcd 和 consul。

另外一个就是 NetflixOSS 的 Prana，反对非 JVM 语言，反对用于 Eureka。

应用第三方的模式，益处就是：很好的实现了和服务注册核心的解耦，不须要依照服务注册核心的要求来实现代码。

毛病就是：这个第三方的注册组件必须保障高可用，这样减少了治理的复杂度。

起源：https://www.imooc.com/article…

文章也会继续更新，能够微信搜寻「迈莫 coding」第一工夫浏览。每天分享优质文章、大厂教训、大厂面经，助力面试，是每个程序员值得关注的平台。