Zuul

　　前言 　　作为分布式项目，单点登录是必不可少的，文本基于之前的的博客（猛戳： SpringCloud系列——Zuul 动态路由 ， SpringBoot系列——Redis ）记录Zuul配合Redis实现一个简单的sso单点登录实例 　　sso单点登录思路： 　　1、访问分布式系统的任意请求，被Zuul的Filter拦截过滤 　　2、在run方法里实现过滤规则：cookie有令牌accessToken且作为key存在于Redis，或者访问的是登录页面、登录请求则放行 　　3、否则，将重定向到sso-server的登录页面且原先的请求路径作为一个参数；response.sendRedirect("http://localhost:10010/sso-server/sso/loginPage?url=" + url); 　　4、登录成功，sso-server生成accessToken，并作为key（用户名+时间戳，这里只是demo，正常项目的令牌应该要更为复杂）存到Redis，value值存用户id作为value（或者直接存储可暴露的部分用户信息也行）设置过期时间（我这里设置3分钟）；设置cookie：new Cookie("accessToken",accessToken);，设置maxAge(60*3);、path("/"); 　　5、sso

前面学习了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

网关的作用 是为服务的入口，需要通过网关我们经行，登录认证，流量限制，请求监控，请求分发等等。 还是复制一份以前写过的代码，只需要主配置类，和配置文件就可以了 导包 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-zuul</artifactId> </dependency> 配置文件 如果想直接通过服务器名称访问我们可以通过不配置zuul直接访问http://localhost:4000/order-server/customer/user/1 eureka: client: serviceUrl: defaultZone: http://localhost:1000/eureka/#注册中心地址 instance: ip-address: true #使用ip配置 instance-id: zuul-server #指定服务的idserver: port: 4000spring: application: name: zuul-serverzuul: ignoredServices: '*' #不允许使用服务名称访问，这里是指的application：name,开启这个配置的时候我们需要开启routes prefix: /hrm

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> Spring Cloud Zuul 作为网关服务，是其他各服务对外中转站，通过Zuul进行请求转发。Spring Cloud Zuul 除了可以实现请求的路由功能，还有一个重要的功能就是 过滤器 。Zuul 的路由功能让所有的微服务提供的接口有统一的网关入口，但并不是所有的接口都是对外完全开发的，它们的访问权限一般都有一定的限制。我们可以在每个服务上对应的权限校验及其他的一些校验,而这些校验通常都是通过过滤器来完成的.一个应用的各个服务的校验大部分都是相似的逻辑,如果每个服务都写一遍逻辑校验的话,会显得代码比较频繁,而且维护也不方便. 为了减少体力代码的出现和后期维护时的方便,我们一般会将这些校验搬到前端发来请求的最前端来做统一的处理,而统一的API服务网关zuul就是最合适的选择. Zuul 可以通过定义过滤器来实现请求的拦截和过滤，而它本身的大部分功能也是通过过滤器实现的. 举个例子，用户服务提供一个登录接口，用户名密码正确后返回一个Token，此Token作为用户服务的通行证，那么用户登录成功后返回的Token就需要进行加密或者防止篡改处理。在到达用户服务其他接口前，就需要对Token进行校验，非法的Token就不需要转发到用户服务中了，直接在网关层返回信息即可。 要修改服务返回的信息

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、应用服务架构演进及微服务架构介绍 1.1 应用架构的演进历程 应用服务架构一直处于不断演进的过程中，上图通过对比5种比较主流的架构模式，展示应用架构的演进历程和变化。 单体架构（All in One）。在业务发展初期，为了快速落地应用，满足客户需求，一般会使用All in One的单体架构。单体架构的特点是：所有模块都耦合在一个进程里，系统完全封闭且很复杂，牵一发动全局。 竖井式架构（Vertical Application）。随着业务的增长，单体架构越来越臃肿，我们对系统做了垂直化的拆分，应用架构进入第二阶段即竖井式架构。竖井式架构，就是根据业务属性将一个大的单体拆分成一些不同的模块或子系统，子系统之间没有直接关联。竖井式架构依然存在紧耦合的问题，系统也是完全封闭的，且存在大量的重复代码拷贝及模块功能需大量重复造轮子的情况。 单体架构和竖井式架构都是围绕web容器打包及部署的架构模式，随着业务的快速发展，要求实现服务的快速迭代和快速交付，应用架构也由此演进为以服务为中心的架构模式。主流的面向服务的架构模式有：RPC架构、ESB中心化架构和微服务架构。 RPC架构。RPC架构在现在的应用系统中还是比较常见的架构模式，适用于高并发场景，性能比较好。Dubbo就是一个典型的RPC架构。RPC架构也存在一些问题

