eureka

1.Eureka Server即服务的注册中心，在刚才上一篇中，我们只有一个EurekaServer，事实上EurekaServer也可以是一个集群，形成高可用的Eureka中心。 　　目的： 多个Eureka Server之间也会互相注册为服务，当服务提供者注册到Eureka Server集群中的某个节点时，该节点会把服务的信息同步给集群中的每个节点，从而实现 数据同步 。因此，无论客户端访问到Eureka Server集群中的任意一个节点，都可以获取到完整的服务列表信息。 2.搭建2台Eeueka Server服务配置相反 实现你中有我，我中有你的注册 　　Erueka Server1 #配置自己的端口号 server: port: 10086 #配置注册中心让自己也能注册到自己 Client就不会因为注册不到自己而报错了 eureka: client: service-url: defaultZone: http://127.0.0.1:10087/eureka # 指定status是自己指定的ip地址 而不是自己的主机名 instance: prefer-ip-address: true ip-address: 127.0.0.1 #配置自己的服务名 spring: application: name: eureka-service 　　 Erueka Server1

Eureka的服务治理设计中，所有节点即是服务提供方，也是服务消费方。 Eureka Server的高可用：就是将自己作为服务向其他服务注册中心注册自己，形成一组互相注册的服务注册中心，实现服务清单的互相同步，达到高可用的效果。 Example：现有两个服务注册中心（RegisterCenterOne、RegisterCenterTwo） application-centerOne.properties内容如下： 　　spring.application.name=eureka-server 　　server.port=1111 　　eureka.instance.hostname=registercenterone 　　eureka.client.serviceUrl.defaultZone=http://registercentertwo:1112/eureka application-centerTwo.properties内容如下： 　　spring.application.name=eureka-server 　　server.port=1112 　　eureka.instance.hostname=registercentertwo 　　eureka.client.serviceUrl.defaultZone=http://registercenterone:1111

在微服务架构这样的分布式环境中，我们需要充分考虑发生故障的情况， 所以在生产 环境中必须对各个组件进行高可用部署， 对于微服务如此， 对于服务注册中心也一样。 但 是到本节为止，我们一直都在使用单节点的服务注册中心，这在生产环境中显然并不合适， 我们需要构建高可用的服务注册中心以增强系统的可用性。 Eureka Server的设计一开始就考虑了高可用问题， 在Eureka的服务治理设计中， 所有 节点即是服务提供方， 也是服务消费方， 服务注册中心也不例外。 是否还记得在单节点的 配置中，我们设置过下面这两个参数， 让服务注册中心不注册自己： eureka.client.register-with-eureka=false eureka.client.fetch-registry=false Eureka Server的高可用实际上就是将自己作为服务向其他服务注册中心注册自己，这 样就可以形成一组互相注册的服务注册中心， 以实现服务清单的互相同步， 达到高可用的 效果。 下面我们就来尝试搭建高可用服务注册中心的集群。 目录结构 在etc/hosts文件中添加对peerl和peer2的转换， 让上面配置的host形式的 serviceUrl能在本地正确访间到； Windows系统路径为C:\Windows\System32\ drivers\etc\hosts。 127.0.0.1

第四章：服务注册中心 Eureka 4-1. Eureka 注册中心高可用集群概述 在微服务架构的这种分布式系统中，我们要充分考虑各个微服务组件的高可用性 问题，不能有单点故障，由于注册中心 eureka 本身也是一个服务，如果它只有 一个节点，那么它有可能发生故障，这样我们就不能注册与查询服务了，所以我 们需要一个高可用的服务注册中心，这就需要通过注册中心集群来解决。 eureka 服务注册中心它本身也是一个服务，它也可以看做是一个提供者，又可 以看做是一个消费者，我们之前通过配置： eureka.client.register-with-eureka=false 让注册中心不注册自己，但是我们 可以向其他注册中心注册自己； Eureka Server 的高可用实际上就是将自己作为服务向其他服务注册中心注册 自己，这样就会形成一组互相注册的服务注册中心，进而实现服务清单的互相同 步，往注册中心 A 上注册的服务，可以被复制同步到注册中心 B 上，所以从任 何一台注册中心上都能查询到已经注册的服务，从而达到高可用的效果。 4-2. Eureka 注册中心高可用集群搭建 我们知道，Eureka 注册中心高可用集群就是各个注册中心相互注册，所以：(可以在新建一个项目作为注册中心，但是这里为了方便，采用多环境配置方法启动两个Eureka注册中心) 1.在 8761 的配置文件中，让它的

