共计 7566 个字符，预计需要花费 19 分钟才能阅读完成。
作者暴渊，API7.ai 技术工程师，Apache APISIX Committer。
近些年随着云原生和微服务架构的日趋倒退，API 网关以流量入口的角色在技术架构中扮演着越来越重要的作用。API 网关次要负责接管所有申请的流量并进行解决转发至上游服务，API 网关的策略决定了 API 网关解决这些流量的逻辑与规定，间接决定了理论的业务流量行为。
什么是 API 网关策略？
API 网关个别位于所有的上游服务之前，当用户向服务发送申请后申请会先到 API 网关，API 网关接管到申请之后个别会判断几件事件：
- 申请是否非法，比方是否来自被禁止拜访的用户列表中；
- 这个申请是否通过认证，拜访的内容是否是通过受权的；
- 申请是否触发了某些限度规定，比方限流限速等；
- 申请应该转发给哪个上游服务。
通过这一系列步骤，这个申请要么不合乎预设的规定被回绝，要么通过了层层解决正确达到指定的上游服务中。咱们将这些解决规定称之为 API 网关的策略。这些规定由网关的管理员在网关运行时一直增加至网关中，网关承受这些规定并依据这些规定作出正确的流量解决行为。
以 API 网关 Apache APISIX 为例，APISIX 的配置信息有两种：网关启动用的配置文件，比方 config.yaml，这个文件决定了网关失常启动所必须的一些配置。另外在运行时管理员能够通过 Admin API 动态创建各种规定与配置，比方 Route、Consumer、Plugin 等等。API 网关的策略就是管理员通过 Admin API 动态创建的各种规定与配置。
本文不再额定形容根本罕用场景，而是针对认证受权、平安、流量解决与可观测性这四类 API 网关中重要的场景进行论述，介绍每种场景下蕴含的一些 API 网关策略的作用以及应用办法。
认证和受权策略
认证能够确认 API 调用者的身份，受权次要限度调用者仅能拜访权限内的资源。
比如说一位乘客返回车站出行，进入车站之前会应用身份证进行“认证”确认身份，在进入车站后出示车票，经工作人员确认后被“受权”进入某班列车。
认证受权类策略次要目标是保障网关转发到上游服务的所有申请都是通过认证和受权的，不会呈现非法申请。并且拜访的都是权限范畴内的资源。比拟罕用的策略有上面几种：
Basic Auth
根本拜访认证策略，这是一种最简略的访问控制技术。个别由用户的 HTTP 代理在发出请求时携带用于认证的申请头，个别为：Authorization: Basic <credentials>，credentials 中即蕴含了用户认证须要的用户 ID 和明码，应用 : 隔离。这种形式不须要登陆页面、cookie 等繁冗的设置，仅仅基于申请头中的简略凭据信息进行认证，个别为用户名和明码，配置应用起来较为简单。
携带根本认证的 cURL 申请的示例如下，用户名为 username，明码为 password：
curl -i -u 'username:password' http://127.0.0.1:8080/hello 须要留神的是 credentials 中的信息在传输过程中并不会被加密，仅仅做 Base64 编码，所以通常须要和 HTTPS 一起应用来保障明码的安全性。
在网关中施行这一策略后，未携带凭据的申请将无奈失常通过网关转发，除非在申请中携带了正确的认证信息，实现了最小老本下为 API 增加了拜访验证。
Key Auth
Key Auth 策略通过在 API 中增加 Key 来限度 API 调用，并辨认申请携带的 Key 来进行拜访资源的管制。只有携带了正确的 Key 之后的申请能力失常拜访，能够在申请头中或 Query 中携带。通常还能够通过这个 Key 来辨别不同的 API 调用方，从而能够针对不同的调用方施行不同的其余策略或资源管制。同样的 Key 在 HTTP 中是明文传输的，确保申请应用了 HTTPS 以保障平安。
以 APISIX 的 key-auth 插件为例，插件须要通过 Admin API 创立一个具备惟一 key 值的 Consumer：
curl http://127.0.0.1:9180/apisix/admin/consumers \
-H 'X-API-KEY: edd1c9f034335f136f87ad84b625c8f1' -X PUT -d '{"username":"jack","plugins": {"key-auth": {"key":"jack-key"}
}
}' 这一申请创立了一个名字为 jack 的 Consumer，它的 key 值为 jack-key。在路由中启用插件时须要配置网关从申请中读取 Key 值的地位和字段名称。默认的配置地位为 header，字段名称为 apikey，那么正确的申请这个路由的示例为：
curl -i http://127.0.0.1:8080/hello -H 'apikey: jack-key'APISIX 在收到这一申请后会从申请中解析出 Key，而后从配置的所有 Key 中找到和这个申请匹配的 Consumer jack，这样网关就分明这个申请是 jack 收回的。如果没有找到匹配的 Key 即可断定为非法申请。
JSON Web Token
JSON Web Token (JWT) 是一个凋谢的规范，它定义了一种以 json 对象模式在各方之间平安传递信息的形式。JWT 策略能够集认证和受权于一身，在用户获得受权后会向用户传输一个 JWT Token，在前面的所有申请中调用方都会携带这个 Token 从而保障申请是被受权的。
在 API 网关中能够通过 JWT 策略将 JWT 身份验证能力增加到网关中，从而把这层逻辑从业务中抽离进去，业务实现者能够更加专一实现业务逻辑。以 APISIX 的 jwt-auth 插件为例，插件须要在 Consumer 中启用并配置惟一的 Key、加密用的公私钥、加密算法、Token 过期工夫等。同时还须要在路由中启用这一插件并配置网关读取 Token 的地位和字段，比方 header、query、cookie 等。该插件会在 API 网关中增加一个 API 用于签发 Token。在发送申请之前须要申请签发 token 的 API 取得 Token，发送申请时须要依据配置信息在指定的地位上携带这一 Token。在申请达到网关后网关会依照配置信息从申请的指定地位读取 Token 并验证 Token 的有效性，验证通过后该申请能力被转发至上游服务。
相较于前两种策略，JWT 策略蕴含了过期工夫选项，签发的 Token 随着工夫流逝是能够过期的，然而 Basic Auth 和 Key Auth 的有效期是永恒的，除非服务端更换了明码或 Key。除此之外 JWT 策略能够在多个服务之间专用，尤其是针对单点登录场景下很有用。
OpenID Connect
OpenID Connect 是建设在 OAuth2.0 协定之上的身份认证办法，为利用的受权提供了比拟残缺的计划，API 网关中的 OpenID Connect 策略将容许上游服务从身份提供者（IdP）中获取申请中的用户信息，从而爱护 API 平安。常见的身份提供者有 Keycloak、Ory Hydra、Okta、Auth0 等等。以 Apache APISIX 为例网关中的 OpenID Connect 策略工作流程如下：
- 客户端向网关发出请求
- 网关收到申请后向 IdP 收回认证申请
- 用户将被重定向到 IdP 提供的页面实现登陆认证
- IdP 重定向到网关并携带认证 code
- 网关通过 code 向 IdP 申请 Access Token 从而获取用户信息
- 网关向上游转发申请时即可携带用户信息
通过这一流程能够将认证和鉴权从业务中独立进去搁置于网关中解决，使架构更加清晰。对于更多 APISIX 的认证受权办法能够参考 API Gateway Authentication。
安全策略
API 网关安全策略像门卫一样保障 API 平安拜访，容许失常申请被网关转发并在网关上拦挡非法申请。依据 OWASP API Security Project，在 API 的调用者中存在着大量可能的威逼和攻打。应用 API 网关安全策略能够对所有的 API 申请进行平安验证，在 API 免于蒙受这些平安威逼上起到了重要作用。
以下是几种比拟重要的 API 网关安全策略。
IP 拜访限度
IP 限度策略通过将某些 IP 或 CIDR 设置为白名单或者黑名单来限度某些客户端对 API 的拜访，确保重要数据不会被随便拜访。正确配置这一策略很大水平上进步了 API 的安全性，实现了更高的 API 平安治理。
URI 拦挡
URI 拦挡策略次要通过设置 URI 的一些规定来阻止潜在的危险 API 申请。比方一些平安攻打通过嗅探 URI 门路从而发现潜在的安全漏洞进而攻打。
Apache APISIX 提供了 uri-blocker 插件来提供这一能力。通过 uri-blocker 插件能够设置一些正则规定，如果申请命中规定就能够拦挡以后用户的申请，例如设置 root.exe、admin，这一插件就能够阻止 */root.exe 和 */admin 这种相似的申请，进一步爱护 API 平安。
CORS
CORS 即浏览器针对跨域申请作出的安全策略。个别状况下在浏览器中收回 xhr 申请前浏览器会验证申请地址和以后地址是否为同一域，如果在同一域下申请能够间接收回，否则浏览器会先登程一个 OPTION 类型的跨域预检申请，而后在该申请的响应头中会有 CORS 相干的设置，例如容许跨域申请的办法、容许申请携带的凭据等。浏览器会依据这些信息决定是否收回正式的申请，具体能够参考 CORS。
个别状况下蕴含 CORS 设置的响应是由后端服务设置的，然而如果服务数量很多，在网关层面针对不同服务对立解决会更加便捷平安。CORS 策略能够在不同的 API 上设置不同的跨域解决策略，上游服务无需再解决这些逻辑。
CSRF
CSRF 即跨站申请伪造攻打，通常状况下会使终端用户在他们曾经认证的站点中执行非被迫的动作。这种攻打通常随同着社会工程学（通过电子邮件向攻击者发送攻打链接），当用户点击这一链接后利用攻击者在网站中已登陆认证的身份执行攻打操作。在网站看来因为用户曾经登陆，所以所做的任何操作都是失常的。
通常网站的后端服务须要增加额定的中间件解决这部分逻辑，防备的办法也都有对立的规范。应用 CSRF 策略能够为网关提供防备这一攻打的能力，在网关层对立做 CSRF 平安解决，简化上游服务逻辑复杂度。
流量解决策略
流量解决策略次要保障 API 网关进行流量转发的上游负载都在衰弱范畴内，同时在申请转发前或者返回给调用者前对申请进行按需改写。这一类型的策略次要围绕限流限速、熔断、缓存、重写等性能开展。
限流限速
在资源无限的状况下，API 能够提供的服务能力是有肯定限度的，如果调用超过了这一限度可能会使上游服务解体继而引起一些连锁反应。限流限速能够防备这种状况的产生，另一方面也能够无效避免 API 蒙受 DDOS 攻打。
在限流限速策略中能够设置一个工夫窗口和可容许最大的申请数量，在工夫窗口内超过这个数量的申请会被回绝并返回设置的信息，直到申请数量低于设定的值或到下一个工夫窗口后会容许持续拜访。
申请计数的凭据能够设置为申请中的变量或着某一个申请头等，例如依据不同的 IP 设置相应的限速策略。实现更加灵便的管制。
熔断
API 熔断策略能够为上游服务提供熔断能力，应用这一策略时须要设置上游服务衰弱和不衰弱的状态码，用于网关判断上游服务状态。另外还须要设置触发熔断或者恢复健康的申请次数，间断达到这一次数后即断定为对应的状态。当上游服务间断向网关返回肯定次数的不衰弱状态码后，网关就会熔断该上游服务一段时间，在这段时间内不再向该上游转发申请而是由网关间接返回谬误。能够避免上游服务因为谬误后持续接管申请呈现“雪崩”，爱护业务服务。超过这一时间后网关会再次尝试向上游转发申请，如果还是返回不衰弱的状态码，网关就会持续熔断更长的工夫（加倍）。直到转发申请后上游间断返回了肯定次数的衰弱状态码，则网关认为上游服务恢复健康，后续会持续往该上游节点转发流量。
在这个策略中还须要设置当不衰弱后须要返回的状态码和信息，当上游服务不衰弱后申请在网关层面间接返回，爱护业务服务稳固。
流量拆分
流量拆分策略能够动态控制将流量按比例转发给不同的上游服务，这在灰度公布或蓝绿公布中十分有用。
灰度公布又名金丝雀公布，当服务公布新性能时能够仅让一部分申请应用新的服务，另一部分依然停留在旧的服务中。如果新服务保持稳定，则能够减少比例逐渐将所有申请转移到新的服务中，直至比例齐全切换，实现服务降级。
蓝绿公布则是另一种公布模式，能够做到在用户应用的高峰期进行公布，同时不会中断服务。服务的旧版本和新版本会同时共存。个别会将生产环境（蓝色）复制到一个雷同然而独自的容器中（绿色）。在绿色环境中公布新的更新，之后将绿色和蓝色一起公布至生产环境。之后就能够在绿色环境中进行测试和修复，在这期间用户拜访的还是蓝色零碎。之后能够应用某些负载平衡策略将申请重定向到绿色环境中。蓝色环境即可放弃待机作为劫难复原选项或者用作下一次更新。
APISIX 的 traffic-split 插件通过流量拆分对上述提到的两种公布类型都进行了很好的反对，使得业务部署更加便捷牢靠。
申请重写
在古代微服务架构中，尤其是服务端与服务、服务与服务之间充斥各种不同的协定，或着申请数据格式不对立，这些问题如果独自在各自服务之间实现转换解决会产生很多冗余的逻辑代码并且难以治理。一些申请重写策略能够解决一些协定转换、申请体改写等逻辑。
APISIX 提供了 response-rewrite 插件能够用来批改上游服务返回的 Body 或者 Header 信息内容，反对增加或者删除响应头，设置规定批改响应体等。这在设置 CORS 响应头实现跨域申请设置或者设置 Location 实现重定向等场景中很有用。
另一方面，对于申请重写 APISIX 则提供了 proxy-rewrite 插件也能够解决代理到上游服务的申请内容，能够对申请的 URI、办法、申请头等重写，在很多场景下为业务解决提供了便捷。
故障注入
故障注入测试是一种软件测试办法，通过在零碎中成心引入谬误来确保零碎的行为失常。通常在部署之前进行测试以保障在生产环境中没有潜在的故障。在一些混沌测试场景下，须要对服务注入一些谬误来验证服务的可靠性。
软件的故障注入能够分为编译时注入和运行时注入。编译时注入指在编写软件的过程中通过扭转某些代码或逻辑来实现；运行时注入通过向正在运行的软件环境中设置谬误来测试软件的行为。故障注入策略能够在网关中以运行时注入的形式，模仿利用网络申请中的故障。通过在策略中设置一个比例，命中这个比例内的申请会执行设置好的故障逻辑，比方延迟时间返回，或间接返回设置的错误码和错误信息给调用方。
通过这种形式能够减少软件的适应性，让开发人员提前看到可能呈现的一些谬误状况，在公布之前针对问题做出适应性批改。
协定转换
协定转换类的策略能够做一些常见协定之间的转换。比方常见的 HTTP 申请和 gRPC 之间的转换。Apache APISIX 提供了 grpc-transcode 插件能够实现在网关接管到 HTTP 申请之后，将申请转码并转发给 gRPC 类型的服务，接管到响应后以 HTTP 的格局返回给客户端。这样客户端无需关注上游 gRPC 的类型，只解决 HTTP 即可。
可观测性策略
可观测性指在一个零碎中通过零碎的输入数据来掂量这个零碎运行状态的能力。在一些简略的零碎中，因为零碎组件数量绝对较少，呈现问题时能够通过剖析各个组件状态失去答案。然而在大型分布式系统中，各种微服务组件数量十分大，对组件一一进行排查显然是不事实的，这个时候就须要零碎具备可观测性。可观测性提供了对分布式系统的“可见性”，当零碎呈现问题时它能够提供工程师所需的控制能力，精确定位问题。
可观测性的数据收集能够在应用程序组件内实现，也能够在其余地位实现。API 网关作为所有流量的入口，在 API 网关中实现零碎的可观测性，能够清晰反映出零碎 API 的应用状况。API 网关的可观测性策略能够帮忙到公司的每个团队：
- 工程师团队能够监控并解决 API 问题；
- 产品团队能够理解 API 的应用状况以开掘背地的商业价值；
- 销售和增长团队能够监控 API 应用状况，察看商业机会并确保 API 提供正确的数据。
可观测性策略依据输入的数据类型个别分为三类：Tracing，Metrics 和 Logging。
Tracing
在大型分布式系统中服务之间的调用关系盘根错节，Tracing（链路追踪）能够在分布式应用中追踪残缺的调用链路、利用之间的依赖剖析以及申请统计等内容。在零碎呈现问题时能够帮忙工程师确定排查范畴和地位。
Tracing 策略能够在 API 网关上集成一些其余的分布式调用链路追踪零碎，收集信息并记录。常见的服务比方 Zipkin、SkyWalking 等。通过 Tracing 策略将这些服务集成到 API 网关中，实现在网关上数据收集和与这些服务之间的通信，能够帮忙工程师解决诸如这个申请接触了什么服务以及引入了多少提早等问题。Tracing 策略使工程师可能进一步确认在特定的会话或相干的 API 调用中要看哪些日志，确认排查范畴。
Metrics
Metrics 指在服务运行期间收集到的一个工夫距离内软件本人的各种观测数据，这些数据默认是结构化的，能够更好地实现查问和可视化。通过对这些数据分析能够把握零碎当下的运行状态和行为。
Metrics 策略能够在 API 网关中集成 Prometheus 或 Datadog 这一类服务，为零碎提供监控、报警等能力。这一策略通过 API 网关中的各种接口收集网关运行过程中的数据，并将数据上报至上述服务中。通过将这些数据可视化后开发者能够清晰看到网关的运行状态，API 申请的统计信息等数据统计图。
Logging
日志是在某个特定工夫零碎事件的文本记录，当零碎呈现问题时日志是首要排查的中央。当服务呈现一些意外状况时工程师依赖日志内容查看零碎“产生了什么”从而找出对应的解决办法。日志内容个别分为两类：API 申请日志和网关本身的运行日志。API 申请日志记录了 API 网关在运行期间所有的 API 申请记录，通过这些记录工程师能够把握 API 拜访状况，及时发现并排查异样申请。网关本身的运行日志则蕴含了网关在工作期间产生的所有事件的记录，当 API 网关本身出现异常时能够作为排查问题的重要依据。
Logging 策略能够将 API 网关中的日志存储在服务器磁盘中或是推送到一些其余的日志服务器中，比方 HTTP 日志服务器、TCP 日志服务器、UDP 日志服务器等，或者是其余的日志零碎比方 Apache Kafka、Apache RocketMQ、Clickhouse 等。
总结
这篇文章介绍了什么是 API 网关策略，并针对认证受权、平安、流量解决与可观测性这四类 API 网关中罕用的策略进行形容。API 网关在所有上游服务之前接管申请的流量，管制一个申请是否要转发以及如何进行转发，对不平安的、未受权的申请间接回绝或进行限度，这些行为都能够由 API 网关策略决定。
