Category Archives: Backend

Airtest自动化测试工具

一开始知道Airtest大概是在年初的时候，当时，看了一下官方的文档，大概是类似Sikuli的一个工具，主要用来做游戏自动化的，通过截图的方式用来解决游戏自动化测试的难题。最近，移动端测试的同事尝试用它的poco库来做自动化，看样子还不错，所以，这里推荐给各位同学。 官方网站 http://airtest.netease.com/ ### Airtest IDE 这是Airtest测试工具标配的IDE，目的是方便我们用于录制/编写自动化测试。 你可以使用账号登录或直接点击左下角“skip”按钮跳过。 启动Android模拟器或者用PC连接一台手机。通过adb命令检查移动设备。

  当我在Android模拟器中操作时，Airtest IDE右侧的界面是同步的，这一点比很多移动测试工具做的优秀，例如，appium desktop必须手动刷新才能获取最新的界面。 #### Airtest Airtest IDE支持Airtest脚本的录制，用法非常简单，你甚至可以先不用看它的API，通过录制来熟悉它的API。 右侧Airtest窗口以及API，点击右上角录制按钮，然后，就可以在映射的Android模拟器界面上点点点了。 以下是我点点点，生成的脚本。 过程非常简单，点击桌面上的计算器图标，打开编辑器输入1+1= ，然后，点击工具栏上的 “运行”按钮，就可以回放了。 这种脚本更适合游戏，因为游戏界面很难定位，图片识别（截图）的方式确实是不错的选择。 ###Poco Poco是另外一种形式的脚本，它与一般的自动化工具一样，通过元素本身的属性来定位元素，并且它同样支持录制。\ 点击右上角第一个的录制按钮。然后，继续在android映射的界面上点点点。 因为脚本里面没截图，我就单独拿出来了。

  从poco的API来看比appium更为简洁。 如果你要做的是非游戏的APP的话，poco应该是我们后面学习的重点。这样的代码不管是和单元测试框架结合还是使用PO设计模式都是没有问题的。 而且，同样提供元素的属性展示，又有录制功能加持，在开发效率上应该会提高不少。 如果，你刚好又会Python，那么这将是一个不错的选择。   from:https://www.cnblogs.com/fnng/p/10247339.html

docker 运行容器_如何修改运行中的docker容器挂载目录

当docker容器创建后，忘记挂接做本地与容器目录挂接后，导致数据存储都是存在容器中，如果想修改容器内文件或替换，就需要通过以下命令替换。

  为了方便，只要在linux目录替换，可以通过容器挂载的方式，只要替换linux的目录，就能实现容器内的文件变更。 挂载目录步骤如下： 1、停止docker运行

  2、修改容器的配制文件 容器路径：/var/lib/docker/containers/[容器ID] 修改的文件： 2.1、hostconfig.json 在"Binds"节点中增加挂载目录的关系，如：

  前面的是本地目录，后面的是容器目录，多个的话，用逗号隔开。 2.2、config.v2.json 在"MountPoints" 节点中增加挂载目录。如：

  3、重新docker,开启容器

  以上是以修改正在运行的容器的方式挂载目录。 还有简单的方式： 提交现有容器为新镜像，然后重新运行挂载。   from:https://blog.csdn.net/weixin_36431535/article/details/113067296

docker: Error response from daemon: driver failed programming external connectivity on endpoint lamp

