10大亮点！带你多角度了解云原生API网关Apache APISIX 3.0预览版( 三 ) _API网关

7.支持更多四层可观测性
APISIX 在可观测性的功能支持上一直都投入很多，几乎支持了所有的可观测性组件，比如 Zipkin、Apache SkyWalking、Datadog 等等。同时还支持了各种各样的日志组件，但这些大多都是在七层（应用层）进行的。
在 APISIX 3.0 版本中将会增加更多基于四层（传输层）的可观测性支持。比如增加了四层上对于 Prometheus 和各种日志的支持，不仅可以让用户非常轻松地观测到七层流量中哪里出了问题，也可以去发现四层的流量运作状况。
8.集成 OpenAPI 规范
API 其实是一个涉及从开发、测试、上线到整个全生命周期的元素。在 APISIX 3.0 版本中，将支持标准的 OpenAPI 3.0 规范。
因此，如果你是在一些 API 设计和测试的软件上进行管理 API 的话，就可以非常方便地通过数据导出和导入，将其放置在 APISIX 中进行管理和维护。同时 APISIX 中的各种 API 也可以通过 OpenAPI 3.0 规范进行导出，然后再导入到其他系统中使用。
除此之外，在 3.0 版本中 APISIX 也支持了针对 Postman 相关自定义格式的支持（Postman Collection Format v2），实现两者之间的数据传输，从而更方便地进行集成。
9.Gateway API 的全面支持和服务网格
在 APISIX Ingress 的版本迭代中，已开始对 Gateway API 进行支持，最新的 1.5 版本中已基本支持了所有的 Gateway API 配置。
由于 Kube.NETes Ingress 资源本身的限制，南北向场景中很多的流量管理能力无法被很好的表达出来，因此市场上大量的 Ingress Controller 解决方案都提供了自定义的 CRD，虽然这样能很好地帮助用户管理流量，但是却间接提高了迁移的成本，几乎导致用户被某个 Ingress Controller 选型锁定。因此 Kubernetes 社区在前两年开始着手制定 Gateway API 这一标准。

文章插图
Gateway API 是一个面向角色分层的协议，通常像 AWS、GCP 这样的云厂商会充当基础设施提供者，他们会提供若干种不同可选的网关选型（GatewayClass）；而网关管理员，通常会创建不同的网关实例（Gateway）；更上层的开发者则只聚焦于如何创建路由来暴露自己的 API，而不关心底层的网关细节。
这种情况下就可以通过 APISIX Ingress 去使用 Gateway API 的方式进行各种配置，也就意味着你能够在各个不同的数据面进行切换。在今年年底，APISIX Ingress 将更加完整地支持 Gateway API 以及支持在四层和七层的更多能力。
与大多数服务网格方案不同，APISIX 的服务网格方案更有优势的地方是数据面（得益于 APISIX 本身的高性能），因此在控制面的选择上，更希望去兼容一些社区上已有的主流方案。最终采取了通过使用 xDS 协议与 Istio 进行交互，并将获取到的配置写入到 APISIX 的 xDS 配置中心的方式，来配合 APISIX 生成具体的路由规则，完成对应请求的路由。
这种方案不仅可以让整个服务网格更加轻量，同时借助于 APISIX 的高拓展性，也可以进行更方便地二次开发与迁移。
10.集成更多生态
【10大亮点！带你多角度了解云原生API网关Apache APISIX 3.0预览版】除了上文提到的 OpenAPI 标准之外，3.0 版本中也会新增非常多的生态插件，比如 OpenFunction、ClickHouse、Elasticsearch、SAML 和 CAS 等，去集成更对关于认证鉴权、安全或者可观测性等。
其中一个有趣的插件workflow是关于流量调度的，通过该插件就可以在流量控制层面进行一些更细粒度的处理。

文章插图
比如当条件 A 成立时执行某个行为，条件 B 成立时执行另一个行为等。通过这种更加清晰的方式，让用户更加方便地调度各种业务流量。
总结
不管是 APISIX 从零开始发展到现在，还是已经推出预览版的 3.0 版本，你会发现 APISIX 其实并没有在架构层面进行太多的调整与改动，更多的是进行生态、兼容性和产品应用层面的改变。
一个开源项目的评判标准，或许并不只有性能和功能，而是需要更多站在用户、开发者和企业的角度，去考虑他们使用这个产品是否可以快速有效地解决当下的痛点。
而本文中提到的亮点或者新特性，其实都是通过开源社区的大环境，接收了来自不同开发者或者企业用户的反馈而打造出来的，是他们让开源产品更加实用和充满活力。