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