


综述:
在微服务时代,注册中心越来越被重视,服务治理逐渐跟业务服务并驾齐驱。注册中心在防控中心的预警系统中,被用于服务治理的服务注册、服务发现、服务探活等场景。
一、 关于注册中心

注册中心,起源于分布式时代,不管是水平拆分架构,或者垂直拆分架构,对于多服务、多实例的支持,都要对服务进行治理。注册中心是微服务架构中的纽带,类似于“通讯录”,它记录了服务和服务地址的映射关系。在分布式架构中,服务会注册到这里,当服务需要调用其它服务时,就到这里找到服务的地址并进行调用。注册中心本质上是为了解耦服务提供者和服务消费者。对任何一个微服务,原则上都应存在或者支持多个提供者,这是由微服务的分布式属性决定的,更进一步,为了支持弹性扩缩容特性,一个微服务的提供者的数量和分布往往是动态变化的,也是无法预先确定的。因此,原本在单体应用阶段常用的静态LB(负载均衡)机制就不再适用了,需要引入额外的组件来管理微服务提供者的注册与发现,而这个组件就是服务注册中心。
二、 注册中心的CAP理论

CAP含义:
C:Consistency 强一致性:注册一个服务,集群下多节点必须全部注册成功后才能进行访问和使用;master节点挂掉了需要等待重新选举成功后才能使用,选举期间服务不可用; (所有节点在同一时间具有相同的服务);
A:Availability 可用性:注册一个服务,只要有一个节点注册成功就可以对外提供访问;master节点挂了也可以正常使用; (保证每个请求不管成功或者失败都有响应);
P:Partition tolerance 分区容错性:把服务注册到每个节点,增强容错机制 (系统中任意信息的丢失或失败不会影响系统的继续运作);
CAP理论的核心是一个分布式系统不可能同时很好的满足一致性,可用性和分区容错性这三个需求;因此,根据 CAP 原理将 NoSQL(非关系型的)数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类:
-
CA 原则:单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大;
-
CP 原则:满足一致性,分区容忍性的系统,通常性能不是特别高;
-
AP 原则:满足可用性,分区容忍性的系统,通常可能对一致性要求低一些;
三、 注册中心解决的问题
1
屏蔽、解耦服务之间相互依赖的细节
服务之间的远程调用必须要知道对面IP、端口。但是该调用方式存在明显的问题,如被调用的IP、端口变化后,调用方也要同步修改。通过服务发现,将服务之间IP与端口的依赖转化为服务名的依赖,服务名可以根据具体微服务业务来做标识。
2
对服务进行动态管理
在微服务架构中,服务数量多且依赖错综复杂,无论是服务主动停止、意外挂掉,还是因为流量增加对服务扩容,这些服务状态上的动态变化,都需要尽快的通知到被调用方才采取相应的措施。所以,对于服务注册中心要实时管理服务的数据与状态,包括服务的注册上线、服务主动下线、异常服务的剔除。
3
降低服务端负载均衡中间件的压力
当服务越来越多时,服务URL配置管理变得非常困难,服务端的负载均衡中间件,比如F5(全球领先的应用交付网络)、Nginx( 高性能的HTTP和反向代理web服务器)压力也越来越大。通过服务注册中心,就可以实现动态地注册和发现服务,使服务的位置透明,并通过在消费方获取服务提供方地址列表,实现软负载均衡和失效转移,降低对服务端的负载均衡中间件,也能减少部分成本。
四、 常见的注册中心
1
Zookeeper
它是一个分布式服务框架,是Apache Hadoop 的一个子项目,它主要是用来解决分布式应用中经常遇到的一些数据管理问题,如统一命名服务、状态同步服务、集群管理、分布式应用配置项的管理等。简单来说zookeeper=文件系统+监听通知机制。
2
Eureka
Eureka是在Java语言上,基于Restful Api开发的服务注册与发现组件,整套搭建中的重要组件。
3
Consul
是由HashiCorp(一家云计算企业)基于Go语言开发的支持多数据中心分布式高可用的服务发布和注册服务软件, 采用Raft算法保证服务的一致性,且支持健康检查。
4
Nacos
是一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。简单来说 Nacos 就是注册中心 + 配置中心的组合,提供简单易用的特性集,帮助我们解决微服务开发必会涉及到的服务注册与发现、服务配置、服务管理等问题。Nacos 还是 Spring Cloud Alibaba 组件之一,负责服务注册与发现。
本文内容为原创,转载请注明出处!
