新产品上市，你准备好了吗 转载---大宝

sodme 大宝

更多选项 12月1日, 下午4时02分

主题：新产品上市，你准备好了吗：关于服务器性能、安全、稳定的全面监控

我们产品前后历经多次面向不同规模用户的测试，每一次的测试也都会让产品更进一步。在已经过去的这些测试里，我曾经对同一个问题一直耿耿于怀：我很希望公司在每一个新产品上市的时候，能向这个新产品派驻一两个富有经验的技术人员，以指导、协助他们完成产品上市前应该作的准备，但是，很可惜，直到我们成长为一个相对成熟的运营产品之后，我们都没有得到过任何这方面的帮助，一直是自己摸索，痛苦而又漫长。

好吧，我希望同样的事，不要一而再、再而三的在更多同行身上重演了，所以，我想聊一些新产品上市所应该准备的事情，供大家参考，也留存我们自己的记忆。

以我们自己的项目为例，我把产品上市前，服务器的性能监控内容分成这样几类：

1. 服务器内存使用、回收的统计、分析机制，更详细的，要统计到各类对象、各玩法、各系统的分别占用情况；
2. 网络流量（含收发包双向流量）的监控、统计、分析机制；
3. CPU使用率的统计、分析机制（结合逻辑架构，细分到各系统、各功能的具体占用）；
4. 数据库存取效率、存取流量，数据内容大小的统计、分析机制

以上是哪些内容应该作监控，至于如何作监控，无非是：尽可能详细、具体的统计出是哪些环节、哪个步骤、哪些系统占用了具体多少的系统资源。统计的工具，
可以采用一些已有的工具，也可以完全自己内建监控体系，我们采用的是后者：自建完整的服务器性能内部监控体系。

具体来说：
在内存使用上，我们尽可能的使用内存池技术来管理引擎层对象的内存使用，对脚本层的内存管理则采用基本内存池的buddy算法（脚本用的是lua），采用内存池一是方便查证内存泄漏，二是可以给策划一个紧箍咒，方便双方商定各类资源的上限（比如怪的数量）；
在网络流量的统计上，我们分别统计单个玩家上下行各类型网络包单位时间内的包数量、包大小、某场景的玩家聚集数，发现问题后，通过两个方法优化流量：减少收发包个数，减少单包大小；
在CPU使用率上，我们在帧轮询机制内和服务器运行的大循环内，对各主要系统进行CPU耗用时间监控，各大系统内又会有更细粒度的耗用时间记录，以此逐层定位性能消耗点；
在数据库操作的效率上，会统计各操作的前后耗用时间，涉及到的数据内容，注意：这里主要是针对逻辑点而言的，而不纯粹是单个的SQL操作时间。

对于一款商业运营的网游产品而言，服务器至少应该保证连续稳定运行一周的时间，这是很多新产品需要跨过的第一道槛，什么时候你作到了连续运行一周不出问题、稳定、高效，什么时候才算是在技术层面真正过了关，注意，这个一周，一定指的是完完整整的至少7天，差一天都不能成为一款合格的商业产品。

我们产品对以上四个方面内容的监控，并不是一次性全部建完了的，是慢慢摸索出来的。当人数压力越来越大时，总会发现系统一些新的不稳定和异常因素，比如刚开始并没有这么严格的监控各类型包的数量、大小，但运行了一段时间后发现网络包突然多了，流量突然变大了，于是就会找原因，在找原因的过程中也就会不断的把各种机制逐渐建立了起来。所幸的是，同行的新产品，在看到这个贴子后，可以不用经历我们的摸索期，而先行建立这样的机制了。:)

我们都知道，网游新产品上市时，普遍面对的一个问题都是新人涌入很多，玩家过于集中，服务器性能各方面的压力都将很大。这时，出于技术人员的本能反应， 我们都会强烈建议策划调整新手进入路线，减少玩家聚集度，以缓解服务器压力。嗯，这种想法严格来说很正当，但是，作为一个想有所作为的产品而言，我给的建议仍然是，使劲吃奶的力气你都要尽可能的优化下去，中国玩家普遍都喜欢凑热闹，越是热闹的地方越是愿意去，越是热闹的产品越愿意玩，如果一个产品当新玩家上线时，举目望去凄凄凉凉，空无一人，也会直接影响到玩家对一款产品是否够火的判断。从产品层面来说，我们应该欢迎热闹，而不是相反去拒绝热闹。技
术人员辛辛苦苦作几年，为的就是产品能成功，能赢利，为的也就是这一回，所以，尽管到时会背负很大的压力，也要坚持把性能尽可能的优化下去。

