【入门】后台开发程序员的进阶之路
1、后台开发涉及的范围
简单来说，后台开发主要涉及网络、数据、业务逻辑和运维四个层面。若进一步扩展，具体内容如下：
- 网络：涵盖分布式系统与并行计算。
- 业务逻辑：包含 WEB、游戏、交易、搜索等领域。
- 数据：涉及 CACHE、DB、KeyValue 以及文件存储服务。
- 运维：包括负载均衡、容错、容灾以及运维工具。
不同类型的业务对上述四个方面的要求存在差异。这里简单总结了公司已有服务器的一些侧重点。实际上，每个成功的业务服务器都有其独特特点。优秀的程序员或设计师能够依据不同的业务特点，选择合适的架构、人力和资源，将精力投入到业务最核心、最关键的功能点或模块上。
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、后台开发需要长期积累
由于国内大学计算机教育存在一定不足，多数毕业的研究生同学所写代码行数不超过 1 万行，且其中不少是通过复制粘贴完成的。因此，研究生毕业后进入工作单位，初期主要是进行知识和技能的补充，包括 C/C++ 的开发和调试、脚本语言的学习、Linux 操作系统的熟悉、简单数据库的操作与分析以及补充硬件相关知识等。工作重点集中在数据统计、运维脚本编写以及小功能、小需求的开发。顺利的话，大约两年时间才能基本承担一个独立模块的开发工作。
在进行大约一年的独立模块开发后，经历过基本架构设计、与策划沟通协调、上线不稳定、用户访问量突然增长、服务器宕机以及配置文件错误等情况的磨练，才能对在线系统开发有较深入的认识，此时大概可以晋升到公司的 T2.3 - T3.1 级别。经过至少 3 年的努力，才有可能真正入门后台开发。此后，还需要通过时间和项目不断积累经验。
服务器开发的经验积累，包括想法、架构和代码设计等方面，都需要通过实际验证才能得到有效提升。线上情况往往超出我们的预期，精心考虑的方案可能无法达到预期效果，用户也可能会在意想不到的地方提出问题。俗话说“没吃过猪肉，总见过猪跑”，但后台开发的经验积累需要我们亲身体验，而不仅仅是旁观。
机遇也是重要因素之一，如果用户 PCU 一直维持在 10 - 20 万，就很难获得 100 万在线的经验。在用户数量逐步增长的过程中，会出现各种问题，解决这些问题的过程就是经验积累和升华的过程。当然，业务能够发展到何种程度，既取决于个人选择，也有一定的运气成分。
4、不能忽视运维
一般来说，后台程序员初期往往更关注网络、业务逻辑和数据这三个方面，认为运维工作有专门的运维人员负责。然而，如果抱着这种想法，可能会面临诸多问题，如半夜被宕机电话骚扰、陪家人时被召回公司加班、因程序配置错误受到指责以及绩效考核不佳等。
在编写代码时，我们应该考虑以下问题：
- 我编写的服务是否正常运行？如何判断其运行状态是否正常？
- 如果运行的服务器宕机，服务如何继续提供？
- 如果网络不通，是否有备份链路？
- 如果策划填错配置表，该如何处理？
- 机器数量众多，如何避免配置对应关系出错？
- 若运维人员将电信服务器配置为联通 IP，导致外网玩家投诉卡顿，该如何解决？
除了配置 IP 的问题外，其他问题运维人员基本无法完全解决，很多事情需要开发者自己思考和解决。显然，系统稳定性的主要责任在于项目开发组。
5、主动精神是唯一的法宝
前面所述的诸多内容，最终都归结为一个核心要点：主动。
完成程序功能仅仅是后台开发工作的 20%。后台开发者还应主动关注程序的实际运行情况，检查日志是否有异常，是否存在瓶颈和处理不当的地方；密切留意硬件和网络异常时程序的表现；当策划提出新功能时，评估其对现有程序的影响，考虑是否需要进行预先微重构；出现错误时，不仅要解决问题，还应思考如何避免类似错误再次发生。
这些经验的积累并非一蹴而就，也不是领导的硬性要求，而是需要在工作过程中不断总结和改进，甚至需要有一定的“自虐”精神。