谈一谈我所理解的微服务中的注册中心 _微服务

微服务现在是一个很火的话题，好像不管项目的大小，适用范围都在往微服务上去靠。这也使得现在如果不会微服务出去都没法和别人聊了。
仅从我自己的工作经历来看，尽管我们的项目也是微服务化了的。但是说实话在业务开发过程中并没有体会到微服务的开发和单体项目开发中存在很大的区别(仅业务开发这一块来说) 。
微服务的学习单独的写几个demo并没有啥用，现在的框架封装程度都很高，就算是代码跑起来来依旧是云里雾里。微服务的学习更多的是搞清楚微服务中每一个组件到底是什么？为什么有这些组件？没有会怎么样？功能大概是怎么实现的？
搞清楚来这些基本上就可以说对微服务有个大体的掌握了。
为什么需要注册中心【谈一谈我所理解的微服务中的注册中心】在微服务中首先需要面对的问题就是不同的服务之间如何进行通信呢？在单体服务中如果不同的服务之间需要通信，一般就是服务将接口暴露，然后其他的服务通过http进行请求，那么很明显在微服务中也可以这样。
但这里存在的问题在于单体服务中我们需要请求的目标是我们在请求的url中直接写死的，因为服务不多可以这样。而微服务中需要考虑的是存在大量服务时手动维护服务列表是否合适？如果服务横向扩展时如何通知其他的服务？服务宕机后，如何及时下线等等问题。
注册中心的功能注册中心的存在是为了更好更方便的管理应用中的每一个服务，是各个分布式节点之间的纽带。注册中心主要提供以下核心功能：

服务注册与发现：动态的增减服务节点，服务节点增减后动态的通知服务消费者，而不需要由消费者来更新配置。
服务配置：动态修改服务配置，并将其推送到服务提供者和服务消费者而不需要重启服务。
健康检查和服务摘除：主动的检查服务健康情况，对于宕机的服务将其摘除服务列表。

注册中心的实现注册中心的主要功能就是保存服务的具体信息，然后由服务消费者读取这些信息。从整体的流程上来说大概就是这样：

文章插图

除了将服务注册到注册中心，实际还存在服务的反注册。
目前对注册中心的实现分为两种模式，分别为客户端(应用内注册)和服务端(应用外注册) 。
客户端注册中心目前客户端实现的注册中心比较有代表性的就是eureka，虽然eureka2.0版本在此前宣布闭源，但目前好像没有太大的影响。后续的话可以考虑阿里开源的nacos 。
eureka是一个基于JAVA语言实现的费用与服务发现与注册的组件，包含服务端和客户端两部分。
服务端主要用来存储服务信息，定时进行服务检查。而客户端用于完成向服务端注册服务信息以及从服务端拉取服务信息等。

文章插图

上图是eureka官给出的eureka的架构图。
从图中可以很明显的看到eureka的服务端也是作为一个服务部署，而客户端则是通过sdk的方式接入应用。客户端向服务端进行服务注册以及更新服务等，同时客户端从服务端获取服务信息，不同服务之间根据获得的服务信息进行远程调用。
为了满足服务的高可用，通过移动多个eureka server服务，不同eureka server相互注册实现服务的高可用。
服务端注册中心eureka是由注册中心提供服务端和客户端的SDK，业务端通过引入注册中心提供的SDK，来实现服务的注册和发现。而服务端的注册中心则是通过应用外的组件来实现服务注册功能的。目前用的比较多的服务端注册中心组件如zookeeper、consul等。这里以zookeeper为例。
Zookeeper 是 Apache Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，是目前Dubbo官方主推搭配的注册中心。

文章插图

上图是dubbo官网提供的zookeeper作为注册中心的基本原理。
以dubbo为根目录，创建一服务接口全限定名的目录，在其下创建存放服务提供者接口信息的providers目录、存放服务消费者接口信息的consumers目录、存放服务配置信息的configurators目录等。
服务提供者启动的时候在providers下创建一条服务信息，该信息可以被consumer获取。通过zk提供的watcher机制注册一个watcher在服务提供者的providers目录下，这样当服务出现扩容或者宕机的时候就可以立即被consumer消费。