微服务化分布式机器学习系统之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的实现方式。

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20181202A17V3W00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券