Docker容器做端口映射报错 docker: Error response from daemon: driver failed programming external connectivity on endpoint lamp3 (46b7917c940f7358948e55ec2df69a4dec2c6c7071b002bd374e8dbf0d40022c): (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 86 -j DNAT --to-destination 172.17.0.2:80 ! -i docker0: iptables: No chain/target/match by that name. 解决方法 docker服务启动时定义的自定义链DOCKER被清除 重启即可systemctl restart docker ———————————————— 版权声明：本文为CSDN博主「米粥粥」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/qq_41545647/article/details/102679560

揭开正则表达式的神秘面纱

[原创文章，转载请保留或注明出处：http://www.regexlab.com/zh/regref.htm] 引言 正则表达式（regular expression）就是用一个“字符串”来描述一个特征，然后去验证另一个“字符串”是否符合这个特征。比如 表达式“ab+” 描述的特征是“一个 'a' 和 任意个 'b' ”，那么 'ab', 'abb', 'abbbbbbbbbb' 都符合这个特征。   正则表达式可以用来：（1）验证字符串是否符合指定特征，比如验证是否是合法的邮件地址。（2）用来查找字符串，从一个长的文本中查找符合指定特征的字符串，比查找固定字符串更加灵活方便。（3）用来替换，比普通的替换更强大。 正则表达式学习起来其实是很简单的，不多的几个较为抽象的概念也很容易理解。之所以很多人感觉正则表达式比较复杂，一方面是因为大多数的文档没有做到由浅入深地讲解，概念上没有注意先后顺序，给读者的理解带来困难；另一方面，各种引擎自带的文档一般都要介绍它特有的功能，然而这部分特有的功能并不是我们首先要理解的。 文章中的每一个举例，都可以点击进入到测试页面进行测试。闲话少说，开始。 1. 正则表达式规则 1.1 普通字符 字母、数字、汉字、下划线、以及后边章节中没有特殊定义的标点符号，都是"普通字符"。表达式中的普通字符，在匹配一个字符串的时候，匹配与之相同的一个字符。  举例1：表达式 "c"，在匹配字符串 "abcde" 时，匹配结果是：成功；匹配到的内容是："c"；匹配到的位置是：开始于2，结束于3。（注：下标从0开始还是从1开始，因当前编程语言的不同而可能不同）  举例2：表达式 "bcd"，在匹配字符串 "abcde" 时，匹配结果是：成功；匹配到的内容是："bcd"；匹配到的位置是：开始于1，结束于4。 1.2 简单的转义字符 一些不便书写的字符，采用在前面加 "\" 的方法。这些字符其实我们都已经熟知了。 表达式 可匹配 \r, \n 代表回车和换行符 \t 制表符 \\ 代表 "\" 本身 还有其他一些在后边章节中有特殊用处的标点符号，在前面加 "\" 后，就代表该符号本身。比如：^, $ 都有特殊意义，如果要想匹配字符串中 "^" 和 "$" 字符，则表达式就需要写成 "\^" 和 "\$"。 表达式 可匹配 \^ 匹配 ^ 符号本身 \$ 匹配 $ 符号本身 \. 匹配小数点（.）本身 这些转义字符的匹配方法与 "普通字符" 是类似的。也是匹配与之相同的一个字符。  举例1：表达式 "\$d"，在匹配字符串 "abc$de" 时，匹配结果是：成功；匹配到的内容是："$d"；匹配到的位置是：开始于3，结束于5。 1.3 能够与 '多种字符' 匹配的表达式 正则表达式中的一些表示方法，可以匹配 '多种字符' 其中的任意一个字符。比如，表达式 "\d" 可以匹配任意一个数字。虽然可以匹配其中任意字符，但是只能是一个，不是多个。这就好比玩扑克牌时候，大小王可以代替任意一张牌，但是只能代替一张牌。 […]

Unknown instruction: FROM CENTOS:7

用Dockerfile构建jdk镜像的时候出的错 把Dockerfile文件删除之后重新建一个 把空格 符号全更换一遍英文 最后运行成功   from:https://blog.csdn.net/weixin_43555477/article/details/106480089

ASP.NET quartz 定时任务

1.下载 2.使用例子 Demo 概述：Quartz 是开源的定时任务工具类，默认每隔10秒执行一次任务，相当于C#的Timer，不断的循环执行（Start 方法），也可以随时停止（ShutDown方法）。 一 下载 下载地址：quartz     二 使用例子 Demo 1）引入程序集，必须引入三个，不然报错 2）IScheduler 和 IJob

3）每隔10秒，修改一次缓存的值，可以打断点随时查看缓存里的实时值。 from:https://www.cnblogs.com/ligenyun/p/7729989.html

服务注册与发现的原理和实现

什么是服务注册发现？ 对于搞微服务的同学来说，服务注册、服务发现的概念应该不会太陌生。 简单来说，当服务A需要依赖服务B时，我们就需要告诉服务A，哪里可以调用到服务B，这就是服务注册发现要解决的问题。 Service B 把自己注册到 Service Registry 叫做 服务注册 Service A 从 Service Registry 发现 Service B 的节点信息叫做 服务发现 服务注册 服务注册是针对服务端的，服务启动后需要注册，分为几个部分： 启动注册 定时续期 退出撤销 启动注册 当一个服务节点起来之后，需要把自己注册到 Service Registry 上，便于其它节点来发现自己。注册需要在服务启动完成并可以接受请求时才会去注册自己，并且会设置有效期，防止进程异常退出后依然被访问。 定时续期 定时续期相当于 keep alive，定期告诉 Service Registry 自己还在，能够继续服务。 退出撤销 当进程退出时，我们应该主动去撤销注册信息，便于调用方及时将请求分发到别的节点。同时，go-zero 通过自适应的负载均衡来保证即使节点退出没有主动注销，也能及时摘除该节点。 服务发现 服务发现是针对调用端的，一般分为两类问题： 存量获取 增量侦听 还有一个常见的工程问题是 应对服务发现故障 当服务发现服务（比如 etcd, consul, nacos等）出现问题的时候，我们不要去修改已经获取到的 endpoints 列表，从而可以更好的确保 etcd 等宕机后所依赖的服务依然可以正常交互。 存量获取 当 Service A 启动时，需要从 Service Registry 获取 Service B 的已有节点列表：Service B1, Service B2, Service B3，然后根据自己的负载均衡算法来选择合适的节点发送请求。 增量侦听 上图已经有了 Service B1, Service B2, Service B3，如果此时又启动了 Service B4，那么我们就需要通知 Service A 有个新增的节点。如图： 应对服务发现故障 对于服务调用方来说，我们都会在内存里缓存一个可用节点列表。不管是使用 etcd，consul 或者 nacos 等，我们都可能面临服务发现集群故障，以 etcd 为例，当遇到 etcd 故障时，我们就需要冻结 Service B 的节点信息而不去变更，此时一定不能去清空节点信息，一旦清空就无法获取了，而此时 Service B 的节点很可能都是正常的，并且 go-zero 会自动隔离和恢复故障节点。 服务注册、服务发现的基本原理大致如此，当然实现起来还是比较复杂的，接下来我们一起看看 go-zero 里支持哪些服务发现的方式。 go-zero 之内置服务发现 go-zero 默认支持三种服务发现方式： 直连 基于 etcd 的服务发现 基于 kubernetes endpoints 的服务发现 直连 直连是最简单的方式，当我们的服务足够简单时，比如单机即可承载我们的业务，我们可以直接只用这种方式。 在 rpc 的配置文件里直接指定 endpoints 即可，比如：

  zrpc 调用端就会分配负载到这两个节点上，其中一个节点有问题时 zrpc 会自动摘除，等节点恢复时会再次分配负载。 这个方法的缺点是不能动态增加节点，每次新增节点都需要修改调用方配置并重启。 基于 etcd 的服务发现 当我们的服务有一定规模之后，因为一个服务可能会被很多个服务依赖，我们就需要能够动态增减节点，而无需修改很多的调用方配置并重启。 常见的服务发现方案有 etcd, consul, nacos 等。 go-zero内置集成了基于 etcd 的服务发现方案，具体使用方法如下：

  Hosts 是 etcd 集群地址 Key 是服务注册上去的 key 基于 […]

服务的注册与发现（Consul、zookeeper、etcd、eureka、Nacos）

一. 对比常用的注册中心 Consul、zookeeper、etcd、eureka、Nacos Feature Consul Zookeeper Etcd Eureka Nacos 服务健康检查  服务状态，内存，硬盘等  (弱)长连接，keepalive  连接心跳  可配支持 传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查 多数据中心  支持  —  —  — 支持 kv存储服务  支持  支持  支持  —  支持 一致性   Raft  Paxos   Raft  — Raft CAP定理  CP  CP  CP  AP CP: 配置中心 AP: 注册中心 使用接口 (多语言能力)  支持http和dns  客户端  http/grpc  http（sidecar） Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用 原生SDK、OpenAPI、或一个独立的Agent watch支持  全量/支持long polling  支持  支持 long polling 支持 long polling/大部分增量 支持 long polling/大部分增量 自身监控  metrics  —  metrics  metrics   安全  acl /https  acl  https支持（弱）  — acl Spring Cloud集成  已支持  已支持  已支持  已支持  已支持 备注 可以作为eureka的替代使用     2.0不在更新 1. 支持dubbo […]

Nacos – 阿里开源配置中心

配置中心相信大家都有听过，zookeeper、apollo等等都是配置中心的代表，但大部分都是JAVA系为主的，笔者主要开发语言使用的是Golang当然也有类似于ETCD这样的组件，但是并不方便管理也无法可视化，在无意之间发现了阿里爸爸开源了nacos这个服务发现+配置中心组件，也经过了一段时间的时候在这里分享给大家 附上: 喵了个咪的博客:w-blog.cn Nacos官方Git地址:https://github.com/alibaba/nacos Nacos官方文档地址:https://nacos.io/zh-cn/docs/ Go语言SDK地址:https://github.com/sunmi-OS/gocore/tree/master/nacos PS：当前官方最新版本为 V1.1.3，阿里云有提供配置中心服务ACM使用方式和Nacos相同，使用阿里云的前提下免运维是个不错的选择 一、Nacos介绍 Nacos是阿里云中间件团队开源的一个项目，基于阿里云内部提供的ACM配置管理服务进行独立，截止到现在github已经有8K以上的star了，虽然成熟度还不能和携程开源的apollo相提并论，比较也是在阿里云上提供服务的组件稳定性还是值得相信的，当然要使用介绍Nacos必须要介绍介绍配置中心这样一个思想了。 配置中心是个老生常谈的话题，从有软件编程开始配置管理都是工程中重要的一步，当然对与一个单体应用只需要单个配置文件或环境变量的方式来管理配置就好了所以不再本文的讨论范围内，配置中心主要解决服务化或微服务化下的配置管理中的如下问题： 有效的密码管理，开发不碰触密码配置，运维人员和架构团队统一管理避免泄露； 多项目下的配置绝对统一性，不会出现配置写错导致的BUG 对于配置的编辑、存储、分发、变更管理、历史版本管理、变更审计有完善的能力 配置分组和灰度发布 有好处当然也有坏处，相对于使用配置文件我们还需要解决如下问题： 配置中心异常情况下服务怎么保障可用（SDK提供Cache功能当中心服务不可用会使用上一次加载的缓存配置） 配置变更后的程序生效逻辑（SDK提供配置变动订阅逻辑可以订阅配置变动编写处理逻辑） 开发过程中的配置文件调试（需要框架进行设计） 对于部分语言来说（PHP）配置中心性能的问题（Nacos的吞吐量8C16G 15K并发） 对比下来还是可以总结出配置中心利大于弊的结论 二、Nacos部署 Nacos不止支持二进制部署也支持支持Docker和K8S部署，因为Nacos是有状态服务存储的数据需要依赖于Mysql而且集群的方式需要指定slave的IP所以使用K8S并不是很好的选择（K8S使用StatefulSet来运行有状态服务），笔者这里用Docker-Composer的方式来运行Nacos

访问：http://localhost:8848/nacos/ 就可以看到登录界面了 PS：默认用户名和密码都是 nacos 阿里云ACM服务 当然自己部署Nacos还会面临很多挑战，比如： 集群搭建 稳定性 Mysql数据库维护 配置安全保护（Nacos没有密码一说，但是ACM需要使用阿里云的密钥可以提高安全程度） PS：秉着能用服务就不自己搭建的原则笔者最终使用的是阿里云的ACM服务（当前ACM服务免费） PS：需要注意阿里云ACM和Nacos在SDK中的链接方式有不同 三、基础使用 Nacos有几个基础概念，我们只有先了解清楚之后才能更好的结合到业务场景： namespace 命名空间 Group 配置分组 DataID 具体的配置名称 一般我们使用namespace来区分不同的项目或环境，Group区分配置的差异系比如A业务获取的配置和B团队的有一些细微的差别可以通过Group来区分，最后使用DataId来区分具体的配置项 增加一个namespace 新增一个配置 支持很多种配置格式，也可以使用自定义的格式甚至直接存放代码都行 也有对应的JAVA系的示例代码 四、SDK和OpenApi使用配置 Nacos支持一下语言的SDK（当然GIT上也有很多非官方的SDK库）： Java go cpp python nodejs 大家可以在官方文档中查看具体的使用方式 上面已经配置好的配置我们可以使用OpenApi来访问它

特别注意tenant就是需要输入namespace的名称，但是不是原名是如下的名称 from:https://www.cnblogs.com/cuiyubo/p/11756777.html

微服务之consul（一）

一、概述 consul是google开源的一个使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等）。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server和client。每个数据中心官方建议需要3或5个server节点以保证数据安全，同时保证server-leader的选举能够正确的进行。 @client CLIENT表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到SERVER，本身是不持久化这些信息。 @server SERVER表示consul的server模式，表明这个consul是个server，这种模式下，功能和CLIENT都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。 @server-leader 中间那个SERVER下面有LEADER的字眼，表明这个SERVER是它们的老大，它和其它SERVER不一样的一点是，它需要负责同步注册的信息给其它的SERVER，同时也要负责各个节点的健康监测。 @raft server节点之间的数据一致性保证，一致性协议使用的是raft，而zookeeper用的paxos，etcd采用的也是raft。 @服务发现协议 consul采用http和dns协议，etcd只支持http @服务注册 consul支持两种方式实现服务注册，一种是通过consul的服务注册http API，由服务自己调用API实现注册，另一种方式是通过json个是的配置文件实现注册，将需要注册的服务以json格式的配置文件给出。consul官方建议使用第二种方式。 @服务发现 consul支持两种方式实现服务发现，一种是通过http API来查询有哪些服务，另外一种是通过consul agent 自带的DNS（8600端口），域名是以NAME.service.consul的形式给出，NAME即在定义的服务配置文件中，服务的名称。DNS方式可以通过check的方式检查服务。 @服务间的通信协议 Consul使用gossip协议管理成员关系、广播消息到整个集群，他有两个gossip  pool（LAN pool和WAN pool），LAN pool是同一个数据中心内部通信的，WAN pool是多个数据中心通信的，LAN pool有多个，WAN pool只有一个。   二、consul集群搭建 1）安装 首先去官网现在合适的consul包：https://www.consul.io/downloads.html 安装直接下载zip包，解压后只有一个可执行的文件consul，将consul添加到系统的环境变量里面。 #unzip consul_1.2.3_linux_amd64.zip #cp -a consul  /usr/bin #consul

输入consul，出现上面的内容证明安装成功。   2）启动 consul必须启动agent才能使用，有两种启动模式server和client，还有一个官方自带的ui。server用与持久化服务信息，集群官方建议3或5个节点。client只用与于server交互。ui可以查看集群情况的。 server： cn1： #consul agent  -bootstrap-expect 2  -server   -data-dir /data/consul0 -node=cn1 -bind=192.168.1.202 -config-dir /etc/consul.d -enable-script-checks=true  -datacenter=dc1 cn2: #consul agent    -server  -data-dir /data/consul0 -node=cn2 -bind=192.168.1.201 -config-dir /etc/consul.d -enable-script-checks=true  -datacenter=dc1  -join 192.168.1.202 cn3: #consul agent  -server  -data-dir /data/consul0 -node=cn3 -bind=192.168.1.200 -config-dir /etc/consul.d -enable-script-checks=true  -datacenter=dc1  -join 192.168.1.202 参数解释： -bootstrap-expect:集群期望的节点数，只有节点数量达到这个值才会选举leader。 -server： 运行在server模式 -data-dir：指定数据目录，其他的节点对于这个目录必须有读的权限 -node：指定节点的名称 -bind：为该节点绑定一个地址 -config-dir：指定配置文件，定义服务的，默认所有一.json结尾的文件都会读 […]