K8S系列四:服务管理

在这里插入图片描述

写在前面

本文是K8S系列第四篇,主要面向对k8s新手同学。阅读本文需要读者对k8s的基本概念,比如Pod、Deployment、Service、Namespace等基础概念有所了解,尚且不了解的同学推荐先阅读本系列的第一篇文章《K8S系列一:概念入门》[1];阅读本文还需要读者对k8s的服务部署有一定深入的了解,特别是怎么通过Pod部署自己的服务,尚且不熟悉的同学推荐阅读本系列前一篇文章《K8S系列三:单服务部署》[2]。

本文旨在讲述如何基于k8s集群管理一群服务,包括如何做高可用(Hight Available,HA)部署和管理、如何做服务平滑升级、如何隔离不同业务的服务等。因此,本文将重点介绍以下的k8s对象/资源(API Resource):

  • Deployment:无状态、多服务管理
  • StatefulSet:有状态、多服务管理
  • Namespace:不同服务资源隔离

0. 为什么需要服务管理?

正文开始之前,我们需要统一一个观点:日常生产中所说的“服务”,或者说是传统的“服务”,对应的是k8s的Pod对象(因为k8s有一个Service对象,经常被翻译和理解为服务,其实也没啥毛病)。

在上一篇文章《K8S系列三:单服务部署》[2]中,详细介绍了如何在k8s集群中部署一个可用的服务,包括容器环境的使用、数据卷的挂载、配置文件的使用、服务网络的配置。k8s会根据提交的Pod的yaml文件自动拉取镜像、挂载数据和配置文件、流量负载均衡器等以确保镜像容器内的服务正常运行。

这个难道还不足够么?还需要做什么呢?

答案是不够,因为还需要把部署在k8s集群上的服务更有效地管理起来,即服务管理。于是问题又来了:什么是服务管理?或者说,为什么需要服务管理?

我们来考虑几个场景:

场景一

高可用(Hight Available,HA)。虽然在实际生产中,后台服务架构设计原则没有统一的标准,不过,大部分后台服务必须考虑“三高”的问题:高并发、高性能、高可用。前两天看到一个非常有趣的话题:

面试官问:“如果线上请求量大,服务扛不住了怎么办?
” 我毫不犹豫:“加机器!”

话糙理不糙啊,加机器扩充服务实例绝对是首选(正经来说,面试官实际想听到的是对“三高”的理解、具体解决措施等)!仔细分析“加机器”这个操作,其实就是高可用的一种很有效的解决手段,而且在实际生产中往往一个程序也会部署几个服务实例,并且为了做有效容灾,服务实例会分布在不同的机器、机房、区域。

那么,“部署多个服务实例”的事情,仅仅用Pod不能完成么?

显然是可以的,做法也挺简单的:准备好N份Pod的yaml文件,设置好正确的镜像地址、挂载的数据卷、配置,以及配置好网络,只需要确保这N份yaml文件除了名字之外其余内容完全相同,譬如pod_1,pod_2,…,pod_n;接着用kubectl工具提交给k8s集群,N个服务实例就部署好了。

完美!

但是,上述操作存在问题:不方便。

比如,部署后发现分配的CPU和内存资源太少了,需要修改Pod的yaml文件。这个时候就是灾难了,因为你得人为修改这N份yaml文件。且不说损耗人力,更重要的是极易出错!就算是用shell脚本,你也会发现用起来没那么顺畅。

场景二

其次,实际生产中,服务发布上线之后,总是免不了迭代(谁还不会写一两个Bug了;客户/产品经理的需求单岂是一两次就提完了的)。这就意味着必须升级线上服务。

还是一样的问题:替换升级线上的服务,仅仅用Pod不能完成么?

也是可以的。做法也不复杂:首先把k8s集群中已经部署的Pod服务删除,然后再把修改好的N份Pod的yaml文件提交给k8s完成部署;或者直接修改(kubectl edit pod xxx)线上服务的配置信息,k8s会先删除老Pod再创建新的Pod。

不过,这种操作会有个很大的问题:在删除Pod和新建Pod中间,会有一段时间无法正常服务,客户端请求全部失败。 这就需要衡量你的服务是否能够接受这样子的“缺陷”;当然,你可以通过选择请求流量最小(譬如晚上)操作,也可以提前告知用户接下来某个时间段要更新服务、这个时间内不要向我发送请求。

