456主机测评
前言
要说最近一段时间最火的话题是什么，那必定是《羊了个羊》，频频冲上微博热搜第一。因访问量骤增，大量玩家涌入进来，高并发流量导致游戏服务器被接连击穿。《羊了个羊》服务器几天内就出现了多次异常，无法登录游戏。
问题思考
我想这其中多次崩溃的原因可能很多：可能是高并发流量导致服务器负载打满，引发宕机；可能是数据库查询量较大，出现性能瓶颈；也可能是高并发访问将缓存击穿；还有可能是受到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
微信关注我，获取更多干货！
- 海报
