API发展历程是怎样的？

想要了解相关问题，可以下载报告《API安全能力建设桔皮书》查看，以下内容都是根据该报告总结的，仅供参考。

API（Application Programming Interface，应用程序接口）是 一种计算接口，定义了软件之间的数据交互方式、功能类型。随着互 联网的普及和发展，API 从早期的软件内部调用的接口，扩展到互联 网上对外提供服务的接口。调用者通过调用 API，可以获取接口提供 的各项服务，而无须访问源码，也无须理解内部工作机制的细节。

API服务的发展历程可以看作企业数字化过程中系统集成需求不 断变化的过程。

21 世纪初期，随着 ERP、CRM 等企业内部管理系统的普及，各类 系统沉淀了海量的关联数据，基于早期的数据库和 HTTP1.0 通信协议， API 在企业内部数据打通后开始崭露头角，系统集成进入 API1.0 时 代。

2007 年前后，随 Web2.0 时代到来，企业信息和资源跨出企业内部，各企业系统不再是孤立状态，系统资源和数据的整合需求也扩散 至外部，进而出现了 UDDI 技术规范和基于 SOAP 协议的 API 接口，系 统集成步入 API2.0 时代。

2015 年后，云服务主导了企业服务市场，大型企业在内部系统集 成理顺的基础上，将企业核心资源以带有适当安全和监管措施的 “API+云服务”形式向合作伙伴、客户、乃至普通大众输出。基于此， RESTful API 开始被大量应用，API 服务正式步入 3.0 时代。在 API3.0 时代，客户和普通大众可以利用企业通过 API 输出的资源来完成各自 的产品和服务的开发，最终延伸出庞大的价值链。 在云技术与容器技术兴起之前，单体架构一直是构建应用程序的 主流架构，然而这两种技术的兴起，为企业快速部署项目以及持续集 成带来了很大便利。伴随着容器技术与云技术的发展，微服务已成为 高速增长公司中构建应用程序的首选。

1. 单体架构

在应用程序发展的早期，大部分软件项目是将所有的服务端功能 模块打包到单个巨石型（Monolith）应用（典型的三级架构，前端 (Web/Wap/APP)+中间业务逻辑层+数据库层。这是一种典型的 Java Spring mvc 或者 Python Django 框架的应用）中，如很多企业的 Java 应用程序打包为 war 包然后发布到 Tomcat 中，其架构图如下所示：

2. 分布式架构

分布式架构是单体架构的并发扩展，将一个大的系统划分为多个 业务模块，业务模块分别部署在不同的服务器上，各个业务模块之间 通过接口进行数据交互。数据库也大量采用分布式数据库，如：Redis、 ES、solor 等。通过 DNS&LVS/Nginx/F5 负载均衡处理器（DNS 是用于 实现地理级别的负载均衡，而 Nginx&LVS&F5 用于同一地点内机器级 别的负载均衡。其中 Nginx 是软件的 7 层负载均衡，LVS 是内核的 4 层负载均衡，F5 是硬件做 4 层负载均衡），将用户请求均衡地负载到 不同的服务器上。相对于单体架构来说，分布式架构提供了负载均衡 的能力，大大提高了系统负载能力，解决了网站高并发的需求。其架 构图如下所示:

3. SOA 架构

SOA是一个组件模型，它将应用程序的不同功能单元（称为服务） 通过这些服务之间定义良好的接口联系起来。SOA 中的接口独立于实 现服务的硬件平台、编程语言，采用中立的方式进行定义，这使得构 建在各系统中的服务可以以一种统一和通用的方式进行交互。面向服 务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行 分布式部署、组合和使用。SOA 可以理解为：对单体架构的系统按照 实际业务，拆分成功能简单、层次清晰、可独立部署的模块，每个模 块之间相互独立，通过服务治理管理这些单独的模块进行工作。其架 构图如下所示：

4. 微服务架构

微服务（Microservices Architecture Pattern）是由 Martin Fowler 在 2014 年提出的，将单体架构的系统应用，转化为多个可以 独立运行、独立开发、独立部署、独立维护的服务或者应用的聚合， 从而满足业务快速变化及分布式多团队并行开发的需求。如康威定律 （Conway’s Law）所言，任何组织在设计一套系统（广义概念）时，所交付的设计方案在结构上都与该组织的通信结构保持一致，微服务 与微前端不仅仅是技术架构的变化，还包含了组织方式、沟通方式的 变化。 微服务架构，主要是中间层分解，将系统拆分成很多小应用（微 服务），微服务可以部署在不同的服务器上，也可以部署在相同的服 务器不同的容器上。当前应用产生的故障不会影响到其他应用，单应 用的负载也不会影响到其他应用，其代表框架有 Spring cloud、Dubbo 等。其架构图如下所示：

5. Serverless 架构

Serverless 架构能够让开发者在构建应用的过程中无须关注计 算资源的获取和运维，由平台来按需分配计算资源并保证应用执行的 SLA（服务等级协议），按照调用次数进行计费，有效地节省应用成 本。其架构图如下所示：

6. Cloud Native 云原生架构

云原生是通过构建团队、文化和技术，利用自动化和架构来管理 系统的复杂性和解放生产力。云原生（Cloud Native）的定义包含以 下三个方面：应用容器化、面向微服务架构、应用支持容器的编排调 度。