eureka服务发现

服务注册组件——Eureka高可用集群搭建 什么是Eureka？ 服务注册组件：将微服务注册到Eureka中。 为什么需要服务注册？ 微服务开发重点在一个"微"字，大型应用拆分成微型服务，意味着服务的数量不可能少。 服务之间存在调用关系，假设没有服务注册，微服务之间的调用关系就会是这个样子： 微服务的部署可能不会在同一台服务器上，而是需要通过远程调用，然后就涉及到IP地址了。理论上来说，直接通过IP地址直接通信也没有什么问题。 但是如果服务出问题，需要换一台服务器部署，ip地址就需要更改了。同时如果该服务被多个其他服务依赖，那么每一个IP地址都需要重置。 服务注册可以形象的理解为一张表，表的左边写着服务名称，而右侧对应的是IP地址。服务的调用使用名称来替代IP地址，那么当IP地址发生改变，直接修改服务注册中心的名称与IP的映射关系。其他服务由于是用名称来远程调用，所以并不需要更改。 Eureka与Zookeeper的区别 Eureka满足Ap原则，而Zookeeper满足CP原则。 （CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），三者最多同时满足俩） Eureka三个角色 Eureka Server 提供服务注册和发现 Service

一.微服务架构 SOA架构演变而来 解决了Webservice,ESB总线架构的性能差的问题 引入一个服务注册中心，（中心话服务注册中心） 不再使用xml传输数据，而是使用JSON来传输数据 将服务再进行一次精细化（细粒度服务组件），使用HTTP协议，使用RESTFul风格开发模式 ⼆.微服务如何拆分的问题 2.1 原则 如果某⼀个模块不能再细分，职责很单⼀，那么就可以成为微 每⼀个服务运⾏在⼀个独⽴进 每⼀个服务有⾃⼰的⼀个数据库存储，缓存系统，消息队列.. 2.2 微服务的原始⽂ https://www.cnblogs.com/liuning8023/p/4493156.html 三.SpringCloud微服务架构 3.1Spring Cloud概述 Spring Boot基础之上开发的⼀套微服务框架。微服务完整解决⽅案。 服务治理、注册与发现、配置管理、跟踪管理、断路器，路由、负载均衡，控制总线，微代理... https://spring.io/projects/spring-cloud https://springcloud.cc/ Spring Cloud⼏⼤组件（五⼤神兽） Spring Cloud Config：分布式配置中⼼ Spring Cloud netflix Eureka：服务的发现与注册 Hystrix：服务熔断，服务的保护 Ribbon：负载均衡

作为服务注册中心，Eureka比Zookeeper好在哪里 著名的CAP理论指出，一个分布式系统不可能同时满足C(一致性)、A(可用性)和P(分区容错性)。由于分区容错性在是分布式系统中必须要保证的，因此我们只能在A和C之间进行权衡。在此Zookeeper保证的是CP, 而Eureka则是AP。 1 Zookeeper保证CP 当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。 zookeeper原理 zookeeper也可以作为注册中心，用于服务治理（zookeeper还有其他用途，例如：分布式事务锁等） 每启动一个微服务，就会去zk中注册一个临时子节点， 例如：5台订单服务，4台商品服务 （5台订单服务在zk中的订单目录下创建的5个临时节点）

