Spring Cloud微服务架构进阶

2021-06-28 20:59:07 阅读：186 来源： 互联网

标签：候选调用服务进阶 Spring self channels 使用 Cloud

服务注册于发现：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己；服务调用方从服务注册中心找到自己需要调用的服务的地址。
负载均衡：服务提供方一般以多个实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，服务节点选择的过程对服务调用方是透明的。
服务网关：服务网关是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、A/B测试、负载限流等功能。
配置中心：将本地话配置信息注册到配置中心
集成框架：以配置形式将所有微服务组件集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
调用链监控：记录完成一次请求的先后衔接和调用关系，并将这种穿行或并行的调用关系展示出来。
支撑平台：系统的部署、运维、监控等都比单体应用架构更加复杂，大部分工作需要自动化。

文件：590m.com/f/25127180-500761991-149ff6（访问密码：551685）

以下内容无关：

-------------------------------------------分割线---------------------------------------------

最新几年的论文都是在单阶段、Transform上进行发掘提升，基本上2020-2021年二阶段论文全军覆没，这篇博文也是总结2016-2019年的发展，最后一篇CenternetV2比较特殊，不能完全算作传统意义的二阶段网络。

目前什么地方还使用二阶段论文？

比赛场景，经常使用FasterRCNN的变种+其它网络进行联合预测
目标比较小的场景（使用较少，一般用anchor-free、增大输入去代替、分割图像检测）
辅助一阶段使用，和（2）类似但不同。比如检测远距离人形+人脸，方案一：先检测人，后检测人脸，两个都是OneStage。方案二：使用TwoStage网络，第一阶段检测人形，第二阶段检测人脸。当然只有第二类别是第一类别的从属，且是唯一关系才能进行！
一. FasterRCNN
以torchvision给出的demo为例子：

第一阶段，和基础SSD等一阶段操作类似，但是这一阶段会立刻输出候选区域
https://github.com/pytorch/vision/blob/183a722169421c83638e68ee2d8fc5bd3415c4b4/torchvision/models/detection/rpn.py#L29

将候选区域从FPN输出的feature上抠出来

使用ROIPooling对齐候选特征的大小

https://github.com/pytorch/vision/blob/183a722169421c83638e68ee2d8fc5bd3415c4b4/torchvision/ops/poolers.py#L83-L277

第二阶段，直接进行FC细化Reg/Cls，当然这里只能是一个候选区域最多一个目标。
class FastRCNNPredictor(nn.Module):
“”"
Standard classification + bounding box regression layers
for Fast R-CNN.
Args:
in_channels (int): number of input channels
num_classes (int): number of output classes (including background)
“”"

def __init__(self, in_channels, num_classes):
    super(FastRCNNPredictor, self).__init__()
    self.cls_score = nn.Linear(in_channels, num_classes)
    self.bbox_pred = nn.Linear(in_channels, num_classes * 4)

def forward(self, x):
    if x.dim() == 4:
        assert list(x.shape[2:]) == [1, 1]
    x = x.flatten(start_dim=1)
    scores = self.cls_score(x)
    bbox_deltas = self.bbox_pred(x)

    return scores, bbox_deltas

image-20210624170757195
注释：

最后一步FC是参考anchor的做法，首先想到的是self.bbox_pred=nn.Linear(in_channels,4) ，因为已经使用class进行了过滤，没有必要再把regression去使用class再去过滤一遍。当然使用class对回归进行区分，这效果肯定优于单个回归。
我们再进一步延伸，如果在不同的class之下，再使用一种手段（长宽、面积、anchor等）对其进一步划分，比如：假设候选区域数量不变为 P，类别为两类（人形、人脸），进一步使用anchor限制（两个anchor，5和20，比例4倍以内使用5，超过4倍使用20），这样会不会更精细？
上一步我们限制了候选区域数量，能不能使用输入多个不同组的候选区域，后面连接多个不同的predict？这就是后续改进cascadeRCNN的由来。
二. MaskRCNN
第一阶段使用FasterRCNN，RPN网络都相同
第二阶段输出多一个分支 K×m×m , 其中 K 表示种类，m 表示输出分辨率
注意：最后输出的mask大小是固定的，设置大小得根据实际种类而定。这个mask分支和FCN有点区别，这里使用K个feature，然后直接进行二分类操作，而FCN使用单个feature进行多分类操作，目前检测的分类loss都是进行单独的二分类操作。

image-20210624175016872
三. CascadeRCNN
第一阶段和FasterRCNN完全一样

第二阶段使用多个RoiHead层进行级联

下图完全显示了CascadeRCNN的由来

下图（C）仅仅在前向计算的时候使用级联finetune操作，精度也得到一定提升，但是有两个缺陷。1）使用共享的Head-H1，不仅时间没降低，而且参数效果还不好。所以在端侧单阶段目标检测中，一般不使用共享的头，虽然参数减少了，但是计算量一点未变，所以都使用不共享的头。2）都是固定的，不能进行训练，后面的阶段已经处于过拟合状态。
下图（d）最大的缺点就是候选区域固定，非常容易过拟合。有一个优点，后面的stage仅仅进行分类而不进行reg，这是cascade未考虑的。但是，分类分支花费的代价很小，基本影响不到大局，所以讨论的人很少。
下图（b）融合了两者的优点，1）可训练。2）不共享。3）候选区域不同。
image-20210624175552697

标签：候选,调用,服务,进阶,Spring,self,channels,使用,Cloud
来源： https://blog.csdn.net/weixin_43322764/article/details/118311951

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

ICode9

Spring Cloud微服务架构进阶