为什么要用Gateway
有一个章节描述到为什么需要Gateway 代替 客户端直接访问微服务子系统,其中提到一个问题:
What happens when the application evolves and new microservices are introduced or existing microservices are updated?
当前微服务发生变化，或者随着整个应用系统不断进化(evolves)或者引入的子系统时,客户端怎么办?就是一个噩梦。
如果没有Gateway, 有如下缺点:
-
Coupling 耦合
客户端与微服务各个子系统耦合度太高。 -
Too many round trips 请求响应之间的往返过多
请求过多，会带来严重的响应迟滞 -
Security issues 安全问题
如果没有Gateway 意味着所有子系统都需要暴露出来，存在安全隐患。当然你也可以为每个子服务系统做一个校验，但请参考第四点。 -
Cross-cutting concerns 横切关注点(或像下文叫的 Gateway Offloading )
如果需要做一些身份校验、权限验证等的验证时，如果没有Gateway ,则每个微服务都需要自己做一层校验，而实际上这一层校验跟其他子系统做的逻辑基本都一样，增加了这个逻辑的冗余。有Gateway 就可以把这些逻辑抽取出来。
Gateway模式
A. 单节点Gateway模式
Single Gateway.png
意思是单一个Gateway去服务不同的产品线客户端，例如商品App及商品运营后台同时使用同一个Gateway。
your API Gateway service will be growing and evolving based on many different requirements from the client apps.
it could be pretty similar to a monolithic application or monolithic service
随着业务需求不断地增长，整个应用系统不断进化膨胀,你会发现单个Gateway越来越像 monolithic 单应用系统。（单应用系统缺点就不多说了，其中一个缺点就是要改动一个功能则要重启整个服务)
B. 多节点Gateway模式
Multiple Gateway.png
一个 产品线客户端都有对应一个定制的Gateway。
例如一个商品App对应一个Gateway, 一个商品运营后台对应一个Gateway。
the API Gateways should be segregated based on business boundaries and the client apps and not act as a single aggregator for all the internal microservices.
每个Gateway应该按照不同的业务边界进行划分，而不是把所有业务需求都放在同一个Gateway,这样会让这一个单一的Gateway变成一个聚合服务。
Gateway 功能
-
Reverse proxy or gateway routing 反向代理及路由
可以参考一下nginx 的反向代理 -
Requests aggregation 请求聚合
将多个对子系统请求聚合在一起 -
Cross-cutting concerns or gateway offloading 横切关注点
主要是将共同的功能抽象出来，有如下功能:- Authentication and authorization 认证及授权
- Service discovery integration 服务发现
- Response caching 缓存
- Retry policies, circuit breaker, and QoS 重试策略、熔断、QoS(服务质量监控)
- Rate limiting and throttling 限流
- Load balancing 负载均衡
- Logging, tracing, correlation 聚合日志、系统跟踪
- Headers, query strings, and claims transformation
- IP whitelisting 白名单
附:
https://www.cnblogs.com/savorboard/p/api-gateway.html -- 另外一篇比较直白的国内文章
里面提到双重Gateway :
第一层Gateway 主要负责 安全、认证、分流、监控、日志
第二层Gateway, 聚合Gateway 主要负责超时、缓存、重试、熔断、查询聚合。
双重Gateway.png
网友评论