服务注册中心在整个微服务体系中,至关重要!如果服务注册中心挂了,整个系统都将崩溃。所以服务注册中心通常不会被部署为单点应用,而是采用集群的部署方式,其中个别节点挂掉不影响整个系统的运行。

下面,我们就来为大家介绍,如何基于CentOS7服务器构建eureka服务注册中心。
## 一、CentOS7(linux)环境准备
| 主机名称 | 主机ip |
| --- | --- |
| peer1 | 192.168.161.3 |
| peer2 | 192.168.161.4 |
| peer3 | 192.168.161.5 |
并且在安装eureka服务注册中心之间,需要将服务器时间同步,不能相差太多,否则eureka服务有可能启动失败。可以使用ntp进行时间同步。如:
~~~
ntpdate ntp.api.bz
~~~
## 二、profile配置文件修改

application-peer1.yml
* hostname为peer1
* defaultZone为peer2和peer3
* 下面配置我们之所以重写了health-check-url(健康检查路径),是因为设置了context-path。默认的健康检查路径是以“/”为项目的context-path。所以我们需要修改为server.servlet.context-path配置的值。
* 因为我们设置了 context-path,所以defaultZone访问端点有两个eureka,第一个eureka是我们配置的context-path。如果不设置 context-path,defaultZone:[http://peer2:8761/eureka/,http://peer3:8761/eureka/](http://peer2:8761/eureka/,http://peer3:8761/eureka/)
* 在eureka集群搭建过程中,fetch-registry和register-with-eureka一定设置为true。
网上有很多人写的垃圾东西,搭建过程遇到各种报错之后,就将fetch-registry和register-with-eureka的值改成false,来解决问题。这两个值之所以设置为true,目的是让eureka集群之间实现互相注册,互相心跳健康状态,从而达到集群的高可用。
把它们设置为false,是能解决你可能遇到的一些集群环境问题。这就好比你腿疼,你把腿砍了是不疼了,但你还能走路么。我们要的是让腿不疼,而不是把腿砍掉。“把腿砍了”这就不是“高可用”集群了,相当于你搭建了多个eureka server单点,这是“掩耳盗铃”的做法。
~~~
server:
port: 8761
servlet:
context-path: /eureka
spring:
application:
name: eureka-server
eureka:
instance:
hostname: peer1
health-check-url: http://${eureka.instance.hostname}:${server.port}/${server.servlet.context-path}/actuator/health
client:
#从其他两个实例同步服务注册信息
fetch-registry: true
#向其他的两个eureka注册当前eureka实例
register-with-eureka: true
service-url:
defaultZone: http://peer2:8761/eureka/eureka/,http://peer3:8761/eureka/eureka/
~~~
application-peer2.yml
* hostname为peer2
* defaultZone为peer1和peer3
~~~
server:
port: 8761
servlet:
context-path: /eureka
spring:
application:
name: eureka-server
eureka:
instance:
hostname: peer2
health-check-url: http://${eureka.instance.hostname}:${server.port}/${server.servlet.context-path}/actuator/health
client:
#从其他两个实例同步服务注册信息
fetch-registry: true
#向其他的两个eureka注册当前eureka实例
register-with-eureka: true
service-url:
defaultZone: http://peer1:8761/eureka/eureka/,http://peer3:8761/eureka/eureka/
~~~
application-peer3.yml
* hostname为peer3
* defaultZone为peer1和peer2
~~~
server:
port: 8761
servlet:
context-path: /eureka
spring:
application:
name: eureka-server
eureka:
instance:
hostname: peer3
health-check-url: http://${eureka.instance.hostname}:${server.port}/${server.servlet.context-path}/actuator/health
client:
#从其他两个实例同步服务注册信息
fetch-registry: true
#向其他的两个eureka注册当前eureka实例
register-with-eureka: true
service-url:
defaultZone: http://peer1:8761/eureka/eureka/,http://peer2:8761/eureka/eureka/
~~~
## 三、为eureka server加入actuator
spring-boot-starter-actuator是为Spring Boot服务提供相关监控信息的包。因为我们的eureka server要互相注册,并检查彼此的健康状态,所以这个包必须带上。
~~~
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
~~~
## 四、CentOS7环境下部署eureka集群
如果你的网络环境内没有DNS,需要配置/etc/hosts文件,将主机名称与ip地址关联。这一步必须要做,否则linux主机之间通过hostname访问eureka服务将无效,每台eureka server主机上都要执行。
~~~
192.168.161.3 peer1
192.168.161.4 peer2
192.168.161.5 peer3
~~~
开放防火墙端口(CentOS7),每台eureka server主机上都要执行。
~~~
firewall-cmd --zone=public --add-port=8761/tcp --permanent
firewall-cmd --reload
~~~
* 第一条命令式在防火墙开放8761端口
* 第二条命令是是开放端口重新加载,使生效
将zimug-server-eureka通过maven打包,然后上传CentOS主机,启动Eureka服务注册中心集群
~~~
# 在peer1主机执行
nohup java -jar -Dspring.profiles.active=peer1 zimug-server-eureka-1.0.jar &
# 在peer2主机执行
nohup java -jar -Dspring.profiles.active=peer2 zimug-server-eureka-1.0.jar &
# 在peer3主机执行
nohup java -jar -Dspring.profiles.active=peer3 zimug-server-eureka-1.0.jar &
~~~
## 四、访问测试
访问[http://192.168.161.3:8761/eureka/](http://192.168.161.3:8761/eureka/),即:访问peer1的eureka服务。可以见到DS Replicas中已经注册了peer3、peer2。

同理:
* 访问[http://192.168.161.4:8761/eureka/](http://192.168.161.3:8761/eureka/),即:访问peer2的eureka服务。可以见到DS Replicas中已经注册了peer1、peer3。
* 访问[http://192.168.161.5:8761/eureka/](http://192.168.161.3:8761/eureka/),即:访问peer3的eureka服务。可以见到DS Replicas中已经注册了peer1、peer2。
出现上面的这种eureka server之间互相注册的效果,表示我们的eureka服务注册中心集群模式搭建成功了!那么恭喜你,你是一个幸运儿。在实际的生产环境中,网络及主机环境往往更复杂,搭建过程的参数调整也更加复杂。
## 五、其他需要注意的点:
出现 unavailable-replicas 问题,首先要去检查一下你的health-check-url是否能正常响应。如果没有设置context-path,默认是:`http://ip:端口/actuator/health`。UP状态表示处于可用状态。

如果健康检查没有问题:
1.是否开启了register-with-eureka=true和fetch-registry=true
2.eureka.client.serviceUrl.defaultZone配置项的地址,不能使用localhost,要使用ip或域名。或者可以通过hosts或者DNS解析的主机名称hostname。
3.spring.application.name要一致,不配置也可以,配置了要一致
4.默认情况下,Eureka 使用 hostname(如:peer1、peer2、peer3) 进行服务注册,以及服务信息的显示(eureka web 页面),那如果我们希望使用 IP 地址的方式,该如何配置呢?答案就是`eureka.instance.prefer-ip-address=true`。当设置prefer-ip-address: true时 ,修改配置`defaultZone:http://你的IP:9001/eureka/`。如果此时你仍然使用`http://peer1:8761/eureka`会导致健康检查失败。
**如果你在本节课中,以上的问题你都检查过了,没有搭建成功也不要气馁,看看后面的章节能否解决你的问题!**
- 文档简介
- 模块与代码分支说明
- dongbb-cloud项目核心架构
- 微服务架构进化论
- SpringBoot与Cloud选型兼容
- Spring Cloud组件的选型
- 单体应用拆分微服务
- 单体应用与微服务对比
- 微服务设计拆分原则
- 新建父工程及子模块框架
- 通用微服务初始化模块构建
- 持久层模块单独拆分
- 拆分rbac权限管理微服务
- Hello-microservice
- 构建eureka服务注册中心
- 向服务注册中心注册服务
- 第一个微服务调用
- 远程服务调用
- HttpClient远程服务调用
- RestTemplate远程服务调用
- RestTemplate多实例负载均衡
- Ribbon调用流程源码解析
- Ribbon负载均衡策略源码解析
- Ribbon重试机制与饥饿加载
- Ribbon自定义负载均衡策略
- Feign与OpenFeign
- Feign设计原理源码解析
- Feign请求压缩与超时等配置
- 服务注册与发现
- 白话服务注册与发现
- DiscoveryClient服务发现
- Eureka集群环境构建(linux)
- Eureka集群多网卡环境ip设置
- Eureka集群服务注册与安全认证
- Eureka自我保护与健康检查
- 主流服务注册中心对比(含nacos)
- zookeeper概念及功能简介
- zookeeper-linux集群安装
- zookeeper服务注册与发现
- consul概念及功能介绍
- consul-linux集群安装
- consul服务注册与发现
- 通用-auatator导致401问题
- 分布式配置中心-apollo
- 服务配置中心概念及使用场景
- apollo概念功能简介
- apollo架构详解
- apollo分布式部署之Portal
- apollo分布式部署之环境区分
- apollo项目权限管理实战
- apollo-java客户端基础
- apollo与SpringCloud服务集成
- apollo实例配置热更新
- apollo命名空间与集群
- apollo灰度发布(日志热更新为例)
- SpringCloudConfig配置中心
- config-git配置文件仓库
- config配置中心搭建与测试
- config客户端基础
- config配置安全认证
- config客户端配置刷新
- config配置中心高可用
- BUS消息总线
- bus消息总线简介
- docker安装rabbitMQ
- 基于rabbitMQ的消息总线
- bus实现批量配置刷新
- alibaba-nacos
- nacos介绍与单机部署
- nacos集群部署方式(linux)
- nacos服务注册与发现
- nacos服务注册中心详解
- nacos客户端配置加载
- nacos客户端配置刷新
- nacos服务配置隔离与共享
- nacos配置Beta发布
- 服务熔断降级hystrix
- 服务降级&熔断&限流
- Hystrix集成并实现服务熔断
- Jemter模拟触发服务熔断
- Hystrix服务降级fallback
- Hystrix结合Feign服务降级
- 远程服务调用异常传递的问题
- Hystrix-Feign异常拦截与处理
- Hystrix-DashBoard单服务监控
- Hystrix-dashboard集群监控
- 分布式系统流量卫兵sentinel
- sentinel简介与安装
- 客户端集成与实时监控
- 实战流控规则-QPS限流
- 实战流控规则-线程数限流
- 实战流控规则-关联限流
- 实战流控规则-链路限流
- 实战流控效果-WarmUp
- 实战流控效果-匀速排队
- BlockException处理
- 实战熔断降级-RT
- 实战熔断降级-异常数与比例
- DegradeException处理
- 注解与异常的归纳总结
- Feign降级及异常传递拦截
- 动态规则nacos集中存储
- 热点参数限流
- 系统自适应限流
- 微服务网关-GateWay
- 还有必要学习Zuul么?
- 简介与非阻塞异步IO模型
- GateWay概念与流程
- 新建一个GateWay项目
- 通用Predicate的使用
- 自定义PredicateFactory
- 编码方式构建静态路由
- Filter过滤器介绍与使用
- 自定义过滤器Filter
- 网关请求转发负载均衡
- 结合nacos实现动态路由配置
- 整合Sentinel实现资源限流
- 跨域访问配置
- 网关层面全局异常处理
- 微服务网关安全认证-JWT篇
- Gateway-JWT认证鉴权流程
- 登录认证JWT令牌颁发
- 全局过滤器实现JWT鉴权
- 微服务自身内部的权限管理