在微服务架构中，通常会存在多个服务调用的情况，如果基础服务出现故障可能会发生级联传递，导致整个服务链上的服务不可用。 microservice-eureka-server工程：服务注册中心，端口为8761 microservice-eureka-order工程：服务提供者，需要启动两个订单实例，其端口号分别是7900和7901 microservice-eureka-user-hystrix工程：服务消费者，使用Ribbon实现，端口号为8030。 microservice-eureka-server、microservice-eureka-order工程使用前几篇创建的。 microservice-eureka-user-hystrix工程搭建过程： <1>创建并在pom.xml中引入eureka和hystrix的依赖 <2>编辑配置文件 <3>在引导类Application中使用@EnableCircuitBreaker注解开启断路器功能 <4>修改用户的控制类 <5>分别启动注册中心、服务提供者和服务消费者 来源： CSDN 作者： liliblue 链接： https://blog.csdn.net/liliblue/article/details/103598397

前面学习了Eureka、Feign、Hystrix、Config，本篇来学习下API网关zuul。在微服务架构中，后端服务往往不直接开放给调用端，而是通过一个API网关根据请求的url，路由到相应的服务。当添加API网关后，在第三方调用端和服务提供方之间就创建了一面墙，这面墙直接与调用方通信进行权限控制，后将请求均衡分发给后台服务端。 为什么需要API Gateway 1、简化客户端调用复杂度 在微服务架构模式下后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway作为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。 2、数据裁剪以及聚合 通常而言不同的客户端对于显示时对于数据的需求是不一致的，比如手机端或者Web端又或者在低延迟的网络环境或者高延迟的网络环境。 因此为了优化客户端的使用体验，API Gateway可以对通用性的响应数据进行裁剪以适应不同客户端的使用需求。同时还可以将多个API调用逻辑进行聚合，从而减少客户端的请求数，优化客户端用户体验 3、多渠道支持 当然我们还可以针对不同的渠道和客户端提供不同的API Gateway,对于该模式的使用由另外一个大家熟知的方式叫Backend for front-end

搭建 Spring Cloud Consul Consul vs. Eureka Consul vs Eureka vs Zookeeper Why was Eureka 2.0 discontinued? #1129 关于Eureka 2.x，别再人云亦云了！ Eureka 2.0 is discontinued. What service discovery platform is Netflix using now? Consul 是一个分布式服务注册与发现，用于跨任何运行时平台和公共或私有云连接、保护和配置服务。它内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案。 它是 go 语言写。 Spring Cloud Consul 是 Spring Cloud 家族的一个项目，致力于提供简洁的整合 Consul。 搭建的时候出现问题，可以在下面留言。 1. 问题列表 IllegalStateException: No instances available 引入依赖 < dependency > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-actuator </ artifactId > </

eureka作为SpringCloud的服务发现与注册中心，在整个的微服务体系中，处于核心位置。单一的eureka服务，显然不能满足高可用的实际生产环境，这就要求我们配置一个能够应对各种突发情况，具有较强容灾能力的eureka集群服务。 其实我们创建不同的yaml文件，以不同yaml运行即可。在项目中，创建三个名字分别为eureka01，eureka02，eureka03的eureka，defaultZone中配置其他两个不同的eureka相互引用即可。 1.eureka01配置文件 server: port: 8083 eureka: instance: #eureka的名字 hostname: eureka01 #开启自我保护机制 当Eureka Server节点在短时间内丢失过多的客户端时（可能发送了网络故障）， #那么这个节点将进入自我保护模式，不再注销任何微服务，当网络故障回复后，该节点会自动退出自我保护模式 server: enable-self-preservation: true client: # 不在注册中心注册自己 register-with-eureka: false # 表示自己就是注册中心，不需要检索服务，只需要维护实例 fetch-registry: false serviceUrl: defaultZone: http://eureka02:8084

在演示spring cloud之前得要知道我们为什么需要微服务框架。 先讲讲我的经历，以前我们做项目时所有功能都写在一起，只是做了分层（模型，数据，业务），所有业务逻辑都写在业务层，刚开始还好，等时间长了，代码量大，各业务代码之间有交集维护起来超级麻烦，每次改动都担心会不会对其他模块造成影响，只改动一个模块也要停系统发一次包，我们以前包含了订单，支付，会员，预定，库存，物流等模块，时间越长心里越慌，出问题的频次也越高，就这样恶性循环。后来我们尝试着把会员剥离了出去，发现效果还不错，后来慢慢的都一个个剥离了出去，一个模块一个服务，各自维护，每次发包只要发对应的模块，不影响其他模块，大大的降低了出问题的频次，维护起来也比较轻松。其实我们老早就摸到了微服务的门槛，只是那时候没有理论和概念作为支撑，只知道这样可行。 我相信大家或多或少有和我类似的经历，上面已经说到了一个模块一个服务，模块服务化其实就是微服务所提倡的，微服务的主旨是将原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行。我之前只有不超过10个服务，而且是单服务应用，没有分布式，没有负载均衡，只是点对点通信。想想看如果是成千上百个服务，我们该怎么办，该如何管理这些服务？这个时候就该我们 spring cloud微服务框架出马了。spring cloud微服务框架的目的就是方便我们协调服务，管理服务

POM: <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version>1.5.2.RELEASE</version> </parent> <dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-dependencies</artifactId> <version>Camden.SR6</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter</artifactId> </dependency> <dependency> <groupId>org.springframework.boot