写点什么

系统架构:学习小结

发布于: 2020 年 07 月 02 日
系统架构:学习小结

课程回顾

这周的课程,老师介绍了一个大型的典型的互联网应用架构的演化,同时分享了淘宝、微博和宅米网的架构演化案例。

初始阶段:最简单的互联网应用架构

优点

快速开发,部署简单,一般用于业务试验阶段。

缺点

单台服务器的性能和容量有限,可用性很差,单机宕机服务即不可用。

阶段一:应用与数据分离

优点

资源充足,性能有所提升。

缺点

  1. 可用性不好,服务没有冗余

  2. 用户量增加,数据库访有问压力



阶段二:使用缓存改善性能

优点

引入缓存,缓解数据库压力,提升了系统性能和容量。

缺点

  1. 可用性不好,服务没有冗余

  2. 单台应用服务器处理能力有限,会造成瓶颈



阶段三:使用应用服务集群来改善系统的并发能力

优点

应用服务做集群部署,增加了系统容量,提升了系统可用性。

缺点

  1. session如何在各个应用之间同步,需要做额外的开发,一般可以使用JWT + redis来处理

  2. 增加系统容量后,随着用户的增加,数据库的处理能力又会到达瓶颈

阶段四:数据库读写分离

优点

读写分离主从DB模式,缓解了单台数据服务的访问压力。

缺点

  1. 从主复制有延迟,业务需要做特殊处理

  2. 静态资源加载慢

阶段五:使用反向代理和CDN加速网站响应

优点

增加了反向代理和CDN,加速了静态资源的访问,其实也是缓存,将资源放到了离用户最近的地方。

缺点

  1. 随着用户的增加,应用服务器可以水平扩展,增加容量,单实例的数据库写入操作将会成为瓶颈

阶段六:使用分布式文件系统和分布式数据库系统

优点

扩展数据库系统,缓解访问压力和存储压力。

缺点

  1. 分库分表能缓解压力,提升数据库系统的容量和性能,但会出现事务、join等操作的复杂度

  2. 虽然缓解压力,但是大量的访问还是存在的

阶段七:使用NOSQL和搜索引擎

优点

增加了存储引擎和Nosql服务器,进一步缓解了数据库的访问压力。

缺点

  1. 业务服务本身的臃肿,阻碍了开发部署的效率,可扩展性成了下一步演化的关键问题

阶段八:业务拆分

优点

将臃肿的业务拆分成各自独立的服务,可以独立开发和部署,同时也可以优化服务器资源,增加热点服务的机器资源,减少边缘服务的资源。

缺点

  1. 拆分后的业务功能逐步增加,变得重新臃肿

阶段九:微服务和中台化

优点

将服务拆分的足够小,每个服务有各自独立的数据库服务,做到真正的各个服务完全独立。中台化复用了各个服务的功能,进一步提升了系统的可扩展性。

缺点

做到这个地步,问题还是会有的,只是具体问题就得具体分析了。

阶段十:大数据 + BI

总结

综上所述:我有以下几点感想。

  1. 瓶颈出现在业务服务中,要么是在数据库服务中;

  2. 数据库服务是扩展的难点,因为数据库有状态,不能无脑水平扩展,要满足CAP或者BASE理论;

  3. 好的架构是能通过水平扩展,增加机器资源就能提升系统性能。



发布于: 2020 年 07 月 02 日阅读数: 58
用户头像

还未添加个人签名 2017.10.30 加入

半壁山房待明月,一盏清茗酬知音。

评论

发布
暂无评论
系统架构:学习小结