多玩YY往事②

说明：

这是小x 写的多玩 YY 往事三篇曲中的第二篇。在网易、多玩和腾讯三家知名互联网上市公司供职后的他，目前在老家湛江已经处于半退休状态，闲不住的他开发了一款叫做 GNB 的开源项目，可以实现去中心化，并且具有极致内网穿透能力，通过 P2P 进行三层网络交换的 SDVN（https://github.com/gnbdev/opengnb）。

序言：

多玩YY即将迎来成立二十周年，当下是2024年，此时听闻张云帆要履新字节跳动整体负责游戏业务，于是决定写一个系列的文章回顾当年多玩YY的往事，以亲历者的角度回顾这家在纳斯达克上市的公司初创时期在风雨飘摇中成长的经历，欢迎点赞收藏加关注一键三连。

文章重点是想讲述多玩早期几个重要的产品，因此我考虑了良久，选择以张云帆为主线去叙事，因为多玩YY在创办不到一年时间里连续推出三个重要的项目均获得了成功，这些产品都是由张云帆主导，为了叙事方便，在写作过程中当年一起在共事的默默无闻的程序员、运营、编辑有些人会被提及有些人没有提及，这里希望大家能够理解。

张云帆需要一个游戏公会系统

在到骏景花园骏盈轩xxx号正式创业之前，我已经提前开发了一套很稳定的论坛系统和一套开发了一半的通行证系统，在当时（2005年）的不少人的观念里新闻发布系统(CMS)和论坛基本上是一家互联网创业公司的标配，当时在国内一些没经验的创业公司就是整一套新闻发布系统和论坛系统就到处找投资，他们甚至不懂什么是通行证系统，这样做固然不对的，可是当时许多创业团队连一套稳定的CMS和论坛系统都开发不出来。

这其中一个原因是：当时的服务器硬件配置也远没有现在的配置那么好，举例说当时网易的许多服务器都是2G内存，用于数据库的服务器内存也就4G内存，比现在手机上的RAM还小，因此在2005年那时候几乎不可能单纯的通过堆硬件来取得这些Web系统的稳定。

另一个更重要原因是：在当时许多的程序员不懂得如何开发基于Web的高性能的系统，对于这个问题我2005年到北京出差时与好朋友小林(lxl)有过一次交流。

小林(lxl)就是林兴陆，他与李学凌有一个相同的网名都叫 lxl ，他们俩也相熟，毫无悬念，由于跟着蔡文胜做域名的业务，lxl.cn 这个域名一放出来就被小林(lxl)牢牢的抢注到手里。

小林(lxl)当时在给蔡文胜做一个项目，那是一个把 Windows 桌面程序和 Web Server 整合在一起的软件，这个软件的功能和 Google Destop 这个软件有点类似，小林(lxl)的软件架构大致是这样，在 Windows 的后台启动一个内部的Web Server提供网页服务，前台是一个Windows程序通过嵌入Web浏览器去访问这个内部的 Web Server 提供的网页，这样大部的UI的改动就可以通过修改 html 页面去实现，升级维护很方便，而软件的一些状态维护则放Windows原生程序里，要知道，在当时基于TCP短连接的http协议里维持用户的状态是一件比较麻烦的事情，小林这个设计很巧妙，两边都兼顾了，这种设计在当下的20024年是司空见惯的，小林(lxl)应该是当时(2005年)在国内第一个做这方面实践的人。

小林(lxl)和我说，他领导的团队中有好些很优秀的程序员，这些程序员在Windows程序开发上经验非常丰富，可是如果让他们开发基于Web的 CGI他们就适应不了如何在基于TCP短连接的http协议里几个http请求之间保持状态，因此他这个设计可以利用基于http的Web界面降低Windows原生程序的开发维护成本同时也解决了Web应用里状态机不好维护的问题。

我非常认同小林这种观点同时我也领悟到了一个事实：我们这些Web开发程序员虽说在当时炙手可热但这并不意味着我们那时的技术有多厉害，国内比我们厉害的程序员多去了，只不过当时掀起的互联网创业潮使得大环境里急需大量的Web开发程序员，而当时有这方面经验的程序员又太少了，我们只是比别人多掌握了一点点经验因而能够幸运的站在了靠近风口的边上，仅此而已。

与当时许多互联网创业者不一样的是，张云帆知道如何站在风口上并且知道如何在风口上准确快速找到定位带领团队前行。

多玩公会系统需要重构

在看了我部署的论坛系统之后，张云帆认为论坛对于多玩网没什么价值，他需要一套公会系统为游戏公会服务。

