BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

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

| 作者 Floyd Marinescu 关注 32 他的粉丝 ,译者 黄璜 关注 0 他的粉丝 发布于 2008年5月15日. 估计阅读时间: 2 分钟 | Google、Facebook、Pinterest、阿里、腾讯 等顶尖技术团队的上百个可供参考的架构实例!

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

问题:

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

解决之道:

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

Udi的收获:

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

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

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

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

好文章、好例子 by 冯 希顺

受教了,从头到尾看一遍感觉像自己都亲身经历了一遍似的,呵呵。

Re: 好文章、好例子 by Zheng Can

深有同感,呵呵~~

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

2 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT