API为核心的架构：Web应用新的关键技术

互联网开发越来越需要一些新的高度个性化的、上下文感知的、可预测的应用，构建和部署在更严格和更高扩展性程度上，并交付给不同类型的客户端。

这些需求的出现，对应用架构的需求已经远远超出了上一个十年标志性的、集成服务器+应用服务器的Web应用开发模型所能提供的支持。

在前一篇博文，“在这个以API为中心的系列架构里”，我们看见了现代应用的构建模式；我们讨论了集成的模式在DevOps的世界中已经不再需要；同时我们也看到了当转换到API为中心的架构上，ETL将会最终消亡。

新的业务面临着诸多的挑战：为正确的人，在任何设备上，在正确的时间提供正确的内容和能力。这种挑战造成了新的架构设计，来拥抱一个有着四个边模型的API架构：应用到客户、应用到后端、应用到应用，以及根据微服务(Micro-Service API)构建的App。

这个四边的模型不仅意味着一个应用可以构建在一个敏捷的模式下、部署在灵活的架构下、可以支持未来任意形式的前端，还意味着可以很容易的连接到企业任何一个内部和外部的应用系统上。应用可以很容易的将相关数据同分析系统共享，或者从分析系统中获得数据驱动的、上下文相关的动作，而这一切都基于这些分析系统的、实施的闭环反馈。

一个以API为中心的架构对企业来说有几个关键的含义：

• 生来就是具备敏捷、扩展和连接的能力：一个API为中心的架构可以允许应用能够以一个敏捷的方式构建起来，支持未来的前端技术，可扩展的部署方式，以及很容易就能够连接到企业内部和外部的其它应用系统；

• 中心化服务治理模型的消亡：虚拟化、IaaS、PaaS，以及新一代互联网开发者的崛起，导致了中心化的服务治理模型的消亡。SOA治理，专注于中心化的IT资源，已经让位给API治理，而后者专注于支持敏捷和去中心化的、API第一的架构。

• 旧的集成模型在新的自动化驱动的DevOps流程里面已经没有地位了：新的API的应用场景（特别是针对Mobile）的，以及围绕API为核心、基于微服务的开发过程，显然并没有多少对集成服务器技术的需求。因此，笨重的集成产品已经让位给一个全新模型。而在这个模型中，所有的资源（包括API和它们所连接的系统）都在应用层(Application Tier)上由专门给现代敏捷企业的DevOps自动化工具来管理。

• API让数据变得更敏捷，ETL被废弃：在一个以API为中心的架构里，传统的ETL(抽取、转换和加载）逐步被废弃了。相反，每个应用都负责将其数据以一个结构化的方式通过API展示出来。而且，基于API的应用数据的导入导出形成了一个完整的循环，能够把数据提供给智能预测引擎，后者能够通过API返回一些触发的动作实现交互。

企业已经不能仅仅将API看作是集成架构的一个扩展或者演进。API和以API为中心的架构，对于开发和部署健壮、可扩展的企业应用，已经变得非常关键。

寄云独家翻译，转载请注明出处。