微服务复习

已于 2022-02-28 14:09:57 修改
阅读量218 收藏
点赞数
文章标签： 微服务 java spring boot
于 2021-07-22 01:13:46 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/qq_31649521/article/details/112861466
版权

分布式解决方案

XA规范：分布式事务规范，定义了分布式事务模型

四个角色：事务管理器(协调者TM),资源管理器(参与者RM),应用程序AP，通信资源管理器（crm）

每次begin事务开始之后commit事务结束进行一个事务，在commit之前做一个发送其他节点通信的操作，给每一个rm一个txid，单节点的话sql没问题就提交

第一个阶段：每个参与者执行本地事务但不提交，进入ready状态，并通知协调者已经准备就绪

第二个阶段：当协调者确认每个参与者ready后，通知参与者进行commit操作，如果有参与者fail，则发送rollfack命令，各参与者做回滚

第三个阶段：主要是针对两阶段的优化，解决了2pc单点故障的问题，但是性能问题和不一致问题仍然没有根本解决，如果挂掉的话各自有各自的超时机制，然后执行这个提交动作，不会一直阻塞在这里

出现问题

单点故障：一旦事务管理器出现故障，整个系统不可用

数据不一致，响应时间长，不确定性

tcc

springcloud熔断策略？

通过后台配置，配置到每一个接口，能够支持到每一个接口的案例，每个案例的每个接口降级，配置一个开关，没次新增一个案例就添加一个案例，目前没有实现自动化。

springboot是怎么做到简化配置的？

主要是@EnableAutoConfiguration这个注解起的作用，这个注解是间接隐藏在springboot的启动类注解@SpringBootApplication中。

通过这个注解，SpringApplication.run(…)的内部就会执行selectImports()方法，寻找 META-INF/spring.factories文件，读取里面的文件配置，将事先已经写好的自动配置类有选择地加载到Spring容器中，并且能按照约定的写法在application.properties中配置参数或开关。

为什么要用 Dubbo？

随着项目需要使用的服务越来越多，服务之间的关系也越来越复杂，于是对这些服务也因此衍生出了一系列相应的技术，比如服务提供，服务调用，连接处理，通信协议，服务发现，服务路由，日志输出等行为，需要把这些技术进行封装和管理这些技术，所以dubbo就出现了

springcloud和dubbo的区别？

它们两个的底层原理都是类似的，dubbo中的二进制性能比http的性能更好一些，他俩底层都是rpc，经过深度优化的RPC框架对于性能和处理并发能力是更好一些的，但是现在很多中小型企业而言dubbo一次请求10ms，springCloud请求一次是20ms，对很多中小型公司而言，性能，并发不是最主要的因素，而springCloud这套架构原理，走http接口和http请求，就足够性能和并发的需求了，没必要使用高度优化的rpc服务框架

springCloud安全性相对比dubbo安全性高一些

dubbo最开始的一个定位只是单纯的一个服务框架而已，类似配置网关这种还得选择一些其他技术不提供其他的功能

而springclod这个框架中小型公司用的特别多，它主打的微服务架构，组件齐全，功能齐全，网关直接提供，分布式配置中心，

授权认证，服务调用链路追踪，资源隔离，熔断降级，服务请求qps监控，契约测试，zk封装

用springCloud优势在于功能齐全，中小型公司开箱即用，直接满足系统中的开发需求

springCloud配置消费者提供者直接通过注解就可以实现配置，而dubbo是需要在xml里面进行配置消费者和提供者

springcloud组件有哪些？

服务发现——Netflix Eureka     客服端负载均衡——Netflix Ribbon    断路器——Netflix Hystrix    服务网关——Netflix Zuul       分布式配置——Spring Cloud Config     

链路追踪----springcloud sleuth：a服务查b服务查c服务，查一个完整的链路

服务网关----gateway：接口鉴权处理，路由转发，权限校验，限流控制，过滤器

springcloud断路器的作用

他针对对报错有一个阈值，开关，断开了以后他就不会调用你这个接口的实现，它会调用你默认的一个方法，像电路一个开关，你达到这个值得时候会自动断开

举个例子： 当一个服务调用另一个服务由于网络原因或者自身原因出现问题时 调用者就会等待被调用者的响应 当更多的服务请求到这些资源时

 导致更多的请求等待 这样就会发生连锁效应（雪崩效应） 断路器就是解决这一问题

断路器有完全打开状态

 一定时间内 达到一定的次数无法调用 并且多次检测没有恢复的迹象 断路器完全打开，那么下次请求就不会请求到该服务

 半开

        短时间内 有恢复迹象 断路器会将部分请求发给该服务 当能正常调用时 断路器关闭

  关闭

         当服务一直处于正常状态 能正常调用 断路器关闭

