eureka

Spring Cloud 学习 (九) Spring Security, OAuth2

喜你入骨 提交于 2020-05-08 19:43:32
Spring Security Spring Security 是 Spring Resource 社区的一个安全组件。在安全方面,有两个主要的领域,一是“认证”,即你是谁;二是“授权”,即你拥有什么权限,Spring Security 的主要目标就是在这两个领域 Spring OAuth2 OAuth2 是一个标准的授权协议,允许不同的客户端通过认证和授权的形式来访问被其保护起来的资源 OAuth2 协议在 Spring Resource 中的实现为 Spring OAuth2,Spring OAuth2 分为:OAuth2 Provider 和 OAuth2 Client OAuth2 Provider OAuth2 Provider 负责公开被 OAuth2 保护起来的资源 OAuth2 Provider 需要配置代表用户的 OAuth2 客户端信息,被用户允许的客户端就可以访问被 0Auth2 保护的资源。OAuth2 Provider 通过管理和验证 OAuth2 令牌来控制客户端是否有权限访问被其保护的资源 另外,OAuth2 Provider 还必须为用户提供认证 API 接口。根据认证 API 接口,用户提供账号和密码等信息,来确认客户端是否可以被 OAuth2 Provider 授权。这样做的好处就是第三方客户端不需要获取用户的账号和密码

java Spring Cloud面试题附pdf答案(最全版本持续更新)

北战南征 提交于 2020-05-08 19:07:56
前言 涵盖各大公司会问到的面试点,同时随着版本的升级,可能也会有一些面试题更新,也会同步保持更新,因为篇幅原因(其实是我懒,哈哈)所以列了一部分答案,所有的答案见下文,总共485页合计20个技术点,文末自取pdf. 1、什么是 Spring Cloud? Spring cloud 流应用程序启动器是基于 Spring Boot 的 Spring 集成应用程序,提供与外部系统的集成。Spring cloud Task,一个生命周期短暂的微服务框架,用于快速构建执行有限数据处理的应用程序。 2、使用 Spring Cloud 有什么优势? 使用 Spring Boot 开发分布式微服务时,我们面临以下问题: 1、与分布式系统相关的复杂性-这种开销包括网络问题,延迟开销,带宽问题,安全问题。 2、服务发现-服务发现工具管理群集中的流程和服务如何查找和互相交谈。它涉及一个服务目录,在该目录中注册服务,然后能够查找并连接到该目录中的服务。 3、冗余-分布式系统中的冗余问题。 4、负载平衡 --负载平衡改善跨多个计算资源的工作负荷,诸如计算机,计算机集群,网络链路,中央处理单元,或磁盘驱动器的分布。 5、性能-问题 由于各种运营开销导致的性能问题。 6、部署复杂性-Devops 技能的要求。 3、服务注册和发现是什么意思?Spring Cloud 如何实现? 当我们开始一个项目时

SpringCloud学习笔记(4):Hystrix容错机制

南笙酒味 提交于 2020-05-08 10:01:41
简介 在微服务架构中,微服务之间的依赖关系错综复杂,难免的某些服务会出现故障,导致服务调用方出现远程调度的线程阻塞。在高负载的场景下,如果不做任何处理,可能会引起级联故障,导致服务调用方的资源耗尽甚至整个系统奔溃。Hystrix是一个由Netflix开源的一个延迟和容错库,它通过添加延迟容忍和容错逻辑来帮助控制这些微服务之间的交互。Hystrix通过隔离服务之间的访问点、停止跨服务的级联故障并提供回退选项来实现这一点,所有这些选项都提高了系统的总体弹性。 项目介绍 sc-parent,父模块(请参照 SpringCloud学习笔记(1):Eureka注册中心 ) sc-eureka,注册中心(请参照 SpringCloud学习笔记(1):Eureka注册中心 ) sc-provider,提供者(请参照 SpringCloud学习笔记(1):Eureka注册中心 ) sc-consumer-hystrix-ribbon,使用Hystrix+Ribbon的消费者 sc-consumer-hystrix-feign,使用Hystrix+Feign的消费者 在Ribbon上使用Hystrix 1.在父模块下创建子模块项目sc-consumer-hystrix-ribbon,pom.xml: <project xmlns="http://maven.apache.org/POM/4.0.0"