我一看游戏公会需求，这不就是在论坛系统的基础上加点功能吗，于是我们几个技术的伙伴就在一起改代码，可是做出来的效果很不理想，而老张坚持认为公会这个系统很有价值，最后我找来做兼职的一个叫陈磊的朋友提出由他来重构公会系统，陈磊对互联网和游戏的热情很大，他原本和我在长天做系统集成开发，对银行业务系统非常熟悉，还当过我的领导，因为他老婆要生孩子了，所以从系统集成公司辞职结束到处出差的生活，我建议李学凌老大请他过来当兼职。至于安排给陈磊的帮手是我大学还没毕业来公司实习的师弟小钟，多玩公会系统就交给这两个人重构了。

在华南这边要说到社区论坛系统就不得不提到两个人，一个是Pboy，一个是范瑞恒，Pboy是网易社区广州区的管理员（SYSOP），范瑞恒是网易社区的主程序，很重要的一个人，可惜本文没有篇幅去介绍，这里主要介绍一下Pboy和他管理的网易广州社区。

在我眼里Pboy是一个很传统的网易人，我非常认同Pboy对社区系统的理念，网易早期靠个人主页和社区论坛系统起家积累了大量的用户，网易社区 club.163.com 在国内曾经影响力很大，早年为网易许多新产品包括网游的推广起到了很大的作用。

当时的Pboy管理着网易广州社区上百个版面，每天有上千用户同时在线，大部分都是非常忠实的用户，范瑞恒开发的网易社区非常稳定，社区系统设计结构简单高效，我也曾经是网易社区的版主，直到今天我还与当年的网易社区里一些网友保持微信联系，再一个是我早年也担任过 Donews的论坛的版主所接触的都是传统的论坛系统，在我当时的眼里社区系统就应该是那个样子，因此要我那个2005年那个时间节点上接受张云帆提出公会系统的理念真的有点难。

有意思的是，在网易上班时我和Pboy很玩得来，Pboy和张云帆也很玩得来，现在回想起来这层关系我觉得张云帆当时对网易的社区系统应该是很了解的，他提出公会系统这个理念是有他自己思考的。

不管怎样，多玩公会系统还是要重构的，在陈磊和小钟重构多玩公会系统的时候，我在继续开发多玩的通行证系统，李学凌老大对我说：“小x，我们需要有一个最好的urs”，urs是universal register system的缩写，通俗点说就是用户注册和认证的系统，在用户只要登陆了通行证，就能访问这个网站上所有的服务，例如多玩游戏公会系统的用户认证就要依托在多玩的通行证系统上，这在当时是一个非常重要的系统，了解的人也不多，毫无疑问，这方面的概念我们是从网易通行证的设计上学到的。

我很快开发好了多玩通行证系统，李学凌老大对技术一向很感兴趣，见我开发好了 urs (通行证系统)就来问我是怎么开发，我大致讲了一下，就是用分库分表的方式把用户的数据通过hash算法相对均匀的放在100张mysql数据库表里，每张表存放100万条记录，这样我们就能够轻松存放1亿用户的数据，由于1张表只存放100万条记录，所以查询起来的的速度也比较快，限于文章的篇幅省略了部分技术内容，我还讲了当将来我们的用户超过1亿时我们该怎样扩容，李学凌老大听了很满意，在他看来，我们的通行证系统在性能上接近老东家网易的水平了。

多玩网的第一批种子用户和难搞的多玩通行证系统

多玩通行证上线后张云帆给了我一个数据库，里面是他创办的游戏公会的注册用户信息，他让我这些用户导入多玩通行证，看来这批游戏公会用户也就成了多玩网的第一批种子用户。

可没过几天，张云帆就来找我了，他说：“小x，你的通行证系统怎么不能用中文作为用户名注册啊？”，我说你看网易的通行证也没支持中文名作为用户名啊。

张云帆认为我们的通行证系统要有易用性，很多用户只懂得使用中文名注册，这时李学凌老大也加进来讨论，李老大问我假如我们的通行证系统支持中文用户名会怎样，我算了一下说，这样我们的系统容量就只有1000万了，但是后面可以通过重构优化支持1亿以上的用户。

由于1000万注册用户在当时（2005年）已经是一个很可怕的数字了，于是我们决定先让多玩的通行证系统支持中文用户名注册，我留意到李老大好像有点郁闷，他说：“嗯，现在只支持1000万用户了”。

当时多玩的通行证系统里允许中文用户名注册后只能支持1000万用户这个背景其实没前面讲的那么简单，张云帆的要求其实是用户在注册时要求输入一个用户id和一个支持中文的用户昵称还有密码，当用户在登录时用户可以通过用户id加上密码或者是输入用户昵称加上密码都能登录成功，根据这个需求，我们需要建一张对照表，并且这个对照表不好拆表，因此这张表的最大容量就是限制了通行证的最大容量。

那一张数据表的最大容量为什么是1000万呢，这个估算来自automan(刘红柳)的一个经验估算，automan认为当时的 Mysql 数据表在超过1000万条记录的时候访问就会变得很慢。

