浏览 923
原文作者：路瑞强 of F5
原文链接：课程实录 | 云原生环境下构建高效 API 管理系统（下）
转载来源：NGINX 开源社区
编者按—— 本文为 2022 年 1 月线上直播课《云原生环境下构建高效 API 管理系统》的课程实录。由于文章较长，将分为上下两篇发布。点击此处阅读本文上篇，点击此处收看课程回放。
本文将以宏观视角分享 API 管理的现状，并深入介绍 NGINX 的 API 解决方案。业内很多的 API 网关基本上都是用 NGINX 作为底座，在此基础上再进行开发以实现特定的功能。本文将探讨 NGINX 官方做的 API 网关和其他的 API 网关的区别。最后，文章会通过一个行业真实案例来说明使用 NGINX 作为 API 网关能达到的效果。
NGINX API 管理关键能力
这里我们简单列举了 NGINX 的 API 网关管理系统的关键能力：比如 API 定义、认证、限流、熔断，包括监控、集成 WAF （安全技术）、故障排除、监控界面、DevOps 配合、最后还有具体的业务开发界面等等，我们来简单介绍一下这些能力。
首先是 API 的定义与发布，也就是对外提供的 API 是什么样的。比如从 URL 的角度来说。业务通过 /123 这样的定义发布了，但如果前期规划的不好或者有业务的变化，导致这个 URL 已经被用掉了，那它不一定可以和后台 URL 一一对应。在这种情况下需要做定义和发布的特殊处理，需要定义新的 URL 然后重新做对应。
接下来是服务发现，也是非常典型的用法，而其中最典型的服务发现技术就是 DNS,当然也可以用一些其他的像注册中心这样的工具来做，通过这些工具来找到业务是什么样的、在什么地方。
而 API 管理更重要的一块就是认证和授权，哪些人可以访问我的 API，以及不同人访问之后能使用什么样的功能、得到什么级别的结果。
例如，普通的用户访问了银行网银系统的 API，银行只会给其查看余额的权限，无法转账也不能查看历史记录。但是当用户做了进一步认证之后，系统识别到足够的安全级别，就会允许一些转账、历史记录查询等操作。
如果用户的级别更高，不只是普通用户而是企业级别的管理员，这种情况下根据 URL 系统可能会给用户访问企业网银的权限。所以每针对每个用户的身份和权限认证以及授权，都必须做到非常精细，这对于业务层和安全性都非常重要。
接下来将介绍的是 API 限流，这是一个非常典型且高可用的场景。比如 API 网端平时的业务量大概在 100 个左右，通常会提供能承担 1000 个业务的能力以应对业务量较大的情况。但黑客可能会放 2000 甚至 10000 个业务进行攻击，在这种情况下就需要对 API 网关做限流，确保它在承受范围内提供服务。
因为 API 不像传统的 web 页面一样很容易被访问，用户需要被认证且通常涉及到交易之类的业务，所以它对于业务的访问量并不大。在此基础上如果不作限制，在黑客的攻击下就很容易崩溃，所以必须要有限流的功能。
如果限流也无法解决问题，那么就需要使用 API 熔断功能在短期内暂停服务，并提供一个错误页面让用户知道出现了问题，需要等待一天或者一个小时之后再进行访问。还有一些其他的功能，像是监控、告警等在运维中也用的比较多。
当然，在整个 NGINX API 网关系统里最重要的就是 API 安全。安全性和可用性很多时候是矛盾，所以在实际中这两者你优先考虑哪个？不同的企业面有不同的侧重和选择。
例如，如果是一个只需要展示页面的小企业，可能对安全就没那么看重。但如果涉及到银行网银系统，安全性就非常重要。在二者只能选其一的时候，如果数据和交易很重要的业务就需要选安全性，反之则选可用性，NGINX 可以通过不同的配置将用户不同的选择进行实现。这也是 NGINX 网关里提供的一个非常强大的能力。
以上几个页面都是通过 NGINX 代码实现的，这里面我只是找了两个很小的场景举例，一个是告警的信息，一个是和容器化做配合的 docker 文件该如何构建，我会大概展示这些是如何用代码的方式实现。
NGINX API 安全防护及可视化
接下来会涉及到系统安全的部分，如果您对于 NGINX 配置文件熟悉的话，会觉得这一页非常眼熟。这里面列出的第一项就是 app protect module 也就是安全模块。
app protect 就是 NGINX 里面的一个 WAF 模块，它是构建于 F5 公司里的 ASM WAF 原理，然后在 NGINX 系统里实现的 WAF。这里用到了 app_protect_modle.so 的动态模块加载形式，来加载到配置文件里。同时后面还有 syslog target 这样的配置，因为不管是发现问题做告警还是做阻断，都需要有日志并且需要用 syslog 的形式把日志倒出来。
接下来是策略文件，安全策略需要做的严格还是轻松？这些都需要策略文件的形式去做配合，可以根据不同的业务安全级别去定义并启用不同的策略文件，非常灵活地去管理和控制，满足企业业务系统安全级别和安全规范的要求。
具体安全策略里的配置大概是这样的模式，从中可以看到API网关里 JSON 文件是什么样的，open API 情况是怎么制定的。同时也可以去定义安全的级别，哪些情况下会启用以及哪些情况会做安全告警。
比如这个例子里有 alarm 和 block， alarm 是告警，block 是真正的阻断。如果整个业务刚刚上线的，为了避免误报可以把策略里的 block 都改成 false，这样的话它就不去做阻断，只去做告警。运行了几天或一周之后，发现有好多地方有这样的告警，这个时候需要分析一下这些告警是真的攻击还是误报，根据分析再去调整相应的配置文件。
自己去写所有的策略文件是不现实的，在配置文件里可以会看到 base 这个级别，在内置的策略文件里是 default 也就是默认策略。以上列出来的就是 OWASP 十个最常见的攻击，包括了一些常见的高等级 CVE 等问题。我们需要的就是写下这两行：“name”和“template”，把这两行加到配置文件里去，它就会开始防御这些默认的攻击。
如果需要更精细的处理，可以再去做更细化的配置并且逐个调整，比如针对上一页提到的 SQL 注入攻击、cookie 篡改攻击，可以做一些单独的处理，甚至可以针对特定的 URL 做一些特殊的保护。我们可以根据需求定制独立需要的策略文件，再加载到相应配置的 URL 或者 server、业务、端口、地址等等作为配置的一部分，这样就可以根据定义做相应配置。
做了这些定义之后更关键的是可视化，我们需要看到是否受到攻击以及具体情况如何。比如在可视化里可以看到被阻断的次数、阻断了多少攻击行为、做了多少次告警等等。如果量特别大，可能要考虑做其他层面的处理。在图上看到的偶然有突发的情况也很常见，可能是黑客利用了一些扫描技术偶然地来扫描一下，就会有这样的突发提醒。这种情况下无需担心，慢慢就会没问题了。
但如果有一些攻击是持续性地，那么需要重点防范。因为持续攻击可能代表那个地方是攻击源，当然通常这不是真正的攻击源，一般都是黑客黑掉的一些机器或者是代理服务器。这个时候需要考虑，为了优化性能是否需要从 IP 地址层面把攻击的地址封掉不再允许访问。
还可以看到这个过程中业务的情况，比如返回的代码是 404、200 或是 500 等等。如果看到了很多 500、400 这类的错误，这证明可能确实受到了攻击或者扫描。如果看到访问的量很大，但是返回的代码都是 200，这个时候可能不一定是攻击而是业务的突发，需要注意并根据情况判断。还可以通过各种其他的角度，比如基于 URL、ip 地址、具体的浏览器类型等等来做精细化的处理。
还可以通过一些其他角度，比如具体的攻击类型、地理区域：流量访问都是从哪里访问的、攻击都是哪些类型，这些信息都可以通过 dashboard 图清晰地看到，并了解整体的安全情况。也可以自定义展示的时间，比如最近一小时、一天或者是一个月，根据不同的用处都可以改变。
如果你正在遭受攻击，那么只需要展示最近一小时或最近三小时的数据就够了，这样有助于分析当前的攻击是什么样的。但如果攻击已经过了，需要针对这次攻击事件进行回溯、历史性分析以及后续处理，这种情况下可能需要看一天的数据，或者回到攻击开始的时候。
还有可能是到了年末总结的时候需要看一年的数据，都可以从不同的层面看到不同的内容，来实现不同的目的。通过以上的内容，您对于整个 API 使用情况包括它的安全和功能，都能有整体大致的了解了，那么接下来就是部署。
API 网关部署
API 网关到底应该怎么部署，能部署在哪些地方？最后，综合了很多用户的使用情况，我们总结了两个参考架构。第一种是传统的部署方式，也就是在传统环境中，服务器装了系统、软件等等。
传统系统里，把 API 网关作为一个软件附在操作系统之上，然后外面会有一个 controller 做管理和对接，在这之外可能还有一些负载均衡设备，这样就可以实现整个 API 的管控。如果量小则不需要负载均衡，做主备就可以了。
在传统环境之外我们还有现代化应用环境，也就是 K8S 网关，实际上是在 K8S 里面做网关。外面的流量进来到了 K8S 的 ingress，通过 ingress 再把流量转到 API 网关上，再由 API 网关转到相应的内部业务 pod 上来实现。
同理，内部的 API 网关需要和外部的 controller 做对接，对接的时候可以通过外面的 controller 管控里面的 API 网关配置与参数、各种监控数据等等。根据以上的具体部署的情况我们可以看出，无论是传统还是现代环境，NGINX 的 API 网关都可以很容易的做部署。
应用案例
最后我们来看一个来自客户的应用案例，某个银行现在需要做开放银行，也是最近这几年比较热门的一种业务。以前的银行都是客户去存钱取钱然后通过银联对接，现在由于支付工具的灵活化，支付宝和微信这些公司也都和银行是有做对接的。
在开放银行的趋势下，用户还可以接触到除微信、支付宝以外更多的企业，例如美团、携程等等，避开了中间的第三方支付平台与更多企业直接做交易。这种情况下就需要开放大量的 API，也就是我们通常讲到的开放银行。
开放银行意味着成百上千个业务和 API 需求，因为用户有不同的需求，必须要通过 API 网关获取各种数据，再通过这些数据做各种各样不同的业务，这种情况下就需要大量的 API 网关去做处理。所以银行需要 API 管理服务来去构建这样的模式，也需要 API 网关管理系统这样整体的方案。
而客户在业务上遇到的情况是，通过测试发现由于业务需求、功能、API 数量都很多，很多传统 API 网关需要增加 500 毫秒也就是半秒钟的延迟，这个延迟时间是很长的。在做支付的时候，光是一个 API 调用就需要半秒，且很多交易涉及到多次 API 交互，如果需要 6 次调用则需要延迟 3 秒，有 10 次就会延迟 5 秒，这个时长用户是很难接受的。
所以根据业务需求，客户要求总的延迟不能超过 70 毫秒，显然传统 API 网关无法满足他们的要求。最后，客户了解到很多网关都是基于 NGINX 做的，继而决定和我们洽谈合作。通过长期的沟通和方案优化之后，我们为用户设计的整体方案通过 API 管理成功将延迟缩短到了 10 毫秒以内，远超出了客户的预期客户，这对业务是十分重要的提升。
业务部门也拿这个速度给很多客户展示我们产品的优势，别的网关需要 100 毫秒延迟，而我们的方案只需要 10 毫秒，这是完全不同等级的性能。同时，刚才也提到了 NGINX 整体的方案和 DevOps 有非常紧密的配合和集成，所以更加能够满足客户的要求。
最后，总而言之 NGINX 会利用控制和管理分离的双平面来提升整体的性能，以及各种其他的功能，在此基础上实现了用户的需求。当然，NGINX 产品以及公司的思路都是以性能为主，可以做到保证性能的基础上，随着版本的不断发布，功能会不断增加来满足更多用户的需求。
更多资源
想要更及时全面地获取 NGINX 相关的技术干货、互动问答、系列课程、活动资源？
请前往 NGINX 开源社区：
按点赞数排序
按时间排序
点赞 6
浏览 6.3k点赞 1浏览 3.4k点赞 10浏览 4.9k
微信公众号
加入微信群
