概念
基本概念
-
应用(Application)/系统(System):完成一整套服务的一个程序或者一组互相配合的程序群
-
模块(Module)/组件(Component):当应用较复杂时,为了分离职责,将其中具有清晰职责的、内聚性强的部分,抽象出概念,便于理解
-
分布式(Distributed):多个模块被部署于不同服务器上
-
集群(Cluster):被部署于多台服务器上的、为了实现特定目标的一组特定的组件,这个整体就是集群
-
主(Master)/从(Slave):一个程序需要承担更多的责任就是主,其他承担附属职责的就是从
-
中间件(Middleware):提供不同应用程序用故意相互通信的软件,处于不同技术、工具和数据库之间的桥梁
评价指标
-
可用性:考察单位时间段内,系统可以正常提供服务的概率/期望,系统正常提供服务的时长/一年总时长
-
响应时长:指用户完成输入到系统给出用户反应的时长
-
吞吐/并发:吞吐考察单位时间段内,系统可以成功处理的请求的数量;并发指系统同一时刻支持的请求最高量
架构演进
单机架构
当我们需要快速将业务系统投入市场进行检验,并且可以迅速响应变化要求,同时对性能和安全并没有过高的要求,系统架构简单,此时就可以选择单机架构
只有一台服务器,用来负责所有的工作,单机服务器也要有两个基本服务:应用服务+数据库服务-->MySQL是一个客户端服务器结构的程序,本体是MySQL服务器,存储和组织数据的部分
但是一台主机的硬件资源是有限的(CPU 内存 硬盘 网络),服务器每次收到请求都是需要消耗一定的资源,如果同一时刻请求很多,资源就会不够用,此时处理请求的
所以遇到服务器不够的情况就要考虑 开源(增加更多硬件资源,但是一台机器能加的硬件资源也是有限的-->取决于主板的扩展能力) 节流(软件上优化,优化设计)
当一台主机扩展到极限时,就会引入多台主机(此时软件上也要对应的做出调整) --> 此时就是分布式系统 --> 通常使用分布式是万不得已的(系统复杂程度会大大提升!-->出现问题的概率也会增加)
应用数据分离架构
当系统的访问量逐步上升后,逐渐逼近了硬件资源的极限,面对当前的性能压力,此时我们就可以将应用和数据分离
应用服务集群架构
在分布式系统中,就会涉及到应用服务(包含业务服务,更大的内存)和数据库分离(要更大的硬盘空间,更快的数据访问速度)
此时就要引入更多的服务器节点 用户的请求先到达负载均衡器/网关 --> 然后在分发给服务器
读写分离/主从分离架构
如果遇到负载均衡器都无法承担请求时,就要划分多个区域,每一个区域都有各自的负载均衡器以及一些服务器,这样请求量就得到了分摊
当应用服务器较多时,数据库(存储服务器)的压力也会增大 --> 解决: 开源(引入更多的机器 --> 读写分离)+节流(门槛高,对程序员要求高)
数据库读写分离:(主数据库(master)+从数据库(slave) --> 数据同步) 主负责写,从负责读
实际场景中: 读要比写的频率更高 (主一般是一个,从会有多个) 从通过负载均衡的方式让应用服务器进行访问
引入缓存 --> 冷热分离架构
把数据区进行 '冷热' ,热点数据放入缓存(在读写分离的基础上加入) --> 二八原则:20%数据能够支持80%的访问量 (Redis就是用作缓存)
垂直分库
引入分布式系统:不仅仅是为了能够应对更高的请求量(并发量),也是为了能够应对更大1的数据量
一台服务器已经存不下数据的情况 引入多个数据库服务器(存储集群 --> 每一个都是有主数据库和从数据库) --> 既可以分库,也可以分表(都是以业务为主)
业务拆分 --> 微服务
如果一个服务器里面做了很多业务,这样就会导致这个服务器的代码越来越复杂,为了方便代码的维护,就会将这个服务器进行拆分
让每个服务器功能更单一,服务器更小,服务器的种类和数量就增加了,此时就是微服务
本质上解决的是 '人' 的问题,减少了维护成本
缺点:
-
系统性能下降,功能之间更加依赖网络通信(只能引入更多的硬件资源)
-
系统复杂度提高,可用性受到影响,服务器更多了,出现问题的概率也会加大(丰富报警机制,做好监控系统)
优点:
-
解决人的问题
-
可以更方便与功能的复用
-
可以给不同的服务进行不同的部署
)
)