系统架构随着技术手段越来越成熟近些年得到了很大的提升,从以前的单系统架构,到应用和数据层分离,集群,分布式集群等等,下面就来一一总结。

一、单应用

单应用顾名思义,就是应用服务和数据库服务都在同一台服务器上运行。一般项目初期会考虑这种架构方式,因为效率决定生死,先要让项目面市,后期考虑优化方案。
单系统架构

二、应用服务和数据库服务分离

从项目上线面市到运营一段时间后,就会发现服务器的负载逐步攀升,当代码层面无法进行优化的时候,就需要考虑增加机器来缓解一台服务器的压力了。

应用和数据分离

从图中可以看到就是将数据库服务分离到了一台新的服务器去,这样两个服务直接不会互占资源,影响彼此。后面只需要关注应用服务的优化即可。

二、应用服务集群

单台应用服务承载的并发毕竟是有上限的,此时需要部署更多的应用服务缓解一台应用的并发压力。

应用集群

但这个时候,就会出现如下问题

  • 用户访问进来到底分配到哪个服务器去
  • 用户的session如何共享。
问题一:用户访问进来到底分配到哪个服务器去

可以使用nginx的负载均衡策略

nginx共有多种负载请求调度策略

  • 轮询(默认)
  • 权重策略
  • IP哈希策略
  • 访问地址哈希策略
  • 最少链接数策略
问题二:用户的session如何共享。

session共享可以使用数据库或缓存(redis等)

三、数据服务集群

现在应用服务的压力减小了不少,但数据库服务的压力咔咔往上增加。

下面是常见的从数据库中获取数据的流程。
数据服务集群

普遍的优化方式有以下两种:

  • 增加缓存
  • 数据库读写分离
  1. 增加缓存

数据服务集群

  1. 数据库读写分离
    数据服务集群

当然还有其他可供选择的缓解数据库压力的服务,比如:ElasticSearch、阿里云的opensearch、xunsearch这些全文索引搜索引擎服务。
数据服务集群

四、业务服务拆分

应用服务进行业务拆分,降低代码冗余程度,独立的应用服务处理独立的业务,各应用服务之间可以使用消息中间件进行通信,或者用最基础的curl。

业务服务拆分

五、数据库拆分、集群

可将数据库根据业务水平、垂直进行拆分

数据库拆分、集群

最后可将数据库做成集群。

数据库拆分、集群

最后修改:2020 年 09 月 12 日 01 : 13 AM
如果觉得我的文章对你有用,请随意赞赏