Zuul浅谈
角色功能:
Zuul是netflix开源的一个API Gateway 服务器, 本质上是一个web servlet应用。nginx
ZuulServlet
相似SpringMvc的DispatcherServlet
,全部的Request都要通过ZuulServlet
的处理。做为一个边界性质的应用程序,Zuul提供了动态路由、监控、弹性负载和安全功能。Zuul底层利用各类filter实现以下功能:web
- 认证和安全 识别每一个须要认证的资源,拒毫不符合要求的请求。
- 性能监测 在服务边界追踪并统计数据,提供精确的生产视图。
- 动态路由 根据须要将请求动态路由到后端集群。
- 压力测试 逐渐增长对集群的流量以了解其性能。
- 负载卸载 预先为每种类型的请求分配容量,当请求超过容量时自动丢弃。
- 静态资源处理 直接在边界返回某些响应。
Zuul的核心是一系列的filters
,
后端
这些Filter在整个HTTP请求过程当中执行一连串的操做。
Zuul提供了一个框架,能够对过滤器进行动态的加载,编译,运行。过滤器之间没有直接的相互通讯。他们是经过一个RequestContext的静态类来进行数据传递的
。RequestContext类中有ThreadLocal变量来记录每一个Request所须要传递的数据。
浏览器
Zuul中定义了四种标准过滤器类型,这些过滤器类型对应于请求的典型生命周期,分别是“PRE”、“ROUTING”、“POST”、“ERROR”,整个生命周期能够用下图来表示。安全

- PRE: 这种过滤器在请求被路由以前调用。咱们可利用这种过滤器实现身份验证、在集群中选择请求的微服务、记录调试信息等。
- ROUTING:这种过滤器将请求路由到微服务。这种过滤器用于构建发送给微服务的请求,并使用Apache HttpClient或Netfilx Ribbon请求微服务。
- POST:这种过滤器在路由到微服务之后执行。这种过滤器可用来为响应添加标准的HTTP Header、收集统计信息和指标、将响应从微服务发送给客户端等。
- ERROR:在其余阶段发生错误时执行该过滤器。 除了默认的过滤器类型,Zuul还容许咱们建立自定义的过滤器类型。例如,咱们能够定制一种STATIC类型的过滤器,直接在Zuul中生成响应,而不将请求转发到后端的微服务。
自定义Filter:
某些场景下,咱们须要自定义Filter时,只须要继承ZuulFilter,并重写里面的方法就能够了
服务器

Ribbon浅谈
负载均衡的实现方式:
- 服务端负载均衡:当浏览器向后台发出请求的时候,会首先向反向代理服务器发送请求,反向代理服务器会根据客户端部署的ip:port映射表以及负载均衡策略,来决定向哪台服务器发送请求,通常会使用到nginx反向代理技术。
- 客户端负载均衡:当浏览器向后台发出请求的时候,客户端会向服务注册器(例如:Eureka Server),拉取注册到服务器的可用服务信息,而后根据负载均衡策略,直接命中哪台服务器发送请求。这整个过程都是在客户端完成的,并不须要反向代理服务器的参与。
Spring Cloud Ribbon 是一个基于Http和TCP
的客服端负载均衡工具,它是基于Netflix Ribbon实现。Ribbon不须要独立部署,但它几乎存在于每一个微服务的基础设施中。Ribbon 能够经过在客户端中配置ribbonServerList
来设置服务端列表去轮询访问以达到均衡负载的做用。并发
当Ribbon与Eureka联合使用时,ribbonServerList会被DiscoveryEnabledNIWSServerList重写,扩展成从Eureka注册中心中获取服务实例列表。同时它也会用NIWSDiscoveryPing来取代IPing,它将职责委托给Eureka来肯定服务端是否已经启动。负载均衡
当Ribbon与Consul联合使用时,ribbonServerList会被ConsulServerList来扩展成从Consul获取服务实例列表。同时由ConsulPing来做为IPing接口的实现。框架
咱们在使用Spring Cloud Ribbon的时候,不管是与Eureka仍是Consul结合,都会在引入Spring Cloud Eureka或Spring Cloud Consul依赖的时候经过自动化配置来加载上述所说的配置内容,因此咱们能够快速在Spring Cloud中实现服务间调用的负载均衡。dom
下面咱们实现Ribbon示例。
轮询策略:

- BestAvailableRule:最大可用策略,即先过滤出故障服务器后,选择一个当前并发请求数最小的;
- AvailabilityFilteringRule:可用过滤策略,先过滤出故障的或并发请求大于阈值一部分服务实例,而后再以线性轮询的方式从过滤后的实例清单中选出一个;
- RoundRobinRule:轮询策略,Ribbon以轮询的方式选择服务器,这个是默认值。因此示例中所启动的两个服务会被循环访问;
- RandomRule:随机选择,也就是说Ribbon会随机从服务器列表中选择一个进行访问;
- WeightedResponseTimeRule:带有加权的轮询策略,对各个服务器响应时间进行加权处理,而后在采用轮询的方式来获取相应的服务器;
- RetryRule:对选定的负载均衡策略机上重试机制,在一个配置时间段内当选择server不成功,则一直尝试使用subRule的方式选择一个可用的server;
- ZoneAvoidanceRule:区域感知策略,先使用主过滤条件(区域负载器,选择最优区域)对全部实例过滤并返回过滤后的实例清单,依次使用次过滤条件列表中的过滤条件对主过滤条件的结果进行过滤,判断最小过滤数(默认1)和最小过滤百分比(默认0),最后对知足条件的服务器则使用RoundRobinRule(轮询方式)选择一个服务器实例。