产品经理需要了解的技术知识：后台宕机

产品的数据量一旦飞速的起来，宕机就变成了分分钟的事情。作为一个成熟而优秀的产品经理，你要做的就是先理解后台逻辑，在做产品规划的时候就考虑到一切可能的风险。本文讲述了后台宕机的原因、机制和解决之法，希望加深产品经理对后台宕机的理解，从而控制风险。

世界上最痛苦的事情不是产品流量没起来，而是流量上来了服务后台却挂了；世界上最痛苦的事情不是版本没有如期上线，而是上线后程序员被祭了天。

但凡一款爆发式增长的产品，几乎都在后台服务上折过腰，一般公司的操作方法：杀一个CTO祭天。但是，祭天有用吗？这事儿就真的和产品经理一点关系都没有吗？

今天丽莎阿姨就和你一起来聊聊后台服务的那些事儿。听完后，希望你能理解程序员小哥，与他在同一认知维度上思考，更关键的是也许你的一个小小举措就能拯救一条猿命啊。

俗话说得好，程序员有三难：

• 安卓：折叠、挖孔、齐刘海
• 苹果：证书、上架、热更新
• 前端开发：IE 六、七、八、九、十
• 后端开发：并发、写库、做运维

相比于其他，后端开发的最大难度就是需要在有限的资源上对海量的数据做高效地处理。

怎么理解这句话呢？

• 有限的资源：例如当前一个很厉害的 88 核/710GB 的后台服务器，其实也就是宇宙第一强手机 HUAWEI P40Pro（8 核/8G）的十倍左右。
• 海量的数据：就我们产品而言，随便挑一个数据库都已经有好几 T 的大小。
• 高效地处理：后台处理一慢，用户体验就变的很糟糕，丝毫不敢懈怠。

所以，产品的数据量一旦飞速的起来，宕机就变成了分分钟的事情。

一个正常的猿外人，首先的思考就是：为啥不扩容？不就是钱能解决问题的吗？

一、扩容能解决宕机的问题吗？

1. 不是所有的资源都能简单的扩容

12306 网站够有钱吧，但是上线当初就是疯狂的崩啊，所以花钱并不能直接解决问题。那么为啥不能简单横向扩容呢？

原因很简单：如果系统用到了一些有单点限制的资源，那其他系统再怎么扩容也没用。哪些是常见的单点资源呢？一般是数据库、缓存、核心依赖的第三方服务等等。

2. 你永远不知道宕机和出轨哪一个先来

如上图所示，随着用户量的增长服务器的费用也会水涨船高，但是用户量的增长很多时候要听天命。就像微博的突发事件，事情来了用户暴涨XXXX万，事情过后一片唏嘘。

不扩容不是人，扩完容人散了，你就是猪。所以，对于产品经理们来说，能够非常精准的预测到即将到来的流量就变的尤为重要。数据监控，模型推演，历史事件对比分析都是非常有效的方式。

这个时候，猿外人估计也会想到，为什么程序猿不进行动态的缩扩容呢？

丽莎阿姨举一个非常形象的例子：把后台服务当做一个奶茶店，假设一个营业员小哥正常 1 分钟处理一个用户，以下是可能会遇到的一些情况：

• 特殊工艺的奶茶：制作工艺非常复杂，做一杯要 5min，那这个营业员这 5 分钟暂时不能接客；
• 水龙头流的很慢：每次接杯水都要好久，处理一个用户的时间自然要变得很长；
• 还有一批混混：不知道被谁雇佣过来的，过来排队但又不买；

这些问题，都是后台开发的过程中会遇到的实际问题，要处理起来每一个都非常棘手，并非雇佣和解雇几个小哥就能解决的。

二、后台服务为什么会挂？

常见的原因有两个：

• 单点系统可能会挂或者处理能力有限，典型：数据库、Redis 缓存(10W qps)
• 第三方依赖可能会故障，包括核心依赖、非核心依赖

后台程序员怎么做能让服务能更稳一点？

1. 拆

拆是一个种常见的方法，常见的会根据伸缩立方和微服务做下面这些拆分。

水平拆分

这种方式比较常见，可以认为是简单的水平扩容，简单来说就是一台不行，多跑一台扛着。

功能性拆分

这种方案是根据功能模块的不同，进行拆分后台服务，不把鸡蛋放在一个篮子里。如果有一个服务故障，不影响其它服务的运行。

数据拆分

前面有提到，数据库经常会成为单点的瓶颈。一般在功能性拆分的同时，我们也会做数据的拆分，不让一份数据变得超级大。

2. 寻找更强的单点

如果单点暂时有瓶颈，那可以考虑：是不是有功能一样，但是性能更强的单点可以替代呢？

常见的方式是换组件，自己的不行换云服务的，单机版不行换集群版本。

比如对于数据库，阿里云上的 PolarDb 号称比传统 MySQL 性能提升 6 倍左右。

3. 牺牲时效性

既然数据库写的单点很难解决，就从读取上想办法。这就像，老板太忙，就请一个秘书，虽然消息传递有一些时延差，但是可以分担老板的精力，一个秘书忙不过来还可以再多请几个。

如下图，一个家校沟通的产品，老师发布作业这个场景就可以牺牲掉一部分的时效性。

4. 让单个请求处理更快

慢请求是后台永远的噩梦，一旦有大量请求处理很慢，就非常危险了，所以要程序员小哥在开发的过程中，经常做重构、优化、做架构演进，目的就是让请求处理得更快。

5. 提前计算好，不要等用户来的时候再计算

对于一个业务来说，会存在一些数据统计相关的服务，如果按照来一个用户计算一次的方式，服务的质量和数据库的压力都会非常大。

最好的方式就是在凌晨时把能计算的数据都计算好，等用户来的时候，数据已经 ready，一个简单的读取就可以拿到他要的结果。

但是，如果这些都做了，服务还是要崩，我们能怎么办？

三、终极大招：有损服务与降级

我们在产品设计和后台开发的时候，需要清楚你的系统「强依赖」和「弱依赖」是什么。

• 用户没感觉是弱依赖
• 用户有感觉是强依赖

有了上面这些概念以后，就可以来做一些对应的设计：

• 牺牲用户体验：用静态化数据代替「千人千面」的动态数据；放缓流量进入的速率，增加验证码机制；简单粗暴的，直接挂一个页面显示「XX 功能在 XX 时间内暂时关闭」
• 牺牲功能完整性：有一些功能是「防御性」的，如果愿意冒险“裸奔”一段时间也会带来可观的资源节约；临时关闭「风控」；取消部分「条件是否满足」的判断
• 牺牲时效性：将一些原本就是异步进行的操作，处理效率放缓，甚至暂缓一段时间。如，送积分、送券等等

每个产品的后台开发都是一个非常复杂的系统工程。服务器挂了，拿程序员祭天是一点作用都没有的。

作为一个成熟而优秀的产品经理，你要做的就是先理解后台逻辑，在做产品规划的时候就考虑到一切可能的风险。然后，就算是后台挂了，也能从上文中提到的思路与后台小哥一起来思考解决问题。

做后台很苦，请善待搬砖民工。文中的后台相关技术术语如果有描述错误的之处，还请各位在评论区指出斧正，感谢。

作者：Lisa Deng；微信公众号：丽莎D的产品手记

本文由 @Lisa Deng 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议