昨晚看完了汤姆汉克斯的<费城故事>,结合之前看的<观止>(写Windows nt开发过程的),以及国内几大互联网公司的发家史(网易,腾讯,盛大之类),感慨良多.小小总结一下:
1 想要成为好的程序员,必须要让自己偏执狂一下
2 人在30岁之后的成就在于其在30岁之前的付出,过早的买房追求稳定其实不利于自己的长远发展
3 人活着还是要有点理想,哪怕在生命垂危之时.
4 中国的社会更加注重人与人之间的关系,通过搞技术来成功的难度很大
5 社会无论如何,应该追求我心
6 不对你的程序要求尽善尽美,也就不可能产生好的程序
闲扯这么多,开始正题吧(对于互联网分布式程序这块,我也是新手,希望各位大侠能指点迷津):
产品描述:
类似于QQ休闲游戏平台,先运行于街机,后面考虑扩展到PC,手机,平台电脑.
相关技术需求:
1 跨平台,客户端和服务器端都需要做成跨平台的:客户端的跨平台已经不是问题,现有的2D引擎在设计的时候已经将跨平台因素考虑进去,剩下只是将平台相关层的接口实现即可.服务器端的跨平台主要是考虑linux下开发便捷性不如windows,利用跨平台的网络通讯库,先在windows上写好,然后再向linux移植.这个应该是可行的,因为我们准备用到的库zeromq,libevent,zookeeper,Google protobuf都是跨平台的
2 单点失效不影响整体服务,对于休闲游戏平台来说,这点感觉还是比较好处理,因为每个房间服务器相对独立,一个房间挂掉,用户可以选择其它房间.
3 服务器端可以无痛升级,即升级时不用停掉整个服务器端程序
4 服务器端负载可以通过简单的加机器来扩展
5 简单易用的服务端监控系统,方便维护
相关技术实现考虑:
1 每一个部分都是可测的,无论从最基本的单元测试确保独立模块的稳定可靠,还是从后面的集成测试,回归测试,确保整个产品有效.可测,bug可重现这一点对于开发大型项目来说尤其重要,这一点在开发之前的局域网版本(30多个游戏,跨没有操作系统的嵌入式平台和Windows)已经得到绝对的验证.可测,可验证将作为之后开发模块和子系统的必要条件,bug可重现这一点在分布式系统上好像比较难搞,尚待进一步的探索,客户端的bug可重现我们已经实现,也是作为2代引擎的核心技术,大大方便了上层游戏的开发.
2 先用脚本语言(python之类)搭建快速原型,满足核心的需求,尽早发现设计中存在的问题,然后才开始进一步深入的设计
3 按照陈硕的分布式系统设计经验,总结一下几点:为容错做设计,注重可维护性,要有可靠的名字服务,要有消息通讯语言,并且可以无痛升级.针对以上几点,初步考虑如下:
a 为容错做设计:zeromq中推荐了两种分布式系统模式,基于代理和p2p两种,其guide中有做详细的介绍,学习其设计思想即可
b 注重可维护性:按照陈硕的推荐,每台机器上有slaver的进程汇报机器的运行情况,同时每个服务器进程都内置http服务接口,用于展现其内部的运行状态
c 要有专门的消息通讯语言,支持无痛升级:Google protobuf是不错的选择
d 要有可靠的名字服务:zookeeper能完成该功能,除开名字服务外,它还可以用于配置分布式系统
4 服务器端偏向于松散的架构,通过协议来描述各个部分之间交互过程,具体参照zeromq的MDP协议设计方案,代码实现有python版本和C版本
5 为了实现高并发性,客户端和服务器集群之间的通讯使用高性能的通讯库libevent来设计,服务器集群内部通讯用zeromq即可.客户端连接服务器的大致过程为:从登陆服务器上获得会话id和房间服务器列表,然后玩家选择相应的房间服务器接入进行游戏.为了实现高并发,玩家并不是直接与房间服务器相连,而是通过中间的连接服务器与其相连.
6 服务器端与客户端的通讯除开使用tcp之外,也要用到udp,主要用在对操作响应比较快的游戏上(类似于vs对战平台上的即时对抗类游戏).这一块需要单独拿出来做
最后两点目前我还没有想到具体实现方案,需要进一步的探索,希望有经验的朋友可以指点迷津:)
初步架构和流程

今天先写到这里了,希望各位多提意见,谢谢啦!

浙公网安备 33010602011771号