诺诺清蔓

简单,美好,奋发

一个对技术追求的Java萌妹子


API GateWay(网关)那些儿事

前言:现在越来越多的技术团队开始尝试采纳微服务架构进行产品开发。而基于微服务架构后后端服务通常而言是动态的,为了简化前端的调用逻辑,通常会引入API Gateway作为轻量级网关,同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度,这边文章我们就来聊聊API Gateway的那些事。
关键字:API Gateway, Spring Cloud Zuul, NginxConsulConsul-Template

为什么需要API Gateway

  • 简化客户端调用复杂度

在微服务架构模式下后端服务的实例数一般是动态的,对于客户端而言如何发现这些动态改变的服务实例的访问地址信息?因此在基于微服务的项目中为了简化前端的调用逻辑,通常会引入API Gateway作为轻量级网关,同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。

  • 数据裁剪以及聚合

通常而言多余不同的客户端对于显示时对于数据的需求是不一致的,比如手机端或者Web端又或者在低延迟的网络环境或者高延迟的网络环境。

因此为了优化客户端的使用体验,API Gateway可以对通用性的响应数据进行裁剪以适应不同客户端的使用需求。同时还可以将多个API调用逻辑进行聚合,从而减少客户端的请求数,优化客户端用户体验

  • 多渠道支持

当然我们还可以针对不同的渠道和客户端提供不同的API Gateway,对于该模式的使用由另外一个大家熟知的方式叫Backend for front-end, 在Backend for front-end模式当中,我们可以针对不同的客户端分别创建其BFF

  • 遗留系统的微服务化改造

对于系统系统而言进行微服务改造通常是由于原有的系统存在或多或少的问题,比如技术债务,代码质量,可维护性,可扩展性等等。API Gateway的模式同样适用于这一类遗留系统的改造,通过微服务化的改造逐步实现对原有系统中的问题的修复,从而提升对于原有业务响应力的提升。通过引入抽象层,逐步使用新的实现替换旧的实现。

使用Zuul实现API网关

