老后台的碎碎念（一）-后台心得

背景

偶发感想，整理下做后台开发这么多年以来的心得体会，帮助读者学习进阶。

看菜下碟-聚焦业务核心模块

一般来讲，后台开发过程就那几个方面：

• 网络协议
• 数据
• 业务逻辑

不同的业务在这三个方面的侧重不同，有的业务逻辑比较复杂，例如对战游戏，可能涉及到智能寻路、碰撞检测；有的侧重网络传播，广播、单播等等，例如微信、QQ，直播也算；有的侧重数据，例如网盘。

我们要分析当前业务属于哪种类型，侧重什么，什么是它技术上的核心。

这样才好合理设计系统架构、分配人力资源等等。

可用性优先级最高

后台和客户端不同，客户端出了闪退bug，一般情况下只会影响用户自己一个人（特指bug路径比较深的场景，路径比较短、比较常用也会影响很多人），但是后台一出故障，那影响面积可就太大了，搞不好还得通告，年终奖告吹。

所以一定要注重服务稳定性的建设，保证高可用，出了bug不要紧，重要的是你不能宕机，一宕机什么功能都用不了，用户体验非常差，损失非常大。

在开发过程和上线后，要特别注意容灾、容错，在写代码期间就要考虑，我这块故障了怎么办？回滚能不能解决问题（有的回滚也解决不了问题)？有没有流水记录？能不能修复数据？

性能反而是次要的

程序员都有性能情结，我表示理解，毕竟我也有，想想自己的服务响应巨快、吞吐率巨高，非常有成成就感，仿佛自己是大佬一般。

但是性能其实一般在前期都不是问题，或者说不是主要矛盾，主要矛盾是快速迭代快速上线，保证活下来。性能？怼机器就行了。

能用钱解决的问题都不是问题。

有一种情况需要优化：关键路径上性能有问题。

例如大型直播间，号称支持万人直播间，实际上直播间一百人性能就有问题了，那肯定不行。这种情况就要及时优化。

先抗住再优化，有序地优化。

做好拓展性应对突发流量

这里说的拓展性不是指业务功能上的可拓展性，而是特指架构上的服务可拓展性，简单来说就是加机器的拓展性。

突发流量来了，服务压力很大，怎么办？

优化代码？晚了！

必须立刻马上扩容，该扩数据库就扩数据库，该加机器就加机器。

哦豁，这时候你发现你的服务是有状态的，横向扩容加机器非常复杂，甚至做不到，救不了火。

等亖吧！

积累

很多知识和复盘你不是没有学习过，你只是不深刻，知识看过了也就看过了，复盘看过了也就看过了，远不如自己踩坑来的深刻，也很可悲，明明前人已经踩过了，输出复盘了，同样的错误还是会犯。

所以说经验这个东西说简单也简单，给你纸笔让你写，能写满几张A4纸呢。说难也难，主要还是深刻，经历的多，不慌，能想起来应对步骤。

机遇

一条SQL、一个技术方案，运行在只有1万用户的业务上和有上亿的业务上，效果是完全不同的。

高流量高并发能快速提升你设计大型系统的能力，这是你在小公司小业务上体验不到的。

理论需要与实践相结合。

主动思考

写完代码服务上线，只是开发的一小部分。

更多的是站在全链路视角下去思考，系统的瓶颈在哪里，监控是否到位，如何提前预警，如何提升代码质量，如何提升系统稳定性。

以及如何提高自己的效率，做一个十倍工程师。

以上。