当今高度可伸缩的web应用程序不是单一的代码库，而是无状态微服务和有状态数据存储的分类组合。这种现代web应用程序的典型体系结构模式解决了扩展、数据管理和开发吞吐量的某些问题。然而，这个解决方案带来了一个新问题：筒仓。分门别类的架构常常导致分门别类的管理和一个分门别类的团队。

在本文中，我们将简要探讨web应用程序体系结构的演变，更深入地研究筒仓问题，并讨论DC/OS这一开源应用程序平台如何解决这一问题。

应用程序架构背景

在过去的十年中，Web应用程序体系结构的趋势有了很大的发展。这些变化主要是由支持现代应用程序的三个需求驱动的：

• 沉重，负载大，多变；
  
• 增加数据的收集和使用；
  
• 开发速度快。
  

面对这些挑战，开发人员不可避免地会离开传统的单机应用程序，将工作分布到多个服务器上。第一种常见模式是将数据库服务器与主应用程序服务器分离。一旦这个模式建立起来，它就很自然地通知了随后的架构模式。当分析数据库与业务数据库分离时，两台服务器变成了三台。静态资产的单独对象存储引入了一个新组件。索引和搜索服务器可能会添加到混合中。

这种演进的逻辑结果是许多当代web应用程序中的典型架构：无状态、容器化微服务和有状态、大容量数据存储的混合。这种方法解决了它想要解决的所有三个挑战：

可扩展性。

根据定义，无状态服务不需要在会话间持久化数据。这意味着它们可以按需复制，并且每个副本不需要知道或与其他副本协调。此外，由于核心应用程序功能由许多不同的微服务组成，因此可以只扩展那些大量使用的服务。

数据管理。

将数据持久化在一个或多个“大数据”存储中，这些存储是为跨多个虚拟机进行分片而优化的，这使得根据需要扩展存储相对容易。也许更重要的是，持久数据存储的广泛选项允许开发人员以适合其用途的自定义方式存储数据。

开发速度。

微服务和数据存储是可组合的，这意味着它们可以被排列并重新组合到新的应用程序中。这使得快速开发新应用程序变得更加容易。

尽管如此，现代应用程序体系结构的所有好处都会产生自己的一系列问题。

筒仓

每个架构组件都有不同的基础设施需求、不同的部署方法、不同的扩展需求和不同的维护挑战。发展一套多样化的操作程序来处理这些需求是不可避免的。这通常会导致筒仓，在筒仓中，单独的团队处理这些单独的操作。

团队筒仓是一种典型的组织响应，用于处理不同的操作需求。它通常在早期就有意义，因为它可以让人们专注于特定的问题和发展专业知识。然而，从长远来看，这种类型的仓储效率低下，增加了复杂性和官僚开销。

尽管团队筒仓是有问题的，技术筒仓也是有问题的。虽然关注点分离和松散耦合是微服务架构的强大优势，但始终需要理解系统并与整个系统交互。无论是用于测试、部署自动化、审计还是分析，系统中都有大量的临时管理过程。这往往会加强服务之间的耦合。

弥合差距

临时管理过程和团队筒仓的另一种选择是一个单一的平台，它提供了具有统一管理接口的分类应用程序体系结构的好处。其中一个这样的平台是DC/OS，这是一个开源的数据中心操作系统，允许您在池计算资源上部署和管理容器和大数据服务。

DC/OS将一组Linux系统组合成一个集群。应用程序由在DC/OS层运行的多个包组成。开发人员可以构建自己的包，但是已经有许多包可用。这些包括关系数据库和非关系数据库、文件系统、对象存储、web服务器、消息队列、数据处理引擎和机器学习工具。Docker也可以作为DC/OS包提供，为实现核心业务功能的定制或现成应用程序提供可扩展的容器平台。

主节点跨集群协调工作，根据可用资源将计算任务和存储需求委派给代理节点。代理节点的调度由开源的Apache Mesos分布式系统内核管理。Apache Mesos运行一个两级调度过程。在一个层次上评估每个DC/OS级应用程序的需求，而第二个层次为这些需求提供底层计算资源。

新的代理或主节点可以配置并添加到系统中，以方便扩展计算能力。DC/OS集群可以组装在私有数据中心中，也可以构建在云计算平台（如AWS、Google cloud或Microsoft Azure）上。

在DC/OS上构建一个应用程序可以提供分类的、面向服务的开发方法的优势，同时避免多个不同平台的孤立趋势。