其实这种需求如果放在今天根本就不是个事，现在许多平台都同时支持用户名，邮箱，手机登陆，可是在当时我们的硬件资源很紧张，甚至没法通过用BDB这样的nosql 的方案去建多个索引，因为这些索引文件的备份、容错、同步一时半会搞不好。

尽管大家暂时接受了这个结果，对于我们说，李学凌老大就是我们的mentor，我们不想让他失望，后来没过多久记得是李欢主动对多玩通行证系统做了一次优化，在支持中文用户名的同时又能有1亿用户的容量，李学凌老大得知后很高兴，说：“嗯，现在我们又支持1个亿的用户了”。

后来事实证明支持中文昵称登陆的多玩通行证系统和多玩公会系统在很短时间里积累了大量的注册用户，多玩公会系统成了多玩早期最成功的平台，这也是老张创业的第二个获得巨大成功的产品。

张云帆在他的公会系统的首页放了一段简介，特地注明他的公会成立于北美，我一直没搞懂为什么要强调是北美，近年想起来问他，他给我解释了，可是我 GET 不到他的意思。

艰难的游戏公会系统重构

据陈磊后来说，开发多玩公会系统那段日子很难受，因为他老婆刚生完孩子就摔伤了手需要人照顾，原本说好兼职的工作因为没日没夜的开发事实上变成了全职，工资还照旧，陈磊以前在银行是用AS400，RS6000这些小型机，这方面他是专家，可是互联网行业所使用硬件比他以前使用的小型机配置低很多了，稳定性也差很多了，雷军借给我们的服务器得用来运行魔兽搜索引擎，因此陈磊手里只有方兴东借给我们比较好的一台Linux服务器，内存有4个G。

说到这里不得不佩服李学凌老大的人脉，据说是方兴东当时得到一笔千万级的投资，因此手里有许多服务器，方兴东老师很慷慨的借给我们一台，我登录上去一看，真的是很好的一台机器，我们都很感激方兴东老师。

用类似银行业务系统的开发模式去开发游戏公会系统

方兴东老师的Linux服务器虽然很好可毕竟不是小型机，陈磊的技术方案还是有点类似传统的银行系统小型机那套做法，尽管重构的过程很艰难可是陈磊毕竟在系统集成公司受过非常专业的训练并且很擅长带着新人搞开发，到最后新的公会系统居然就被他们两个人开发出来了，系统还很稳定，其实用现在的价值观看，陈磊这样的设计并没有错，只是当时我们的硬件资源太少了，因此我们经常不得不用一些旁门左道的技术手段去解决问题，这反而是不对的。

根据老张的设计意图重构的公会系统出来后，Toby(美术设计)给公会系统设计了一套非常漂亮界面，张云帆，刘涛（老张的大学同学），盈盈（张云帆当时的女朋友后来的张夫人）担任公会的管理员，多玩公会系统上线了。

在推广多玩游戏网玩游戏公会系统的时候，张云帆想了个叫“多玩游戏多喝水”的口号，至于这是什么意思不作解释，可能那年广州的夏天确实很热，大家每天要喝很多的水，配合着这个无厘头的宣传语多玩公会系统上线没几天就异常火爆，很快公会系统的数据库压力变得很大，同时系统也产生了大量的日志使得硬盘空间也很紧张，我经常看到小钟和陈磊在吃饭的时候维护服务器。当时我们为了延续网易的优良传统，在办公室免费给大家供应午餐晚餐，这样大家就可以不用离开办公室去找饭吃，节省出的时间可以用来工作。

当时负责给我们找煮饭阿姨的是张云帆，他开始找了一个四川的阿姨，可是我们这里大多人吃不惯四川口味，后来张云帆又找一个广州的阿姨来分担四川阿姨的工作，这个广州阿姨来了一天之后觉得太辛苦就回去了，据说是她家的房子拆迁了不差钱了。于是很长一段时间里一直都是这位四川阿姨给我们煮饭，结果就是每天都剩下很多饭菜放在冰箱里。后来到了晚上，我就用这些剩饭剩菜给大家做宵夜，因为每天剩的白米饭很多，我就经常给大家做炒饭，冰箱里有不少鸡蛋，我就把剩的菜和鸡蛋一起放到炒饭里，大家吃得很满意；当没有剩饭的时候，我就给大家做面条，我会准备一盆冰水，把面条放在沸水煮好后，放到冰水里浸，再放到锅和当天的剩菜一起炒，这样面条会很清爽，李欢每次都把我做的夜宵吃个干净。

多玩公会系统用户暴增，需要用门户级的技术来优化

