系统架构:学习小结
课程回顾
这周的课程,老师介绍了一个大型的典型的互联网应用架构的演化,同时分享了淘宝、微博和宅米网的架构演化案例。
初始阶段:最简单的互联网应用架构
优点
快速开发,部署简单,一般用于业务试验阶段。
缺点
单台服务器的性能和容量有限,可用性很差,单机宕机服务即不可用。
阶段一:应用与数据分离
优点
资源充足,性能有所提升。
缺点
可用性不好,服务没有冗余
用户量增加,数据库访有问压力
阶段二:使用缓存改善性能
优点
引入缓存,缓解数据库压力,提升了系统性能和容量。
缺点
可用性不好,服务没有冗余
单台应用服务器处理能力有限,会造成瓶颈
阶段三:使用应用服务集群来改善系统的并发能力
优点
应用服务做集群部署,增加了系统容量,提升了系统可用性。
缺点
session如何在各个应用之间同步,需要做额外的开发,一般可以使用JWT + redis来处理
增加系统容量后,随着用户的增加,数据库的处理能力又会到达瓶颈
阶段四:数据库读写分离
优点
读写分离主从DB模式,缓解了单台数据服务的访问压力。
缺点
从主复制有延迟,业务需要做特殊处理
静态资源加载慢
阶段五:使用反向代理和CDN加速网站响应
优点
增加了反向代理和CDN,加速了静态资源的访问,其实也是缓存,将资源放到了离用户最近的地方。
缺点
随着用户的增加,应用服务器可以水平扩展,增加容量,单实例的数据库写入操作将会成为瓶颈
阶段六:使用分布式文件系统和分布式数据库系统
优点
扩展数据库系统,缓解访问压力和存储压力。
缺点
分库分表能缓解压力,提升数据库系统的容量和性能,但会出现事务、join等操作的复杂度
虽然缓解压力,但是大量的访问还是存在的
阶段七:使用NOSQL和搜索引擎
优点
增加了存储引擎和Nosql服务器,进一步缓解了数据库的访问压力。
缺点
业务服务本身的臃肿,阻碍了开发部署的效率,可扩展性成了下一步演化的关键问题
阶段八:业务拆分
优点
将臃肿的业务拆分成各自独立的服务,可以独立开发和部署,同时也可以优化服务器资源,增加热点服务的机器资源,减少边缘服务的资源。
缺点
拆分后的业务功能逐步增加,变得重新臃肿
阶段九:微服务和中台化
优点
将服务拆分的足够小,每个服务有各自独立的数据库服务,做到真正的各个服务完全独立。中台化复用了各个服务的功能,进一步提升了系统的可扩展性。
缺点
做到这个地步,问题还是会有的,只是具体问题就得具体分析了。
阶段十:大数据 + BI
总结
综上所述:我有以下几点感想。
瓶颈出现在业务服务中,要么是在数据库服务中;
数据库服务是扩展的难点,因为数据库有状态,不能无脑水平扩展,要满足CAP或者BASE理论;
好的架构是能通过水平扩展,增加机器资源就能提升系统性能。
版权声明: 本文为 InfoQ 作者【行下一首歌】的原创文章。
原文链接:【http://xie.infoq.cn/article/10d46099d7ff1e0ec3ab962bd】。
本文遵守【CC BY-NC】协议,转载请保留原文出处及本版权声明。
评论