除了性能压力之外，我认为，面向玩家服务而言，我们最应该作的是，不管采用什么方法，都要尽可能完整的确保玩家数据安全。稍微慢一点，挤一点还不伤大雅，但如果频繁发生数据丢失、回档之类的运营事故，对官方形象和玩家信心的打击将是致命的。但是，安全和稳定，是具体到每一天开发内容之中的，是需要根植到每一个开发者思想深处的。如果是等到产品已经上市的时候再提安全，可能已经有点晚了。通常情况下，每一个新产品在开始测试时，几乎都会发生服务器异常当机，相应的，就会发生玩家的数据丢失。

所以，对待玩家的数据安全，我们应该从以下几个方面着手去作：
1. 在研发期，就应该加强开发者的安全教育，安全编码不仅仅是一种习惯，更是一种工作态度，要把玩家数据安全放在第一位，如果有必要，有时宁愿牺牲掉一些小性能来保证安全；
2. 要建立完整的针对于核心系统代码审核、发布的流程，重要代码由放心的人来作，次要代码能全面监控（自查，互查，流程及代码review）；
3. 所有重要的玩家数据，其获取、流通、消耗的全过程，都应该有尽可能完整的留下日志记录，以便于当发生数据丢失时能帮玩家找回数据，不要偷懒；
4. 要建立能迅速根据core dump文件来定位当机原因的机制，不管是符号表编译、反汇编分析、日志分析、玩法重现中的哪一种，只要能越快定位原因就用哪一种，甚至可以多管齐下，多人并行定位。

新产品上市，是一场战役，很真实的战役，真实到，可以决定你这几年青春到底价值几何。

好吧，也希望能看到更多朋友聊一聊大家各自在新产品上市时所作的事，或者说一些趣事分享一下经验也挺好的。

	Lei Gu		更多选项 12月1日, 下午4时38分

  非常感谢。有个疑问，你们上线前没有一些checklist吗？我想应该有若干个checklist，基本就是包含你列的这些项，通过了，才允许上线运营。按说­你们已经有几款成功的产品了，有些经验应该固化成流程来搞。

	sodme 大宝		更多选项 12月1日, 下午4时47分

 

嗯，你说的很对，如果万事都能真正作到"按理说"，那就真的是万事大吉了，呵呵。

或者，这就是理想与现实之间的差距吧。

很多事，在当时，不是想不到，而是作不到。

  而作不到，又是因为没时间作，没经验作，没能力作等等各种各样的原因，总之，不管是哪样的原因，最终导致了很多本来应该作的事而没有作。可惜的是，我们总在每次的事后才想起有些事早应该作。但我们能把握得太少，不管你如何准备，总会存在一些需要在最短的时间之内需要最快速度解决的问题，呵呵，所以，闻且闻之，作且作之，而结果到底如何，就只能到时再应对了。

Hailong Shu

更多选项 12月1日, 下午4时50分

很好，很真实。

对于大规模的应用来说，常常会遇见很多稀奇古怪的问题。这种时候通过代码逻辑是难以分析出什么结论的。尤其是内存操作，对C或者C++不用内存池是难以做出一个­7×24的应用了。不能OS的资源回收机制想的很健全。

Lei Gu

更多选项 12月1日, 下午5时02分

总需要第一个总结分享的，重在有这个心，并且把这些事情记录下来了。
相信后来者会感谢你的

	Kasicass		更多选项 12月1日, 下午7时41分

:-) 大宝总结得已经很详细了。

个人的感受就是，游戏开发相对其他软件产品，需求变化还是太快了，对于一个团队应该如何形成自己的开发流程，只能靠团队内部的成员自己摸索并实践。
比如说要做 scrum，那晨会怎么开，聊些什么内容，这样的细节，也需要大家沟通、讨论后慢慢确定。否则生搬硬套其实无意义。

	jiang li		更多选项 12月2日, 下午11时52分

好文章，拜读了。

有几个问题。对服务器的各方面的监控一定会涉及到写日志的，对于一个多进程/线程的服务器，日志模块一般都是怎么设计的呢？是多个进程向同一个文件中写吗，这样­会不会造成性能上的损失？我之前用过log4cxx库，但不知道是否还有更好的解决方案？
还有，如果对系统的方方面面都进行监控，那么对于整体的性能大概会有多大的影响呢，会不会得不偿失啊？

