在决定是复制还是分发以支持可扩展性时要考虑什么？答案

【问题标题】：What to Consider when deciding whether to replicate or to distribute in order to support scalability?在决定是复制还是分发以支持可扩展性时要考虑什么？
【发布时间】：2012-03-23 07:53:02
【问题描述】：

在编写应用程序以支持可伸缩性时，我如何决定是使用 EJB 等技术支持它并将应用程序分布在多台机器上，还是不使用此类技术编写软件并在多台机器上复制它？

有什么好的资源（书籍/文章）可以解释这一点吗？

【问题讨论】：

标签： architecture scalability

【解决方案1】：

可扩展性更多是一种架构能力。技术和工具只是实现了这种能力。

如果您定义的架构具有固有的可扩展性，那么您可以改造任何技术来支持该架构。您可以找到在几乎所有技术堆栈（无论是 PHP、.NET、Java、COBOL、RoR 等）中都非常适合大型用户群的示例。

从现在开始，在云上部署既便宜又容易，请在设计架构时牢记Share Nothing architectural 概念。您可以根据任何大型用户群的需求轻松扩展。

谈到您提到的具体技术，EJB - 它是一种中间件技术，它带有一个包袱 - Java EE 应用程序服务器（或带有一些管道的 Tomcat）。关键是 EJB 解决方案不是轻量级的，建议用于特定的用例，例如 - 可移动性、事务等。另外，开发基于标准的解决方案的成本比仅使用开源堆栈要高。

从可扩展性的角度来看，基于标准的解决方案（例如 EJB、JPA 等）也支持云并支持云可扩展性，即复制和共享。检查这个link。

无论有没有标准——重要的是可以扩展的应用程序架构。

【讨论】：

【解决方案2】：

我相信您的问题是关于纵向和横向可扩展性的。

理想情况下，您应该努力实现水平可扩展性，这并不容易。

当垂直可扩展性需要您增加更多马力时，水平可扩展性会影响应用程序的架构。我们目前处于可以轻松垂直缩放但不能水平缩放的位置。我们的平台将在未来几个月达到顶峰，我们必须对平台的架构进行更改。

我认为这与任何特定技术无关。您可以使用 EJB，但仍然无法水平扩展。这不是那么简单。 Cal Henderson 有一本好书，Building Scalable Web Sites。可能是一个很好的开始。

【讨论】：

【解决方案3】：

可扩展性是一个广义术语，通常与技术无关。

如果在您的设计阶段您决定，我知道这个应用程序将支持 10 万用户，但我希望能够支持多达 100 万用户而不需要重构，那么您通常希望与恕我直言这种通过“硬件”方法进行的扩展。如果您知道您的设计可以在集群中的 2 台服务器上很好地处理 10 万用户，那么可以通过增加硬件来达到 100 万，前提是提供 10 万基础的软件解决方案的设计并不差。

分布式技术很有趣，也很不错，但它们确实有开销，并且随之而来的问题。当您的集群只有 2 个节点时，这没什么大不了的，并且您需要来自另一个节点的对象，您知道该节点在哪里，并且可以去请求它.. 这有一定的成本，但通常不会有什么离谱的但是当你把它扩大到现在你的集群有 25 或 50 台服务器时，即使你有一个很好的容器为它扮演交通警察，获取那个对象也可能是完全不同的球赛。

另外，可悲的是，但在现实世界中，管理决策者往往对技术一窍不通，往往会被 9 个女人一个月生孩子的心态所吸引。对你来说，这是一场容易得多的战斗，让他们诚实地理解说，如果你想要更多的容量，我们将需要更多的硬件。而不是很好，它需要一个可能需要 4-6 个月的完整重构.

尽管使用硬件方法，但请注意，它不是无限的，添加到集群的每台服务器都会产生开销，并且最终会达到收益递减规律。

我的基本经验法则是“简洁”，因为它想要使用你读到的所有那些花哨的模型，想了很长时间并努力确保它们是正确的解决方案，它非常容易过度设计一个解决方案.

【讨论】：