软件架构趋势与 API
本文作者 李C理
前言
连接是一件令人惊喜的事情，现在我们已习惯动动手指就可以实时链接世界，从电脑到移动设备上我们可以在任何地方任何时间购物，邮件，社交，筛选东西，实现前所未有的方式与世界互连，这一切的背后正是有 API 这位无名英雄存在。通过 API，一方以特定方式发送远程请求,而无需了解对方内部系统的逻辑，即可访问对方开放的资源，实现企业内外部产品和服务的互动。API 已成为企业内外系统集成的重要手段。如今，互联网环境瞬息万变，跨界融合创新不断发生，使得 API 的使用亦更加广泛，API Bank 的诞生，人工智能 ChatGPT API 的横空出世，就已经注定了 API 与传统行业的邂逅已无处不在。而这一切的“幕后之手” API 在不同架构时代发展中又经历了哪些，未来 API 又会具有怎样的趋势呢？
发展历程
“道由白云尽，春与青溪长。”
API 单体架构时代
所谓单体，简单理解就是一个程序里包含了一个系统/产品的所有业务功能，比如一个 ERP 系统，就包含了商品模块、订单模块、采购模块、销售模块、库存模块、报表模块等等，这个程序在部署时就是一个进程，比如把 WAR 包部署到 Tomcat 中。API 负责进行内部服务调用。在当时单体结构的优点也是显而易见的。
- 结构简单，容易理解：对于我们开发人员而言，这是非常重要的一点。经典的分层架构已经相对比较成熟，更容易被大家所理解和接受，学习成本也相对比较低，对团队本身的要求也不是特别高。这不仅使得系统的设计和开发都相对比较容易，而且出错的几率会相对低一些。用现在时髦的词语说，就是“坑相对较少”，开发实现都可以“踩在踩坑人的背上前进”，实现数据一致性相对比较容易，通过本地事务或者分布式事务可以方便有效地保证数据一致性。
- 部署简单方便：比如上面提到的 ERP 系统，可以方便快速地打包成 WAR 包，部署到 Jetty 或者 Tomcat 容器中，也可以是一个部署在 IIS 中的 .NET 解决方案。无论哪种，一次部署完成即可运行整个应用程序。
- 持续集成策略的设计相对容易：基本上团队可以根据项目的实际情况很容易地设计出持续集成方案，很多情况下，整套解决方案会放在同一个代码库中，根据持续集成策略，项目的持续交付也不会有太大压力。
随着互联网时代的迅速发展，需求量的提升，单体架构的缺点也逐渐凸显，系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长。
- 系统错误隔离性差、可用性差：任何一个模块的错误均可能造成整个系统的宕机。
- 可伸缩性差：系统的扩容只能只对这个应用进行扩容，不能做到对某个功能点进行扩容。
- 线上问题修复周期长：任何一个线上问题修复需要对整个应用系统进行全面升级。这些缺点也导致了单体架构随之慢慢被微服务架构所替代，而 API 作为微服务的交流方式，也注定了 API 的命运不会平凡。
API SOA 架构时代
当软件架构发展至 SOA 时代，其中的许多概念、思想都已经能在今天微服务中找到对应的身影了。服务之间的松散耦合、注册、发现、治理，隔离、编排，等等。这些今天微服务中耳熟能详的名词概念，大多数也是在分布式服务刚被提出时就已经预见到的困难。SOA 针对这些问题，乃至于针对“软件开发”这件事情本身，进行了更加系统性、更加具体的探索。
采用 SOA 架构可提高业务敏捷性，无需重写和重新集成每个新开发项目，而是通过可复用服务接口 API 组装应用程序，因此极大地提高了效率，让我们开发人员能够更快地构建应用程序以应对新的商机。
在当时 API 通过轻型协议 SOAP 这种简单对象访问协议，用于分散的、分布式计算环境中交换信息。以助于独立于平台的方式访问对象、服务和服务器。
SOA 在 21 世纪最初的十年里曾经盛行一时，众多行业巨头厂商为其呐喊冲锋，吸引了不少软件开发商、尤其是企业级软件的开发商的跟随，最终却还是偃旗息鼓，沉寂了下去。其逐渐边缘化的本质原因，是因为过于严格的规范定义带来过度的复杂性。SOA 诞生的那一天起，就已经注定了它只能是少数系统精致奢侈品，它可以实现多个异构大型系统之间的复杂集成交互，却很难作为一种具有广泛普适性的软件架构风格来推广。
API REST 架构时代
REST 架构时代的到来使得 REST API 几乎可以使用任何编程语言进行开发，并支持多种数据格式。REST 如今是一种无需解释的 API 架构风格，它由一系列的架构约束所定义，被广泛 API 使用者采用。基于 RESTful 架构的应用程序所具备的特征，我们在开发和部署它们时就可以感受到这一系列明显的优势，这也使得 REST 这套设计规范成为了当前开发互联网应用程序的主要解决方案之一。在这里，我们可以简单地将这些优势归纳如下：
- 接口统一：这是 RESTful 架构的设计初衷，它致力于让后端业务逻辑以统一接口的方式向前端提供服务，这样就简化了系统架构，降低了应用程序前后端之间的耦合性，以便于程序员们在开发整个应用程序可进行模块化分工
- 分层系统：RESTful 架构允许在后端构建基于多台服务器的分层系统服务。这意味着，应用程序的前端通常不需要知道自己连接的是最终的服务器，还是某台资源请求路径上的中间服务器。这更有助于我们在部署和维护应用程序时设置更为稳妥的服务器负载策略和其他安全性策略。
- 易于重构：正是由于 RESTful 架构实现了应用程序的前后端在业务逻辑上的分离，降低它们之间的耦合度，这意味着我们对前端业务逻辑所进行的任何重构都基本上不会对后端的实现产生影响，反之亦然。例如我们既可以根据智能手机，PC 等不同客户端设备重构出不同的前端用户界面，也可以在用 JavaScript 基于 Node.js 运行环境编写的程序无法满足性能需求时，使用 Python、Go 等更适用于大规模科学运算的编程语言重构后端服务部分的业务逻辑。
虽然 REST 设计有益于支撑 SOA 的目标，但务实的 REST 的战略关注点与许多 SOA 的举措不同。务实的 REST API 设计团队专注于自下而上的应用场景、友好的协议或格式，比如 HTTP、JSON、DNS，以及宽容的接口定义和简单的交互模型，比如在保证送达之上的重试。
大家在系统中，专注于管理对象并面向许多使用者的 API 是最常见的 API 类型。REST 帮助此类 API 具有强大的可发现性，良好的文档编制，因此 REST 非常适合此对象模型。简单的资源驱动型应用程序。在用于连接不需要查询灵活性的资源驱动型应用时，REST 是一种非常有效的方法。
未来趋势
“时有落花至，远随流水香。”
人工智能 API 将惠及所有人
发展到时代的今天人工智能 AI，已经成为家喻户晓的一个名词，而最近爆火的 ChatGPT 更是席卷了整个互联网，也标志着人工智能成为当前科技革命的核心技术，我们或许将真正迎来一个人工智能助理时代。通过基于大型预训练语言模型，我们可以对其进行微调，以完成各种任务，如回答问题、提供信息或参与对话。与许多使用预定义的响应或规则生成文本的聊天机器人不同，ChatGPT 经过了训练，可以根据接收到的输入生成响应，从而生成更自然、更多样化的响应。
ChatGPT 模型的出现对于文字/语音模态的 AIGC 应用具有重要意义，可能会对 AI 产业上下游产生重大影响。AI 杀手级的出现可能会通过 API 链接实现不同领域应用上的改革，可代替大量低端人工，将给世界带来新的产业革命。也标志着未来世界的每一个关键的科技进步所需要的资源也将越来越多，API 的优势将会越来越显著。
时代的今天 API 开放已经成为不可逆的趋势，OpenAI 于3月2日发布公告，正式向第三方开发者开放 ChatGPT API，以及 Whisper API，通过 API 将 ChatGPT 集成到第三方的应用程序和服务中，这也趋势着人工智能接口 API 的普及，未来会有更多的企业通过 API 进行 AI 对接，在各种领域我们都有可能潜移默化的享受着 AI 的惠及。
API 驱动数字化转型
“API Bank”概念的诞生，标志着通过 API 架构驱动，场景金融将融入互联网生态，围绕客户需求和体验，形成即想即用的跨界服务，重构全新的银行业务模式和经营理念，推动银行产品、服务全面升级。
举个例子方便大家理解 API Bank，假如你要去境外旅行，通过 API Bank 银行在帮助你完成境外旅行固定流程的同时，甚至还能够会根据你偏好主动提供分期、信用调额、保险套餐等产品，还可感知你位置，实时推荐周边优惠商户，航班延误信息等实用信息。你的体验得了前所未有的提升，基本上可说是“即想即用”。然而，更大的变革还不是表现在用户端，而是银行与企业的关系，在这里，API Bank 无界开放银行甚至不是一个单纯的技术平台，而是一个“连接器”，使银行与各行业连接起来，构成一个开放共享、共建共赢的生态圈。
“API Bank”只是 API 驱动数字化转型的开始，展望未来，我认为企业需要筹划未来十年之内如何超越数字化转型、全面实现数字卓越。围绕安全性、全局范围、访问管理以及人工智能等高级云功能支持不断增长的全球数字生态系统。设计合理且易于管理的 API ，建立起强大且稳健的运营体系。同时要注意在技术方面的长期积累与投入，未来基于 API Bank 的行业竞争，说到底还是技术实力的竞争。
写在最后
总体来讲 API 经历了由单体架构时代到微服务架构时代的转变，如今 REST 面向业务应用也成为了 API 架构的一种主要风格，未来“幕后之手” API 在人工智能和数字化经济方面可能同样会有着不可小觑的贡献。文章到这里就落幕了，以上也仅仅是个人的一些观点，希望能为大家带来更深入的理解，谢谢观看。
