随着新技术的不断涌现，应用服务器和应用服务器架构似乎前景黯淡。本文探讨应用服务器，以及在现代应用开发策略里是否有其存在空间？

现在似乎很难从媒体那里听到的词就是应用服务器了，它也很可能是每个企业都已经拥有的东西。应用服务器的好日子已经结束了么？

虽然我不会宣告他们已经完蛋了，不过应用服务器显然在生长曲线的相反端。

应用服务器在90年代中后期盛极一时，当时公司正处在客户端-服务器架构到多层架构的变革中。企业从类似Sun Microsystems这样的公司购买大型物理服务器，并且最大化购买价值，需要将多个客户端-服务器应用移动到这些服务器上。这催生了现在广为所知的应用服务器，Java EE是最典型的例子。在Microsoft那里，Windows Server不仅是操作系统，也是应用服务器，因为操作系统需要运行多个应用。

应用服务器带来的主要挑战是一个应用程序的性能可能会影响其他应用的风险，因为它们在竞争底层服务器上的相同资源。

时至今日：开发架构发生了巨变。底层硬件已经通过使用虚拟化和容器技术实现了抽象。应用程序分解为服务。部署的所有东西变得更加小巧，更小的部署单元意味着更大的灵活性以及更少的依赖。如果功能组件都不需要通过消息系统通信，或者分布式事务，那么为什么还要部署这些东西呢？

这就是现状。因此，带有所有所需库的重量级应用服务器的需求正在消亡。替代物包括基于脚本的语言（比如，Python、node.js）和按需部署框架，或者运行Java的更为轻量的服务器或框架，比如Jetty和Spring.io。

因此，还需要传统的应用服务器吗？可能吧。

作为一个企业架构师，我意识到将一堆组件划出来并将其称为应用，这变得越来越难。已有方案包括共享数据库，共享业务服务，甚至可能共享基于Web的API。如果我有决定权的话，应用可能仅仅用来做UI。

因此，应用服务器这个名词已经有些过时了。同时，还有很多情况下事物并没有共享，这时处理的不是Internet类型的可扩展性，我们的团队有很强的Java EE经验。在这些情况下，有什么理由不继续使用可靠的Tomcat或者Weblogic服务器呢？也不要忘记还有很多第三方应用，其运行要求Java EE服务器。

就像还有很多企业仍然有大型主机一样，从今以后十年里，你的环境里仍然会运行着Java EE应用服务器。虽然你90%的活动都会关注于最新类似Docker的容器的编排，在公有云提供商间以不可思议的速度和性能自由穿梭，但是仍然很需要Java EE服务器在后台静静得运行，支撑一些老旧的，不常变化的系统来完成需要它们完成的事情。