一. 分布式架构的演进
1.1 单机架构
单机架构指的是应用服务器和数据库部署在了一台主机上.
写过web项目的程序猿都知道,web服务器可以分为应用服务器和数据库,用户提交请求给应用服务器,应用服务器使用数据库查询相关信息,然后返回响应.
1.2 应用数据分离架构
随着用户数量的增多,一台主机既要存储用户信息,还要响应用户的请求.如果它的硬件配置很拉,会给用户带来非常糟糕的体验.然鹅再高端的主机也有吃不消的时候,更何况硬件的升级并不是随着钞能力呈线性增长的.
因此有了应用数据分离架构,应用服务器和存储服务器部署在不同的主机上,不同主机通过网络进行通信.
这样一来,我们就可以根据业务场景选择不同的服务器.应用服务器需要面对高并发问题,因此适合使用高性能的CPU和内存;存储服务器需要存储大量的信息,因此适合使用空间大访问速度快的硬盘.
1.3 应用服务集群架构
做个美梦~随着我们的app越来越受欢迎,用户数量不断增长,一台应用服务器已经不能应对大量的用户请求.因此有了两种解决方案:
- 垂直扩展: 购买性能更优,价格更高的应用服务器来应对高并发问题.(这当然需要更大的钞能力)
- 水平扩展: 通过增加应用服务器的数量,同时需要调整软件架构,将用户流量分摊到不同的应用服务器上.(虽然节省了购买机器的成本,但是更多的主机会带来更多的Bug,会大大提高人力成本)
垂直扩展没啥好讨论的,我们接下来要讲的是水平扩展.需要引入一个负载均衡服务器,它能使用一定的算法将用户的请求平均分配给不同的应用服务器.
1.4 读写分离/主从分离架构
用户向应用服务器发出的请求越多,应用服务器向数据库发出的请求也会增多,因此我们不能只升级应用服务器,数据库服务器也做了水平扩展.因为写入操作要比读出操作少的多,因此采用读写分离机制,为读操作多分配几台主机.
保留一个主要的数据库作为写数据库(主数据库),其他的数据库作为读数据库(从数据库),从数据库需要从主数据库同步信息.
其中,从数据库也会使用负载均衡的方式平摊请求.
1.5 冷热分离架构
相信诸位都听过"二八定则"--80%的财富被掌握在20%的人手中(很不幸,博主被排除在外了).计算机届也同样适用.80%的请求量访问的是20%的数据,通常,被频繁访问的数据我们称为"热点数据",与之对应的是"冷数据".
因此又引入了缓存机制存储热数据提升响应时间.(可类比Cache)
1.6 垂直分库
随着用户数量的增多,不仅带来了大量的网络请求,对存储服务器的空间要求也更大.大量的数据存储在一个数据库中已经有些力不从心了.
可以进行分库/分表操作,将数据存放在不同的数据库中,这些存储数据的主机称为"存储集群".
1.7 微服务
用户数量增多--->公司员工增多--->业务需求多样化,因此为了更方便的业务划分和人员管理,又引入了**"微服务"--将业务分给不同的开发团队去维护,每个团队独立实现自己的功能.**
举个栗子~一个教育平台的微服务就包括教师信息维护,学生信息维护,作业情况,课程完成进度等.
二. 分布式的常见概念
一提起分布式系统,童靴们肯定会觉得这个项目提升了不止一个档次(博主一开始也是这样想的),看完下面的定义,你可能会觉得just so so~~
- 应用/系统: 为了完成一整套服务的一个程序或者一组相互配合的程序群.
- 模块/组件: 当应用比较复杂时,为了分离业务,将其中内聚性强的部分抽象出来
- 分布式: 系统的多个模块被部署在不同的服务器上(物理意义上的多台主机)
- 主/从:集群架构中,通常有一台服务器承担更多的职责(称为主),其他承担附属职责的被称为从
- 中间件: 不同业务的系统用来沟通的桥梁,即功能更通用的组件
下面是系统的评价指标:
- 可用性: 系统正常提供服务的时长/期望时长
- 响应时长: 用户提交请求到系统给出响应的时长
- 吞吐量/并发量: 单位时间内处理用户请求的数量