Eureka和zookeeper的区别？

Zookeeper保证CP

        当向注册中心查询服务列表时，我们可以容忍注册中心返回的是几分钟以前的注册信息，但不能接受服务直接down掉不可用。也就是说，服务注册功能对可用性的要求要高于一致性。但是zk会出现这样一种情况，当master节点因为网络故障与其他节点失去联系时，剩余节点会重新进行leader选举。问题在于，选举leader的时间太长，30 ~ 120s, 且选举期间整个zk集群都是不可用的，这就导致在选举期间注册服务瘫痪。在云部署的环境下，因网络问题使得zk集群失去master节点是较大概率会发生的事，虽然服务能够最终恢复，但是漫长的选举时间导致的注册长期不可用是不能容忍的。

Eureka保证AP

        Eureka看明白了这一点，因此在设计时就优先保证可用性。Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时如果发现连接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况：

  • Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
  • Eureka仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
  • 当网络稳定时，当前实例新的注册信息会被同步到其它节点中

因此， Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使整个注册服务瘫痪。

Hystrix如何实现线程隔离？

Hystrix通过命令模式，将每个类型的业务请求封装成对应的命令请求，比如查询订单->订单Command，查询商品->商品Command，查询用户->用户Command。每个类型的Command对应一个线程池。创建好的线程池是被放入到ConcurrentHashMap中

maven命令？

maven package：会将jar包打包到target下

maven install：将jar包装载到maven仓库，供其他项目使用

springCloud工作原理

Eureka的工作流程表

