Spring Cloud

idea中有个窗口叫做 Run DashBoard 在这里可以管理多个模块的启停，这个面板一般情况下是关闭的打开Run DashBoard面板 在工程的.idea中找到workspace.xml，并找到RunDashboard < component name ="RunDashboard" > < option name ="ruleStates" > < list > < RuleState > < option name ="name" value ="ConfigurationTypeDashboardGroupingRule" /> </ RuleState > < RuleState > < option name ="name" value ="StatusDashboardGroupingRule" /> </ RuleState > </ list > </ option > </ component > 添加 < option name ="configurationTypes" > < set > < option value ="SpringBootApplicationConfigurationType" /> </ set > </ option > 添加以后如下 < component name ="RunDashboard" > < option

Gateway 简介 是什么？ Spring Cloud 全家桶中有个很重要的组件：网关。在 1.x 版本中使用的是 Zuul 网关，但是到了 2.x，由于Zuul的升级不断跳票，Spring Cloud 自己研发了一套网关组件：Spring Cloud Gateway。 Spring Cloud Gateway基于 Spring Boot 2.x，Spring WebFlux 和 Project Reactor 构建，使用了 Webflux 中的 reactor-netty 响应式编程组件，底层使用了 Netty 通讯框架。 详见： 官网 能干嘛？ 反向代理 鉴权 流量控制 熔断 日志监控 ...... 网关在微服务架构中的位置 Gateway 的三大概念 Route（路由） ：路由是构建网关的基本模块，它由 ID、目标 URI、一系列的断言和过滤器组成，如果断言为 true 则匹配该路由 Predicate（断言） ： 参考的是 Java8 中的 java.util.function.Predicate 。开发人员可以匹配 HTTP 请求中的所有内容（例如请求头或请求参数），如果请求与断言相匹配则进行路由 Filter（过滤） ：指的是 Spring 框架中 GatewayFilter 的实例，使用过滤器，可以在请求被路由之前或之后对请求进行修改 工作流程 Clients

前言 在spring cloud分布式架构中，系统被拆分成了许多个服务单元，业务复杂性提高。如果出现了异常情况，很难定位到错误位置，所以需要实现分布式链路追踪，跟进一个请求有哪些服务参与，参与的顺序如何，从而去明确一个问题。 spring cloud sleuth 通常来说，一个分布式服务跟踪系统主要由三部分：数据收集、数据存储和数据展示。 对于大规模的分布式系统来说，数据存储可分为实时数据和全量数据两部分。实时数据用来排查故障，全量数据用于系统优化；数据展示涉及数据挖掘和分析。 名词解释 服务追踪的追踪单元是从客户端发起请求抵达被追踪的系统边界开始，到被追踪的边界开始，到被追踪的紫铜向客户返回响应为止的过程，称呼为一个 "trace"。每个 trace 中会调用若干个服务，为了记录调用了哪些服务，以及每次调用的响应时间等信息，在调用每个服务时，都会迈入一个调用记录，成为一个 "span"。如此，若干个 有序的 span 就组成了一个 trace 。 在系统向外界提供服务的过程中，会不断地有请求和响应发生，也就会不断生成 trace ，把这些带有 span 的 trace 记录下来，就可以描绘出一幅系统的服务拓扑图。附带上 span 中的响应时间，以及请求成功与否等信息，就可以在发生问题的时候，找到异常的服务；根据历史数据，还可以从系统整体层面分析出哪里性能差，定位性能优化的目标。

一、前言 Spring Cloud Sleuth 主要功能就是在分布式系统中提供追踪解决方案 ,并且兼容了zipkin，提供了REST API接口来辅助我们查询跟踪数据以实现对分布式系统的监控程序 。 Sleuth 是个组件，没有提供我们可视化的界面，和一些相信的api信息，而zipkin 是个系统，他有可视化的界面，和对应接口调用详细的信息情况。 二、为什么要使用链路追踪 微服务架构上通过业务来划分服务的，通过REST调用，对外暴露的一个接口，可能需要很多个服务协同才能完成这个接口功能，如果链路上任何一个服务出现问题或者网络超时，都会形成导致接口调用失败。随着业务的不断扩张，服务之间互相调用会越来越复杂。 ，对调用链的分析会越来越复杂。如果那里出现了错误，我们是很排查的。所以我们引入了链路追踪，使用可视化的界面我们可以很容易的找到那一块耗时多，等等。 Sleuth 的使用： 　　1.在项目中加入依赖： <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-sleuth</artifactId> </dependency> 2.然后在你想打印日志的地方输入 控制台会出现下面这个 （现在看起来是不是感觉使用起来也不怎方便，下面我会讲zipkin

spring-boot-starter-parent 整合第三方常用框架信息(各种依赖信息) spring-boot-starter-web 是Springboot整合SpringMvc Web 实现原理:Maven依赖继承关系 　　相当于把第三方常用maven依赖信息,在parent项目中已经封装好了 提供依赖信息关联整合的jar包 　　springboot中快速原理(Maven子父依赖关系),springboot对常用依赖信息进行封装 <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> 在pom中为什么不写版本号,因为在parent已经封装好 了 </dependency> #springcloud 依赖于springboot实现微服务###springboot默认集成springmvc组件 springcloud使用springmvc 编写微服务http接口 微服务通讯接口(http+json格式) @RestController注解 表示该类中的方法返回json格式相当于 @Conytoller+@ResponseBody 由spring mvc 4.0后提供的注解,为微服务提供返回json格式

