从知乎宕机说起，闲聊设计原则与优化方法

闲言碎语说几句，一点个人不成熟的看法，想哪写哪，没有逻辑

今天中午知乎又一次宕机，访问返回502错误，有网友提问：知乎作为一个问答内容管理系统，技术上有什么难点？为啥叕崩了？，看到之后我做了如下回答：

实际上如果仅仅是写答案，读答案的话还是不容易崩的，关键是这么大一公司，要寻找各种商业变现，然后就不断的给自己加功能，功能加的多了，崩也不可避免了

就像建房子，房子建好实际上是不容易倒塌的，你要今天给加个窗户，明天再加个阳台，后天觉得里边空间不合理再敲掉改改，倒掉的概率就大大增加了

随口的回答，有点戏谑，但这也是很多大型系统面临的现实。这也让我想到了我在系统设计过程中所遵循的原则

在系统设计时应尽量保持简单，简单并不是说要砍掉系统的某些功能，而是指在满足需求以及安全稳定的前提下，尽量避免一些复杂的设计，简单的设计有诸多好处

• 出活快，能让项目尽早上线
• 好排错，一旦出现问题排错更快
• 稳定性强，简单依赖少，出错的概率就低

在现在张口高并发，闭口大流量的当下，很多系统在设计时就被诸多概念所环绕，微服务，中台，Serverless，似乎不用上两个项目就没技术似的，然后996赶进度，待到上线之时也是BUG一大堆，用户还没几个，最大的好处怕是可以写上几张PPT，向上邀功KPI罢了，当然不否认，KPI也很重要

盖尔定律说：一个切实可行的复杂系统势必是从一个切实可行的简单系统发展而来的。从头开始设计的复杂系统根本不切实可行，无法修修补补让它切实可行。你必须由一个切实可行的简单系统重新开始。

这一点我是同意的，复杂的系统都是逐渐演变而来的，并非一开始就能够设计，不同的时间点，不同的用户量，我们面对的很多问题是不一样的，对系统稳定性的要求也会不一样。对于系统和架构，没有最好的，只有最合适的，这个合适从哪里来，就是随着项目的不断发展而逐渐演变而来的，所以好好做好当下的系统架构设计即可，遵循简单原则，快速迭代

对于一些中小型的网站该如何降低宕机概率，优化用户体验呢？除了常说的双机热备、高可用之外还有哪些事情能有帮助呢？

动静分离，页面不要使用动态渲染的方式，而采用静态页面+异步接口填充数据来处理，分离动态和静态资源处理服务器，给静态资源添加CDN。我们知道服务器对于静态资源的处理效率要比动态资源高很多，而用户进入网站大部分加载到的都是静态资源，这样不仅可以让我们分别针对两类资源做优化，更重要的是如果动态服务宕机，也不至于直接返回用户报错页面，而对于静态资源，单台nginx的处理能力都能达到数万并发，如果带宽管够，是不太会被打挂的

页面静态化，动静分离的方式面临着一个至关重要的问题，就是当动态服务宕机时，页面没有数据显示不完整，更进一步的优化是将静态页面+动态数据做整合直接生成纯静态的页面，实际上很多新闻网站就是这么做的，这样的话即便是动态服务宕机用户依然可以正常查看已经生成好的数据，只是例如回复、点赞之类动态交互功能无法使用了，体验可以得到进一步提升

动态服务也可以借助高性能的缓存来实现效率和稳定性的提升，优化是个复杂的系统工程，需要找出系统中的性能短板来针对处理，这也是著名的木桶原理

生产的系统往往复杂很多，尤其是像知乎这类的大型系统，多少工程师的无数个日日夜夜都奉献给了它，服务于亿万用户，创造了很大的价值。我们知道保证系统不宕机不太可能，但致力于提供稳定的服务，减少宕机的次数和时间理应作为一个重要指标受到所有工程师的重视

能看到这里一定是真爱，关注一下吧