跟MMO的架构很像啊

mark

Tortoisesvn好像也可以吧

你试试Beyond compare和compare it 看看

@zhuangzhuang1988 可是我不会python呀

@sunriseyuen 推荐下你们已经在实用的工具，策划还是得用word及excel

word文档不是自带版本管理，跟踪么？参考http://www.greggalipeau.com/2010/09/16/sharepoint-compare-differences-in-word-documents/

NB 不过其实有了Python下了reStructuredText感觉就够了

有很多不错的用来比较word 和 excel的工具啊.为何没有呢? 文本的格式似乎还不够直观啊,如果做成word那样会好些.

Markdown确实不错，我们部门都是用Markdown写API文档

哈哈，前段时间也看了一下markdown 好玩的东西

是的，一个小软件而已

SF LZ是一个人写的么,先看看!

@mynetstudy @钢铁奏鸣曲 我说得不够清楚，文中所称的Session Server的意思是说一个高速的共享数据的服务，并非HTTP里的Session或Cookie

博主的第二个架构方案就对了。恭喜。 通常的大型架构中，都只有2个连接，一个用于登陆/全局（长连接） 另一个连接是透明的连接。其实从规模上来说，超大型架构，像魔兽世界这种，考虑到各个国家和地区的需求的不同，设计雏形是只有一个gateway的，通过“可编程NAT”做后端的TCP数据映射，这个模块通常是硬件可编程设备，以支撑超大流量。当然，在大陆地区，因为网易是代理，需求有变，所以才把loginServer从gateway后端独立到前端，形成2个连接渠道。如果博主不卖平台，web，login，等等完全可以由一个gateway来担当，对外就是一个IP，甚至是同一个端口。

@mynetstudy 从开销的角度确实可以使用cookie，但是从安全的角度，只能使用session，综上，可以考虑不重要的数据和前端缓存现实数据使用cookie，敏感数据还是得用session。

很好的东东，不过给个建议，Session最好用cookie代替，中间使用加密规则，这样不仅可以减少共享服务器的压力，IO和连接数,

@不能飚车 以前做过相应的开发，行业搜索引擎项目，但是最终没有商用，这次应该是会商用的，呵呵。我会全程记录下的，另本文相关的补充补发了一文，请大家提提建议《[url=http://www.cnblogs.com/yihuiso/archive/2010/10/22/1858119.html]一款SNS战略休闲游戏开发笔记01——分布式系统逻辑架构设计的补充与讨论[/url]》

一挥原创，版权所有，想转就转！ 我喜欢这句话，非常欣赏！

这种项目会很锻炼人，建议全盘考虑，但是分步实施，否则很难测试，以及很难满足进度要求。 个人也经常考虑这种系统，但是都是旧系统改造，没有机会全新设计。觉得其中最重要和最难的是容灾，比如某一台服务器突然挂了，某一个磁盘突然坏了，那当时正在执行的服务咋无损切换。如果能做到这一点，那相应的重启、扩容，其实都解决了。 强烈关注哈～

@Phantaci.com 谢谢你的提意，DB这一块我是这样打算的，以Mysql为主数据存储，而前缀配置Cache Server,程序里写一个DB代理，进行Mysql的主读写分离以及后期可能的sharding处理 @魏琼东,@不能飚车 虽各类绘图制表软件还算熟悉，但用这些软件时我总觉得影响思维，等整个笔记写完了后再用软件重绘一下，呵呵。

建议楼主设计一个DB前端. db前端用于连接游戏的多个DB. db前端就是一个数据存取代理服务器.

这个图画得太惨了点，既然在搞设计了，还是用绘图软件画嘛～～呵呵，支持分布式架构，这是一个很长远的发展方向，经久不衰，期待连载

很不错文章

@花祭果凛 这个体系用户会在游戏过程与三个服务建立连接，确实被改数据的可能会比一个连接更高，但如果采用Login Server来中转响应性能可能会是个问题，但一个用户都放在一台服务器上处理，响应也会有问题，请做游戏服务器开发的同学给个建议吧！

@辰 我是打算通过自实现的SESSION SERVER，你有没有更好更简单的方式呢？

@黑色 谢谢你的建议，理论上说你说很对，但是如果一直只用登录服务器与客户端登录，对性能与扩展性会不会有影响？

@superstar 是打算用.net开发的，理想只是让它也可以兼容mono

@基拉大神 本来我的字就对不住观众，再加上手写板试用，呵呵！

只想知道，如何做服务器之间数据同步？ 难道说所有服务器连接一个数据库？

在登录后，全部交互就要通过内部通讯来处理咯，不然被改的几率很大滴 补充：不知道你做过SF没，全部游戏通通都只有一个对外的网关来处理，防止数据被篡改

如果我做外挂，我会在这做手脚 4 War Service(WS) A.战斗数据处理 B.战斗数据保存 搞个N倍经验金钱什么的

楼主在那家公司做用了什么技术的，.net的？

学习了

楼主这个字不敢恭维啊，呵呵

呵。小弟也用MVC beta做了个网站,并写了总结。
www.51xiangyin.com 在这里广告下。
总结地址在我博客主页就有。

英雄，你的Duw.web.Routing 是怎么和System.web.MVC 结合在一起的啊。。

@Leven
都满人了，还做嘛广告啊，主要想LZ进去和你探讨探讨而已
哈哈

@Leven，其实我是一个拿来主义者。
如果没有研究清晰它的思路，我如何修改且保持应用兼容？
对升级来说由于我只是改变了它的一些实现方式，对外是一模一样，所以对其它人不会造成太大影响。
但很要命的v2与V3及以后有太大差别，总是要修改程序。还有V3以后的新功能或扩展似乎主要是扩充了更多的服务器端控件（HTML.xxx),这些可以提高开发效率但是性能是我们做一个较大的项目需要考虑的，你们看看MVC的代码就会发现<%=HTML.Select%>等的性能损失。
是的我对性能是很重视的，我最欣赏的就是google类的UE！

