1、后台开发涉及的范围

 

简单地说,后台开发涉及的层面主要包括网络、数据、业务逻辑、运维4个方面,如果扩展和延伸的话:
网络-分布式系统-并行计算
业务逻辑-WEB-游戏-交易-搜索
数据-CACHE-DB-KeyValue-文件存储服务
运维-负载均衡-容错-容灾-运维工具
不同类型的业务对以上4点的要求是不同的
简单总结了一下公司已有服务器的一些偏重点

 

 

应该说每个成功的业务服务器,都有各种的特点,高明的程序员或设计师,能够根据不同的业务特点,选择合适的架构、人力和资源,投入到自己业务最核心和最关键的功能点或模块上。

 

2、后台开发的特点
 
A.后台开发相对稳定
我们知道,在用户界面和表现这一块,变化是非常快的。用户总是喜欢新鲜的,更好的表现。各大公司在这块的竞争也非常多,总想把用户捆绑到自己的平台上来。各种第三方的组件、引擎都层出不穷。例如微软就不停地发布各种API和各种开发语言。苹果兴起后,直接把一个不出名的Objective-C提升到了排行榜的第三名。

 

 

由于后台开发基本不涉及表现层,主要处理的是网络、数据和消息等。受“流行”和“时尚”的冲击比较小。无论是windows也好,MAC也好,IOS、Android,对后台架构的影响都不大。开发语言也比较稳定,主流的就是C/C++。

 

B.稳定性是首要保证的
后台服务程序是为多人同时在线服务的,因此对其可靠性的要求特别高。相对客户端程序而言,如果一个进程或一台机器倒掉,客户端仅仅影响的是一个用户的体验;而对于服务器来说,就有可能是上千人的体验,甚至是如果不幸地是关键节点出现问题,将是整个服务的不可用。游戏界因为服务器的原因失败的例子实在太多。最近一个悲壮的例子是《大航海时代Ⅴ》

 

 

本周《大航海时代5》正式运营,也许是得益于多个游戏论坛的玩家们孜孜不倦的“口水炮”,18日正式开始在日本测试的《大航海》到了第二天就光荣地化身泰坦尼克号,由于各种bug和服务器问题,直接停服当机。
这么些年以来,已经见过了太多象《 大航海时代Ⅴ》一样的烈士,并且相信,这绝不是最后一个因为服务器倒下的游戏。
当然腾讯的同学会感觉奇怪,就一个比较简单的页游,在日本公测,最多同时在线1万人。就会把服务器给搞垮?接入用个LVS负载均衡,业务逻辑用java/php/fastcgi,中间加一个MemDB或是Redis,不就搞定?个中缘由,只有问项目团队了。我想,由于《大航海时代》,原来是单机程序,没有服务器相关经验,对于可靠性的重视程度不足,可能是游戏服务器失败的一个重要原因。
作为一个程序员而言,往往会有性能情结,总是希望用最少的服务器来支持更多的人数。这里不是说性能不重要,而是要根据不同的场合去区分。例如:逆战的游戏服务器,如果不考虑性能问题,那么一台C1服务器就只能支撑200-300人,甚至对于复杂的PVE模式来说,就只能支持不到100人,单单服务器成本就会把项目拖垮;对于御龙在天来说,如果不解决千人同屏时的系统广播压力,和竞争对手相比的一个重要卖点就完全丧失。对于某些预期压力不大,或者可以通过简单扩容来解决的问题,在初期时就不应该去死抠服务器的一点点性能,应该精力放到稳定性和可扩展性上,等有需要的时候再来解决性能问题。而对于关系到系统基础和核心体验的性能问题,那它的优先级就是第一位的。当然,也可能存在某个服务,随着用户喜好或业务发展,从不起眼变得十分重要。这时,它的性能和稳定性都会变得十分重要。
公司的海量数据的系列课程中,有个比较著名的短语:“先抗住,再优化”,也表达了类似的意思。先要保证系统稳定可用,否则,初期用户就已经流失了,后面就再也没有优化的机会了。当然,如果我们在设计之初,就把系统的关键路径的稳定性考虑地比较充分;那么随着业务的逐步发展,优化将是有序和可控的。

 

