这些年,系统架构都经历了怎样的演变?
当今技术的发展日新月异,系统架构也跟随技术的发展不断升级和改进,从传统的单一架构演变为如今的微服务分布式架构,我们来看看技术架构的演变过程。
NO.1 初期网站架构
网站建设初期,访问人数有限,数据量不大,只需要一台服务器足矣,这时应用程序、文件、数据库等所有资源全部集中在这台服务器上,网站架构请看下图:
NO.2 应用和数据分离
随着网站业务的不断发展,一台服务器已经不能满足要求,用户访问量越来越大,数据量也越来越大,此时对网站的要求也逐渐变大,这就需要将应用和数据分离,变成应用服务器、文件服务器和数据库服务器。架构图如下:
NO.3 缓存数据以改善网站性能
随着用户逐渐的不断增加,数据库访问压力变大,导致访问延迟,性能较低,这时就需要缓存技术,将查询较多或者改动不大的数据缓存起来,以加快应用访问速度,下面是基本的架构图:
NO.4 应用集群
在网站访问高峰,并发量大的情况下,应用服务器就成为了整个网站的瓶颈,单一的应用服务器资源有限,高并发情况下连接很快就会超限,这时,我们就需要部署应用服务器集群,利用负载均衡器分散访问流量,减少单台服务器的压力,网站架构图如下:
NO.5 数据库读写分离
这个阶段,数据继续增加,请求数量继续加大,单个数据库已然不能满足要求,这个时候需要部署多个数据库进行读写分离,请看架构图:
NO.6 部署 CDN 节点
用户访问量的增加意味着用户地域的分散请求,如果所有请求都直接发送中心服务器的话,距离越远,响应速度越差,这时就需要用到 CDN 技术,通过 CDN 加速,保证用户访问每次都从最近的服务器获取数据,架构图如下:
NO.7 分布式数据库
分布式数据库是网站数据库拆分的最后手段,只有在单表数据规模非常庞大的时候才使用。
不到不得已时,网站更常用的数据库拆分手段是业务分库,将不同业务的数据库部署在不同的物理服务器上,如下图所示:
NO.8 使用非关系型数据库
当网站数据足够庞大,达到PB甚至更高时,关系型数据库已经达到瓶颈,这时就需要考虑采用非关系型数据库了,请看下图:
NO.9 微服务架构
随着网站业务的不断扩大,我们需要将各个业务进行拆分,形成不能的产品线,每个产品线由不同的业务团队负责,各个产品之间需要通信,这时就要用到微服务架构,请看下图:
最流行的 JavaEE 框架就是 Spring 框架,该框架是最古老也就是最成熟的 Java 技术框架之一。
为了适应技术的高速发展,Spring Cloud 出现了,它的出现带给了我们微服务的解决方案。
通过 Spring Cloud,我们很容易部署一套高性能高可用的微服务架构。