API网关
为 Apache APISIX 增加后端支持 从 ADC 0.11 开始，引入了对 Apache APISIX 后端的实验性支持。ADC 现在与 APISIX Admin API 集成，实现了高效的资源导出和同步。ADC 中默认启用了 apisix 后端选项，用户只需配置 Admin API 端点和 API 密钥即可连接。
ADC 与 Admin API 的区别 请注意，ADC 并不旨在完全覆盖 APISIX 的所有功能，而是专注于核心功能集和最佳实践。我们相信，投资于用户真正需要的功能，而不是盲目追求全面覆盖，才是 ADC 发展的正确路径。
尽管 APISIX 提供了高度的配置灵活性，但这种自由往往伴随着长期维护的复杂性。当配置管理从一个维护者转交给另一个时，新的维护者通常会面临理解前任维护者独特配置方法和风格的挑战，而不是直接采用一套成熟且广泛认可的最佳实践规则。
例如，在一个产品服务中，我们定义了一个名为“Product Service”的服务，并配置了上游、启用插件以及设置路由。在这种模型中，多个路由可以共享相同的上游和插件配置，大大简化了配置过程。
yaml复制代码services:
- name: Product Service
upstream:
type: roundrobin
nodes:
- host: product.ecommerce.svc.cluster.local
port: 443
weight: 100
scheme: https
plugins:
key-auth: {}
routes:
- name: List Products
uris:
- /products
methods: ["GET"]
- name: Get Product
uris:
- /product/*
methods: ["GET"]
以上示例是服务定义的最小格式。除此之外，ADC 还支持服务发现、超时设置、重试策略和路由优先级等高级功能，确保配置的全面性和灵活性。
鉴于 APISIX 支持更丰富的配置方法，ADC 在导出配置时，可能与 APISIX Admin API 显示的内容存在不一致，例如：
不使用服务的路由将被聚合到一个服务中，以符合服务-路由层级结构。
通过 ID 引用的上游将在使用时内联。
插件模板资源将被替换为包含路由的服务。
因此，用户需要仔细审查导出过程中生成的 ADC 定义文件，以确保它们仍然符合原始意图。
为什么推荐使用 ADC？ 使用 APISIX Dashboard 时，用户通常需要在表单中执行重复操作，这既繁琐又容易出错。相比之下，使用 ADC 进行声明式配置只需编写 YAML 文件并执行同步操作。ADC 会自动将配置转换为 Admin API 调用，实现快速部署和管理。
因此，ADC 可以帮助简化管理和部署流程，并轻松实现 GitOps 场景。这涉及通过 Git 仓库管理 YAML 定义文件，并使用 PR 工作流和 CI 工具自动更新配置。这显著减少了所需的手动操作，避免了 APISIX Dashboard 中的问题，并减少了编写调用 Admin API 脚本的复杂性。
对于新项目，我们强烈建议从 ADC 开始构建网关配置。对于现有项目，可以通过导出和适度修改配置，逐步迁移到 ADC 管理。
API7 企业版的后端优化 包含在 0.11/0.12 版本中 在 0.11 和 0.12 版本中，我们对 API7 后端进行了多项优化，以提升开发者体验。ADC 完全兼容这些改进，开发者只需保持 ADC 版本最新，即可在无需修改现有定义文件的情况下受益。
优化 ADC 定义检查 包含在 0.12 版本中 我们全面优化并修复了 ADC 定义检查的模式规则，帮助开发者提前检测并有效避免潜在的配置问题。
JSON Schema 此外，我们现在支持将验证规则导出为 JSON Schema，以协助使用 IDE 的编辑器。用户将受益于语法提示和文件中的实时检查，大大提高编码效率和质量。
对于喜欢使用 Visual Studio Code 的开发者，启用 YAML 插件并在文件顶部添加以下注释，将激活此功能：
yaml 复制代码 # yaml-language-server: $schema=https://raw.githubusercontent.com/api7/adc/main/schema.json
结论 如我们在之前的博客中提到的那样，ADC 最终将开源。经过六个月的内部开发和多次迭代，ADC 已完全重构为基于 TypeScript 的代码库，彻底抛弃了原来的 Go 代码。这使其更易于学习和开发。
随着 ADC 0.12 版本的公开发布，我们邀请全球开发者参与其开发和改进。代码库现已开放，网址为：，我们期待您的贡献。