由《羊了个羊》想到的高并发架构之路

前言

    要说最近一段时间最火的话题是什么，那必定是《羊了个羊》，频频冲上微博热搜第一。因访问量骤增，大量玩家涌入进来，高并发流量导致游戏服务器被接连击穿。《羊了个羊》服务器几天内就出现了多次异常，无法登录游戏。

问题思考

    我想这其中多次崩溃的原因可能很多：可能是高并发流量导致服务器负载打满，引发宕机；可能是数据库查询量较大，出现性能瓶颈；也可能是高并发访问将缓存击穿；还有可能是受到ddos攻击…

    曾经我面试的时候就有面试官问道：“现在让你设计一个业务场景，客户端访问我们的业务服务端，从最初的业务规模很小，到后面业务规模业务很大，你应该如何设计并改进？”

    现在具有一定规模的业务场景必定都采用了高并发的架构。

    本文将以业务刚开始搭建到业务规模壮大为引子，详细讲一讲高并发架构是如何一步一步实现的，也很好的回答了上面的那道面试题。

高并发架构演进

1. 单机架构提供服务

业务初期，用户量很少，百来十个请求，一台服务器就可以部署应用和数据库。
使用后端编程语言（python、go、php、java）开发一个应用程序，然后使用一个数据库（mysql、sqlserver）再存储业务数据。应用和数据库运行在同一台机器上面，开始对外提供服务。

2. 应用服务和数据库分离

用户开始增多，应用服务和数据库产生资源争抢，一台服务器使用起来够呛，于是将应用服务和数据库进行拆分，一台服务器专门跑应用程序，一台服务器专门跑数据库。

3. 增加缓存数据库

随着用户量进一步增多，每次访问都和数据库交互，会十分影响系统的响应速度，所以可以使用缓存技术。针对热点数据，直接从内存中取出来返回，加快响应速度。

4. 引入负载均衡

用户量还在进一步增多，单一应用服务器性能不足以支撑业务，系统开始变得卡顿。为了防止宕机导致业务不可用，这时需要增加多台应用服务器，形成集群，使用负载均衡进行负载（软件负载均衡nginx、haproxy），提高并发访问量。

5.数据库读写分离

用户数量的增长，数据量激增，数据库的读写压力就增大了。数据库开始出现瓶颈，读写变慢。但对于数据库来说，无法简单的应用集群来解决压力问题，因为数据会不一致，所以需要采用读写分离，写走主库，读走从库（事务中的读也要走主库）。

6.数据库拆表分库

业务数据量越来越大时，所有的业务都存储在单一的数据库中，即使单一的数据库已经做了读写分离，但是因为数据量庞大，依然无法满足系统性能的要求，这时就需要拆表分库。同一张表的数据拆分到多个数据库中（水平拆分），把单个数据库中的不同业务拆分到不同的数据库服务器中（垂直拆分）。

7. 使用硬件负载均衡

业务越来越火爆，用户量还在激增，最终软件负载均衡也扛不住了。那就采用硬件负载均衡（F5），将流量分发到不同的软件负载均衡上面，提高访问性能。

8. DNS轮询负载

当用户还在数几十万几百万的增长时，硬件防火墙也扛不住了。这时咱们再采用DNS轮询的方式，将访问域名解析到多个机房的IP上面，不同地区的用户访问到不同的IP上面。千万级到亿级的并发量都可以通过增加机房来解决。

9. 引入高防系统

随着业务的知名度越来越高，可能会受到外部的ddos攻击，导致正常的请求流量无法进入系统，用户访问失败。这时就需要引入高防系统，清洗异常流量。

10. 引入WAF应用防火墙

后来，业务系统经常受到SQL注入、XSS跨站、Webshell上传、CC攻击。这时需要引入WAF应用防火墙，有效识别Web业务流量的恶意特征，在对流量清洗和过滤后，将正常、安全的流量返回给服务器，从而保障系统的业务安全和数据安全。

上面讲解了高并发架构的演进之路，当然，根据实际业务情况，我们可能还需要引入Nosql数据库，时序数据库，消息队列，CDN等系统，甚至需要进行微服务的拆分，进一步强大健壮我们的业务系统。

参考文档

https://mp.weixin.qq.com/s/BABN6y2mYj2Cd-p0dlb6Ug

微信关注我，获取更多干货！