但是在更多的实际生产场景中,上面的“缺陷”是不会被允许的。

其实,你也可以选择这么部署:再准备N份Pod的yaml文件,名字换另一组,譬如pod_n+1,pod_n+2,…,pod_n+n,然后,先提交部署新的N份yaml,紧接着再删除老的N个Pod。

不过,我们可以看到上面的做法:更加不方便了!

场景三

实际生产中,往往会管理多条业务线的服务,于是一个非常合理的需求自然而然就提出了:能否把不同业务线的服务分开管理?,一方面防止不同服务互相干扰,另一方面方便做资源隔离和管理。

一个很自然的想法是:对于每一条业务线部署一套k8s集群。

但是,这种做法太重了,首先是部署k8s是一件相对耗时耗力的事情;其次,实际生产环境也不一定有这么多的机器。最佳的方案是能够在一套k8s集群中完成(当然不排除在一些项目中,会要求部署多套k8s集群)。

综上,我们可以发现,仅仅使用Pod(Volume,ConfigMap,Secret和Service包括其中)一种对象无法满足更多的常见的、可能更复杂的实际生产场景。 但是,我们不应该责怪Pod,因为Pod的设计是合理的:

Pod是可以在 Kubernetes 中创建和管理的、最小的可部署的计算单元。

但是,上述几个场景中怎么解决呢?

k8s自然有解决办法和机制,这也是本文讨论的服务管理,这也是本文要重点讨论的几个API对象,概括来说:

  • 管理无状态的服务,用Deployment;
  • 管理有状态服务,用StatefulSet;
  • 隔离服务资源,用Namespace;

接下来,我们来看Deployment、StatefulSet和Namespace分别是怎么使用的吧!

I. Deployment:无状态、多服务管理

Deployment是管理无状态服务的利器,官网[3]描述:

一个 Deployment 为 Pods 和 ReplicaSets 提供声明式的更新能力。

官方文档总是说些听不懂的话,而且这里又引入了新的名词:ReplicaSet。这个是什么?

首先,Deployment、ReplicaSet和Pod之间的关系如下(图片引自书籍《k8s-in-action》[4]):

其次,在《K8S系列一:概念入门》[1]文中对Deployment、ReplicaSet和Pod三者之间的关系有过介绍:

ReplicaSet的作用就是管理和控制Pod,管控他们好好干活。但是,ReplicaSet受控于Deployment。形象来说,ReplicaSet就是总包工头Deployment手下的小包工头。

但是,上面的描述会有点小问题。严格来说,ReplicaSet是一个独立的API对象,所谓的“ReplicaSet受控于Deployment”是:当创建了Deployment对象后,它会自动创建ReplicaSet来管理Pod。

这就好像你准备装修你的房子,Deployment就是一个非常棒的装修公司,而ReplicaSet则是实际干活的包工头,而Pod则是每个干活的工人。装修公司只需要告诉包工头这个工程需要多少个工人干活,之后包工头就会实时监控每个工人,如果有M个工人请假,包工头会马上再雇佣M个工人参与进来。如果你觉得说:这批工人做工质量不行啊,我需要升级更好的。那么装修公司会马上撤走这个工程队,包括包工头和他手下所有工人,再雇佣新的工程队,包括新的包工头和新的工人。

可以看到,**Deployment的高可用实际上是ReplicaSet的特性,Deployment实际特性则是做服务的平滑升级,**也就对应了上面例子提到的“更换工程队”。

好的,那就让我们一起来看看Deployment的yaml文件(来自官网[3]):

apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: nginx:1.14.2ports:- containerPort: 80

对比Pod的yaml文件,我们会发现:Deployment比Pod多了几个字段:

  • ‘replicas’:控制实际在运行的Pod数量;
  • ‘selector’:通过该label管理对应的Pod(请留意’template.metadata.labels’);

由此也可以窥探到Deployment通过ReplicaSet管理Pod的内在机制:创建’replicas’个Pod,并且赋予Pod用户指定的label和一个名为’pod-template-hash’的label,内容为一个随机生成9位数的hash值;通过’selector’实时匹配在运行的Pod数量,不足则创建、非Running状态的杀死后重建、超过则杀死多余的。管理过程如下图:
在这里插入图片描述
接下来,让我们分别来看Deployment的两个特性:高可用平滑升级

特性一:高可用

在维基百科[5]上对高可用的定义是:

高可用性(英语:high availability,缩写为
HA),IT术语,指系统无中断地执行其功能的能力,代表系统的可用性程度。是进行系统设计时的准则之一。高可用性系统与构成该系统的各个组件相比可以更长时间运行。
高可用性通常通过提高系统的容错能力来实现。

高可用核心是:无中断提供服务。因此,提升高可用可以从几个方面入手:

  • 提升程序的鲁棒性(减少crash);
  • 增加服务实例,如采取主从(冷热)和双主(双热),甚至是多主的集群工作方式;

实际生产中,最佳手段还是增加服务实例,毕竟,谁也不能保证自己写的程序没有Bug。而Deployment的就可以做到确保k8s集群中实时存在用户需要的N个服务在正常工作。

笔者做了一个实验,假设我需要的是3个服务实例,那么只需要设置Deployment的yaml文件的’replicas: 3’即可,提交后发现集群上确实启动了三个Pod。紧接着,模拟线上服务挂了的状态,手动删除了其中一个Pod,再来看k8s中Pod的情况,发现马上有新的Pod被拉起。下图展示了整个过程,删除的Pod名字为’kubia-depl-765b79cff9-grzbm’,而被Deployment新拉起来的Pod名字为’‘kubia-depl-765b79cff9-zxx5g’:
在这里插入图片描述
前文已经说过:Deployment的高可用实际上是ReplicaSet的特性。这个怎么理解呢?

我们在通过Deployment部署Pod服务之后,到k8s分别查看Deployment、ReplicaSet和Pod,会发现一个有趣的现象:ReplicaSet的名字是则Deployment名字基础上加了一个’-9位hash值’生成的,并且其’selector’的label=用户自定义的label+‘pod-template-hash:9位hash值’;而Pod的名字则是ReplicaSet名字基础上再增加一个’-5位hash值’生成的,并且其label严格等于ReplicaSet的’selector’的label。如下图所示:
在这里插入图片描述
因此,确保’replicas’数量的Pod运行的特性的提供者,就是ReplicaSet!不信?你可以尝试一口气把所有的Pod都删除了,最后发现还是会被ReplicaSet拉起来。该过程如下图:
在这里插入图片描述
实践出真知啊。

特性二:平滑升级

上面我们已经看到,其实用ReplicaSet也能够管理多个服务,并且k8s最早开源的时候,也没有Deployment对象。但是之后发现,在实际生产中,程序版本迭代是一件常见且相对高频的操作。于是就推出了Deployment(早前有ReplicationController,自动Deployment推出之后就不被推荐使用了)。

我们现在来看看Deployment是怎么做服务的平滑升级。

在《k8s-in-action》[4]中第九章专门介绍了Deployment的升级,书中有一幅描述Deployment升级的示意图:
在这里插入图片描述
更具体的升级过程应该如下图:
在这里插入图片描述
可以看到,升级过程和上一节高可用提到的实时确保’replicas’个Pod在运行是不一样的:后者是依靠ReplicaSet完成的;而前者则是Deployment的功能特性。

怎么才能触发Deployment的升级呢?

但凡修改Deployment中非’replicas’的其他有效字段(镜像地址’image’、资源’resources’),都会触发Deployment的升级。笔者做了一个实验,修改了’resources’,可以看到:
在这里插入图片描述
然而,实际生产中仅仅知道Deployment会做平滑升级还不足够,还需要掌握选择升级策略和控制升级频率。关于这块,希望做更详细了解的同学建议阅读《Deployment Strategies》[6]和《Kubernetes部署策略详解》[7]。

  • Deployment升级策略
    Deployment有两种升级策略:Recreate和RollingUpdate。前者是先把所有旧的/已有的Pod全部销毁,然后再拉起新的;后者则是一个一个销毁旧的/已有的Pod,同时再一个一个拉起新的。RollingUpdate是默认的。
  • Deployment升级频率
    这里重点介绍RollingUpdate策略的参数,主要原因它是大部分实际生产中最佳的选择。

首先来看yaml文件中与之相关的部分:

strategy:type: RollingUpdaterollingUpdate:maxSurge: 25%maxUnavailable: 25%

敲重点:maxSurgemaxUnavailable是相对比较重要,且理解不直观的两个参数!网上关于这俩参数的解读有很多,大部分的解释仍旧不直观。笔者结合实验,在这里尝试解释:

核心理解点在于:maxSurge关系到启动新的Pod的速度;而maxUnavailable则关联到杀死旧的Pod的速度。RollingUpdate的任务就是一个一个销毁旧的/已有的Pod,同时再一个一个拉起新的。

我们假设’replica’为rp,maxSurge为ms(绝对值),而maxUnavailable为mu(绝对值)。实际上,RollingUpdate是先拉起mu个新的Pod,同时销毁min{ms+mu,剩余的}个旧的/已有的;(确保旧的/已有的被销毁了,而新的被拉起了)之后再拉起mu个新的Pod,同时销毁min{ms+mu,剩余的}个旧的/已有的。借用《k8s-in-action》[4]的过程图来说明:
在这里插入图片描述
由此可见,maxSurgemaxUnavailable越大,更新越快;反之,更新会越慢。并且,k8s要求maxSurge和maxUnavailable不能同时为0,为什么? 因为都为0的话,根本没办法更新了!那么,到底要怎么设置这两个值,这就要视实际生产要求而定。

笔者也做了下实验,和大家分享:

  • 实验一:replicas=4,maxSurge=0,maxUnavailable=1,2,4。
    结论:升级速度越来越快。
    在这里插入图片描述
    在这里插入图片描述
    在这里插入图片描述
  • 实验二:replicas=2,maxUnavailable=0,maxSurge=1,2
    但是由于笔者试用的k8s集群资源有限(一次至多4个Pod在跑,而且时不时会被抢占资源),因此只能做replicas=2的实验,再大一点就会跑不起来。大家可以自行实验。

结论:升级速度越来越快。
在这里插入图片描述
在这里插入图片描述
不知道会不会有同学在想:如果我追求快速升级迭代,那是不是把maxSurge设置跟’replicas’一样最好?一次性就升级好了!

但是请注意,笔者分享自己实际遇到的坑:k8s集群总归会有资源不足的情况(比如cpu、gpu甚至是ip资源),因此在资源非常紧张的时候,如果maxSurge越大,升级反而不见得越快;并且在资源恰好足够的时候,maxSurge大于零,就会造成升级卡主!!!因为,RollingUpdate实际升级过程是先拉起maxSurge新实例,紧接着销毁maxUnavailable个旧的/已有的实例。切忌小心升级,别以为用了k8s就万事大吉!

II. StatefulSet:有状态、多服务管理

在讨论StatefulSet之前,笔者先说明:实际生产中笔者所用业务并没有使用到该类管理器API对象,所有的知识都是从《k8s-in-action》[4]学习的。

首先,我们要知道:为什么需要StatefulSet?或者说,它和Deployment不同点在哪?

《k8s-in-action》[4]在第十章一开头,花了很大的篇幅在描述这个问题,笔者通过书籍、网上博客和实验,感觉文章《StatefulSet和Deployment的区别 》[8]总结得很好:

  • 稳定的、唯一的网络标识。
  • 稳定的、持久的存储。
  • 有序的、优雅的部署和伸缩。
  • 有序的、优雅的删除和停止。
  • 有序的、自动的滚动更新。

而在文章《Kubernetes服务之StatefulSets简介》[9]则对于StatefulSet的用法细节总结得很好:

在这里插入图片描述
在这里插入图片描述
笔者试验了StatefulSet的CURD,发现其创建和扩缩容确实都是按顺序扩增、缩小;但是如果直接把StatefulSet删除的话,那么所有的Pod也就被删除了:

  1. 创建:可以看到Pod是逐个被创建,并且以StatefulSet的名字+id(从0开始递增)的形式为其名字。
    在这里插入图片描述

  2. 扩容:可以看到,扩增的Pod是在已有的id基础上继续递增,并且也是逐个创建。
    在这里插入图片描述

  3. 缩容:是从当前最大id逐个销毁。
    在这里插入图片描述

  4. 删除:直接全部删除了。
    在这里插入图片描述

笔者这个时候在思考,如果仅仅是其中一个Pod挂了会怎么样?实验后发现:StatefulSet会拉起!并且,StatefulSet并没有中间创建ReplicaSet或者ReplicationController,因此有理由相信StatefulSet自己实现了实时监督Pod和拉起失败Pod的能力(可能复用了StatefulSet的代码)。

在这里插入图片描述

仅仅从CURD层面看,StatefulSet和Deployment是完全不一样的。至于其他方面的特性,笔者还没来得及深入了解,挖个坑吧!

