架构之美阅读(2)

本来都打算睡觉了,忍不住上来喷一下;我他妈真的被搞Java的和搞出版的震惊了。

 

(这里,搞Java != 用Java,如果你真的是“搞”Java的,那你只有自己衡量是不是被我扫到了...)

 

第四章:

 

妈的此文简直令人发指。一个像咱们这些菜鸟一样误解职责链作用的“天才架构师”:词儿倒是一套一套的。

 

(我倒是发现这个职责链真是设计模式的“驴桥”,谁功夫下到了,到了这一关一目了然)

 

通篇唠叨他的那些破烂细节。不知道是不是从来没人这么捧他,恨不得连内裤是什么颜色都要介绍一下,昆汀的电影么?

 

就不论那井底之蛙的见识了,整个一拿着鸡毛当令箭的祥林嫂。有这功夫看两眼.NET WinForm的代码都比听他白活好。

 

这厮完成任务没有?有。这章有思考没有?有。但何时砖家的标准降到如此之低了?

 

说实话,我就不明白出版社怎么就不能多掏点钱,雇个专业点的顾问识别下呢,难道美国出版社也缺钱不成。

 

(为什么我跟泼妇骂街似的?因为此文已经达到了我没办法一点一点具体的数落的大成境界)

 

Update: 主要是此类人物的判断和结论中,太多的“因为->所以”经不起推敲了,但对于经验不足的人却难于发现。

 

对了,这厮的简历是:致力于为开发人员“提高”水平和“减少”痛苦;他还TM的得了Jolt大奖。Erlang作者所言不虚啊....

 

比较上一代程序员和这一代,美国人种绝对退化了。赶紧苦练英文,渗透过去发财吧。

 

第三章:

 

本章根本是要把Web那套搬游戏里去,不过毕竟还是试验阶段的玩意,我也没能力评价,最后结果会说明一切。

 

这个团队处理任务当的想法是值得大家借鉴的;可惜本文缺乏必要的架构和决定的细节,而广告性质更浓一些。

 

无论是数据性质的,还是执行码性质的,如何将动作封装成一个一个的单位,可以传输、运行,也是我一直在考虑的问题。

 

区别于基本的Map-Reduce,我个人认为这样的设计是分布式计算的基础。

 

另一方面,服务器在游戏领域,就我所想,最关键的角色实际上是验证数据的可靠性,防止作弊。

 

(其次是提供中转节点,保证所有人的响应不至于离平均响应时间差距太大,影响公平性和其它表现)

 

在这个方面,难道真的没有更P2P的解决办法吗?这是我阅读这一章的时候一直存在的一个疑问。

 

直觉上,我认为不是没有解决之道,关键在于三方面:

 

1. 用于验证的数据量足够小。

 

2. 如何选择仲裁者。

 

3. 决定性因素:还是性价比。

 

第三点来自于,服务器节点是必定不能缺的,因为服务器还要承载关于当前世界状态的所有信息。

 

在这样一个前提下,优化服务器端收集信息的频率和其它计算量,是不是真的有必要呢?这需要样本分析了。

 

不过我不赞成作者的先持久化,再分配的方案。取而代之的,两者应该是并行的。甚至可以降低持久化的频率。

 

我觉得作者对现存架构的攻击不符合实际情况。崩溃是有的,但概率极低、更不是非得损失几个小时的数据。

 

所以这中间可以找到一个方案(甚至不是折中),去避免数据损失、提高分布的灵活性,但又避免无谓的工作。

 

另一方面,作者的分析和结论实际上是淡化了游戏数据的临时性,这同样也是一个关键的前提条件。

posted on 2010-01-26 14:42  怪怪  阅读(1123)  评论(0编辑  收藏  举报

导航