1. Eureka设计原理 1.1. 前言 目前我越来越关注技术原理层面的东西，开始考虑中间件设计背后，要考虑哪些因素，为什么要这样设计，有什么优化的地方，这次来讨论Eureka 1.2. 设计问题 设计一个注册中心，需要考虑什么东西？一步步来 首先注册中心的作用是用来存储各个服务器的地址端口等信息，所以需要考虑如何存储 存储就需要考虑是主动去拉还是各系统自己推送地址信息过来？拉取或推送的时间频率如何考虑？如何进行拉取推送，使用socket通信？ 如何保证注册服务的准确性，实时性，可靠性？ 当有几百上千个服务的时候，会对Eureka造成压力吗？如何克服这种压力？ 1.3. 注册步骤 Eureka Client A启动后主动注册到Eureka Server，Eureka Client B再一段时间后主动向服务端拉取注册表，发现客户端A注册上来了 当Eureka Client C启动再注册上Eureka Server，一定时间后客户端AB再去拉取注册表，就可以发现C注册上来了 客户端每隔一段时间（默认30秒）会去服务端拉取注册表信息，保证注册表是最新的 且客户端每隔一段时间（默认30秒）会发送一次心跳，来表示客户端存活 1.4. 如何抗住上千台机器压力 假设100个服务每个部署20台机器，那就是2000台 按每个客户端每隔30秒发送一个心跳+一次注册表拉取，每分钟就是4次

一、MicroService基本描述 　　微服务（MicroService）架构产生的原因： 解决单体应用框架的缺点。 　　单体应用（Monolith）框架： 所有的代码及功能都包含在一个WAR包中的项目组织方式被称为Monolith。 　　单体应用（Monolith）框架的缺点： 　　　编译难，部署难，测试难； 　　扩展难； 　　技术选择难； 　　微服务的含义： 　　微服务:对一个大服务的拆分; 每个服务运行在其独立的进程中;服务直接相互交互;独立地部署;各自服务的技术选择很自由。 　　微服务的优点： 编译容易，部署容易，测试容易； 　　扩展容易； 　　技术选择容易； 　　容错性高； 　　适用场景： 单体应用架构：中小型项目(功能相对较少) crm 物流 库存管理等 微服务架构：大型项目（功能比较多） 商城 erp等 二、MicroService实现技术-spring提供解决方案(springboot+springcloud) 　　MicroService只是一种架构思想，提出了微服务的设计原则； 实现： 　　 　　 单个服务：springboot　 　 　　　　Spring Boot是一套快速配置脚手架，可以基于Spring Boot快速开发单个微服务； 　　 多个服务（服务治理框架）： 　　　　 由于微服务架构中存在多个微服务，就需要服务治理框架

Spring Cloud 高可用注册中心 Eureka Server SpringBoot 版本2.1.4.RELEASE、Spring Cloud版本Greenwich.RELEASE Eureka系统架构图 register-with-eureka、fetch-registry参数对应图中的Registry、Get操作 Eureka Server和Eureka Client 1、 Eureka Server提供服务发现的能力，各个微服务启动时，会向Eureka Server注册自己的信息（例如IP、端口、微服务名称等），Eureka Server会存储这些信息； 2、Eureka Client是一个Java客户端，用于简化与Eureka Server的交互； 3、 微服务启动后，会周期性（默认30秒）地向Eureka Server发送心跳以续约自己的“租期”；eureka.instance.lease-renewal-interval-in-seconds=30 4、 如果Eureka Server在一定时间内没有接收到某个微服务实例的心跳，Eureka Server将会注销该实例（默认60秒）；eureka.server.eviction-interval-timer-in-ms=60000 5、默认情况下，Eureka Server同时也是Eureka Client

1.SpringCloud和Dubbo SpringCloud和Dubbo都是现在主流的微服务架构 SpringCloud是Apache旗下的Spring体系下的微服务解决方案 Dubbo是阿里系的分布式服务治理框架 从技术维度上,其实SpringCloud远远的超过Dubbo,Dubbo本身只是实现了服务治理,而SpringCloud现在以及有21个子项目以后还会更多 所以其实很多人都会说Dubbo和SpringCloud是不公平的 但是由于RPC以及注册中心元数据等原因,在技术选型的时候我们只能二者选其一,所以我们常常为用他俩来对比 服务的调用方式Dubbo使用的是RPC远程调用,而SpringCloud使用的是 Rest API,其实更符合微服务官方的定义 服务的注册中心来看,Dubbo使用了第三方的ZooKeeper作为其底层的注册中心,实现服务的注册和发现,SpringCloud使用Spring Cloud Netflix Eureka实现注册中心,当然SpringCloud也可以使用ZooKeeper实现,但一般我们不会这样做 服务网关,Dubbo并没有本身的实现,只能通过其他第三方技术的整合,而SpringCloud有Zuul路由网关,作为路由服务器,进行消费者的请求分发,SpringCloud还支持断路器,与git完美集成分布式配置文件支持版本控制