III. Namespace:不同服务资源隔离

Namespace可就太基本,而且使用起来也非常简单:

# 创建
$ kubectl create namespace ${name}
# 删除
$ kubectl delete namespace ${name}
# 查看
$ kubectl get namespace

那么为什么要特别为它设立一个章节呢?因为越是基础,越是重要,也越是容易被忽略!请一定合理为不同的项目创建Namespace!

写在后面

k8s实践tip1: 实际生产中使用kubectl工具时,会发现有些API对象有缩写,比如pod是po,replicaset就写rs。怎么查看呢?

kubectl api-resources非常重要!可以看到当前k8s的所有API对象、其缩写、它是否可以被Namespace隔离等:
在这里插入图片描述
最后,如果文章中有纰漏,非常欢迎留言或者私信指出;有理解错误的地方,更是欢迎留言或者私信告知。总之,非常欢迎大家留言或者私信交流更多k8s的问题。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/44378.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

JVM——分代收集理论和垃圾回收算法

一、分代收集理论 1、三个假说 弱分代假说:绝大多数对象都是朝生夕灭的。 强分代假说:熬过越多次垃圾收集过程的对象越难以消亡。 这两个分代假说共同奠定了多款常用的垃圾收集器的一致的设计原则:收集器应该将Java堆划分出不同的区域&…

kafka--kafka的基本概念-topic和partition

一、kafka的基本概念-topic和partition 1、topic (主题 ) topic是逻辑概念 以Topic机制来对消息进行分类的,同一类消息属于同一个Topic,你可以将每个topic看成是一个消息队列。 生产者(producer)将消息发…

利用Jackson封装常用的JsonUtil工具类

在实际开发中,我们对于 JSON 数据的处理,通常有这么几个第三方工具包可以使用: gson:谷歌的fastjson:阿里巴巴的jackson:美国FasterXML公司的,Spring框架默认用的 由于以前一直用习惯了阿里的…

Spring事务和事务传播机制(1)

前言🍭 ❤️❤️❤️SSM专栏更新中,各位大佬觉得写得不错,支持一下,感谢了!❤️❤️❤️ Spring Spring MVC MyBatis_冷兮雪的博客-CSDN博客 在Spring框架中,事务管理是一种用于维护数据库操作的一致性和…

Mac OS下应用Python+Selenium实现web自动化测试

在Mac环境下应用PythonSelenium实现web自动化测试 在这个过程中要注意两点: 1.在终端联网执行命令“sudo pip install –U selenium”如果失败了的话,可以尝试用命令“sudo easy_install selenium”来安装selenium; 2.安装好PyCharm后新建project&…

DTC 19服务学习1

在UDS(统一诊断服务)协议中,0x19是用于DTC(诊断故障代码)信息的服务。以下是你提到的子服务的功能和作用: 0x01 - 报告DTC按状态掩码。这个子服务用于获取当前存储在ECU中的DTC列表。状态掩码用于过滤DTC&a…

数据可视化-canvas-svg-Echarts

数据可视化 技术栈 canvas <canvas width"300" height"300"></canvas>当没有设置宽度和高度的时候&#xff0c;canvas 会初始化宽度为 300 像素和高度为 150 像素。切记不能通过样式去设置画布的宽度与高度宽高必须通过属性设置&#xff0c;…

对话 4EVERLAND:Web3 是云计算的新基建吗?

在传统云计算的发展过程中&#xff0c;数据存储与计算的中心化问题&#xff0c;对用户来说一直存在着潜在的安全与隐私风险——例如单点故障可能会导致网络瘫痪和数据泄露等危险。同时&#xff0c;随着越来越多 Web3 项目应用的落地&#xff0c;对于数据云计算的性能要求也越来…

对前端PWA应用的部分理解和基础Demo

一、什么是PWA应用&#xff1f; 1、PWA简介 ​ 渐进式Web应用&#xff08;Progressive Web App&#xff09;&#xff0c;简称PWA&#xff0c;是 Google 在 2015 年提出的一种使用web平台技术构建的应用程序&#xff0c;官方认为其核心在于Reliable&#xff08;可靠的&#xf…

git压缩/合并多次commit提交为1次commit提交

git压缩/合并N次commit提交为1次commit提交 假设有最近3次提交&#xff1a; commit_id1 commit_id2 commit_id3目标是把以上3次commit合并成1个commit&#xff0c;注意&#xff0c;最新的commit提交在最上面。 在git bash里面的操作步骤&#xff1a; &#xff08;1&#xff0…

