AfterShip 亿级流量 API 网关的演进

导读：

1. AfterShip API Gateway 需要解决的问题

1.1服务治理诉求

1.2服务暴露的痛点

2. AfterShip API Gateway  整体架构

2.1 为什么选择使用 Kong

2.2 基于 Kong 改造后的 API Gateway 架构

2.3 稳定性保障实践

2.4 扩展性与易用性

3. Kong 的一些实践经验

3.1 基于 Kong 所面临的问题

3.2 Kong 配置管理和快速暴露 API

3.3 如何对 Kong 进行性能优化

 

API Gateway 是随“微服务”概念而兴起的一种架构模式，原本一个庞大的单体应用系统被拆分成许多微服务系统并行独立维护和部署，服务拆分带来的变化是 API 规模成倍增长，所以使用 API Gateway 发布和管理 API 逐渐成为一种趋势。

AfterShip 是一家业务和团队遍布全球的电商 B2B SaaS 公司，从 2012 年成立至今，AfterShip 已经与全球 800 多家物流公司，包括 Amazon、 Microsoft、 Wish、 eBay、Shopify、迪卡侬在内的 10 万家客户达成了合作，成为了连接物流公司和电商平台的桥梁，并进入了全球 200 多个国家地区。AfterShip 从成立至今，共发布了 10 多款 to B 产品和 2 款 to C 产品，并且已经初步构建完成了电商 SaaS 产品矩阵。AfterShip 系统整体基于微服务架构之上，随着越来越多新的产品发布，及其产品之间的依赖越来越多，在服务治理上也面临越来越大的挑战。在此基础上 AfterShip 期望引入统一的 API Gateway 来解决 统一鉴权、版本管理、灰度、流控、降级等一系列问题，同时也期望兼具有更好的扩展能力以应对特殊定制的需求。

AfterShip 最终选型使用 Kong 作为 API Gateway 方案。业务研发人员通过配置，即可简单对外开放功能和数据，无需在每个业务系统都实现通用的 API 管理功能，能更聚焦在业务逻辑本身。下面将进一步介绍 AfterShip API Gateway 的诞生和演进过程。如何兼顾效率和稳定性，平衡功能复杂性和系统性能，并向云原生架构进行演进。

1. AfterShip API Gateway 需要解决的问题

1.1 服务治理诉求

基于微服务的架构，降低了服务的耦合度，但也增加了服务管理的难度。基于这样的架构考虑，有一个全局的入口来统一管理这些服务的诉求就越来越大。

在业务发展的早期，AfterShip 的鉴权、流控等基础能力是在每个业务服务中单独实现，但是随着业务的不断发展及其更多新的业务产品的出现，系统面临越来越大的挑战。作为服务全球客户的电商 SaaS 公司，安全、合规及其隐私保护方面一直被我们高度重视。我们通过了 ISO 27001 认证体系，并且也在严格遵循 GDPR 和 CCPA 相关的规范要求。我们需要有更好的机制来统一管理 API，在更好服务业务的同时，也尽可能多的规避潜在的安全风险。

 注:引用自（https://github.com/Kong/kong）

1.2 服务暴露的痛点

公司的第一款产品 AfterShip 于 2012 年正式发布上线，随后陆续发布了 10 多款产品，to B 和 to C 的产品均包括在内。系统也经历多次的迭代演变，同时也由于有一些历史原因，整体的的服务管理方式不太统一。

南北流量

 

早期因为历史包袱的问题，南北流向的服务暴露的管理方式不太统一：

• 一开始使用 GCE Ingress Loadbalancer 暴露服务，但功能较单一，基本上就是 7 层透明代理，没法做一些 Rewrite、Ratelimit 等策略；

• 部分服务使用 Nginx Ingress 暴露服务，解决一些特殊需求。同时通过 Nginx SideCar 的方式做 SSO 等鉴权，对不同 OpenAPI 的场景，也是由不同的业务方自己做鉴权。比如对现有一些服务࿰