# springcloud **Repository Path**: Eddyer/springcloud ## Basic Information - **Project Name**: springcloud - **Description**: 学习demo - **Primary Language**: Java - **License**: Not specified - **Default Branch**: master - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 1 - **Forks**: 1 - **Created**: 2020-07-14 - **Last Updated**: 2021-11-05 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README ## SpringCloud 回顾之前的知识 **串一下自己会的东西** * JavaSE, JAVA EE * 数据库(mysql,oracle,sql server,redis,memcache,mongodb) * 前端(html,css,js,node,vue,react,angular) * servlet * Http * Mybatis * Maven、Git * Ajax、json * Spring * SpringMVC * SpringBoot * Dubbo、Zookeeper、分布式基础 **这个阶段该如何学** ``` 三层架构 + MVC 框架： Spring IOC AOP SprignBoot 模块化~ all in one 模块化的开发 ==== all in one 代码没变化 微服务架构的4个核心问题? 1.服务很多，客户端该怎么访问？ 2.这么多服务？服务之间如何通信？ 3.这么多服务？如何治理？ 4.服务崩了怎么办？ 解决方案 Spring Cloud 生态 1.Spring Cloud NetFlix 一站式解决方案 2018年12月停止维护 API网关：zuul组件 Feign ----HttpClient http通信方式，同步、阻塞 服务注册发现： Eureka 熔断机制： Hystrix 2.Apache Dubbo zookeeper 半自动，需要整合别人的 API: 没有 找第三方组件或者自己实现 Dubbo Zookeeper 没有：借助 Hystrix 纯粹的RPC通信框架 3.Spring Cloud Alibaba 一站式解决方案 更简单 新概念： 服务网格~ server Mesh istio 万变不离其宗 1.API 2.HTTP,RPC 3.注册和发现 4.熔断机制 总之原因 网络不可靠！ ``` ## 1、常见面试题 1.1、 什么是微服务？ 1.2、 微服务之间是如何独立通讯的？ 1.3、 SpringCloud 和 Dubbo有哪些区别？ 1.4、SpringBoot和SpringCloud ，谈谈你对他们的理解 1.5、 什么是服务熔断？ 什么是服务降级 1.6、 微服务的优缺点分别是什么？说下你在项目开发中遇到的坑 1.7、 你所知道的微服务技术栈有哪些？ 1.8、 Eureka和zookeeper都可以提供服务注册与发现的功能，请说说两个的区别？ ## 2、微服务叙述 ### 2.1、微服务 ### 2.2、 微服务与微服务架构 ##### 微服务 强调的是服务的大小，它关注的是某一个点，是具体解决某一个问题/提供落地对应服务的一个服务应用，狭义的看,可以看做是IDEA中的一个个微服务工程，或者Moudel ``` IDEA工具里面使用Maven开发的一一个 个独立的小Moudle.它具体是使用springboot开发的一个小模块， 专业的事情交给专业的模块来做，一个模块就做着一件事情 强调的是一个个的个体，每个个体完成-一个具体的任务或者功能! ``` ##### 微服务架构 一种新的架构形式， Martin Fowler, 2014提出 微服务架构是-种架构模式，它提倡将单一应用程序划分成一组小的服务, 服务之间互相协调，互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相协作，每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境中，另外,应尽最避免统一的， 集中式的服务管理机制，对具体的一个服务而言,应根据业务上下文，选择合适的语言，工具对其进行构建。 ### 2.3、微服务优缺点 ##### 优点 * 单一职责原则 * 每个服务足够内聚足够小,代码容易理解，这样能聚焦一个指定的业务 功能或业务需求; * 开发简单，开发效率提高，一个服务可能就是专一的只干一件事; * 微服务能够被小团队单独开发，这个小团队是2~5人的开发人员组成; * 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。 * 微服务能使用不同的语言开发。 * 易于和第三方集成，微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如jenkins, Hudson,bamboo * 微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。 * 微服务允许你利用融合最新技术。 * **微服务只是业务逻辑的代码，不会和HTML， CSS或其他界面混合** * **每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库** ##### 缺点: * 开发人员要处理分布式系统的复杂性 * 多服务运维难度，随着服务的增加，运维的压力也在增大 * 系统部署依赖 * 服务间通信成本 * 数据一致性 * 系统集成测试 * 性能监控 ### 2.4、微服务技术栈有哪些？ | 微服务条目 | 落地技术 | | ---------------------------------------- | ---------------------------------------------------------- | | 服务开发 | SpringBoot,Spring,SpringMVC | | 服务配置与管理 | Netflix公司的Archaius、阿里的Diamond等 | | 服务注册与发现 | Eureka、Consul、Zookeeper等 | | 服务调用 | Rest、RPC、gRPC | | 服务熔断器 | Hystrix、Envoy等 | | 负载均衡 | Ribbon、Nginx等 | | 服务接口调用（客户端调用服务的简化工具） | Feign等 | | 消息队列 | Kafks、RabbitMQ、ActiveMQ等 | | 服务配置中心管理 | SpringCloudConfig、Chef等 | | 服务路由（API网关） | Zuul等 | | 服务监控 | Zabbix、Nagios、Metrics、Specatator等 | | 全链路追踪 | Zipkin、Brave、Dapper等 | | 服务部署 | Docker、OpenStack、Kubernetes | | 数据流操作开发包 | SpringCloud Stream(封装与redis,rabbit,kafka等发送接收消息) | | 事件消息总线 | SpringCloud Bus | ### 2.5、为什么选择SpringCloud作为微服务架构 #### **1、选型依据** * 整体解决方案和框架成熟度 * 社区热度 * 可维护性 * 学习曲线 #### **2、当前各大IT公司用的微服务架构有哪些？** * 阿里：dubbo+HFS * 京东： JSF * 新浪： Motan * 当当网 DubboX #### **3、各微服务框架对比** | 功能点/服务框架 | Netflix/SpringCloud | Motan | gRPC | Thrift | Dubbo/Dubbox | | --------------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------- | -------- | ----------------------------------- | | 功能定位 | 完整的微服务框架 | RPC框架，但组合了ZK或Consul，实现集群环境的基本服务注册/发现 | RPC框架 | RPC框架 | 服务框架 | | 支持Rest | 是，Ribbon支持多种可插拔的序列化选择 | 否 | 否 | 否 | 否 | | 支持RPC | 否 | 是（hession2） | 是 | 是 | 是 | | 支持多语言 | 是（Rest形式） | 否 | 是 | 是 | 否 | | 负载均衡 | 是（服务端zuul+客户端Ribbon），zuul-服务，动态路由，云端负载均衡Eureka（针对中间层服务器） | 是（客户端） | 否 | 否 | 是（客户端） | | 配置服务 | Netflix Archaius,Spring Cloud Config Server集中配置 | 是（zk提供) | 否 | 否 | 否 | | 服务调用链监控 | 是（zuul）提供边缘服务，API网关 | 否 | 否 | 否 | 否 | | 高可用/容错 | 是（服务端Hystrix+客户端Ribbon) | 是（客户端） | 否 | 否 | 是（客户端） | | 典型应用案例 | Netflix | Sina | Google | Facebook | | | 社区活跃程度 | 高 | 一般 | 高 | 一般 | 2017年后重新开始维护，之前中断了5年 | | 学习难度 | 中段 | 低 | 高 | 高 | 低 | | 文档丰富程度 | 高 | 一般 | 一般 | 一般 | 高 | | 其他 | SpringCloudBus为我们的应用程序带来了更多管理端点 | 支持降级 | Netflix内部在开发集成gRPC | IDL定义 | 实践的公司比较多 | ## 3、SpringCloud入门叙述 ### 3.1、SpringCloud是什么 Spring官网：https://spring.io/ ![Spring Cloud diagram](https://spring.io/images/cloud-diagram-1a4cad7294b4452864b5ff57175dd983.svg) SpringCloud,基于SpringBoot提供了一套微服务解决方案,包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡,熔断器等组件，除了基于NetFlix的开源组件做高度抽象封装之外，还有一些选型中立的开源组件 SpringCloud利用SpringBoot的开发便利性，巧妙地简化了分布式系统基础设施的开发, SpringCloud为开发人员提供了快速构建分布式系统的一些工具，**包括配置管理，服务发现，断路器，路由, 微代理，事件总线，全局锁，决策竞选，分布式会话等等**,他们都可以用SpringBoot的开发风格做到一键启动和部署。 SpringBoot并没有重复造轮子，它只是将目前各家公司开发的比较成熟，经得起实际考验的服务框架组合起来,通过SpringBoot风格进行再封装，屏蔽掉了复杂的配置和实现原理，**最终给开发者留出了一套简单易懂，易部署和易维护的分布式系统开发工具包** SpringCloud是分布式微服务架构下的一站式解决方案，是各个微服务架构落地技术的集合体，俗称微服务全家桶。 ### 3.2、SpringCloud和SpringBoot关系 * SpringBoot专注于快速方便的开发单个个体微服务。 * SpringCloud是关注全局的微服务协调整理治理框架,它将SpringBoot开发的一 个个单体微服务整合并管理起来，为各个微服务之间提供：配置管理，服务发现，断路器，路由, 微代理，事件总线，全局锁，决策竞选，分布式会话等等集成服务。 * SpringBoot可以离开SpringCloud独立使用,开发项目，但是SpringCloud离不开SpringBoot,属于依赖关系 * **SpringBoot专注于快速、方便的开发单个个体微服务，SpringCloud关注全局服务治理框架** ### 3.3、Dubbo和SpringCloud技术选型 ##### 1、分布式+服务治理Dubbo 目前成熟的互联网架构：应用服务化拆分+消息中间件 ![image 20200712001239876](https://s1.ax1x.com/2020/07/14/UU5Yes.png) 2、Dubbo和SpringCloud对比 可以看下社区活跃度 https://github.com/dubbo https://github.com/spring-cloud **结果：** | | Dubbo | Spring | | ------------ | ------------- | ---------------------------- | | 服务注册中心 | zookeeper | Spring Cloud Netflix Eureka | | 服务调用方式 | RPC | REST API | | 服务监控 | Dubbo-monitor | SpringBoot Admin | | 断路器 | 不完善 | Spring Cloud Netflix Hystrix | | 服务网关 | 无 | Spring Cloud Netflix Zuul | | 分布式配置 | 无 | Spring Cloud Config | | 服务跟踪 | 无 | Spring Cloud Sleuth | | 消息总线 | 无 | Spring Cloud Bus | | 数据流 | 无 | Spring Cloud Stream | | 批量任务 | 无 | Spring Cloud Task | **最大区别: SpringCloud拋弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。** 严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能,但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活， 服务提供方和调用方的依赖只依靠一纸契约, 不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。 **品牌机与组装机的区别** 很明显，Spring Cloud的功能比DUBBO更加强大,涵盖面更广，而且作为Spring的拳头项目，它也能够与SpringFramework. Spring Boot. Spring Data、Spring Batch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。使用Dubbo构建 的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了。总是让人不怎么放心，但是如果你是一名高手 ,那这些都不是问题;而SpringCloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性,但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。 **社区支持与更新力度** 最为重要的是，DUBBO停止了5年左右的更新，虽然2017.7重启 了。对于技术发展的新需求，需要由开发者自行拓展升级(比如当当网弄出了DubboX)，这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的，中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案， 并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。 **总结：** 曾风靡国内的开源RPC服务框架Dubbo在重启维护后,令许多用户为之雀跃，但同时，也迎来了一些质疑的声音。互联网技术发展迅速，Dubbo 是否还能跟上时代? Dubbo 与Spring Cloud相比又有何优势和差异?是否会有相关举措保证Dubbo的后续更新频率? 人物: Dubbo重启维护开发的刘军，主要负责人之一 刘军，阿里巴巴中间件高级研发工程师，主导了Dubbo重启维护以后的几个发版计划，专注于高性能RPC框架和微服务相关领域。曾负责网易考拉RPC框架的研发及指导在内部使用，参与了服务治理平台、分布式跟踪系统、分布式一致性框架等从无到有的设计与开发过程。 **解决的问题领域不一样：Dubbo的定位是一款RPC框架，SpringCloud的目标时微服务架构下的一站式解决方案。** 参考书： * https://www.springcloud.cc/spring-cloud-netflix.html * 中文API文档： https://springcloud.cc/spring-cloud-dalston.html * SpringCloud中国社区 http://springcloud.cn/ * SpringCloud中文网 https://springcloud.cc ## 4、SpringCloud开始 ### 4.1、总体介绍 * 我们使用一个Dept部门模块做一个微服务通用案例Consumer消费者（client）通过REST调用Provider提供者（server)提供的服务。 * 回忆Spring，SpringMVC,MyBatis等以往学习的知识 * Maven的分包分模块架构复习 ``` 一个简单的Maven模块结构是这样的： --app-parent: 一个父项目（app-parent）聚合很多子项目（app-util,app-dao,app-web...) |--pom.xml | |--app-core | |--pom.xml | |--app-web | |--pom.xml ``` 一个父工程带着多个子Module子模块 MicroServiceCloud父工程（Project）下初次带着3个子模块（Module) * microservicecloud-api 【封装的整体entity/接口/公共配置等】 * microservicecloud-provider-dept-8001 【服务提供者】 * microservicecloud-consumer-dept-80 【服务消费者】 ### 4.2、SpringCloud版本选择 大版本说明 | Spring Boot | Spring Cloud | 关系 | | ----------- | ----------------------- | ---------------------------------------------- | | 1.2.x | Angel版本(天使) | 兼容Spring Boot 1.2.x | | 1.3.x | Brixton版本(布里克斯顿) | 兼容Spring Boot 1.3.x, 也兼容Spring Boot 1.4.x | | 1.4.x | Camden版本(卡姆登) | 兼容Spring Boot 1.4.x, 也兼容Spring Boot 1.5.x | | 1.5.x | Dalston版本(多尔斯顿) | 兼容Spring Boot 1.5.x, 不兼容Spring Boot 2.0.x | | 1.5.x | Edgware版本(埃奇韦尔) | 兼容Spring Boot 1.5.x, 不兼容Spring Boot 2.0.x | | 2.0.x | Finchley版本(芬奇利) | 兼容Spring Boot 2.0.x, 不兼容Spring Boot 1.5.x | | 2.1.x | Greenwich版本(格林威治) | | **实际开发版本关系** ### 4.3、创建父工程 * 新建父工程项目springcloud,切记packageing是pom模式 * 主要是定义POM文件，将后续各个子模块公用的jar包等统一提取出来 ```xml 4.0.0 org.example springcloud 1.0-SNAPSHOT pom UTF-8 1.8 1.8 4.12 1.2.17 1.16.18 org.springframework.cloud spring-cloud-dependencies Greenwich.SR1 pom import org.springframework.boot spring-boot-dependencies 2.1.4.RELEASE pom import mysql mysql-connector-java 5.1.47 com.alibaba druid 1.1.18 org.mybatis.spring.boot mybatis-spring-boot-starter 1.3.3 ch.qos.logback logback-core 1.2.3 junit junit ${junit.version} org.projectlombok lombok ${lombok.version} log4j log4j ${log4j.version} ``` ### 4.4、一个简单的Rest #### **创建子module ——springcloud-api** ```xml org.projectlombok lombok ``` 编写实体类 ```java @Data @NoArgsConstructor @Accessors(chain = true) //链式写法 public class Dept implements Serializable { private Long deptno; private String dname; //这个数据存在哪个数据库 微服务 一个服务对应一个数据库，同一个信息可能存在不同的数据库 private String db_source; public Dept(String dname) { this.dname = dname; } /* 链式写法 Dept dept = new Dept(); dept.setDeptNo(11).setDname('sss').setDbsource('db01') */ } ``` #### **创建子module ——springcloud-provider-dept-8001** ```.xml org.example springcloud-api 1.0-SNAPSHOT junit junit mysql mysql-connector-java com.alibaba druid ch.qos.logback logback-core org.mybatis.spring.boot mybatis-spring-boot-starter org.springframework.boot spring-boot-test org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-starter-jetty org.springframework.boot spring-boot-devtools ``` 配置application.yml ```xml server: port: 8001 #mybatis配置 mybatis: type-aliases-package: com.springcloud.pojo config-location: classpath:mybatis/mybatis-config.xml mapper-locations: classpath:mybatis/mapper/*.xml #spring配置 spring: application: name: springcloud-provider-dept datasource: type: com.alibaba.druid.pool.DruidDataSource driver-class-name: org.gjt.mm.mysql.Driver url: jdbc:mysql://localhost:3306/db01?useUnicode=true&characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=true&serverTimezone=GMT%2B8 username: root password: ldtianzhe ``` mybatis-config.xml配置 ```xml ``` 编写service层、dao层代码 #### **创建子module ——springcloud-consumer-dept-80** 通过RestTemplate调用8001的接口 首先配置Bean ```java @Configuration public class ConfigBean { @Bean public RestTemplate getRestTemplate(){ return new RestTemplate(); } } ``` 在controller层中注入调用 ```java @RestController public class DeptConsumerController { //消费者不应该有service层 //RestTemplate 供我们直接调用就可以了 注册到Spring中 //(url,实体：Map,Class responseType) @Autowired private RestTemplate restTemplate; public static final String REST_URL_PREFIX = "http://localhost:8001"; @RequestMapping("/consumer/dept/add") public Boolean add(Dept dept){ return restTemplate.postForObject(REST_URL_PREFIX+"/dept/add/",dept,Boolean.class); } @RequestMapping("/consumer/dept/get/{id}") public Dept get(@PathVariable("id") Long id){ return restTemplate.getForObject(REST_URL_PREFIX+"/dept/get/"+id,Dept.class); } @RequestMapping("/consumer/dept/list") public List list(){ return restTemplate.getForObject(REST_URL_PREFIX+"/dept/list/",List.class); } } ``` ## 5、Eureka服务注册与发现 ### 5.1、什么是Eureka * Eureka怎么读 ——由瑞卡 * Netflix在设计Eureka时，遵循的就是AP原则 * Eureka是Netflix的一个子模块，也是核心模块之一。Eureka是一 个基于REST的服务,用于定位服务,以实现云端中间层服务发现和故障转移，服务注册与发现对于微服务来说是非常重要的,有了服务发现与注册，只需要使用服务的标识符，就可以访问到服务，而不需要修改服务调用的配置文件了，功能类似于Dubbo的注册中心，比如Zookeeper; ### 5.2、原理讲解 * Eureka的基本架构 * SpringCloud封装了NetFlix公司开发的Eureka模块来实现服务注册和发现(对比Zookeeper) * Eureka采用了C-S的架构设计，EurekaServer 作为服务注册功能的服务器，他是服务注册中心 * 而系统中的其他微服务。使用Eureka的客户端连接到EurekaServer并维持心跳连接。 这样系统的维护人员就可以通过EurekaServer来监控系统中各个微服务是否正常运行，SpringCloud的一 些其他模块(比如Zuul)就可以通过EurekaServer来发现系统中的其他微服务，并执行相关的逻辑； * 和Dubbo架构对比 * ![在这里插入图片描述](https://img-blog.csdnimg.cn/20190703102014756.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3F3ZTg2MzE0,size_16,color_FFFFFF,t_70) * ![image 20200712155758032](https://s1.ax1x.com/2020/07/14/UU5RFx.png) * Eureka 包含两个组件: Eureka Server和Eureka Client。 * Eureka Server提供服务注册服务，各个节点启动后，会在EurekaServer中进行注册，这样Eureka Server中的服务注册表中将会存储所有可用服务节点的信息，服务节点的信息可以在界面中直观的看到 * Eureka Client是一个Java客户端，用于简化EurekaServer的交互， 客户端同时也具备一个内置的，使用轮询负载算法的负载均衡器。在应用启动后，将会向EurekaServer发送心跳(默认周期为30秒)。如果Eureka Server在多个心跳周期内没有接收到某个节点的心跳，EurekaServer将会 从服务注册表中把这个服务节点移除掉(默认周期为90秒) * 三大角色 * Eureka Server：提供服务的注册与发现。zookeeper * Service Provider：将自身服务注册到Eureka中，从而使消费方能够找到。 * Service Consumer：服务消费方从Eureka中获取注册服务列表，从而找到消费服务。 * 盘点目前工程状况 ### 5.3、构建Eureka **开启服务四步走** **1.引入依赖** **2.编写yml配置文件** **3.开启这个功能 @EnableXXXX** **4.配置类** #### **1、eureka-server** **1. 创建springcloud-eureka-7001项目** * **2. 引入依赖** ```xml org.springframework.cloud spring-cloud-starter-eureka-server 1.4.6.RELEASE org.springframework.boot spring-boot-devtools ``` * **3. 编写yml配置文件** ```yaml server: port: 7001 #Eureka配置 eureka: instance: hostname: localhost client: register-with-eureka: false #表示是否向Eureka注册中心注册自己 fetch-registry: false #fetch-registry如果是false，则表示自己为注册中心 service-url: defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ ``` * **4. 在程序启动类上开启功能** ```java @SpringBootApplication @EnableEurekaServer//EnableEurekaServer 服务端的启动类，可以接受别人注册进来 public class EurekaServer_7001 { public static void main(String[] args) { SpringApplication.run(EurekaServer_7001.class,args); } } ``` #### 2、Service Provider 在springcloud-provider-dept-8001中配置eureka将服务入驻到7001的eureka中 1.首先添加pom依赖，增加eureka的支持 ```xml org.springframework.cloud spring-cloud-starter-eureka 1.4.6.RELEASE ``` 2. 配置yml文件 ```yaml #Eureka的配置，服务注册到哪里 eureka: client: service-url: defaultZone: http://localhost:7001/eureka/ ``` 3. 主启动类开启EurekaClient ```java @SpringBootApplication @EnableEurekaClient //在服务启动后自动注册到eureka中 public class DeptProvider_8001 { public static void main(String[] args) { SpringApplication.run(DeptProvider_8001.class,args); } } ``` 4.启动7001，再启动8001,测试访问 ![image 20200712173902700](https://s1.ax1x.com/2020/07/14/UU5WY6.png) #### 3、actuator与注册微服务信息完善 **主机名称：服务名称修改** ![image 20200712174236397](https://s1.ax1x.com/2020/07/14/UU5cwR.png) * 在8001的yml中修改一下配置 ```yaml #Eureka的配置，服务注册到哪里 eureka: client: service-url: defaultZone: http://localhost:7001/eureka/ instance: instance-id: springcloud-provider-dept8001 #修改eureka上的默认描述信息 ``` **访问信息有ip信息提示** ![image 20200712174444753](https://s1.ax1x.com/2020/07/14/UU5gT1.png) * 在yaml中再添加一个配置 ```yaml #Eureka的配置，服务注册到哪里 eureka: client: service-url: defaultZone: http://localhost:7001/eureka/ instance: instance-id: springcloud-provider-dept8001 #修改eureka上的默认描述信息 prefer-ip-address: true #访问路径可以显示IP地址 ``` **info内容构建** * 修改8001的pom文件，新增依赖 ```xml org.springframework.boot spring-boot-starter-actuator ``` * ~~在总的父工程中修改pom.xml添加build信息~~【没必要做】 ```xml springcloud src/main/resource true org.apache.maven.plugins maven-resources-plugin $ ``` * 然后回到我们的8001的yml文件中修改增加信息 ```yaml #info配置 info: app.name: springcloud-ldtianzhe company.name: ldtianzhe.com ``` * 重启项目测试 ![image 20200712180009573](https://s1.ax1x.com/2020/07/14/UU5ffK.png) #### 4、Eureka的自我保护机制 之前出现的这些红色情况 ![image 20200712180057009](https://s1.ax1x.com/2020/07/14/UU54SO.png) **自我保护机制:好死不如赖活着** 一句话总结:某时刻某一个微服务不可以用了， eureka不会立刻清理，依旧会对该微服务的信息进行保存! * 默认情况下，如果EurekaServer在一定时间内没有接收到某个微服务实例的心跳，EurekaServer将会注销该实例(默认90秒)。但是当网络分区故障发生时,微服务与Eureka之间无法正常通行,以上行为可能变得非常危险了--因为微服务本身其实是健康的，**此时本不应该注销这个服务**。Eureka通过 **自我保护机制**来解决这个问题-当EurekaServer节点在短时间内丢失过多客户端时(可能发生了网络分区故障)， 那么这个节点就会进入自我保护模式。一旦进入该模式，EurekaServer就会保护服务注册表中的信息 ，不再删除服务注册表中的数据(也就是不会注销任何微服务)。当网络故障恢复后， 该EurekaServer节 点会自动退出自我保护模式 * 在自我保护模式中，EurekaServer会保护服务注册表中的信息，不再注销任何服务实例。当它收到的心跳数重新恢复到阈值以上时，该EurekaServer 节点就会自动退出自我保护模式。它的设计哲学就是宁可保留错误的服务注册信息，也不盲目注销任何可能健康的服务实例。一句话: 好死不如赖活着 * 综上，自我保护模式是一种应对网络异常的安全保护措施。它的架构哲学是宁可同时保留所有微服务(健康的微服务和不健康的微服务都会保留)，也不盲目注销任何健康的微服务。使用自我保护模式，可以让Eureka集群更加的健壮和稳定 * 在SpringCloud中， 可以使用eureka. server . enable-self-preservation = false 禁用自我保护模式【不推荐关闭自我保护机制】 #### 5、8001 服务发现Discovery * 对于注册进eureka里面的微服务，可以通过服务发现来获得该服务的信息。【对外暴露服务】 * 修改springcloud-provider-dept-8001 工程中的DeptController ```java //获取一些配置的信息， @Autowired private DiscoveryClient client; //注册进来的微服务 获取一些消息~ @GetMapping("/discovery") public Object discovery(){ //获取微服务列表的清单 List services = client.getServices(); System.out.println("discovery=>services："+services); //得到一个具体的微服务信息，通过具体的微服务id，application.name List instances = client.getInstances("springcloud-provider-dept"); for (ServiceInstance instance : instances) { System.out.println( instance.getHost()+"\t"+ instance.getPort()+"\t"+ instance.getUri()+"\t"+ instance.getServiceId()); } return this.client; } ``` * 启动类开启注解 @EnableDiscoveryClient ```java @SpringBootApplication @EnableEurekaClient //在服务启动后自动注册到eureka中 @EnableDiscoveryClient//服务发现 public class DeptProvider_8001 { public static void main(String[] args) { SpringApplication.run(DeptProvider_8001.class,args); } } ``` 重启项目测试 ![image 20200712205853395](https://s1.ax1x.com/2020/07/14/UU55lD.png) ### 5.4、集群配置 * 新建springcloud-eurekaserver-7002、springcloud-eurekaserver-7003 * pom文件和启动类与springcloud-eurekaserver-7001一致 * 修改3个eurekaserver的yml文件 7001 ```yaml server: port: 7001 #Eureka配置 eureka: instance: hostname: eureka7001.com client: register-with-eureka: false #表示是否向Eureka注册中心注册自己 fetch-registry: false #fetch-registry如果是false，则表示自己为注册中心 service-url: #单机defaultZone: http://${eureka.instance.hostname}:${server.port}/eureka/ #集群（关联） defaultZone: http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/ ``` 7002 ```yaml server: port: 7002 #Eureka配置 eureka: instance: hostname: eureka7002.com client: register-with-eureka: false #表示是否向Eureka注册中心注册自己 fetch-registry: false #fetch-registry如果是false，则表示自己为注册中心 service-url: defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7003.com:7003/eureka/ ``` 7003 ```yaml server: port: 7003 #Eureka配置 eureka: instance: hostname: localhost client: register-with-eureka: false #表示是否向Eureka注册中心注册自己 fetch-registry: false #fetch-registry如果是false，则表示自己为注册中心 service-url: defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/ ``` 启动项目测试 ![image 20200712214433095](https://s1.ax1x.com/2020/07/14/UU57md.png) ### 5.5、对比Zookeeper **回顾CAP原则** RDBMS (MySQL、Oracle、sql server)==>ACID NoSQL (redis、mongodb)===>CAP **ACID是什么？** * A（Atomicity）原子性 * C（Consistency）一致性 * I（Isolation) 隔离性 * D（Durability）持久性 **CAP是什么？** * C（Consistency）强一致性 * A（Availability）可用性 * P（Partition tolerance）分区容错性 CAP的三进二：CA、AP、CP **CAP理论的核心** * 一个分布式系统不可能同时很好的满足一致性, 可用性和分区容错性这三个需求 * 根据CAP原理，将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类: * CA：单点集群，满足一致性，可用性的系统，通常可扩展性较差 * CP：满足一致性，分区容错性的系统，通常性能不是特别高 * AP：满足可用性, 分区容错性的系统，通常可能对一致性要求低一些 **作为服务注册中心，Eureka比Zookeeper好在哪里?** 著名的CAP理论指出，一个分布式系统不可能同时满足C (一 致性)、A (可用性)、P (容错性)。 由于分区容错性P在分布式系统中是必须要保证的，因此我们只能在A和C之间进行权衡。 * Zookeeper保证的是CP; * Eureka保证的是AP; **Zookeeper保证的是CP** ​ 当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。 但是zk会出现这样一种情况， 当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长,30~120s，且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因为网络问题使得zk集群失去master节点是较大概率会发生的事件，虽然服务最终能够恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。 **Eureka保证的是AP** ​ Eureka看明白了这一点，因此在设计时就优先保证可用性。**Eureka各个节点都是平等的**，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时，如果发现连接失败，则会自动切换至其他节点，只要有一台Eureka还在， 就能保住注册服务的可用性，只不过查到的信息可能不是最新的，除此之外，Eureka还有一种自我保护机制， 如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况: 1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务 2. Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其他节点上(即保证当前节点依然可用) 3. 当网络稳定时，当前实例新的注册信息会被同步到其他节点中 ==因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪== ## 6、Ribbon ribbon怎么读？ **ribbon是什么？** * Spring Cloud Ribbon是基于Netflix Ribbon实现的一套==客户端负载均衡的工具==。 * 简单的说，Ribbon是Netflix发布的开源项目， 主要功能是提供客户端的软件负载均衡算法，将NetFlix的中间层服务连接在一起。Ribbon的客户端组件提供一系列完整的配置项如:连接超时、重试等等。简单的说，就是在配置文件中列出LoadBalancer (简称LB:负载均衡)后面所有的机器，Ribbon会 自动的帮助你基于某种规则(如简单轮询，随机连接等等)去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法! **ribbon能干嘛?** * LB,即负载均衡(Load Balance)， 在微服务或分布式集群中经常用的一种应用。 * **负载均衡简单的说就是将用户的请求平摊的分配到多个服务上,从而达到系统的HA (高可用)。** * 常见的负载均衡软件有Nginx, LVS等等 * dubbo、 SpringCloud中均给我们提供了负载均衡，**SpringCloud的负载均衡算法可以自定义** * 负载均衡简单分类: * 集中式LB * 即在服务的消费方和提供方之间使用独立的LB设施，如Nginx：反向代理服务器，由该设施负责把访问请求通过某种策略转发至服务的提供方! * 进程式LB . * 将LB逻辑集成到消费方,消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选出-一个合适的服务器。 * ==Ribbon就属于进程内LB==,它只是一个类库, 集成于消费方进程，消费方通过它来获取到服务提供方 ### 服务发现机制 在一个分布式的系统当中，有很多服务系统。在一个大的互联网公司，可能会有几十甚至上百个服务系统。 这些服务当中，会有生产者，也会有消费者。那么这些消费者该如何去发现这些生产者呢？ ​ 微服务架构下服务实例具有动态分配的网络地址，随着服务的自动扩展、故障和发布升级，导致服务实例的网络地址发生动态变更。因此，需要一种机制，支持服务消费者在服务提供者实例地址发生变更时，能够及时感知获取最新的地址，即服务发现机制。 ​ 经过多年的业界实践，总结出三种服务发现模式。 * #### 集中式LB * ![在这里插入图片描述](https://img-blog.csdnimg.cn/20191224001821225.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDQ4OTg3,size_16,color_FFFFFF,t_70) * 传统基于LB的模式。 专门的LB，负载均衡器，使用硬件的F5负载均衡器、软件的Nginx负载均衡器。 服务器上线后，向运维申请一个域名，运维会配这个负载均衡器，域名会指向这个后台的服务。 LB上有所有的服务地址，消费者要去访问这个服务时，会通过DNS做域名解析，域名解析会解析到LB上，LB会根据域名负载均衡到后台的服务。 缺点：LB挂了的话，那整个服务系统就无法访问了。 消费者申请调用服务器要穿透LB，会有性能损失。 * #### 进程内LB * ![在这里插入图片描述](https://img-blog.csdnimg.cn/20191224002131633.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDQ4OTg3,size_16,color_FFFFFF,t_70) * 把LB这个功能移到了应用的进程内。 服务提供者会自动地以注册的方式注册到服务注册表上面，并且定期地发送心跳，告诉服务注册表我还活着。 消费者用了一个客户端，客户端带有服务发现和负载均衡的功能，他会通过LB来调用后台的服务，LB会定期地同步服务注册表的服务信息。 缺点：但是在多语言环境中，你必须为不同语言的消费者去开发不同的客户端，升级成本、多语言支持成本就比较高。 * #### 主机独立进程LB * ![在这里插入图片描述](https://img-blog.csdnimg.cn/20191224002315451.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzM2NDQ4OTg3,size_16,color_FFFFFF,t_70) * 也不是在客户端进程内的LB，而是在每个主机上部署一个LB。 消费者要调用后台的服务，首先是调用本机的LB进程，这个进程会帮他做负载均衡和远程调用。 优点：支持多语言，多语言可以灵活接入，不需要为每种语言去开发客户端。 缺点：运维成本会比较高，在每台主机都部署了LB进程。 ## 7、Feign负载均衡 ### 7.1、简介 feign是声明式的web service客户端,它让微服务之间的调用变得更简单了，类似controller调用service。SpringCloud集成了Ribbon和Eureka,可在使用Feign时提供负载均衡的http客户端。 只需要创建一个接口,然后添加注解即可! feign，主要是社区，大家都习惯面向接口编程。这个是很多开发人员的规范。调用微服务访问两种方法 1. 微服务名字【ribbon】 2. 接口和注解【feign 】 **Feign能干什么?** * Feign旨在使编写Java Http客户端变得更容易 * 前面在使用Ribbon + RestTemplate时， 利用RestTemplate对Http请求的封装处理， 形成了一套模板化的调用方法。但是在实际开发中，由于对服务依赖的调用可能不止一处，往往一个接口会被多处调用， 所以通常都会针对每个微服务自行封装一些客户端类来包装这些依赖服务的调用。所以，Feign在此基础上做了进一步封装，由他来帮助我们定义和实现依赖服务接口的定义，==在Feign的实现下，我们只需要创建一个接口并使用注解的方式来配置它(类似于以前Dao接口上标注Mapper注解，现在是一-个微服务接口上面标注- -个Feign注解即可。)==即可完成对服务提供方的接口绑定，简化了使用Spring Cloud Ribbon时，自动封装服务调用客户端的开发量。 **Feign集成了Ribbon** * 利用Ribbon维护了springcloud-dept的服务列表信息，并且通过轮询实现了客户端的负载均衡，而与Ribbon不同的是，通过Feign只需要定义服务绑定接口且以声明式的方法，优雅而且简单的实现了服务调用。 ### 7.2、Feign使用步骤 创建一个新的项目与Ribbon对比开来 ![image 20200713135517247](https://s1.ax1x.com/2020/07/14/UU5I6e.png) 引入依赖 ```xml org.springframework.cloud spring-cloud-starter-feign 1.4.6.RELEASE org.springframework.cloud spring-cloud-starter-eureka 1.4.6.RELEASE org.example springcloud-api 1.0-SNAPSHOT org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-devtools ``` 配置yml文件 ```yaml server: port: 80 #eureka配置 eureka: client: register-with-eureka: false #不向eureka注册自己 service-url: defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/ ``` 创建contrller层 ```java @RestController public class DeptConsumerController { @Autowired private DeptClientService deptClientService; @RequestMapping("/consumer/dept/add") public Boolean add(Dept dept){ return this.deptClientService.addDept(dept); } @RequestMapping("/consumer/dept/get/{id}") public Dept get(@PathVariable("id") Long id){ return this.deptClientService.queryById(id); } @RequestMapping("/consumer/dept/list") public List list(){ return this.deptClientService.queryAll(); } } ``` 编写启动类 ```java @SpringBootApplication @EnableEurekaClient @EnableFeignClients(basePackages = "com.springcloud") public class FeignDeptConsumer_80 { public static void main(String[] args) { SpringApplication.run(FeignDeptConsumer_80.class,args); } } ``` 启动测试 ![image 20200713140202750](https://s1.ax1x.com/2020/07/14/UU5oOH.png) ## 8、Hystrix **分布式系统面临的问题** 复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免的失败! **服务雪崩** 多个微服务之间调用的时候，假设微服务 A调用微服务 B和微服务 C, 微服务B和微服务 C又调用其他的微服务,这就是所谓的“扇出”、如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应"。 对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒中内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障，这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。 我们需要弃车保帅 ### **什么是Hystrix** ​ Hystrix是一个用于处理分布式系统的延迟和容错的开源库，在分布式系统里，许多依赖不可避免的会调用失败,比如超时，异常等，Hystrix能够保证在一 个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。 ​ “断路器”本身是一种开关装置， 当某个服务单元发生故障之后，通过断路器的故障监控(类似熔断保险丝)，**向调用方返回一个服务预期的，可处理的备选响应(FallBack) ，而不是长时间的等待或者抛出调用方法无法处理的异常，这样就可以保证了服务调用方的线程不会被长时间**，不必要的占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩 **能干嘛** * 服务降级 * 服务熔断 * 服务限流 * 接近实时的监控 * ...... **官网资料** https://github.com/Netflix/Hystrix/wiki ### 服务熔断 是什么 ​ 熔断机制是对应雪崩效应的一种微服务链路保护机制。 ​ 当扇出链路的某个微服务不可用或者响应时间太长时，会进行服务的降级，==进而熔断该节点微服务的调用，快速返回错误的响应信息==。当检测到该节点微服务调用响应正常后恢复调用链路。在SpringCloud框架里熔断机制通过Hystrix实现。Hystrix会监控微服务间调用的状况，当失败的调用到一定阈值，缺省是5秒内20次调用失败就会启动熔断机制。熔断机制的注解是@HystrixCommand。 **开始案例** * 创建项目springcloud-provider-dept-hystrix-8001 * 引入依赖 * ```xml org.springframework.cloud spring-cloud-starter-hystrix 1.4.6.RELEASE ``` * 修改Controller * ```java @RestController public class DeptController { @Autowired private DeptService deptService; @GetMapping("/dept/get/{id}") @HystrixCommand(fallbackMethod = "hystrixGet") public Dept queryById(@PathVariable("id") Long id){ Dept dept = deptService.queryById(id); if (dept==null){ throw new RuntimeException("id=>"+id+",不存在该用户，或者信息无法找到"); } return dept; } //备选方法 public Dept hystrixGet(@PathVariable("id") Long id){ return new Dept() .setDeptno(id) .setDname("id=>"+id+"没有对应的信息,null") .setDb_source("NO this database in MySQL"); } } ``` * 配置启动类注解 * ```java @SpringBootApplication @EnableEurekaClient //在服务启动后自动注册到eureka中 @EnableDiscoveryClient//服务发现 @EnableCircuitBreaker //添加对熔断的支持 public class DeptProviderHystrix_8001 { public static void main(String[] args) { SpringApplication.run(DeptProviderHystrix_8001.class,args); } } ``` * 启动项目测试 ### 服务降级 在springcloud-api项目中service层中编写DeptClientServiceFallbackFactory类 ```java @Component public class DeptClientServiceFallbackFactory implements FallbackFactory { @Override public DeptClientService create(Throwable throwable) { return new DeptClientService() { @Override public Boolean addDept(Dept dept) { return null; } @Override public Dept queryById(Long id) { return new Dept() .setDeptno(id) .setDname("id=>"+id+"没有对应的信息,客户端提供了降级的信息，这个服务现在已经被关闭") .setDb_source("NO this database in MySQL"); } @Override public List queryAll() { return null; } }; } } ``` 在DeptClientService接口的注解上绑定自己的服务降级类 ```java @FeignClient(value = "SPRINGCLOUD-PROVIDER-DEPT",fallbackFactory = DeptClientServiceFallbackFactory.class) ``` 修改springcloud-consumer-feign yml配置文件 ```yaml #开启服务降级 feign: hystrix: enabled: true ``` 启动项目测试 **对比** ```xml 服务熔断: 服务端~ 某个服务超时或者异常， 引起熔断， 相当于保险丝~ 服务降级: 客户端~ 从整体网站请求负裁考虑 ，当某个服务熔断或者关闭之后，服务将不再被调用 此时在客户端，我们可以准备一个FallbackFactory,返回一个默认的值(缺省值)， 整体的服务水平下降了~ 但是。好歹能用 比直接挂掉强 ``` ### Hystrix监控 #### 开启步骤 #### 1.创建项目 springcloud-consumer-hystrix-dashboard #### 2.引入依赖 ```xml org.springframework.cloud spring-cloud-starter-hystrix 1.4.6.RELEASE org.springframework.cloud spring-cloud-starter-hystrix-dashboard 1.4.6.RELEASE org.springframework.cloud spring-cloud-starter-ribbon 1.4.6.RELEASE org.springframework.cloud spring-cloud-starter-eureka 1.4.6.RELEASE org.example springcloud-api 1.0-SNAPSHOT org.springframework.boot spring-boot-starter-web org.springframework.boot spring-boot-devtools ``` #### 3.配置yml ```yaml server: port: 9001 ``` #### 4.创建启动类 **使用@EnableHystrixDashboard注解开启功能** ```java @SpringBootApplication @EnableHystrixDashboard public class DeptConsumerDashboard_9001 { public static void main(String[] args) { SpringApplication.run(DeptConsumerDashboard_9001.class,args); } } ``` #### 5.在8001项目下添加servlet ```java @SpringBootApplication @EnableEurekaClient //在服务启动后自动注册到eureka中 @EnableDiscoveryClient//服务发现 @EnableCircuitBreaker //添加对熔断的支持 public class DeptProviderHystrix_8001 { public static void main(String[] args) { SpringApplication.run(DeptProviderHystrix_8001.class,args); } //增加一个servlet @Bean public ServletRegistrationBean hystrixMetricsStreamServlet(){ ServletRegistrationBean registrationBean = new ServletRegistrationBean(new HystrixMetricsStreamServlet()); registrationBean.addUrlMappings("/actuator/hystrix.stream"); return registrationBean; } } ``` #### 6.启动测试 * 访问http://localhost:9001/hystrix * 输入http://localhost:8001/actuator/hystrix.stream * 时间设置200ms * 起一个名字 发起get请求看结果 ![image 20200713192530226](https://s1.ax1x.com/2020/07/14/UU5OtP.png) ### 如何看 * * 7色 * ![image 20200713192001820](https://s1.ax1x.com/2020/07/14/UU5Lkt.png) * 一圈 实心圆：共有两种含义。它通过颜色的变化代表了实例的健康程度 它的健康程度从 绿色<黄色<橙色<红色 递减 该实心圆除了颜色的变化之外，它的大小也会根据实例的请求流量发生变化，流量越大，该实心圆就越大，所以通过该实心圆的展示，就可以在大量的实例中快速发现**故障实例和高压力实例**。 ![image 20200713192530226](https://s1.ax1x.com/2020/07/14/UU5OtP.png) * 一线 曲线：用来记录2分钟内流量的相对变化，可以通过它来观察到流量的上升和下降趋势！ ![image 20200713192746411](https://s1.ax1x.com/2020/07/14/UU5bTI.png) * 整图说明 ![image 20200713192826814](https://s1.ax1x.com/2020/07/14/UU5Xff.png) * 搞懂一个才能看懂复杂的 ![image 20200713193020009](https://s1.ax1x.com/2020/07/14/UU5x1S.png) ## 9、Zuul路由网关 ### 概述 **什么是Zuul？** ​ Zuul包含了对请求的路由和过滤两个最主要的功能: ​ 其中路由功能负责将外部请求转发到具体的微服务实例上，是实现外部访问统一入口的基础， 而过滤器功能则负责对请求的处理过程进行干预，是实现请求校验，服务聚合等功能的基础。Zuu和Eureka进行整合,将Zuul自身注册为Eureka服务治理下的应用，同时从Eureka中获得 其他微服务的消息，也即以后的访问微服务都是通过Zuul跳转后获得。 ​ 注意: Zuul服务最终还是会注册进Eureka ​ 提供: 代理 + 路由 + 过滤 三大功能! **Zuul能干嘛?** * 路由 * 过滤 官网文档: https://github.com/Netflix/zuul **开始使用** **1.创建项目springcloud-zuul-9527** 2.配置yml配置文件 ```yaml server: port: 9527 spring: application: name: springcloud-zuul eureka: client: service-url: defaultZone: http://eureka7001.com:7001/eureka/,http://eureka7002.com:7002/eureka/,http://eureka7003.com:7003/eureka/ instance: instance-id: zuul9527.com prefer-ip-address: true #访问路径可以显示IP地址 #info配置 info: app.name: springcloud-ldtianzhe company.name: ldtianzhe.com ``` **3.编写启动类** 使用@EnableZuulProxy注解 ```java @SpringBootApplication @EnableZuulProxy public class ZuulApplication_9527 { public static void main(String[] args) { SpringApplication.run(ZuulApplication_9527.class,args); } } ``` **4.启动项目测试** 1. 访问 http://localhost:9527/springcloud-provider-dept/dept/get/1 2. 在yml中添加配置 ```yaml zuul: routes: mydept.serviceId: springcloud-provider-dept mydept.path: /mydept/** ignored-services: springcloud-provider-dept #忽略隐藏服务 不能再使用这个访问了 #prefix: #访问前缀 ``` 3. 访问 http://localhost:9527/mydept/dept/get/1 ## 10、SpringCloud config 分布式配置 ### 概述 **分布式系统面临的-配置文件的问题** ​ 微服务意味着要将单体应用中的业务拆分成一一个个 子服务,每个服务的粒度相对较小,因此系统中会出现大量的服务，由于每个服务都需要必要的配置信息才能运行，所以一套集中式的，动态的配置管理设施是必不可少的。SpringCloud提供了ConfigServer来解决这个问题，我们每一个微服务自 己带着一个application.yml, 那上百的的配置文件要修改起来，岂不是要发疯! **什么是SpringCloud config分布式配置中心** ![image 20200713213619770](https://s1.ax1x.com/2020/07/14/UU5z6g.png) ​ Spring Cloud Config为微服务架构中的微服务提供集中化的外部配置支持，配置服务器为**各个不同微服务应用**的所有环节提供了一个**中心化的外部配置**。 ​ Spring Cloud Config 分为**服务端**和**客户端**两部分; ​ 服务端也称为分布式配置中心，它是一一个独立的微服务应用，用来连接配置服务器并为客户端提供获取配置信息,加密，解密信息等访问接口。 ​ 客户端则是通过指定的配置中心来管理应用资源，以及与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。配置服务器默认采用git来存储配置信息，这样就有助于对环境配置进行版本管理。并且可以通过git客户端工具来方便的管理和访问配置内容。 **SpringCloud config分布式配置中心能干嘛** * 集中管理配置文件 * 不同环境，不同配置，动态化的配置更新,分环境部署，比如/dev /test/ /prod /beta /release * 运行期间动态调整配置，不再需要在每个服务部署的机器上编写配置文件，服务会向配置中心统一 拉取配置自己的信息。 * 当配置发生变动时，服务不需要重启，即可感知到配置的变化,并应用新的配置 * 将配置信息以REST接口的形式暴露 **SpringCloud config分布式配置中心与github整合** 由于Spring Cloud Config默认使用Git来存储配置文件(也有其他方式， 比如支持SVN和本地文件) , 但是最推荐的还是Git，而且使用的是http / https访问的形式; 配置资料 ​ https://www.springcloud.cc/spring-cloud-dalston.html#_quick_start ### Config服务端 * 编写yml配置文件，上传git * 创建项目springcloud-config-server-3344 * 引入依赖 ```xml org.springframework.cloud spring-cloud-config-server org.springframework.boot spring-boot-starter-actuator org.springframework.boot spring-boot-starter-web ``` * 编写yml配置 ```yam server: port: 3344 spring: application: name: springcloud-config-server cloud: config: server: git: uri: https://gitee.com/ldtianzhe/springcloud-config.git ``` * 编写启动类，开启注解 ```java @SpringBootApplication @EnableConfigServer public class Config_Server_3344 { public static void main(String[] args) { SpringApplication.run(Config_Server_3344.class,args); } } ``` * 启动项目测试 ![image-20200714155228243](C:\Users\ldtia\AppData\Roaming\Typora\typora-user-images\image-20200714155228243.png) http://localhost:3344/master/config-client-dev.yml ### Config客户端 * 创建项目springcloud-config-client-3355 * 引入依赖 ```xml org.springframework.cloud spring-cloud-starter-config org.springframework.boot spring-boot-starter-actuator org.springframework.boot spring-boot-starter-web ``` * 编写配置文件 * bootstrap.yml 系统级别的配置 ```yaml #系统级别的配置 spring: cloud: config: uri: http://localhost:3344 name: config-client #从git上读取的资源名称，不需要后缀 profile: dev label: master ``` * application.yml 用户级别的配置 ```yaml #用户级别的配置 spring: application: name: springcloud-config-client-3355 ``` * 编写启动类 * 编写Controller层 ```java @RestController public class ConfigController { @Value("${spring.application.name}") private String applicationName; @Value("${eureka.client.service-url.defaultZone}") private String eurekaServer; @Value("${server.port}") private String port; @RequestMapping("/config") public String getConfig(){ return "applicationName:"+applicationName+ "eurekaServer"+eurekaServer+ "port"+port; } } ``` * 启动测试 ![image 20200714155927826](https://s1.ax1x.com/2020/07/14/UUI9mj.png) 新建springcloud-config-eureka-7001和springcloud-provider-config-dept-8001看一下效果 大致步骤同上 * 引入依赖 * 编写bootstrap.yml和application.yml 测试服务注册成功! ![image 20200714170736181](https://s1.ax1x.com/2020/07/14/UUIP7n.png) 数据请求成功 ![image 20200714170813093](https://s1.ax1x.com/2020/07/14/UUIC0s.png)
spring-boot-starter-parent spring-cloud-dependencies
版本号 发布日期 版本号 发布日期
1.5.2.RELEASE 2017年3月 Dalston.RC1 2017年未知月
1.5.9.RELEASE Nov,2017 Edgware.RELEASE Nov,2017
1.5.16.RELEASE Sep,2018 Edgware.SR5 Oct,2018
1.5.20.RELEASE Apr,2019 Edgware.SR5 Oct,2018
2.0.2.RELEASE May,2018 Finchley.BUILD-SNAPSHOT 2018年未知月
2.0.6.RELEASE Oct,2018 Finchley.SR2 Oct,2018
2.1.4.RELEASE Apr,2019 Greenwich.SR1 Mar,2019