C.突发事件的冲击
服务器还面临着在特定时间内的特定活动,用户访问数量增加,引起雪崩的问题。从前些年的短信拜年,到双12大促,12306抢票,春节的微信红包等活动。短短时间内的访问峰值是平时的100倍甚至上千倍。一旦并发数量上去后,平时系统中所隐含的错误、考虑不周和极限情况等,通通都会冒出来。我甚至还遇到过在冲线的关键时刻,有台比较重要的服务器宕机的事件。
服务器的业绩有很重要的一部分是在峰值期间能够提供正常服务。所有我们很多时候的工作就是为了那几个小时的“巅峰时刻”。

 

3、 后台开发需要长期积累
 
众所周知的原因,国内大学的计算机教育是比较失败的。多数毕业的研究生同学,所写的代码行数不超过1w行,并且其中还有不少是CTRL_C,CTRL_V。因此从研究生毕业后到工作单位的开始的工作是在补课,例如C/C++的开发和调试,脚本语音的学习,linux操作系统的熟悉,简单DB的操作与分析、补充硬件相关知识等。工作的重点也主要是数据统计、运维脚本的编写、小功能小需求的开发。一切顺利的话,基本能承担一个独立模块的开发,两年已经过去了。
大概做个一年的独立模块开发,经历过基本架构设计、和策划讨价还价、上线的不稳定、用户访问突然增长、服务器宕机、配置文件错误等的磨练后,终于对在线系统的开发有了比较深的认识。这时候,大概可以升级到公司的T2.3-T3.1。经过最少3年的努力,后台开发可以入门了。后期就需要通过时间和项目进行逐步的积累。
服务器的经验累积,包括想法,架构和代码设计都需要通过实际的验证才能获得证明。线上的情况总是会出乎我们的意料。往往考虑很周详的方案落了空;而用户总是在意想不到的地方出招。俗话说,没吃过猪肉,总见过猪跑吧。但后台的积累需要我们去吃猪肉,而不是仅仅看看猪跑。
机遇也是另一重要的因素,如果用户PCU就一直徘徊在10,20万,那就一直不会有100w在线的经验。在用户数逐步增长的过程中,会出现各种各样的问题,逐个去解决问题的过程,就是经验逐步积累和升华的过程。当然,业务能够发展的到什么程度,这个就需要看大家的选择和运气了。

 

4、不能忽视运维
 
一般来说,作为一个后台程序员在初期的时候往往会对网络、业务逻辑和数据这三部分比较关心。运维嘛,反正有运维的同时,网络、机器和配置等事情,他们来搞定吧。如果抱着这样想法的同学,那就等着不停在在半夜2,3点被宕机电话骚扰;在陪家人的时候,被召回公司加班;程序配错,各种指责降临;绩效考核时,程序不稳定,年终奖不佳…
大家在写代码的时候,有没有考虑过下面的问题:
  • 我写的服务运行得正常吗?怎么样才能知道它是正常的?
  • 如果运行的服务器宕机了,服务怎么样才能继续?
  • 如果网络不通了,有没有备份的链路?
  • 策划如果把配置表填错改怎么办?
  • 机器太多,不小心又把对应关系配错。
  • 运维的同学把电信的服务器配成了联通的IP,外网玩家投诉卡。
除了配置IP的问题外,其余的问题,运维的同学基本都不能帮你搞定。很多事情都有自己考虑和解决。显然,救世主不存在,系统稳定性的责任主要在项目开发组上。

 

5、 主动精神是唯一的法宝
 
前面零零碎碎讲着这么多,其实最终还是要落到一点上:主动。
程序功能完成,仅仅只是后台开发20%的工作。后台的同学还应该主动关心自己的程序实际运行的情况怎么样,日志有没有报异常,是不是有瓶颈和处理不周到的地方;密切注意硬件和网络异常时,自己程序的表现;在策划提出新功能时,是否对现有程序有影响,是不是需要预先做一些微重构;出现错误时,不仅仅是解决问题,还应考虑怎么避免下次再犯类似的错误。
这些点点滴滴的积累,不是一蹴而就的,也不是领导对你的要求。而是需要在工作的过程中不断地总结和改进,甚至有些时候要一点“自虐”的精神。