sodme 大宝

更多选项 12月3日, 上午8时33分

我们是自己作的日志系统，作法是这样：

1. 使用日志队列管理所有待写日志，主逻辑线程将待写日志丢入队列，写日志文件的线程从队列取数据写入实际文件；

2. 不同类型的日志写入不同文件，比如物品系统、交易系统、任务系统等是写到不同文件，这样不仅可以控制文件大小而且也方便运营时的日志查询；

3. 日志文件的总量控制上，采用循环日志与非循环日志两种方式。循环日志是指开若干个同类型的日志文件，以编号作区别，比如
trace01.log~trace10.log，每个日志文件记录的行数相对固定，写满一个后再写后一个，写到第10个时再回头写第1个。记录很频
繁、量很大、非永久性的日志，可写入循环日志，比如性能追踪的相关日志等。非循环日志，是指需要长久保存的日志，比如玩家的交易记录等。

4. 严格控制非循环日志的总量，适时调整循环日志与非循环日志的内容，写的频率的非循环日志要看看能不能调整到循环日志中。我们的日志记录比较详细，
其输出量相对来说现在不算小，一周一个服会输出文本类的日志将近7G，我们只会保存最近两个月的相关日志，更远时间的日志视备份系统的硬盘大小决定适时
删除。也就是说，对于客服方面的运营问题，我们只提供最近2个月以内的行为记录确认服务。

5. 日志方面的性能，对于我们服务器性能方面的整体影响来说，不算很大，但也要看日志的输出频率，还是要控制好日志的输出频率和输出量，影响大小不是
首要的，首要的是要建立一套可伸缩的日志输出体系，可以让你适时调整相关的性能影响比例。

lin_style

更多选项 12月3日, 上午9时15分

您好。LZ是直接写文本吗？还是写数据库。还有个，日志为什么这里是用异步的？为了效率吗？但是在一些错误的日志跟踪上，用异步可能会影响你的判断

sodme 大宝

更多选项 12月3日, 上午9时22分

1. 写文本
2. 对于错误的日志跟踪，与异步不异步无关。重要的是，尽可能全的找到那些关键的数据，并将其记录下来。放到日志队列时，那些可以追踪的关键数据已被
记录，至于何时写到真正的日志文件并不重要。

 

 

zhihua che

更多选项 12月3日, 上午9时26分

我觉得LZ说的应该主线程将日志丢入日志线程，但日志线程是以先入先出的方式写，这样并不影响日志发生的时间顺序，这样对跟踪没什么影响吧？

 

 

sodme 大宝

更多选项 12月3日, 上午9时28分

对滴，正是这样。

 

lin_style

更多选项 12月3日, 上午9时31分

谢谢LZ回答。是我想多了，呵呵。

再请教个问题
“1. 服务器内存使用、回收的统计、分析机制，更详细的，
要统计到各类对象、各玩法、各系统的分别占用情况
”
1。这么健全的模块监视，用了多少时间开发呢？
2。服务器宕的时候，LZ是怎么快速定位到错误的？除了日志那边记录堆栈的信息，日志的一些关键数据，还有其他方法可以分享吗？

谢谢

		sodme 大宝	更多选项 12月3日, 上午9时43分

 

1. 我们前后经历三次不同规模的用户测试，两次全服的数据转档，一次全服的服务器合并。这些监控模块，基本上是在这些历次的大型事件中逐一添加的。如
果集中时间添加，我想基本的机制大概最多一两个月就可以完全搭完，更重要的是后期的持续跟进和调整。其实，关键的是，有了这套基本的机制之后，你的心里
就不会发虚了。

2. 定位服务器当机的方法，我们常用的是：使用gdb对core dump文件的反汇编、堆栈调用、寄存器及变量值的分析，当机前后的日志分析。前面
这些是精准分析，剩下的方法就是一些推测类的分析了，比如尝试故障现场的重现，查看最近的代码更新内容，了解来自于玩家的一些异常报告之类。还有最后一
招，不是所有人都能用得上，就是：直觉。它来自于长期产品运营的经验和直观感受，有时没啥特别的原因，就是偶然一个念头想到了可能是某部分的原因，于是
就会去求证，我想很多开发者也都经历过这样的情况。呵呵。

zhihua che

更多选项 12月3日, 上午9时53分

我是网络游戏开发的新手，想问个大的方向的问题。
你们现在服务器的是彻底从底层（我说的socket方面）自己建立网络IO模式，还是会使用一些框架，比如ACE，或者轻量的libevent之类。你们最常使­用的IO模式是怎么样的？

