20240402
parent
366ac55e94
commit
8bd71be8de
|
|
@ -25,14 +25,26 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "markdown",
|
"type": "markdown",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "后端/极客时间Java实战/RPC.md",
|
"file": "日志检索.md",
|
||||||
|
"mode": "source",
|
||||||
|
"source": false
|
||||||
|
}
|
||||||
|
}
|
||||||
|
},
|
||||||
|
{
|
||||||
|
"id": "fcca90a4313bff23",
|
||||||
|
"type": "leaf",
|
||||||
|
"state": {
|
||||||
|
"type": "markdown",
|
||||||
|
"state": {
|
||||||
|
"file": "后端/极客时间Java实战/分布式服务容错.md",
|
||||||
"mode": "source",
|
"mode": "source",
|
||||||
"source": false
|
"source": false
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"currentTab": 1
|
"currentTab": 2
|
||||||
}
|
}
|
||||||
],
|
],
|
||||||
"direction": "vertical"
|
"direction": "vertical"
|
||||||
|
|
@ -98,7 +110,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "backlink",
|
"type": "backlink",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "后端/极客时间Java实战/RPC.md",
|
"file": "后端/极客时间Java实战/分布式服务容错.md",
|
||||||
"collapseAll": false,
|
"collapseAll": false,
|
||||||
"extraContext": false,
|
"extraContext": false,
|
||||||
"sortOrder": "alphabetical",
|
"sortOrder": "alphabetical",
|
||||||
|
|
@ -115,7 +127,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "outgoing-link",
|
"type": "outgoing-link",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "后端/极客时间Java实战/RPC.md",
|
"file": "后端/极客时间Java实战/分布式服务容错.md",
|
||||||
"linksCollapsed": false,
|
"linksCollapsed": false,
|
||||||
"unlinkedCollapsed": true
|
"unlinkedCollapsed": true
|
||||||
}
|
}
|
||||||
|
|
@ -138,7 +150,7 @@
|
||||||
"state": {
|
"state": {
|
||||||
"type": "outline",
|
"type": "outline",
|
||||||
"state": {
|
"state": {
|
||||||
"file": "后端/极客时间Java实战/RPC.md"
|
"file": "后端/极客时间Java实战/分布式服务容错.md"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|
@ -159,9 +171,15 @@
|
||||||
"command-palette:打开命令面板": false
|
"command-palette:打开命令面板": false
|
||||||
}
|
}
|
||||||
},
|
},
|
||||||
"active": "7abb266d201c3bb5",
|
"active": "fcca90a4313bff23",
|
||||||
"lastOpenFiles": [
|
"lastOpenFiles": [
|
||||||
|
"后端/极客时间Java实战/Dubbo服务端与客户端通信原理.md",
|
||||||
|
"后端/极客时间Java实战/分布式服务容错.md",
|
||||||
|
"后端/极客时间Java实战/Dubbo提供的各种服务引用机制.md",
|
||||||
|
"后端/极客时间Java实战/Zookeeper.md",
|
||||||
|
"未分类日志.md",
|
||||||
"日志检索.md",
|
"日志检索.md",
|
||||||
|
"后端/极客时间Java实战/Dubbo.md",
|
||||||
"后端/极客时间Java实战/RPC.md",
|
"后端/极客时间Java实战/RPC.md",
|
||||||
"后端/极客时间Java实战",
|
"后端/极客时间Java实战",
|
||||||
"VSCode 连接 云服务器.md",
|
"VSCode 连接 云服务器.md",
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,2 @@
|
||||||
|
高性能和透明化的RPC实现方案
|
||||||
|
SOA 服务治理 方案
|
||||||
|
|
@ -0,0 +1,15 @@
|
||||||
|
### Dubbo服务引用流程
|
||||||
|
|
||||||
|
### 本地接口 -> 远程调用
|
||||||
|
1. 导入服务提供者接口API和服务信息
|
||||||
|
2. 生成远程服务的本地动态代理对象 （这里的代理细节是什么）
|
||||||
|
5. 本地API调用转换成远程服务调用，返回调用结果
|
||||||
|
|
||||||
|
### Dubbo远程调用全流程
|
||||||
|
|
||||||
|
### 服务调用核心技术
|
||||||
|
- 回声测试
|
||||||
|
- 异步调用 -- 基于NIO
|
||||||
|
- 泛化调用（任意的制定方法，参数；不推荐）
|
||||||
|
|
||||||
|
###
|
||||||
|
|
@ -0,0 +1,11 @@
|
||||||
|
## Dubbo网络通信组件整体架构
|
||||||
|
|
||||||
|
### Remoting
|
||||||
|
- Exchange 信息交换层，用于封装请求-响应模式
|
||||||
|
- Transport 网络传输层，抽象Netty等框架作为统一的接口
|
||||||
|
- Serialize 序列化层，主要完成数据的序列化和反序列化
|
||||||
|
|
||||||
|
## Dubbo服务端通信机制解析
|
||||||
|
服务端通信的目的就是集成并绑定 `Netty` 服务从而启动服务监听，典型的多层架构
|
||||||
|
|
||||||
|
## Dubbo客户端通信机制解析
|
||||||
|
|
@ -0,0 +1,72 @@
|
||||||
|
## Dubbo 服务注册中心
|
||||||
|
### 注册中心基本模型
|
||||||
|
- 注册中心
|
||||||
|
- 服务提供者
|
||||||
|
- 通过注册中心客户端，向注册中心注册服务
|
||||||
|
- 服务消费者
|
||||||
|
- 通过注册中心客户端，从注册中心订阅服务
|
||||||
|
- 接收来自注册中心的变更通知
|
||||||
|
- 调用订阅的服务
|
||||||
|
- 本地保留订阅服务缓存，缓存需要和注册中心中的保持一致
|
||||||
|
|
||||||
|
### 注册中心核心功能：
|
||||||
|
- 支持对等集群：本身支持无状态的高可用
|
||||||
|
- 提供CURD接口 （不能理解这个点的curd访问的是什么内容）
|
||||||
|
- 订阅发布机制
|
||||||
|
- 变更通知机制
|
||||||
|
|
||||||
|
### dubbo注册中心功能
|
||||||
|
- 直连： 不使用注册中心
|
||||||
|
- 只发布（注册）
|
||||||
|
- 只订阅
|
||||||
|
- 支持不同的注册中心，(用得少)
|
||||||
|
|
||||||
|
### Dubbo支持的注册中心
|
||||||
|
- Nacos
|
||||||
|
- Zookeeper
|
||||||
|
- Multicast
|
||||||
|
- Redis
|
||||||
|
- Consul
|
||||||
|
- Etcd3
|
||||||
|
|
||||||
|
### Dubbo 中的注册中心的定义
|
||||||
|
通过回调函数实现异步通知
|
||||||
|
#### 注册中心构造类
|
||||||
|
- RegistryService
|
||||||
|
- AbstractRegistryFactory
|
||||||
|
- MulticastRegistryFactory
|
||||||
|
- NacosRegistryFactory
|
||||||
|
- ZookeeperRegistryFactory
|
||||||
|
|
||||||
|
#### Zookeeper注册中心结构
|
||||||
|
- Zookeeper
|
||||||
|
- Root -- dubbo
|
||||||
|
- Service -- 具体的服务定义
|
||||||
|
- Type -- 服务的类型 （消费者/提供者）
|
||||||
|
- URL -- 提供者(或消费者)的地址
|
||||||
|
- Provider -- 监听提供者的URL 层次
|
||||||
|
- Consumer -- 监听提供者的type层和消费者的URL层
|
||||||
|
- Monitor -- 监听Service层
|
||||||
|
|
||||||
|
## Zookeeper 功能特性
|
||||||
|
核心是一个精简的文件系统，提供基于目录节点(ZNode)树方式的数据存储，以及一些额外的抽象操作，如排序、通知和监控。本质上是一种分布式协调工具
|
||||||
|
### Zookeeper 访问特性
|
||||||
|
- 原子性访问
|
||||||
|
所有请求的处理结果在整个Zookeeper集群中所有机器是一致的
|
||||||
|
- 顺序访问
|
||||||
|
从同一个客户端发起的事务请求，会按照其发起顺序严格应用到Zookeeper
|
||||||
|
### Zookeeper操作模型
|
||||||
|
- Zookeeper 会话
|
||||||
|
- 操作
|
||||||
|
- TCP连接
|
||||||
|
- 发送请求
|
||||||
|
- 接受Watch事件
|
||||||
|
- 节点类型
|
||||||
|
- 临时 -- 建立连接创建，连接断开之后自动消失（会话结束自动删除）
|
||||||
|
- 持久
|
||||||
|
- Watch (基于会话，分布式环境下的回调函数)
|
||||||
|
- ZNode一旦变化，变更消息通过会话传回到客户端
|
||||||
|
- 客户端关注ZNode发生变化，当ZNode 的变化发生的时候，回调函数被调用
|
||||||
|
### Zookeeper 核心API
|
||||||
|
|
||||||
|
## 掌握Zookeeper作为注册中心的底层实现原理
|
||||||
|
|
@ -0,0 +1,59 @@
|
||||||
|
## 服务容错的基本概念
|
||||||
|
### 服务访问失败的原因
|
||||||
|
- 分布式固有特性 网络问题导致的间歇性的失败
|
||||||
|
- 服务自身失败 服务bug，修改
|
||||||
|
- 服务依赖失败 (会导致服务链路失败，雪崩效应)
|
||||||
|
|
||||||
|
#### 服务雪崩效应
|
||||||
|
- 服务A
|
||||||
|
- 服务B
|
||||||
|
- 服务C
|
||||||
|
- 服务D
|
||||||
|
- 服务E
|
||||||
|
- 上面提到的服务逐层依赖，当服务A不可用之后，服务B会不断重试，会导致自身资源耗尽，最后服务B也不可用；后面依赖服务B的那些服务也一样，这样会导致大量服务不可用，即雪崩效应。
|
||||||
|
- 解决办法，出现问题的服务，直接从集群中踢掉，避免雪崩的出现
|
||||||
|
#### 服务失败的解决思路
|
||||||
|
- 超时
|
||||||
|
- 如果服务未能在这个时间内响应，将回复一个失败消息
|
||||||
|
- 重试
|
||||||
|
- 为了降低网络瞬态异常所造成的网络通信问题，可以使用重试机制
|
||||||
|
|
||||||
|
#### 容错思想
|
||||||
|
- 集群容错
|
||||||
|
- 集群的建立已经满足冗余条件，而围绕如何进行重试就产生了集中常见的集群容错策略
|
||||||
|
- 集群容错
|
||||||
|
- 服务降级
|
||||||
|
- 对服务进行分级管理，必要时，关闭对不重要服务的访问入口，节省资源用于处理重要服务的请求
|
||||||
|
- 本地伪装和存根
|
||||||
|
|
||||||
|
## Dubbo集群容错
|
||||||
|
|
||||||
|
### 负载均衡基本概念
|
||||||
|
- 负载均衡的路由问题
|
||||||
|
- 分布式服务，在访问一个集群时，具体访问哪一个，的决策 --> 路由
|
||||||
|
- 负载均衡机制：
|
||||||
|
- Random：随机
|
||||||
|
- RoundRobin：轮询
|
||||||
|
- LeastActive: 最少活跃调用数
|
||||||
|
- ConsistentHash: 一致性Hash
|
||||||
|
### 容错机制
|
||||||
|
- Failover -- 失败转移；一个服务实例不可用，立即访问另一个服务实例，作为重试，会设置重试次数
|
||||||
|
- Failfast -- 直接抛异常，结束
|
||||||
|
- Failsafe -- 记录错误日志，退出，等查看日志，解决问题
|
||||||
|
- Failback -- 定时重试
|
||||||
|
- Forking --
|
||||||
|
- Broascast
|
||||||
|
|
||||||
|
### Dubbo容错策略使用方法
|
||||||
|
- cluster 配置项： 代表集群容错机制，可任选一种
|
||||||
|
- retries配置项： 重试次数，当调用发生失败时重新发起请求的次数
|
||||||
|
|
||||||
|
|
||||||
|
## 服务降级
|
||||||
|
- 本地伪装
|
||||||
|
- 当某个服务提供者全部失效后，客户端不抛出异常，而是通过Mock数据返回失败
|
||||||
|
- Mock类在服务消费者端配置
|
||||||
|
- 本地存根
|
||||||
|
- 服务的提供方也有在本地执行部分逻辑的场景 (例如原先校验参数，从而间接实现服务容错)
|
||||||
|
- Stub类在服务提供者端配置
|
||||||
|
|
||||||
|
|
@ -0,0 +1,14 @@
|
||||||
|
## tar 解压失败
|
||||||
|
```
|
||||||
|
gzip: stdin: not in gzip format
|
||||||
|
tar: Child returned status 1
|
||||||
|
tar: Error is not recoverable: exiting now
|
||||||
|
```
|
||||||
|
解决方法：[上链接](https://www.cnblogs.com/xqzt/p/5032865.html)
|
||||||
|
**注意：一定搞清楚文件的类型**
|
||||||
|
|
||||||
|
|
||||||
|
## 腾讯云访问github
|
||||||
|
腾讯云默认是访问不了github的，应该是因为墙的原因
|
||||||
|
解决办法：[上链接](https://www.cnblogs.com/redwei/p/16309106.html)
|
||||||
|
**注意：这里使用的方法是修改host，这种方法只能临时使用，后面需要进行修改**
|
||||||
Loading…
Reference in New Issue