@Q.Lee.lulu
lulu在这儿还不忘广告..佩服
@一挥
看楼主的文章.感觉楼主是个蛮喜欢修改开发库的开发者.个人认为这不是好习惯呢.首先冒的风险太大.在没有透彻了解开发库的情况下修改.很有可能出现无法预料的问题.再次就是使用修改过的开发库容易导致交流问题和程序的后续维护.每个人的理解都有不同.说不定你修改的部分正好对别的开发人员造成困扰了.最后,mvc框架我不认为有很大的性能问题,有些性能问题往往是使用不当导致的,如果有异议希望楼主能明确指出有问题的地方.大家能讨论下.

期待后文！！
期待性能的提高！！
PS: 有兴趣可以加ASP.NET MVC 交流QQ群1215279 大家交流一下

--引用--------------------------------------------------
cnlamar: 有些东西看似复杂,以为无必要,也许只是你没理解,谦虚一点,理解下别人为什么会写那么复杂,仅仅如此.
--------------------------------------------------------
接受批评，但请不要太为难我的文字语病，我不是一个好的作者。

这是根据我们自己的要求（主要是性能）修改了一下mvc，不敢谈“开源”二字。由于现在我们还在测试它的稳定性及性能测试，后续文章会附上源码及简单的性能测试数据。

没有发现代码

有些东西看似复杂,以为无必要,也许只是你没理解,谦虚一点,理解下别人为什么会写那么复杂,仅仅如此.

----------------------------------------------------
如此不是更加简单明了?至于你担心的VidaData中xxx为空的情况.根本无需考虑.这儿如果为空则会错误,只需要简单排错即可,楼主提供一个Has方法.我认为纯粹是降低执行效率.
---------------------------------------------------
很有道理，采纳！

看不到东西...

--引用--------------------------------------------------
一挥: --引用--------------------------------------------------
Leven: 楼主的方式,实在是有误导初学者之嫌...而且还是使用的这么老的版本
建议认真学学mvc后再写吧.
--------------------------------------------------------
谢谢批评，但是我请告诉我新的mvc preview3/preview4/previewn有些什么特别的改变或改进呢？你用哪个版本进行了什么应用的开发，是实际用的还是学习用？
--------------------------------------------------------
首先说明一点.既然楼主的项目用了p2.看样子项目不小.升级估计也麻烦.我也仅在此一提而已.主要是对楼主的几个修改不认同:
1."在应用mvc之前我们都是用Request["id"]的方式获取",mvc和routing的出现就是让我们从Request取值中解脱出来(p5中这一理念更为显然),楼主却反其道而行之.更改源码搞了这么个功能,所以我不赞同.
2."修改了ViewData类，使ViewData["key"]不区分大小写",个人认为完全多此一举.这是一个Dictionary对象.该对象的key本来就是区分大小写的.你这么一改,别人反而迷惑.
3.增加用配置文件配置route规则,这点赞同
4.新增扩展方法获取ViewData的数据.个人认为用处不大.可能在有的时候可以获得一定的便利.但是实现的代码我不大赞同,这样一来,既损失了效率,又让View中的代码更为隐晦,比如public static T Get<T>(this System.Web.Mvc.ViewData obj, string key),想必楼主是为了实现:
while((type t=ViewData.Get<type>("xxx") != null)
{
xxx t;
}
之类的代码.但是对于刚看到这部分代码的View开发人员不可避免的产生迷惑.为什么不直接
type tc=ViewData("xxx") as type;
foreach(var item in tc)
{
xxx item;
}
如此不是更加简单明了?至于你担心的VidaData中xxx为空的情况.根本无需考虑.这儿如果为空则会错误,只需要简单排错即可,楼主提供一个Has方法.我认为纯粹是降低执行效率.
5.给controller增加一个类似.aspx里的Url.Action("story","space",{id=34})的方法Util.GetUrl(),这个方法在特殊情况下是很不错.但是如果被滥用,将严重破坏整个mvc系统的构架.
ok.这一篇就说到这儿.等下去拜读下楼主另一篇.

又一文,呵呵,真是快啊

估计以后这样的组件会有很多开源的