Zuul

Spring Cloud 功能 开源实现 说明 通用功能 服务注册与发现 Netflix Eureka Consul Discovery 兼容且提供替换组件 负载均衡 Netflix Ribbon 兼容 服务调用 Feign RestTemplate 兼容 配置管理 Config Server Consul Config 兼容且提供替换组件 服务网关 Spring Cloud Gateway Netflix Zuul Spring Cloud Gateway旨在为微服务架构提供简单、有效和统一的API路由管理方式 ， 目标是替代Netflix Zuul 链路跟踪 Spring Cloud Sleuth 兼容且提供替换组件 消息驱动 Spring Cloud Stream RabbitMQ binder Kafka binder 兼容且提供替换组件 消息总线 Spring Cloud Bus RabbitMQ Kafka 兼容且提供替换组件 安全 Spring Cloud Security 兼容 分布式任务调度 Spring Cloud Task 兼容 分布式协调 Spring Cloud Cluster 兼容 来源： oschina 链接： https://my.oschina.net/guoenzhou/blog/4292964

过滤器类型 Zuul 中的过滤器跟我们之前使用的 javax.servlet.Filter 不一样，javax.servlet.Filter 只有一种类型，可以通过配置 urlPatterns 来拦截对应的请求。 而 Zuul 中的过滤器总共有 4 种类型，且每种类型都有对应的使用场景。 1）pre 可以在请求被路由之前调用。适用于身份认证的场景，认证通过后再继续执行下面的流程。 2）route 在路由请求时被调用。适用于灰度发布场景，在将要路由的时候可以做一些自定义的逻辑。 3）post 在 route 和 error 过滤器之后被调用。这种过滤器将请求路由到达具体的服务之后执行。适用于需要添加响应头，记录响应日志等应用场景。 4）error 处理请求时发生错误时被调用。在执行过程中发送错误时会进入 error 过滤器，可以用来统一记录错误信息。 请求生命周期 可以通过图 1 看出整个过滤器的执行生命周期， 图 1 过滤器生命周期 通过上面的图可以清楚地知道整个执行的顺序，请求发过来首先到 pre 过滤器，再到 routing 过滤器，最后到 post 过滤器，任何一个过滤器有异常都会进入 error 过滤器。 通过 com.netflix.zuul.http.Zuul Servlet 也可以看出完整执行顺序，ZuulServlet 类似 Spring -Mvc 的

1. 背景 通过 Spring Cloud 和微服务 的学习，我们了解到使用Spring Cloud实现微服务的架构基本成型，大致是这样的： 我们使用Spring Cloud Netflix中的Eureka实现了 服务注册中心 以及服务注册与发现；而服务间通过 Ribbon 或Feign实现服务的消费以及均衡负载。为了使得服务集群更为健壮，使用 Hystrix 的熔断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。 在该架构中，服务集群包含：内部服务Service A 和 Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块，直接暴露我们的服务地址，这样的实现是否合理，或者是否有更好的实现方式呢？ 先来说说这样的架构需要做的一些事儿以及存在的不足： • 破坏了服务无状态特点。 为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。 从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问的控制处理。 • 无法直接复用既有接口。 当我们需要对一个即有的集群内访问接口，实现外部服务访问时

原理：通过请求头埋入指定服务的metadata标识，扩展ribbon的choose策略。 一定要注意hystrix的隔离策略 ！！强烈推荐使用信号量隔离。 因为一旦使用线程隔离（线程池存在复用），会导致InheritThreadLocal（只会在线程init时拷贝父线程的ThreadLocal值）失效。 传送门 下载源码编译 应用集成 maven依赖 <dependency> <groupId>io.jmnarloch</groupId> <artifactId>ribbon-discovery-filter-spring-cloud-starter</artifactId> <version>2.1.0</version> </dependency> 应用配置 #AB测试用，网关会根据该参数路由 spring.cloud.nacos.discovery.metadata.launcher=A 拦截器 public class AbTestingFilter extends OncePerRequestFilter { private final static String SWITCH_KEY = "launcher", SWITCH_HEAD_KEY = "switchTag", DEFAULT_ENV = "B";//默认B为线上测试环境 @Value("${spring

Spring Cloud整体核心架构只有一点：Rest服务，也就是说在整个Spring Cloud配置过程之中，所有的配置处理都是围绕着Rest完成的，在这个Rest处理之中，一定要有两个端：服务的提供者（Provider）、服务的消费者（Consumer），所以对于整个Spring Cloud基础的结构就如下所示。 SpringCloud基础架构 既然Spring Cloud的核心是Restful结构，那么如果要想更好的去使用Rest这些微服务还需要考虑如下几个问题。 1、所有的微服务地址一定会非常的多，所以为了统一管理这些地址信息，也为了可以及时的告诉用户哪些服务不可用，所以应该准备一个分布式的注册中心，并且该注册中心应该支持有HA机制，为了高速并且方便进行所有服务的注册操作，在Spring Cloud里面提供有一个Eureka的注册中心。 微服务结构图 2、对于整个的WEB端的构架（SpringBoot实现）可以轻松方便的进行WEB程序的编写，而后利用Nginx或Apache实现负载均衡处理，但是你WEB端出现了负载均衡，那么业务端呢？应该也提供有多个业务端进行负载均衡。那么这个时候就需要将所有需要参与到负载均衡的业务端在Eureka之中进行注册。 多业务端-负载均衡 在进行客户端使用Rest架构调用的时候，往往都需要一个调用地址，即使现在使用了Eureka作为注册中心

