架构演进之路

前言

架构之所以会进行演变，是因为硬件的限制导致没办法容纳更多的请求
解决方法一般有：开源、节流
开源：即增加某台服务器的配置
节流：将流量分摊

1. 单机架构

顾名思义，将所有的服务放到一台服务器上

缺陷：一台服务器的可扩展能力有限，如果对硬件需求高于服务器最大能力则导致无法正常提供服务
优点：简单、方便、便宜

2. 应用数据分离架构

在单机架构的基础上，将应用服务和数据库部署到不同的服务器上，应用服务通过网络访问数据，可以最小代价的提升系统的承载能力

3. 应用服务集群架构

随着访问量越来越多，一台应用服务器已经无法满足大量的请求时，应用服务器集群孕育而生，将应用服务部署到多台服务器上，由负载均衡器来调度分配请求到应用服务器上

负载均衡策略：

1. Round-Robin轮询：即非常公平地将请求依次分给不同的应用服务器。
2. Weight-Round-Robin 轮询：为不同的服务器（比如性能不同）赋予不同的权重（weight），能者多劳。
3. 一致哈希散列:通过计算用户的特征值（比如 IP 地址）得到哈希值，根据哈希结果做分发，优点是确保来自相同用户的请求总是被分给指定的服务器。也就是我们平时遇到的专项客户经理服务.

有朋友就要问了，虽然请求被分摊到了每个应用服务器上去处理，但是负载均衡器可是接收了所有的请求，那负载均衡器不就也会有请求达到上限的时候吗？
对的，负载均衡器的处理能力也会达到上限

1. 负载均衡器只需要做分发的工作，这意味着他需要处理的事难度很低，能够比应用服务器容纳更多的请求
2. 可以横向扩充负载均衡器的个数，形成多个集群，就类似于有的大学，因为招收学生不断的增多，一个校区已经容纳不下那么多的学生，就可以新建新的校区

4. 读写分离 / 主从分离

应用服务器集群架构虽然解决了单个应用服务器访问量过大的问题，但是应用服务器都连着同一个数据服务器，这就导致数据服务器的访问量过大，所以就有了读写分离架构

在实际应用中，大多数情况都是读的次数比写的次数多很多的，所以可以让读写分离，分别取访问不同的服务器，当用户写数据时，修改主数据库，并且同步到从数据库

5. 冷热分离架构

虽然主从服务器解决服务器访问量的问题，但是并没有解决效率问题，由于数据库是要和磁盘交互的，这就意味着效率很低。
解决方法：引入缓存服务器，计算机也有“二八”定律，即百分之二十的数据能够支撑百分之八十的访问量，正是因为这个原因，便可以把少量数据存在缓存中（即内存），访问内存的速度可比访问磁盘速度快多了
Redis就可以用做缓存服务器“

6. 业务拆分 —— 微服务

由于有多台应用服务器但是代码只有一份，会导致代码的复杂程度分成的高，而且维护困难，最重要的是管理难度非常高，微服务就是为了解决"人"的问题而生的

将业务分给不同的开发团队去维护，每个团队独立实现自己的微服务，然后互相之间对数据的直接访问进行隔离，可以利用 Gateway、消息总线等技术，实现相互之间的调用关联。甚至可以把一些类似用户管理等业务提成公共服务。

优点：代码复用，模块之间解耦，维护较容易

缺点： 效率会有所降低，因为服务之间需要通过网络交互，比访问内存慢很多

7. 总结

并不是演进越后的架构就越好，架构越靠后，就意味着投入的成本会很高，且每个架构有自己的优点，也会有自己的缺点，只有适合业务的才是最好的。