在微服务架构下，服务拆分会让 API 的规模成倍增长，应用 API 网关来治理 API 逐步成为一种趋势。美团对立 API 网关服务 Shepherd 就是在这种背景下应运而生，实用于美团业务且齐全自研，用于替换传统的 Web 层网关利用，业务研发人员通过配置的形式即可对外开放性能和数据。本文将介绍美团对立 API 网关诞生的背景、要害的技术设计和实现，以及 API 网关将来的布局，心愿能给大家带来一些帮忙或者启发。
一、背景介绍
1.1 API 网关是什么？
API 网关是随着微服务（Microservice）概念衰亡的一种架构模式。本来一个宏大的单体利用（All in one）业务零碎被拆分成许多微服务（Microservice）零碎进行独立的保护和部署，服务拆分带来的变动是 API 的规模成倍增长，API 的治理难度也在日益减少，应用 API 网关公布和治理 API 逐步成为一种趋势。一般来说，API 网关是运行于内部申请与外部服务之间的一个流量入口，实现对外部申请的协定转换、鉴权、流控、参数校验、监控等通用性能。
1.2 为什么要做 Shepherd API 网关？
在没有 Shepherd API 网关之前，美团业务研发人员如果要将外部服务输入为对外的 HTTP API 接口。通常要搭建一个 Web 利用，用于实现根底的鉴权、限流、监控日志、参数校验、协定转换等工作，同时须要保护代码逻辑、根底组件的降级，研发效率绝对比拟低。此外，每个 Web 利用都须要保护机器、配置、数据库等，资源利用率也十分差。
美团外部一些业务线苦于没有现成的解决方案，依据本身业务特点，研发了业务相干的 API 网关。放眼业界，亚马逊、阿里巴巴、腾讯等公司也都有成熟的 API 网关解决方案。
因而，Shepherd API 网关我的项目正式立项，咱们的指标是为美团提供高性能、高可用、可扩大的对立 API 网关解决方案，让业务研发人员通过配置的形式即可对外开放性能和数据。
1.3 应用 Shepherd 带来的收益是什么？
从业务研发人员的角度来看，接入 Shepherd API 网关，能带来哪些收益呢？简而言之包含三个方面。
-
晋升研发效率
- 业务研发人员只须要通过配置的形式即可疾速凋谢服务接口。
- Shepherd 对立提供鉴权、限流、熔断等非业务根底能力。
- Shepherd 反对业务研发人员通过开发自定义组件的形式扩大 API 网关能力。
-
升高沟通老本
- 业务研发人员配置好 API，能够主动生成 API 的前后端交互文档和客户端 SDK，不便前后端开发人员进行交互、联调。
-
晋升资源利用率
- 基于 Serverless 的架构思维，实现 API 全托管，业务研发人员无需关怀机器资源问题。
二、技术设计与实现
2.1 整体架构
咱们先来看看 Shepherd API 网关的整体架构，如下图所示：
Shepherd API 网关的 管制面 由 Shepherd 治理平台和 Shepherd 监控核心组成。治理平台次要实现 API 的全生命周期治理以及配置下发的工作，监控核心实现 API 申请监控数据的收集和业务告警性能。
Shepherd API 网关的 配置核心 次要实现管制面与数据面的信息交互，通过美团对立配置服务 Lion 来实现。
Shepherd API 网关的 数据面 也就是 Shepherd 服务端。一次残缺的 API 申请，可能是从挪动利用、Web 利用，合作伙伴或外部零碎发动，通过 Nginx 负载平衡零碎后，达到服务端。服务端集成了一系列的根底性能组件和业务自定义组件，通过泛化调用申请后端 RPC 服务、HTTP 服务、函数服务或服务编排服务，最初返回响应后果。
上面咱们将针对这三个次要模块做具体的介绍。
2.1.1 管制面
应用 API 网关的管制面，业务研发人员能够轻松的实现 API 的全生命周期治理，如下图所示：
业务研发人员从创立 API 开始，实现参数录入、DSL 脚本生成；接着能够通过文档和 MOCK 性能进行 API 测试；API 测试实现后，为了保障上线稳定性，Shepherd 治理平台提供了公布审批、灰度上线、版本回滚等一系列平安保障措施；API 运行期间会监控 API 的调用失败状况、记录申请日志，一旦发现异常及时收回告警；最初，对于不再应用的 API 进行下线操作后，会回收 API 所占用的各类资源并期待从新启用。
整个生命周期，全副通过配置化、流程化的形式，由业务研发人员全自助治理，上手工夫根本在 10 分钟以内，极大地晋升了研发效率。
2.1.2 配置核心
API 网关的配置核心寄存 API 的相干配置信息——应用自定义的 DSL（Domain-Specific Language，畛域专用语言）来形容，用于向 API 网关的数据面下发 API 的路由、规定、组件等配置变更。
配置核心的设计上应用对立配置管理服务 Lion 和本地缓存联合的形式，实现动静配置，不停机公布。API 的配置如下图所示：
API 配置的具体阐明：
- Name、Group：名字、所属分组。
- Request：申请的域名、门路、参数等信息。
- Response：响应的后果组装、异样解决、Header、Cookies 信息。
- Filters、FilterConfigs：API 应用到的性能组件和配置信息。
- Invokers：后端服务 (RPC/HTTP/Function) 的申请规定和编排信息。
2.1.3 数据面
API 路由
API 网关的数据面在感知到 API 配置后，会在内存中建设申请门路与 API 配置的路由信息。通常 HTTP 申请门路上，会蕴含一些门路变量，思考到性能问题，Shepherd 没有采纳正则匹配的形式，而是设计了两种数据结构来存储。如下图所示：
一种是不蕴含门路变量的间接映射的 MAP 构造。其中，Key 就是残缺的域名和门路信息，Value 是具体的 API 配置。
另外一种是蕴含门路变量的前缀树数据结构。通过前缀匹配的形式，先进行叶子节点准确查找，并将查找节点入栈解决，如果匹配不上，则将栈顶节点出栈，再将同级的变量节点入栈，如果依然找不到，则持续回溯，直到找到（或没找到）门路节点并退出。
性能组件
当申请流量命中 API 申请门路进入服务端，具体解决逻辑由 DSL 中配置的一系列性能组件实现。网关提供了丰盛的性能组件集成，包含链路追踪、实时监控、拜访日志、参数校验、鉴权、限流、熔断降级、灰度分流等，如下图所示：
协定转换 & 服务调用
API 调用的最初一步，就是协定转换以及服务调用了。网关须要实现的工作包含：获取 HTTP 申请参数、Context 本地参数，拼装后端服务参数，实现 HTTP 协定到后端服务的协定转换，调用后端服务获取响应后果并转换为 HTTP 响应后果。
上图以调用后端 RPC 服务为例，通过 JsonPath 表达式获取 HTTP 申请不同部位的参数值，替换 RPC 申请参数相应部位的 Value，生成服务参数 DSL，最初借助 RPC 泛化调用实现本次服务调用。
2.2 高可用设计
Shepherd API 网关作为接入层的根底组件，高可用性始终是业务研发人员十分关怀的局部。接下来。咱们就来摸索一下 Shepherd 在高可用设计方面的实际。
2.2.1 排除性能隐患
一个高可用的零碎，预防故障的产生，首先要排除性能隐患，保障高性能。
Shepherd 对 API 申请做了全异步化解决，申请通过 Jetty IO 线程异步提交到业务解决线程池，调用后端服务应用 RPC 或 HTTP 框架的异步形式，开释了因为网络期待引起的线程占用，使线程数不再成为网关的瓶颈。下图是应用 Jetty 容器时，服务端的申请线程解决逻辑：
咱们通过域名压测网关单机的端到端 QPS，发现 QPS 在超过 2000 时，会呈现很多超时谬误，而网关的服务端负载与性能却十分充裕。调研发现，公司内其余的 Web 利用都存在这个问题，与 Oceanus 团队进行联结排查后，发现是 Nginx 与 Web 利用之间的长连接功能没有关上，且无奈配置。Oceanus 团队通过紧急排期，研发并上线长连接功能后，Shepherd 端到端的 QPS 胜利晋升到了 10000 以上。
另外，咱们对 Shepherd 服务端进行了 API 申请预热的优化，使得网关启动时能立即达到最佳性能，缩小毛刺的产生。而后，通过压测时的 CPU 热点排查，将性能瓶颈找出，缩小主链路上的本地日志打印，对申请日志进行异步化、近程化革新。Shepherd 端到端的 QPS 再次晋升 30% 以上。
在 Shepherd 服务上线稳固运行一年当前，咱们再次对性能进行优化，并且做了一次网络框架降级，将 Jetty 容器全面替换为 Netty 网络框架，性能晋升 10% 以上，Shepherd 端到端的 QPS 胜利晋升到 15000 以上。下图是应用 Netty 框架时，服务端的申请线程解决逻辑：
2.2.2 服务隔离
集群隔离
借鉴公司缓存、任务调度等成熟组件的教训，Shepherd 在设计之初，就思考了按业务线维度进行集群隔离，也反对重要业务独立部署。如下图所示：
申请隔离
服务节点维度，Shepherd 反对申请的快慢线程池隔离。快慢线程池隔离次要用于一些应用了同步阻塞组件的 API，例如 SSO 鉴权、自定义鉴权等，可能导致长时间阻塞共享业务线程池。
快慢隔离的原理是统计 API 申请的解决工夫，将申请解决耗时较长，超过容忍阈值的 API 申请隔离到慢线程池，防止影响其余失常 API 的调用。
除此之外，Shepherd 也反对业务研发人员配置自定义线程池进行隔离。具体的线程隔离模型如下图所示：
2.2.3 稳定性保障
Shepherd 提供了一些惯例的稳定性保障伎俩，来保障本身和后端服务的可用性。如下图所示：
- 流量管控：从用户自定义 UUID 限流、App 限流、IP 限流、集群限流等多个维度提供流量爱护。
- 申请缓存：对于一些幂等的、查问频繁的、数据及时性不敏感的申请，业务研发人员可开启申请缓存性能。
- 超时治理：每个 API 都设置了解决超时工夫，对于超时的申请，进行疾速失败的解决，防止资源占用。
- 熔断降级：反对熔断降级性能，实时监控申请的统计信息，达到配置的失败阈值后，主动熔断，返回默认值。
2.2.4 申请平安
申请平安是 API 网关十分重要的能力，Shepherd 集成了丰盛的平安相干的零碎组件，包含有根底的申请签名、SSO 单点登录、基于 SSO 鉴权的 UAC/UPM 访问控制、用户鉴权 Passport、商家鉴权 EPassport、商家权利鉴权、反爬等等。业务研发人员只须要简略配置，即可应用。
2.2.5 可灰度
API 网关作为申请入口，往往肩负着申请流量灰度验证的重任。
灰度场景
Shepherd 在灰度能力上，反对灰度 API 本身逻辑，也反对灰度上游服务，也能够同时灰度 API 本身逻辑和上游服务。如下图所示：
灰度 API 本身逻辑时，通过将流量分流到不同的 API 版本实现灰度能力；灰度上游服务时，通过给流量打标，分流到指定的上游灰度单元中。
灰度策略
Shepherd 反对丰盛的灰度策略，能够依照比例数灰度，也能够依照特定条件灰度。
2.2.6 监控告警
立体化监控
Shepherd 提供 360 度的立体化监控，从业务指标、机器指标、JVM 指标提供 7 ×24 小时的业余守护，如下表：
| 监控模块 | 次要性能 | |
|---|---|---|
| 1 | 对立监控 Raptor | 实时上报申请调用信息、零碎指标，负责应用层（JVM）监控、零碎层（CPU、IO、网络）监控 |
| 2 | 链路追踪 Mtrace | 负责全链路参数透传、全链路追踪监控 |
| 3 | 日志监控 Logscan | 监控本地日志异样关键字：如 5xx 状态码、空指针异样等 |
| 4 | 近程日志核心 | API 申请日志、Debug 日志、组件日志等可上报近程日志核心 |
| 5 | 健康检查 Scanner | 对网关节点进行心跳检测和 API 状态检测，及时发现异常节点和异样 API |
多维度告警
有了全面的监控体系，天然少不了配套的告警机制，次要的告警能力包含：
| 告警类型 | 触发机会 | |
|---|---|---|
| 1 | 限流告警 | API 申请达到限流规定阈值触发限流告警 |
| 2 | 申请失败告警 | 鉴权失败、申请超时、后端服务异样等触发申请失败告警 |
| 3 | 组件异样告警 | 自定义组件解决耗时长、失败率高告警 |
| 4 | API 异样告警 | API 公布失败、API 查看异样时触发 API 异样告警 |
| 5 | 健康检查失败告警 | API 心跳查看失败、网关节点不通时触发健康检查失败告警 |
2.2.7 故障自愈
Shepherd 服务端接入了弹性伸缩模块，可依据 CPU 等指标进行疾速扩容、缩容。除此之外，还反对疾速摘除问题节点，以及更细粒度的问题组件摘除。
2.2.8 可迁徙
对于一些曾经在对外提供 API 的 Web 服务，业务研发人员为了缩小运维老本和后续的研发提效，思考将其迁徙到 Shepherd API 网关。
对于一些非核心 API，能够思考应用 Oceanus 的灰度公布性能间接迁徙。然而对于一些外围 API，下面的灰度公布性能是机器级别的，粒度较大，不够灵便，不能很好的反对灰度验证过程。
解决方案
Shepherd 为业务研发人员提供了一个灰度 SDK，接入 SDK 的 Web 服务，可在辨认灰度流量后转发到 Shepherd API 网关进行验证。
灰度哪些 API、灰度百分比能够在 Shepherd 治理端动静调节，实时失效，业务研发人员还能够通过 SPI 的形式自定义灰度策略。灰度验证通过后，再把 API 迁徙到 Shepherd API 网关，保障迁徙过程的稳定性。
灰度过程
灰度前：在 Shepherd 治理平台创立 API 分组，域名配置为目前应用的域名。在 Oceanus 上，原域名规定不变。
灰度中：在 Shepherd 治理平台开启灰度性能，灰度 SDK 将灰度流量转发到网关服务，进行验证。
灰度后：通过灰度流量验证 Shepherd 上的 API 配置合乎预期后再迁徙。
2.3 易用性设计
Shepherd API 网关的功能强大且简单，易用性对业务研发人员来说至关重要，咱们着重来看下主动生成 DSL、API 操作提效的解决方案。
2.3.1 主动生成 DSL
业务研发人员在理论应用网关治理平台时，咱们尽量通过图形化的页面配置来加重 DSL 的编写累赘。但服务参数转换的 DSL 配置，依然须要业务研发人员手工编写。一般来说，生成服务参数 DSL 的流程是：
- 引入服务的接口包依赖。
- 拿到服务参数类定义。
- 编写 Testcase 生成 JSON 模板。
- 填写参数映射规定。
- 最初手工录入治理平台，公布 API。
整个过程十分繁琐，且容易出错。如果须要录入的 API 多达几十上百个，全副由业务研发人员手工录入的效率是十分低下的。
解决方案
那么能不能将服务参数 DSL 的生成过程给自动化呢？答案是能够的，业务 RD 只需在网关录入 API 文档信息，而后录入服务的 Appkey、服务名、办法名信息，Shepherd 治理端会从最新公布的服务框架控制台获取到服务参数的 JSON Schema 信息，JSON Schema 定义了服务参数的类型和构造信息，治理端可依据这些信息，主动生成服务参数的 JSON Mock 数据。联合 API 文档的信息，主动替换参数名雷同的 Value 值。这套 DSL 主动生成计划，应用过程中对业务通明、标准化，业务方只需降级最新版本服务框架即可应用，极大晋升研发效率，目前受到业务研发人员的宽泛好评。
2.3.2 API 操作提效
疾速创立 API
API 网关的外围能力是建设在 API 配置的根底上的，但提供弱小性能的同时带来了较高的复杂性，不少业务研发人员吐槽 API 配置太繁琐，学习老本高。疾速创立 API 的性能应运而生，业务研发人员只须要提供大量的信息就能够创立 API。疾速创立 API 的性能以后分为 4 种类型（后端 RPC 服务 API、后端 HTTP 服务 API、SSO CallBack API、Nest API），将来会依据业务利用场景的不同，提供更多的疾速创立 API 类型。
批量操作
业务研发人员在 API 网关上，须要治理十分多的业务分组，每个业务分组，最多能够有 200 个 API 配置，多个 API 可能有很多雷同的配置，如组件配置，错误码配置和跨域配置的。每个 API 对于雷同的配置都要配置一遍，操作反复度很高。因而 Shepherd 反对批量操作多个 API：勾选多个 API 后，通过【批量操作】性能可一次性实现多个 API 配置更新，升高业务反复配置的操作老本。
API 导入导出
Shepherd 提供在不同研发环境互相导入导出 API 的能力，业务研发人员在线下测试实现后，只须要应用 API 导入导出性能，即可将配置导出到线上生产环境，防止反复配置。
2.4 可扩展性设计
一个设计良好的根底组件，除了能提供弱小的根底能力，还须要有良好的扩大能力。Shepherd 的可扩展性次要体现在：反对自定义组件、服务编排的能力。
2.4.1 自定义组件
Shepherd 提供了丰盛的零碎组件实现鉴权、限流、监控能力，可能满足大部分的业务需要。但仍有一些非凡的业务需要，如自定义验签、自定义后果解决等。Shepherd 通过提供加载自定义组件能力，反对业务实现一些自定义逻辑的扩大。
下图是自定义组件实现的一个实例。getName 中填写自定义组件申请时的名称，invoke 办法中实现自定义组件的业务逻辑，如继续执行、进行页面跳转、间接返回后果、抛出异样等。
目前 Shepherd 通过自定义组件曾经胜利反对了美团优选、外卖、餐饮、打车等重要业务，接入的自定义组件数量有 200 多个。
2.4.2 服务编排
个别状况下，网关上配置的一个 API 对应后端一个 RPC 或者 HTTP 服务。如果调用端有聚合和编排后端服务的需要，那么有多少后端服务，就必须发动多少次 HTTP 的申请调用。由此就会带来一些问题，调用端的 HTTP 申请次数过多，效率低，在调用端聚合服务的逻辑过重。
服务编排的需要应运而生，服务编排是对既有服务进行编排调用，同时对获取的数据进行解决。次要利用在数据聚合场景：一次 HTTP 申请返回的数据须要调用多个或屡次服务（RPC 或 HTTP）能力获取到残缺的后果。
通过后期调研，公司曾经有一套成熟的服务编排框架，由客服团队开发的海盗组件（参见《海盗中间件：美团服务体验平台对接业务数据的最佳实际》一文），也是美团外部的公共服务。
因而咱们与海盗团队单干，设计了 Shepherd 的服务编排反对计划。海盗通过独立部署的形式提供服务编排能力，Shepherd 与海盗之间通过 RPC 进行调用。这样能够解耦 Shepherd 与海盗，防止因服务编排能力影响集群上的其余服务，同时多一次 RPC 调用并不会有显著耗时减少。应用上对业务研发人员也是通明的，十分不便，业务研发人员在治理端配置好服务编排的 API，通过配置核心同时下发到 Shepherd 服务端和海盗服务上，即可开始应用服务编排能力。整体的交互架构图如下：
三、将来布局
目前接入 Shepherd API 网关的 API 数量超过 18000 多个，线上运行的集群数量 90 多个，日均总调用次数在百亿以上。随着 Shepherd API 网关业务规模的一直增长，对咱们的可用性、易用性、可扩展性必将提出更高的要求。将来一年，Shepherd 的布局重点包含有云原生架构演进、动态网站托管、组件市场等。
3.1 云原生架构演进
Shepherd API 网关的云原生架构演进有三个指标：简化接入网关步骤，晋升业务研发人员的研发效率；减小服务端 War 包大小，晋升安全性和稳定性；接入 Serverless 弹性，降低成本，进步资源利用率。
为了实现这个三个指标，咱们打算整体迁徙网关服务到公司的 Serverless 服务 Nest（参见《美团 Serverless 平台 Nest 的摸索与实际》一文）上，同时通过抽取 Shepherd 外围性能到 SDK 的形式集成到业务的网关集群，业务研发人员能够只抉择本人须要应用的自定义组件，从而大幅减小服务端的 War 包大小。
3.2 动态网站托管
依靠 Shepherd API 网关实现动态网站托管的指标是：建设通用的动态网站托管解决方案，为开发者提供便捷、稳固、高扩展性的动态网站托管服务。
动态网站托管解决方案能为业务研发人员提供的次要性能包含：托管动态网站资源，包含存储及拜访；治理利用生命周期，包含自定义域配置以及身份验证和受权；CI/CD 集成等。
3.3 组件市场
Shepherd API 网关组件市场的指标是：单干共赢，造成开发生态，业务研发人员可将开发的自定义组件提供给其余有须要的业务研发团队应用。
咱们心愿让业务研发人员参加到自定义组件的开发，欠缺应用文档后设置为公共组件，凋谢给所有应用 Shepherd 的业务研发人员应用，防止反复造轮子。
作者简介
充泽、志洋、李敏等，均来自美团根底技术部 - 基础架构团队。
招聘信息
美团根底技术部 - 基础架构团队诚招高级、资深技术专家，Base 北京、上海。咱们致力于建设美团全公司对立的高并发高性能分布式基础架构平台，涵盖数据库、分布式监控、服务治理、高性能通信、消息中间件、根底存储、容器化、集群调度等基础架构次要的技术畛域。欢送有趣味的同学投送简历至：edp.itu.zhaopin@meituan.com。
浏览美团技术团队更多技术文章合集
前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试
| 在公众号菜单栏对话框回复【2020 年货】、【2019 年货】、【2018 年货】、【2017 年货】等关键词，可查看美团技术团队历年技术文章合集。
| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至 tech@meituan.com 申请受权。