大型网站系统演进流程

一、分布式系统概述

一、什么是分布式系统
  • 组件分布在网络计算机上
  • 不同的组件之间通过消息进行通信

简单理解就是一张蜘蛛网,不同的蜘蛛通过网络连接,并通过呼喊进行通信的方式叫做分布式网络。

二、为什么需要分布式系统
  • 单纯提高单机处理能力性价比低
  • 单机处理能力存在瓶颈
  • 单机处理如果一旦机器挂了会影响所有的组件服务
三、线程与进程
  • 多线程:互不相互干扰的多线程、共享内存的多线程
  • 多进程(涉及数据共享问题)
四、网络IO实现过程
  • BIO 阻塞式 一个请求一个线程处理
  • NIO 非阻塞式 多个请求被Reactor代理并中转给Handler处理,派发给不同的线程
五、如何将单机拓展到分布式

计算机的组成分为输入设备、内存、控制器、运算器、输出设备

对于用户而言,一个请求发送,背后是一个庞大的分布式网络去处理,其实站在用户的角度,这也是一个计算机。

六、分布式系统跟单机的区别

1、输入设备:在庞大的分布式集群上面,每个能接受请求、消息的设备都可以称为输入设备

2、输出设备:能向分布式网络中的节点发送消息的节点都可以看成输出设备

3、控制器:对于单机而言,控制器就是CPU中的控制器,而在由许多节点通过网络相互连接,通过消息传递进行协调的分布式系统上,控制器实际上是不同的节点之间的一个桥梁,作用是用于控制或者调解不同节点之间的动作或者行为。例如在请求发起方以及请求处理方增加一个负载均衡设备,负载均衡设备能确定请求的处理机器的位置并且将请求发送给处理机器。也可以使用名称服务的方式,在这样的方式下,名称服务能维护一份请求处理方的状态信息,当请求处理方上下线的时候能进行感知并将服务提供方的信息更新到请求方,由请求方跟服务方进行直连。

4、运算器

5、存储

七、分布式系统的问题

二、大型网站及其架构演进

一、 单机系统存在的问题
  • 单机系统上,服务端以及数据库都部署在同一台机器上面,当访问量增大,机器的load持续升高。
二、演进

1、数据库与应用分离。

在最开始的设计上,应用跟数据库处于同一台机器,在load升高的时候,可以采用数据库应用分离的策略。
数据库应用分离

2、单机变成集群。

当单机变成集群之后,有2个问题需要解决。

  • 请求过来哪台机器进行处理:增加负载均衡。
    引入负载均衡

  • session问题。当用户请求的时候,因为session存储于单机服务器上,而负载均衡解析请求并把请求转发给的机器上不一定是刚刚访问并存在session的机器。比如一个用户登录完,请求打到了其他的机器,该机器没有session,用户又得重新登录。

    1
    2
    3
    4
    5
    6
    7
    8
    9
    1、SessionSticky 

    在负载均衡上,将同样的session请求都发送到同一台服务器上。

    2、SessionReplication

    集群上的服务器的所有session进行同步。

    3、Session数据集中存储

3、读写分离

前面已经能够解决一部分应用服务器压力大的问题,但是请求打到DB,DB的压力还是存在的。

  • 读写分离

    • 假如我们做一个秒杀业务,实际上对于DB而言,是存在读多写少的情况的,那么针对这种情况,可以做读写分离。简单的说就是将原来的单DB换成读DB+写DB的组成。但是这样会带来几个问题:
    1
    2
    1、数据同步问题
    因为从写库到读库的同步需要一点时间,故会存在一定的时间窗口。MySql自带复制功能,可以直接进行使用。
  • 在使用中,经常使用引擎进行数据存储,因为检索速度快的原因,DB经常是作为打底数据使用。从这个角度看,搜索引擎也是一个读库。
    搜索引擎

  • 缓存
    缓存

4、数据库垂直与水平拆分

当读写分离以及引入分布式存储之后,对于主库的压力大大减少,但是当系统变得更加复杂的时候,我们单一的主库也会开始扛不住压力。

  • 数据库垂直拆分

    垂直拆分指的是以业务为维度进行数据库的拆分,比如一个交易管理系统有用户、订单、交易等等的业务,每个业务都放在同一个数据库中进行维护,当业务复杂之后,单DB会开始抗不住压力,此时我们可以按照业务的维度增加DB。比如用户DB,订单BD,交易DB等等,减轻所有的业务都存在一个DB的情况。

  • 数据库水平拆分

    当按照业务的维度划分后,可能存在两个问题,第一个是业务的复杂度继续加深,单表无法支撑更多的查询或者写入的请求,耗时更长,此时针对单一业务的DB可以进行水平拆分。

    水平拆分的意思是按照某个维度拆分到更多的库中,在库中由原先的一张表变成多张表。比如用户表,可以根据用户的ID进行sharding,将单表改变成多表的形式进行优化。

5、数据压力减小、应用服务压力增大

  • 应用拆分

    随着业务的复杂度提升,原先在一个系统中的交易、订单、购物车等等的应用会加入更多的模块,业务的模块增多,虽然我们已经如前面一样,在水平方向上做集群,但是如何让应用部再继续臃肿,是需要考虑的问题。

    就像分库分表一样,可以对臃肿的应用进行分家,比如交易分出去作为单一的应用,订单分出去作为单一的应用等等。

    垂直拆分之后,应用如下图:

    垂直拆分应用

  • 服务化

    应用拆分会带来另外的问题,就是这些拆分出去的应用本来是在同一个应用里的,它们存在一些公共的服务,这个时候可以通过服务化的方式进行解决。

    比如有交易管理系统的订单、优惠券、活动等都需要跟用户打交道,此时用户应用可以作为中间层,也就是服务层对上述的前端应用进行服务。

    如此一来,整体的流程都会进行改变。

    • 原先的单机调用一部分变成了RPC调用。
    • 散落在不同应用的代码都存放在服务中心中。
    • 数据库的工作更多的放在了服务中心中。
三、消息中间件

上面可以知道,分布式系统是位于网络不同节点之间,不同节点通过消息进行协调工作的系统。而上面也解决了应用以及数据库的压力问题,此时消息中间件就非常重要了。

  • 概念

    消息中间件:在分布式系统中,完成消息的发送与接收的基础软件,称之为消息中间件。简单来说,在分布式系统的不同节点上,不同节点向外发送消息的时候,消息需要先存入消息中间件中并由消息中间件进行转发的操作。

  • 好处

    极大的提高了应用之间的解耦,在分布式系统上,不同的节点之间不存在耦合的关系,只存在订阅消息与否的关系。

坚持原创技术分享,您的支持将鼓励我继续创作!