cdn加速分布式系统高可用高并发架构设计，架构

 之前写过一篇并发数1万，日活跃百万的系统的数据库的架构设计，本文从另一个视角来分析下这类高并发的系统的整体系统架构设计方案。

• 1，缘起

• 2，单体架构

• 3，服务器集群

• 4，分布式缓存系统

• 5，读写分离

• 6，总结

1，缘起

 之前写过一篇并发数1万，日活跃百万的系统的数据库的架构设计（想看看的话，地址在这里：【分布式系统-数据库架构设计】并发数1万？日活跃百万？数据库咋办啊），有很多朋友看了后感觉迷茫，无从下手，所以本文来点实在的，从另一个视觉来讲解下。

2，单体架构

我们大多数待的都是小公司，研发团队一般8到10人左右，一开始的时候，编写一个项目，用户量不大，一般几千到几万，所以这时候的架构设计是用的“单体架构”，也就是所有的模块代码在一个系统里面，大家分工写功能模块，然后git提交合并，这样子也挺省事（很多人可能会觉得为嘛一开始这样子设计？设计得灵活点不更好吗？）。

上面一般会是三个服务器，CDN服务器（静态资源存放），应用代码服务器，数据库服务器，那么这种部署就会存在单节点故障问题，要是应用服务器挂了怎么办？数据库服务器挂了怎么办？也即是要“高可用”，

那么这时候我们可以再加服务器冗余配置，比如两台应用服务器，再加一个web服务器负载均衡比如LVS，Nginx等都行，数据库方面再加一台数据库服务器做主从同步（现在一般的数据库都支持该功能），CDN当然也需要。那么现在我们的系统算是简单的“高可用”了。

但后来随着项目上线，用户量越来越多，发展前景很好，预计用户量达到1000万，那么按照28原则，算下来在5小时内（24*0.2=4.8 ）会有200万用户访问，假设平均每个用户点击页面20-30次，则会有6000万次请求，即5小时内，6000万请求，估算得 QPS = 3000，那么峰值为 3000 * 3 = 10000 ，也即是并发数1万。那现在的简单“高可用”的架构顶不住的，那该怎么办？

3，应用服务器集群

并发数1万，上面服务器顶不住的，怎么办？集群呗。

怎么集啊？

拆分啊，简单说就是服务化（本小节本来名字想改为“服务化”，名字不重要，各位记住这词就OK了），也即是把之前的整个系统，按照业务逻辑拆分成几个子系统，子模块，然后各个子系统分别部署，并且每个子系统做备份处理。

然后每个子系统交给一个小组负责，分工协作，开发效率大大提升，而且系统整体也得到了提升。

其实这里有点类似与“微服务架构”了，算是起步，后续要完全走向“微服务架构”牵涉会很多的。

4，分布式缓存系统

应用层面解决了，可数据库还没呢，并发10000，平均每次请求读写数据库3次，那么数据库请求为30000，这数据库，可顶不住，那怎么办？

也集群呗？

集群也行，但有点浪费的感觉，那最为最后办法吧，先看看有没其他的。

既然是不想让数据压到数据库，那么我们压在中间层如何？可以，那就是“缓存”了，那么用redis集群部署分布式缓存系统来处理，那需要部署多少redis呢？还是按照28原则，那么大概有2.4万次是读请求，那么3到4个redis可满足。这里还会牵涉具体分布式存储系统架构设计细节，可以看下之前文章【存储系统架构设计】缓存穿透，缓存击穿，缓存雪崩，热点数据集中失效，redis 缓存系统四连击怎么解决？和【存储系统架构设计】redis可以解决什么问题？

5，读写分离

3万数据库读写过滤了2.4万读请求到存储系统，那还剩大概1万会压到数据库层面，数据库还是顶不住，那怎么办？集群呗。又来集群，有钱啊，其实也可以先不用，之前不是做了“主从同步”的吗？我们读写分离就好了啊，这样的话，大概会有4000到5000写操作压到数据库，可以支撑，问题不大。   

到这里那么我们的系统就是一个可以支撑10000并发，千万用户的高可用高并发系统了。

最后来一张总的系统架构图吧。

6，总结

本文主要分析了千万用户，10000并发的高可用高并发系统的设计思路，当然其中还有很多的细节未展开（比如负载均衡算法，该系统的下一步方向等等），后续感兴趣的可以单开章节详解，还是之前的话，思路最重要，希望能对你有所帮助。