在编写支持可伸缩性的应用程序时，如何决定是使用EJB等技术支持它还是在多台机器之间分发应用程序，还是在不使用这些技术的情况下编写软件并在多台机器中复制它？ / p>
是否有任何好的资源（书籍/文章）可以解释这个？
答案 0 :(得分：3)
可扩展性更像是架构功能。技术和工具才能实现这一功能。
如果您定义的架构具有固有的可扩展性，那么您可以改进任何技术来支持架构。您可以找到几乎所有技术堆栈（无论是PHP，.NET，Java，COBOL，RoR等）的大型用户群都能很好地扩展的示例。
从那时起，它便宜且易于在云上部署，设计您的架构时牢记Share Nothing architectural概念。您可以轻松按需扩展任何大型用户群。
来到您提到的特定技术，EJB - 它是一种中间件技术，它带有一个包袱 - Java EE应用服务器（或带有一些管道的Tomcat）。重点是EJB解决方案不是轻量级的，并且建议用于特定用例，例如 - 远程处理，事务处理等。此外，开发基于标准的解决方案的成本在较高的方面只是使用开源堆栈。
从可扩展性的角度来看，基于标准的解决方案即EJB，JPA等也支持云，并支持云可扩展性，即复制和共享。请检查此link。
有无标准 - 可以扩展的应用程序架构是什么问题。
答案 1 :(得分：1)
我相信您的问题是纵向和横向可扩展性。
理想情况下，您应该蓬勃发展以实现水平可伸缩性，这并不容易。
当垂直可扩展性要求您添加更多马力时，水平可伸缩性会对应用程序的体系结构产生影响。我们目前处于可以轻松垂直扩展但不能水平扩展的位置。我们的平台将在未来几个月内达到顶峰，我们必须对平台的架构进行更改。
我认为这与任何特定技术无关。您可以使用EJB，但仍然无法水平扩展。它并不那么简单。建立可扩展网站的Cal Henderson有一本好书。可能是一个很好的阅读开始。
答案 2 :(得分：1)
可伸缩性是一个广义的术语，通常是技术不可知的。
如果您在设计阶段决定，我知道此应用程序将支持10万用户，但我希望能够支持多达100万用户而无需重构，那么您通常希望接近恕我直言这种通过“硬件”方法进行扩展。如果你知道你的设计可以在一个集群中的2台服务器上处理好10万用户，那么通过硬件增加就可以达到100万用户，提供的软件解决方案可以提供100k基础设计。
分布式技术既有趣又好，但它们确实存在开销，以及随之而来的问题。当你的集群只有2个节点，而你需要一个来自另一个节点的对象时，它就不是什么大问题，你知道该节点在哪里，并且可以去询问它......这有成本，但它通常没什么特别的但是当你扩展到现在你的集群有25或50台服务器时，获得该对象，即使你有一个漂亮的容器为它播放交通警察，也可能是一个完全不同的球类游戏。
此外，伤心地说，但在现实世界中，管理决策者往往是严重的技术懵了，往往倾向于到9名妇女让婴儿在一个月心态。对你来说，这是一个更容易上手的战斗，并且老实说要理解，如果你想要更多的容量，我们将需要更多的硬件......而不是很好，它需要一个可能需要4-6个月的完整重构。
但是，通过硬件方法，请注意，它不是无限的，您添加到群集的每个服务器都会产生开销，并且最终会达到收益递减规律。
我的基本经验法则是“整洁”，因为它想要使用您所阅读的所有那些花哨的模型，认真思考并且很难确保它们是正确的解决方案，它非常容易构建一个解决方案