系统高并发的架构演进思路_高并发演化

前提：高并发系统各不相同。比如每秒百万并发的中间件系统、每日百亿请求的网关系统、瞬时每秒几十万请求的秒杀大促系统。
不同系统在应对高并发的时候，因为系统自身特点的不同，所以应对架构都是不一样的。另外，比如电商平台中的订单系统、商品系统、库存系统，在高并发场景下的架构设计也是不同的，因为背后的业务场景什么的都不一样。（明白一点：业务驱动）

（一）一个最简单的系统架构
假设刚开始你的系统就部署在一台机器上，后台就连接了一台数据库，数据库部署在一台服务器上。
举个例子
1 系统配置：系统部署的机器是4核8G，数据库服务器是16核32G。
2 假设你的系统用户量总共就10万，用户量很少，日活用户按照不同系统的场景有区别，我们取一个较为客观的比例，10%吧，每天活跃的用户就1万。
3 按照28法则，每天高峰期算他4个小时，高峰期活跃的用户占比达到80%，就是8000人活跃在4小时内。然后每个人对你的系统发起的请求，我们算他每天是20次吧。那么高峰期8000人发起的请求也才16万次，平均到4小时内的每秒（14400秒），每秒也就10次请求。
4 系统层面每秒是10次请求，对数据库的调用每次请求都会好几次数据库操作的，比如做做crud之类的。那么取一个一次请求对应3次数据库请求吧，这样的话，数据库层每秒也就30次请求。按照这台数据库服务器的配置，支撑是绝对没问题的。
上述系统如图：
（二）系统集群化部署
假设此时你的用户数开始快速增长，比如注册用户量增长了50倍，上升到了500万。此时日活用户是50万，高峰期对系统每秒请求是500/s。对数据库的每秒请求数量是1500/s，这个时候会怎么样呢？
1 按照上述的机器配置来说，如果系统内处理的是较为复杂的一些业务逻辑，比如，是那种重业务逻辑的系统的话，是比较耗费CPU的。此时，4核8G的机器每秒请求达到500/s的时候，很可能你会发现你的机器CPU负载较高了。
2 在数据库层面，以上述的配置而言，其实基本上1500/s的高峰请求压力的话，还算可以接受。这个主要是要观察数据库所在机器的磁盘负载、网络负载、CPU负载、内存负载，按照线上经验而言，那个配置的数据库在1500/s请求压力下是没问题的。所以此时你需要做的一个事情，首先就是要支持你的系统集群化部署。你可以在前面挂一个负载