eureka

某厂面试归来，发现自己落伍了！>>> 互联网发展到现在，由于数据量大、操作并发高等问题，大部分网站项目都采用分布式的架构。 而分布式系统最大的特点数据分散，在不同网络节点在某些时刻（数据未同步完，数据丢失），数据会不一致。 在2000年，Eric Brewer教授在PODC的研讨会上提出了一个猜想：一致性、可用性和分区容错性三者无法在分布式系统中被同时满足，并且最多只能满足其中两个！ 在2002年，Lynch证明其猜想，上升为定理。被这就是大家所认知的CAP定理。 CAP是所有分布式数据库的设计标准。例如Zookeeper、Redis、HBase等的设计都是基于CAP理论的。 CAP定义 所谓的CAP就是分布式系统的三个特性： Consistency，一致性。所有分布式节点的数据是否一致。 Availability，可用性。在部分节点有问题的情况（数据不一致、节点故障）下，是否能继续响应服务（可用）。 Partition tolerance，分区容错性。允许在节点（分区）数据不一致的情况。 深入理解 有A、B、C三个分布式数据库。 当A、B、C的数据是完全相同，那么就符合定理中的Consistency（一致性）。 假如A的数据与B的数据不相同，但是整体的服务（包含A、B、C的整体）没有宕机，依然可以对外系统服务，那么就符合定理中的Availability（可用性）。

目录 1 eureka 2 hystrix 1 eureka eureka基本 eureka升级 2 hystrix 来源： https://www.cnblogs.com/my-ordinary/p/12501727.html

背景 　　服务进程监控一般都有相关组件处理了，早期业务出现特定服务使用的DB资源超过额配量，导致健康检测失败，服务陆续从Eureka下线了，业务监控在没路由到特定节点时候，或者路由到特定节点但没有碰到阈值场景不会触发告警，意味着业务短暂性正常，服务陆续下线；Eureka server 作为注册中心可以较早感知到服务注册状态，实例节点挂了(注册上的实例少了)、节点状态非UP 场景 监控方案 Eureka定时采集注册信息，实例节点数、实例节点状态信息 prometheus 定时采集Eureka server 采集到的数据 grafana 查询及对数据告警 Eureka注册信息数据采集 metric 数据结构定义 统计节点状态 type：Gauge eureka_instance_status{client="{client}",status="{status}"} client : eureka client application name status 枚举 状态 枚举值 UP 1 DOWN 5 STARTING 2 OUT_OF_SERVICE 3 UNKNOW 4 最近n时间内平均值大于1，表示异常，执行告警 统计节点数量 type：Gauge eureka_instance_count{client="{client}",count="{count}"} client :

最近在做eureka参数调优，发现了个eureka踢出异常下线实例的bug，测试的时候发现，当实例异常下线时，eureka踢出实例的时间基本都是 “超时踢出秒数的2倍 + 补偿时间（lease-expiration-duration-in-seconds: 8 #超时8秒剔除）”。 看了下源码发现是eureka存在的一个小bug，eureka的续约renew = System.currentTimeMillis() + duration（踢出时长）;续约的时候错误的多加了个duration，导致在计算超时的时候也多加了个duration，所以实际计算踢出时间等于加了两次的 duration，所以异常实例的剔除变成了 “超时踢出秒数的2倍 + 补偿时间”，看注释是作者认为修复的话影响较大，而且这个bug只影响异常下线的实例，不修复了。还是得注意下啊！ 来源： oschina 链接： https://my.oschina.net/icebergxty/blog/3193535

CAP理论 RuoYiplus 使用Eureka作为注册中心， 说到注册中心首先想到的应该是‘’分布式”，分布式系统有个著名的理论—CAP理论【Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）】 著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。Eureka保证的是AP，Zookeeper则保证的是CP。 一致性（C）：在分布式系统中的所有数据备份，在同一时刻是否同样的值。（等同于所有节点访问同一份最新的数据副本） 可用性（A）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。（对数据更新具备高可用性） 分区容忍性（P）：以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 （当分区数据不一致时，要保证系统的正常运行） Zookeeper(CP) zk使用的是ZAB协议（Zookeeper 原子广播协议），ZooKeeper它所做的就是确保对数据的修改都会被复制到集合体中超过半数的节点上。如果少于半数的机器出现故障，则最少有一台机器会保存最新的状态

上一篇我们已经学会了如何创建一个服务提供者，那么这一篇我们来创建一个服务消费者，实现思路是先通过Spring boot搭建一个微服务应用，再通过Eureka Client把它注册到注册中心Eureka Server，成为一个服务消费者。那么服务消费者如何调用服务提供者的接口呢，那么我们首先要来介绍一个组件RestTemplate的使用。 一、什么是RestTemplate RestTemplate 是 Spring 框架提供的基于 REST 的服务组件，底层是对 HTTP 请求及响应进⾏了封装， 提供了很多访问 RETS 服务的⽅法，可以简化代码开发。 二、如何使用RestTemplate 1.创建一个maven工程作为子服务 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> <version>2.0.2.RELEASE</version> </dependency> 2.创建application.yml，代码如下 server: port: 8080 spring: application: name: consumer eureka: client: service-url:

一、spring cloud简介 spring cloud 为开发人员提供了快速构建分布式系统的一些工具，包括配置管理、服务发现、断路器、路由、微代理、事件总线、全局锁、决策竞选、分布式会话等等。它运行环境简单，可以在开发人员的电脑上跑。另外说明spring cloud是基于springboot的，所以需要开发中对springboot有一定的了解，如果不了解的话可以看这篇文章：2小时学会springboot。另外对于“微服务架构” 不了解的话，可以通过搜索引擎搜索“微服务架构”了解下。 二、创建服务注册中心 在这里，我们需要用的的组件上Spring Cloud Netflix的Eureka ,eureka是一个服务注册和发现模块。 2.1 首先创建一个maven主工程。 **2.2 然后创建2个model工程:**一个model工程作为服务注册中心，即Eureka Server,另一个作为Eureka Client。 下面以创建server为例子，详细说明创建过程： 右键工程->创建model-> 选择spring initialir 如下图： 下一步->选择cloud discovery->eureka server ,然后一直下一步就行了。 创建完后的工程的pom.xml文件如下： <?xml version="1.0" encoding="UTF-8"?> <project

SpringCloud底层原理 1.eureka 1.1服务发现原理 Application Service ：是一个Eureka Client ，扮演服务提供者的角色，提供业务服务， 向Eureka Server 注册和更新自己的信息，同时能从Eureka Server 注册表中获取到 其他服务的信息。 Eureka Server ：扮演服务注册中心的角色，提供服务注册和发现的功能。每个 Eureka Cient 向Eureka Server 注册自己的信息，也可以通过Eureka Server 获取到其 他服务的信息达到发现和调用其他服务的目的。 Application Client ：是一个Eureka Client ，扮演了服务消费者的角色，通过Eureka Sever 获取注册到其上其他服务的信息，从而根据信息找到所需的服务发起远程调用。 Replicate: Eureka Server 之间注册表信息的同步复制，使Eureka Server 集群中不同 注册表中服务实例信息保持一致。 Make Remote Call ：服务之间的远程调用。 Register ：注册服务实例， Client 端向Server 端注册自身的元数据以供服务发现。 Renew ：续约，通过发送心跳到S巳rver 以维持和更新注册表中服务实例元数据的有 效性。当在一定时长内， Server

概述： 保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护，一旦进入保护模式，Eureka Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据，也就是不会注销任何微服务。 一句话： 某时刻某一个微服务不可用了，Eureka不会立刻清理，依旧会对该微服务的信息进行保存。 如果在Eureka Server的首页看到以下这段提示，则说明Eureka进入了保护模式。属于CAP里面的AP分支。 为什么会产生Eureka自我保护机制？ 为了防止EurekaClient可以正常运行，但是 与 EurekaServer网络不通情况下，EurekaServer不会立刻将EurekaClient服务剔除。 什么是自我保护模式？ 默认情况下，如果EurekaServer在一定时间内没有接受到某个微服务实例的心跳，EurekaServer将会注销该实例（默认90秒）。但是当网络分区故障发生（延迟、卡顿、拥挤）时，微服务与EurekaServer之间无法正常通信，以上行为可能变得非常危险了——因为微服务本身其实是健康的，此时不应该注销这个微服务。Eureka通过“自我保护模式”来解决这个问题——当EurekaServer节点在短时间内丢失过多客户端时（可能发生了网络分区故障），那么这个节点就会进入自我保护模式。 在自我保护模式中，Eureka

1.Ribbon负载均衡简介 1.1Ribbon概述 1.1.1.Ribbon是什么 SpringCloud Ribbon是基于Netflix Ribbon实现的一套 客户端负载均衡 的工具。 简单的说，Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如 连接超时 ， 重试 等。简单的说，就是在配置文件中列出 LoadBalanCer （简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随机连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。 1.1.2.Ribbon主要职责 LB（负载均衡） LB，即负载均衡（ Load Balanoe )，在微服务或分布式集群中经常用的一种应用。 负载均衡简单的说就是将用户的请求平摊的分配到多个服务上，从而达到系统的HA。 常见的负载均衡有软件nginx , LVS,硬件F5等。 相应的在中间件，例如：dubbo和 SpringCloud中均给我们提供了负载均衡，SpringCloud的负载均衡算法可以自定义。 LB又分为两种，集中式LB和进程内LB 集中式LB（偏硬件） 即在服务的消费方和提供方之间使用独立的LB设施（可以是硬件，如F5，也可以是软件，如nginx )