多玩公会系统在很长的时间里是多玩网人气最高的平台，当时全国的游戏公会基本都会来进驻多玩网，那时李学凌老大在跟人介绍多玩的时候都会提到多玩的游戏公会，当时也就只有多玩网才提供这样的游戏公会系统服务。

有一天陈磊告诉我，游戏公会系统的数据库系统部分他已经优化到尽头了可是公会系统还是很慢，我相信这是事实，陈磊用的数据库不是 Mysql 而是 Postgres，在当时Mysql相比Postgres响应速度不算快，但比Mysql稳定很多，没遇到过崩溃。

我登入服务器一看，发现是公会系统提供静态图片下载的 Web Server 过载了，当时我们用的Apache Web Server，而这个Apache Web Server 除了转发 jsp 的请求外还承担了公会系统的图片、html页面等静态资源的下载，这时我知道我们已经不可能靠Apache web server来支撑公会系统的静态资源了，因为当时我们设定让Apache工作在多进程/线程模式下，大量用户的请求会导致产生大量的Apache进程/线程，这样CPU会处理不过来，由于有网易的工作经验，所以我知道如何去优化这个架构，我给图片等静态资源配置上了反向代理Squid。

Squid 的工作原理就是可以在单个进程里同时处理上千个HTTP请求，我们通过先让Squid接到用户的http请求然后转发到后端的Apache Server，Squid会在内存和磁盘中缓存Apache Server返回的html、css、js和图片等静态资源，在一定时间里，如果再有用户访问这些静态资源，Squid就会从内存或者本地磁盘中调取这些缓存数据直接返回给用户的浏览器，这样就极大减少后端的Apache Server的压力，前面讲过当时的Apache Server处理用户的http请求是用一个进程处理一个请求，因此资源消耗比较大，在Apache的前面加了一层Squid做缓存用户网页打开的速度就变得很快了。

在2005年， Squid是我们能找到的最好的开源的 Web Cache 方案，这在当时只有一些门级的网站例如新浪、网易、搜狐这些门户网站的新闻频道才会用到，一家叫蓝汛的CDN公司基于 Squid 做了大量改动开发了一个叫FC的系统在全国范围部署CDN节点为门户网站提供边缘加速服务，不过在当时多数网站都不需要用到这在加速服务，像网易社区这样的量级的产品都没有用到Squid来做加速，而张云帆推出这个游戏公会系统居然在上线一个月不到的时间里就需要用这种门户网站才会使用的技术来支撑，可见当时的公会系统有多火。

我知道有人看到这里会想到Nginx，Nginx Web Server 在国内推广是几年之后的事情。有意思的是，最早在网易里推广使用 Nginx 的是离开了多玩重新回到网易上班的李欢，ChinaUnix因此还邀请李欢去给网友们线下讲PPT分享使用Nginx的经验，我和李学凌也去了，由于李欢这次的技术分享太成功了被网友们围了个水泄不通不停的向他提问，我和李学凌则被远远的晾在一边，这一次应该是李欢人生中的高光时刻吧，据说李欢后来因此得了一个称号叫“中国Nginx教父”。

之所以花了如此多的篇幅讲解技术方面的话题，是因为这一系列的文章讲述的是二十年前发生的事情，我认为需要给年轻的读者详细描述清楚当时的行业背景；由于我从不玩网游也不和游戏玩家有接触，所以我只能选取这样一个叙事角度去讲述游戏公会系统这个多玩早期最重要的平台，希望你们阅读的时候感到新奇愉快。

魔兽每周停服维护我们遭遇的“链式反应”

在 Squid Web cache 部署上去之后，公会系统服务器CPU负载的压力一度降了下来，但没过多久陈磊告诉我，公会系统的服务器又变得很卡了，当这次我们去检查服务器时竟然发现是服务器的带宽满了可用户的请求还是源源不绝的过来。

服务器的负载一天比一天重，特别是周二这天某个时段，张云帆和刘涛告诉我们情况是这样的：周二这天魔兽服务器维护，玩家进不了游戏服就去逛游戏论坛，由于当时国内的魔兽世界的游戏论坛很火爆同时也很脆弱，当一群玩家把一个论坛挤垮之后就会转移到下一个论坛，当这个论坛又不堪负载崩溃时，两股论坛的玩家就会合成一股去访问再集聚到下一个论坛，然后又把后面那个论坛挤垮，张云帆称这种现象是“链式反应”，即幸运又不幸的是我们多玩的公会系统就在这“链式反应”中的其中一环，如果我们能扛住这波冲击，我们就能吸收这些玩家成为我们注册用户，如果我们扛不住，用户就走了。

于是每逢周二我们就死盯着服务器，只要服务进程一阻塞无法提供服务，我们就赶紧重启，直到魔兽世界游戏开服玩家散去，最后我们算是勉强扛住了，从今天的角度去看这个，只能说当时我们的技术实在是太弱了。