架构之美阅读(2)

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

 

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

 

第四章：

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

第三章：

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

2. 如何选择仲裁者。

 

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

 

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

 

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

 

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

 

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

 

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

 

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