这篇文章主要介绍“eureka服务治理的概念和用法是什么”，在日常操作中，相信很多人在eureka服务治理的概念和用法是什么问题上存在疑惑，小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”eureka服务治理的概念和用法是什么”的疑惑有所帮助！接下来，请跟着小编一起来学习吧！
[TOC]
分布式是现在互联网架构的首选。在分布式中我们会有三方理论简称CAP
| 简称 | 全称 | 解释 |
|---|
| C | Consistency | 数据一致性 |
| A | Availability | 可用性，性能 |
| P | Partition tolerance | 分区容错性 |
今天我们就来看看分布式中关于服务治理这块的服务
什么是服务治理
在多个服务之间相互调用的时候比较零散，管理起来比较麻烦。当被调用者有所改动可能都会牵扯到调用者的修改。所以服务治理应运而生。
spring cloud的Eureka实现了服务注册、服务调用、负载均衡、容错。这也是服务治理模块通用功能。
服务注册和服务调用在eureka看来都是客户端。eureka服务是服务端。所以他是一种典型的CS架构。eureka客户端需要与eureka服务保持心跳机制。这样eureka服务才会认为客户端没有宕机。
Eureka调用过程
service provider启动时会将自己服务的信息封装后注册到eureka注册中心上。service consumer已provider注册名去注册中心寻找到真实地址并进行调用。
针对service provider的管理对于service consumer来说不需要知道service provider的具体信息。只需要知道service provider的注册名就行了。在我们集群化后也不用担心provider我们具体的调用地址。负载均衡也是eureka帮我分配了。我们客户端只负责接口的调用。
Eureka单机注册
Eureka 单机启动
点我下载源码
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>
eureka:
instance:
hostname: localhost
client:
register-with-eureka: false #表示该模块作为eureka服务，自己是不需要想自己注册的，注册了只是徒增烦恼
fetch-registry: false # 表示自己就是注册中心。自己是管理者不是被管理者。
service-url:
defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/
单机注册
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>
eureka:
client:
register-with-eureka: true
fetch-registry: true
service-url:
defaultZone: http://localhost:7001/eureka
集群注册
客户调用
还记得我们的feature/cloud-pre上order模块是如何调用payment的吗。是的我们通过resetTemplate进行http方式调用的。现在我们还是通过他进行调用只不过调用地址是payment注册在eureka上的服务名。
这里客户端如何注册和payment配置一样的。因为虽然是order调用payment，但是对于eureka来说payment和order都是客户端。所以配置都是一样的。
Eureka集群注册
eureka:
client:
register-with-eureka: true
fetch-registry: true
service-url:
defaultZone: http://localhost:7001/eureka,http://www.eureka2/eureka
eureka:
instance:
hostname: www.zxhtom1.com #eureka服务端的实例名字
client:
register-with-eureka: false #表识不向注册中心注册自己
fetch-registry: false #表示自己就是注册中心，职责是维护服务实例，并不需要去检索服务
service-url:
defaultZone: http://eureka7002.com:7002/eureka/
idea 如何同一个项目启动多次
Eureka自我保护
为什么要自我保护
上面我们发现有两个8002的payment。为什么会出现如此奇怪的问题呢。排查发现一开始我通过idea启动了8001，8002。然后我又通过引入外部配置文件的方式重新启动了8002。这个时候原来的8002实例其实已经挂了。这个时候eureka会认为出现50%的客户端没有准时发送心跳。50<85 这个时候eureka认为大批客户端可能因为网络波动导致没有及时回复。eureka会开启自我保护机制。
虽然上面是个反面列子。也恰恰说明了为什么需要自我保护。加入这个时候8002在其他机器上因为网络延迟被踢出就会出现冤假错案。所以这也解释了为什么上述出现两个8002.
如何开启自我保护
自我保护如何激活
其实上面两个8002是一种意外。我们无意中触发了自我保护。
自我保护机制条件 ： 最近一分钟收到心跳数线程占总线程85%以下。
低于85%说明没有指定活跃数进行心跳回复，所以认为是网络波动了。
自我保护的临界值= renews(last min)/renews(threshold)
通过计算我们知道是75% 。 如果不算上正常的8002 。 那就是50% 。 所以不管怎么样都会触发自我保护的。
自我保护也满足的开篇提到的CAP原理中的A理论。eureka满足了高可用性原则。及时客户端真的宕机了也要留下。宁可多留也不错杀。这样就会导致数据不一致的情况。
到此，关于“eureka服务治理的概念和用法是什么”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注天达云网站，小编会继续努力为大家带来更多实用的文章！