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

前言

使用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的实现方式。