微服务
2022-04-09 07:14:21 2 举报AI智能生成
springcloud微服务知识点
作者其他创作
大纲/内容
核心类serviceconfig，export暴露服务，referenceconfig引用配置，初始化时创建服务代理
dubbo协议使用长连接，hessian序列化，底层使用netty传输数据
spi机制，生成通用adpative代码，方法通过extensionloader根据URL的参数动态获取实现类
Dubbo
RPC
每30秒刷新缓存（服务拉取）
每30秒发送心跳（服务续约）
client和server交互时，只会与其中的一个server进行交互
客户端
每1分钟剔除过期注册信息
每10分钟更新集群节点数据
每15分钟更新续约数及阈值
Renews threshold：Eureka Server 期望每分钟收到客户端实例续约的总数
Renews (last min)：Eureka Server 最后 1 分钟收到客户端实例续约的总数
默认阈值比例是0.85
自我保护机制：通过阈值（服务续约数）判断，续约数超过阈值是client端的问题直接剔除服务，少于阈值则判断是server端的问题，不直接剔除服务
服务端
server初始化时，会根据配置节点信息生成与其他的server同步的客户端
server接收到client的服务请求时，会把请求同步发送到配置的server节点，同步只会传播一次，通过header里的参数判断请求时来自client还是server
节点同步
Eureka
-server ： 定义agent运行在server模式
-bootstrap-expect ：在一个datacenter中期望提供的server节点数目，当该值提供的时候，consul一直等到达到指定sever数目的时候才会引导整个集群，该标记不能和bootstrap共用
-bind：该地址用来在集群内部的通讯，集群内的所有节点到地址都必须是可达的，默认是0.0.0.0
-node：节点在集群中的名称，在一个集群中必须是唯一的，默认是该节点的主机名
-ui-dir： 提供存放web ui资源的路径，该目录必须是可读的
-rejoin：使consul忽略先前的离开，在再次启动后仍旧尝试加入集群中
-config-dir：配置文件目录，里面所有以.json结尾的文件都会被加载
-client：consul服务侦听地址，这个地址提供HTTP、DNS、RPC等服务，默认是127.0.0.1所以不对外提供服务，如果你要对外提供服务改成0.0.0.0
-join ：加入到集群中
-data-dir 指定agent储存状态的数据目，对于server尤其重要，因为他们必须持久化集群的状态
启动
设置key valueconsul kv put user/config/connections 5
根据key获取valuekv get -detailed user/config/connections
存储K/V
注册服务
发现服务
服务
Consul
leader、follower、observer三种角色，zab协议两种模式：恢复模式和广播模式
czxid：该数据节点被创建时的事务id。
mzxid：该节点最后一次被更新时的事务id。
ctime：节点被创建时的时间。
mtime：节点最后一次被更新时的时间。
version：这个节点的数据变化的次数。
cversion：这个节点的子节点 变化次数。
aversion：这个节点的ACL变化次数。
ephemeralOwner：如果这个节点是临时节点，表示创建者的会话id。如果不是临时节点，这个值是0。
dataLength：这个节点的数据长度。
numChildren：这个节点的子节点个数
节点stat
zookeeper
配置模块的30秒长轮询，引起的频繁GC
基于HTTP连接模型，TIME_WAIT状态连接过多
心跳续约感知服务变化，时延长
心跳数量多，导致TPS高
1.0
使用grpc长连接，解决1.0的问题
流式推送更可靠，吞吐更高
结构复杂，需要管理连接状态
可观测性降低，通信内容变为二进制
2.0
nacos
服务注册
服务发现
服务健康检查
多租户管理
集群高可用以及数据一致性
功能点
注册中心
阻塞多线程处理
zuul
基于netty的多路复用
predicate，断言用于规则匹配
filter用户请求前后的处理
gateway
服务路由
限流
统一验证
网关
线程池使用单独的线程池调用远程服务与原请求线程分离，涉及线程上下文切换，开销比较大
信号量，调用远程服务与请求线程为同一线程
资源隔离方式
hytrix
sentinel
服务降级
熔断器
配置数据存储在git上
配置实时刷新依赖git的webhook
springcloud config
数据存储在数据库中
支持配置实时推送
分支主题
提供配置获取接口
提供配置推送接口
服务于Apollo客户端
集成eureka服务
集成metaserver
ConfigService
提供配置管理接口
提供配置修改发布接口
服务于管理界面Portal
AdminService
通过MetaServer获取AdminService的服务列表
使用客户端软负载SLB方式调用AdminService
Portal\t配置管理界面
为应用获取配置，支持实时更新
通过MetaServer获取ConfigService的服务列表
使用客户端软负载SLB方式调用ConfigService
Client
核心模块
用于服务发现和注册
Config/AdminService注册实例并定期报心跳
和ConfigService住在一起部署
Portal通过域名访问MetaServer获取AdminService的地址列表
Client通过域名访问MetaServer获取ConfigService的地址列表
相当于一个Eureka Proxy
逻辑角色，和ConfigService住在一起部署
MetaServer
和域名系统配合，协助Portal访问MetaServer获取AdminService地址列表
和域名系统配合，协助Client访问MetaServer获取ConfigService地址列表
和域名系统配合，协助用户访问Portal进行配置管理
NginxLB
辅助模块
每个应用的唯一的身份标识
application (应用)
应用处于哪个环境，从而可以去获取应用的配置
environment (环境)
一个应用下不同实例的分组，比如典型的可以按照数据中心分
cluster (集群)
一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件
namespace (命名空间)
配置概念
apollo
配置中心
配置类LoadBalancerAutoConfiguration
创建了一个LoadBalancerInterceptor的Bean，用于实现对客户端发起请求时进行拦截，以实现客户端负载均衡
创建了一个RestTemplateCustomizer的Bean，用于给RestTemplate增加LoadBalancerInterceptor拦截器
维护了一个被@LoadBalanced注解修饰的RestTemplate对象列表，并在这里进行初始化，通过调用RestTemplateCustomizer的实例来给需要客户端负载均衡的RestTemplate增加LoadBalancerInterceptor拦截器
ribbon
负载均衡策略
FeignClientsConfigurationFeignRibbonClientAutoConfiguration
FeignClientFactoryBean
程序启动后通过包扫描，当类有@FeignClient注解，将注解的信息取出，连同类名一起取出，赋给BeanDefinitionBuilder，然后根据BeanDefinitionBuilder得到beanDefinition，最后beanDefinition式注入到ioc容器中
注入bean之后，通过jdk的代理，当请求Feign Client的方法时会被拦截，代码在ReflectiveFeign类
在SynchronousMethodHandler类进行拦截处理，当被FeignClient的方法被拦截会根据参数生成RequestTemplate对象
首先通过@EnableFeignCleints注解开启FeignCleint
根据Feign的规则实现接口，并加@FeignCleint注解
程序启动后，会进行包扫描，扫描所有的@ FeignCleint的注解的类，并将这些信息注入到ioc容器中。
当接口的方法被调用，通过jdk的代理，来生成具体的RequesTemplate
RequesTemplate在生成Request
Request交给Client去处理，其中Client可以是HttpUrlConnection、HttpClient也可以是Okhttp，LoadBalancerFeignClient
最后Client被封装到LoadBalanceClient类，这个类结合类Ribbon做到了负载均衡
实现流程
openfeign
随机，按权重设置随机概率
Random LoadBalance
轮循，按公约后的权重设置轮循比率
RoundRobin LoadBalance
最少活跃调用数，相同活跃数的随机，活跃数指调用前后计数差
LeastActive LoadBalance
一致性 Hash，相同参数的请求总是发到同一提供者
ConsistentHash LoadBalance
负载均衡
elastic-job
支持自定义任务失败重试次数，当任务失败时将会按照预设的失败重试次数主动进行重试
失败重试
忽略：调度过期后，忽略过期的任务，从当前时间开始重新计算下次触发时间；
立即执行一次：调度过期后，立即执行一次，并从当前时间开始重新计算下次触发时间；
调度过期
FIRST（第一个）：固定选择第一个机器
LAST（最后一个）：固定选择最后一个机器
ROUND（轮询）
RANDOM（随机）：随机选择在线的机器
CONSISTENT_HASH（一致性HASH）
LEAST_FREQUENTLY_USED（最不经常使用）：使用频率最低的机器优先被选举；
LEAST_RECENTLY_USED（最近最久未使用）：最久未使用的机器优先被选举；
FAILOVER（故障转移）：按照顺序依次进行心跳检测，第一个心跳检测成功的机器选定为目标执行器并发起调度；
BUSYOVER（忙碌转移）：按照顺序依次进行空闲检测，第一个空闲检测成功的机器选定为目标执行器并发起调度；
SHARDING_BROADCAST(分片广播)：广播触发对应集群中所有机器执行一次任务，同时系统自动传递分片参数；可根据分片参数开发分片任务；
路由策略
调度器服务
每个执行器对每个jobid启用单独的JobThread执行任务，
单机串行（默认）：调度请求进入单机执行器后，调度请求进入FIFO队列并以串行方式运行；
丢弃后续调度：调度请求进入单机执行器后，发现执行器存在运行的调度任务，本次请求将会被丢弃并标记为失败；
覆盖之前调度：调度请求进入单机执行器后，发现执行器存在运行的调度任务，将会终止运行中的调度任务并清空队列，然后运行本地调度任务；
阻塞策略
支持自定义任务超时时间，任务运行超时将会主动中断任务
任务执行超时
执行器服务
xxl-job
定时任务
失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟
Failover Cluster
快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录
Failfast Cluster
失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作
Failsafe Cluster
失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作
Failback Cluster
并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数
Forking Cluster
广播调用所有提供者，逐个调用，任意一台报错则报错 。通常用于通知所有提供者更新缓存或日志等本地资源信息
Broadcast Cluster
容错
号段模式，利用数据库存储，一次批量提取一个号段
leaf算法，workid基于zookeeper或数据库生成顺序id
雪花算法
分布式ID
Drools
easy-rules
QLExpress
规则引擎
squirrel
状态机引擎
同步更新失败、异步更新
增加重试、补偿任务、最终一致
先更新数据库，再删除缓存，可以满足大部分的场景
先删除缓存，再更新数据库，延迟1秒再删除缓存
缓存不一致
缓存里没有，数据库里也没有的数据
空对象缓存、布隆过滤器
缓存穿透
缓存里没有，数据库里有，引起大量请求更新缓存
互斥更新，保证少量请求到数据库重建缓存，可以用本地锁或分布式锁
缓存击穿
缓存中数据大批量到过期时间，而查询数据量巨大，引起数据库压力过大
本地缓存+快速失败熔断、主从模式或集群模式保证高可用、差异失效时间、热点数据永不过期、加锁或队列
缓存雪崩
利用双向链表和哈希表存储，借助哈希表快速查询数据，再利用链表快速插入头部和删除
LRU
同样利用哈希表和双向链表存储，利用一个哈希表以频次为key存储链表数据，来实现使用频率的链表存储
LFU
缓存淘汰策略
应用本地缓存
读写分离，路由到不同的从节点读取
热点key
缓存
补偿性TCC：try阶段锁定资源类似资金冻结、confirm扣除资金、cancel解冻资金
异步确保型，最大努力通知型
一阶段执行SQL，生成数据快照，锁定数据
二阶段将保存的快照数据和行锁删掉
AT模式
seta
参与者将操作成败通知协调者，再由协调者根据所有参与者的反馈情报决定各参与者是否要提交操作还是中止操作
两个阶段是指：第一阶段：准备阶段(锁定资源)和第二阶段：提交阶段（执行阶段）
同步阻塞，执行过程中，所有参与节点都是事务阻塞型的
协调者挂机导致参与者阻塞，一旦协调者发生故障，参与者就会处于阻塞状态
数据不一致，在二阶段提交的阶段中，当协调者向参与者发送commit请求之后，发生了局部网络异常或者在发送commit请求过程中协调者发生了故障，这回导致只有一部分参与者接受到了commit请求。而在这部分参与者接到commit请求之后就会执行commit操作。但是其他部分未接到commit请求的机器则无法执行事务提交。于是整个分布式系统便出现了数据部一致性的现象
缺点
2PC
引入超时机制。同时在协调者和参与者中都引入超时机制
在第一阶段和第二阶段中插入一个准备阶段。保证了在最后提交阶段之前各参与节点的状态是一致的
三阶段提交有CanCommit、PreCommit、DoCommit三个阶段
3PC
与TCC一样是补偿型事务，没有try直接commit，适用于业务流程长、多的业务
Saga
事务
提交代码频繁出现大量冲突
小功能要积累到大版本才能上线，上线开总监级别大会
横向扩展流程复杂，主要业务和次要业务耦合
拆分时机
多语言支持、环境可移植性、快速启动
微软的dapr
分布式运行时
spiffe
可信安全
SOA强调按水平架构划分为：前、后端、数据库、测试等
微服务强调按垂直架构划分，按业务能力划分，每个服务完成一种特定的功能，服务即产品
架构划分不同
SOA应用倾向于使用统一的技术平台来解决所有问题
微服务可以针对不同业务特征选择不同技术平台，去中心统一化，发挥各种技术平台的特长
技术平台选择不同
SOA架构强调的是异构系统之间的通信和解耦合（一种粗粒度、松耦合的服务架构）
微服务架构强调的是系统按业务边界做细粒度的拆分和部署
系统间边界处理机制不同
SOA架构，主要目标是确保应用能够交互操作
微服务架构，主要目标是实现新功能、并可以快速拓展开发团队
主要目标不同
soa和微服务区别
proposer
acceptor
learner
角色
prepare阶段，proposer提出一个议案，编号为N，请求acceptors的quorum接受
promis阶段，如果N大于此acceptor之前接受的提案编号则接受否则拒绝
accept阶段，proposer获得多数人支持，则发出accept请求以及提案编号N及内容
accepted阶段，acceptor在此期间没有接受到大于编号N的提案，则接受N号提案，否则忽略
阶段
basic paxos
leader
去除prepare阶段
muti paxos
candidate
follower
保证日志连续性，没有日志空洞
一个leader的周期称为term
心跳由leader发往follower
raft
一个leader的周期称为epoch
心跳由follower发往leader
zab
Basic Paxos每个副本都能提议，可用性高，但因为竞争冲突导致效率低下；Multi-Paxos选举Leader避免冲突，提高效率，但同时又引入了Leader瓶颈，降低了可用性
一致性算法
slf4j-api
日志
媒体类型的版本控制
自定义Header
URI路径
请求参数控制
restapi版本控制
其他
一个 topic，一个 partition，一个 consumer，内部单线程消费，单线程吞吐量太低，一般不会用这个
写 N 个内存 queue，具有相同 key 的数据都到同一个内存 queue；然后对于 N 个线程，每个线程分别消费一个内存 queue 即可，这样就能保证顺序性
保证消息的顺序性
kafka
Ledger：它是 BK 的一个基本存储单元（本质上还是一种抽象）
Fragment：BK 的最小分布单元（实际上也是物理上的最小存储单元），也是 Ledger 的组成单位，默认情况下一个 Ledger 会对应的一个 Fragment（一个 Ledger 也可能由多个 Fragment 组成）
Entry：每条日志都是一个 Entry，它代表一个 record
bookkeeper
pulsar
消息队列
需要运用技术手段抵抗大流量的冲击，能让流量更平稳的被系统所处理，带给用户更好的体验
体现系统并行处理能力，在有限的硬件投入下，提高性能意味着节省成本
高性能
系统可以正常服务的时间
高可用
流量高峰时能否在短时间内完成扩容
高扩展
目标
平均响应时间
TP90、TP99等分位值
吞吐量
TPP99应该控制在200毫秒以内，TP999应该控制在1秒以内
性能指标
SLA
可用性指标
扩展性=性能提升比例/机器增加比例，通常维持在70%以上
需要考虑有状态服务的扩展性，数据库、缓存和消息中间件、负载均衡、带宽、依赖的第三方服务都会成为扩展的瓶颈点
可扩展性指标
指标
提升单机处理能力
提升单机的硬件性能
提升单机的软件性能
纵向扩展
做好分层架构
各层进行水平扩展
横向扩展
集群部署
多级缓存
分库分表和索引优化
考虑NoSQL数据库的使用
异步化，将次要流程通过多线程、MQ、甚至延时任务进行异步处理
限流，包括前端限流、反向代理层的限流、后端服务限流
对流量进行削峰填谷，通过MQ承接流量
并发处理，通过多线程将串行逻辑并行化
预计算
缓存预热
减少IO次数，数据库和缓存的批量读写，批量接口的支持
减少IO时的数据包大小，减少接口的多余字段、减少缓存key的大小
程序逻辑优化
各种池化技术的使用和大小设置，包括线程池、连接池
JVM优化，减少GC频率和耗时
锁选择
数据异构，通过消息队列机制接收数据变更，原子化存储
数据闭环， 屏蔽多从数据来源，将数据异构存储，形成闭环
服务化演进:，进程内服务-单机远程服务-集群手动注册服务-自动注册和发现服务-服务的分组、隔离、路由-服务治理
考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等
系统维度：按照系统功能、业务拆分，如购物车，结算，订单等
功能维度：对系统功能在做细粒度拆分
读写维度：根据读写比例特征拆分；读多，可考虑多级缓存；写多，可考虑分库分表
模块维度：对整体代码结构划分Web、Service、DAO
拆分
降级处理，保证核心业务，牺牲非核心业务
限流处理
切流量
对等节点的故障转移
非对等节点的故障转移
接口层面的超时设置、重试策略和幂等设计
MQ消息的可靠性保证，producer端的重试机制，broker的持久化，consumer端的ACK机制
灰度发布
监控告警
灾备演练
可回滚
合理的分层架构
存储层的拆分
业务层的拆分
方案
高并发
让系统在一定的负载压力下进行正常的工作，观察系统的表现能否满足用户的需求
负载测试
通过对系统极端加压，观察系统表现出来的性能问题，对性能问题进行分析优化
压力测试
验证系统的并发能力，确定系统是否满足设计的并发需要
并发测试
需要有一个基准点，用以判断新模块对整个软件系统的性能影响
基准测试
长时间的负载测试，确定系统的稳定性
稳定性测试
测试系统能否快速从错误状态中恢复正常
可恢复性测试
系统上下游的全链路压力测试与稳定性测试方式
全链路测试
性能测试
snout
sysdig，相当于strace+tcpdump+isof+htop+iftop以及其他工具的合集
sar，可以记录和分析历史数据的工具
perf，linux cpu、memory性能分析工具
load averages
uptime
kernel errors
dmesg|tail
overall stats by time
vmstat l
cpu balance
mpstat -P ALL l
process usage
pidstat l
disk I/O
iostat -xz l
memory usage
free -m
network I/O
sar -n DEV l
TCP stats
check overview
top
十大常用调试工具
容器测试工具
测试
最底层的存储单元是Object对象，每个Object包含元数据和原始数据
Object
Object Storage Device，也就是负责响应客户端请求返回具体数据的进程
OSD
Placement Grouops，是一个逻辑的概念，一个PG包含多个OSD
PG
一个Ceph集群需要多个Monitor组成的小集群，它们通过Paxos同步数据，用来保存OSD的元数据
Monitor
Librados是Rados提供库
Librados
Ceph Metadata Server，是CephFS服务依赖的元数据服务
MDS
基础组件
RADOS block device，是Ceph对外提供的块设备服务
RBD
RADOS gateway，是Ceph对外提供的对象存储服务，接口与S3和Swift兼容
RGW
Ceph File System，是Ceph对外提供的文件系统服务
CephFS
Ceph
分布式存储
微服务
0 条评论
回复 删除
下一页