springcloud之hystrix熔断器-Finchley.SR2版

試著忘記壹切 提交于 2020-05-08 10:01:07
本篇和大家分享的是springcloud-hystrix熔断器,其主要功能是对某模块调用失败做断路和降级,简单点就当某个模块程序出问题了并达到某阈值就限制后面请求,并降级的方式提供一个默认返回数据。最近在琢磨hystrix源码,琢磨思路写一个自己的简易熔断器,希望大家后期关注。 springcloud版本说明 hystrix可用于工作中场景 springcloud-hystrix运用 feign客户端使用hystrix springcloud版本说明 由于市面上其版本比较多,版本不一可能造成了读者尝试时版本问题,所以这里指明当前作者写文章时使用的cloud版本 springboot版本: 1 <parent> 2 <groupId>org.springframework.boot</groupId> 3 <artifactId>spring-boot-starter-parent</artifactId> 4 <version> 2.0 . 7 .RELEASE</version> 5 <relativePath/> <!-- lookup parent from repository --> 6 </parent> springcloud版本: 1 <properties> 2 <java.version> 1.8 </java.version> 3 <spring-cloud

Spring Cloud-网关 Spring-Cloud-Gateway

匆匆过客 提交于 2020-05-07 11:45:43
简介 Spring Cloud Gateway 是 Spring Cloud 的一个全新项目,该项目是基于 Spring 5.0,Spring Boot 2.0 和 Project Reactor 等技术开发的网关,它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。 Spring Cloud Gateway 作为 Spring Cloud 生态系统中的网关,目标是替代 Netflix Zuul,其不仅提供统一的路由方式,并且基于 Filter 链的方式提供了网关基本的功能,例如:安全,监控/指标,和限流。 概念 Route(路由):Route 是网关的基础元素,由 ID、目标 URI、断言、过滤器组成。当请求到达网关时,由 Gateway Handler Mapping 通过断言进行路由匹配,当断言为真时,匹配到路由。 Predicate(断言):Predicate 是 Java 8 中提供的一个函数。允许开发人员匹配来自 HTTP 的请求,例如请求头或者请求参数。简单来说它就是匹配条件。 Filter(过滤器):Filter 是 Gateway 中的过滤器,可以在请求发出前后进行一些业务上的处理。 工作原理 当客户端请求到达 Spring Cloud Gateway 后,Gateway Handler Mapping 会将其拦截,根据 predicates

SpringCloud系列六:Feign接口转换调用服务(Feign 基本使用、Feign 相关配置)

筅森魡賤 提交于 2020-05-06 10:43:28
声明:本文来源于MLDN培训视频的课堂笔记,写在这里只是为了方便查阅。 1、概念:Feign 接口服务 2、具体内容 现在为止所进行的所有的 Rest 服务调用实际上都会出现一个非常尴尬的局面,例如:以如下代码为例: Dept dept = this .restTemplate .exchange(DEPT_GET_URL + id, HttpMethod.GET, new HttpEntity<Object>( this .headers), Dept. class ) .getBody(); 所有的数据的调用和转换都必须由用户自己来完成,而我们本身不擅长这些,我们习惯的编程模式是: 通过接口来实现业务的操作,而不是通过具体的 Rest 数据。 2.1、Feign 基本使用 为了方便起见现在将“microcloud-consumer-80”模块复制为了“microcloud-consumer-feign”模块。 1、 【microcloud-consumer-feign】为了可以使用到 feign 支持,需要修改 pom.xml 配置文件,引入相关依赖包: < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-feign </

springboot+cloud 学习(四)Zuul整合Swagger2

∥☆過路亽.° 提交于 2020-05-06 09:38:10
前言 在微服务架构下,服务是分散的,怎么把所有服务接口整合到一起是我们需要关注的。 下面举例用zuul作为分布式系统的网关,同时使用swagger生成文档,想把整个系统的文档整合在同一个页面上来说明。 项目结构 eureka-server :eureka服务注册中心,端口8761, eureka-server2 :eureka服务注册中心,端口8762, eureka-server3 :eureka服务注册中心,端口8763, zuul-swagger2 :zuul网关,端口8090, management-device :外接设备系统,端口8083, management-equip :设备管理系统,端口8082, Zuul整合Swagger2 eureka注册中心的搭建这里不再讲述,直接来看 zuul-swagger2 项目里怎么集成swagger pom.xml 文件中引入依赖: <!-- 必须要引入 springboot parent ,帮我们实现了很多jar包的依赖管理 --> <parent> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-parent</artifactId> <version> 2.0 . 2 .RELEASE</version>

