一 为什么要使用微服务网关


不同的微服务网关一般都会有不同的网络地址,而外部客户端(例如手机APP)可能需要调用多个服务的接口才能完成一个业务需求。例如一个电影购票的手机APP,可能会调用多个微服务的接口,才能完成一次购票的业务流程,如下图:




微服务 多网关_微服务 多网关


如果让客户端直接与各个微服务通信,会有以下问题:


1 客户端多次请求不同的微服务,增加了客户端的复杂性。


2 存在跨域请求,在一定的场景下处理相对复杂。


3 认证复杂,每个微服务都需要独立认证。


4 难以重构,随着项目的迭代,可能需要重新划分微服务。例如,可能将多个微服务合并成一个或者将一个微服务拆分成多个。如果客户端直接与微服务通信,那么重构将会很能实施。


5 某些微服务可能使用了防火墙/浏览器不友好的协议,直接访问会有一定困难。


以上问题可借助微服务网关解决。微服务网络是介于客户端和服务端之间的中间层,所有的外部请求都会先经过微服务网关。使用微服务网关后的架构如下:



微服务 多网关_HTTP_02


如上图,微服务网关封装了应用程序的内部结构,客户端只须跟网关交互,而无须直接调用特定微服务的接口。这样开发就可以得到简化。不仅如此,使用微服务网关还有以下优点:


1 易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析。


2 易于认证。可在微服务网关上进行认证,然后再将请求转发到后端的微服务,而无须在每个微服务上进行认证。


3 减少了客户端与各个微服务之间的交互次数。



二 Zuul简介


Zuul是Netflix开源的微服务网关,它可以和Eureka、Ribbon、hystrix等组件配合使用。Zuul的核心是一系列过滤器。这些过滤器完成以下功能:


1 身份认证和安全:识别每个资源的验证要求,并拒绝那些与要求不符的请求。


2 审查与监控:在边缘位置追踪有意义的数据和统计结果,从而带来精确的生产视图。


3 动态路由:动态地将请求路由到不同的后端集群。


4 压力测试:逐渐增加指向集群的流量,以了解性能。


5 负责分配:为每一种负载类型分配对应容量,并弃用超出限定值的请求。


6 静态响应处理:在边缘位置直接建立部分响应,避免其转发到内部集群。


7 多区域弹性:跨越AWS Region进行请求路由,旨在实现ELB(Elastic Load Blancing)使用的多样化,以及让系统的边缘更贴近系统的使用者。


Spring Cloud对Zuul进行了整合与增强。目前,Zuul使用默认HTTP客户端是Apache HTTP Client,也可使用RestClient或okhttp3.OkHttpClient。如果想要使用RestClient,可以设置ribbon .restclient.enabled=true;想要使用okhttp3.OkHttpClient,可以设置ribbon.okhttp.enabled=true。