1.介绍一些基本概念:
- 1.
响应时间:
- 指的是执行一个请求开始,到最后收到响应所花费的总体时间
- 2.
并发数:
- 指系统同时处理请求的数量
- 3.
并发连接数
:- 指的客户端向服务器端发送的请求,并建立Tcp连接的总数量。
- 请求数:也称之为
QPS
,指的每秒多少请求 - 并发用户数:单位时间内有多少用户
- 请求数:也称之为
- 指的客户端向服务器端发送的请求,并建立Tcp连接的总数量。
- 4.
吞吐量
:- 单位时间内系统处理请求的数量
- 5.
TPS:
- 指的是每秒的事务。所谓的事务并不是数据库中所谓的增删改查啥的。和那个没关系。这里指的是客户端发啊送请求,到服务端做出响应,再到客户端收到响应。这算一个事务。这个事务里面可能会包含很多次请求和很多连接。
综上:
QPS > 并发连接数 > TPS
2.大型互联网项目架构目标:
- 1.
高性能
:可以提供快速的访问体验 - 2.
高可用
:网站可以一直正常访问 - 3.
可伸缩
:就是通过硬件的增加或者减少,可以提高或降低处理能力 - 4.
高扩展
:系统间耦合性底,方便的通过新增或移除方式,增加或者减少新的功能模块 - 5.
安全性
:提供网站安全访问和数据加密,安全存储等策略 - 6.
敏捷性
:随需应变,快速响应。
3.系统的演变过程:
3.1.单体架构:
a.单体架构图:
- 单体架构就是将所有功能都集中在一个项目种进行开发,打成一个包部署
b.单体架构特点:
- 1.当网站流量很小时,只需一个应用,将所有功能都部署在一起,以减少部署节点和成本
- 2.这种结构,用于简化增删改查工作量的
数据访问框架(ORM)
是关键 - 3.适用于小型网站,小型管理系统,大部分web工程(前端页面,web层代码,service层代码,dao层代码)是将所有功能模块,打包到一起并放在一个web容器中
- 4.当用户访问
量增大的时候,可以通过扩展服务器来承载访问。但是每次扩展服务器都是连着整个应用一块扩展
c.单体架构优点:
- 1.所有的功能都集中在一个项目工程中,架构简单
- 2.项目结构简单,前期开发成本低,部署成本低,小型项目的首选
d.单体架构缺点:
- 1.全部功能集中在一个工程中,对于大型项目不易开发,扩展及其维护很难
- 2.系统性能的扩展只能通过扩展集群节点,成本高,有瓶颈
3.2.垂直架构:
a.垂直架构图:
b.垂直架构特点:
- 1.是指将单体架构中的多个模块拆分为多个独立的项目。形成多个独立的单体架构。
- 2.垂直架构存在的问题:重复功能太多。将来会有更多的模块aap1,app2,app3…appn。这种情况,各个
模块都会有一些共同的部分
,但是这种结构就造成了重复,存在大量重复模块
。
c.垂直架构优点:
- 1.项目架构简单,前期开发成本低,周期短,小型项目的首选。
- 2.通过垂直拆分,原来的单体项目不至于无限扩大,
不同的项目可采用不同的技术
。
d.垂直架构缺点:
- 1.全部功能集成在一个工程中,对于大型项目不易开发、扩展及维护。
- 2.系统性能扩展只能通过扩展集群结点,成本高、有瓶颈。
- 3.各个模块都会有
一些共同
的部分 ,但是这种结构就造成了大量重复模块的开发
3.3.分布式架构:
a.分布式架构的图
- 1.根据业务规则对系统进行拆分,每个业务模块作为独立的项目开发,称为一个服务
b.分布式架构特点:
- 1.所谓的分布式架构就像人的神经元一样,
彼此之间独立但又相互联系
- 2.分布式就是
根据业务功能对系统进行拆分
,每个业务模块
作为独立项目开发,称为一个服务 - 3.分布式是指
在垂直架构的基础上
,将公共业务模块抽取出来
,作为独立的服务供其他调用者消费,以实现服务的共享和重用
c.分布式架构的优点:
- 1.
增大系统容量
:- 我们的业务量越来越大,而要能应对越来越大的业务量,一台机器的性能已经无法满足了,我们需要多台机器才能应对大规模的应用场景。所以,
我们需要垂直或是水平拆分业务系统,让其变成一个分布式的架构
。
- 我们的业务量越来越大,而要能应对越来越大的业务量,一台机器的性能已经无法满足了,我们需要多台机器才能应对大规模的应用场景。所以,
- 2.
加强系统可用
:- 我们的业务越来越关键,需要提高整个系统架构的可用性,这就意味着架构中
不能存在单点故障
。这样,整个系统不会因为一台机器出故障而导致整体不可用。所以,需要通过分布式架构来冗余系统以消除单点故障,从而提高系统的可用性
;
- 我们的业务越来越关键,需要提高整个系统架构的可用性,这就意味着架构中
- 3.因为
模块化
,所以系统模块重用度更高 - 4.因为
软件服务模块被拆分,开发和发布速度可以并行而变得更
快,降低服务的耦合性 - 5.降低服务的耦合性,系统扩展性更高,有利于服务升级拓展
d.分布式架构的缺点:
- 1.服务提供方一旦产生变更,所有消费方都需要变更。比如一旦当E的IP地址,或者端口变化,那aap1,app2,app3…appn模块都要改变。
- 2.各服务模块不可以实时调节
- 3.架构设计变得复杂
- 4.多个服务的部署,其流程变得复杂
- 5.系统吞吐量大了,但是响应时间会变长
- 6.多元化的技术、服务的变多使得运维变得复杂
- 7.架构复杂导致学习曲线变大
- 8.测试和查错的复杂度增大
- 9.管理分布式系统中的服务和调度变得困难和复杂
e.分布式中需要考虑的问题:
- 1.
远程调用
:服务之间的互相调用 - 2.
服务发现
:A调用B,B上有好几台机器,那A调用哪台机器,分析这种问题 - 3.
负载均衡
:B中有好几个台机器,B上的机器有相同的功能,这就达到了负载均衡的目的 - 4.
服务容错
: - 5.
配置管理
:把配置放在配置中心 - 6.
服务监控
:实时监控每个服务运行状态 - 7.
链路追踪
: - 8.
日志管理
:整个项目的日志管理 - 9.
任务调度
:执行定时任务,定时任务怎一台机器执行还是所有机器都执行
f.基于这些问题的解决方案:
- 1.
在系统的分布式架构中有很多需要注意的问题
,针对这些问题就出现了ESB,Dubbo,微服务
等一些解决方案;
3.4.SOA架构:
a.SOA架构设计图:
b.SOA架构特点
- 1.SOA:(Service-Oriented Architecture,
面向服务的架构
)- SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和契约联系起来。
具有分布式,可重用,扩展灵活,松耦合的优点。
- SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和契约联系起来。
- 2.ESB:(Enterparise Servce Bus)
企业服务总线
,服务中介。- 主要是提供了一个服务于服务之间的交互。
- ESB包含的功能如:负载均衡,流量控制,加密 处理,服务的监控,异常处理,监控告急等等。
c.SOA优点:
- 1.抽取公共的功能为服务,提高开发效率
- 2.对不同的服务进行集群化部署解决系统压力
- 3.基于ESB/DUBBO减少系统耦合
d.SOA缺点:
- 1.抽取服务的粒度较大
- 2.服务提供方与调用方接口耦合度较高
3.5.微服务架构:
a.微服务架构图:
b.微服务架构概念
- 1.微服务架构是一种架构模式,提倡的是
将单一应用划分成一组小的服务
,服务与服务之间互相协调
,互相配合,从而为用户提供服务; - 2.每个服务都运行在独立的进程中,服务与服务之间使用轻量级的通信方式进行通信机制(通常为基于HTTP协议的RESTfulAPI)
- 3.每个服务围绕着具体的业务进行构建,可以独立部署在生产环境中部署
- 4.微服务架构是在 SOA上做的升华,微服务架构强调的一个重点是“
业务需要彻底的组件化和服务化
”,原有的单个业务系统会拆分为多个
可以独立开发、设计、运行
的小应用。这些小应用之间通过服务完成交互和集成
。 - 5.微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
c.微服务的优点:
- 1.
单一职责
:微服务拆分粒度更小,每一个服务都对应唯一的业务能力,做到单一职责,避免重复业务开发 - 2.
面向服务
:微服务对外暴露业务接口,服务之间使用轻量级HTTP交互
- 3.
自治
:团队独立、技术独立、数据独立、部署独立,服务去中心化
,各服务自治,服务可以使用不同的语言
,不同的存储技术进行开发 - 4.
隔离性强
:服务调用做好隔离、容错、降级,避免出现级联问题 - 5.通过服务的原子化拆分,以及微服务的独立打包、部署和升级,小团队的交付周期将缩短,运维成 本也将大幅度下降
- 6.微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。
d.微服务缺点:
- 1.架构非常复杂,运维、监控、部署难度提高
- 2.服务实现组件化:开发者
可以自由选择开发技术
。也不需要协调其他团队 - 3.服务之间
交互一般使用REST API
去中心化: - 4.每个微服务有
自己私有的数据库持久化
业务数据 - 5.自动化部署:把应用拆分成为一个一个独立的单个服务,方便自动化部署、测试、运维
e.微服务技术对比:
- 1.微服务这种方案需要技术框架来落地,国内流行的就是有:
Dubbo和SpringCloud以及SpringCloudAlibaba
- 2.三种技术的对比:
4.集群架构、分布式架构区别:
4.1.基本概念:
- 1.
集群的概念
:- 集群就是很多人干一样的事情
- 2.
分布式概念
:- 就是很多人干不一样的事情,事情合起来后就是一件完整的大事。
- 也就是说是若干独立计算机的集合,这些计算机对于用户来说就像单个相关系统;
- 分布式系统(distributed system)是
建立在网络之
上的软件系统。
6.服务的远程调用介绍:
6.1.什么是远程调用技术:
- 1.在微服务架构中,通常存在多个服务之间的远程调用的需求。
- 2.远程调用通常包含两个部分:序列化和通信协议
- 3.常见的序列化协议
包括json、xml、hession、protobuf、thrift、text、bytes
等 - 4.目前主流的远程调用技术有
基于HTTP的RESTful接口
以及基于TCP的RPC协议
6.2.RPC相关介绍:
a.什么是RPC:
- 1.RPC【Remote Procedure Call】是指
远程调用过程
,是一种进程间通信方式
,他是一种技术的思想
,而不是规范
- 2.它允许程序调用另一个地址空间(通常是共享网络的另一台机器上)的过程或函数,而不用程序员显式编码这个远程调用的细节。.即程序员无论是调用本地的还是远程的函数,本质上编写的调用代码基本相同
- 3.有非常多的协议和技术来都实现了RPC的过程。比如:
HTTP REST风格
,Java RMI规范
,WebService SOAP协议
、Hession等
- 4.比如:当 A调用了B里面的方法,但是这两个方法不在同一台服务器上。所以A-B之间的通讯是出现了以下的过程。而RPC指的就是这个
小助手
- 5.综上来看:
RPC两个核心模块应该是:怎么样建立更快的通讯,怎么样更快的序列化
6.3.RESTful相关介绍:
a.RESTful:
- 1.REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 REST 原则是:
客户端和服务器之间的交互在请求之间是无状态的
。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启,客户端不会得到通知。此外,无状态请求可以由任何可用服务器回答,这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。 - 2.在服务器端,应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体,它向客户端公开。资源的例子有:应用程序对象、数据库记录、算法等等。每个资源都使用 URI (Universal Resource Identifier) 得到一个唯一的地址。所有资源都共享统一的接口,以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法,比如 GET、PUT、POST 和DELETE。
- 3.在 REST 样式的 Web 服务中,每个资源都有一个地址。资源本身都是方法调用的目标,方法列表对所有资源都是一样的。这些方法都是标准方法,包括 HTTP GET、POST、PUT、DELETE,还可能包括 HEAD 和 OPTIONS。简单的理解就是,如果想要访问互联网上的资源,就必须向资源所在的服务器发出请求,请求体中必须包含资源的网络路径,以及对资源进行的操作(增删改查)。
b.
REST(Representational State Transfer),表现性状态转换,它是一种软件架构风格。
根据REST风格对资源进行访问称为RESTful。
按照REST风格访问资源时使用请求方式区分对资源进行了何种操作。
http://localhost/users 查询全部用户信息 GET(查询)
http://localhost/users/1 查询指定用户信息 GET(查询)
http://localhost/users 添加用户信息 POST(新增/保存)
http://localhost/users 修改用户信息 PUT(修改/更新)
http://localhost/users/1 删除用户信息 DELETE(删除)
6.4.RESTful与RPC比较:
7.分布式中的CAP:
7.1.CAP原理:
- Consistency(一致性):数据一致更新,所有数据的
变化都是同步
的 - Availability(可用性):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求
- Partition tolerance(分区容忍性):
某个节点的故障,并不影响整个系统
的运行
7.2.CAP最大特点:
- 通过学习CAP理论,我们得知任何分布式系统
只可同时满足二点,没法三者兼顾
,既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点,所以我们就需要抛弃一样: