这篇文章是一个掠影，关于在负载增加时，你的精雕细琢的程序可能会遇到的所有坏事情：所有会突然导致损失的地狱。当然你可以扩展或扩大，但是你也可以选择 更好的编程。使你的系统能处理更大的负载。这能节约经费，因为只需要更少的容器，而且这会使整个应用更加可靠并具有更好的响应时间。同时这对程序员也是一 个极大的满足。 大量的对象当对象的数量变多以后，我们通常会遇到伸缩性问题。随着对象数量增长，对所有类型资源的清晰的使用被强调突出出来。连续的失败引起无限的事件流在大量的网络故障场景，从来就没有足够的时间进行系统恢复。我们处于持续的压力状态。 大量的高优先级工作例如，重选路由是一个高优先级的活动。如果存在大量的不能屏蔽或消除的重选路由工作，那么资源将会被持续的消耗，用来支持这些高优先级的工作。 更大的数据流随着媒体资产大小的增长，系统的负载也增加了。随着请求来源数量的增加，系统负载也增加了。 特征潜变随着更多的特性被添加，系统中的漏洞要比系统曾经设想中的要多。 客户端的增加更多的客户端意味着更多的资源使用。线程是为客户端建立的，以便可以将事件推送给它们。内存被用来做客户端队列。网络带宽被用来通信。为了每个客户端，每个客户数据都需要被维护。 不太好的设计决策有许多设计上的问题能导致伸缩性的问题。
假设是无效的大多数你做出的估计都是无效的，有关于你正在使用内存数量、某些事情需要的时间、什么才是合理的超时、在一个时刻你能够消耗的数量，故障有多大几率发生，系统中不同的点潜伏的问题、你的队列需要有多大，等等。 内存溢出内存使用的基线增长，以及内存使用的峰值增长。这些可能会引起内存溢出（Out of Memory）。 CPU 匮乏由于需要操作更多的对象，有更多的对象操作需要更长的时间。这使得CPU可用性降低，进而导致其它操作没有资源。一个地方的匮乏可以传播到其它地方。可能 没有足够的CPU来执行必须要做的工作。之所以这样是因为工作的基线数值很高，或者某个特定场景导致许多高优先级的工作需要被完成。原生资源使用量增长更多的对象占用了更多的内存。如果有人想支持1千万同步对象，你可能办不到，因为很简单你无法获得足够的内存。 隐含资源使用量增长
大多数功能会将许多额外的资源用于每个以“原生”方式使用的资源。如果你在两个不同的列表中存储了一个对象，那么该对象数量的增长将会带来两倍的内存使用
量增长。队列的大小也需要向上调整。磁盘的数量需要增长。将数据复制到二级存储所需要的时间有增长。将数据装载进一个应用所需要的时间有增长。为了所有这
些，CPU的使用量有增长。引导时间有增长。 事件爆炸 许多系统中都新增了无数的工作流。网站服务器和应用程序服务器需要为巨型用户群提供服务，所以需求有多大，系统提供的服务就有多少。这样的工作永无止境。用户的请求每周7天每天24小时不停的来。所以服务器的CPU使用率很容易就打到100%。 一般都把100%的CPU使用率当成一个坏信号。为了避免这样，所以我们构建了非常复杂的架构以达到负载平衡，复制信号和服务器集群。 CPU是不会感觉到累的，所以你就想我们可以尽可能多的提高CPU的使用率。 另一方面，我们也通过最大限度的增加应届资源来提供效率。 在服务器端我们总是认为得保持CPU的低使用率以保证服务器能维持一个文档的响应速度。这样的做法是出于这样的考虑，如果没有可用的CPU资源，那么我们就不能在可用户可接受的响应时间内给出响应，或者去做其他的事情。 CPU 100%的使用率真的是个问题吗？使用空闲的CPU资源，与其使用任务的优先级这样简单的电脑程序的认知方法去构建系统，而不去深究使系统低量的工作负担，也不去搜集信息去做一些特别的决策，这真的不是一个问题？ 除了根据负载平衡原则而构建笨拙的系统，猜测使用线程的数量和线程的优先级之外，我们束手无策。 要删除系统的功能的时候要从架构方面小心考虑。现在的应用构架很难决定程序是怎么跑的。 |