access_token是客户端调用其他微服务调的凭证，access_token有效期不能太长（丢了风险很大），一般可以设置2小时，如果access_token失效了，就不能调用微服务了，上节说了access_token失效的处理---refresh_token来刷新令牌，refresh_token可以设置很长的有效期，比如一个月 下面是用refresh_token刷新令牌的步骤： 1，配置refresh_token 　在客户端应用的表里配置 refresh_token 的有效期，然后配置refresh_token授权模式，这样认证服务器在给客户端应用发access_token的同时，也会发一个refresh_token （图1） 2， 在客户端应用调用微服务时，从session中拿出token，判token是否过期（在存入session时已经设置了token的过期时间），如果token已过期，就从拿refresh_token换取access_token： （图2） 如果refresh_token也过期了怎么处理呢？ 虽然refresh_token有效期很长（比如一个月）但是还是会过期的。如果refresh_token也过期了怎么办呢？ 答案是：没办法。只能去认证服务器走一遍认证流程。 当重新去认证服务器走授权流程的时候，又分两种情况： 1，refresh_token虽然过期了

本篇解决一个问题，token有效期 token是一个短活的东西，session可能是3天，但是token可能就2个小时，此时就会出现一种情况，session还有效但是token失效了，此时再拿着这个token去调用其他微服务就会失败了。 这就涉及到了OAuth2协议中的Refresh token，刷新令牌。刷新令牌说的是，不管你使用OAuth协议中的四种授权类型中的哪一种（密码模式、授权码模式、简化模式、客户端模式），当token失效的时候，你可以拿着一个refresh_token去重新获取一个令牌，而不需要输入用户名密码。这样用户拿到一个短生命周期的access_token，和一个长生命周期的refresh_token，当access_token失效的时候，就拿refresh_token去换取一个新的access_token。 理论上来说，access_token可以设置一个很长的有效期，但是这样是不安全的，只要拿到access_token，就可以访问你的服务了，所以如果这样做，风险很高。而refresh_token就不一样了，如下图可以看到，要想通过refresh_token换取access_token，需要携带clientId和clientSecret，认证服务器会校验他俩，这两者是保存在服务器端的，别人是拿不到的，所以即使别人拿到了refresh_token也是没用的。

前几篇说的都是基于session的SSO（客户端应用的session、认证服务器的session），客户端应用拿到认证服务器返回的token后，将其存在自己的session， 用户登录状态是存在服务器端的。 本篇要说的是，要实现一个基于浏览器cookie的SSO，客户端应用获取到令牌后，不是将其存到session，而是写入浏览器cookie，这个改变会带来一些列问题，本篇将解决这些问题。 在OAuth授权回调里处理 客户端应用 客户token后的改造，在OAuth授权回调里处理，拿到token后写入cookie： CookieTokenFilter 在客户端应用，引入zuul的依赖，写一个CookieTokenFilter，从cookie拿出token 加在请求头里。 package com.nb.security.admin; import com.netflix.zuul.ZuulFilter; import com.netflix.zuul.context.RequestContext; import com.netflix.zuul.exception.ZuulException; import org.apache.commons.lang3.StringUtils; import org.springframework.http.* ; import org

1.前言 　　最近一直在看Springboot和springcloud代码，看了将近20多天，对这两个系统的认知总算是入了门。后续应该会有一个系列的文章，本文就先从Springboot的启动入手. 2.容器初始化 上面的代码是Springboot的入口，现在从run方法进去 点击进来后到了这里就会分成两步 1 .生成一个SpringApplication对象 2.调用生成的对象的run方法 【 2.1 】我们先看SpringApplication的构造器是如何生成一个SpringApplication对象 1.推断程序类型，推断规则在2.1.1 2.查找ApplicationContextInitializer的实现类，ApplicationContextInitializer是Spring框架的接口，在ApplicationContext的初始化之前，需要逐一调用ApplicationContextInitializer的实现类的initialize方法。 3.查找中ApplicationListener的实现类，Springboot大量的采用了事件监听机制，ApplicationListener负责将监听事件并广播出去。后续我们会详细讲解 【2.1.1】判断程序类型 至此SpringApplication构造初始化就完成了。 3.容器启动 调用生成的对象的run方法 【3.1

授权模式改造成了Authorization code完成了改造的同时也实现了SSO。微服务环境下的前后端分离的单点登陆。 把admin的服务重启。刷新页面 并没有让我去登陆，直接就进入了首页。 order的API控制台 只要你在认证服务器上的session没过期。认证服务器就知道你是谁，他就不会让你输入用户名密码了。直接跳回到客户端应用。 一共有三个有效期。 退出操作 退出的时候。现在前端服务器清空session，认证服务器也需要清空session 在前端服务器退出后，再跳转到认证服务器执行退出。logout是spring security默认的退出路径 这时候跳转到了认证服务器。 点击退出后 如果再次输入账号密码登录 这时候没跳转会前端， 这是个404的页面。 这是因为我们之前触发的登陆页面的请求，是下面这样的一个请求 这里他是不知道是要跳转回admin的应用的，所以默认进去了自己的主页。 :9090/根目录，这个主页没做任何的处理 所以是一个404页面。 退出操作优化 退出的时候加一个参数redirect_uri 认证服务器改造 首先要找到处理logout这个请求的代码。 它会拦截logout的方法，然后 拦住以后会生成一个页面出来。 页面上很简单，上面一个提示语，问题你是不是确认要退出。点了按钮就会提交这个表单。 我们来复制这个类，首先在我们的代码里面建一个一模一样的包