数字化监控平台工作台的注册中心是什么

注册中心相当于目录服务，负责服务地址的注册与查找。

调用方和服务方只在启动时与注册中心交互，注册中心不转发请求，压力较小。

监控中心负责统计各服务调用次数，调用时间等。

监控统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示

服务方向注册中心注册服务，并汇报调用时间到监控中心，此时间不包含网络开销

调用方从注册中心获取服务方地址，负载均衡调用服务方，上报调用时间到监控中心

注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外

注册中心通过长连接探活服务方，服务提供者宕机，注册中心将推送事件通知消费者

注册中心和监控全部宕机，不影响已运行的服务调用，调用方已本地缓存服务方列表

注册中心和监控中心都是可选的，服务消费者可以直连服务提供者

按Alt + 回车键，将会生成eureka-server.zip，解压缩后得到一个maven 项目，将该项目录入IDE。

我们首先来看一下pom文件，可以看出项目中引用了spring-cloud-starter-netflix-eureka-server, 并且springboot 的版本号为：2.1.2.RELEASE, Spring Cloud的版本号为：Greenwich.RC2RC2 表示还没有正式发布，只是第二个Release Candidate。

接下来我们只需要两个步骤，

a、修改EurekaServerApplication, 在@SpringBootApplication的注解上面，加入一个新的注解：@EnableEurekaServer

b、在resources 目录中加入application.yml 文件， 并配置以下信息：

一个简单的Eureka 注册中心就已经可以使用了，我们运行一下这个spring boot 应用，找开浏览器：localhost:8761，即可看到我们的注册中心就已经运行启来了。并且EUREKA-SERVER也注册到自己的注册中心了。

单节点的注册中心已经搭建完毕，但单节点的注册中心存在单点故障的可能，不能用于生产环境。生产环境的Eureka一般采用集群方式进行部署。

通过client.serviceUrl.defaultZone配置多个peer节点，因为是在单机上测试，所以修改了host文件，并且使用不同的端口号来启动注册中心。正式的生产环境请根据自己的实际情况进行配置，比如：第一台Eureka的IP地址为：192.168.0.100，则defaultZone配置其他三台注册中心http://192.168.0.101:8761/eureka/,http://192.168.0.102:8761/eureka/,http://192.168.0.103:8761/eureka/

依次启动4台注册中心，打开网页:http://localhost:8764

可以看到其它三台注册中心已经出现在已注册的replicas和可用的replicas列表里边。

如上图所示，4台注册中心，每台注册中心需要配置其他三台服务器，以Eureka 1为例，其配置如下：

注册中心是本应该是无状态的，可以横向扩展。但由于每台注册中心的配置都不一样，所以扩展起来比较麻烦，需要修改配置文件，这样就无法做到快速的扩容。

微服务客户端需要配置注册中心的地址，使用的是如下的配置：

由于配置的是固定的IP地址，如果我们要扩容注册中心，增加新的注册中心节点，那我们就需要修改微服务客户端的配置文件，将新的注册中心节点进入的服务器列表中。试想一下，如果有几十个微服务，每个微服务有4个节点，那将会要修改上百个配置文件。很显然这种方式不太可取，从软件设计角度来说，违反了开闭原则。

其实Eureka 注册中心还有另一种高可用配置方式，基于DNS。Eureka天生就可以部署在像AWS这样的公有云上，并且可以跨Region，跨Available Zone部署。虽然我们不用部署在云端，依然可以利用这一特性，我们可以把Region看作我们数据中心的机房，Avaiable Zone 看作是机房中的网络区域，结合内部DNS服务来实现高可用的注册中心。

画重点：

a. region: default，配置地区

b. useDnsForFetchingServiceUrls，表示基于DNS获取服务信息

c. eurekaServerDNSName: eureka.txzq.com.cn，配置域名服务器名称

键：txt.default.eureka.txzq.com.cn 值：shenzhen.eureka.txzq.com.cn

键：txt.shenzhen.eureka.txzq.com.cn 值：172.18.10.1 172.18.10.2 172.18.10.3 172.18.10.4

第一条记录表示，default 区域，包含了哪些可用区，我们用shenzhen表示是深圳机房，txt记录的值就设置为：shenzhen.eureka.txzq.com.cn

第二第记录表示 , shenzhen机房有哪些服务器，多台服务器使用空格格开。

如果在本地测试，需要搭建一台自己的DNS服务器，可以参考我的另一篇文章： 基于Docker快速搭建DNS Server

Client View是指DNS服务应用到哪一个网段，比如：172.18.10.0/24网段的IP连接到BIND服务器，才会解析指定的域名。

在添加域名的时候，需要指定Client View，这里我们选择我们刚刚创建的View_172.18.10.0，指的是只有在这个网段的IP访问这台DNS服务器，才能解析。

添加完一级域名后我们刷一下这个ZONE，然后设置一下本地DNS服务器

DNS域名服务器验证通过后，我们接下来就可以在为这个域名添加我们所需要的txt 记录了。

到这里我们的准备工作就已经基本完成了。使用Maven将注册中心编译成，输出jar包。新建一个Eureka的docker镜像，并启动4个容器。基于DNS的注册中心就搭建完毕了。

你只需要对DNS记录进行变更，就可以实现动态的、快速扩容/缩容了。

关于如何将Eureka部署到Docker，请参考另一篇文章：

之前的文章中，详细的介绍了如何去搭建一个基于SOFABoot框架的项目，我们都知道，在用SpringBoot框架去开发一款分布式项目时，Spring Cloud为我们提供了一整套的针对多个服务之间的相互调用的解决方法，包括Eureka、Hystrix、Feign、Config等。在之前的文章中也介绍了，SOFABoot的主要功能中，除了介绍过的健康检查能力，类隔离和日志隔离之外，还有一个重要的，就是SOFAStack中一些SOFA中间件的集成管理。其实，SOFAStack同Spring Cloud一样，就是为了方便我们能更快的使用SOFABoot去搭建一款微服务项目。今天介绍一下SOFAStack中的注册中心SOFARegistry。

同Eureka一样，SOFARegistry 是蚂蚁金服开源的一个生产级、高时效、高可用的服务注册中心。SOFARegistry 最早源自于淘宝的 ConfigServer，十年来，随着蚂蚁金服的业务发展，注册中心架构已经演进至第五代。目前 SOFARegistry 不仅全面服务于蚂蚁金服的自有业务，还随着蚂蚁金融科技服务众多合作伙伴，同时也兼容开源生态。SOFARegistry 采用 AP 架构，支持秒级时效性推送，同时采用分层架构支持无限水平扩展。

服务注册中心分为四个角色，客户端（Client）、会话服务器（SessionServer）、数据服务器（DataServer）、元数据服务器（MetaServer），每个角色司职不同能力组合后共同提供对外服务能力。

Client

客户端：提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。

SessionServer：9603

会话服务器：提供客户端接入能力，接受客户端的服务发布及服务订阅请求，并作为一个中间层将发布数据转发 DataServer 存储。SessionServer 可无限扩展以支持海量客户端连接。

DataServer：9622

数据服务器：负责存储客户端发布数据，数据存储按照数据 ID 进行一致性 hash 分片存储，支持多副本备份，保证数据高可用。DataServer 可无限扩展以支持海量数据量。

MetaServer：9615

元数据服务器：负责维护集群 SessionSer

---