借力 Amazon 实现 Apache APISIX 的生态探索与产品成长

{"value":"> 作者张超，Apache APISIX PMC 成员，API7.ai 技术专家。API7 Cloud 产品负责人，开源爱好者。本文整理自《亚马逊云科技——中国峰会》中的分享内容。\n\n## Apache APISIX\n\nApache APISIX 于 2019 年被两位创始人捐赠给 Apache 软件基金会孵化器，并于第二年 7 月从孵化器毕业，成为 Apache 顶级项目。APISIX 作为开源 API 网关，一直以活跃和快速成长的状态，在网关领域持续发光发热。\n\n### 性能优异，扩展丰富\n\n作为一个云原生 API 网关，APISIX 从诞生之日起就对性能层面有着高要求。\n\nAPISIX 在产品使用上，给用户最直接的表现就是**高性能与低延迟**。同时在功能方面，也有着丰富的流量治理能力，比如常用于后端服务的灰度发布、蓝绿发布。还有 API 安全层面的鉴权认证，APISIX 支持多种不同的鉴权方式，比如 JWT Auth、HMAC Auth 以及 Open ID Connect 协议等等。\n\n此外，APISIX 对于有着扩展和定制开发的开发者们也非常友好。除了 APISIX 自身支持的 Lua 语言外，你也可以借助 APISIX Plugin Runner 去使用一些高级语言对 APISIX 进行扩展，比如 Java、Go、Python 和 [WebAssembly](https://webassembly.org/)。有了多语言插件的加持，无需投入学习成本就可以轻易进行二次开发了。 \n\n### 生态多样，活跃开放\n\n目前 APISIX 在生态层面做了非常多的动作，基于各种不同类型的项目进行了集成开发，APISIX 主仓库目前已经拥有了超过 70+ 的插件。\n\n使用这些插件，你可以与类似**亚马逊云科技**这样的平台进行快速集成与使用落地，减少用户在使用过程中额外的开发成本。\n\n同时在社区中，APISIX 的月度贡献者活跃数量一般都维持在 30 人左右，这是一个非常活跃的数字。你可以看到在 APISIX 的 GitHub 中，每天都有社区用户帮忙回答或解决 Issue、PR 或者 Discussion 中的问题。良好的社区运作氛围，也带动着产品的快速迭代与生态的丰富扩展。\n\n因此，APISIX 也开始在全球范围内拥有多个领域的企业用户。比如空中云汇（跨境支付）、新浪微博、欧盟数字工厂、NASA、奈雪的茶等用户。得益于越来越多企业的使用与贡献，APISIX 也逐渐被大众看到。目前 APISIX 贡献者已突破 300 人，总项目贡献者也已超过 500 人。\n\n\n\n### 架构升级，取长补短\n\n回到产品架构层面，APISIX 的架构采用了数据面+控制面的模式，如下图所示。\n\n\n\n左侧为 APISIX 自身，也就是整个 API 网关的数据面，主要去承担和处理用户的真实业务流量。这其中 APISIX 会提供服务治理能力，比如限流限速、负载均衡等。右侧则是 API 网关的控制面，也就是控制 APISIX 运作的组件，包括像可观测性相关的日志组件等等，方便收集运行状态数据。同时搭配 etcd 与 Admin API，帮助用户去配置相关规则，进而让 APISIX 能够按照既定的方式运行。\n\n\n\n像上文提到的多语言插件就可以嵌入到左侧数据面结构内。比如通过 APISIX 内置 wasm plugin 模块允许用户去使用 C++ 或 Rust 语言进行扩展。而右边则是呈现了基于 Plugin Runner 的多语言方式，通过传统的 Unix domain socket 这种 RPC 的方式，调用相关语言的 Plugin Runner（比如 Java Plugin Runner）去接受来自于 APISIX 的请求，然后帮助 APISIX 去处理这些流量。\n\n## APISIX 基于 Amazon 的探索\n\n目前 APISIX 基于 Amazon 也进行了一些产品和性能层面的尝试。\n\n### Amazon Marketplace\n\n\n\n在 Amazon Marketplace 页面中搜索 APISIX 的话，你会发现如上图所示的结果。早在 2021 年，支流科技就将 APISIX 上架到了平台上。基于这个软件，你可以非常快速地把 APISIX 部署到 Amazon EC2 的实例中。同时这个软件费用为 0，你只需支付 EC2 实例的费用即可。\n\n该软件会在 EC2 实例中运行一个 APISIX 进行和 etcd 实例。因此，比较适用于本身就是 Amazon 的用户，当你想去试用 APISIX 或者是想用 POC 去验证 APISIX 是否满足一些目标场景的需求。\n\n### CDK APISIX\n\nCDK 是 Amazon 所提供的开源软件开发框架，旨在帮助用户通过编程的方式来操作云上的基础设施。\n\nAPISIX 社区的 committer [Pahud Hsieh](https://github.com/pahud) 基于此开发了 [cdk-apisix](https://github.com/pahud/cdk-apisix)。该项目允许用户通过可编程以及自动化的方式，去创建 APISIX 实例，与上文不一样的是，使用该项目可以把 APISIX 部署到 AWS Fargate 中。 这样就可以在一些需要有事件触发的场景下，去完成 APISIX 的部署与销毁。整个过程更加响应式，无需手动处理。\n\n\n\n从上方架构图中可以看到，客户端的流量进入后会经过云上的 ELB 将流量分发到 APISIX，之后 APISIX 会进行一些基本的处理，比如判断权限、限流限速应用等。然后会发到后端真正的应用实例上。\n\n使用 CDK 这种方式，可以方便用户使用自己熟悉的语言部署 Apache APISIX，并且借助这些高级语言的特性，可以更加方便地将 APISIX 部署到 Amazon。同时在使用层面，当你把编写好的一份部署模板配置完成后，可以将其复用或者定制。这就意味着在未来某个时刻，如果你需要再次去使用这样的场景模版时，可以直接拿来使用，从而减轻部署流程。\n\n### Amazon-Lambda 插件\n\n使用 Lambda 或者 Serverless 去部署应用时，可以以一种成本非常低的方式去运作相关业务，并且可以非常快速地实现扩缩容等业务场景。使用这种方式部署时，通常需要一个事件触发器，那么 API 网关就是一个可以作为触发器的通道。\n\n当用户在路由中配置了 APISIX 的`amazon-lambda` 插件后，它能够将流量全量地转发给用户所配置的 Lambda 函数地址，然后交由 Lambda 函数去处理请求，最终将由 APISIX 再次返回到客户端。\n\n该插件同时也支持 Amazon IAM 认证和 Key Auth。这样就可以保证在后端进行业务部署的 Lambda 函数，可以在不牺牲安全性的情况下，更好地与 APISIX 进行集成。\n\n### 相关性能测试\n\n在今年 5 月份，[AWS Graviton3](https://aws.amazon.com/cn/blogs/aws/new-amazon-ec2-c7g-instances-powered-by-aws-graviton3-processors/) 处理器正式推出。与 AWS Graviton2 处理器相比，基于领先的 DDR5 内存技术，Graviton3 处理器可提供高达 25% 的性能提升、高达 2 倍的浮点性能以及 50% 的内存访问速度；在性能与同类 EC2 实例相同的情况下，Graviton3 还可减少 60% 的能源。\n\n在 AWS Graviton3 推出不久，APISIX 就对此进行了完整的回归测试，这意味着用户可以非常放心地在 Graviton3 EC2 的实例上去使用 APISIX，并且不会存在任何兼容性问题。同时我们也在 AWS Graviton 系列处理器环境下进行了性能测试，通过两种场景，分别对 AWS Graviton2 和 AWS Graviton3 进行了性能测试：\n\n- 单个上游。该场景下使用单个上游（不包含任何插件），主要测试 APISIX 在纯代理回源模式下的性能表现。\n\n- 单上游+多插件。该场景下使用单上游与多插件配合，在这里使用了两个插件。主要测试 APISIX 在开启 `limit-count` 和 `prometheus` 两个核心消耗性能插件时的性能表现。\n\n\n\n可以看到，无论是稳定性还是流量处理层面，APISIX 的表现都十分亮眼。在 API 网关这样网络 IO 密集型的计算场景下，AWS Graviton3 比 AWS Graviton2 的性能提升了 76%，同时延迟还降低了 38%。这个数据比开头提到的 AWS 官方给出的数据（25%性能提升）还要优异。\n\n\n\n所以整体来说，在 Grafana 3 上使用 APISIX 时，它的整个性能表现是非常优异的。基于 AWS Graviton3 这种高性能的处理器，也能给我们在实际业务中提升效率，降低资源和使用成本。\n\n## API7 Cloud 如何借力 Amazon 实现产品快速成长\n\n云原生的兴起，使得越来越多企业将业务进行上云（往往是多种公有云平台）。在这种背景下，如何高效管理并部署云上的 API，变成了一个亟待解决的难题。\n\nAPI7 Cloud 是一款基于 APISIX 的 SaaS 服务，帮助用户连接部署在任意云上 API 的 SaaS 产品，于 2022 年 3 月份正式发布。它为用户提供了简单易用的 API 管理功能、灵活且丰富的可观测性指标以及 API 安全特性，让用户的 API 连接能够更加高效、安全与可靠。\n\n该产品是按照 API 调用次数来付费，目前支持两种数据面部署方式。一种是 self-host，即用户自己准备基础设施，将 APISIX 部署到自己的基础设施内，保持 APISIX 与 API7 Cloud 的通信。另一种是 semi-managed，也称为半托管，即用户需要授权 API7 Cloud 去使用他的云账户（比如 Amazon 账户），然后就可以在 API7 Cloud 的控制台上，一键部署 APISIX 到其账号下的某个基础设施。\n\n目前 API7 Cloud 的整套组件都是托管以及使用了 Amazon 服务的，产品架构如下图所示。\n\n\n\n从上图可以看到，数据面的 APISIX 可以部署在不同的云上，甚至是部署在用户自己的基础设施或数据中心中。API7 Cloud 这一侧则主要去提供类似可观测性、基础 API 管理和一些比较重要的 API 安全等特性。\n\n借助 Amazon 的一些服务，API7 Cloud 呈现了更好的产品表现。\n\n首先就是依赖于 Amazon EKS 服务。作为一个新的 SaaS 产品，API7 Cloud 在一开始就被部署在了 K8s 中。因此我们也希望能利用云上的一些能力，所以将所有组件部署在 EKS 集群中。同时每个用户可能会有一些不同的组件，独立的组件都需要运行在这个集群里面，所以我们也是使用了基于 NetWorkPolicy 的租户隔离方式，进行一些网络隔离，保证这些租户的 namespace 相互之间不可访问的。整套服务中，还借助了 APISIX Ingress Controller 作为网关，来顺利完成整套流程的运行。\n\n> APISIX Ingress Controller 是一个 Ingress 控制器的实现，可以将用户配置的规则转换为 APISIX 中的规则，从而使用 APISIX 完成具体的流量承载。\n\n其次作为产品中最重要的数据库组件，API7 Cloud 在这里选择了 Amazon RDS(PostgreSQL)。使用 RDS 主要是存储用户的元数据，包括类似于 API 的源数据或用户的行为数据等。因为作为一个 SaaS 产品，我们需要去关注一个用户是怎么使用产品的，以及通过这些数据来判断我们的产品是否在布局和开发者体验上存在问题，从而明确未来的产品决策方向。\n\n同时在 API7 Cloud 中，我们还使用了Amazon ElastiCache 组件，并选用了主从模式的 Redis。这主要用来保存数据面的实例状态，也就是 APISIX 在连接到 API7 Cloud 之后定期向 Cloud 发送的状态数据。因为这种状态数据本身并不是特别敏感或者重要的数据，并且数据面和控制面需要频繁交互，因此没有选择使用关系型数据库。\n\n此外该组件的另一个重要用途就是，作为消息队列。Redis 5.0 中引入了 Stream 数据结构，我们用它做了一个非常轻量的消息队列，帮助用户快速地完成数据的控制、创建和销毁。\n\n## 总结\n\n以上就是从 APISIX 相关产品视角带来的分享，通过借力 Amazon 各类产品的功能和生态加持，也使 APISIX 在生态领域的探索更进一步。未来也期待 APISIX 与 Amazon 能够有更多有趣的集成，共同创造一个蓬勃的生态。","render":"<blockquote>\n<p>作者张超，Apache APISIX PMC 成员，API7.ai 技术专家。API7 Cloud 产品负责人，开源爱好者。本文整理自《亚马逊云科技——中国峰会》中的分享内容。</p>\n</blockquote>\n<h2><a id=\"Apache_APISIX_2\"></a>Apache APISIX</h2>\n<p>Apache APISIX 于 2019 年被两位创始人捐赠给 Apache 软件基金会孵化器，并于第二年 7 月从孵化器毕业，成为 Apache 顶级项目。APISIX 作为开源 API 网关，一直以活跃和快速成长的状态，在网关领域持续发光发热。</p>\n<h3><a id=\"_6\"></a>性能优异，扩展丰富</h3>\n<p>作为一个云原生 API 网关，APISIX 从诞生之日起就对性能层面有着高要求。</p>\n<p>APISIX 在产品使用上，给用户最直接的表现就是<strong>高性能与低延迟</strong>。同时在功能方面，也有着丰富的流量治理能力，比如常用于后端服务的灰度发布、蓝绿发布。还有 API 安全层面的鉴权认证，APISIX 支持多种不同的鉴权方式，比如 JWT Auth、HMAC Auth 以及 Open ID Connect 协议等等。</p>\n<p>此外，APISIX 对于有着扩展和定制开发的开发者们也非常友好。除了 APISIX 自身支持的 Lua 语言外，你也可以借助 APISIX Plugin Runner 去使用一些高级语言对 APISIX 进行扩展，比如 Java、Go、Python 和 <a href=\"https://webassembly.org/\" target=\"_blank\">WebAssembly</a>。有了多语言插件的加持，无需投入学习成本就可以轻易进行二次开发了。</p>\n<h3><a id=\"_14\"></a>生态多样，活跃开放</h3>\n<p>目前 APISIX 在生态层面做了非常多的动作，基于各种不同类型的项目进行了集成开发，APISIX 主仓库目前已经拥有了超过 70+ 的插件。</p>\n<p>使用这些插件，你可以与类似<strong>亚马逊云科技</strong>这样的平台进行快速集成与使用落地，减少用户在使用过程中额外的开发成本。</p>\n<p>同时在社区中，APISIX 的月度贡献者活跃数量一般都维持在 30 人左右，这是一个非常活跃的数字。你可以看到在 APISIX 的 GitHub 中，每天都有社区用户帮忙回答或解决 Issue、PR 或者 Discussion 中的问题。良好的社区运作氛围，也带动着产品的快速迭代与生态的丰富扩展。</p>\n<p>因此，APISIX 也开始在全球范围内拥有多个领域的企业用户。比如空中云汇（跨境支付）、新浪微博、欧盟数字工厂、NASA、奈雪的茶等用户。得益于越来越多企业的使用与贡献，APISIX 也逐渐被大众看到。目前 APISIX 贡献者已突破 300 人，总项目贡献者也已超过 500 人。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/f7a00828fccd4436a815a45ac32d5426_image%20%2861%29.png\" alt=\"image 61.png\" /></p>\n<h3><a id=\"_26\"></a>架构升级，取长补短</h3>\n<p>回到产品架构层面，APISIX 的架构采用了数据面+控制面的模式，如下图所示。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/55efc667060f40f9b195adfe6ef796c2_image%20%2862%29.png\" alt=\"image 62.png\" /></p>\n<p>左侧为 APISIX 自身，也就是整个 API 网关的数据面，主要去承担和处理用户的真实业务流量。这其中 APISIX 会提供服务治理能力，比如限流限速、负载均衡等。右侧则是 API 网关的控制面，也就是控制 APISIX 运作的组件，包括像可观测性相关的日志组件等等，方便收集运行状态数据。同时搭配 etcd 与 Admin API，帮助用户去配置相关规则，进而让 APISIX 能够按照既定的方式运行。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/acf2b1c1e26c4013bfe6db0cb47bacfa_image%20%2863%29.png\" alt=\"image 63.png\" /></p>\n<p>像上文提到的多语言插件就可以嵌入到左侧数据面结构内。比如通过 APISIX 内置 wasm plugin 模块允许用户去使用 C++ 或 Rust 语言进行扩展。而右边则是呈现了基于 Plugin Runner 的多语言方式，通过传统的 Unix domain socket 这种 RPC 的方式，调用相关语言的 Plugin Runner（比如 Java Plugin Runner）去接受来自于 APISIX 的请求，然后帮助 APISIX 去处理这些流量。</p>\n<h2><a id=\"APISIX__Amazon__38\"></a>APISIX 基于 Amazon 的探索</h2>\n<p>目前 APISIX 基于 Amazon 也进行了一些产品和性能层面的尝试。</p>\n<h3><a id=\"Amazon_Marketplace_42\"></a>Amazon Marketplace</h3>\n<p><img src=\"https://dev-media.amazoncloud.cn/6ae292a78d6546e597f3d7800b925749_image%20%2864%29.png\" alt=\"image 64.png\" /></p>\n<p>在 Amazon Marketplace 页面中搜索 APISIX 的话，你会发现如上图所示的结果。早在 2021 年，支流科技就将 APISIX 上架到了平台上。基于这个软件，你可以非常快速地把 APISIX 部署到 Amazon EC2 的实例中。同时这个软件费用为 0，你只需支付 EC2 实例的费用即可。</p>\n<p>该软件会在 EC2 实例中运行一个 APISIX 进行和 etcd 实例。因此，比较适用于本身就是 Amazon 的用户，当你想去试用 APISIX 或者是想用 POC 去验证 APISIX 是否满足一些目标场景的需求。</p>\n<h3><a id=\"CDK_APISIX_50\"></a>CDK APISIX</h3>\n<p>CDK 是 Amazon 所提供的开源软件开发框架，旨在帮助用户通过编程的方式来操作云上的基础设施。</p>\n<p>APISIX 社区的 committer <a href=\"https://github.com/pahud\" target=\"_blank\">Pahud Hsieh</a> 基于此开发了 <a href=\"https://github.com/pahud/cdk-apisix\" target=\"_blank\">cdk-apisix</a>。该项目允许用户通过可编程以及自动化的方式，去创建 APISIX 实例，与上文不一样的是，使用该项目可以把 APISIX 部署到 AWS Fargate 中。 这样就可以在一些需要有事件触发的场景下，去完成 APISIX 的部署与销毁。整个过程更加响应式，无需手动处理。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/a20313bb352b43408892967e9bd8c8cd_image%20%2865%29.png\" alt=\"image 65.png\" /></p>\n<p>从上方架构图中可以看到，客户端的流量进入后会经过云上的 ELB 将流量分发到 APISIX，之后 APISIX 会进行一些基本的处理，比如判断权限、限流限速应用等。然后会发到后端真正的应用实例上。</p>\n<p>使用 CDK 这种方式，可以方便用户使用自己熟悉的语言部署 Apache APISIX，并且借助这些高级语言的特性，可以更加方便地将 APISIX 部署到 Amazon。同时在使用层面，当你把编写好的一份部署模板配置完成后，可以将其复用或者定制。这就意味着在未来某个时刻，如果你需要再次去使用这样的场景模版时，可以直接拿来使用，从而减轻部署流程。</p>\n<h3><a id=\"AmazonLambda___62\"></a>Amazon-Lambda 插件</h3>\n<p>使用 Lambda 或者 Serverless 去部署应用时，可以以一种成本非常低的方式去运作相关业务，并且可以非常快速地实现扩缩容等业务场景。使用这种方式部署时，通常需要一个事件触发器，那么 API 网关就是一个可以作为触发器的通道。</p>\n<p>当用户在路由中配置了 APISIX 的<code>amazon-lambda</code> 插件后，它能够将流量全量地转发给用户所配置的 Lambda 函数地址，然后交由 Lambda 函数去处理请求，最终将由 APISIX 再次返回到客户端。</p>\n<p>该插件同时也支持 Amazon IAM 认证和 Key Auth。这样就可以保证在后端进行业务部署的 Lambda 函数，可以在不牺牲安全性的情况下，更好地与 APISIX 进行集成。</p>\n<h3><a id=\"_70\"></a>相关性能测试</h3>\n<p>在今年 5 月份，<a href=\"https://aws.amazon.com/cn/blogs/aws/new-amazon-ec2-c7g-instances-powered-by-aws-graviton3-processors/\" target=\"_blank\">AWS Graviton3</a> 处理器正式推出。与 AWS Graviton2 处理器相比，基于领先的 DDR5 内存技术，Graviton3 处理器可提供高达 25% 的性能提升、高达 2 倍的浮点性能以及 50% 的内存访问速度；在性能与同类 EC2 实例相同的情况下，Graviton3 还可减少 60% 的能源。</p>\n<p>在 AWS Graviton3 推出不久，APISIX 就对此进行了完整的回归测试，这意味着用户可以非常放心地在 Graviton3 EC2 的实例上去使用 APISIX，并且不会存在任何兼容性问题。同时我们也在 AWS Graviton 系列处理器环境下进行了性能测试，通过两种场景，分别对 AWS Graviton2 和 AWS Graviton3 进行了性能测试：</p>\n<ul>\n<li>\n<p>单个上游。该场景下使用单个上游（不包含任何插件），主要测试 APISIX 在纯代理回源模式下的性能表现。</p>\n</li>\n<li>\n<p>单上游+多插件。该场景下使用单上游与多插件配合，在这里使用了两个插件。主要测试 APISIX 在开启 <code>limit-count</code> 和 <code>prometheus</code> 两个核心消耗性能插件时的性能表现。</p>\n</li>\n</ul>\n<p><img src=\"https://dev-media.amazoncloud.cn/6de8e15d8ca34f69a878a07bcf6ddadf_image%20%2866%29.png\" alt=\"image 66.png\" /></p>\n<p>可以看到，无论是稳定性还是流量处理层面，APISIX 的表现都十分亮眼。在 API 网关这样网络 IO 密集型的计算场景下，AWS Graviton3 比 AWS Graviton2 的性能提升了 76%，同时延迟还降低了 38%。这个数据比开头提到的 AWS 官方给出的数据（25%性能提升）还要优异。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/67089ba2cdd646de9b81d339376a2bc8_image%20%2867%29.png\" alt=\"image 67.png\" /></p>\n<p>所以整体来说，在 Grafana 3 上使用 APISIX 时，它的整个性能表现是非常优异的。基于 AWS Graviton3 这种高性能的处理器，也能给我们在实际业务中提升效率，降低资源和使用成本。</p>\n<h2><a id=\"API7_Cloud__Amazon__88\"></a>API7 Cloud 如何借力 Amazon 实现产品快速成长</h2>\n<p>云原生的兴起，使得越来越多企业将业务进行上云（往往是多种公有云平台）。在这种背景下，如何高效管理并部署云上的 API，变成了一个亟待解决的难题。</p>\n<p>API7 Cloud 是一款基于 APISIX 的 SaaS 服务，帮助用户连接部署在任意云上 API 的 SaaS 产品，于 2022 年 3 月份正式发布。它为用户提供了简单易用的 API 管理功能、灵活且丰富的可观测性指标以及 API 安全特性，让用户的 API 连接能够更加高效、安全与可靠。</p>\n<p>该产品是按照 API 调用次数来付费，目前支持两种数据面部署方式。一种是 self-host，即用户自己准备基础设施，将 APISIX 部署到自己的基础设施内，保持 APISIX 与 API7 Cloud 的通信。另一种是 semi-managed，也称为半托管，即用户需要授权 API7 Cloud 去使用他的云账户（比如 Amazon 账户），然后就可以在 API7 Cloud 的控制台上，一键部署 APISIX 到其账号下的某个基础设施。</p>\n<p>目前 API7 Cloud 的整套组件都是托管以及使用了 Amazon 服务的，产品架构如下图所示。</p>\n<p><img src=\"https://dev-media.amazoncloud.cn/5d93048af7444d57be61ae08258b4e80_image%20%2868%29.png\" alt=\"image 68.png\" /></p>\n<p>从上图可以看到，数据面的 APISIX 可以部署在不同的云上，甚至是部署在用户自己的基础设施或数据中心中。API7 Cloud 这一侧则主要去提供类似可观测性、基础 API 管理和一些比较重要的 API 安全等特性。</p>\n<p>借助 Amazon 的一些服务，API7 Cloud 呈现了更好的产品表现。</p>\n<p>首先就是依赖于 Amazon EKS 服务。作为一个新的 SaaS 产品，API7 Cloud 在一开始就被部署在了 K8s 中。因此我们也希望能利用云上的一些能力，所以将所有组件部署在 EKS 集群中。同时每个用户可能会有一些不同的组件，独立的组件都需要运行在这个集群里面，所以我们也是使用了基于 NetWorkPolicy 的租户隔离方式，进行一些网络隔离，保证这些租户的 namespace 相互之间不可访问的。整套服务中，还借助了 APISIX Ingress Controller 作为网关，来顺利完成整套流程的运行。</p>\n<blockquote>\n<p>APISIX Ingress Controller 是一个 Ingress 控制器的实现，可以将用户配置的规则转换为 APISIX 中的规则，从而使用 APISIX 完成具体的流量承载。</p>\n</blockquote>\n<p>其次作为产品中最重要的数据库组件，API7 Cloud 在这里选择了 Amazon RDS(PostgreSQL)。使用 RDS 主要是存储用户的元数据，包括类似于 API 的源数据或用户的行为数据等。因为作为一个 SaaS 产品，我们需要去关注一个用户是怎么使用产品的，以及通过这些数据来判断我们的产品是否在布局和开发者体验上存在问题，从而明确未来的产品决策方向。</p>\n<p>同时在 API7 Cloud 中，我们还使用了Amazon ElastiCache 组件，并选用了主从模式的 Redis。这主要用来保存数据面的实例状态，也就是 APISIX 在连接到 API7 Cloud 之后定期向 Cloud 发送的状态数据。因为这种状态数据本身并不是特别敏感或者重要的数据，并且数据面和控制面需要频繁交互，因此没有选择使用关系型数据库。</p>\n<p>此外该组件的另一个重要用途就是，作为消息队列。Redis 5.0 中引入了 Stream 数据结构，我们用它做了一个非常轻量的消息队列，帮助用户快速地完成数据的控制、创建和销毁。</p>\n<h2><a id=\"_114\"></a>总结</h2>\n<p>以上就是从 APISIX 相关产品视角带来的分享，通过借力 Amazon 各类产品的功能和生态加持，也使 APISIX 在生态领域的探索更进一步。未来也期待 APISIX 与 Amazon 能够有更多有趣的集成，共同创造一个蓬勃的生态。</p>\n"}