关于运维:API-网关的功能用途及实现方式

1. API 网关诞生背景

前言

API 经济生态链曾经在寰球范畴笼罩，绝大多数企业都曾经走在数字化转型的路线上，API 成为企业连贯业务的外围载体，并产生微小的盈利空间。快速增长的 API 规模以及调用量，使得企业 IT 在架构上、模式上面临着更多的挑战。

API 是什么

API 网关是一个服务器，是零碎的惟一入口。从面向对象设计的角度看，它与外观模式相似。API 网关封装了零碎外部架构，为每个客户端提供一个定制的 API。它可能还具备其它职责，如身份验证、监控、负载平衡、缓存、申请分片与治理、动态响应解决。API 网关形式的外围要点是，所有的客户端和生产端都通过对立的网关接入微服务，在网关层解决所有的非业务性能。通常，网关也是提供 REST/HTTP 的拜访 API。服务端通过 API-GW 注册和治理服务。

1. API 凋谢数量一直减少

毋庸置疑，随着企业的数据化停顿，微服务革新，不同畛域的 API 层出不穷，早在 2014 年 ProgrammableWeb 便预测 API 矢量可达到 100,000 到 200,000，并会一直增长。API 开发数量的减少给边缘系统带来机会，也随即演变了 API 网关的呈现。大规模的 API 管理系统成为外围的发展趋势。

2. API 服务平台多样化

最后的 API 次要针对不同单体利用的网络单元之间信息交互，现已演变到服务间疾速通信。随着人工智能 EI，IOT 的一直演进，依赖 API 的平台不断更新，如 Web，Mobile，终端等，将来将会呈现更多的服务体系。包含不限于：

• 浏览器
• IOS
• Android
• macOS
• Windows
• Linux
• IOT
• 其余挪动端
• 小程序
• 终端设备（如智慧批发、工业的终端等）
• ……

3. 逐渐替换原有企业的服务模式，API 即商品

卖计算，卖软件，卖能力，最终的企业的销售模式会逐渐转变，能力变现，开释数据价值，依靠不同的 API 治理平台发明新的盈利。

API 网关诞生背景

随着 API 的整体趋势倒退，每个期间都面临着不同的挑战，架构也随之变动，具体如下图：

1. 1960-1980：阿帕网、ATTP、TCP
2. 1980-1990：点对点
3. 1990-2000：消息中间件、ESB（企业服务总线，Enterprise service bus），SOA（面向服务的架构）
4. 2000 至今：Integration as a service，RESTful services，API 治理，云上编排

从最原始的“传输协定通信”->“简略的接口集成”->“消息中间件”->“规范 REST”，能够看到 API 的倒退更趋向于简洁，集成，规范化，这也促使更多的零碎边界组件不断涌现，在承载了万亿级的 API 经济的背景下，API 网关应运而生。

如果没有适合的 API 管理工具，API 经济不可能顺利开展。同时提出了对于 API 管理系统的生命周期定义：planning（布局）, design（设计），implementation（施行），publication（公布），operation（运维）, consumption（生产）, maintenance（保护）and retirement of APIs（下架）

如果没有适合的 API 管理工具，API 经济不可能顺利开展。同时提出了对于 API 管理系统的生命周期定义：planning（布局）, design（设计），implementation（施行），publication（公布），operation（运维）, consumption（生产）, maintenance（保护）and retirement of APIs（下架）

— Magic Quadrant for Full Life Cycle API Management，Gartner, 2016-10-27

2. API 网关外围性能

• API 生命周期治理

  • planning（布局）
  • design（设计）
  • implementation（施行）
  • publication（公布）
  • operation（运维）
  • consumption（生产）
  • maintenance（保护）
  • retirement（下架）

• API 网关根底性能

  • 认证
  • 鉴权
  • 服务发现和集成
  • 负载平衡
  • 日志
  • 链路追踪
  • 监控
  • 重试
  • 限流
  • QoS
  • 熔断器
  • 映射
  • 缓存
  • Header、query 字符串 等 本义
  • API 文档
  • API 测试
  • SDK 生成
• API 多版本、多环境治理
• 插件
• API 集中式 metrics、logging、tracing 治理

