微服务API网关

为什么出现网关

微服务的架构体系中，可以简单的看做是一个大应用拆分为多个小应用，小应用可以自成体系，可以拥有自己的数据库、框架甚至于语言等等，各个小应用一般通过Rest接口的形式被第三方、H5或者APP去调用。这个时候必然会存在一种情况，某些页面需要多个服务组合才能得到用户需要的信息。举个栗子：

在电商系统中，查看商品详情页，这个商品详情页包含商品的详情，价格，库存，评论等，这些数据对于后端来说位于不同的微服务系统之中，后台的系统是这样来拆分服务的：

• 商品服务：负责提供商品的标题，描述，规格等。
• 营销服务：负责对产品进行定价，价格策略计算，促销价等。
• 库存服务：负责产品库存。
• 评价服务：负责用户对商品的评论，回复等。

我们不做任何处理的时候，调用的时候是这样：

该处的缺点就是前端需要调用多次服务才能拿到我们想要的数据，为了解决这个问题我们可以做一层中间的聚合层，聚合层也就是我们通常所说的BFF（Back-end for Front-end），BFF可以认为是一种适配服务，将后端的微服务进行适配（主要包括聚合裁剪和格式适配等逻辑），实现上没太大限制，能做请求转发和数据转化即可，升级以后框架是这样的，现在我们系统处于这个阶段：

这里会有两个问题

• 多个聚合层有很多跨横切面的代码是重复的，比如安全认证，日志监控，限流熔断等，随着时间的发展代码变得不可维护；
• 随着访问量、业务的增加，两个BFF层也满足不了我们的业务，需要抽象更多的BFF和采用集群部署的方式。

接下来我们再次升级我们架构，如下图：

网关的加入我们可以将所有的跨横切面的代码通通抽象到网关层，这样我们BFF层只需要关注服务适配的逻辑，另外也解决掉了之前业务单点、多节点的等问题，这个时候你可能又想，网关的部署也是单点了，这个时候你可以考虑在网关前挂一层NG或者F5，如果随着业务发展网关管理的服务越来越多，也可以将网关按照业务域进行整体的拆分。

网关作用

• 对外：提供统一的流量入口
• 对内：提供安全认证，日志监控，限流熔断等功能
• 功能：
  • 过滤：网关需要检测一些异常访问，过滤掉这些请求
  • 转发：请求转发和协议转换
  • 灰度发布：网关完全可以做到对相同服务不同版本的实例进行导流，还可以收集相关的数据
  • API聚合：使用网关可以将多个单独请求聚合成一个请求
  • 服务治理：限流、降级、熔断、负载均衡等

网关非功能性设计

功能点	描述	关键点	备注
高性能	在技术设计上，网关不应该也不能成为性能的瓶颈	无状态设计，异步非阻塞的 I/O
高可用	因为所有的流量或调用经过网关，所以网关必须成为一个高可用的技术组件，它的稳定直接关系到了所有服务的稳定	集群化，热更新
高扩展	因为网关需要承接所有的业务流量和请求，所以一定会有或多或少的业务逻辑。而我们都知道，业务逻辑是多变和不确定的，因此，我们需要支持能够通过配置执行不同的逻辑	插件化

微服务网关一般处理流程

• Pre Filter：请求被路由之前调用，身份验证
• Routing Filter：将请求路由到微服务
• Post Filter：远程调用后执行，HTTP Header、收集统计信息和指标、Response
• Error Filter：发生错误时执行

开源网关系统

• Tyk：Tyk是一个开放源码的API网关，它是快速、可扩展和现代的。Tyk提供了一个API管理平台，其中包括API网关、API分析、开发人员门户和API管理面板。Try 是一个基于Go实现的网关服务。
• Kong：Kong是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。Kong 在任何RESTful API的前面运行，通过插件扩展，它提供了超越核心平台的额外功能和服务。

参考

• 公司40k招的架构师写的API网关选型总结，就是牛逼！