那是2005年6月的一个晴天，看着为之奋斗两年的新订单系统在生产环境上线，我们精神无比振奋。我们的合作伙伴开始发送订单，监视系统也告诉我们一切工作正常。一个小时之后，我们的COO给战略合作伙伴发了一封邮件，告诉他们可以将订单发送到新系统了。五分钟之后，一台服务器宕掉了，一分钟后，又有两台服务器瘫痪。客户开始打电话过来，那时我们明白，我们将有一段时间见不着太阳了。

　　相关厂商内容

　　如何基于NCP开放平台设计并实现一个公告板应用?

　　SOY Framework：Java富客户端快速开发框架

　　(7.17成都)专享免费电子票下载：SOA中国关键任务论坛

　　原本意在提高战略伙伴订单利润率的系统就这样崩溃了。抓狂的COO不得不再次给战略伙伴发去邮件，不过这次是让他们使用旧系统。奇怪的是，尽管我们有后备服务器，但是来自战略伙伴的少量订单就击垮了一台服务器。能供大量一般合作伙伴使用的系统却偏偏应付不了为数不多的战略合作伙伴。

　　这是一个关于我们所犯的错，我们如何改正错误，以及最后顺利完成项目的故事。

　　“最佳实践” 远远不够

　　尽管我们设计系统时翻阅了众多供应商所提供的最佳实践文档，使用了无状态的请求处理逻辑、分层结构、分层部署、分离OLTP 和OLAP服务器，但是从没有人告诉我们这个系统将要应对不同类型的伸缩性问题。在2003年，我们设计了和系统效率有关的关键部分。在2004年，我们经受住了负载和压力测试的考验。因此，我们都信心满满地以为我们将各方面都覆盖到了。

　　通过筛选审查服务器日志和监视系统的事件，我们发现来自战略伙伴的订单和一般合作伙伴的订单有着很大的不同。一般合作伙伴一次订购几百件物品，战略伙伴一次发来的订单却有成千上万行。请求的数据量甚至可以达到数百兆字节。我们的消息基础设施和对象/关系映射代码都从未承受过如此负载的测试。服务器核心为了反序列化所有这些XML数据承受了前所未有的考验，处理单个请求就能消耗掉半G内存。数据库锁的占用时间达到了几分钟而不是毫秒级。当线程超时后，垃圾回收机制开始疯狂地回收内存，这更加损害了系统的可用性。

　　我们做的第一件事就是在性能测试实验室再现现实中的场景。每当我们一遍一遍的测试而系统一次又一次的崩溃时，我们面面相觑，都不敢相信。我不断告诉自己：“我们做了书上说的每一件事，怎么会是这样?”

　　事实上，这是我工作中遇到的第一家真正给你时间和预算让你一切都照着书本去做的公司。我们没有任何的借口。可当书本远远不够解决问题时，你能做些什么呢?

　　不同类型的伸缩性

　　最后发现，每秒的请求数仅仅是可伸缩性的一方面而已。我们经历痛苦找到的其它方面还包括：

　　消息的大小

　　每个请求的CPU利用率

　　每个请求的内存利用率

　　每个请求的IO(和网络)利用率

　　每个请求的总处理时间

　　消息的大小看似对其它的各个方面都有很大的影响。当消息增大时，它会占用更多的CPU时间来反序列化，消耗更多的内存来保存结果数据，更多的网络带宽和IO来进行数据库读写操作，所有这些加起来就会影响总的处理时间。然而，即使是像给一个合作伙伴的所有待处理订单打折这样的小请求，也会因所处理数据量不同而受到影响。