文章：智能服务契约带来的巨大伸缩性

Udi Dahan讲述了在实现一个新订单系统时所遇到的一次经历，当时大尺寸消息的传送影响了系统的伸缩性，甚至导致了服务器瘫痪。这篇文章叙述了他们如何查出问题并给出了他们的解决方案，“通过改变我们的服务契约并引入有状态的交互，使得我们能够管理那些和系统性能息息相关的状态”。

问题：

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

解决之道：

与之前的一条“创建订单信息”不同，合作伙伴可以随着时间动态地发送给我们多条“订单信息”，关键字是：（合作伙伴id，采购订单编号）。当该采购订单编号的所有条目完成后，他们可以发来一个“完成”标志为真的“订单信息”。这是有状态的交互......一旦每个请求的资源利用率得以下降，延迟也得以明显下降，但是吞吐率却比我们预期的更高。

Udi的收获：

我最大的收获是：可伸缩性不是是或不是这样一个简单的问题。除了并发用户数量和在线服务器的数量之外，可伸缩性还是一个多维的成本函数。对于某个响应时间的需求，峰值和均值请求的比率，消息大小，格式，每个请求的内存工作集大小，每个请求的CPU/IO利用率，一个解决方案需要花多大的代价？对于战略伙伴有意义的技术选型对一般合作伙伴又不具成本效益。始终站在业务的角度来得出结论——当他们发现成本（前端和进行中）盖过产生的回报的时候他们就可能改变性能需求。

你也曾经有过类似的经历吗？

阅读全文：智能服务契约带来的巨大伸缩性。