科普系统架构系列:分布式架构发展过程中问题和挑战的分析研究

277 阅读6分钟

这是我参与8月更文挑战的第20天,活动详情查看:8月更文挑战

分布式架构

初始阶段架构

在这里插入图片描述

特征

  • 应用程序,数据库,文件等所有资源都放在同一台服务器上

应用服务和数据服务以及文件服务分离

在这里插入图片描述

特征

  • 应用程序,数据库和文件分别部署在独立的资源上

问题

  • 随着系统访问量的再度增加 ,webserver机器的压力在高峰期会上升到比较高,需要开始考虑增加一台webserver

使用缓存改善性能

在这里插入图片描述

特征

  • 数据库中访问较集中的一小部分数据存储在缓存服务器中,减少数据库的访问次数,降低数据库访问压力

问题

  • 系统访问特点遵循二八定律,即80% 的业务访问集中在20% 的数据上
  • 缓存分为本地缓存和远程分布式缓存
  • 本地缓存访问的速度更快但是缓存数量有限,同时存在与应用程序争抢内存的情况

使用应用服务器集群

在这里插入图片描述

特征

  • 多台服务器通过负载均衡同时向外部提供服务,解决单台服务器处理能力和存储空间上限的问题

描述

  • 使用集群是解决高并发,海量数据问题的常用手段
  • 通过向集群中追加资源,提升系统的并发处理能力,使得服务器的负载压力不再成为整个系统的瓶颈

问题

  • Apache会阻塞很多请求,应用服务器对每个请求的比较快的
  • 请求数太高会导致需要排队等待,响应速度变慢

数据库读写分离

在这里插入图片描述

特征

  • 数据库引入了主备部署

描述

  • 数据库划分为读库和写库
  • 通过引入主从数据库服务,读和写操作在不同的数据库服务处理
  • 读库可以有很多个,通过同步机制将写库的数据同步到读库
  • 对于需要查询最新写入数据的场景,可以通过缓存中多写一份,通过缓存获得最新数据

问题

  • 数据库写入,更新的操作部分对数据库连接的资源竞争非常激烈,导致系统变慢

反向代理和CDN加速

在这里插入图片描述

特征

  • 采用CDN和反向代理加快系统的访问速度

描述

  • 为了应付复杂的网络环境和不同地区用户的访问,通过CDN和反向代理加快用户访问的速度,同时减轻后端服务器的压力
  • CDN与反向代理的基本原理都是缓存

分布式文件系统与分布式数据库

在这里插入图片描述

特征

  • 数据库采用分布式数据库,文件系统采用分布式文件系统

描述

  • 任何强大的单一服务器都满足不了大型系统持续增长的业务需求
  • 数据库读写分离随着业务的发展最终也将无法满足需求,需要使用分布式数据库及分布式文件系统来支撑
  • 分布式数据库:
    • 是系统数据库拆分的最后方法,只有在单表数据规模非常庞大的时候才使用
    • 更常用的数据库拆分手段是业务分库,将不同的业务数据库部署在不同的物理服务器上

问题

  • 随着系统的不断运行,数据量开始大幅增长
  • 数据库分库的查询仍然很慢,于是按照分库的思想来做分表的工作

使用NoSQL和搜索引擎

在这里插入图片描述

特征

  • 系统引入NoSQL数据库和搜索引擎

描述

  • 随着业务越来越复杂,对数据存储和检索的要求也越来越复杂,系统需要采用一些非关系型数据库NoSQL和分数据查询技术搜索引擎
  • 应用服务器通过统一的数据访问模块访问各种数据,减轻程序管理诸多数据源的麻烦

业务拆分

在这里插入图片描述

特征

  • 系统按照业务进行拆分,应用服务器按照业务区分进行分别部署

描述

  • 为了应对日益复杂的业务场景,通常使用分而治之的手段将整个业务系统分成不同的产品线
  • 应用之间通过超链接建立关系,也可以通过消息队列进行数据分发.更多是通过访问同一数据存储系统来构成一个关联的完整系统
  • 纵向拆分:
    • 将一个大应用拆分成多个小应用
    • 如果新业务比较独立,那么就直接设计部署为一个独立的Web应用系统
    • 纵向拆分相对比较简单,通过梳理业务,可以将较少相关的业务剥离即可
  • 横向拆分:
    • 将复用的业务拆分出来,独立部署为分布式系统
    • 新增的业务只需要调用这些分布式服务
    • 横向拆分需要识别可复用的业务,设计服务接口,规范服务依赖关系

分布式服务

在这里插入图片描述

特征

  • 公共的应用模块被提取出来,部署在分布式服务器上供应用服务器调用

问题

  • 随着业务越拆越小,应用系统整体复杂程度呈指数级上升
  • 由于所有应用要和所有数据库系统连接,最终导致数据库连接资源不足,拒绝服务

分布式架构问题和挑战

  • 当服务越来越多时,服务URL配置管理变得非常困难,硬件负载均衡器的单点压力也越来越大
  • 当服务越来越多时,服务间的依赖关系变得错综复杂,甚至分不清哪个应用要在哪个应用之前启动,架构师都不能完整地描述应用的架构关系
  • 服务的调用量越来越大,服务的容量问题就暴露出来,这个服务需要多少机器支撑?什么时候该加机器?
  • 服务多了,沟通成本也开始上升,调用某个服务失败应该找谁?服务的参数都有什么约定?
  • 一个服务有多个业务消费者,如何确保服务质量?
  • 随着服务的不断升级,总有一些意想不到的事情发生: 比如cache写错了导致内存溢出,故障不可避免,每次核心服务宕机,影响损失大,如何控制故障的影响面?服务是否可以功能降级?服务是否可以资源劣化?
  • 针对这个问题,可以使用以下架构解决:
    • 单元化架构
    • 微服务架构
    • Serveless架构
  • 针对业务系统,做到以下几个方面可以解决上述问题:
    • 业务与业务隔离
    • 管理域和运行域分开
    • 业务与平台隔离