微服务化分布式机器学习系统之API网关一

Posted 2021-04-21 筱凡小筑

前言

使用nginx转发访问到后端服务的方式是当前互联网企业的主流。 但是随着业务的发展，nginx配置会越来越复杂，但又没有统一的管理，到最后只能发展成各业务自己负责自己的服务。不但会造成功能重复开发，浪费开发人员的时间和精力，还会因安全意识的缺乏导致服务器被入侵的安全事故。

 

API 网关，即API Gateway，是大型分布式系统中，为了保护内部服务而设计的一道屏障，可以提供高性能、高可用的 API托管服务，从而帮助服务的开发者便捷地对外提供服务，而不用考虑安全控制、流量控制、审计日志等问题，统一在网关层将安全认证、流量控制、黑白名单、监控、负载均衡、缓存和静态响应处理等实现。API Gateway作为微服务重要的中间件，能让搭建一个新的应用服务变得简单、快捷、高效，开发者将精力更多放在和业务紧密相关的工作上。

 

选型

当然，不存在包治百病的技术选型，只有最贴合企业业务的架构。API Gateway有如下优缺点。

优点：

1、解耦作用：它封装了应用的内部结构，客户端直接和网关通信，而不必调用特定的服务。

2、提供给每种客户端特定优化的API。

3、减少请求环路、简化客户端逻辑。比如说，API Gateway使得客户端用一次请求就可以从多个service处获取数据。

缺点：

1、必须被开发、部署和管理成一个高度可用的组件，也有成为开发瓶颈的危险。

2、为了暴露出每个微服务的，开发者必须更新API网关。

 

目前业界也有多款成熟的API网关可用:Kong、Zuul、Traefik等等。

 

Kong

性能高、稳定，可以通过插件扩展已有功能，这些插件（使用lua编写）在API请求响应循环的生命周期中被执行。有大量可用的插件(限流、鉴权等等)可以开箱即用。目前，Kong在Mashape管理了超过15,000个API，为200,000开发者提供了每月数十亿的请求支持。

问题：只支持Http协议；二次开发，自由扩展困难；提供管理API，缺乏更易用的管控、配置方式。另外，Kong是基于Nginx+Lua的，从公司的角度比较难于找到能去维护这种架构产品的人，需要评估当前公司是否有这个能力去维护这个产品。

OpenResty

高性能、高扩展性、高可靠性、低内存消耗、单机支持 10 万以上的并发连接，支持热部署，以及使用较自由的 BSD 许可协议。

问题：适合有较强研发团队，自主开发企业自己的API网关。

Zuul

Netflix开源，功能丰富，使用JAVA开发，易于二次开发；需要运行在web容器中，如Tomcat。

问题：缺乏管控，无法动态配置；依赖组件较多；处理Http请求依赖的是Web容器，性能不如Nginx。

Traefik

Go语言开发；轻量易用；提供大多数的功能：服务路由，负载均衡等等；提供WebUI。

问题：二进制文件部署，二次开发难度大；UI更多的是监控，缺乏配置、管理能力。

Tyk

Tyk是一个开放源码的API网关，它是快速、可扩展和现代的。Tyk提供了一个API管理平台，其中包括API网关、API分析、开发人员门户和API管理面板。Try 是一个基于Go实现的网关服务。

问题：Tyk只能支持HTTP REST API，不支持SOAP或者RPC等其他服务。

 

注：以上 API 网关都缺少超时，熔断，重试，聚合查询等功能。

 

Istio Gateway

分布式可定制可扩展的，组件是可拔插的。以 sidecar 形式运行来拦截所有进出服务的流量，同时对流量加以控制（欲知后事如何,且听下周分解）。

 

如何设计一个好的企业级API网关？

1、功能需求

1）API 生命周期管理功能：

覆盖 API 的配置、测试、发布的整个生命周期管理，便捷的CI\CD、版本管理，支持热升级和快速回滚。

 

2）安全防护功能：

API 请求到达后端服务，需要经过严格的权限认证。支持waf、前后端token核对、算法签名、 SSL 加密。

 

3）流量控制功能：

可控制单位时间内 API 允许被调用流量大小。支持对 API 限流，可以根据 API的重要程度来配置不同流量，从而保障重要业务的稳定运行；支持用户、应用和黑白名单，可以根据用户的重要性来配置限流；流量控制粒度：分钟、小时、天。

 

4）ABTest和灰度发布：

在实际开发中经常涉及到项目的升级和改动效果的验证，需要并行运行两个项目一段时间进行数据比对和校验，待没问题后再进行上线。

 

5）监控告警功能：

提供实时、可视化的 API 监控，包括：调用量、调用方式、响应时间、错误率，能够清楚的了解 API 的运行状况和用户的行为习惯。支持自定义报警规则，来针对异常情况进行报警，降低故障处理时间。提供可订阅的数据分析报表和智能分析。

 

6）协议转换：

对外将其适配为HTTP接口，对内仍为RPC调用，这无疑可以极大的提升系统整体性能，同时不用约束上游系统的实现方式。

 

2、高可用设计

1） 无状态设计原则。

网关层为保证高可用、易于伸缩和快速启动，需要设计成无状态。

 

2）防止雪崩

集群部署，任务一台服务器的crash都不影响整体系统的可用性。采取熔断模式，当某个目标服务调用阻塞，熔断该服务的调用，对于后续调用请求，不在继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。

 

3）扩展性设计

生产需求总是在变化的，一个功能在一段时间之后就会跟实际情况脱节，因此需要思考API网关如何更新维护的问题，比较理想的是通过插件的形式进行插拔。

 

4）API管理与动态发布设计

对服务管理来说，有前端与后端的服务管理。通过配置前后端服务映射的方式，解耦网关层对服务层的依赖。当服务层的API（例如服务名、参数名等）发生变化时，只需调整映射关系，无需对网关层的代码进行调整。网关层按照映射，自动装配服务层API所需要的数据格式。这样，网关层团队与服务层团队可以相互不受干扰地开发各自的服务。

 

随着互联网业务的飞速发展，系统动辄要支持亿级流量压力，架构设计不断面临新的挑战。海量系统设计、容灾、健壮性，架构师要考虑多方面的需求做出权衡。本章为API网关的概念性介绍，下周将深入Istio源码介绍Istio Gateway的实现方式。