1.为何使用分布式系统?
1)由于单体应用:代码间关系复杂,难以理解和维护
项目体积变大,开发、测试、部署的过程都无比困难
无法使用新框架
可靠性下降
2)
设备激增,用户增多
功能更多,更新频繁,业务复杂度几何级增长
数据量趋于海量
系统稳定性要求更高,可用性要求极高
2.单体——》微服务架构:
一个单体应用拆分成多个服务,每个服务有自己独立的数据库
单个服务的复杂度降低
服务与服务之间需要通信,协调
3.微服务架构风格
微服务架构风格这种开发方法,是以开发一组小型服务的方式来开发一个独立的应用系统。其中每个小型服务都运行在自己的进程中,并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建,并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写,并且可以使用不同的数据存储技术。对这些微服务,我们仅做最低限度的集中管理。
4.分布式系统概念
分布式系统就是一组部署在同一个网络下的多个通过网络来通信和协调的组件,对外部而言表现的如同一个系统
分布式系统有多种层面的理解,比如,
- 可以指多个不同组件分布在网络上互相协作,比如前例所说的电商网站
- 也可以一个组件的多个副本组成集群,互相协作如同一个组件,比如数据存储服务中为了数据不丢失而采取的多个服务备份冗余,当数据修改时也需要通信来复制数据
所以:
- 微服务架构 是 分布式系统,分布式系统不一定是微服务架构
- 应用系统当中,这两种的集群模式都有出现
5.CAP
1.cap原理:1).Consistency 一致性:在分布式系统中的所有数据备份,在同一刻是否同样的值
2)Availability 可用性:在集群中一部分节点故障后,集群整体是否还能正常响应客户 端的读写请求。(高可用性:故障发生量小)
3)Partition tolerance 分区容错性:分区容错性是指 系统必须能够处理组件之间因为 通信失败(或者延迟)而造成分区的情况。通信 出现故障就会形成多个分区,此时系统无法同时 保证数据的一致性和可用性。(解决方案有两个 1.暂停或关闭所有节点,等待网络恢复,数据达 成一致,这样保证了数据一致性。2. 继续提供 服务,保证可用性,那么访问分区1和分区2、分 区3 得到的将会不同的数据,不满足一致性无论 使用哪一种方案,都无法保证CAP同时成立)
2.cap定理:CAP这三个指标无法同时满足。
6.BASE原理
1.Basically Available(基本可用)
2.Eventually consistent(最终一致性)
3.Soft state(软状态)
7.Spring-Cloud
概念:微服务架构工具集
项目技术选型
- 服务发现: nacos
- 负载均衡: ribbon
- 服务容错:sentinel
- 配置管理:nacos
- 服务调用:openfeign
- 服务网关: spring-cloud-gateway
- 分布式事务:seata
- 消息队列:rocketmq
- 搜索引擎: elasticsearch
- 服务追踪: zipkin
- 部署:docker + k8s