API 之旅的三个阶段
原文作者:Andrew Stiefel- F5 产品营销经理转载来源: NGINX 中文官网
NGINX 唯一中文官方社区 ,尽在 nginx.org.cn
近 20 年来,每家使用软件的企业都逐步踏上了 API 采用之旅。这条路径已经成为应用开发领域的大势所趋,API 也已是技术交互和交易的主要方式。
谈起 API 采用挑战,很多人就急着介绍其单体式、一体化平台,殊不知这种大而无当的技术方案早已过时。受云原生应用发展趋势的影响,在安全防护“左移”的推动下,开发人员、网站可靠性工程师 (SRE)、DevOps 和平台工程团队已与这种自上而下的 API 解决方案渐行渐远。
云原生技术人员更倾向于选择构建适合自己需求的 API 堆栈。这些堆栈结合使用开源、专有和内部产品来打造一套可持续且可扩展的解决方案集,用于管理日益增长的 API,同时加速 API 开发进程。
企业的 API 堆栈采用进程往往大同小异,可被描绘成一个包含三个不同阶段的框架。每个阶段都有一系列问题、流程和实践,需要大多数企业在升级其现有基础设施时认真对待。
阶段 1:起步
在第一个阶段,企业刚刚开始涉足 API领域。在大多数情况下,技术团队以临时使用的方式用 API 来连接外部系统,以引入更高效的外部服务,或者满足合作伙伴和客户希望通过 API 连接和交换信息的需求。
API 采用第一阶段的特点是 API 实践不一致,有时甚至杂乱无章,企业可能只是应需采用 API。在这一阶段,工程师的工作重点是处理南北向 API 流量、建立连接和实现外部系统之间的通信。设计重点是将 API 与现有系统(比如第三方服务或外部合作伙伴)相集成,以促进数据交换并实现跨不同平台的功能。通常,架构师尚未部署微服务或 Kubernetes,而且可能没有使用完全分布式系统。
在这个不成熟的阶段,工程师通常没有标准化的 API 设计原则——不同的团队可能在没有决策协调的情况下构建自己的基础设施(部署网关、基本安全防护等)。这往往会导致临时抱佛脚,只为满足即时的集成需求,却造成了长期的技术债务。
阶段 2:设定发展路线
在迈向完整 API 堆栈的进程中,API 采用的第二个阶段是制定企业级 API 策略。通常,这意味着公司已经认识到 API 将成为其架构的重要组成部分,于是在规划和资源方面,API 开始像应用开发、数据库、网络和安全防护一样被严肃对待。此时,利益相关者(开发人员、DevOps、SRE、平台运维以及安全和网络团队)认识到,需要在整个企业内采用结构化、协调一致的 API 管理方法。
在这一阶段,南北向 API 是应用堆栈的重要组成部分,同时东西向 API 越来越受到关注。公司可能会采用一些(或许多)云原生应用的构建方式,包括微服务或无服务器架构并有可能采用分布式容器编排系统。随着公司不断朝着 API 优先架构的方向迈进,标准化需求悄然产生。一个日益受到关注的问题是如何管理内部 API,并为开发人员提供工具,从而以一种松散耦合的方式设计、构建、部署、管理和保护内部 API 。
微服务通常是这一阶段的催化剂。团队将单体应用分解成可独立开发、部署和扩展的小型应用,并通过 API 进行链接和管理这些微服务。这种分解可提高系统的可维护性、可扩展性和敏捷性。在这一阶段,工程师专注于根据企业总体架构目标设计 API,提高可重用性,并对 API 开发、文档编制、安全防护和版本控制实施标准化实践。
阶段 3:腾飞
此时,企业已经有了一套日渐成熟的 API 策略和方法。利益相关者已经从承认 API 优先的重要性转变为将 API 优先作为首要运维任务。在这一阶段,工程师们采用 API 优先的方法来开发新应用或升级现有应用。API 被设计和开发为应用和架构规划流程的一部分,以便与底层系统、基础设施和后端或数据应用紧密集成。该方法强调了定义明确、记录完善且可重用的 API 的重要性,旨在将这些 API 部署为可扩展、可互操作系统的基础。
在第三个阶段,团队要为各种 API(包括内部、合作伙伴、第三方和(如适用)公共 API)制定全面的方法和治理实践。这些治理实践可确保整个企业的 API 设计、安全防护、版本控制和生命周期管理保持一致,从而实现与外部利益相关者的高效协作和紧密集成。理想情况下,得益于 API 创建的基线模式和针对不同 API 类别设置的策略类型,这在很大程度上这部分工作可以实现自动化。
由于 API 堆栈具有灵活性和松散耦合性,因此在这一阶段,平台运维团队应评估可帮助企业改进 API 系统的新技术,例如 GraphQL 等新格式、用于自动更新文档的生成式 AI 工具,以及可生成 API 友好代码的即购即用型 Denon 等语言。
API 技术栈从成熟走向敏捷
API 项目进入第三个阶段后,通常已积蓄了巨大的发展惯性。API 不仅是关键任务组件,而且还是企业的基础技术架构。开发人员、DevOps、SRE、安全和网络团队都已成为利益相关者,并参与其中。平台运维团队现在将 API 视为其职责的重要组成部分,以及持续取得成功的关键因素。
新 API 堆栈的优点在于支持轻松更换组件或修改方法,而不会造成重大中断或停机。所有云原生的敏捷性实践都可应用于 API,包括 A/B 部署、蓝绿部署和灰度部署。到达第三个阶段后,您将具备足够的敏捷性,可应对未来 API 旅程中的任何波折。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
VTS:基于Apache SeaTunnel的开源向量数据迁移工具
引言 VTS(Vector Transport Service),全称向量传输服务,是一个由Zilliz开发的专注于向量和非结构化数据迁移的开源工具。VTS的核心特点在于其基于Apache SeaTunnel开发,这一事实使其在数据处理和迁移方面具有显著的优势。Apache SeaTunnel作为一个分布式数据集成平台,以其丰富的连接器系统和多引擎支持而闻名,VTS正是在此基础上,进一步扩展了其在向量数据库迁移和非结构化数据处理的能力。 VTS:基于Apache SeaTunnel的开源向量数据迁移工具 什么是向量数据库 向量数据库是一种专门用于存储和检索向量数据的 数据库系统: • 它能够高效处理高维向量数据,支持相似性搜索 • 支持KNN(K-近邻)搜索 • 计算向量间的距离(欧氏距离、余弦相似度等) • 快速检索最相似的向量 • 主要用于AI和机器学习应用场景 • 图像检索系统 • 推荐系统 • 自然语言处理 • 人脸识别 • 相似商品搜索 开发动力和背景 作为领先的向量数据库服务提供商,Zilliz 深知开发出色的 AI 应用离不开数据本身。然而,在有效处理 AI 应用中的非结...
- 下一篇
分布式API设计 上
背景 当作为一个架构师,选择分布式API框架,你需要注意哪些事项 当你作为一个服务提供者,提供分布式API,你需要注意哪些事项,至少有10点。 当你需要调用一个分布式API,你需要注意哪些事项,至少有10点。 当调用出现故障或者性能优化问题,有哪些思路解决 分布式API 软件世界,是通过API互相链接,这些API或者是进程内的API,或者是分布式API,通过这些API,构造出精彩的复杂的企业应用,互联网世界,物联网世界。学习完本节后,当你是调用一个分布式API的时候,你会掌握API调用最佳实践,当你提供一个分布式API时候,你会清楚API设计原则,本章覆盖如下内容 分布式API的技术选型 REST API 设计原则 (参考 远程调用API设计 下:REST,待定) 面向架构质量的设计 我们知道,架构主要目标是对软件系统分解成较小更容易实现的元素,如模块或者子系统,并能让这些元素协同完成业务需求,对于通常的程序员视角来说,架构貌似就是画几个框,然后连上线即可。 如下是一个分布式系统最简单的架构。看着很简单的俩框一线,但架构师却需要考虑的非常多,这也是架构师和普通程序员区别 A 服务...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- Docker安装Oracle12C,快速搭建Oracle学习环境
- CentOS7安装Docker,走上虚拟化容器引擎之路
- Linux系统CentOS6、CentOS7手动修改IP地址
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Hadoop3单机部署,实现最简伪集群
- CentOS6,7,8上安装Nginx,支持https2.0的开启