单点系统可能会挂或者处理能力有限，典型：数据库、Redis 缓存(10W qps)

第三方依赖可能会故障，包括核心依赖、非核心依赖

后台程序员怎么做能让服务能更稳一点？法宝 1：拆拆是一个种常见的方法，常见的会根据伸缩立方和微服务做下面这些拆分。

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

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

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

法宝 2：寻找更强的单点如果单点暂时有瓶颈，那可以考虑：是不是有功能一样，但是性能更强的单点可以替代呢？常见的方式是换组件，自己的不行换云服务的，单机版不行换集群版本。比如对于数据库，阿里云上的 PolarDb 号称比传统 MySQL 性能提升 6 倍左右，如下所示。
法宝 3：牺牲时效性既然数据库写的单点很难解决，就从读取上想办法。这就像，老板太忙，就请一个秘书，虽然消息传递有一些时延差，但是可以分担老板的精力，一个秘书忙不过来还可以再多请几个。如下图，一个家校沟通的产品，老师发布作业这个场景就可以牺牲掉一部分的时效性。法宝 4：让单个请求处理更快慢请求是后台永远的噩梦，一旦有大量请求处理很慢，就非常危险了，所以要程序员小哥在开发的过程中，经常做重构、优化、做架构演进，目的就是让请求处理得更快。法宝 5：提前计算好，不要等用户来的时候再计算对于一个业务来说，会存在一些数据统计相关的服务，如果按照来一个用户计算一次的方式，服务的质量和数据库的压力都会非常大。最好的方式就是在凌晨时把能计算的数据都计算好，等用户来的时候，数据已经 ready，一个简单的读取就可以拿到他要的结果。
但是，如果这些都做了，服务还是要崩，我们能怎么办？
3终极大招：有损服务与降级
下面引用阿里的同学在 QCON 大会分享的一份 PPT 为例：
我们在产品设计和后台开发的时候，需要清楚你的系统「强依赖」和「弱依赖」是什么。