应用架构驱动着基础设施架构的发展。下一代应用架构聚焦于社交、移动、大数据、智能硬件，驱动应用向着更好的用户体验发展，也对传统的技术架构产生了冲击。
本文我们将看下新一代技术架构的元素，以及公司在下一代应用和基础设施中，应当如何进行架构选型。
在过去的6-12个月里，Container技术引起了企业的CIO、架构师和开发人员的极大兴趣。
Container技术引起CIO兴趣的原因在于，他们找到了向现代应用框架快速转型的方法，从而驱动业务的发展。
对于架构师来说，Container技术增强了应用的可移植性，适用于混合云架构。
而开发人员通过Container技术，可以快速地应用微服务架构，增强应用的可扩展性。
DockerCon和Red Hat Summit中，都曾讨论过这一趋势。但是每种新技术，都会带来新的挑战和利弊权衡。本文将对container技术架构中的元素逐一进行分析。
下图为Docker技术人员Patrick Chanezon总结的Container技术栈：
在深入了解Container技术架构之前，有必要先理解以下几个基本问题：
Container技术非常适用于分布式应用框架中，这意味着底层的Container基础架构必须是模块化和非常灵活的；
以下所探讨的核心概念，很多来源于如今的虚拟化架构，比如服务发现（Service Discovery），集群管理（Cluster Management）和资源调度（Resource Scheduling）；
围绕整个container技术架构的公司生态也在快速发展，多数情况下，他们都从单一的工具开始，慢慢发展为一个全栈服务。
深入Container技术架构
从单一的Container到服务于产品的架构，需要一系列的工具和配置。从这些工具和配置上，我们可以看出下一代基于Container的应用需要哪些组件：
首先，要进行以下声明：
所有这些组件都不是硬件的，也不依赖于云服务；
在实现时，可能会结合一些组件到一个软件中；
并非所有组件都是必须的。
下面是对整个技术栈自下而上的分析：
Container实现——灵活性，交互性以及挑战
对于企业来说，Container技术的挑战之一在于，选择Container技术栈意味着舍弃传统的，由ISV提供的一站式“单块架构”，通常会令企业望而生畏。
第二个挑战在于，初创公司常常将个人项目作为工具，许多情况下，要么是某公司在主导这个项目，要么由一个开源社区主导。
第三个挑战在于许多工具是彼此协作和可替代的。许多早期用户会试用不同项目的组件，而不是由一个供应商或开源项目提供的技术栈。短期来讲，有助于早期采用者实现灵活性和技术的多样性。长期来看，不利于企业对稳定环境的需求，同时也会增加对新技术的学习成本。相关的公有云服务，比如Amazon Elastic Cloud Services和 Google Container Engine，可以帮助用户屏蔽技术上的复杂性。
总结
Container技术和架构产生和发展都很迅速。许多初创企业都在驱动新工具和框架的产生，能够将合适的架构组件组合起来的技术，将为企业带来很多优势。不管基于已有的基础架构还是公有云，随着更多的解决方案级别的产品被推向市场，Container技术的发展脉络也将逐步清晰。
本文译自wikibon文章《Evolving Container Architectures》，原文请点击“阅读原文”。
微信ID：Containerdaily
长按左侧二维码关注Container技术日报(ContainerDaily)
