课程回顾

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

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

优点

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

缺点

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

阶段一：应用与数据分离

优点

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

缺点

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. 好的架构是能通过水平扩展，增加机器资源就能提升系统性能。