【.com速译】如果一个组织一直在以某种方式开发或采用应用程序架构，那么在过去几年中会看到很多变化。虽然组织采用了许多不同类型的体系结构和技术，但有时很难跟踪它们，需要审查应用程序体系结构的采用情况并了解其未来的发展方向。本文将分析和讨论应用程序架构在过去几年中是如何演变的，以及每次演变的驱动因素。它还将讨论单体架构、面向服务的架构(SOA)、微服务和事件驱动架构(EDA)。单体架构过去，一切都是单体架构。许多组织经常使用一个应用程序来做多项事情。整体架构允许组织的开发团队快速将原型与完成所有工作的应用程序放在一起。由于无需依赖其他团队，因此维护成本更低。然而，随着应用程序投入生产并继续增长，事情很快就会失控。例如，一个典型的单体应用程序可能涉及多个层，例如用户界面层、业务逻辑层、数据接口层和数据存储层。该应用程序将获取用户输入，对其进行处理，应用业务逻辑，使用一些现有数据对其进行扩充，并将其存储在关系数据库中以供以后处理。单体架构有三个主要缺点：部署缓慢、可扩展性差和相互依赖。由于单体应用程序难以调试和更新，因此大型应用程序需要花费大量时间和精力来识别问题并推出更新，而这时用户需求可能已经发生变化。单体应用程序的第二个缺点是可扩展性差。单体应用程序的功能有限。在当今世界，计算资源比过去便宜得多，通过简单地将它们扔给它们来并行计算要容易得多。过去在功能强大但极其昂贵的服务器上运行的单一应用程序现在可以轻松地作为小型应用程序在商用硬件上并行运行。此外，昂贵的硬件也使得快速扩展变得更加困难。同样对于大型应用程序，每个微小的更改都会影响应用程序的一个或多个其他部分。这增加了潜在破坏重要功能的额外风险。例如，用户界面层的错误会影响整个应用程序的运行。例如，一个组织正在开发一个应用程序，该应用程序提供对跨资产市场数据（股票、外汇、商品等）的访问。更改可能会破坏其用户使用的应用程序的一个非常重要的功能。并且这两个功能是完全独立的，但是因为是同一个代码库的一部分，所以会有一些共享的资源。但用户对此并不满意。敏捷与瀑布许多组织很快意识到他们需要找到一种更好的方法来构建他们的应用程序。与此同时，敏捷方法也越来越流行。许多组织历来使用瀑布方法开发应用程序，这意味着收集广泛的需求，计划到极致，涵盖所有边缘情况，然后一次性谨慎发布具有所有功能的最终产品。对于某些行业，瀑布方法是唯一的方法，因为每次迭代和法规要求都涉及成本。对于其他行业，敏捷方法更为有效。敏捷方法就是在快速迭代中发布最小可行产品(MVP)。一个项目失败得越快，就越能知道什么是行不通的。敏捷方法已经存在了一段时间，并在2011年变得非常流行，而敏捷认证和敏捷教练也变得无处不在。面向服务的体系结构(SOA)通过采用敏捷方法，具有可以轻松更新和扩展的较小应用程序具有明显的更高价值优势。这导致了面向服务的体系结构(SOA)。在单体架构中，一个应用程序做所有事情，而在面向服务的架构(SOA)中，应用程序根据其用例被分解为几个较小的服务。正如IBM所说：“面向服务的体系结构(SOA)的核心目的是通过格式良好、易于使用的同步接口（例如Web服务）公开隐藏在记录系统中的数据和功能。”回到Monoliths示例应用程序，它可以分解成几个更小的服务：用户界面服务。业务逻辑服务。数据集成服务。数据存储服务。这些服务中的每一个都负责一个特定的用例。它们都独立存在，并通过基于简单对象访问协议(SOAP)的同步API相互通信。然而，随着组织中服务数量的增长，为每个服务编写一个接口以与其他服务进行通信变得更加困难。这是组织将从使用企业服务总线(ESB)中受益的时候。企业服务总线(ESB)允许开发人员解耦他们的服务（见下图）并使整体架构更加灵活。解耦服务面向服务的架构(SOA)有很多好处：快速推出。更容易调试。可扩展。职责分工明确。减少对其他服务/组件的依赖。有了如此显着的好处，大多数组织开始采用面向服务的架构和敏捷方法，但他们不知道的是，云计算革命就在眼前。MicroservicesService-OrientedArchitecture最终为MicroserviceArchitecture铺平了道路，它有很多相似之处，但在某些方面又有所不同。导致微服务架构出现的最重要因素是低成本和灵活的基础设施。由于水平扩展基础架构和在集群上运行服务很容易，因此鼓励开发人员编写可以在集群上轻松并行运行的软件。与此同时，能够处理大数据的分布式应用程序和框架激增，例如Hadoop，它普及了map-reduce编程模型。此外，AWS云平台在2015年开始广泛使用，基础设施即服务（IaaS）的概念真正起飞，由于价格低廉，启动EC2实例变得非常方便。初创公司是最先采用IaaS的公司，中小企业紧随其后。在观望和等待之后，大公司最终接受了IaaS并决定采用混合云方法。虽然在云平台上运行分布式基础设施很棒，但也存在一些问题，并且以稳健的方式在分布式云基础设施上运行应用程序绝非易事，而且很多事情都可能出错。集群上的应用程序实例或节点可能会发生故障，那么您如何确保应用程序在遇到这些故障时继续运行？答案是微服务。微服务是一个非常小的应用程序，负责特定的用例，就像面向服务的架构，但完全独立于其他服务。它可以使用任何语言和框架进行开发，并且可以部署在任何操作环境中，无论是在本地数据中心还是在公共云上。此外，它们可以轻松地在不同地区的许多不同服务器上运行，以提供并行性和高可用性。例如，一个小型数据应用程序可以在计算集群中的5个实例上运行，这样如果一个实例出现故障，其他4个实例将确保数据应用程序继续运行。将一个服务分解成多个微服务意味着它们需要相互通信。与依赖企业服务总线和同步API的面向服务的架构不同，微服务利用消息代理和异步API。容器化正如向面向服务架构的转变是由敏捷方法驱动的一样，微服务运动也是由容器化驱动的。容器化在行业专家HackerNoon的一篇文章中有很好的描述：“容器化涉及将应用程序与其所有关联的配置文件、库和依赖项捆绑在一起，以便它可以分布在不同的计算环境中，以高效且无错误的方式运行方式。”Docker最初于2013年推出，是当时最流行的容器平台。如今，几乎所有的现代软件都可以运行在Docker上。随着云计算基础设施的兴起，Docker已成为确保组织可以在其中运行软件的极其重要的工具。新环境，尤其是在云平台上。随着微服务变得越来越流行，服务网格的概念也越来越流行，它允许服务主要使用请求/回复消息模式并保持连接。Nginx公司在他们的博客上对服务网格有很好的解释：“服务网格是一个可配置的、低延迟的基础设施层，旨在使用应用程序编程接口(API)在它们之间进行许多基于网络的进程间通信。”2014年，Google开源了Kubernetes，允许用户编排微服务。借助Docker和Kubernetes，组织可以更轻松地在云平台上部署和管理分布式微服务。这两种技术在过去几年得到了广泛应用。今天，大多数新创业公司编写的云原生微服务可以通过Docker轻松部署并与Kubernetes编排，许多大公司正在与Pivotal等公司合作，轻松将其应用程序迁移到云端。云计算基础设施和分布式微服务的兴起导致到大量初创公司的出现，这些初创公司提供监控微服务（它们消耗多少内存）、自动化（跨服务器自动持续部署微服务）、资源管理（最低出价的AWS资源）等服务。事件驱动架构（EDA）)随着越来越多的数据不断被捕获，组织需要找到创造性的方法来使用它。随着物联网（如AlexaMicrowave）和可穿戴设备（如AppleWatch）的兴起，出现了大量的时间序列数据或事件。智能手机、智能手表、平板电脑、笔记本电脑等现在可以即时推送通知，组织发现事件驱动架构很重要，因为他们的用户希望在重要事件发生时收到实时通知。例如，航空公司应用程序可以在航班延误或登机开始时实时通知乘客。它不会等待人工检查或定期检查事件。在这个新的事件驱动世界中，微服务是围绕事件设计的，并且正在迅速被各个行业领域采用。结束语本文展示了应用程序架构在过去几年中如何受到不同技术和需求的影响和演变。当今大多数组织都在采用微服务和云计算，有些组织在采用事件驱动的架构。在可预见的未来，以事件驱动的方式设计的微服务将会大量涌现。原标题：HowYourApplicationArchitectureHasEvolved，作者：HimanshuGupta
