浓缩精华的架构演进过程 _架构

业务驱动技术的发展是亘古不变的道理。最开始的时候，业务量少，业务复杂度低，采取的技术也相对简单，基本满足用户对功能的需求。

文章插图

图片来自 Pexels
随着 IT 信息化的普及，更多的交易放到了网络上，信息量增加和访问次数频繁就是要解决的问题了。
因此，逐渐加入了缓存、集群等技术手段。同时对业务的扩展性和伸缩性的要求也越来越高。
高并发、高可用、可伸缩、可扩展、够安全的软件架构一直是架构设计追求的目标。
今天我们来看一下架构设计经历了哪些阶段，每个阶段都解决了哪些问题，又引出了哪些新问题。
主要是引起大家的思考，在不同的业务发展阶段采取合适技术手段，用变化拥抱变化是 IT 人追求的目标。
应用与数据一体模式
最早的业务应用以网站、OA 等为主，访问的人数有限，单台服务器就能够应付。
通常，将应用程序和数据库部署到一台服务器上面，如图 1 所示：

文章插图

图 1：应用与数据一体模式
在这一阶段，我们利用 LAMP(linux Apache MySQL php)技术就可以迅速搞定，并且这些工具都是开源的。
【浓缩精华的架构演进过程】很长一段时间内，有各种针对这种应用模式的开源代码可以使用。这种模式基本上没有高并发的要求，可用性也很差。
有的服务器采用托管模式，上面就安装了不同的业务应用，一旦服务器出现问题，所有的应用就罢工了。
不过其开发和部署成本相对较低，适合刚刚起步的应用服务。图 1 就描述了单个应用和数据库运行在单台服务器的模式，我们称这种模式为应用与数据一体模式。
应用与数据分离模式
随着业务的发展，用户数和请求数逐渐上升，服务器的性能出现了问题。其中比较简单的解决方案就是增加资源，将业务应用和数据存储分开。
其架构图如图 2 所示：

文章插图

图 2：应用与数据分离模式
其中，应用服务器需要处理大量的业务请求，对 CPU 和内存有一定要求;而数据库服务器需要对数据进行存储和索引等 IO 操作，对磁盘的转速和内存会考虑更多。
这样的分离解决了性能的问题，我们需要扩展更多的硬件资源让其各司其职，使系统可以处理更多的用户请求。
虽然业务上依旧存在耦和，但硬件层面的分离在可用性上比一体式设计要好很多。
缓存的加入
随着信息化系统的发展和使用互联网人数的增多，业务量、用户量、数据量都在增长。
我们同时发现，用户会对某些数据的请求量特别大，例如新闻、商品信息和热门消息。
之前这些信息的获取方式是依靠数据库，因此受到数据库 IO 性能的影响。此时数据库成为了整个系统的瓶颈。
如果再增加服务器的数量，恐怕也很难解决，于是缓存技术就登场了，其架构图如图 3 所示：

文章插图

图 3：缓存的加入
这里提到的缓存技术分为客户端浏览器缓存、应用服务器本地缓存和缓存服务器缓存。
①客户端浏览器缓存：当用户通过浏览器请求服务器的时候，会发起 HTTP 请求。如果对每次 HTTP 请求进行缓存，那么可以减少应用服务器的压力。
②应用服务器本地缓存：它使用的是进程内缓存，又叫托管堆缓存。以 JAVA 为例，这部分缓存放在 JVM 的托管堆上面，同时会受到托管堆回收算法的影响。
由于它运行在内存中，对数据的响应速度很快，通常我们会把热点数据放在这里。
在进程内缓存没有命中的时候，会到缓存服务器中获取信息，如果还是没有命中，才会去数据库中获取。
③缓存服务器缓存：它相对于应用服务器本地缓存来说，就是进程外缓存，既可以和应用服务部署在同一服务器，也可以部署到不同的服务器。
一般来说，为了方便管理和合理利用资源，会将其部署到专门的缓存服务器上面。由于缓存会占用内存空间，因此这类服务器会配置比较大的内存。
图 3 描述了缓存请求的次序，先访问客户端缓存，之后是进程内的本地缓存，接下来是缓存服务器，最后才是数据。
如果在任意一层获取了缓存信息，就不再往下访问了，否则会一直按照这个次序获取缓存信息，直到数据库。