轮回阿旭
关注
RT-DETR训练自己的数据集（从代码下载到实例测试）
Limiiiing的博客
09-14 1万+
在Windows10上配置CUDA环境教程是百度提出的一种实时目标检测模型。RT-DETR采用了与DETR相同的编码器和解码器结构，但对其进行了大量的优化，在保持较高检测精度的同时，实现了实时目标检测，为目标检测领域提供了一种新的有效解决方案，具有广泛的应用前景，如自动驾驶、智能监控、机器人等领域。以上是RT-DETR官方的论文和代码，详细介绍了RT-DETR的构成和实现。在YOLOv10中也实现了RT-DETR的代码，所以本文使用YOLOv10的项目文件进行RT-DETR的训练和测试。YOLOv10。
RT-DETR改进策略【Neck】| SEAM：分离和增强注意模块，解决复杂场景下的小目标遮挡问题
最新发布
Limiiiing的博客
04-17 274
本文记录的是利用 SEAM 模块优化 RT-DETR 的目标检测网络模型。的设计出发点在于解决复杂场景下的人脸遮挡问题，相当于是小目标被其他物体部分遮挡时，传统方法因特征缺失导致检测精度下降的问题。该模块通过增强未遮挡区域的特征响应并补偿被遮挡区域的信息损失，提升模型对遮挡小目标的检测能力。YOLO-FaceV2: A Scale and Occlusion Aware Face DetectorSEAM模块（Separated and Enhancement Attention Module）的设计出发点
RT-DETR代码详解（官方pytorch版）——参数配置（1）
小小老大MUTA的博客
01-07 6132
RT-DETR代码详解（官方pytorch版）参数配置
RT-DETR论文解读与代码
qq_52053775的博客
06-15 5625
目前以大名鼎鼎的YOLO为代表的基于CNN的实时监测网络需要NMS进行后处理，导致不能很好的优化网络，并且网络不够健壮，从而导致检测器的推理速度出现延迟。研究者也分析了Anchor-based和Anchor-free的YOLO的性能，发现Anchor并不是影响实时监测的关键要素，而NMS后处理彩色。DETR很好的解决了后处理对于模型的限制，却受限于Transformer巨大的计算量，无法发挥实时监测性。因此，作者想要重构detr,使其具有实时性。
RT-DETR改进策略【模型轻量化】| 替换骨干网络 CVPR-2024 RepViT 轻量级的Vision Transformers架构
Limiiiing的博客
12-03 449
一、本文介绍 本文记录的是基于RepVit的RT-DETR轻量化改进方法研究。RepVit的网络结构借鉴ViT的设计理念，通过分离的token mixe和channel mixer减少推理时的计算和内存成本，同时减少扩展比率并增加宽度，降低延迟，并通过加倍通道来弥补参数大幅减少的问题，提高了准确性。本文在替换骨干网络中配置了原论文中的repvit_m0_9、repvit_m1_0、repvit_m1_1、repvit_m1_5和repvit_m2_3五种模型，以满足不同的需求。 模型 参数量 计算量
RT-DETR模型源码解析
weixin_58429528的博客
08-07 1011
"""目的是将特定的函数（如 to(), cpu(), cuda(), half(), float() 等）应用到模型的张量上，但这些张量不能是模型的参数或已注册的缓冲区。'''举个例子，如果args = {'imgsz': 416, 'data': 'coco128.yaml', 'task': 'detect', 'batch_size': 8}，这里有一个明显的错误，'grfc' 很可能是一个拼写错误，应该是 'grpc'，这是一种常用于微服务架构的通信协议。
RT-DETR部分源码解析
weixin_58429528的博客
08-07 790
RT-DETR源码解析
RT-DETR详解之 Decoder 层
pengxiang1998的博客
06-11 3694
在上一篇博客中，博主已经讲解了如何利用选择出好的特征，接下来便要将这些特征输入到Decoder中进行解码，需要注意的是，在RT-DETR的Encoder中，使用的是标准的自注意力计算方法，而在其Decoder中，则使用的是可变形自注意力（deformable attention)，可变形自注意力能够大幅的降低计算量，同时该部分还使用到了CUDA算子，能够加快运行速度，当然，这个可变形自注意力计算并非是RT-DETR的创新点，但其作用却是极大，在DINO，DN-Deformable-DETR中都有使用。
RT-DETR推理详解及部署实现
周同学的博客
11-12 2万+
RT-DETR推理详解及部署实现
详解RT-DETR网络结构/数据集获取/环境搭建/训练/推理/验证/导出/部署
热门推荐
Snu77的博客
11-27 4万+
本文给大家带来是利用RT-DETR模训练自己的数据集，RT-DETR是一种新提出的目标检测模型，它利用的自注意力机制来处理图像数据。不同于YOLO通过连续的卷积层直接对图像区域进行分析，RT-DETR采用Transformer架构中的自注意力机制，这允许模型更有效地理解图像中不同部分之间的关系。这种方法使得RT-DETR在处理图像中的复杂场景和多对象环境时，能够展现出更高的准确性和效率。此外，RT-DETR在保持高精度的同时，也针对实时处理进行了优化，使其适合需要快速响应的应用场景。
RT-DETR改进有效系列目录 | 包含卷积、主干、RepC3、注意力机制、Neck上百种创新机制
Snu77的博客
01-29 2万+
Hello，各位读者们好Hello，各位读者，距离第一天发RT-DETR的博客已经过去了接近两个月，这段时间里我深入的研究了一下RT-DETR在ultralytics仓库的使用，旨在为大家解决为什么用v8的仓库训练的时候模型不收敛，精度差的离谱的问题，我也是成功的找到了解决方案，对于ultralytics仓库进行多处改进从而让其还原RT-DETR官方的实验环境从而达到一比一的效果。同时本人一些讲解视频和包含我所有创新的RT-DETR文档。
目标检测+PaddleDetection+rt-detr运行代码
06-28
该代码是百度的PaddleDetection代码，包含rt-detr配置文件和相关代码，可以直接用来测试
RT-DETR模型结构详解，在Ultralytics项目中配置rtdetr-resnet18、rtdetr-resnet34
Limiiiing的博客
01-21 1374
RT-DETR是一种实时端到端的目标检测模型，主要由 骨干网络、高效混合编码器和 带有辅助预测头的 Transformer 解码器组成。本文对其进行了详细分析，并在项目中配置了结构。
RT-DETR
weixin_65802479的博客
10-18 1156
RT-DETR 的网络架构是通过结合 CNN 和 Transformer 的优势，优化了目标检测流程，能够高效、准确地完成目标检测任务。其自注意力机制和特征融合技术使得模型能够处理复杂场景中的物体检测。
目标检测算法之RT-DETR
weixin_52862386的博客
06-27 3081
对RT-DETR的encoder部分，整体看下来像是yolo的backbone+neck。RT-DETR的核心还是在增速上，所以这里它的优化思想是值得借鉴的，但是yolo结构跟DETR结构之间的界限越来越模糊了。对query的优化上，只是做了对齐，使其选择的query更加精确。整体而言模型的创新不大。虽然DETR提倡的是NMS-Free，但是对于某些对精装度要求较高的任务中，如果阈值设置过低，导致最后得出的框过多，仍然需要借助NMS的方法去改进。设置过高则存在丢框的问题。
RT-DETR代码详解（官方pytorch版）——模型加载（2）
小小老大MUTA的博客
01-08 1642
找到在RT-DETR中，模型和数据集是怎么传入train_ine_epoch中进行训练的
[转]RT-DETR推理详解及部署实现-优快云博客
chinagudujian的专栏
01-04 4348
是由 Baidu 提出的基于 transformer 的端到端实时检测器，本篇文章主要分享博主在实现 RT-DETR 推理和部署时做的一些尝试，不涉及任何的原理性分析。若有问题欢迎各位看官批评指正😄博主在这里针对 RT-DETR 的预处理和后处理做了简单分析，同时与大家分享了 C++ 上的实现流程，目的是帮大家理清思路，更好的完成后续的部署工作😄。
RT-DETR：端到端的实时Transformer检测模型（目标检测+跟踪）
pengxiang1998的博客
05-31 8108
博主一直一来做的都是基于的目标检测领域，相较于基于卷积的目标检测方法，如YOLO等，其检测速度一直为人诟病。终于，RT-DETR横空出世，在取得高精度的同时，检测速度也大幅提升。那么RT-DETR是如何做到的呢？在研究RT-DETR的改进前，我们先来了解下DETR类目标检测方法的发展历程吧DETRNMSDAB-DETRDETR100DETRDAB-DETRH-DETR然而，上述方法尽管已经大幅提升了检测精度，降低了计算复杂度，但其受本身高计算复杂度的制约，DETR。
RT-DETR 基于Transformer的目标检测模型介绍及微调训练
小毕超博客
11-03 3469
RT-DETR是基于Transformer的目标检测模型,DETR的基础上采用了高效的混合编码器和IoU感知,有效降低了计算成本、提高了检测精度。
rt-detrv3网络结构
03-16
### RT-DETRv3 网络结构分析 RT-DETRv3 是一种基于 Transformer 的实时端到端目标检测算法，其核心在于通过引入分层密集正监督方法以及一系列创新性的训练策略，解决了传统 DETR 模型收敛慢和解码器训练不足的问题。以下是 RT-DETRv3 的主要网络结构特点： #### 1. **基于 CNN 的辅助分支** 为了增强编码器的特征表示能力，RT-DETRv3 引入了一个基于卷积神经网络 (CNN) 的辅助分支[^3]。这一分支提供了密集的监督信号，能够与原始解码器协同工作，从而提升整体性能。 ```python class AuxiliaryBranch(nn.Module): def __init__(self, in_channels, out_channels): super(AuxiliaryBranch, self).__init__() self.conv = nn.Conv2d(in_channels, out_channels, kernel_size=3, padding=1) self.bn = nn.BatchNorm2d(out_channels) def forward(self, x): return F.relu(self.bn(self.conv(x))) ``` 此部分的设计灵感来源于传统的 CNN 架构，例如 YOLO 系列中的 CSPNet 和 PAN 结构[^2]，这些技术被用来优化特征提取效率并减少计算开销。 --- #### 2. **自注意力扰动学习策略** 为解决解码器训练不足的问题，RT-DETRv3 提出了一种名为 *self-att 扰动* 的新学习策略。这种策略通过对多个查询组中阳性样本的标签分配进行多样化处理，有效增加了阳例的数量，进而提高了模型的学习能力和泛化性能。 具体实现方式是在训练过程中动态调整注意力权重分布，确保更多的高质量查询可以与真实标注 (Ground Truth) 进行匹配。 --- #### 3. **共享权重解编码器分支** 除了上述改进外，RT-DETRv3 还引入了一个共享权重的解编码器分支，专门用于提供密集的正向监督信号。这一设计不仅简化了模型架构，还显著降低了参数量和推理时间，使其更适合实时应用需求。 ```python class SharedDecoderEncoder(nn.Module): def __init__(self, d_model, nhead, num_layers): super(SharedDecoderEncoder, self).__init__() decoder_layer = nn.TransformerDecoderLayer(d_model=d_model, nhead=nhead) self.decoder = nn.TransformerDecoder(decoder_layer, num_layers=num_layers) def forward(self, tgt, memory): return self.decoder(tgt=tgt, memory=memory) ``` 通过这种方式，RT-DETRv3 实现了高效的目标检测流程，在保持高精度的同时大幅缩短了推理延迟。 --- #### 4. **与其他模型的关系** 值得一提的是，RT-DETRv3 并未完全抛弃经典的 CNN 技术，而是将其与 Transformer 结合起来形成混合架构[^4]。例如，它采用了 YOLO 系列中的 RepNCSP 模块替代冗余的多尺度自注意力层，从而减少了不必要的计算负担。 此外，RT-DETRv3 还借鉴了 DETR 的一对一匹配策略，并在此基础上进行了优化，进一步提升了小目标检测的能力。 --- ### 总结 综上所述，RT-DETRv3 的网络结构主要包括以下几个关键组件：基于 CNN 的辅助分支、自注意力扰动学习策略、共享权重解编码器分支以及混合编码器设计。这些技术创新共同推动了实时目标检测领域的发展，使其在复杂场景下的表现更加出色。 ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值