Web Gateway

设计的真正价值在于输出公共的原则和标准

API 网关杂记

微服务最近很火，一些公司暴露API供用户使用，按量或调用次数计费来获得收益。

API网关作用

类似一个组织内运行服务的保安部门。

• 统一的认证和授权
• 请求转发（负载均衡）
• 请求调用限流（防止系统过载和预防DDos攻击）
• 协议转换 HTTPS(SSL/TLS 流量)外部请求 -> 非加密Plain HTTP
• 处理服务内部错误(防止异常栈信息泄露)
• 请求响应合并（客户端发送一个请求，网关发起一堆请求进行响应合并）
• 请求统一化访问日志（因为网关是请求同一访问入口，非常方便）
• 服务发现（高级功能，基于服务注册中心进行请求动态分发）
• 告警
• 清晰的Rest API(用于实例启动注册，可以基于网关做管理UI)

你可以看到原来应用访问控制全部都在网关做了。

1. API 网关 & DevOps

当然部分遵循DevOps规范的公司，开发微服务。那么微服务API就是微服务之间交互的语言，进行CI/CD的时候，顺便就会将服务注册到API网关上。

API网关的部署模式

来源：Choosing the Right API Gateway Pattern for Effective API Delivery

1. 单体网关（edge gateway）

全部功能都在上做单体网关，一般南北流量（外部->服务）优化度较高，东西流量（服务之间）优化度感人。

2. 双层网关

根据单体网关的特点，我们发现只有认证之后，负载均衡等高级功能才有意义，于是基础的功能放到第一层网关去做，第二层做剩下的功能。

第一层：

• SSL/TLS termination
• Authentication
• Centralized logging of connections and requests
• Tracing injection

第二层：

• Authorization
• Service discovery
• Load balancing

这种部署模式有个缺点，分离度不高。团队和团队之间相互影响。

3. 微服务网关

既然大家相互影响，那就各自用各自的呗。

网关规则是团队自治的，不过不是完全自由，需要满足统一的接入规范（最好是每个微服务网关都是一个实例，由自动化软件去管理转发规则，安全限制等）。

这里可以引入API管理规范 （API management）,管理微服务网关API的整个声明周期，包括API的定义与发布，性能监控，调用情况等。

网关评测指标

指标	单位	说明
并发量		同时在线用户数量
请求延迟	ms	用户请求发起到收到响应的RTT时间
平均响应时间	ms	平均响应时间
吞吐量	req/s	每秒完成请求处理次数
功能支持	-	日志，认证，监控等支持能力
兼容性	-	硬件兼容情况
资源占用	-	CPU与内存在相同负载下的占用情况

网关功能考虑方面

1. 服务发现

服务发现的实现方式一般做法是使用注册中心(比如etcd,nacos,zookeeper,Eureka), 请求发送到网关，网关从注册中心(registry)获取实例信息，根据LB算法进行请求路由。

从注册中心拿到的实例列表需要进行筛选，目的是避免请求被路由到不健康的实例。可以通过健康检查来辅助筛选。

健康检查分为主动和被动两种方式。一种是周期性巡检，一种是请求到来时再探测。一般可以让用户设置如下参数

参数	-
周期	多长时间检查一次（仅主动）
成功阈值	请求多少次就认为实例健康
失败阈值	请求多少次就认为实例不健康
超时时间	允许最大的请求响应时间
成功响应状态码	比如HTTP 2xx
失败响应状态码	比如HTTP 5xx ,4xx
重试次数	-

2. 可扩展

不论你的核心做的性能如何的好，为了适应复杂的业务需求，都要为自定义逻辑留下口。更准确的来说，整个请求的周期，包括路由规则匹配之前，路由成功匹配之后，路由转发前，路由转发响应收到后都要留下接口。

开源社区我看使用的都是插件机制，就是让用户自己用lua脚本实现一个SPI函数。

Phase	名字
BEFORE_ROUTE	路由规则匹配之前
ROUTE_MATCH	路由成功匹配之后
BEFORE_ROUTE	路由转发前
AFTER_ROUTE	路由转发响应收到后

3. 公共Rest API

提供如Rest API这种开放接口能够被其他应用调用。这点也很重要，这可以使得更多系统如CI/CD，监控，告警系统etc.的接入方式清晰而一致。

4. 网关服务的高可用性

网关可以保证其后面的服务的高可用性，那么网关的高可用性怎么保证？

4.1 硬件LB

硬件LB背后挂载多个无状态nginx实例。这种方式单点故障也是存在的，不过可以保证可以把这种类型的锅甩给运维（手动狗头）。

4.2 VIP+KeepAlived

主从模式，VIP永远在主节点。当主节点失效，失效转移，将VIP转移到备节点。不过这是所有高可用服务的通用解决方式。
优点： 解决了单点故障。
缺点是：无法线性扩展，同时只有一个实例在用。