spring-boot版本：2.0.4.RELEASE，spring-cloud版本：Finchley.RELEASE，java版本：1.8 一、快速启动一个zuul 1.新建一个父项目，依赖如下 <?xml version="1.0" encoding="UTF-8"?> <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <groupId>com.taikang.bd</groupId> <artifactId>spring-cloud</artifactId> <version>0.0.1-SNAPSHOT</version> <packaging>pom</packaging><!--声明pom为父--> <!--子项目--> <modules> <module>eureka-8761</module> <module>zuul-8800</module

Eureka用于服务的注册于发现，Feign支持服务的调用以及均衡负载，Hystrix处理服务的熔断防止故障扩散，Spring Cloud Config服务集群配置中心。 为什么需要API Gateway 1、简化客户端调用复杂度 在微服务架构模式下后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway作为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。 2、数据裁剪以及聚合 通常而言不同的客户端对于显示时对于数据的需求是不一致的，比如手机端或者Web端又或者在低延迟的网络环境或者高延迟的网络环境。 因此为了优化客户端的使用体验，API Gateway可以对通用性的响应数据进行裁剪以适应不同客户端的使用需求。同时还可以将多个API调用逻辑进行聚合，从而减少客户端的请求数，优化客户端用户体验 3、多渠道支持 当然我们还可以针对不同的渠道和客户端提供不同的API Gateway,对于该模式的使用由另外一个大家熟知的方式叫Backend for front-end, 在Backend for front-end模式当中，我们可以针对不同的客户端分别创建其BFF 4

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 首先需要明白Jwt是什么 这里有个大佬详细介绍如何使用 << 密码加密与微服务鉴权JWT详细使用教程 >> 我们只使用这个工具进行功能实现 流程图 步骤详解 功能一 : 登录成功后使用jwt生成随机码,并传递给浏览器(token) 功能二 : 浏览器判断登录成功后,把token保存到sessionStorage中(会话级别) 功能三 : 在每次发送http请求时都加上一个请求头Authorization___请求拦截器 功能四 : zuul过滤器中进行拦截判断 判断是否访问登录服务 进行token校验 功能五 : 使用响应拦截器进行拦截判断状态码,跳转login页面 步骤实现 功能一 : 登录成功后使用jwt生成随机码,并传递给浏览器(token) package com.czxy.service.impl; import com.czxy.domain.User; import com.czxy.mapper.UserMapper; import com.czxy.service.UserService; import com.czxy.utils.JwtUtils; import com.czxy.utils.RasUtils; import com.czxy.vo.BaseResult; import

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> [TOC] 前言 之前写了一篇:《 密码加密与微服务鉴权JWT详细使用教程 》 实际操作(练习实例) pom(common)，在原有基础上添加jwt依赖 <dependencies> <!--lombok--> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.16.20</version> </dependency> <!--工具--> <dependency> <groupId>org.apache.commons</groupId> <artifactId>commons-lang3</artifactId> </dependency> <!--jwt依赖--> <dependency> <groupId>commons-beanutils</groupId> <artifactId>commons-beanutils</artifactId> <version>1.9.3</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一, 首先创建项目,分对应模块 整体架构图 二, 在公共工具中导入pom.xml依赖(包含JWT相应依赖), <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> </dependency> <!--lombok--> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.16.20</version> </dependency> <!--jwt依赖--> <dependency> <groupId>commons-beanutils</groupId> <artifactId>commons-beanutils</artifactId> <version>1.9.3</version> </dependency> <dependency> <groupId>io.jsonwebtoken</groupId> <artifactId>jjwt</artifactId> <version>0.9