为什么要有服务网关?
我们都知道在微服务架构中,系统会被拆分为很多个微服务。那么作为客户端要如何去调用这么多的微服务呢?难道要一个个的去调用吗?很显然这是不太实际的,我们需要有一个统一的接口与这些微服务打交道,这就是我们需要服务网关的原因。
我们已经知道,在微服务架构中,不同的微服务可以有不同的网络地址,各个微服务之间通过互相调用完成用户请求,客户端可能通过调用N个微服务的接口完成一个用户请求。比如:用户查看一个商品的信息,它可能包含商品基本信息、价格信息、评论信息、折扣信息、库存信息等等,而这些信息获取则来源于不同的微服务,诸如产品系统、价格系统、评论系统、促销系统、库存系统等等,那么要完成用户信息查看则需要调用多个微服务,这样会带来几个问题:
客户端多次请求不同的微服务,增加客户端代码或配置编写的复杂性 认证繁杂,访问每个服务都要进行一次认证 每个服务都通过http访问,导致http请求增加,效率不高拖慢系统性能 多个服务存在跨域请求问题,处理起来比较复杂
我们该如何解决这些问题呢?我们可以尝试想一下,不要让前端直接知道后台诸多微服务的存在,我们的系统本身就是从业务领域的层次上进行划分,形成多个微服务,这是后台的处理方式。对于前台而言,后台应该仍然类似于单体应用一样,一次请求即可,于是我们可以在客户端和服务端之间增加一个API网关,所有的外部请求先通过这个微服务网关。它只需跟网关进行交互,而由网关进行各个微服务的调用。
这样的话,我们就可以解决上面提到的问题,同时开发就可以得到相应的简化,还可以有如下优点:
减少客户端与微服务之间的调用次数,提高效率 便于监控,可在网关中监控数据,可以做统一切面任务处理 便于认证,只需要在网关进行认证即可,无需每个微服务都进行认证 降低客户端调用服务端的复杂度 这里可以联想到一个概念,面向对象设计中的门面模式,即对客户端隐藏细节,API网关也是类似的东西,只不过叫法不同而已。它是系统的入口,封装了应用程序的内部结构,为客户端提供统一服务,一些与业务本身功能无关的公共逻辑可以在这里实现,诸如认证、鉴权、监控、缓存、负载均衡、流量管控、路由转发等等。示意图
SpringCloud Gateway网关介绍
- SpringCloud Gateway是Spring Cloud 的一个全新项目,该项目是基于 Spring 5.0,Spring Boot 2.0 和 Project Reactor 等技术开发的网关,它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。
- SpringCloud Gateway作为Spring Cloud 生态系统中的网关,目标是替代 Zuul,在Spring Cloud 2.0以上版本中,没有对新版本的Zuul 2.0以上最新高性能版本进行集成,仍然还是使用的Zuul 2.0之前的非Reactor模式的老版本。而为了提升网关的性能,SpringCloud Gateway是基于WebFlux框架实现的,而WebFlux框架底层则使用了高性能的Reactor模式通信框架Netty。
总结一下,服务网关大概就是四个功能:统一接入、流量管控、协议适配、安全维护。而在目前的网关解决方案里,有Nginx+ Lua、Spring Cloud Zuul以及Spring Cloud Gateway等等。这里以Spring Cloud Gateway为例进行说明。
Spring Cloud Gateway 的目标,不仅提供统一的路由方式,并且基于 Filter 链的方式提供了网关基本的功能,例如:安全,监控/指标,和限流。
提前声明:Spring Cloud Gateway 底层使用了高性能的通信框架Netty。
SpringCloud Gateway 特征
SpringCloud官方,对SpringCloud Gateway 特征介绍如下:
- 基于 Spring Framework 5,Project Reactor 和 Spring Boot 2.0
- 集成 Hystrix 断路器
- 集成 Spring Cloud DiscoveryClient
- Predicates 和 Filters 作用于特定路由,易于编写的 Predicates 和 Filters
- 具备一些网关的高级功能:动态路由、限流、路径重写
从以上的特征来说,和Zuul的特征差别不大,SpringCloud Gateway和Zuul主要的区别,还是在底层的通信框架上。
简单说明一下上文中的三个术语:
Filter(过滤器):
和Zuul的过滤器在概念上类似,可以使用它拦截和修改请求,并且对上游的响应,进行二次处理。
过滤器为org.springframework.cloud.gateway.filter.GatewayFilter类的实例。
Route(路由):
网关配置的基本组成模块,和Zuul的路由配置模块类似。
一个Route模块由一个 ID,一个目标 URI,一组断言和一组过滤器定义。如果断言为真,则路由匹配,目标URI会被访问。
Predicate(断言):
一个 Java 8 的 Predicate,可以使用它来匹配来自 HTTP 请求的任何内容,例如 headers 或参数。断言的输入类型是一个 ServerWebExchange。
SpringCloud Gateway的核心架构
迎来了Webflux,Webflux的出现填补了Spring在响应式编程上的空白,Webflux的响应式编程不仅仅是编程风格的改变,而且对于一系列的著名框架,都提供了响应式访问的开发包,比如Netty、Redis等等。
SpringCloud Gateway 使用的Webflux中的reactor-netty响应式编程组件,底层使用了Netty通讯框架。
SpringCloud Zuul的核心架构
SpringCloud Zuul的IO模型
Springcloud中所集成的Zuul版本,采用的是Tomcat容器,使用的是传统的Servlet IO处理模型。
servlet由servlet container进行生命周期管理。
- container启动时构造servlet对象并调用servlet init()进行初始化;
- container关闭时调用servlet destory()销毁servlet;
- container运行时接受请求,并为每个请求分配一个线程(一般从线程池中获取空闲线程)然后调用service()。
Servlet的IO模型
servlet是一个简单的网络IO模型,当请求进入servlet container时,servlet container就会为其绑定一个线程,在并发不高的场景下这种模型是适用的,但是一旦并发上升,线程数量就会上涨,而线程资源代价是昂贵的(上线文切换,内存消耗大)严重影响请求的处理时间。
在一些简单的业务场景下,不希望为每个request分配一个线程,只需要1个或几个线程就能应对极大并发的请求,这种业务场景下servlet模型没有优势。
Springcloud Zuul 是基于servlet之上的一个阻塞式处理模型,即spring实现了处理所有request请求的一个servlet(DispatcherServlet),并由该servlet阻塞式处理处理。
Springcloud Zuul无法摆脱servlet模型的弊端,虽然Zuul 2.0开始,使用了Netty,并且已经有了大规模Zuul 2.0集群部署的成熟案例,但是,Springcloud官方已经没有集成改版本的计划了。
Webflux 服务器
Webflux模式替换了旧的Servlet线程模型,用少量的线程处理request和response io操作,这些线程称为Loop线程,而业务交给响应式编程框架处理,响应式编程是非常灵活的,用户可以将业务中阻塞的操作提交到响应式框架的work线程中执行,而不阻塞的操作依然可以在Loop线程中进行处理,大大提高了Loop线程的利用率。官方结构图:
Webflux虽然可以兼容多个底层的通信框架,但是一般情况下,底层使用的还是Netty,Netty是目前业界认可的最高性能的通信框架。
而Webflux的Loop线程,正好就是著名的Reactor 模式IO处理模型的Reactor线程,如果使用的是高性能的通信框架Netty,这就是Netty的EventLoop线程。
Spring Cloud Gateway的处理流程
- GatewayClassPathWarningAutoConfiguration 作用检查是否配置我们webflux依赖。
- GatewayAutoConfiguration 加载了我们Gateway需要注入的类。
- GatewayLoadBalancerClientAutoConfiguration 网关需要使用的负载均衡,Lb//jarye-member// 根据服务名称查找真实地址
- GatewayRedisAutoConfiguration 网关整合Redis整合Lua实现限流
- GatewayDiscoveryClientAutoConfiguration 服务注册与发现功能
- 客户端向网关发送Http请求,会到达DispatcherHandler接受请求,匹配到RoutePredicateHandlerMapping。
- 根据RoutePredicateHandlerMapping匹配到具体的路由策略。
- FilteringWebHandler获取的路由的GatewayFilter数组,创建GatewayFilterChain处理过滤请求
- 执行我们的代理业务逻辑访问。
Spring Cloud Gateway的源码流程
过滤器默认有8种,采用责任链模式关联着:
SpringCloud Gateway官方资源
源码及案例
- github.com/spring-clou…
- github.com/spring-clou…
案例
- spring.io/projects/sp…
分享资源
获取以上资源请访问开源项目 点击跳转