swagger2 接口文档,整个微服务接口文档

给你一囗甜甜゛ 提交于 2020-05-06 08:45:43
1,因为整个微服务会有好多服务,比如会员服务,支付服务,订单服务,每个服务都集成了swagger 我们在访问的时候,不可能每个服务输入一个url 去访问,看起来很麻烦,所以我们需要在一个页面上集成整个微服务项目中所有的 swagger 效果图:可以选择不同的应用,出来的是不同的swagger 接口文档 2,实现思路: zuul 网关 + swagger 客户端访问一个应用,zuul 网关转发到相应的界面,看起来是在一个服务上的效果 3,eureka :注册中心 springcloud-config:注册中心:路由转发用配置中心做的,没有写在本地。可以参考 springcloud-config 动态网关路由 springcloud-api-member-impl-service:在eureka 注册的服务是:app-aiyuesheng-member springcloud-api-order-impl-service:在eureka 注册的服务是:app-aiyuesheng-order springcloud-swagger2:swagger 服务 springcloud-zuul :zuul 网关服务 4, 第一步: member 服务 和 order ,zuul 需要添加maven 依赖: <dependency> <groupId>com.spring4all<

SpringCloud全家桶学习之路由网关----Zuul(六)

拈花ヽ惹草 提交于 2020-05-06 07:16:32
一、Zuul概述 (1)Zuul是什么?   Zuul包含了对请求的 路由 和 过滤 的两个最主要的功能,其中路由功能负责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础;而过滤功能则负责对请求的处理过程进行干预,是实现请求校验、服务聚合等功能的基础,Zuul和Eureka进行整合,将Zuul自身注册为Eureka服务治理下的应用,同时从Eureka中获得其他微服务的消息,也即以后的访问微服务都是通过zuul跳转后获得。    注 :     ①Zuul服务最终还是会注册到Eureka     ② 提供代理、路由、过滤三大功能   本项目地址: https://github.com/Simple-Coder/microservice-demo-study (2)官网介绍   源码参考地址: https://github.com/Netflix/zuul/wiki/Getting-Started-2.0    二、Zuul路由基本配置 (1)Maven模块结构图 (2)microservice-zuul-gateway9527模块添加pom依赖 <!--zuul相关--> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zuul<

Spring Cloud Zuul 快速入门

狂风中的少年 提交于 2020-05-06 03:45:46
服务网关和Zuul 为什么要有服务网关: 我们都知道在微服务架构中,系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么多的微服务呢?难道要一个个的去调用吗?很显然这是不太实际的,我们需要有一个统一的接口与这些微服务打交道,这就是我们需要服务网关的原因。 我们已经知道,在微服务架构中,不同的微服务可以有不同的网络地址,各个微服务之间通过互相调用完成用户请求,客户端可能通过调用N个微服务的接口完成一个用户请求。比如:用户查看一个商品的信息,它可能包含商品基本信息、价格信息、评论信息、折扣信息、库存信息等等,而这些信息获取则来源于不同的微服务,诸如产品系统、价格系统、评论系统、促销系统、库存系统等等,那么要完成用户信息查看则需要调用多个微服务,这样会带来几个问题: 客户端多次请求不同的微服务,增加客户端代码或配置编写的复杂性 认证繁杂,访问每个服务都要进行一次认证 每个服务都通过http访问,导致http请求增加,效率不高拖慢系统性能 多个服务存在跨域请求问题,处理起来比较复杂 如下图所示: 我们该如何解决这些问题呢?我们可以尝试想一下,不要让前端直接知道后台诸多微服务的存在,我们的系统本身就是从业务领域的层次上进行划分,形成多个微服务,这是后台的处理方式。对于前台而言,后台应该仍然类似于单体应用一样,一次请求即可,于是我们可以在客户端和服务端之间增加一个API网关