随着系统的上线，我们不出意外地获得了成功。市场上出现了⼀批忠实于我们的⽤⼾，使得系统的访问量逐步上升，逐渐逼近了硬件资源的极限，同时团队也在此期间积累了对业务流程的⼀批经验。⾯对当前的性能压⼒，我们需要未⾬绸缪去进⾏系统重构、架构挑战，以提升系统的承载能⼒。但由于预算仍然很紧张，我们选择了将应⽤和数据分离的做法，可以最⼩代价的提升系统的承载能⼒.

如果业务进一步增长,用户量和数据量都水涨船高的时候,总有一天,一台主机就会难以应付,这个时候我们就需要引入更高的硬件资源.毕竟一台主机的硬件资源是有限的.

可以看到这个架构和之前的架构的区别就是将数据库服务器部署在了其他的主机上,应用服务器就会通过网络去访问数据库服务器.

应用数据集群架构

应用服务器可能会吃很多的CPU和内存,如果把CPU和内存都吃完了,那么应用服务器就会顶不住了,那么我们需要引入更多的应用服务器来解决这个问题.

此时如果当访问量进一步增高的时候,这种一个应用服务器和一个存储服务器的架构已经满足不了需求的时候,就会引入更多的应用服务器节点.

这里的web服务器可以是多个,不止两个.

可以发现当引入了更多应用服务器节点之后,我们的架构中出现了负载均衡器.这个负载均衡器的作用就像公司里面的领导一样,要负责管理,要负责把任务平均的分配给每个员工.

假设有1W的用户请求,如果只有一个应用服务器的时候,那么这1W个请求肯定都会落在哪一个应用服务器上的,但是如果有多个应用服务器之后,再加上负载均衡器的加入,负载均衡器会将这1W个请求尽可能平均的分配给每个应用服务器.

读写分离 / 主从分离架构

如上面所讨论,增加了应用服务器之后,确实可能承载更多的请求了,但是我们的存储服务器要承担的请求量还是那么多?

这个时候我们是不是应该考虑增加存储服务器的主机数量了.

将存储服务器的职责进一步细分,存储服务器的主机之间变成读写分离的结构.

我们可以将写数据请求全部交给主库处理，但读请求分散到各个从库中。由于⼤部分的系统中，读写请求都是不成⽐例的，例如 100 次读 1 次写，所以只要将读请求由各个从库分担之后，数据库的压⼒就没有那么⼤了。

只用主数据库进行写,其他数据从数据库进行读,然后在主数据库和从数据库之间进行数据同步.主服务器一般只有一个,但是从服务器可以有多个.

引⼊缓存⸺冷热分离架构

到了这一步之后,我们发现业务中⼀些数据的读取频率远⼤于其他数据的读取频率。我们把这部分数据称为热点数据，与之相对应的是冷数据..对于我们需要频繁访问的热数据,数据库的响应还是比较慢的.

我们可以将冷热数据进行区分,将热数据放入缓存中,因为缓存的访问速度要比访问数据库要快很多的.

我们这里的缓存服务器可以使用Redis,让Redis帮助数据库进行负重前行.

我们可以在缓存服务器这里存放一部分热点数据,因为这些热点数据都是会被频繁访问的数据,数据库服务器这里存储的还是全量的数据.

当我们需要进行读取数据的时候,会先在缓存服务器中读取,如果缓存服务器中有数据,则不在去数据库服务器中查询,要是缓存服务器中没有数据,才会去查询数据库服务器.这样的话,数据库服务器的压力就会进一步减小.

垂直分库

随着业务的数据量增⼤，⼤量的数据存储在同⼀个库中已经显得有些⼒不从⼼了，所以可以按照业务，将数据分别存储。

这时就需要针对数据库进一步进行拆分,也就是分库分表

本来一个数据库服务器上就会有多个数据库,现在引入多个数据库服务器,每一个数据库服务器存储一个或者一部分数据.如果某个表特别大,可以针对这个表进行拆分.具体如果拆分,还需要根据具体的业务场景进行展开.

业务拆分-微服务

随着⼈员增加，业务发展，我们将业务分给不同的开发团队去维护，每个团队独⽴实现⾃⼰的微服务，然后互相之间对数据的直接访问进⾏隔离，可以利⽤ Gateway、消息总线等技术，实现相互之间的调⽤关联。甚⾄可以把⼀些类似⽤⼾管理、安全管理、数据采集等业务提成公共服务。

按照功能,拆分为多组微服务,就有利于上述人员的组织分配了.

使用微服务,可以更方便的进行功能的复用,可以针对不同的服务进行不同的部署.不同服务之间通过网络进行交互.

声明：本文内容由网友自发贡献，不代表【wpsshop博客】立场，版权归原作者所有，本站不承担相应法律责任。如您发现有侵权的内容，请联系我们。转载请注明出处：https://www.wpsshop.cn/w/羊村懒王/article/detail/378020