将可扩展性设计到应用程序中
这句话是什么意思 - 将可扩展性设计到应用程序中。 是否存在可以使应用程序更具可扩展性的设计模式？ 这个问题主要针对 Web 应用程序或基于 SOA 中间件的应用程序。
What does it mean to say - Engineering scalability into applications. Are there design patterns that would make an application more scalable? This question is mainly in the context of web applications or SOA middleware based applications.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
当我想到“大规模应用程序”时，我想到了三个截然不同的事物：
将在大型横向扩展集群（远大于 1024 个核心）上运行的应用程序。
将处理比物理内存大得多的数据集的应用程序。
具有非常大的代码源库的应用程序。
每种“可扩展性”都会引入不同类型的复杂性，并且需要一组不同的妥协。
横向扩展应用程序通常依赖于使用 MPI 来协调各种进程的库。 一些应用程序是“令人尴尬的并行”，并且需要很少（甚至不需要）不同进程之间的通信才能完成任务（例如渲染动画电影的不同帧）。 这种类型的应用程序往往会受到基于 CPU 时钟速率或内存带宽的性能限制。 在大多数情况下，添加更多核心几乎总是会增加应用程序的“可扩展性”。 其他应用程序需要不同进程之间存在大量消息流量，以确保解决方案取得进展。 这种类型的应用程序往往会受到节点之间互连的整体性能的限制。 这些消息密集型应用程序可能受益于非常高的带宽、低延迟的互连（例如InfiniBand）。 这种类型的应用程序的可扩展性首先是尽量减少所有进程对共享文件或资源的使用。
第二种类型的可扩展性是在少量服务器（包括单个 SMP 类型服务器）上运行但处理非常大的数据集或大量事务的应用程序。 向系统添加物理内存通常可以提高应用程序的可扩展性。 然而，在某些时候物理内存将会耗尽。 大多数情况下，性能瓶颈会与系统的磁盘I/O性能有关。 在这些情况下，添加高性能持久存储（例如，剥离的硬盘驱动器阵列），甚至添加高性能互连到某种 SAN 都有助于提高应用程序的可扩展性。 这种类型的应用程序的工程可扩展性从算法决策开始，这些算法决策将最大限度地减少重复接触相同数据（或设置相同基础设施）的需要，而不是完成任务所需的次数（例如，打开与数据库的持久连接，而不是打开每笔交易都有一个新连接）。
最后，还有与源代码库的总体大小相关的可扩展性的情况。 在这些情况下，良好的软件工程实践可以帮助最大限度地减少冲突，并保持代码库干净。 大规模 C++ 软件设计这本书是我真正遇到的第一本接受了为大型源代码库软件开发提供最佳实践的挑战。 本书重点关注 C++ 作为实现语言，但指南和实践可以应用于任何项目或语言。 这种类型的应用程序的工程可扩展性涉及对代码结构做出高层决策，以最大限度地减少代码库内的依赖性（例如，不要有单个 .h，当更改时将强制重建整个代码库，请使用构建系统将尽可能重用 .o）。
When I think about "large scale applications" I think of three very different things:
Applications that will run across a large scale-out cluster (much larger than 1024 cores).
Applications that will deal with data sets that are much larger than physical memory.
Applications that have a very large source base for the code.
Each kind of "scalability" introduces a different kind of complexity, and requires a different set of compromises.
Scale-out applications typically rely on libraries that use MPI to coordinate the various processes. Some applications are "embarrassingly parallel" and require very little (or even no) communication between the different processes in order to complete the task (e.g. rendering different frames of an animated movie). This style of application tends to be performance bound based on CPU clock rates, or memory bandwidth,. In most cases, adding more cores will almost always increase the "scalability" of the application. Other applications require a great deal of message traffic between the different processes in order to ensure progress toward a solution. this style of application will tend to be bound on the overall performance of the interconnect between nodes. These message intensive applications may benefit from a very high bandwidth, low latency interconnect (e.g. InfiniBand). Engineering scalability into this style of application begins with minimizing the use of shared files or resources by all the processes.
The second style of scalability are applications that run on a small number of servers (including a single SMP style server), but that deal with a very large dataset, or a very large number of transactions. Adding physical memory to the system can often increase the scalability of the application. However, at some point physical memory will be exhausted. In most cases, the performance bottleneck will be related to the performance of the disc I/O of the system. In these cases, adding high performance persistent storage (e.g. stripped hard drive arrays), or even adding a high performance interconnect to some kind of SAN can help to increase the scalability of the application. Engineering scalability into this style of application begins with algorithmic decisions that will minimize the need to repeatedly touch the same data (or setup the same infrastructure) more than is necessary to complete the task (e.g. open a persistent connection to a database, instead of opening a new connection for each transaction).
Finally, there is the case of scalability related to the overall size of the source code base. In these instances, good software engineering practices can help to minimize conflicts, and to keep the code base clean. The book Large Scale C++ Software Design was the first one that I encountered that really took on the challenge of providing best practices for large source base software development. The book focuses on C++ as the implementation language, but the guidelines and practices can be applied to any project or language. Engineering scalability into this style of application involves making high level decisions about the structure of the code to minimize dependencies within the code base (e.g. do not have a single .h that when changed will force a rebuild of the entire code base, use a build system that will reuse .o's whenever possible).
从广义上讲，可扩展性意味着系统负载的增加可以通过按比例较小的资产增加来处理，而必须整理这些资产来服务该负载。
如果您的 Web 应用程序的负载增加了 100 倍，您会做什么？
可扩展性的一项基本原则是识别和消除处理中的潜在瓶颈，包括限制性任务的并行化。 但这只是一种味道； 我相信您会得到很多其他同样有效的答案。
编辑：请注意，瓶颈不仅仅出现在实际任务处理中。 它们可以是整体流程设置、必要的硬件操作、维护任务、重新设计/重构等等。
Very broadly, scalability means an increase in system load can be handled with a proportionally smaller increase in assets that must be marshaled to serve that load.
If the load on your web app increased by a factor of 100, what would you do?
One fundamental principal for scalability is the identification and elimination of potential bottlenecks in processing, including parallelization of constricting tasks. But that's just a taste; I'm sure you'll get lots of other equally valid answers.
Edit: note that bottlenecks occur not just in actual task processing. They can be in overall process setup, necessary hardware operations, maintenance tasks, redesign/refactoring, you name it.
以下是一些有关 Web 应用程序可扩展性的重要资源，可帮助您入门：Todd Hoff 的 highscalability.com、可扩展互联网架构，作者：Theo Schlossnagle，以及构建可扩展的网站，作者：Cal Henderson。 Highscalability.com 将为您提供许多值得一读的演示文稿和文章，包括 这篇来自 Danga 的文章 关于他们如何随着 LiveJournal 的发展而扩展它。
Here are some great resources on web application scalability to get you started: Todd Hoff's highscalability.com, Scalable Internet Architectures by Theo Schlossnagle, and Building Scalable Web Sites by Cal Henderson. Highscalability.com will point you to a lot of presentations and articles well worth reading, including this one from Danga about how they scaled LiveJournal as it grew.
我认为当您谈论网络时，您主要关心的是： 对
这样，您可以将一台服务器扩展到任意多个层（应用程序层、缓存层、数据库层），并在出现扩展问题时水平扩展这些层。
I think when you're talking about the web, you're mainly concerned with:
With this, you can stretch one server into however many tiers (application tier, caching tier, database tier) and expand those horizontally should a scaling problem arise.
可扩展性意味着如果负载/数据可以通过某个指标 N 来衡量，即用户数量、每天完成的事务总数等，并具有一些固定的响应要求 t，则应用程序可以重新配置以处理给定的任意 N资源增加 O(f(n))，其中 f(n) 是同一响应时间 t 内 N 的线性或接近线性函数。
通常，这意味着应用程序使用分布式架构，以便可以线性添加更多服务器、应用程序服务器、网络服务器、数据库服务器来处理更多用户。 也就是说，要处理两倍的用户，您需要添加两倍的数据库服务器、网络服务器、机器等。
即使理论上这通常也是不可能的，因为分发请求通常需要树状结构，因此缩放因子为 O( n * log(N))。 在实践中，由于您可以在树中使用较大的分支因子，并且分配成本与总体交易成本相比较小，因此 log(N) 因子并不重要。
Scaleability means that if the load/data can be measured by some metric N, i.e. number of users, total number of transactions done daily, etc., with some fixed response requirement t, that the application can be reconfigured to handle an arbitrary N given an increase in resources of O(f(n)) where f(n) is a linear or close to linear function of N within the same response time t.
Typically this means that the application uses a distributed architecture so that more servers, application servers, webservers, database servers can be added linearly to handle more users. I.e. to handle twice as many users, you would need to add twice the database servers, webservers, machines, etc.
Even theoretically this is not usually possible because distributing the requests usually requires a tree-like structure so that the scaling factor is O(n * log(N)). In practice, because you can use a large branching factor in the tree and the distribution cost is small compared to the overall transaction cost, the log(N) factor is not significant.