点赞
评论
收藏
分享
举报
课程实录 | 云原生环境下构建高效 API 管理系统(上)
发表于2022-12-07 11:05

浏览 1.4k

文章标签

原文作者:路瑞强 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 开源社区:

已修改于2023-03-09 02:02
本作品系原创
创作不易,留下一份鼓励
NGINX官方账号

暂无个人介绍

关注



写下您的评论
发表评论
全部评论(0)

按点赞数排序

按时间排序

关于作者
NGINX官方账号
这家伙很懒还未留下介绍~
264
文章
21
问答
198
粉丝
相关文章