服务注册核心

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

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

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

因而， 一个服务注册核心， 应蕴含一个服务器的集群， 在这个集群中， 各个机器中的数据须要保持一致， 机器之间通过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 」第一工夫浏览。每天分享优质文章、大厂教训、大厂面经，助力面试，是每个程序员值得关注的平台。