分享人：温铭，Apache 顶级我的项目 APISIX 的 PMC 主席，开源商业化公司 API7.ai 的联结创始人和 CEO。
背景介绍
Apache APISIX 是一个动静、实时、高性能的开源 API 网关，提供负载平衡、动静上游、灰度公布、服务熔断、身份认证、可观测性等丰盛的流量治理性能。
作为 API 网关，Apache APISIX 能够帮忙企业疾速、平安地解决 API 和微服务流量，利用于网关、Kubernetes Ingress 和服务网格等场景。利用 APISIX 既能够解决从客户端到服务端的南北向流量，也能够解决从各个企业微服务之间的东西向流量。
APISIX 在 2019 年 6 月 6 号开源，同年 10 月份捐献给了 Apache 软件基金会。在之后不到一年的工夫内，毕业成为 Apache 顶级我的项目。
在我的项目疾速倒退的背地，APISIX 在技术上进行了哪些摸索？为什么会失去越来愈多开发者和企业用户的青眼？在接下来的内容中，将为你讲述更多细节。
APISIX 技术摸索之路
解脱数据库依赖
在 APISIX 我的项目问世之前，也有十分多的商业 API 网关或开源 API 网关产品，但这些产品大多数都把 API 数据、路由、证书和配置等信息寄存在一个关系型数据库中。
寄存在关系型数据库的劣势其实很显著，能够让用户更加不便地应用 SQL 语句进行灵便查问，不便用户进行备份及后续保护等环节。
但这种状况也会额定带来一个问题。网关作为一个根底中间件，它解决了所有来自客户端的流量，这种状况下对于可用性的要求便会十分高。如果你的 API 网关依赖了一个关系型数据库，也就意味着关系型数据库一旦呈现了故障（比方宕机、失落数据），你的 API 网关也会因而受到影响。这种状况下，零碎的整体可用性就会大打折扣。
所以 APISIX 在设计之初，就从底层架构上防止了相似上述情况的产生。
APISIX 的架构次要分成两局部。第一局部叫做数据面，它是真正去解决来自客户端申请的一个组件，去解决用户的实在流量，包含像身份验证、证书卸载、日志剖析和可观测性等性能。数据面自身并不会存储任何数据，所以它是一个无状态构造。
第二局部叫做管制面。APISIX 在底层架构上和其它 API 网关的一个很大不同就在于管制面。APISIX 在管制面上并没有应用传统的相似于像 MySQL 去做配置存储，而是抉择应用 etcd。这样做的益处次要有以下几点：
- 与产品架构的云原生技术体系更对立
- 更贴合 API 网关寄存的数据类型
- 能更好地体现高可用个性
- 领有低于毫秒级别的变动告诉
应用 etcd 后，对于数据面而言只需监听 etcd 的变动即可。如果轮询数据库的话，可能须要 5-10 秒能力获取取到最新的配置；但如果监听 etcd 的配置变更，就能够将工夫管制在毫秒级别之内，达到实时失效的成果。
所以应用 etcd 而不是关系型数据库，不仅让 APISIX 在底层上更加贴合云原生，也让它在零碎高可用的体现上带来了更多劣势。
反对多语言插件
API 网关其实和数据库或其余中间件不太一样，尽管都属于根底组件，但对于网关来说，它更多应用场景是进行一些定制化开发和系统集成。
目前 APISIX 官网尽管有十分多的插件，但仍难以涵盖用户的所有应用场景。所以在实在应用场景中，多多少少都会面对业务进行一些定制化的插件开发。通过网关去集成更多的协定或者零碎，最终实现在网关层的对立治理。
APISIX 在刚开始只反对应用 Lua 语言进行开发插件。这样做的益处在于，通过原生计算语言的底层优化，能够让开发进去的插件具备十分高的性能。然而它的劣势也非常明显，就是学习 Lua 这门新语言是须要工夫和了解老本的。
为此，APISIX 通过两种形式去解决了上述问题。
第一种形式就是通过 Runner Plugin 来反对更多的支流开发语言，比方 Java、Python、Go 等。如果你是一个后端工程师，至多应该会其中一种语言，那么这个时候你就能够十分不便地通过本地 RPC 通信，应用你之前相熟的计算语言去开发一个 APISIX 插件。
这样做的益处是缩小了开发成本，进步了开发效率。当然弊病就是在性能层面有一些损失。那么，有没有一种既能达到 Lua 原生性能，同时又兼顾高级语言的开发效率计划呢？
这里就引出了第二种形式，也就是上图左侧局部。WebAssembly 最早是用在前端或浏览器上的一个技术，在服务端它也逐步展现进去它的劣势。
把 WebAssembly 嵌入到了 APISIX 里，用户就能够应用 WebAssembly 去编译成 WebAssembly 的字节码在 APISIX 中运行。最终达到的成果就是利用高效率，开发出了一个既有高性能又应用高级计算语言编写的 APISIX 插件。
所以在目前的 APISIX 版本中，用户能够应用 Lua、Go、Python 和 Wasm 等多种形式，基于 APISIX 编写自定义代码。通过这样的形式，升高了开发者的应用门槛，也为 APISIX 的性能提供了更多的可能性。
插件热加载
APISIX 和 NGINX 相比，有两处十分大的变动：APISIX 反对集群治理和动静加载。
如果大家应用过 NGINX，就晓得它的所有配置都会写在 nginx.conf 这个配置文件中。如果想要进行集群管制，就须要一台台去批改它的 nginx.conf 文件。整个过程中没有一个集中化治理的管制立体，每一个 NGINX 都是一个数据面 + 管制面的混合体。如果此时你有几十台几百台 NGINX，它的治理老本就会特地高。
在上述场景中，批改完每台 NGINX 的 nginx.conf 文件后，都须要重启能力失效。比方进行证书更新或者上游变更，都须要先批改配置文件，而后重启失效。如果你的申请不是特地多，那么这种办法勉强还能承受。但随着越来越多 API 和微服务的调用，如果每次批改都进行重启，这对于客户端的稳定其实会十分大。
上图中列出来了 APISIX 目前在哪些组件中实现了动静加载，从这个列表咱们能够看到从上游到证书，甚至插件自身，它的代码都是实时失效的。那么其实在社区外面就会有人问到，他能够了解上游、证书这些是动静的，因为这些会常常变动，但为什么插件的批改也要做成动静的呢？因为插件的批改并不是一个特地频繁的操作，没有必要做成一个极致的动静。
对于 APISIX 的底层设计工程师来说，咱们心愿它能够做到一个极致的动静。因为极致动静带来了一个十分大的劣势就是减少了更多可能性。比如说用户能够在不批改任何插件代码的状况下，对已有代码进行故障排查，这个过程中可能会存在调试插件的批改。那么这种状况下，用户就能够不必重启，继而随时复现问题并记录。这种调试性能的插件配合插件热加载的机制后，就会变得非常灵活，帮忙开发者在排查问题的过程中省时省力。
插件动静编排
除了上述提到的插件热加载，APISIX 在插件和插件之间也反对实时的动静编排，动静编排也为插件的运行带来了有限可能。
什么叫插件编排？咱们在提出各种各样的需要时，更多是心愿能够把一个需要变成一个插件，就像玩乐高一样，通过一个对立的规范（形态符合、穿插等），就能够搭进去有限种可能的造型，这也是乐高的乐趣之一。那么对于 APISIX 的插件来说，每一个插件其实都实现了一个独立的场景需要，那么有没有一种可能，能够让用户像搭乐高一样，把各种插件摆出来让用户本人依照需要进行排列组合呢？
比方 APISIX 当初提供了 100 个插件，那么 APISIX 给用户裸露的性能其实也就只有这 100 个插件所具备的性能，并没有把底层的一些灵活性展露出来。在进行技术中间件开发时，咱们不仅须要思考这个产品当初能做成什么样子，而更应该思考的是将来用户在上手应用时，是否将这个产品赋予更多可能性。
APISIX 目前有将近 100 个插件，在退出插件编排能力后，你会发现它的可能性不是 100 种，而是 100×99×98×97×96x……，也就是靠近有限种可能。
举个例子，比方你想对一个用户进行限流限速，当他被限速之后，个别状况下是返回一个错误码。这时你是否能够尝试对接一个日志记录插件，或者是谬误上报插件来进行后续的流动记录。下方图片展现了 APISIX 的插件编排模式。
这个性能其实暗藏了一个很大的益处，每一个插件的代码都被残缺的测试案例笼罩到。也就是说当用户进行插件编排时，能够不必写任何代码。这对于像产品经理、平安工程师以及像运维工程师来说，不须要投入专门的学习老本，只须要拖拽一些插件而后设置一些条件，就能够诞生一个专属本人的 APISIX 新插件，同时这个新插件的代码品质是和开源 APISIX 的官网代码品质一样高。
全流量网关
对于服务端的工程师来说，如果你进行一些和网关相干的开发，根本都会波及到两个概念。一个是南北向流量，指的是从客户端、浏览器或 IoT 设施等达到服务端的流量，这个流量属于纵向的。另一个就是东西向流量，指的是在企业外部，零碎与微服务之间的相互调用，这个流量属于横向的。
在解决纵向和横向的这些流量时，各组件组成也会有所不同。比方在解决南北向流量的组件中，可能会先通过一个 LB，而后再到网关，通过网关之后可能会进入一个业务网关。所以就会有相似于像 NGINX、APISIX、Sping Cloud Gateway 这样的组件。那么在东西向流量中，如果你应用了服务网格，那么可能会用到相似于像 Envoy 这样的组件，这些组件看上去会十分多，但如果仔细观察它们的性能，你会发现这些组件基本上都是一样的，大多都是进行像路由调度、动静上游以及平安身份认证的插件实现等。
所以这种状况下，是否把解决南北向与东西向流量的组件对立起来？现实状态是当一个客户端的申请进到服务端之后，全副由 APISIX 来解决。即不论流量是南北向还是东西向，都是通过管制面去管制所有流量与数据。这在 APISIX 目前的技术摸索中，是齐全能够实现的。
在理论应用过程中，通过一些现有用户的实际反馈，你会发现这种模式可能大大降低用户本身的运维老本，同时能够升高整体零碎的复杂度，从而晋升了整个零碎之间的响应速度。这样的反馈后果，也让后续 APISIX 的迭代有了更清晰的方向，让 APISIX 在全流量网关层面去尝试更多的性能和角色。
多服务发现组件
网关尽管是根底组件，但它的地位极其重要。它会解决所有来自客户端的申请，解决实现后，对于 API 网关来说还有一个十分重要的职责，就是去和各种各样的零碎及开源我的项目进行集成。
在集成过程中，就会用到一个十分重要的组件——服务发现与注册。因为用户会把各种各样的服务搁置到 Eureka、Nacos 这样独自的组件中去实现。对于一些大规模或业务存续较久的 IT 零碎来说，多个服务发现组件并存是十分常见的。
这种状况下，其实所有的流量出入口都是网关。你可能须要在 A 路由下来独自指定一个 Nacos 服务发现，在 B 路由上指定 Consul 的服务发现等。这对于绝大部分的网关来说，个别都只反对一个服务发现，这时你可能就要部署多套网关，让不同的网关对接不同的服务发现组件。
目前在 APISIX 中不仅反对在数据面的服务发现，也逐渐反对在管制面上去对接多个服务注册和发现的组件。这对于一些大规模和业务长远的企业来说，就是一个十分好的解决方案，只部署一个 API 网关，就能够轻松对接多种不同的服务发现和注册组件。
多云与混合云场景摸索
对于网关来说，当用户把它部署到生产环境中时，如果是云原生架构，那么多云和混合云必然是一个长期存在的技术场景。对于 APISIX 来说，当它领有了欠缺的性能、性能、插件和多服务发现后，就不可避免地去思考如何让用户在生产环境中更好地去运行起来。
多云和混合云场景其实对 APISIX 带来了更多的挑战，须要思考更多细节。
- 上下游均反对 mTLS
之前咱们感觉反对上游的 mTLS 这个性能的优先级并不高，但一旦处于跨云场景，上游可能就是另外一个云上的服务，或者另外一个 SaaS 服务等。为了进步数据的安全性，就须要进行 mTLS 性能的加持。
- 管制面与数据面架构齐全拆散
APISIX 在最近一年中被爆进去几个安全漏洞，这些安全漏洞的起源很多是因为 APISIX 的管制面与数据面是混合部署在一起的。能够了解为 APISIX 服务启动实现之后，它的管制面与数据面在同一个服务里。此时如果一个黑客通过安全漏洞入侵了某个数据面，那么也就意味着他有机会可能入侵到管制面，从而管制所有的数据面，造成十分大的影响。
在 APISIX 后续的架构设计中，咱们在思考把数据面与管制面齐全拆散。采纳不同的端口与服务，将其部署在齐全不同的服务器上，从而避免出现上述安全隐患。
- 增强平安治理
网关个别会存储一些比拟敏感的数据，比方有些用户可能就会间接把 SSL 证书存储在网关上，或者把连贯 etcd 的密钥信息存在网关上。这种状况下一旦 etcd 被侵入了或者数据面被攻破，就有可能造成比较严重的数据泄密。
因而就须要思考在存储一些要害信息时，去反对应用 Vault 这样专门存密钥的组件来进行敏感信息的爱护。这样做不仅能够让 APISIX 本身更加平安，也可能让用户应用 APISIX 时更加合规。
- 集成更多云上规范
在多云状况下咱们须要去思考，APISIX 在相似阿里云、腾讯云及 AWS 等云服务商中应用时，如何与他们更好地交融在一起来应用？咱们的初衷是心愿用户不必配置任何货色就可能在各个云平台上顺利运行起来。
这个过程的实现，并不说让用户再进行自定义插件配置，而是间接让 APISIX 去集成各个云上的规范、API 或其余服务，提前帮用户做好适配，保障后续用户的间接上手体验感。
前行之路的支持者
纵观 APISIX 的倒退历程，其实在技术层面做了十分多的翻新。不论是从一开始的代码搭建，还是目前依然放弃的疾速迭代，越来越多的社区贡献者们携手并进，将 APISIX 逐步搭建成了残缺且性能日渐丰盛的 API 网关。
一个开源产品的迭代与提高，必然少不了贡献者与使用者的功绩。
在 APISIX 刚捐献给 Apache 软件基金会时，它还并不是一个特地成熟的我的项目，那时的 APISIX 只有 20 个贡献者。现在的迅速倒退，也让 APISIX 在寰球范畴内播种泛滥使用者、贡献者和企业用户。比方 WPS、新浪微博、爱奇艺等国内大厂，这些都是每天承载几百亿次 API 调用的企业用户。在海内也有像 NASA、欧盟数字工厂、瑞士电信等十分多的一些用户在应用。
拿 WPS 这种云办公软件来说，不论你在手机、浏览器还是终端设备上进行多人协同办公时，几十甚至几百个人能够同时去编辑一份文档，同时你能够实时查看到其他人进行的批改。这个性能实现的背地，就是通过 API 的各种调用来实现的。
国内这些大厂企业用户的应用场景中，多是解决上百亿 API 调用和峰值 QPS 超百万的规模。这种应用规模下，也让 APISIX 真正在大规模场景中失去历练与播种实在场景反馈。得益于这些企业用户的场景应用，APISIX 作为开源产品才得以更成熟疾速倒退。
当然除了将 APISIX 利用到企业业务中来，很多使用者在应用 APISIX 的过程中，也会把他们的一些教训或者代码性能迭代等反馈给社区，实现了单方互利共赢的趋势。这也阐明使用者们不仅感觉 APISIX 是一个好的产品，更是一个值得去参加其中的开源我的项目。先博得开发者们的喜爱，才有机会去变成一个真正有价值的开源我的项目。
贡献者们用体验和反馈打造了十分多的产品性能，使用者们利用这些性能又能够给企业带来价值。这个才是真正开源的精华所在，而不是一味只去谋求各种外表数据而带来的数字凋敝。
APISIX 3.0 前瞻
至此咱们聊了十分多对于 APISIX 在过来及当初进行的摸索。从工夫线来看，能够把 APISIX 的倒退历程分为几个阶段。
APISIX 1.0 阶段，是在打造这个产品的框架，将底层架构打理好并出现一些 API 网关的基本功能。来到 2.0 阶段，则是在初始版本上进行了更粗疏的摸索，让底层更加灵便，让架构更加饱满。
对于一个成熟的开源我的项目来说，它成熟的标记并不是说性能有多弱小，而是在产品应用上，为用户和开发者带来更好的应用体验。
在目前阶段中，APISIX 都是在技术上进行了十分多的摸索与翻新，但并未思考到使用者背地的感触，比方文档品质参差不齐、教学视频少之又少等现状。这就让很多用户在刚接触 APISIX 时，存在茫然与手足无措。不晓得怎么应用，不晓得如何将某些性能利用到什么场景，不晓得 APISIX 这些弱小的性能背地能给企业带来怎么的独特价值。
所以在接下来的 APISIX 3.0 阶段中，会尝试解决相似的问题，重构掉目前很多对于开发者体验不敌对的中央。比方从新去设计 API，去掉对于 etcd 的一些非凡返回值的依赖；重构官网应用文档，让文字性这种最间接的表达方式对开发者更加敌对。在性能层面，也会进行管制面与数据面拆散，让 APISIX 自身变得更加平安；反对更多的 4 层协定，反对更多的 RPC 协定，让用户能够十分不便地去实现南北东西向的全流量网关。
这些待实现性能加在一起，你会发现 APISIX 3.0 阶段将会变得比之前版本更加安全可靠与易用。功能强大的同时，仍不忘应用体验。咱们心愿将来的 APISIX，是能够解决寰球所有 API 和微服务的申请，最终达到一个十分好的应用价值，助力企业在 API 和微服务流量的解决上更加便当。
预计在 2022 年年底，APISIX 将会公布全新的 3.0 版本，心愿大家也能够继续关注 APISIX 新版本的各种动向，踊跃参加 Apache APISIX 我的项目共建。
APISIX 的将来
服务端技术的倒退和更替是疾速的，五年前风行的技术和框架，当初很多曾经无人问津。究其原因，并非是工程师们喜新厌旧，而是这些技术自身没有满足工程师和企业的实在需要，倒退的路线呈现了偏差，最终被淘汰。这是很残暴的，这也是事实：技术要服务于业务和产品，技术不能闭门造车。
“勿在浮沙筑高台”，这句话时刻揭示着 Apache APISIX 的开发者们，应该用实在的需要和场景来指引 Apache APISIX 的倒退和进化，不要自嗨，否则就很容易在人不知; 鬼不觉中被工程师们所摈弃。
如何能够始终放弃 Apache APISIX 在技术层面的当先性？这是 Apache APISIX 将来是否能够持续博得开发者、博得企业用户的关键问题。答案其实也非常简单：与疾速成长的企业和工程师打成一片，一起成长，相互成就，让 Apache APISIX 始终站在技术的最火线。唯有如此，APISIX 才有机会成为一个长青的开源我的项目，成为一个世界级的开源我的项目。
APISIX 的将来，是更好的反对 Serverless，欠缺服务网格，构建 API 全生命周周期平台，还是晋升私有云上的应用体验，这些并不是由某几个开发者布局进去的，而是由千千万万一线的工程师们一起打造的，这是开源的魅力，欢送退出咱们！