NGINX API 管理工作关键性潜能
这里他们单纯列出了 NGINX 的 API 交换机信息控制系统的关键性潜能：比如说 API 表述、证书、开闭、TNUMBERAP，包括监视、软件系统 WAF （安全控制技术）、机械故障须建、监视介面、DevOps 相互配合、最后还有具体的销售业务合作开发介面之类，他们来单纯如是说一下那些潜能。
首先是 API 的表述与正式发布，也是对内提供更多的 API 是怎样的。比如说从 URL 的视角来说。销售业务透过 /123 这种的定义正式发布了，但假如后期总体规划的不太好或者有销售业务的变化，导致这个 URL 已经被用掉了，那它不一定能和前台 URL 相异。在此种情况下须要做表述和正式发布的特定处理，须要表述捷伊 URL 然后重新做相关联。
接下来是服务项目辨认出，也是十分众所周知的用语，而其中最众所周知的服务项目辨认出控制技术是 DNS,当然也能用许多其他的像注册登记中心这种的辅助工具来做，透过那些辅助工具来找出销售业务是怎样的、在甚么地方。
而 API 管理工作更关键的几块就是证书和许可，甚么样人能出访我的 API，和不同人出访后能使用怎样的功能、得到甚么等级的结果。
例如，一般的使用者出访了商业银行信用卡控制系统的 API，商业银行只会给其查阅银行存款的职权，无法提款也不能查阅历史纪录。但是当使用者做了进一步证书后，控制系统辨识到足够多的安全等级，就会容许许多提款、历史纪录查阅等操作。
假如使用者的等级更高，不只是一般使用者而是民营企业等级的图书馆员，此种情况下根据 URL 控制系统可能会给使用者出访民营企业信用卡的职权。所以每特别针对每一使用者的身分和职权证书和许可，都必须努力做到十分精巧，这对于销售业务层和可靠性都十分关键。
接下去将如是说的是 API 开闭，这是一个十分众所周知且高需用的情景。比如说 API 网端平常的销售业务量约莫在 100 个左右，通常会提供更多能分担 1000 个销售业务的潜能以应对销售业务规模较大的情况。但黑客可能会放 2000 甚至 10000 个销售业务进行攻击，在此种情况下就须要对 API 交换机做开闭，确保它在承受范围内提供更多服务项目。
因为 API 不像传统的 web 页面一样很容易被出访，使用者须要被证书且通常涉及到交易之类的销售业务，所以它对于销售业务的出访量并不大。在此基础上假如不作限制，在黑客的攻击下就很容易崩溃，所以必须要有开闭的功能。
假如开闭也无法解决问题，那么就须要使用 API TNUMBERAP功能在短期内暂停服务项目，并提供更多一个错误页面让使用者知道出现了问题，须要等待一天或者一个小时后再进行出访。还有许多其他的功能，像是监视、告警等在运维中也用的比较多。
当然，在整个 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 交换机须要增加 500 毫秒也是半秒钟的延迟，这个延迟时间是很长的。在做支付的时候，光是一个 API 调用就须要半秒，且很多交易涉及到多次 API 交互，假如须要 6 次调用则须要延迟 3 秒，有 10 次就会延迟 5 秒，这个时长使用者是很难接受的。
所以根据销售业务需求，客户要求总的延迟不能超过 70 毫秒，显然传统 API 交换机无法满足他们的要求。最后，客户了解到很多交换机都是基于 NGINX 做的，继而决定和他们洽谈合作。透过长期的沟通和方案优化后，他们为使用者设计的整体方案通过 API 管理工作成功将延迟缩短到了 10 毫秒以内，远超出了客户的预期客户，这对销售业务是十分关键的提升。
销售业务部门也拿这个速度给很多客户展示他们产品的优势，别的交换机须要 100 毫秒延迟，而他们的方案只需要 10 毫秒，这是完全不同等级的性能。同时，刚才也提到了 NGINX 整体的方案和 DevOps 有十分紧密的相互配合和软件系统，所以更加能够满足客户的要求。
最后，总而言之 NGINX 会利用控制和管理工作分离的双平面来提升整体的性能，和各种其他的功能，在此基础上实现了使用者的需求。当然，NGINX 产品和公司的思路都是以性能为主，能努力做到保证性能的基础上，随着版本的不断正式发布，功能会不断增加来满足更多使用者的需求。
如欲了解更多相关信息，您能点击文章《云原生环境下构建高效 API 信息控制系统》查阅，更多关于NGINX 的相关知识，您能进入NGINX 官方社区了解。