SpringCloud 关键名词 服务发现(service discovery) 服务ID SpringCloud经常用的5个组建： 服务发现——Netflix Eureka 传统DNS+负载均衡在微服务中不足 服务发现架构 基于云的微服务环境的服务发现其特征 部署高可用eureka server集群 实例1配置 实例2配置 client端配置 客服端负载均衡——Netflix Ribbon/Feign Ribbon + restTemplate 一般都是用 Feign client，比较方便。 断路器——Netflix Hystrix Feign中使用断路器 服务网关——Netflix Zuul 分布式配置——Spring Cloud Config 关键名词 服务发现(service discovery) 在许多分布式系统架构中，都需要去获取机器的物理地址（微服务实例部署的服务器地址及端口）。这一认知在分布式系统架构开始的时候就已经存在，而等到分布式计算出现的时候，被正式称为服务发现(service discovery)。 SpringCloud是微服务架构的集大成者，将一系列优秀的组件进行了整合。基于springboot构建。 SpringCloud的组件相当繁杂，拥有诸多子项目。重点关注Netflix。 服务ID 服务ID只是被服务发现代理用来给不同服务分组而已

1.SpringCloud和Dubbo SpringCloud和Dubbo都是现在主流的微服务架构 SpringCloud是Apache旗下的Spring体系下的微服务解决方案 Dubbo是阿里系的分布式服务治理框架 从技术维度上,其实SpringCloud远远的超过Dubbo,Dubbo本身只是实现了服务治理,而SpringCloud现在以及有21个子项目以后还会更多 所以其实很多人都会说Dubbo和SpringCloud是不公平的 但是由于RPC以及注册中心元数据等原因,在技术选型的时候我们只能二者选其一,所以我们常常为用他俩来对比 服务的调用方式Dubbo使用的是RPC远程调用,而SpringCloud使用的是 Rest API,其实更符合微服务官方的定义 服务的注册中心来看,Dubbo使用了第三方的ZooKeeper作为其底层的注册中心,实现服务的注册和发现,SpringCloud使用Spring Cloud Netflix Eureka实现注册中心,当然SpringCloud也可以使用ZooKeeper实现,但一般我们不会这样做 服务网关,Dubbo并没有本身的实现,只能通过其他第三方技术的整合,而SpringCloud有Zuul路由网关,作为路由服务器,进行消费者的请求分发,SpringCloud还支持断路器,与git完美集成分布式配置文件支持版本控制

Eureka涉及到的参数配置项数量众多，它的很多功能都是通过参数配置来实现的，了解这些参数的含义有助于我们更好的应用Eureka的各种功能，下面对Eureka的配置项做具体介绍，供大家参考。 Eureka客户端配置 1、RegistryFetchIntervalSeconds 从eureka服务器注册表中获取注册信息的时间间隔（s），默认为30秒 2、InstanceInfoReplicationIntervalSeconds 复制实例变化信息到eureka服务器所需要的时间间隔（s），默认为30秒 3、InitialInstanceInfoReplicationIntervalSeconds 最初复制实例信息到eureka服务器所需的时间（s），默认为40秒 4、EurekaServiceUrlPollIntervalSeconds 询问Eureka服务url信息变化的时间间隔（s），默认为300秒 5、ProxyHost 获取eureka服务的代理主机，默认为null 6、ProxyProxyPort 获取eureka服务的代理端口, 默认为null 7、ProxyUserName 获取eureka服务的代理用户名，默认为null 8、ProxyPassword 获取eureka服务的代理密码，默认为null 9、GZipContent eureka注册表的内容是否被压缩