共计 4341 个字符，预计需要花费 11 分钟才能阅读完成。
白泽平，Apache APISIX PMC 成员，目前次要在 APISIX 和周边我的项目 APISIX Dashboard 上进行相干奉献。本文整顿自阿里云「中间件开发者 Meetup」中的议题分享。
Apache APISIX 是一个高性能的、动静的、实时的 API 网关，它是基于 NGINX 和 OpenResty 进行实现的。
作为一个脱胎于 NGINX 和 OpenResty 的软件，APISIX 人造继承了 NGINX 的性能和 OpenResty 的灵活性，因而，APISIX 的性能在一众 API 网关中都是首屈一指的。
细数 Apache APISIX 劣势
架构舍短取长
具体来说，像 NGINX + Linux epoll 提供了高性能的网络 IO 基础设施，这些是 C 语言实现的，是动态的。而 OpenResty 则集成了 LuaJIT，它基于 NGINX 提供的生命周期钩子进行扩大，容许用户通过 Lua 代码对 NGINX 进行编程。而 LuaJIT 自身，得益于优良的 JIT 实现，它能够在运行时对代码进行 JIT 编译，当热门路上的内容被编译为机器码后，性能将能够与原生 C 语言相比。
当然，除了 NGINX 与 OpenResty 的人造个性劣势外，APISIX 自身也为性能进行了多处优化。比方没有复用 NGINX 的 location 来解决路由匹配，而是应用了基数树的形式。目前其余很多 API 网关还在应用遍历的形式解决路由，而 APISIX 则不会呈现遍历形式的重大性能消退，在路由很多时（这里指达到数千量级），它也能够提供根本安稳的匹配速度。
同时，APISIX 也在动静性能层面进行了一些操作。
置信应用过 NGINX 做服务部署的敌人肯定记得，如果你批改了 NGINX 的配置文件，即便只是增加了一个 location，也必须要通过 NGINX reload 指令来利用配置，甚至有时还须要重启。这种状况对于外部利用场景来说还能够承受，然而对线上利用来进行这种操作时，可能会造成客户端连贯的中断，这就影响很大。
而在 APISIX 中，上述配置操作过程都是齐全动静的，location 能够动静配置，upstream 和 SSL 证书这些全副都能够动静配置。这次要得益于 APISIX 应用了 etcd 作为配置核心，通过 etcd watch 机制实现了动静的更新其配置，从而不须要依赖 reload 和重启。
除此之外，像是以往须要 NGINX 批改配置才能够设置的 gzip 和缓存等，也能够动静地在繁多路由的维度中进行启用。
如上是 APISIX 体系的架构图，底层就是刚刚提到的 NGINX + Lua 环境，再向上是 APISIX 的外围模块，它包含路由、上游等相干能力，还有一些罕用性能的封装。这个外围模块也是插件框架的入口，用户在相似路由等组件中配置路由时，将被合并在此调用执行。
APISIX 在外围模块中提供了很多开箱即用的性能，比方负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性、服务发现、限流限速和日志收集等性能。
APISIX 中的很多性能都是通过插件形式进行实现的，目前 APISIX 的插件已靠近 80 个，将来还在继续扩大减少中。提到插件，不得不说 APISIX 提供的插件运行时是一个十分易于开发的插件框架，用户能够轻而易举地应用 Lua 编写本人的插件，来实现特定业务性能。如果切实不具备 Lua 的开发保护能力也能够应用内部 Plugin Runner（APISIX 多语言插件）或者 WASM 开发插件。
开源沉闷凋谢
APISIX 是 Apache 软件基金会旗下的顶级开源我的项目，它应用了 Apache License v2 开源协定，对商业应用与二次开发都比拟敌对。
同时 APISIX 社区也始终放弃着沉闷，包含但不限于产品技术自身的沉闷（比方近一个月内有 70+ commit，解决了 70+ issue 等），还有社区活动和一些内容分享上的寰球布道等。
Apache Way 的理念，领导着每一个 Apache 基金会开源我的项目，即「社区 > 代码」。社区的建设至关重要，重要性甚至超过我的项目代码自身。回过头来咱们看，为什么 APISIX 社区能够如此沉闷？
- 社区凋谢，欢送任何有意义的探讨（比方问题报告、新性能等）。 除此之外，无论我的项目维护者身份如何、来自什么公司，大家都采纳同样的形式参加社区。所有探讨都在邮件列表内进行，未经邮件列表探讨的事项，就是不存在的；全副开发工作也都是公开的，任何事项都有痕迹。
- 常常与其余社区进行我的项目单干。 比方 APISIX 的很多插件都是与其余我的项目或者服务的集成，像 Casbin 社区参加到 APISIX 我的项目中，奉献了
casbin权限治理和casdoor身份认证插件。 - 通过各种渠道吸引新的贡献者参加社区。 比方 APISIX 我的项目已间断多年参加 Google GSoC 打算和国内开源供应链点亮打算等流动，吸引国内外对开源我的项目感兴趣的学生来参加其中，减少学生们对开源社区的教训。
周边我的项目齐开花
上文咱们提到的都是 APISIX 我的项目自身的一些内容。但其实，基于 APISIX 这个云原生 API 网关，也衍生出了很多周边我的项目。
通过应用 APISIX Ingress Controller，用户能够将 Kubernetes Ingress 资源和 APISIX 自定义的 CRD 资源提取进去，进而为 APISIX 配置路由、上游或插件等。它将主动依据 K8s Service 生成上游，并与路由进行关联，提供了一种在 K8s 中的申明式 API 的实现门路。
除此之外，APISIX 还提供本人的开源控制台实现——APISIX Dashboard，它提供了 APISIX 中最罕用性能的可视化配置能力，可间接在界面上批改即可实现 API 的配置高低线。这与 APISIX Ingress Controller 提供的代码即配置的思路有所不同，前者重视配置的灵活性，而后者重视规定定义的确定性。
同时在以后最热门的服务网格畛域，APISIX 也在尝试交出本人的答卷。APISIX 的服务网格我的项目 Amesh 现曾经开源，目前的计划应用 Istio 作为管制面实现，与 Envoy 一样通过 xDS 协定与 Istio 通信，并将通信规定转换为 APISIX 中的路由与上游配置。从而替换了 Istio + Envoy 组合中 Envoy 的流量网关角色。
APISIX 如何应答利用倒退
古代利用零碎架构曾经通过屡次倒退，从单体利用、多单体利用 + 企业服务总线的 SOA 到当初的多微服务架构演变。
当单体利用迭代到微服务后，微服务自身具备肯定规模后，单纯的微服务并不足以解决生产上面临的问题。其随同的一个显著特色就是，服务的数量在大幅增长，各个服务间的调用关系也变得更加简单。
因而，在不同的阶段其实大家都面临着很多不同的技术选型。比方服务层面，咱们能够用到像是 Apache、NGINX、HAProxy 这样的反向代理工具。进入到微服务时代咱们又会用到像 NGINX 或是一些更加现代化的动静 API 管理工具，这里又会因为技术栈的不同扩大出更多的产品。比方在 Java 语言侧抉择 Zuul 或者 Spring Cloud Gateway 这样的组件，在 Kubernetes 部署又会有 Ingress 等抉择。更进一步到服务网格架构中，又会产生 Istio + Envoy/MOSN 这种抉择。
各种技术手段浩如烟海，如何依据以后企业、团队的情况抉择最合适的架构对架构师的能力带来很大的挑战。
除了整体架构上的抉择，随着团队的扩充和业务场景的简单，对于开发者而言，须要理解和思考的货色越来越多。这种状况下，各种各样的流量比方 HTTP/TLS、gRPC、四层的 TCP/UDP、中间件的调用（比方 Redis 缓存）等等，对它们进行对立的治理正是当下利用倒退阶段所面临的窘境。
APISIX 作为云原生 API 网关，为许多企业提供了一个更优的抉择。在应答各种不同场景时，APISIX 有着一些流量代理的用法。比方咱们能够将 APISIX 作为一个 LB 来解决对外服务的负载平衡问题，同时也能够将其用作 API 网关来解决微服务的裸露与调用，利用 APISIX Ingress Controller 还能够解决容器中的 API 治理难题。
能够看到，应用 APISIX 能够为你在不同阶段提供一个对立的、全流量的解决形式。那这种形式能为用户带来哪些收益呢？
- 对于研发人员来说，如果一个人把握了 APISIX 这套体系的技术，他就能够很轻松地实现企业团队中各种不同畛域的工作，比方在 API 网关或者 Ingress Controller 这种流量治理的落地场景。
- 对于运维人员来说，应用 APISIX 后无论是后续保护现有环境还是切换到新的技术栈上，你都能够间接应用同一种工具和办法进行间接治理，而无需再投入学习和工夫老本。同时作为开源产品，学习之后还能够作为本身的技术积攒复用到其余工作中，堪称是一举多得。
- 对于公司来说，选用 APISIX 的架构不仅仅能够满足现有需要，还为未来的技术演进预留下空间。比方当下是为了满足作为 LB 的需要，如果之后公司技术倒退，未来也能够无缝过渡到 API 网关或者容器平台乃至服务网格等畛域。
瞻望：与 OpenSergo 的将来打算
咱们在上文中也提到了与其余社区的积极合作。在之前，OpenSergo 在 APISIX 社区我的项目仓库的 issue 中曾发动探讨，心愿能够通过社区单干的形式，协商建设一个用于流量管制的统一标准，这引起了一部分社区成员的趣味。之后在一次 APISIX 社区的中文 Weekly Meeting 中，OpenSergo 社区的搭档也为大家介绍了这一项目标愿景、思路和价值。
作为一个凋谢且容纳的开源社区，APISIX 是十分欢送这种社区间单干的，通过我的项目协同能够施展出各自我的项目更大的价值。
具体来说，因为 OpenSergo 我的项目规范的表现形式次要为 Kubernetes CRD，其用于云原生的容器环境中，因而能够优先思考将它与 APISIX Ingress Controller 我的项目进行集成，为其减少 OpenSergo 的配置解析和解决模块，将原始配置转换为 APISIX 的内置速率限度插件等。
这种做法有助于应用 Kubernetes 的用户来加强其流量控制能力，并与其余各种上下游生态进行集成，比方 RPC 框架。对于不应用 Kubernetes 的用户，在目前产品现状下，还短少一个桥梁去实现 CRD 到 APISIX 插件的配置转换。
因而，咱们也有参考彼此产品的一些将来布局。比方 OpenSergo 的文档中提到，它们将公布专门的 SDK 供数据面组件调用以集成至 OpenSergo。如果有了 SDK 或是其余模式的接口，在接下来的日子里，无望看到 OpenSergo 与 APISIX 的集成我的项目。
最初，作为开源沉闷我的项目，APISIX 社区也十分欢送有趣味的搭档来提交这些性能的实现，帮忙我的项目的集成成为事实。置信通过开源间的单干，彼此我的项目都能够获得更大的成就。
