前言
架构之所以会进行演变,是因为硬件的限制导致没办法容纳更多的请求
解决方法一般有:开源、节流
开源:即增加某台服务器的配置
节流:将流量分摊
1. 单机架构
顾名思义,将所有的服务放到一台服务器上
缺陷:一台服务器的可扩展能力有限,如果对硬件需求高于服务器最大能力则导致无法正常提供服务
优点:简单、方便、便宜
2. 应用数据分离架构
在单机架构的基础上,将应用服务和数据库部署到不同的服务器上,应用服务通过网络访问数据,可以最小代价的提升系统的承载能力
3. 应用服务集群架构
随着访问量越来越多,一台应用服务器已经无法满足大量的请求时,应用服务器集群孕育而生,将应用服务部署到多台服务器上,由负载均衡器来调度分配请求到应用服务器上
负载均衡策略:
- Round-Robin轮询:即非常公平地将请求依次分给不同的应用服务器。
- Weight-Round-Robin 轮询:为不同的服务器(比如性能不同)赋予不同的权重(weight),能者多劳。
- 一致哈希散列:通过计算用户的特征值(比如 IP 地址)得到哈希值,根据哈希结果做分发,优点是确保来自相同用户的请求总是被分给指定的服务器。也就是我们平时遇到的专项客户经理服务.
有朋友就要问了,虽然请求被分摊到了每个应用服务器上去处理,但是负载均衡器可是接收了所有的请求,那负载均衡器不就也会有请求达到上限的时候吗?
对的,负载均衡器的处理能力也会达到上限
- 负载均衡器只需要做分发的工作,这意味着他需要处理的事难度很低,能够比应用服务器容纳更多的请求
- 可以横向扩充负载均衡器的个数,形成多个集群,就类似于有的大学,因为招收学生不断的增多,一个校区已经容纳不下那么多的学生,就可以新建新的校区
4. 读写分离 / 主从分离
应用服务器集群架构虽然解决了单个应用服务器访问量过大的问题,但是应用服务器都连着同一个数据服务器,这就导致数据服务器的访问量过大,所以就有了读写分离架构
在实际应用中,大多数情况都是读的次数比写的次数多很多的,所以可以让读写分离,分别取访问不同的服务器,当用户写数据时,修改主数据库,并且同步到从数据库
5. 冷热分离架构
虽然主从服务器解决服务器访问量的问题,但是并没有解决效率问题,由于数据库是要和磁盘交互的,这就意味着效率很低。
解决方法:引入缓存服务器,计算机也有“二八”定律,即百分之二十的数据能够支撑百分之八十的访问量,正是因为这个原因,便可以把少量数据存在缓存中(即内存),访问内存的速度可比访问磁盘速度快多了
Redis就可以用做缓存服务器“
6. 业务拆分 —— 微服务
由于有多台应用服务器但是代码只有一份,会导致代码的复杂程度分成的高,而且维护困难,最重要的是管理难度非常高,微服务就是为了解决"人"的问题而生的
将业务分给不同的开发团队去维护,每个团队独立实现自己的微服务,然后互相之间对数据的直接访问进行隔离,可以利用 Gateway、消息总线等技术,实现相互之间的调用关联。甚至可以把一些类似用户管理等业务提成公共服务。
优点:代码复用,模块之间解耦,维护较容易
缺点: 效率会有所降低,因为服务之间需要通过网络交互,比访问内存慢很多
7. 总结
并不是演进越后的架构就越好,架构越靠后,就意味着投入的成本会很高,且每个架构有自己的优点,也会有自己的缺点,只有适合业务的才是最好的。