微服务和 Kubernetes：使用 OpenAPI 实现功能和操作的一致性

使用 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 配置的一致性方面举步维艰。一些挑战是由交付过程以及团队结构中的工作流程竞争引起的。例如，入口控制器的操作配置通常由运维人员执行，而 API 的功能演变则由开发人员完成。协调开销会导致瓶颈或生产问题。

使用 OpenAPI 实现设计优先的功能和操作一致性

应用设计优先的方法可以改进您的 API 项目。通过包含服务的操作和功能方面，并利用 OpenAPI 规范，团队可以在以质量为中心的协作 API 工作流程中从设计进展到部署。

在深入探讨该方法的好处之前，让我们先了解一下它的术语。

什么是 OpenAPI？

OpenAPI 规范 (OAS)，以前称为 Swagger 规范，定义了一个标准的、与语言无关的 HTTP API 接口。OAS 允许人类和计算机在无需访问源代码、文档或网络流量检查的情况下了解服务的功能。

像 OpenAPI 这样的 API 规范不仅可以记录 API 的外观。消费者可以以最少的实现逻辑来理解和与远程服务交互。在 API 的提供者方面也是如此，因为利益相关者可以更有效地沟通任何服务提供的价值主张。

使用 API 定义可以帮助自动化 API 生命周期中的许多环节，包括客户端和服务器代码生成、模拟 API 的实现、测试自动化以及讲述 API 的故事。这种自动化潜力减少了 API 生产者和消费者端的 DevOps 周期中的浪费。

API 和微服务 – 有什么区别？

这些术语经常互换使用，但它们并不相同。

API 代表应用程序编程接口。API 是服务、功能或数据的接口。可编程接口促进软件应用程序和组件之间的连接和通信，同时隐藏实现细节。API 是软件的语言。

微服务全部关于实现。微服务架构是一种实现模式，它促进了自包含组件的交付。这些组件可以独立更新和演进。API 可以存在而无需微服务！大多数组织没有从头开始的奢侈，因此他们的 API 策略包括从单体到微服务方法的 API 交付演变。

微服务是 API 数量增加的主要催化剂。

什么是 Kubernetes？

Kubernetes，也称为 K8s，是一个可移植、可扩展和开源的平台，用于管理容器化的工作流程和服务。它使用“pod”和“标签”的概念将构成应用程序的容器分组到逻辑单元中，以便于管理和发现。

Kubernetes 由 Google 开发，并将其捐赠给了云原生计算基金会 (CNCF)。

什么是 API 网关？

API 网关是 API 管理策略的一部分。它充当您 API 资产的前门。网关拦截客户端和 API 之间的请求和响应流量，并执行许多常见活动。具体功能各不相同，但路由、映射、速率限制、身份验证、转换、验证、分析和计费都是可能的。

什么是 Ingress 和 Ingress 控制器？

通常，服务和 Pod 具有只能通过内部集群网络路由的 IP 地址。所有最终到达边缘路由器的流量都会被丢弃或转发到其他地方。

Kubernetes Ingress 是一个 API 对象，它描述了进入 Kubernetes 集群内运行的服务的传入流量（通常是 HTTP 或 HTTPS）的外部访问路由规则。创建 Ingress 的目的是为了使外部客户端（驻留在集群之外）能够通过稳定且可外部寻址的 URL 轻松访问集群内的应用程序。

Ingress 控制器提供了实际的 Ingress 实现，并且需要一个正在运行的控制器才能使 Ingress 资源工作。Ingress 控制器是 Pod，就像集群中的任何其他应用程序一样，可以看到其他 Pod。控制器可以检查传入的请求并执行某些规则，例如按照 Ingress 清单中指定的路由。Ingress 控制器类似于 API 网关。

云使 API 标准变得必要 - 而且很棘手

行业研究表明，标准化、治理和安全性是重大挑战。随着云原生环境的采用，强制执行 API 产品操作方面的标准化与功能要素同等重要，这既要保证整体的开发者体验，同时也要保持对分布式组织环境的监督。它可以带来卓越的开发者体验，同时保持对分布式组织环境的监督。

SmartBear 最近与我们在 Kubeshop 的朋友合作，展示了如何将 SwaggerHub 和 Kusk 结合起来，为您的 API 推广 单一事实来源。

SwaggerHub 最擅长的是实现快速、协作和标准化的 API 设计。它使遵守 OpenAPI 和您的组织自定义规则（或样式指南）变得简单直观。将 SwaggerHub 和 Kubeshop 的 x-kusk 扩展相结合，为团队提供了一个用于操作和管理对 Kubernetes 中运行的 API 的访问的单一事实来源。

x-kusk 扩展支持直接使用 OpenAPI 定义以统一的方式声明 API 的各种运行时细节，而无需考虑选择的集群技术。

可以使用定义直接指定以下内容

• 超时/重试
• CORS
• 禁用路径/操作（例如，在外部公开之前隐藏管理路径）
• 模拟
• 验证
• 特定于集群的属性

使用相同的 SwaggerHub API 编辑器，团队可以在熟悉的工具中配置 Ingress 路由和其他操作细节。此外，SwaggerHub 允许您在设计期间应用操作配置的标准化，并为验证、模拟和路由级设置等功能奠定基础。

当 API 准备好发布到 Kusk 网关时，团队知道运行时设置将与早期阶段验证的设置匹配。

典型的 SwaggerHub 和 Kusk 网关工作流程是

1. 与所有相关利益相关者协作在 SwaggerHub 中设计您的 API
2. 使用 SwaggerHub 标准执行来确保 x-kusk 扩展正确就位
3. 使用 SwaggerHub GitHub 集成来同步/推送您验证的定义（到 GitHub）
4. 使用 CI/CD 自动化将 API 定义部署到 Kusk 网关，并确保实现到位
5. 从移动/Web/第三方应用程序发布和使用您的 API

采用 API 标准以确保整个组织的一致性

随着 API 消耗软件世界，微服务征服整体式领域，控制 API 和微服务资产的功能和操作方面从未如此重要。

免费亲身体验一下：尝试 SwaggerHub 让您的标准就位，并启动敏捷策略。

为什么要有 API 标准？组织优势

• 功能和操作方面的集中表示（事实来源）
• 整个团队（业务、开发、测试人员、安全、运维）之间的协作设计
• 微服务的由外而内方法 – 关注消费者体验和一致性
• 标准化和治理 – 确保整个组织的可发现性和一致性；能够在周期的早期验证/断言操作方面
• 拥抱迭代开发 – 支持从设计到部署的自动化工作流程；减少瓶颈

了解更多信息

• 点播网络研讨会 – Kubeshop 的 CTO 兼前 OpenAPI 主席 Ole Lensmar 和 SmartBear 的 API 技术布道者 Frank Kilcommins 探讨了使用微服务和 Kubernetes 扩展 API 程序所面临的挑战，以及 OpenAPI 在平息混乱方面可以发挥的作用。
• Kubeshop 团队的逐步演练博客 – 使用 SwaggerHub、Kusk 和 OpenAPI 以及您选择的 Kubernetes 集群，从设计优先到自动化部署 API。