Spring Cloud的Zuul组件提供了轻量级网关的功能支持,通过定义路由规则可以快速实现一个轻量级的API网关

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
zuul:
ignoredPatterns: /api/auth
sensitive-headers: "*"
ignoreLocalService: true
retryable: false
host:
max-total-connections: 500
routes:
service01:
path: /service01/**
serviceId: service01
stripPrefix: true
thirdpart:
pateh: /thirdpart/**
url: http://thirdpart.api.com

同时除了通过serviceId关联已经注册到Consul的服务实例以外,我们也可以通过zuul直接定义实现对已有服务的直接集成。

这里我们就不过多介绍Zuul的细节,在实际使用中我们会发现直接使用Zuul会存在诸多问题,包括:

  • 性能问题:当存在大量请求超时后会造成Zuul阻塞,目前只能通过横向扩展Zuul实例实现对高并发的支持;
  • WebSocket的支持问题: Zuul中并不直接提供对WebSocket的支持,需要添加额外的过滤器实现对WebSocket的支持;

    为了解决以上问题,可以通过在Zuul前端部署Nginx实现对Zuul实例的反向代理,同时适当的通过添加Cache以及请求压缩减少对后端Zuul实例的压力。

实现Nginx的动态代理

通过Nginx我们可以实现对多实例Zuul的请求代理,同时通过添加适当的缓存以及请求压缩配置可以提升前端UI的请求响应时间。这里需要解决的问题是Nginx如何动态发现Zuul实例信息并且将请求转发到Zuul当中。

consul-template可以帮助我们解决以上问题,consul-template是一个命令行工具,结合consul实现配置文件的动态生成并且支持在配置文件发生变化后触发用户自定义命令。

我们使用了如下的Dockerfile用于构建我们的Nginx服务

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
FROM nginx:1.11.10
ADD consul-template /usr/local/bin
RUN mkdir /etc/consul-templates
# 模板文件
ADD nginx.tpl /etc/consul-templates/nginx.tpl
ENV CT_FILE /etc/consul-templates/nginx.tpl
ENV NX_FILE /etc/nginx/conf.d/default.conf # 目标文件
ENV SERVICE identity # 注册在Consul的服务名
COPY dist /usr/share/nginx/html
RUN mkdir -p /data/cache
CMD /usr/sbin/nginx -c /etc/nginx/nginx.conf \
& CONSUL_TEMPLATE_LOG=debug \
consul-template -consul-addr=$CONSUL -template "$CT_FILE:$NX_FILE:/usr/sbin/nginx -s reload";

Nginx配置模板文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# nginx.tpl
upstream api_server {
least_conn;
{{range service "identity"}}
server {{.Address}}:{{.Port}};
{{else}}server 127.0.0.1:9191;{{end}}
}
server {
listen 80;
server_name localhost;
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}
location /api {
proxy_pass http://api_server;
}
}

其中

1
2
3
4
5
6
upstream api_server {
least_conn;
{{range service "identity"}}
server {{.Address}}:{{.Port}};
{{else}}server 127.0.0.1:9191;{{end}}
}

会根据当前consul中注册的所有identity服务实例进行模板渲染,并且当配置文件内容发生变化后调用nginx -s reload重新加载Nginx配置从而实现对于后端服务实例的动态代理。

1
2
3
CMD /usr/sbin/nginx -c /etc/nginx/nginx.conf \
& CONSUL_TEMPLATE_LOG=debug \
consul-template -consul-addr=$CONSUL -template "$CT_FILE:$NX_FILE:/usr/sbin/nginx -s reload";

其它的一些优化建议

启用Nginx的Gzip可以对服务器端响应内容进行压缩从而减少一定的客户端响应时间

1
2
3
4
5
gzip on;
gzip_min_length 1k;
gzip_buffers 4 32k;
gzip_types text/plain application/x-javascript application/javascript text/xml text/css;
gzip_vary on;

缓存图片以及其它静态资源可以减少对Zuul实例的请求量

1
2
3
4
5
6
7
8
9
10
11
12
13
proxy_buffering on;
proxy_cache_valid any 10m;
proxy_cache_path /data/cache levels=1:2 keys_zone=my-cache:8m max_size=1000m inactive=600m;
proxy_temp_path /data/temp;
proxy_buffer_size 4k;
proxy_buffers 100 8k;
location ~* (images) {
proxy_pass http://api_server;
# cache setting
proxy_cache my-cache;
proxy_cache_valid 200;
}

如果需要通过Nginx实现对Websocket的代理可以添加一下配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
location /sockjs {
proxy_pass http://api_server;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# WebSocket support (nginx 1.4)
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
# !!!Support Spring Boot
proxy_pass_header X-XSRF-TOKEN;
proxy_set_header Origin "http://localhost:4000";
}
最近的文章

在Spring Cloud中实现降级之权重路由和标签路由

前言 限流、降级、灰度是服务治理的一个很重要的功能。本文参考Spring Cloud中国社区的VIP会员-何鹰的博客-整理Dubbo自带服务降级、限流功能,spring cloud并没有提供此功能,只能由我们自行实现。这里的限流、降级、灰度都是针对服务实例级别,并不是整个服务级别,整个服务级别可以通过实例部署数量来实现。 限流降级设计场景服务A,部署了3个实例A1、A2、A3。spring cloud默认客户端负载均衡策略是采用轮询方式,A1、A2、A3三个实例流量均分,各1/3。如果这个时候需要将服务A由1.0版升级至2.0版,我们需要做的步骤是:将A1的流量降为0,柔性下线,关闭A1实例并升级到2.0,将A1流量提升为10%观察2.0线上运行情况,如果情况稳定,则逐步开放流量至不限制及1/3。依次在A2,A3上执行上述操作。在上述步骤中,我们想让特别的人使用2.0,其他人还是使用1.0版,稳定后再全员开放。 …

Spring Cloud Ribbon 继续阅读
更早的文章

Spring Cloud Zuul的URL转发和路由规则

摘要:最近开了《跟我学Spring Cloud》系列教程,由于最近比较忙,因此更新较慢。由于自己最近在研究基于Netty名为Janus的网关中间件分为janus-Server端和janus-console管控端,纳管Spring Cloud实现市面上网关85%以上的功能,将在2017年5月6号Spring Cloud中国社区北京技术沙龙分享。顺便抽时间把Spring Cloud Zuul相关的东西整理比较。在本篇文章中Spring Cloud的版本更换为Dalston.RELEASE,Spring Boot的版本为1.5.2.RELEASE。 Spring Cloud Zuul Spring Cloud Zuul 通过与 Spring Cloud Eureka 进行整合,将自身注册到 Eureka Server中,与Eureka,Ribbon,Hystrix等整合,同时从 Eureka 中获得了所有其它微服务的实例信息。这样的设计通过把网关和服务治理整合到一起,Spring Cloud Zuul可以获取到服务注册信息,结合Ribbon,Hystrix等更好的实现路由转发,负载均衡等功能。想了解更多的内容,可以参考下面的中英文对照翻译文档。或者查看官网文档。 Spring Cloud Zuul中英文对照翻译① Spring Cloud Zuul中英文对照翻译② Spring Cloud Zuul中英文对照翻译③ …

Spring Cloud Zuul 继续阅读