哪些类型的系统必须“向上扩展”而不是“向外扩展”？

Question

很长一段时间以来，我一直想知道是否有系统必须“纵向扩展”（到更强大、更昂贵的服务器上）而不是通过拆分到许多较小的服务器来“横向扩展”。

这样的系统是否存在，如果存在，是否有什么特别的东西会导致系统需要扩展而不是横向扩展？（例如，可能 ACID-complaint 数据库事务或其他强大的数据完整性要求会产生这种需求。）

由于向上扩展似乎比向外扩展带来更高的硬件成本，因此如果可能的话，这似乎是您想要避免的事情，但我不确定它是否总是可以避免的。

那么，是否存在无法横向扩展而必须纵向扩展的系统？什么可能导致这种情况，您将如何识别这样的系统？（它们通常是否具有一些共同的特征，可能使它们更容易识别？）

Answer 1

我主要使用具有零水平扩展潜力的应用程序。尽管它在 Linux 上运行，但应用程序、数据结构和 I/O 要求迫使我“向上扩展”到越来越大的系统上，以适应增加的用户工作负载。

许多遗留的业务线和事务性应用程序都有这些类型的约束。这是我强调行业专注于云解决方案和 DevOps 驱动的网络规模架构忽略了计算世界的很大一部分的原因之一。

不幸的是，我所描述的放大系统真的很不吸引人，因此该行业往往会忽视它们的价值或不重视解决大型关键系统（例如牛与宠物）所需的技能。

Answer 2

从开发人员的角度来看，我可以说几乎所有传统的主流数据库引擎都只能纵向扩展，横向扩展是事后的想法。

近年来，随着对更高可扩展性和高可用性系统的需求，人们一直在努力使现有数据库向外扩展。但是因为设计受到遗留代码的阻碍，它在很大程度上只是固定的，而不是设计的基础。如果尝试扩展大多数众所周知的数据库引擎，您会遇到这种情况。添加从属服务器可能非常难以设置，您会注意到它有很大的局限性，其中一些可能需要重新调整数据库表。

例如，它们中的大多数是主/（多）从而不是多主设计。换句话说，您可能只是将整个服务器放在那里而无法处理查询。有些可以，但有限制……例如只读多从机设计。因此，您可能有一台服务器进行写入，而所有其他服务器都提供只读数据。当您设置这些系统时，您会注意到它并不总是一个简单的过程，并且很难正常工作。在许多情况下，这感觉非常重要。

另一方面，一些较新的数据库引擎从一开始就采用并发和多主机设计进行开发。 NOSQL和NewSQL是新的设计类。

因此，从传统 SQL 服务器获得更好性能的最佳方法似乎是向上扩展！在使用 NOSQL 和 NewSQL 时，它既可以向上扩展又可以向外扩展。

传统 RDBMS 系统紧密耦合的原因是因为它们都需要相同数据的一致视图。当您有多个服务器接受来自不同客户端的相同数据的更新时，您信任哪一个？任何试图通过某种锁定机制确保数据一致的方法都需要其他服务器的合作，这会损害性能或影响数据质量，因为从客户端读取的任何数据都可能过时。并且服务器需要在写入同一记录时自行决定哪些数据是最新的。正如您所看到的，这是一个复杂的问题，因为工作负载分布在服务器之间，而不仅仅是在访问数据仍然非常快的进程或线程之间。

Answer 3

在我看来，纵向扩展/横向扩展的划分取决于工作流的并行程度，以及并行线程需要相互协调的紧密程度。

单线程
无论出于何种原因，此工作流只能在单线程中工作。

一个线程意味着一个系统意味着向上扩展以使其运行得更快。

紧密耦合并行性
这是一个多线程系统，其中线程需要彼此紧密耦合。也许进程间通信需要非常快，或者这一切都需要通过单个内存管理器进行管理。大多数 RDBMS 系统都是这种并行计算。

在大多数情况下，这些系统是那些规模达比出来但也有例外。例如，在单一系统映像样式集群上工作的工作流、单一内存空间但线程之间的高延迟可能会使横向扩展更容易。但是这样的 SSI 系统使用起来非常棘手，所以大多数工程师只是制作一个更大的盒子。

松散耦合的并行性
这是一个多线程/进程系统，其中线程之间存在高延迟。或者根本不需要互相交谈。横向扩展的 Web 服务和渲染农场是此类系统的经典示例。像这样的系统比紧密耦合的并行系统更容易扩大规模，这就是为什么人们对这种风格的系统感到兴奋的原因。

这是规模的风格出来是一个容易得多。