浏览 1k
原文作者：路瑞强 of F5
原文链接：课程实录 | 云原生环境下构建高效 API 管理系统（上）
转载来源：NGINX 开源社区
编者按——本文为 2022 年 1 月线上直播课《云原生环境下构建高效 API 管理系统》的课程实录。由于文章较长，将分为上下两篇发布。
本文将以宏观视角分享 API 管理的现状，并深入介绍 NGINX 的 API 解决方案。业内很多的 API 网关基本上都是用 NGINX 作为底座，在此基础上再进行开发以实现特定的功能。本文将探讨 NGINX 官方做的 API 网关和其他的 API 网关的区别。最后，文章会通过一个行业真实案例来说明使用 NGINX 作为 API 网关能达到的效果。
API 管理现状
API 应用场景的变化
下面我们开始第一个部分—— API 的现状。说到这里，必须从业界的变化开始讲起，相信大家一定能感受到，我们的应用场景在不断地变化。通过这些调查报告我们可以看出趋势，例如第一个数据就非常典型地体现了现代化应用的快速发展，有 3/4 的用户都正在做现代化应用改造，这样的改变是业务驱动所造成的。
在改造过程中，最重要的部分就是在应用架构中加入了 API 这一层，它成为了最灵活的各个组件和业务之间对接的接口，从而实现了现代化高效灵活的应用发展。
从第二组数据中可以看出应用的变化，那么随着应用的变化，维护该怎么做？高效的处理又如何运行？显然这和 DevOps 有关， DevOps 对于整个体系可以带来提升和帮助。
从这组有关 DevOps 的数字里可以看出，有 65% 的企业已经在做 DevOps 的扩展工作，严格来说绝大部分企业都已经做了。只是对于大企业来说，比如银行、电信等，由于他们的业务数量庞大有成百上千之多，所以只能先在一个小的应用上做实验，再慢慢进行推广，且推广过程很长。
因此我们可以看到，绝大部分的用户做了小范围的转变，但大部分的用户正在扩展到更多传统的业务中去，甚至是一些不一定适合 DevOps 结构的传统业务也在利用这种思想进行改造。在改造过程中，需要各种各样的工具来实现 DevOps，比如有用来构件、测试、编排的工具等等，而这些工具基本默认都是靠 API 来连接。所以通过数据我们能看到，70% 的 CIO 都采用了 API 连接自动化工具。
最后，这些应用和运维的转变会牵扯到整个技术路线的变化，而技术路线的变化是清晰的，比如新的应用架构中最流行的是容器架构。容器改变了我们整个开发和运维的模式，有 95% 新增应用都是在容器的环境中做的。无论您在什么企业，新增应用基本都会按照新的架构来做。尤其是互联网或者媒体这类变化速度较快的企业，可能所有的业务都已经在新增的容器里运行了。
而像刚才提到的一些大企业，例如股份制国有大行，他们想要把所有的应用都迁移到容器是不现实的，而是会把一些新的应用放到容器里去做，但传统的应用还是会保留在传统的架构里面。
当然，涉及到传统应用架构体系上的应用也会有新的需求，但因为业务数量过于庞大迁移所需的时间过长，新的需求还是会保留在传统架构里。总而言之，相对没那么复杂的新兴业务会全部转到容器环境中，这也是我们会看到的技术路线的变化。
另外这组数据还展示了，整个网络流量里 83% 都是 API 的流量，以前来自 web、 html 的流量有很多，但现在大部分都来源于 API，这也和我们的应用场景转变有关系。
比如，物联网绝大部分都是 API 流量，我们很常用到的很多手机 app 也基本都会用 API 的方式，而不是传统的 html。所以我们能看到，整个应用场景的变化也是导致技术路线变化的原因之一。在这个过程中 API 的情况又是怎么样的呢？
API 的快速发展
通过一些第三方调查机构的数据我们可以看出， API 正处于快速发展的阶段。例如通过 programableWeb 公司提供的数据可以看到，2012 年 是 API 在整个业内被使用的一个较大分水岭，从 2012 年之后开始快速提升。金融行业从 2012 年开始虽然增长速率较慢，但从 2017 年开始也出现了很大的变化，这里指的金融行业包括了支付、银行、保险等业务。
而在数量增加的同时，作为企业我们更看重的是营收的变化。比如 Salesforce 的营收里 API 占比超过了 50%， Expedia 已经有 90% 以上的业务都会通过 API 的收入来做。从以上的数据都可以看到， API 已经是一个不可逆转的趋势，目前在业内达到了很高的地位。
现代应用架构的基础
接下来，让我们回归技术本身， API 在现代化应用技术领域的地位是比较高的，因为它是整体架构的基础。
我们从最常见的三个方向展开说一下，第一是微服务的模式，容器的组建能力和 K8S 编排能力都是微服务的基础，而其中的对接都是通过 API 来实现的。如果您熟悉 K8S，会看到它典型的配置、使用、监控，也都需要通过 API。
第二是我们经常谈的云原生，在云原生里提到的网络组建和开发模式的优化过程中，之间的配合都是通过 API 实现的。现代化应用运维中最基础的 DevOps，其中的编排流程自动化以及架构级代码的模式里，更是需要 API 来进行对接。
通过之前数据我们已经能清晰地看到， API 是一个典型的结构， DevOps 用的工具都需要通过 API 连接和对接，架构级代码更是如此。在云原生上构建架构，您要做的就是写一堆代码，然后指定要哪些设备和功能的特征，把这些特征写上去放到公有云上，形成整个应用的架构。以上的例子和数据都充分说明了， API 是整个现代化应用的基础。
那么 NGINX 的情况怎么样呢？从这两个数据可以看出大量的网站都在使用 NGINX，根据 Web Server 的调查 NGINX 的使用是站在第一位的。第二个数据更有意思，有 40% 的用户是把 NGINX 作为 API 网关来做部署的。以前大家都认为 NGINX 更多是一个负载均衡或 web server 工具，而数据证实，更多的用户是把 NGINX 当作 API 网关来进行使用。
在这种情况下， NGINX API 网关是如何实现的？使用中有什么特点呢？根据这个思路我们再来看一下 NGINX 的 API 管理系统。
NGINX 全生命周期 API 管理
从第一部分我们能看到， NGINX 的 API 网关是全生命周期网关，在前期有 API 定义、监控以及保护和分析功能。同时它也有控制和数据层的双平面让两者分离，这是现代化应用的标准软件架构。
比如多年前提到的 sdn 架构，其实就是把数据和控制层面做分离，数据层面做路由转化等数据包处理，控制层面就是下发网络信息和路由信息，比如哪些点是同一个 vlan，哪些 vlan 之间需要路由。
NGINX 也是运用同样的思路，它分成两个组件：controller 和 API 网关。其中 controller 负责做定义和规则，而这些规则是在 API gateways 上执行，从而各自分离并相互搭配以实现整体结构。
NGINX API 管理方案特点
这个结构中有以下几个特点：第一是整体软件的架构、传统 CI/CD 过程以及 DevOps 之间的紧密配合。第二是可以作为微服务业务的 API 接口，也就是微服务边界的出口。
所有外部访问都可以先访问 API 再到各种内部业务中去，甚至可以作为多个微服务之间的对接，当然这个环节就不是工作在微服务内部了，可能需要在传统环境里部署网关，然后由它把不同的 API 和业务分发到不同微服务组里。
这也是得益于其部署环境灵活的特征，使它可以部署在传统环境里，也可以部署在容器、 K8S 这些现代化应用环境里。除此之外， NGINX 一向以高性能为基准，这一典型特征是广为人知的， API 网关的性能自然也有所保障。那么 NGINX 具体在 API 网关的性能上是怎么做的呢？
我们从这张图可以看到，左边是我们传统的在 NGINX 基础上延展的 API 网关，右边是 NGINX 自己的网关。如果是在 NGINX 的基础上延展，我们需要在前面加一个壳并由它来接收各种请求和处理，再转到数据层面。在这种情况下因为转了一层，处理自然会更慢。
而 NGINX 之所以能做到高性能，是因为它自身的网关把 API 管理层面直接挂在了数据处理的旁边，使数据处理直接对接请求处理响应，而管理、控制和配置则运用了其他的板块来实现。
NGINX 作为网关的功能
而在高性能的基础上， NGINX 作为网关的功能怎么样呢？拿 CI/CD 举例，其中包括了源代码的控制、 CI、测试、 CD、以及监控的过程，在整个过程中可能会在中间任何一个环节出现问题。
比如代码提交完成之后构建失败了，这说明代码中有不兼容的地方，那么做基本测试的时候就无法通过。如果重新提交之后通过了，下一步需要进行部署也就是 CI 的过程，我们需要在测试环境（QA）里部署，在这一步中会涉及到 NGINX。全流程测试中并不是纯代码，所以需要把 NGINX 的配置放进去把整个测试做出来。
如果在测试过程中失败了，例如配置了 NGINX 之后发现和业务不匹配，比如 ABC.html 这个目录应该去往第一台服务器，但事实上去了另外一台，配置出现错误导致测试也无法通过，整个过程需要重新再来。如果调整之后测试通过，下一步就是看业务是否有 bug，比如数据处理层中的业务数据是否有问题。
通过之后，到部署在生产环境这一环节，也就是 CD 的过程。在一些有条件的企业中间可能还有一个准生产的步骤，在这个步骤中再整体重新部署一遍，没问题的话再到生产环节。但对于大部分企业来说，只要测试环境过了就可以直接在生产上做部署了。
部署之后需要监控流量的变化，业务是否正常，交易是否更加平缓。比如，晚上九点做了部署，但完成之后发现交易突然跌了 30%，或者流量突然增长了几倍，这显然说明是有问题的，需要去检查并处理问题。对现代化应用来说，查到问题之后的补救方法可能是马上发布下一个版本。
但对于传统企业来说，遇到类似问题第一步就是回退——回到以前的版本，这是不同的企业应对问题的处理方法。梳理了整个流程之后，我们可以看到在整个 CI/CD 过程中， NGINX 有很多部署的东西可以去做处理，包括您的生产、测试环境等等。
在整个过程中，我们还能在逻辑的基础上看到更细节的东西。通过这张图可以看到，在运用 gitlab 这类工具做代码提交的时候可以进入 CI 的过程，在这个过程中会提交到代码库，再去做部署，包括测试。
比如在这个过程中把 NGINX 作为一个组件去部署到它的容器里面，把容器都拉起来，同时也需要传输一些相应的参数。传完之后会有一些自动化的测试，比如具体的测试脚本、单元和整体测试，根据具体的部署情况，具体的业务情况等等。
比如这里面有一个简单例子，比如我去 curl 一下， curl 某个链接看能达到什么效果。或者直接用 NGINX 本身，用 NGINX-t 的参数去确认配置里的语法是否有问题，这都可以很容易的实现测试。
如果测试有问题就回到上一步，没问题可以接着往下走，提交到标准的构建库里去。在构建里再触发整个 CD 的过程做部署，部署的时候生成 docker 镜像，再去各个业务层做 K8S 层面的逐步更新。根据自己的情况，例如灰度发布蓝绿发布等等，通过各种发布实现出整个过程。
从以上的例子可以看到 NGINX 作为网关的过程，如何揉在整个 CI/CD 里，和 DevOps 结合在一起并整体地实现功能。但在和 DevOps 组合的基础上，更重要的是融合之后能做哪些工作。
更多资源
想要更及时全面地获取 NGINX 相关的技术干货、互动问答、系列课程、活动资源？
请前往 NGINX 开源社区：
按点赞数排序
按时间排序
点赞 6
浏览 6.5k点赞 1浏览 3.5k点赞 10浏览 5k
微信公众号
加入微信群