基于深度学习的铁路异物侵限检测算法研究_整体认知感觉欠点意思,但是有一个新的变形卷积-Octave 卷积

相比于其他的交通运输方式&#xff0c;铁路运输具有准时性高、连续性强、速度快、运输量大、运输成本低以及安全可靠等优点。同时由于国家高速铁路网络建设的不断推进&#xff0c;铁路运输逐渐成为我国客运与货运的主要运输方式。虽然铁路运输为人们出行和货物运输带来的极大的…

MySQL数据库——SQL(3)-DQL(基本查询、条件查询、聚合函数、分组查询、排序查询、分页查询、案例练习)

目录 语法 基本查询 1.查询多个字段 2.设置别名 3.去除重复记录 示例 条件查询 1.语法 2.条件 示例 聚合函数 介绍 常见聚合函数 语法 示例 分组查询 语法 示例 排序查询 1.语法 2.排序方式 示例 分页查询 语法 示例 DQL案例练习 执行顺序 DQL总结…

简单理解Linux中的一切皆文件

一款操作系统要管理各种各样不同的硬件&#xff0c;因为硬件的不同所以它们使用的文件系统也不同。但是按道理来说&#xff0c;文件系统的不同对于用户来说可不是一件好事&#xff0c;操作不同的硬件就要使用不同的方法。 但是Linux有一切皆文件。 简单来说&#xff0c;Linux…

基于单片机DHT11温湿度NRF2401无线通信控制系统

一、系统方案 本设计采用STC89C5单片机作为主控制器&#xff0c;从机采用DHT11传感器采集温湿度、按键设置报警阀值&#xff0c;液晶1602显示&#xff0c;蜂鸣器报警&#xff0c;无线NRF2401模块。 二、硬件设计 原理图如下&#xff1a; 三、单片机软件设计 1、首先是系统…

使用 umap 图形化展示原文在嵌入后的位置情况

使用 umap_plot 图形化展示原文在嵌入后的位置情况 1. 效果展示2. 工具函数3. 示例代码14. 示例代码2 1. 效果展示 2. 工具函数 import umap import altair as altfrom numba.core.errors import NumbaDeprecationWarning, NumbaPendingDeprecationWarning import warningswar…

G0第26章:微服务概述与gRPCprotocol buffers

Go微服务与云原生 1、微服务架构介绍 单体架构&#xff08;电商&#xff09; SOA架构&#xff08;电商&#xff09; 微服务架构&#xff08;电商&#xff09; 优势 挑战 拆分 发展史 第一代:基于RPC的传统服务架构 第二代:Service Mesh(istio) 微服务架构分层 核心组件 Summar…

【GaussDB】 SQL 篇

建表语句 表的分类 普通的建表语句 复制表内容 只复制表结构 create table 新表名(like 源表名 including all); 如果希望注释被复制的话要指定including comments 复制索引、主键约束和唯一约束&#xff0c;那么需要指定including indexes including constraints &#xf…

MsrayPlus多功能搜索引擎采集软件

MsrayPlus多功能搜索引擎采集软件 摘要&#xff1a; 本文介绍了一款多功能搜索引擎软件-MsrayPlus&#xff0c;该软件能够根据关键词从搜索引擎中检索相关数据&#xff0c;并提供搜索引擎任务、爬虫引擎任务和联系信息采集三大功能。我们将分析该软件在不同领域的应用&#xf…

VBA技术资料MF43:VBA_Excel中自动填充

【分享成果&#xff0c;随喜正能量】以时寝息&#xff0c;当愿众生&#xff0c;身得安隐&#xff0c;心无动乱。愿我们都能&#xff0c;梦见幸福&#xff01;在踉跄中前进&#xff0c;在跌倒后跃进&#xff0c;逐渐强大.。 我给VBA的定义&#xff1a;VBA是个人小型自动化处理的…

使用Jmeter自带recorder代理服务器录制接口脚本

脚本录制 配置线程组 添加代理服务器 端口 和 录制脚本放置位置可根据需要设置 启动录制 点击启动后 弹出创建证书提示&#xff0c;点击OK 这个证书后续需要使用到 然后可见 一个弹窗。 Recorder . 本质是代理服务录制交易控制 可设置对应数据 方便录制脚本的查看 证书配置…