微服务之服务注册中心

一、什么是微服务的服务注册中心？
　　注册中心是微服务最核心的基础服务之一，是隐藏在服务框架背后最基础的服务，记录各个服务的实例信息，决定业务服务是否正常调用，主要涉及到三大角色，服务提供者、服务消费者、注册中心。三者的架构关系如下图：

　　服务注册中心执行流程原理：

　　1、各微服务启动时，会将自己的实例信息注册到注册中心，注册中心会管理和保存这些数据。

　　2、服务消费者会从注册中心获取到服务提供者的实例信息，通过ip+port的方式远程调用服务提供者提供的功能接口。

　　3、注册中心与微服务之间通过心跳来检测服务是否运行正常，服务模块会定时的想注册中心发送心跳包，以向其注册中心证明自己运行正常，同时注册中心会对提供者服务进行健康检查，以决定是否下线服务。

　　4、微服务发生变动时，重新注册信息到注册中心。服务消费者无需改动就可以直接从注册中心获取最新服务。

二、注册中心的功能

　　1、服务注册表：记录各个微服务实例信息，例如微服务的名称、IP、端口等。服务注册表提供查询和管理API，查询API用于查询可用的微服务实例，管理API用于服务的注册与注销。

　　2、服务注册与发现：服务注册是指微服务在启动时，将自己的信息注册到注册中心的过程，而服务发现是指查询可用的微服务列表及网络地址的机制。

　　3、服务检查：注册中心使用一定的机制定时检测已注册的服务，如发现某实例长时间无法访问，就会从服务注册表移除该实例。

三、主流的服务注册中心组件

　　常见的服务注册中心组件有 Eureka、Consul、ZooKeeper和Nacos。这几种开源组件， 都是基于分布式理论 CAP 的 CP 、AP 来实现的。CAP理论是分布式架构实现中重要的理论，CAP理论是Brewer提出的，它描述了一个分布式系统的三个特性：一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。一个分布式系统最多满足其中的两种，无法同时满足三种。

 

　　分区容错性：指的分布式系统中的某个节点或者网络分区出现了故障的时候，整个系统仍然能对外提供满足一致性和可用性的服务。也就是说部分故障不影响整体使用。

　　可用性： 一直可以正常的做读写操作。简单而言就是客户端一直可以正常访问并得到系统的正常响应。用户角度来看就是不会出现系统操作失败或者访问超时等问题。

　　一致性：在分布式系统完成某写操作后任何读操作，都应该获取到该写操作写入的那个最新的值。相当于要求分布式系统中的各节点时时刻刻保持数据的一致性。　

　　CAP三者不可兼得，该如何取舍?

　　　　(1) CA: 优先保证一致性和可用性，放弃分区容错。 这也意味着放弃系统的扩展性，系统不再是分布式的，有违设计的初衷。

　　　　(2) CP: 优先保证一致性和分区容错性，放弃可用性。在数据一致性要求比较高的场合(譬如:zookeeper,Hbase) 是比较常见的做法，一旦发生网络故障或者消息丢失，就会牺牲用户体验，等恢复之后用户才逐渐能访问。

　　　　(3) AP: 优先保证可用性和分区容错性，放弃一致性。NoSQL中的Cassandra 就是这种架构。跟CP一样，放弃一致性不是说一致性就不保证了，而是逐渐的变得一致。