简单地说，后台开发涉及的层面主要包括网络、数据、业务逻辑、运维4个方面，如果扩展和延伸的话：

网络-分布式系统-并行计算

业务逻辑-WEB-游戏-交易-搜索

数据-CACHE-DB-KeyValue-文件存储服务

运维-负载均衡-容错-容灾-运维工具

不同类型的业务对以上4点的要求是不同的

简单总结了一下公司已有服务器的一些偏重点

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

 

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

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

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

本周《大航海时代5》正式运营，也许是得益于多个游戏论坛的玩家们孜孜不倦的“口水炮”，18日正式开始在日本测试的《大航海》到了第二天就光荣地化身泰坦尼克号，由于各种bug和服务器问题，直接停服当机。

这么些年以来，已经见过了太多象《 大航海时代Ⅴ》一样的烈士，并且相信，这绝不是最后一个因为服务器倒下的游戏。

当然腾讯的同学会感觉奇怪，就一个比较简单的页游，在日本公测，最多同时在线1万人。就会把服务器给搞垮？接入用个LVS负载均衡，业务逻辑用java/php/fastcgi，中间加一个MemDB或是Redis，不就搞定？个中缘由，只有问项目团队了。我想，由于《大航海时代》，原来是单机程序，没有服务器相关经验，对于可靠性的重视程度不足，可能是游戏服务器失败的一个重要原因。

作为一个程序员而言，往往会有性能情结，总是希望用最少的服务器来支持更多的人数。这里不是说性能不重要，而是要根据不同的场合去区分。例如：逆战的游戏服务器，如果不考虑性能问题，那么一台C1服务器就只能支撑200-300人，甚至对于复杂的PVE模式来说，就只能支持不到100人，单单服务器成本就会把项目拖垮；对于御龙在天来说，如果不解决千人同屏时的系统广播压力，和竞争对手相比的一个重要卖点就完全丧失。对于某些预期压力不大，或者可以通过简单扩容来解决的问题，在初期时就不应该去死抠服务器的一点点性能，应该精力放到稳定性和可扩展性上，等有需要的时候再来解决性能问题。而对于关系到系统基础和核心体验的性能问题，那它的优先级就是第一位的。当然，也可能存在某个服务，随着用户喜好或业务发展，从不起眼变得十分重要。这时，它的性能和稳定性都会变得十分重要。

公司的海量数据的系列课程中，有个比较著名的短语：“先抗住，再优化”，也表达了类似的意思。先要保证系统稳定可用，否则，初期用户就已经流失了，后面就再也没有优化的机会了。当然，如果我们在设计之初，就把系统的关键路径的稳定性考虑地比较充分；那么随着业务的逐步发展，优化将是有序和可控的。

服务器还面临着在特定时间内的特定活动，用户访问数量增加，引起雪崩的问题。从前些年的短信拜年，到双12大促，12306抢票，春节的微信红包等活动。短短时间内的访问峰值是平时的100倍甚至上千倍。一旦并发数量上去后，平时系统中所隐含的错误、考虑不周和极限情况等，通通都会冒出来。我甚至还遇到过在冲线的关键时刻，有台比较重要的服务器宕机的事件。

服务器的业绩有很重要的一部分是在峰值期间能够提供正常服务。所有我们很多时候的工作就是为了那几个小时的“巅峰时刻”。

 

众所周知的原因，国内大学的计算机教育是比较失败的。多数毕业的研究生同学，所写的代码行数不超过1w行，并且其中还有不少是CTRL_C,CTRL_V。因此从研究生毕业后到工作单位的开始的工作是在补课，例如C/C++的开发和调试，脚本语音的学习，linux操作系统的熟悉，简单DB的操作与分析、补充硬件相关知识等。工作的重点也主要是数据统计、运维脚本的编写、小功能小需求的开发。一切顺利的话，基本能承担一个独立模块的开发，两年已经过去了。

大概做个一年的独立模块开发，经历过基本架构设计、和策划讨价还价、上线的不稳定、用户访问突然增长、服务器宕机、配置文件错误等的磨练后，终于对在线系统的开发有了比较深的认识。这时候，大概可以升级到公司的T2.3-T3.1。经过最少3年的努力，后台开发可以入门了。后期就需要通过时间和项目进行逐步的积累。

服务器的经验累积，包括想法，架构和代码设计都需要通过实际的验证才能获得证明。线上的情况总是会出乎我们的意料。往往考虑很周详的方案落了空；而用户总是在意想不到的地方出招。俗话说，没吃过猪肉，总见过猪跑吧。但后台的积累需要我们去吃猪肉，而不是仅仅看看猪跑。

机遇也是另一重要的因素，如果用户PCU就一直徘徊在10，20万，那就一直不会有100w在线的经验。在用户数逐步增长的过程中，会出现各种各样的问题，逐个去解决问题的过程，就是经验逐步积累和升华的过程。当然，业务能够发展的到什么程度，这个就需要看大家的选择和运气了。

 

一般来说，作为一个后台程序员在初期的时候往往会对网络、业务逻辑和数据这三部分比较关心。运维嘛，反正有运维的同时，网络、机器和配置等事情，他们来搞定吧。如果抱着这样想法的同学，那就等着不停在在半夜2，3点被宕机电话骚扰；在陪家人的时候，被召回公司加班；程序配错，各种指责降临；绩效考核时，程序不稳定，年终奖不佳…

大家在写代码的时候，有没有考虑过下面的问题：

• 我写的服务运行得正常吗？怎么样才能知道它是正常的？
• 如果运行的服务器宕机了，服务怎么样才能继续？
• 如果网络不通了，有没有备份的链路？
• 策划如果把配置表填错改怎么办？
• 机器太多，不小心又把对应关系配错。
• 运维的同学把电信的服务器配成了联通的IP，外网玩家投诉卡。

除了配置IP的问题外，其余的问题，运维的同学基本都不能帮你搞定。很多事情都有自己考虑和解决。显然，救世主不存在，系统稳定性的责任主要在项目开发组上。

 

前面零零碎碎讲着这么多，其实最终还是要落到一点上：主动。

程序功能完成，仅仅只是后台开发20%的工作。后台的同学还应该主动关心自己的程序实际运行的情况怎么样，日志有没有报异常，是不是有瓶颈和处理不周到的地方；密切注意硬件和网络异常时，自己程序的表现；在策划提出新功能时，是否对现有程序有影响，是不是需要预先做一些微重构；出现错误时，不仅仅是解决问题，还应考虑怎么避免下次再犯类似的错误。

这些点点滴滴的积累，不是一蹴而就的，也不是领导对你的要求。而是需要在工作的过程中不断地总结和改进，甚至有些时候要一点“自虐”的精神。