我们最喜欢用的是用异步socket，轮询响应玩家请求。不过这样有一个很明显的问题，我们经常在一个场景中有20个玩家左右进行频繁操作的话（比如PK)，会­明显出现卡的现象。

希望得到诸如IOCP模式等方面的指点。

	阿杜		更多选项 12月3日, 上午9时54分

很多东西是来自于执著和坚持的产物，这里面经验是一方面，态度是一方面。

 

 

sodme 大宝

更多选项 12月3日, 上午9时55分

我们是自建，平台是debian，用的是epoll.

 

zhihua che

更多选项 12月3日, 上午9时58分

我想在网络IO等性能方面有些进步，可以做点什么了？最近我在研究libevent，memchaced等库，不过一直没机会在实际项目中使用，希望能有帮助和­进步。

 

 

sodme 大宝

更多选项 12月3日, 上午10时10分

 

好一点的网络模型（比如IOCP,EPOLL），优势在大规模并发连接方面，并不在于单个连接的数据处理。如果你想在处理大规模并发方面有所提高，建议
还是选择这些已经成熟的网络通信模型。

网络模型的选型，还是要根据实际项目的网络架构、用户规模、逻辑数据的处理特点等来定，不是简单地说可以用这个，不可以用那个，这玩意没有什么绝对的概
念。事实上，在我们的产品中，网络层关于通信的性能是很小的一块，完全没有构成对整体性能的关键性影响。

网络上已有的框架可以参照，但要考虑到驾奴能力。基本上，我们产品对于开发模型的选择思路都是选择自建，这是根据我们的实际情况作出来的：
1. 我需要短时间内对这些内容作到完全可控，我认为再好的第三方库，也没有自己写的知根知底；
2. 方便以后对其进行灵活改造。

当然，这也并不就是所有新团队和新人都要选择的道路，看项目紧迫度、看团队成员的已有技术水平、看项目未来的用户规模等等。

[e-mail]

更多选项 12月3日, 下午12时00分

想仔细了解一下，是否有做端口或者进程级的流量监控？包括流量的大小，流向？

我们现在困恼没有好的办法对整个集群进行端口级、进程级的流量异动监控。

 

sodme 大宝

更多选项 12月3日, 下午12时09分

有，推荐一个工具：cacti

 

JoeCen

更多选项 12月3日, 下午3时03分

cacti是没有做端口或者进程级别的流量监控的。
如果要做估计要使用sniff之类的方法才能实现，用这些的话对系统的性能也会有耗损的，感觉意义也不大。进程级的做cpu和内存的监控就好。

 

sodme 大宝

更多选项 12月3日, 下午3时11分

呵呵，回答以joe的为准，joe是我们产品的sa，我们的cacti系统也是joe负责搭起来的。

cacti的总体监控，配上产品内置的细节监控，我认为总体上已经完全可以满足运营需求。

cacti提供了相对完善的外部扩展方法，如果想针对进程监控流量，只要形成流量日志即可，cacti可以将此日志再以图形化的方式表现出来。

Xu Yong

更多选项 12月4日, 上午1时03分

checklist的更新一般跟不上环境的变化，所以制度流程+技术经验都不可或缺。

	Xu Yong		更多选项 12月4日, 上午1时17分

推荐一下sflow和netflow的东东。

 

[e-mail]

更多选项 12月4日, 上午10时38分

 

的确。不过因为我们业务众多且数据中心分布很散，需要有全局的流量监控搭配个别业务的突发流量异动监控。在海量访问中筛选出这种异动流量，尽快定位问
题。是基础架构的平台产品。我试试看各位提供的工具。

 

 

[e-mail]

更多选项 12月4日, 上午11时05分

 

和相关TEAM了解了：
1、sflow受限于某些设备，在我们的环境中，无法全覆盖；
2、netflow能满足需求，大型集群网络中，条目太多，硬件条件不允许，并且只能在3层以上设备中才可使用，如果能在2层设备使用，就不存在问
题；
3、cacti已经在我们的网络流量监控上用了，但是无法满足我们对TCP端口、进程这种颗粒度的需求。

莫非只有DIY了？

非狐外传

更多选项 12月4日, 下午5时12分

怎么没有用syslog？比如syslog-ng，rsyslog等，有tcp连接，也有本机缓存。
感觉你们肯定考虑过，但后来排除了，是什么原因呢？