• 平安

  • HTTPS
  • IP 黑白名单

• 高可用

  • 可热重启
• 高性能

• 可扩展性

  • 无状态横向扩大

3. API 网关的用处

OpenAPI

企业须要将本身数据、能力等作为开发平台向外凋谢，通常会以 rest 的形式向外提供。最好的例子就是淘宝开放平台、腾讯公司的 QQ 开发平台、微信开放平台。

Open API 开放平台必然波及到客户利用的接入、API 权限的治理、调用次数治理等，必然会有一个对立的入口进行治理，这正是 API 网关能够发挥作用的时候。

微服务网关

在微服务架构中，有一个组件能够说是必不可少的，那就是微服务网关，微服务网关解决了负载平衡，缓存，路由，访问控制，服务代理，监控，日志等。

API 网关在微服务架构中正是以微服务网关的身份存在。

API 中台

上述的微服务架构对企业来说有可能施行上是艰难的，企业有很多遗留零碎，要全副抽取为微服务改变太大，对企业来说老本太高。

然而因为不同零碎间存在大量的 API 服务相互调用，因而须要对系统间服务调用进行治理，清晰地看到各零碎调用关系，对系统间调用进行监控等。

API 网关能够解决这些问题，咱们能够认为如果没有大规模的施行微服务架构，那么对企业来说微服务网关就是企业的 API 中台。

4. API 网关的价值

通过 API 网关，能够封装后端各种服务，以 API 的模式，提供给各方应用。API 网关产品的劣势总结如下：

• API 全生命周期治理：帮助开发者轻松实现 API 的创立、保护、公布、监控等整个生命周期的治理。
• 丰盛的服务治理能力：反对 API 限流，参数校验，元数据保护，SDK 生成，批量操作等能力，帮助开发者高效治理服务。
• 可察看性：通过 API 网关，反对对调用次数，前后端谬误次数等丰盛监控指标的可视和告警能力；通过全面的监控告警，保障用户服务的可用性。
• 可经营性：反对 企业 OpenAPI 定价，账单等经营性能
• 服务平安：通过接入多种认证形式，确保用户 API 的拜访安全性；通过严格的流量管制，防止用户服务的过载。
• 前后端业务解耦
• 多类型后端买通

5. API 网关的实现形式

支流 API 网关

• Istio（以及最新出的 Envoy Gateway)
• Linkerd
• NGINX 及其商业版
• KONG
• Traefik
• APISIX
• RedHat 3scale
• Netflix Zuul
• Spring Cloud Gateway
• Amazon API Gateway
• 阿里云 API 网关（其最新开源的 Higress 是基于 Envoy Gateway 的）
• 腾讯云 API 网关
• MuleSoft

OpenAPI

对于定位 OpenAPI 平台的 API 网关，目前只能抉择业余的 API 网关作为解决方案。

微服务网关

对于定位为「微服务网关」的 API 网关，业务有多种实现形式：

Service Mesh

典型的如 Istio，架构如下：

通用反向代理

基于 NGINX 或 NGINX + LUA + OpenResty 的实现。典型如：

• Nginx 及其 商业版

  • NGINX Controller（API 治理、App 交付）
  • NGINX Plus（API Gateway，负载平衡，仪表板）
  • NGINX Ingress Controller
  • NGINX Service Mesh
• KONG
• Traefik
• 3scale

API 网关框架

• Netflix Zuul，zuul 是 spring cloud 的一个举荐组件
• Spring Cloud Gateway

私有云解决方案

其实私有云的解决方案也是基于以上计划的定制化开发并产品化后公布到私有云上，支流的也是基于：NGINX + LUA + OpenResty, 或者最新的可能是基于 Istio Gateway 的实现

• Amazon API Gateway
• 阿里云 API 网关
• 腾讯云 API 网关

其余计划

• 基于 Netty、非阻塞 IO 模型。
• 基于 Node.js 的计划。这种计划是利用了 Node.js 的非阻塞的个性。
• 基于 Java，如 MuleSoft

三人行, 必有我师; 常识共享, 天下为公. 本文由东风微鸣技术博客 EWhisper.cn 编写.