使用 OpenAPI 克服微服务与 Kubernetes 的挑战。API 赋能现代组织。
使用 OpenAPI 克服微服务与 Kubernetes 的挑战
API 赋能现代组织。
API 优先的开发策略正在不断增加，以满足当今技术赋能消费者的数字需求。为什么？因为组织必须快速响应市场变化。为了变得更加敏捷，许多组织已转向更易于消费的架构方法。
微服务架构是一种专注于具有明确接口的单一功能模块的软件开发方法，它支持敏捷和去中心化的工作流，以提供更小的可消费能力。
与此同时，基于容器的技术正被广泛采用来部署和托管微服务。Kubernetes 作为容器编排系统，是处理微服务管理、扩展和部署的流行选择。
但是，采用这些模式和技术并不能保证 API 策略的成功。在提供一致质量的同时实现足够的规模并非易事。投资甚至可能需要时间才能开花结果——例如 SoundCloud 使用绞杀者模式从单体架构历时八年的迁移之旅。
话虽如此，让我们探讨几个方面，它们将使您处于最佳位置来掌控自己的未来。
API、微服务、Kubernetes 的挑战
零散的 API 交付方法会导致 API 混乱，并阻碍数字化发展。
许多组织中一个普遍的问题是，大量未文档化的 API 支撑着系统集成。这会导致 API 质量不一致、开发者体验不佳以及潜在的安全问题。
Kubernetes 抑制了 API 的无序扩张，但也带来了自身的挑战。Kubernetes Ingress 的声明性意味着它是配置驱动的。Ingress 规范描述了这些配置，但该规范缺乏在生产环境中可靠暴露 API 所需的许多功能。为了克服这些限制，Kubernetes 生态系统中的许多控制器都有自己指定功能配置选项的方法。
由于这些挑战，组织难以提供最佳的开发者体验、保持 API 质量以及控制其 Kubernetes 配置的一致性。一些挑战是由交付过程中的工作流冲突以及团队结构引起的。例如，Ingress 控制器的操作配置通常由运维人员执行，而 API 的功能演进则由开发人员完成。这种协调开销可能导致瓶颈或生产问题。
使用 OpenAPI 实现设计优先的功能和操作一致性
采用设计优先的方法可以改进您的 API 项目。通过涵盖服务的S功能和操作方面，并利用 OpenAPI 规范，团队可以在以质量为中心的协作式 API 工作流中从设计阶段推进到部署阶段。
在深入探讨这种方法的好处之前，我们先来了解其术语。
什么是 OpenAPI？
OpenAPI 规范 (OAS)，前身为 Swagger 规范，定义了一个与语言无关的基于 HTTP 的 API 标准接口。OAS 允许人机在无需访问源代码、文档或检查网络流量的情况下理解服务的功能。
像 OpenAPI 这样的 API 规范不仅仅是描述 API 的外观。消费者可以用最少的实现逻辑来理解和与远程服务交互。对于 API 的提供者端也是如此，利益相关者可以更有效地沟通任何服务所提供的价值主张。
图1 – OpenAPI 驱动 API 生命周期
使用 API 定义有助于自动化 API 生命周期中的许多环节，包括客户端和服务器代码生成、API 实现模拟、测试自动化以及讲述 API 的故事。这种自动化潜力减少了 API 生产者和消费者两侧 DevOps 周期中的浪费。
API 和微服务——有什么区别？
这些术语经常被交替使用，但它们并不相同。
API 代表 *应用程序编程接口*。API 是服务、能力或数据的接口。可编程接口促进了软件应用程序和组件之间的连接与通信，同时隐藏了实现细节。API 是软件的*语言*。
微服务完全关乎实现。微服务架构是一种实现模式，它促进了自包含组件的交付。这些组件可以独立更新和演进。API 可以独立于微服务而存在！大多数组织没有从零开始的奢侈条件，因此他们的 API 策略包括从单体到微服务方法的 API 交付演进。
图2 – 典型的单体到微服务演进方法
微服务是 API 数量增长的主要催化剂。
什么是 Kubernetes？
Kubernetes，也称为 K8s，是一个可移植、可扩展的开源平台，用于管理容器化工作流和服务。它使用“Pods”和“Labels”的概念，将构成应用程序的容器分组为逻辑单元，以便于管理和发现。
图3 – Kubernetes 架构（灰色为容器，彩色为 Pod），© Google Inc
Kubernetes 由谷歌开发，并捐赠给了云原生计算基金会 (CNCF)。
什么是 API 网关？
API 网关是 API 管理策略的一部分。它充当您 API 资产的入口。网关拦截客户端与 API 之间的请求和响应流量，并执行许多常见活动。具体功能各异，但路由、映射、速率限制、身份验证、转换、验证、分析和计费等功能都是可行的。
什么是 Ingress 和 Ingress 控制器？
通常，服务和 Pod 具有只能通过内部集群网络路由的 IP。所有到达边缘路由器的流量要么被丢弃，要么被转发到其他地方。
Kubernetes Ingress 是一个 API 对象，它描述了进入 Kubernetes 集群内部运行服务的传入流量（通常是 HTTP 或 HTTPS）的外部访问路由规则。创建 Ingress 是为了方便外部客户端（位于集群外部）通过稳定且外部可访问的 URL 访问集群内部的应用程序。
图4 – 简单 Ingress – ©Kubernetes.io
Ingress 控制器提供实际的 Ingress 实现，并且 Ingress 资源需要运行中的控制器才能工作。Ingress 控制器是 Pod，就像集群中的任何其他应用程序一样，并且可以查看其他 Pod。控制器可以检查传入请求并执行某些规则，例如路由，如 Ingress 清单中所指定。Ingress 控制器类似于 API 网关。
云环境使得 API 标准化既必要又棘手
行业研究表明，标准化、治理和安全性是重大挑战。随着云原生环境的采用，强制执行 API 产品的操作层面标准化与功能元素同等重要，以确保整体开发者体验，同时保持对分布式组织格局的监督。这可以带来卓越的开发者体验，同时保持对分布式组织格局的监督。
SmartBear 最近与 Kubeshop 的朋友合作，展示了如何结合 SwaggerHub 和 Kusk 来为您的 API 推广一个单一事实来源。
实现快速、协作和标准化的 API 设计是 SwaggerHub 的强项。它使遵守 OpenAPI 和您的组织自定义规则（或样式指南）变得简单直观。将 SwaggerHub 与 Kubeshop 的 x-kusk 扩展结合使用，为团队提供了一个用于操作和管理在 Kubernetes 中运行的 API 访问的单一事实来源。
x-kusk 扩展支持直接通过 OpenAPI 定义声明 API 的各种运行时特定内容，以统一的方式实现，且与所选的集群技术无关。
可以直接通过定义指定以下内容
- 超时/重试
- CORS
- 禁用路径/操作（例如，在外部暴露之前隐藏管理员路径）
- 模拟
- 验证
- 集群特定属性
图5 – OpenAPI 的 Kusk 扩展示例
使用相同的 SwaggerHub API 编辑器，团队可以在熟悉的工具中配置 Ingress 路由和其他操作细节。此外，SwaggerHub 允许您在设计阶段对操作配置应用标准化，并为验证、模拟和路由级别设置等功能奠定基础。
当 API 准备好发布到 Kusk 网关时，团队知道运行时设置将与早期阶段验证的内容相匹配。
典型的 SwaggerHub 和 Kusk 网关工作流如下
- 与所有相关利益相关者在 SwaggerHub 中协作设计您的 API
- 使用 SwaggerHub 的标准强制执行功能，确保 x-kusk 扩展正确到位
- 使用 SwaggerHub GitHub 集成同步/推送您已验证的定义（到 GitHub）
- 使用 CI/CD 自动化 API 定义到 Kusk 网关的部署，并确保实现已到位
- 从移动/Web/第三方应用程序发布和使用您的 API
拥抱 API 标准，确保整个组织的一致性
随着 API 吞噬软件世界，以及微服务征服单体架构的领域，掌控 API 和微服务资产的功能和操作方面变得前所未有的重要。
免费亲身体验：尝试 SwaggerHub，建立您的标准并启动敏捷策略。
为什么需要 API 标准？组织收益
- 功能和操作方面的集中表示（单一事实来源）
- 整个团队（业务、开发、测试、安全、运维）的协作设计
- 微服务的外部化方法——关注消费者体验和一致性
- 标准化和治理——确保整个组织的可发现性和一致性；在周期早期验证/断言操作方面的能力
- 拥抱迭代开发——支持从设计到部署的自动化工作流；减少瓶颈
了解更多
- 按需网络研讨会 – Kubeshop 首席技术官、前 OpenAPI 主席 Ole Lensmar 与 SmartBear API 技术布道师 Frank Kilcommins 探讨了使用微服务和 Kubernetes 扩展 API 项目的挑战，以及 OpenAPI 在平息混乱中可以发挥的作用。
- 分步指南博客（来自 Kubeshop 团队） – 使用 SwaggerHub、Kusk 和 OpenAPI，通过您选择的 Kubernetes 集群，实现从设计优先到 API 自动化部署。