Web应用架构演进及系统性能、稳定性所需要解决的问题

最新推荐文章于 2021-04-23 15:46:32 发布

原创

最新推荐文章于 2021-04-23 15:46:32 发布 · 置顶 · 9.3k 阅读

7 ·

CC 4.0 BY-SA版权

文章标签：

#web应用 #架构 #性能 #稳定性

本文探讨了Web应用从项目初期到大规模访问量下的架构演进，包括服务化、系统性能提升、稳定性保障和多机房容灾策略。随着业务扩展，系统经历了从单体到拆分，从单库到分库分表，以及引入索引库。为了应对高并发，采取了异步处理、内存管理优化等手段。同时，通过异地多活、服务降级和熔断等策略保证系统稳定性。此外，文中还强调了SLA的重要性以及系统监控在保障服务稳定性中的作用。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

Web应用架构演进

项目起步阶段

在项目起步阶段，系统访问量不大，业务比较单一，且需求紧，需要快速上线，这个时候一般瀑布式开发，单系统、单库、单缓存集群。
业务范围扩大，根据业务边界拆分

在业务范围扩大过程中，单系统会逐渐变得臃肿庞杂，业务耦合越来越严重，改动小可能影响会很大，有时候可能因为一处细小的错误导致全站宕机。
当前阶段最直接的办法就是根据业务边界进行拆分，每个业务模块由专门的开发人员进行维护，做到专而精。
访问量级增大，系统性能考虑提上日程

在系统的访问量级变大之后，对于系统性能方面考虑就要提上日程了，以前可能单库就搞定的事情现在需要分库分表了，以前把量全部往数据库打都不要紧的现在需要考虑哪些数据需要做预热了，以前很多的非核心逻辑在主流程同步执行的需要考虑异步去执行了。而且在访问量这么大的条件下，对于系统的稳定性要求会更高，以前挂1分钟可能都没请求进来，现在挂1分钟可能是上百万请求异常。
该系统中由于存在需要根据多字段去检索信息，所以会有一个索引库的概念，通过在索引库去查询信息所在分库，但是这种模型对于读能力是可以水平扩展的，而写能力则是有单点瓶颈，有待优化。
多机房容灾
上一步完成之后，对于单机房的可用性已经有一定的保障，要做到服务的持续可用，还得继续发展做网络分区，保证一个网络分区下的整个集群全部挂掉，另外的网络分区也可继续提供服务。
在介绍网络分区之前，先来介绍下CAP定理，在分布式系统中，不可能同时满足三点，C，consistence数据一致性，A，availability高可用性，P，partition tolerance容忍网络分区；如果有了网络分区，要么选择不同分区都可以写数据，丧失部分数据一致性能力，通过最终一致性保证不同分区下数据一致；要么选择只有一个分区在写数据，丧失写的高可用。
先来看看国内使用较多的模式，两地三中心，同城两个机房可同时提供服务，写数据可一个机房写也可以两个机房都写再同步，异地机房做冷备，一般来说同城机房之间50公里的光纤距离，数据同步延时在1~2ms，是一个可接受的范围，而异地机房同步延时可能超过100ms；选择这种方式整体来说就会简单一些。

一个异地机房就这么一直处于空闲状态总觉得代价挺大的，完全部署了一套却长期派不上用场，而且一旦主机房出问题了，冷备机房长期未使用，对于这个机房是否能完全接管下来还是个未