应用程序架构是如何演变的

【squids.cn】全网zui低价RDS，免费的迁移工具DBMotion、数据库备份工具DBTwin、SQL开发工具等

如果您一直在开发或以某种方式参与应用程序架构，那么在过去的几年中您肯定看到了许多变化。有很多不同类型的架构和技术陆续出现然后消失，以至于有时很难跟踪它们。但是，当你反思它们时，它们不仅可以讲述过去的故事，还可以预示应用程序架构的发展方向。

在这篇文章中，我将讨论近几年来应用程序架构在我看来是如何演变的，以及每次演变的驱动因素是什么。我们将讨论单体架构、面向服务的架构(SOA)、微服务，最后是事件驱动架构(EDA)。让我们开始吧！

单体架构

在过去，所有东西都是单体的。大团队会专注于一个单体应用程序，这个应用程序负责执行许多任务。单体架构允许您迅速地将原型组合在一个应用程序中，这个应用程序可以完成所有的事情。由于你不需要依赖其他团队，所以维护成本较低。然而，当应用程序被推送到生产并继续增长时，事情很快就会失控。

例如，一个典型的单体应用程序可能包括多个层次，如用户界面层、业务逻辑层、数据接口层和数据存储层。此应用程序会接受用户输入，处理它，应用业务逻辑，使用现有数据进行丰富，然后可能将其存储在关系型数据库中，供以后进行额外的处理。

单体架构有三个主要的缺点：部署慢、可扩展性差和相互依赖。单体应用程序更难调试和更新。大型应用程序需要大量的时间和努力来确定问题并部署更新，而当这些更新被推出时，需求可能已经发生了变化。

单体应用的第二个缺点是可扩展性差。一个应用程序能做的只有那么多。在当今的世界，计算资源比过去便宜得多，我们通过简单地为应用程序投入更多的计算资源，更容易地并行计算。一个过去运行在强大但非常昂贵的服务器上的单体应用程序，现在可以作为较小的应用程序并行运行在普通硬件上。此外，较慢的部署（我们之前讨论过的）使得快速扩展变得更加困难。

此外，在一个大型应用中，每一个小的改动都可能影响到应用的一个或多个其他部分。这增加了可能破坏重要功能的额外风险。例如，用户界面层的一个错误可能会影响整个应用程序。

在我之前的工作中，我曾在一个应用上工作，该应用提供了对跨资产市场数据（股票、外汇、大宗商品等）的访问。在一个版本中，我为股票用户推出了一个新功能，但由于我们的应用是单体的，我的这个小改动最终破坏了一个由外汇用户使用的应用的非常重要的功能。这两个功能是完全独立的，但由于它们是同一个代码库的一部分，它们有很多共享资源。不用说，外汇用户并不满意。

敏捷 vs. 瀑布

很快，公司们开始意识到，他们需要找到一个更好的方法来构建他们的应用程序。大约在同一时间，敏捷方法论正变得越来越受欢迎。以前，公司主要使用瀑布方法论来开发应用程序，这意味着收集大量的需求，进行极端的规划，涵盖所有的边界情况，然后在一个大的爆炸中小心地发布具有所有功能的最终产品。

对于某些行业，由于每次迭代所涉及的成本和/或监管要求，这是唯一的方法。而对于许多其他行业，敏捷方法论更为有效。敏捷方法论是关于在快速迭代中发布最小可行产品(MVP)。你失败得越快，知道什么不起作用，就越好。敏捷方法论，虽然已经存在了一段时间，但在2011年左右变得非常流行，当时敏捷联盟（是的，这是真的）创建了《敏捷实践指南》。敏捷认证和敏捷教练无处不在。不管你怎么努力躲藏，你的敏捷教练总会在每日晨会时找到你。

面向服务的架构

随着敏捷方法论的推广，人们明确地认识到，拥有可以轻松更新和扩展的小型应用程序有着宝贵的优势。这引出了面向服务的架构。在单体架构中，一个应用程序自己做所有事情，而在面向服务的架构中，一个应用程序会被分解成基于其用途的几个较小的服务。正如IBM的这篇文章所提及的：

SOA的核心目的是通过格式良好、易于使用、同步的接口（如Web服务）来暴露系统中的数据和功能。

回到我们关于单体应用的例子，它可以被分解成多个较小的服务：

用户界面服务。
业务逻辑服务。
数据集成服务。
数据存储服务。

每个服务都负责一个特定的用例。它们都独立存在，并通过基于简单对象访问协议(SOAP)的同步API进行通信。然而，随着你组织中服务数量的增长，为每个服务编写一个与其他所有服务通信的接口会变得越来越困难。这时，你会从企业服务总线（ESB）中受益。ESBs允许开发人员解耦他们的服务（请参阅下面的图）并使整体架构更加灵活。

解耦服务图

解耦您的服务

面向服务架构的多个好处包括：

快速推出。
更容易调试。
可扩展性。
职责明确。
对其他服务/组件的依赖性较少。

由于这些明显的优势，大多数公司开始采纳面向服务的架构以及敏捷方法论，但他们几乎不知道，云计算的革命即将到来。

微服务

面向服务的架构最终为微服务架构铺平了道路，它们有很多相似之处，但在一些细微之处有所不同。

我认为导致微服务架构产生的最重要因素是廉价和灵活的基础设施。由于水平扩展你的基础设施并在集群上而不是在强大的服务器上运行你的服务变得如此容易，所以鼓励开发人员编写可以轻松在集群上并行运行的软件。大约在同一时期，出现了大量的分布式应用和框架，如Hadoop，它普及了map-reduce编程模型。

此外，大约在2015年，AWS变得非常流行。那时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资源竞标）提供服务的初创公司的诞生。如果你曾参加过AWS峰会，那么你就知道我在说什么。