一、高级篇幅之高并发情况下接口限流特技 1、nginx层限流 2、网关层限流 简介：谷歌guava框架介绍，网关限流使用 package net.xdclass.apigateway.filter; import com.google.common.util.concurrent.RateLimiter; import com.netflix.zuul.ZuulFilter; import com.netflix.zuul.context.RequestContext; import com.netflix.zuul.exception.ZuulException; import org.springframework.http.HttpStatus; import org.springframework.stereotype.Component; import javax.servlet.http.HttpServletRequest; import static org.springframework.cloud.netflix.zuul.filters.support.FilterConstants.PRE_TYPE; /** * 订单限流 */ @Component public class OrderRateLimiterFilter extends ZuulFilter

今天我们介绍的Zuul动态路由的解决方案来自于携程开源的配置中心Apollo。 Apollo概述 Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。 Apollo支持4个维度管理Key-Value格式的配置： application (应用) environment (环境) cluster (集群) namespace (命名空间) Apollo相比于Spring Cloud Config优势 Spring Cloud Config的精妙之处在于它的配置存储于Git，这就天然的把配置的修改、权限、版本等问题隔离在外。通过这个设计使得Spring Cloud Config整体很简单，不过也带来了一些不便之处。（了解源码可+求求: 1791743380） 功能点 Apollo Spring Cloud Config 备注 配置界面 一个界面管理不同环境、不同集群配置 无，需要通过git操作 配置生效时间 实时 重启生效，或手动refresh生效 Spring Cloud Config需要通过Git webhook，加上额外的消息队列才能支持实时生效 版本管理 界面上直接提供发布历史和回滚按钮 无，需要通过git操作 灰度发布 支持 不支持 授权、审核、审计

1.我们在controller的方法经常要根据token来获取用户的信息，如果每个方法都执行这个操作让程序看起来不太优雅，所以选择使用自定义参数解析器去自动根据token获取用户信息，在controller的方法上加入这个对象作为参数即可。 2.在common模块编写这个自定义参数解析器 @Service public class UserArgumentResolver implements HandlerMethodArgumentResolver { @Override public boolean supportsParameter(MethodParameter methodParameter) { Class<?> clazz = methodParameter.getParameterType(); return clazz == AuthenticationInfo.class; } @Override public Object resolveArgument(MethodParameter methodParameter, ModelAndViewContainer modelAndViewContainer, NativeWebRequest nativeWebRequest, WebDataBinderFactory webDataBinderFactory

ribbon 可以看到 Feign 调用步骤比较繁琐，并且传参数以及经过zuul 问题较多 再来看看ribbon 只需要在 implements 接口类里面引入一个 ribbon 均衡，再方法中调用即可 /** * www.1b23.com */ @Service @Transactional //开启事物 public class UsersServiceImpl implements UsersService { @Autowired private LoadBalancerClient loadBalancerClient; //ribbon负载均衡器 ...... /**保存用户 * @param pd * @throws Exception */ public void saveUser (PageData pd) throws Exception { usersMapper .saveUser (pd); pd .put ( "tokenKey" , Tools.creatTokenKey( "userAdd" )); LoadBalancerUtil .responseByPost (this.loadBalancerClient, "fh-dbsync" , "user/add" , pd); //请求数据库表同步微服务 } } "fh-dbsync"

github https://github.com/marcosbarbero/spring-cloud-zuul-ratelimit spring-cloud-zuul-ratelimit 说明 spring-cloud-zuul-ratelimit是和zuul整合提供分布式限流策略的扩展 对请求的目标URL进行限流（例如：某个URL每分钟只允许调用多少次） 对客户端的访问IP进行限流（例如：某个IP每分钟只允许请求多少次） 对某些特定用户或者用户组进行限流（例如：非VIP用户限制每分钟只允许调用100次某个API等） 多维度混合的限流。此时，就需要实现一些限流规则的编排机制。与、或、非等关系。 支持的限流粒度 服务粒度 (默认配置，当前服务模块的限流控制) 用户粒度 用户限流的实现：如果你的项目整合 Shiro 或者 Spring Security 安全框架，那么会自动维护request域UserPrincipal，如果是自己的框架，请登录成功后维护request域UserPrincipal，才能使用用户粒度的限流。未登录默认是：anonymous ORIGIN粒度 (用户请求的origin作为粒度控制) 某个IP的客户端被限流并不影响其他客户端，即API网关对每个客户端限流是相互独立的 URL 接口粒度 (请求接口的地址作为粒度控制) 以上粒度自由组合，又可以支持多种情况。