当今高度可伸缩的web应用程序不是单一的代码库，而是无状态微服务和有状态数据存储的分类组合。这种现代web应用程序的典型体系结构模式解决了扩展、数据管理和开发吞吐量的某些问题。然而，这个解决方案带来了一个新问题：筒仓。分门别类的架构常常导致分门别类的管理和一个分门别类的团队。
在本文中，我们将简要探讨web应用程序体系结构的演变，更深入地研究筒仓问题，并讨论DC/OS这一开源应用程序平台如何解决这一问题。
应用程序架构背景在过去的十年中，Web应用程序体系结构的趋势有了很大的发展。这些变化主要是由支持现代应用程序的三个需求驱动的：
沉重，负载大，多变；
增加数据的收集和使用；
开发速度快。
面对这些挑战，开发人员不可避免地会离开传统的单机应用程序，将工作分布到多个服务器上。第一种常见模式是将数据库服务器与主应用程序服务器分离。一旦这个模式建立起来，它就很自然地通知了随后的架构模式。当分析数据库与业务数据库分离时，两台服务器变成了三台。静态资产的单独对象存储引入了一个新组件。索引和搜索服务器可能会添加到混合中。
这种演进的逻辑结果是许多当代web应用程序中的典型架构：无状态、容器化微服务和有状态、大容量数据存储的混合。这种方法解决了它想要解决的所有三个挑战：
可扩展性。根据定义，无状态服务不需要在会话间持久化数据。这意味着它们可以按需复制，并且每个副本不需要知道或与其他副本协调。此外，由于核心应用程序功能由许多不同的微服务组成，因此可以只扩展那些大量使用的服务。
数据管理。将数据持久化在一个或多个“大数据”存储中，这些存储是为跨多个虚拟机进行分片而优化的，这使得根据需要扩展存储相对容易。也许更重要的是，持久数据存储的广泛选项允许开发人员以适合其用途的自定义方式存储数据。
开发速度。微服务和数据存储是可组合的，这意味着它们可以被排列并重新组合到新的应用程序中。这使得快速开发新应用程序变得更加容易。
尽管如此，现代应用程序体系结构的所有好处都会产生自己的一系列问题。
筒仓/单筒每个架构组件都有不同的基础设施需求、不同的部署方法、不同的扩展需求和不同的维护挑战。发展一套多样化的操作程序来处理这些需求是不可避免的。这通常会导致筒仓，在筒仓中，单独的团队处理这些单独的操作。
团队筒仓是一种典型的组织响应，用于处理不同的操作需求。它通常在早期就有意义，因为它可以让人们专注于特定的问题和发展专业知识。然而，从长远来看，这种类型的仓储效率低下，增加了复杂性和官僚开销。
尽管团队筒仓是有问题的，技术筒仓也是有问题的。虽然