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

  • Floyd Marinescu
  • 黄璜

2008 年 5 月 14 日

话题:SOA.NET架构语言 & 开发

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

问题:

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

解决之道:

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

Udi 的收获:

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

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

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

SOA.NET架构语言 & 开发