IntelliJ IDEA 2022.1 EAP 3 已发布，第三个 EAP 版本带来了捆绑的 Kotlin 1.6.20-M1 插件、调试器的 UI 增强、Markdown 编辑器的改进等等内容，下面摘录一部分新功能作介绍：

Kotlin 1.6.20-M1 插件捆绑

IntelliJ IDEA 2022.1 的新 EAP 版本捆绑了 Kotlin 1.6.20-M1 插件，这意味着 IDE 预览版本支持最新的语言功能。 

第一个 Kotlin 1.6.20 预览版引入了许多值得注意的更新，例如对并行编译的支持、上下文接收器的原型、所有 Kotlin 目标之间更好的代码共享等等

调试器 UI 改进

• 重置框架（Reset Frame）功能

在 Frames 视图中，有一个新的内联 Reset Frame 图标，可用于删除选定的框架和所有嵌套的框架。（此操作以前可从工具栏中获得）

• 默认隐藏选项卡标签

为了最大化 调试器 工具窗口中的可用空间，IntelliJ IDEA 2022.1 EAP 3 默认隐藏了选项卡标签。

如果需要重新显示或自定义它们的位置，请使用布局设置中的 Show Tab Labels 选项，或通过 Search Everywhere（macOS 上的 ⇧⇧ /Windows/Linux 上的 Shift+Shift ）调用它，并聚焦调试 工具窗口。

更新了 Markdown 编辑器浮动工具栏

为了更容易格式化 Markdown 文件，IntelliJ IDEA 2022.1 EAP 3 重新设计了出现在文本选择上方的浮动工具栏。除了新设计之外，工具栏现在还提供创建列表功能和一个允许选择标题样式的下拉菜单。

该浮动工具栏是可自定义的，可以使用所需的选项去填充它，在 设置 | 首选项 | 外观与行为 | 菜单和工具栏 | Markdown 编辑器浮动工具栏 中进行设置：

新建项目向导中的 Maven Archetype 优化

作为新建项目向导的 UI 改造的一部分，IntelliJ IDEA 重新设计了 Maven Archetype 项目生成器，该  2022.1 EAP 3 版本在浏览原型时引入了“键入时搜索”功能，以及在模块创建期间管理原型目录的能力。

此外，还可以按原型输入所需的属性：

以上是 IntelliJ IDEA 2022.1 EAP 3 版本提供的较显著的改进，可以在发行说明中找到完整的更新列表。 

Grafana 8.4.1 现已发布。Grafana 是一个功能丰富的指标标准仪表板和图形编辑器，用于分析和监控 Graphite、Elasticsearch、OpenTSDB、Prometheus 和 InfluxDB。

该版本具体更新内容如下：

Features and enhancements

• Cloudwatch：添加对 AWS/PrivateLink* 指标和维度的支持。#45515
• Configuration：添加自定义 okta 登录按钮名称和图标的功能。#44079
• Tempo：使用 AsyncSelect 组件切换 Select 以在 Tempo Search 中获取加载状态。#45110

Bug 修复

• Alerting：通过使 send_alerts_to 字段可为空来修复迁移。#45572

更新说明：https://github.com/grafana/grafana/releases/tag/v8.4.1

PhpStorm 2022.1 早期访问计划的第三个版本现已推出，该版本聚焦于对数组形状和注释的增强支持，下面来介绍一下：

多行和嵌套数组形状

PhpStorm 2021.2 在 PHPDoc 块中引入了对数组形状的支持。但是，它有一个很大的限制——仅支持单行和单级注释。如果要获得多行支持，可以选择使用属性，但是它仍然不支持嵌套结构。

PhpStorm 2022.1 EAP 3 在 PHPDoc 和属性中添加了对多行和嵌套数组形状的完全支持：

在这种情况下，可以使用数组形状注释定义数组结构，以获得键的代码补全并推断值的类型。

也可以在 PhpStorm 中使用 Booth PHPDoc 和 Attribute 语法，这些语法支持返回类型和参数类型定义：

除了多行和嵌套注释支持外，数组形状还有许多其他改进。

支持带数字键的数组形状

支持类对象数组中的特定数组

支持数组形状的列表

支持 @var 变量用法的数组形状注释

对 Vue 的改进

 JetBrains 的 IDE 2022.1 版本对 Vue 3 进行了多项改进，PhpStorm 整合了 WebStorm 对 HTML/CSS/JS 和其他 Web 技术的所有改进。在此版本中，如果你将组件定义为全局，IDE 将在你的 .vue 文件中识别它们。

PhpStorm 也正确支持 createApp 语法，它将正确匹配使用 createApp 相关素创建的应用程序。

此版本还包括对 Nuxt 3 的支持。

PhpStorm 2022.1 EAP #3 发行说明中提供了完整的更改列表，包括错误修复和改进。

操作项 命令内容
JVM超时（controller层http方法超时）
https://www.xujun.org/blade create jvm delay –time 2000 –classname=$1 –methodname=$2 –pid 1
JVM异常（controller层http方法异常）
https://www.xujun.org/blade create jvm throwCustomException –classname=$1–methodname=$2 –exception java.lang.Exception –pid 1
dubbo类超时
https://www.xujun.org/blade create dubbo delay –time $1 –service $2 –methodname $3 –consumer –pid 1
dubbo类异常
https://www.xujun.org/blade create dubbo throwCustomException –exception java.lang.Exception –service $1 –methodname $2 –consumer –pid 1
redis超时
https://www.xujun.org/blade c jedis delay –time $1
redis异常
https://www.xujun.org/blade c jedis throwCustomException –exception java.lang.Exception –exception-message “chaosblade mock Error”
redis线程池打满
https://www.xujun.org/blade c jvm throwCustomException –exception java.lang.Exception –classname org.apache.commons.pool2.impl.GenericObjectPool –methodname borrowObject –pid 1
Mybatis超时
https://www.xujun.org/blade c jvm delay –time $1 –classname org.apache.ibatis.binding.MapperMethod –methodname execute –pid 1
Mybatis异常
https://www.xujun.org/blade c jvm throwCustomException –exception java.lang.Exception –classname org.apache.ibatis.binding.MapperMethod –methodname execute –pid 1
CPU打满
https://www.xujun.org/blade create cpu load
内存打满
https://www.xujun.org/blade c mem load –mode ram –mem-percent 100
磁盘空间打满
https://www.xujun.org/blade c disk fill –percent 100
磁盘读写IO打满
https://www.xujun.org/blade create disk burn –read –write
JVM堆内存OOM
https://www.xujun.org/blade c jvm oom –area HEAP

首先，让我们定义一下 Kubernetes 中 hard-way 的概念：Kubernetes 中的困难方式是为了学习和应用每一步，但是你要了解该步骤背后的内容。因此，您每一个命令都会发生神奇的事情，最后通过一个很长的路径和命令才能升级您的集群。第一次看起来可能很难，但这将是您之后升级的经验积累，因为您将熟悉每个 Kubernetes 升级组件，因为您将使用大量命令工具，这可以帮助您进行故障排除并为您提供更多的集群可控性。

现在让我们跳到一个演示中，用我们的双手来操作命令行。我们将把一个集群从1.22版升级到1.23版。

前提条件

• 确保备份所有重要组件，例如存储在数据库中的应用状态。Kubernetes 升级不涉及正常的工作负载，只涉及与 Kubernetes 相关的组件，但备份始终是最佳实践。

• 必须禁用Swap交换

步骤

master节点

1. 清空主节点

驱逐/删除主节点的所有 Pod（镜像 Pod 除外）（不能通过 API 服务器删除），以便能够执行升级。如果有 ，drain 不会在没有  的情况下继续进行，因为这些 pods 将立即被 daemon set 控制器替换，它会忽略不可调度的标记。

Draining 成功后，您可以检查节点的状态以确保它是SchedulingDisabled，这意味着该节点上不能调度任何 Pod。

1. 更新系统中的包管理器，根据您的操作系统，它可能会有所不同。

1. 在包管理器中搜索可用的 kubeadm 包，并使用 grep 过滤结果以获得您需要的版本。在我们的例子中是 1.23 版本。

输出应类似于以下内容：

1. 保留 kubectl 和 kubelet包，防止它们被自动安装、升级或删除。这是一个预防措施。

1. 取消保留 kubeadm 包，升级后再次 hold。

1. 检查 kubeadm版本以确保它已升级。

kubeadm 版本

1. 查看kubeadm升级计划，看看还有哪些组件需要升级。

kubeadm 升级计划

1. 应用计划，你应该可以看到升级成功的消息

1. 取消保留 kubectl 和 kubelet包，升级它们然后再次持有它们。

请注意，如果您要复制此内容，您可能需要删除“-”并在终端中再次输入，因为它可能被视为拼写错误。

1. 重新启动 kubelet 并检查是否正常运行。

1. 运行 kubeadm upgrade plan check以确保一切都已升级。

kubeadm 升级检查

1. 检查节点状态和主节点的新版本。

1. 解封主节点，使其再次可调度

这里我们完成了主节点，让我们移动到工作节点

worker 节点

我们将重复使用以下相同的命令

1. 清空主节点

您可能需要使用“force”参数来强制驱逐一些 pod。

1. 更新包管理器。取消保留，安装 kubeadm。

1. 取消保留，安装，然后保留 kubectl 和 kubeadm。

1. 重启kubelet进程并检查其状态

1. 检查节点状态

1. 解封worker节点，使其再次可调度

至此升级成功！！

结论

我们将 Kubernetes 集群版本从 1.22.2 升级到 1.23.1 Kubeadm 包升级到 1.23.1 版本，然后使用 kubeadm 升级集群的其他组件。Kubectl 和 Kubelet 升级到同一个版本 1.23.1 一般来说，基本步骤就是清空节点，取消持有安装包，升级它然后再次持有它，最后解封节点。

 1、Dos 攻击防范（自动屏蔽攻击 IP）

2、Linux 系统发送告警脚本

3、MySQL 数据库备份单循环

4、MySQL 数据库备份多循环

5、Nginx 访问访问日志按天切割

6、Nginx 访问日志分析脚本

7、查看网卡实时流量脚本

8、服务器系统配置初始化脚本

9、监控 100 台服务器磁盘利用率脚本

本篇分享在编写 Dockerfiles 和使用 Docker 时应遵循的一些最佳实践。篇幅较长，建议先收藏慢慢看，保证看完会很有收获。

文章目录

Dockerfile 最佳实践

1. 使用多阶段的构建

2. 调整 Dockerfile 命令的顺序

3. 使用小型 Docker 基础镜像

4. 尽量减少层的数量

5. 使用无特权的容器

6. 优先选择  而不是 

7. 将  包缓存到 Docker 主机上

8. 每个容器只运行一个进程

9. 优先选择数组而不是字符串语法

10. 理解  和  之间的区别

11. 添加健康检查 

Docker 镜像最佳实践

1. Docker 镜像的版本

2. 不要在图像中存储密钥

3. 使用  文件

4. 检查和扫描你的 Docker 文件和镜像

5. 签署和验证图像

6. 设置内存和 CPU 的限制

Dockerfile 最佳实践

1. 使用多阶段的构建

利用多阶段构建的优势来创建更精简、更安全的Docker镜像。多阶段 Docker 构建(multi-stage builds[1])允许你将你的 Dockerfile 分成几个阶段。

例如，你可以有一个阶段用于编译和构建你的应用程序，然后可以复制到后续阶段。由于只有最后一个阶段被用来创建镜像，与构建应用程序相关的依赖关系和工具就会被丢弃，因此可以留下一个精简的、模块化的、可用于生产的镜像。

Web 开发示例：

在这个例子中，GCC 编译器在安装某些 Python 包时是必需的，所以我们添加了一个临时的、构建时的阶段来处理构建阶段。

由于最终的运行时映像不包含 GCC，所以它更轻，也更安全。镜像大小比较：

再来看一个例子：

镜像大小比较：

总之，多阶段构建可以减少你的生产镜像的大小，帮助你节省时间和金钱。此外，这将简化你的生产容器。由于尺寸较小和简单，相对会有较小的攻击面。

2. 调整 Dockerfile 命令的顺序

密切注意你的 Dockerfile 命令的顺序，以利用层缓存。

Docker 在一个特定的 Docker 文件中缓存每个步骤（或层），以加快后续的构建。当一个步骤发生变化时，不仅该步骤，而且所有后续步骤的缓存都将被废止。

例如：

在这个 Dockerfile 中，我们在安装需求之前复制了应用程序的代码。现在，每次我们改变 sample.py 时，构建都会重新安装软件包。这是非常低效的，特别是在使用 Docker 容器作为开发环境时。因此，把经常变化的文件放在 Dockerfile 的末尾是很关键的。

你也可以通过使用 .dockerignore 文件来排除不必要的文件，使其不被添加到 Docker 构建环境和最终镜像中，从而帮助防止不必要的缓存失效。更多信息后面会提到。

因此，在上面的 Dockerfile 中，你应该把  命令移到底部，如下所示：

注意。

1. 总是把可能发生变化的层放在 Dockerfile 中尽可能的低。

2. 将多个 ， 等命令结合到一起执行。(这也有助于减少镜像的大小，后面会很快就会提到这一点)。

3. 如果你想关闭某个 Docker 构建的缓存，可以添加  标志。

3. 使用小型 Docker 基础镜像

较小的 Docker 镜像更具有模块化和安全性。较小的 Docker 基础镜像在构建、推送和拉动镜像的速度较小，它们也往往更安全，因为它们只包括运行应用程序所需的必要库和系统依赖。

你应该使用哪个 Docker 基础镜像？这个没有一个固定的答案，它这取决于你要做什么。下面是 Python 的各种 Docker 基础镜像的大小比较。

虽然基于 Alpine Linux 的 Alpine flavor 是最小的，但如果你找不到可以与之配合的编译二进制文件，往往会导致构建时间的增加。因此，你最终可能不得不自己构建二进制文件，这可能会增加图像的大小（取决于所需的系统级依赖）和构建时间（由于必须从源头编译）。

关于为什么最好不要使用基于 Alpine 的基础镜像，请参考适用于 Python 应用程序的最佳 Docker 基础映像[2] 和 使用 Alpine 可以使 Python Docker 构建速度慢 50 倍[3] 了解更多关于为什么最好避免使用基于 Alpine 的基础图像。

归根结底，这都是关于平衡的问题。如果有疑问，从  flavor 开始，特别是在开发模式下，因为你正在构建你的应用程序。你想避免在添加新的  包时不得不不断地更新 Dockerfile 以安装必要的系统级依赖。当你为生产强化你的应用程序和 Dockerfile 时，你可能想探索使用 Alpine 来完成多阶段构建的最终镜像。

另外，别忘了定期更新你的基础镜像，以提高安全性和性能。当一个基础镜像的新版本发布时，例如： –> ，你应该拉出新的镜像并更新你正在运行的容器以获得所有最新的安全补丁。

4. 尽量减少层的数量

尽量把 、 和  命令结合起来使用，因为它们会创建层。每一层都会增加图像的大小，因为它们是被缓存的。因此，随着层数的增加，镜像大小也会增加。

你可以用  命令来测试一下。

请注意尺寸。只有 、 和  命令增加了图像的尺寸，你可以尽可能地通过合并命令来减少图像的大小。比如：

可以合并成一个  命令：

因此，创建一个单层而不是两个，这就减少了最终图像的大小。虽然减少层数是个好主意，但更重要的是，这本身不是一个目标，而是减少镜像大小和构建时间的一个副作用。换句话说呢，与其试图优化每一条命令，你更应该关注前面的三种做法！！！

1. 多阶段构建

2. Dockerfile命令的顺序

3. 以及使用一个小的基础镜像。

注意

1. 、 和  都会创建图层

2. 每个图层都包含与前一个图层的差异

3. 图层会增加最终图像的大小

提示

1. 合并相关命令

2. 在创建过程中执行  步骤中删除不必要的文件

3. 尽量减少运行  的次数，因为它将所有软件包升级到最新版本。

4. 对于多阶段的构建，不要太担心过度优化临时阶段的命令

最后，为了便于阅读，建议将多行参数按字母数字排序。

5. 使用无特权的容器

默认情况下，Docker 在容器内以 root 身份运行容器进程。然而，这是一个糟糕的做法，因为在容器内以 root 身份运行的进程在 Docker 主机中也是以 root 身份运行。

因此，如果攻击者获得了对容器的访问权，他们就可以获得所有的 root 权限，并可以对 Docker 主机进行一些攻击，例如：

1. 将敏感信息从主机的文件系统复制到容器中

2. 执行远程命令

为了防止这种情况，确保以非 root 用户运行容器进程。

你可以更进一步，删除 shell 权限，确保没有主目录。

验证

在这里，容器内的应用程序在一个非 root 用户下运行。然而，请记住，Docker 守护进程和容器本身仍然是以 root 权限运行的。

请务必查看以非根用户身份运行 Docker 守护进程，以获得以非根用户身份运行守护进程和容器的帮助。

6. 优先选择  而不是 

除非你确定你需要  所带来的额外功能，否则请使用 。

那么  和  的区别是什么？

首先，这两个命令都允许你从一个特定的位置复制文件到 Docker 镜像中。

虽然它们看起来作用相同，但  有一些额外的功能。

•  用于将本地文件或目录从 Docker 主机复制到镜像上。

•  可以用于同样的事情，也可以用于下载外部文件。另外，如果你使用压缩文件（tar、gzip、bzip2等）作为参数， 会自动将内容解压到指定位置。

最后  在语义上比  更加明确和更容易理解。

7. 缓存安装包到 Docker 主机上

当一个需求文件被改变时，镜像需要被重建以安装新的包。先前的步骤将被缓存，正如在最小化层数中提到的。在重建镜像时下载所有的包会导致大量的网络活动，并需要大量的时间。每次重建都要占用同等的时间来下载不同构建中的通用包。

以 Python 为例，你可以通过将 pip 缓存目录映射到主机上的一个目录来避免这种情况。所以对于每次重建，缓存的版本会持续存在，这可以提高构建速度。

在 Docker 运行中添加一个卷，作为  或者作为 Docker Compose 文件中的映射。

上面介绍的目录只供参考，要确保你映射的是 cache 目录，而不是 site-packages（内置包所在的位置）。

将缓存从 docker 镜像中移到主机上可以为你节省最终镜像的空间。

8. 每个容器只运行一个进程

为什么建议每个容器只运行一个进程？

让我们假设你的应用程序栈由两个 Web 服务器和一个数据库组成。虽然你可以很容易地从一个容器中运行所有三个，但你应该在一个单独的容器中运行每个服务，以便更容易重复使用和扩展每个单独的服务。

• 扩展性 – 由于每个服务都在一个单独的容器中，你可以根据需要水平地扩展你的一个网络服务器来处理更多的流量。

• 可重用性 – 也许你有另一个服务需要一个容器化的数据库，你可以简单地重复使用同一个数据库容器，而不需要带着两个不必要的服务。

• 日志 – 耦合容器会让日志变得更加复杂。（我们将在本文后面进一步详细讨论这个问题）

• 可移植性和可预测性 – 当容器有较少的部分在工作时，制作安全补丁或调试问题就会容易得多。

9. 优先选择数组而不是字符串语法

你可以在你的 Dockerfiles 中以数组（exec）或字符串（shell）格式

在 Dockerfile 中，你可以以数组（exec）或字符串（shell）格式来使用  和  命令

两者都是正确的，并且实现了几乎相同的事情；但是，你应该尽可能地使用 exec 格式。

以下来自 Docker的官方文档[4]内容：

• 确保你在 Dockerfile 中使用  和  的 exec 形式。

• 例如，使用  而不是 。使用字符串形式会导致 Docker 使用  运行你的进程，而  并不能正确处理信号。Compose 总是使用 JSON 形式，所以不用担心如果你在你的 Compose 文件中覆盖了命令或入口。

因此，由于大多数 shell 不处理对子进程的信号，如果你使用 shell 格式，CTRL-C（产生 ）可能不会停止一个子进程。

例子:

这两种情况执行效果一样。但请注意，在字符串（shell）格式的情况下， 不会杀死这个进程。相反，你会看到 。

另一个注意事项是，字符串（shell）格式携带的是 shell 的 PID，而不是进程本身。

10. 了解  和  之间的区别

我应该使用  还是  来运行容器进程？有两种方法可以在容器中运行命令。

两者本质上做的是同一件事：用  服务器在  启动应用程序，并将其绑定到 。

 很容易被重写。如果你运行 ，上述  就会被新的参数所取代。

例如，。而要覆盖  命令，必须指定  选项。

在这里，很明显，我们正在覆盖入口点。所以，建议使用  而不是 ，以防止意外地覆盖命令。

它们也可以一起使用。比如说

当像这样一起使用时，为启动容器所运行的命令就变成了：

如上所述， 很容易被重写。因此， 可以被用来向  命令传递参数。比如很容易更改 workers 的数量，就像这样：

这样就将有 6 个 Gunicorn workers 启动容器，而不是默认的 4 个。

11. 添加健康检查 

使用  来确定容器中运行的进程是否不仅已启动并正在运行，而且是“健康”的。

Docker 公开了一个 API 来检查容器中运行的进程的状态，它提供的信息不仅仅是进程是否“正在运行”，因为“运行”涵盖了“它正在运行”、“仍在启动”、甚至“陷入某种无限循环错误状态”。你可以通过 `HEALTHCHECK`[5] 指令与此 API 交互。

例如，如果你正在提供 Web 应用程序，则可以使用以下内容来确定  端点是否已启动并可以处理服务请求：

如果你运行 ，你可以看到  的状态。

健康的示例

不健康的示例

你可以更进一步，设置一个仅用于健康检查的自定义端点，然后配置  以针对返回的数据进行测试。

例如，如果端点返回  的 JSON 响应，你可以指示  验证响应正文。

以下是使用  查看运行状况检查状态的方法：

这里省略了部分输出。

你还可以向 Docker Compose 文件添加运行状况检查：

选项：

• ：要测试的命令。

• ：要测试的间隔 – 即，测试每 x 时间单位。

• ：等待响应的最长时间。

• ：何时开始健康检查。它可以在容器准备就绪之前执行其他任务时使用，例如运行迁移。

• ：在将测试指定为失败之前的最大重试次数。

如果你使用的是 Docker Swarm 以外的编排工具（比如 Kubernetes 或 AWS ECS），它们很可能有自己的内部系统来处理健康检查。在添加  指令之前，请参阅特定工具的文档。

Docker 镜像最佳实践

1. Docker 镜像版本

只要有可能，就要避免使用  标签的镜像。

如果你依赖  标签（这并不是一个真正的 “标签”，因为当图像没有明确的标签时，它是默认应用的），你无法根据镜像标签来判断你的代码正在运行哪个版本。

如果你想回滚就变得很困难，并且很容易被覆盖（无论是意外还是恶意的）。标签，就像你的基础设施和部署，应该是不可改变的。

所以无论你如何对待你的内部镜像，都不应该对基本镜像使用  标签，因为你可能会无意中把一个带有破坏性变化的新版本部署到生产中。

对于内部镜像，应使用描述性的标签，以便更容易分辨哪个版本的代码正在运行，处理回滚，并避免命名冲突。例如，你可以使用以下描述符来组成一个标签。

1. 时间戳

2. Docker 镜像 ID

3. Git 提交哈希值

4. 语义版本 (Semantic version)

关于更多的选择，也可以参考 Stack Overflow 问题[6] “Properly Versioning Docker Images” 中的这个答案。

比如说

在这里，我们用下面的内容来形成标签

1. 项目名称：web

2. 环境名称: prod

3. Git commit short hash: b25a262 (通过命令  来获得)

4. 语义学版本：1.0.0

选择一个标签方案并与之保持一致是至关重要的。由于提交哈希值（commit hashes）可以很容易地将镜像标签与代码联系起来，建议将它们纳入你的标签方案。

2. 不要在镜像中存储机密信息

Secrets 是敏感的信息，如密码、数据库凭证、SSH密钥、令牌和 TLS 证书等。这些信息不应该在没有加密的情况下被放入你的镜像中，因为未经授权的用户如果获得了镜像的访问权，只需要检查这些层就可以提取密钥。

因此不要在 Docker 文件中添加明文的密钥，尤其是当你把镜像推送到像 Docker Hub 这样的公共仓库！！

相反，它们应该通过以下方式注入

1. 环境变量（在运行时)

2. 构建时参数（在构建时)

3. 协调工具，如 Docker Swarm（通过 Docker secrets）或 Kubernetes（通过 Kubernetes secrets）。

此外，你还可以通过在你的  文件中添加常见的密钥文件和文件夹来帮助防止密钥的泄露。

最后，要明确哪些文件会被复制到镜像中，而不是递归地复制所有文件。

明确的做法也有助于限制缓存的破坏。

环境变量

你可以通过环境变量来传递密钥，但它们会在所有子进程、链接的容器和日志以及  中可见。要更新它们也很困难。

这是最直接的密钥管理方法。虽然它不是最安全的，但它会让诚实的人保持诚实，因为它提供了一个薄薄的保护层，有助于使密钥不被好奇的游荡的眼睛发现。

使用共享卷传递密钥是一个更好的解决方案，但它们应该被加密，通过 Vault 或 AWS密钥管理服务（KMS），因为它们被保存到磁盘。

构建时参数

你可以在构建时使用构建时参数来传递密钥，但这些密钥对于那些可以通过 docker 历史访问镜像的人来说是可见的。

例子

构建

如果你只需要临时使用密钥作为构建的一部分。例如，用于克隆私有 repo 或下载私有软件包的 SSH 密钥。你应该使用多阶段构建，因为构建者的历史会被临时阶段忽略。

多阶段构建只保留了最终镜像的历史。你可以把这个功能用于你的应用程序需要的永久密钥，比如数据库凭证。

你也可以使用 docker build 中新的  选项来向 Docker 镜像传递密钥，这些密钥不会被存储在镜像中。

这将装载  文件中的密钥。

构建镜像

最后，检查历史记录，看看密钥是否泄露了。

Docker 密钥

如果你正在使用 Docker Swarm，你可以用 Docker secrets 来管理密钥。

例如，启动 Docker Swarm 模式。

创建一个 docker 密钥。

当一个容器被赋予上述密钥的访问权时，它将挂载在 。这个文件将包含明文的密钥的实际值。

使用其他的编排工具？

• 使用 AWS Secrets Manager 的密钥与 Kubernetes 的密钥[7]

• DigitalOcean Kubernetes – 保护 DigitalOcean Kubernetes 集群的推荐步骤[8]

• Google Kubernetes引擎 – 与其他产品一起使用密钥管理器[9]

• Nomad – Vault 集成和检索动态密钥[10]

3. 使用 .dockerignore 文件

之前已经提到过几次使用  文件。这个文件用来指定你不希望被添加到发送给 Docker 守护进程的初始构建上下文中的文件和文件夹，后者将构建你的镜像。换句话说，你可以用它来定义你需要的构建环境。

当一个 Docker 镜像被构建时，整个 Docker 上下文 – 即你的项目的根在  或  命令执行之前就被发送给了 Docker 守护进程。

这可能是相当费资源，尤其是当你的项目中有许多依赖关系、大量的数据文件或构建工件时。

另外，当 Docker CLI 和守护程序不在同一台机器上。比如守护进程是在远程机器上执行的，你就更应该注意构建环境的大小了。

你应该在  文件中添加什么？

1. 临时文件和文件夹

2. 构建日志

3. 本地 secrets

4. 本地开发文件，如 

5. 版本控制文件夹，如 “.git”、”.hg” 和 “.vscode” 等

例子：

总之，结构合理的 .dockerignore 可以帮助

1. 减少 Docker 镜像的大小

2. 加快构建过程

3. 防止不必要的缓存失效

4. 防止泄密

4. 检查并扫描你的 Dockerfile 和图像

Linting 是检查源代码中是否存在可能导致潜在缺陷的编程和风格错误以及不良做法的过程。就像编程语言一样，静态文件也可以被 lint。特别是对于你的 Dockerfile，linter 可以帮助确保它们的可维护性、避免弃用语法并遵守最佳实践。整理图像应该是 CI 管道的标准部分。

Hadolint[11] 是最流行的 Dockerfile linter：

这是 Hadolint 一个在线的链接 https://hadolint.github.io/hadolint/ 也可以安装 VS Code 插件[12]

你可以将 Dockerfile 与扫描图像和容器的漏洞结合使用。

以下是一些有影响力的镜像扫描工具：

• Snyk[13] 是 Docker 本地漏洞扫描的独家提供商。你可以使用  CLI 命令来扫描图像。

• Trivy[14] 可用于扫描容器镜像、文件系统、git 存储库和其他配置文件。

• Clair[15] 是一个开源项目，用于对应用程序容器中的漏洞进行静态分析。

• Anchore[16] 是一个开源项目，为容器镜像的检查、分析和认证提供集中式服务。

总而言之，对你的 Dockerfile 和图像进行 lint 和扫描，来发现任何偏离最佳实践的潜在问题。

5. 签名和验证图像

你怎么知道用于运行生产代码的图像没有被篡改？

篡改可以通过中间人（MITM）攻击或注册表被完全破坏来实现。Docker 内容信任（DCT）可以对来自远程注册中心的 Docker 镜像进行签名和验证。

为了验证镜像的完整性和真实性，请设置以下环境变量。

现在，如果你试图拉一个没有被签名的镜像，你会收到以下错误。

你可以从使用 Docker 内容信任签署图像文档中了解签署图像的情况。

当从 Docker Hub下 载图像时，确保使用官方图像或来自可信来源的经过验证的图像。较大的团队应该使用他们自己的内部私有容器仓库

6. 设置内存和 CPU 的限制

限制 Docker 容器的内存使用是一个好主意，特别是当你在一台机器上运行多个容器时。这可以防止任何一个容器使用所有可用的内存，从而削弱其他容器的功能。

限制内存使用的最简单方法是在 Docker cli 中使用  和  选项。

上述命令将容器的使用限制在 2 个 CPU 和 512 兆的内存。

你可以在 Docker Compose 文件中做同样的事情，像这样。

请注意  字段。它是用来设置软限制的，当主机的内存或CPU资源不足时，它就会优先考虑。

其他相关资源

1. 带有内存、CPU和GPU的运行时选项：https://docs.docker.com/config/containers/resource_constraints/

2. Docker Compose 的资源限制：https://docs.docker.com/compose/compose-file/compose-file-v3/#resources

总结

以上就是本文介绍的 17 条最佳实践，掌握这些最佳实践一定会让你的 Dockerfile 和 Docker Image 变得精简，干净，和安全。

• 1.1 安装Docker

  • Ubuntu 16.04 安装 Docker

• 1.2 使用Docker

• 2.1 安装 Java 与 Scala

  • 2.1.1 修改 apt 源

  • 2.1.2 安装 Scala 与 Java

• 2.2 安装 Hadoop

  • 2.2.1 安装 Vim 与 网络工具包

  • 2.2.2 安装 SSH

  • 2.2.3 安装 Hadoop

  • 2.2.4 在 Docker 中启动集群

  • 2.2.5 运行内置WordCount例子

绪论

使用Docker搭建Hadoop技术平台，包括安装Docker、Java、Scala、Hadoop

集群共有5台机器，主机名分别为 h01、h02、h03、h04、h05。其中 h01 为 master，其他的为 slave。

• JDK 1.8

• Scala 2.11.6

• Hadoop 3.2.2 【原文是3.2.0，但软件源已失效】

1. Docker

1.1 安装Docker

Ubuntu 16.04 安装 Docker

1.2 使用Docker

现在的 Docker 网络能够提供 DNS 解析功能，我们可以使用如下命令为接下来的 Hadoop 集群单独构建一个虚拟的网络。

以上命令创建了一个名为 Hadoop 的虚拟桥接网络，该虚拟网络内部提供了自动的DNS解析服务。

使用下面这个命令查看 Docker 中的网络，可以看到刚刚创建的名为  的虚拟桥接网络。

查找 ubuntu 容器

下载 ubuntu 16.04 版本的镜像文件

查看已经下载的镜像

根据镜像启动一个容器，可以看出 shell 已经是容器的 shell 了

输入  可以退出容器

查看本机上所有的容器

启动一个状态为退出的容器，最后一个参数为容器 ID

进入一个容器

并不是所有容器都可以这么干

查看正在运行的容器

关闭一个容器

以上，Docker 的基础使用，在下面会用到，大部分的操作都会在容器里完成，比用虚拟机安装好多了。

2. 安装集群

主要是安装 JDK 1.8 的环境，因为 Spark 要 Scala，Scala 要 JDK 1.8，以及 Hadoop，以此来构建基础镜像。

2.1 安装 Java 与 Scala

进入之前的 Ubuntu 容器

先更换  的源

2.1.1 修改 apt 源

备份源

先删除源文件，这个时候没有 vim 工具..

使用  命令将源写入新文件

阿里源如下

再使用  来更新

2.1.2 安装 Scala 与 Java

直接输入命令

来安装 jdk 1.8

测试一下安装结果

再输入

直接安装 Scala

测试一下安装结果

按  退出 Scala 的交互模式

2.2 安装 Hadoop

• 在当前容器中将配置配好

• 导出为镜像

• 以此镜像为基础创建五个容器，并赋予 hostname

• 进入 h01 容器，启动 Hadoop

2.2.1 安装 Vim 与 网络工具包

安装 vim，用来编辑文件

安装 net-tools

2.2.2 安装 SSH

安装 SSH，并配置免密登录，由于后面的容器之间是由一个镜像启动的，就像同一个模具出来的 5 把锁与钥匙，可以互相开锁。所以在当前容器里配置 SSH 自身免密登录就 OK 了。

安装 SSH

安装 SSH 的客户端

进入当前用户的用户根目录

生成密钥，不用输入，一直回车就行，生成的密钥在当前用户根目录下的  文件夹中

以  开头的文件与文件夹  是看不到的，需要  才能查看。

将公钥追加到 authorized_keys 文件中

启动 SSH 服务

免密登录自己

修改  文件，启动 shell 的时候，自动启动 SSH 服务

用 vim 打开  文件

按一下  键，使得 vim 进入插入模式，此时终端的左下角会显示为 ，将光标移动到最后面，添加一行

添加完的结果为，只显示最后几行

按一下  键，使得 vim 退出插入模式

再输入英文模式下的冒号 ，此时终端的左下方会有一个冒号  显示出来

再输入三个字符 ，这是一个组合命令

• 是保存的意思

• 是退出的意思

• 是强制的意思

再输入回车，退出 vim。

此时，SSH 免密登录已经完全配置好。

2.2.3 安装 Hadoop

下载 Hadoop 的安装文件

【注：原文这里的hadoop3.2.0已失效，这里替换为清华开源软件镜像站提供的hadoop3.2.2，后续涉及到hadoop版本的地方也一并进行了更换，不再赘述】

解压到  目录下面并重命名文件夹

修改  文件，添加一下环境变量到文件中

先用 vim 打开 

追加以下内容

JAVA_HOME 为 JDK 安装路径，使用 apt 安装就是这个，用  可查看

【注：原文中处变量地址有误，应为，本文已做出修正 】

使环境变量生效

在目录  下

• 修改 hadoop-env.sh 文件，在文件末尾添加一下信息

• 修改 core-site.xml，修改为

• 修改 hdfs-site.xml，修改为

• 修改 mapred-site.xml，修改为

• 修改 yarn-site.xml，修改为

• 修改 workers 为

【注：原文中文件名为误写，当前目录中的文件名实为】

此时，hadoop已经配置好了

2.2.4 在 Docker 中启动集群

先将当前容器导出为镜像，并查看当前镜像

【注：原文里此处及以下命令中，镜像名作者均误写为，实为，本文已修正】

启动 5 个docker终端，分别执行这几个命令

第一条命令启动的是  是做 master 节点的，所以暴露了端口，以供访问 web 页面

–network hadoop 参数是将当前容器加入到名为  的虚拟桥接网络中，此网站提供自动的 DNS 解析功能

启动后退回到用户，继续启动

其余的四条命令就是几乎一样的了

【注：此处代码可以进行优化。为减少进入/退出容器与反复输密码的操作，可以在指令中添加参数。以为例，具体代码为，运行完毕后只返回容器ID，依然处于当前用户中。同理。】

接下来，在  主机中，启动 Haddop 集群

先进行格式化操作

不格式化操作，hdfs会起不来

进入 hadoop 的 sbin 目录

启动

【注：这步很容易报错，前面步骤中很多细节都会导致结点拉不起来。如果报 等错误，先去查下面的几个配置文件是否配置正确（比如忘记删），如果仍然排除不了，仔细查看报错原因，然后借助网络求助。】

访问本机的 8088 与 9870 端口就可以看到监控信息了

使用命令  可查看分布式文件系统的状态

Hadoop 集群已经构建好了

2.2.5 运行内置WordCount例子

把license作为需要统计的文件

在 HDFS 中创建 input 文件夹

上传 file1.txt 文件到 HDFS 中

查看 HDFS 中 input 文件夹里的内容

运作 wordcount 例子程序

输出如下

查看 HDFS 中的 /output 文件夹的内容

查看  文件的内容

恭喜，Hadoop 部分完成了~

多年前，为了降低开发人员的OnBoarding成本，让大家的更加专注于价值业务的开发而不是花费时间搭建和管理环境，广泛采用VMWare这一类虚拟桌面的技术。而如今，随着DevOps广泛被采用，人工智能技术的崛起，云端开发环境VSCode/Jupyter Lab/Projector以及最关键的以Kubernetes为首的云原生技术成熟，让云端开发的成本以及体验较之上一代的VMWare技术有了巨大的提升。

MegaIDE正是在这一系列成熟技术以及方法论之上搭建的一套云端开发环境管理系统。它致力于解决以下三个场景：

• 降低开发人员OnBoarding的成本：开发人员不再需要折腾环境，直接打开系统，开启自己需要的云端IDE即可开始开发
• 轻松切换环境：开发人员可以开设多个属于自己的开发环境，在多套环境之间便捷的切换，提升开发效率
• 培训教学环境：助力帮助培训教学，提升教学环境的资源利用率，同时提升教学的效果
• 延长DevOps流水线： DevOps流水线一般从Gitlab开始，我们希望DevOps的流水线能够被延长至开发环节，从IDE开始

go-charts

go-charts基于go-chart，提供更简单方便的形式生成数据图表，支持与两种方式的输出，支持三种主题, 以及。

在前端开发中得到众多开发者的认可，因此提供了兼容的配置参数，简单快捷的生成相似的图表(或)，方便插入至Email或分享使用。下面为常用的图表截图(主题为light与grafana)：

支持图表类型

暂仅支持三种的图表类型：, 以及

示例

下面的示例为两种方式的参数配置：golang的参数配置、echarts的JSON配置，输出相同的折线图。 更多的示例参考：目录

ECharts参数说明

名称有[]的参数非echarts的原有参数，为的新增参数，可根据实际使用场景添加。

• 画布类型，支持与，默认为
• 颜色主题，支持、以及模式，默认为
• 字体，全局的字体设置
• 图表的内边距，单位px。支持以下几种模式的设置
  • 设置内边距为5
  • 设置上下的内边距为 5，左右的内边距为 10
  • 分别设置边距
• 图表的区域，以{“left”: Int, “right”: Int, “top”: Int, “bottom”: Int}的形式配置
• 画布宽度，默认为600
• 画布高度，默认为400
• 图表标题，包括标题内容、高度、颜色等
  • 标题文本，支持以的形式换行
  • 副标题文本，支持以的形式换行
  • 标题与容器左侧的距离，可设置为, , , 以及 这样的具体数值
  • 标题与容器顶部的距离，暂仅支持具体数值，如
  • 标题文字颜色
  • 标题文字字体大小
  • 标题文字的字体系列，需要注意此配置是会影响整个图表的字体
• 直角坐标系grid中的x轴，由于go-charts仅支持单一个x轴，因此若参数为数组多个x轴，只使用第一个配置
  • 坐标轴两边留白策略，仅支持三种设置方式, 或者。或时则数据点展示在两个刻度中间
  • 坐标轴的分割段数，需要注意的是这个分割段数只是个预估值，最后实际显示的段数会在这个基础上根据分割后坐标轴刻度显示的易读程度作调整
  • x轴的展示文案，暂只支持字符串数组，如[“Mon”, “Tue”]，其数量需要与展示点一致
• 直角坐标系grid中的y轴，最多支持两个y轴
  • 坐标轴刻度最小值，若不设置则自动计算
  • 坐标轴刻度最大值，若不设置则自动计算
  • 刻度标签的内容格式器，如
  • 坐标轴颜色
• 图表中不同系列的标记
  • 图例是否显示，如果不需要展示需要设置为
  • 图例的数据数组，为字符串数组，如[“Email”, “Video Ads”]
  • 图例标记和文本的对齐，可设置为或者，默认为标记靠左
  • legend的padding，配置方式与图表的一致
  • legend离容器左侧的距离，其值可以为具体的像素值(20)或百分比(20%)、或者
  • legend离容器顶部的距离，暂仅支持数值形式
• 图表的数据项列表
  • 图表的名称，与对应，两者只只设置其一
  • 图表的展示类型，暂支持, 以及，需要注意只能单独使用
  • 饼图的半径值，如，默认为
  • 该数据项使用的y轴，默认为0，对yAxis的配置对应
  • 是否显示文本标签(默认为对应的值)
  • 距离图形素的距离
  • 文本标签的颜色
  • 该数据项展示时使用的颜色
  • 图表的标注配置
  • 标注的大小，默认为30
  • 标注类型，仅支持数组形式，其类型只支持与，如：`[{“type”: “max”}, {“type”: “min”}]
  • 图表的标线配置
  • 标线类型，仅支持数组形式，其类型只支持、以及，如：`[{“type”: “max”}, {“type”: “min”}, {“type”: “average”}]
  • 数据项对应的数据数组，支持以下形式的数据：
    • 常用形式，数组数据为浮点数组，如[1.1, 2,3, 5.2]
    • pie图表或bar图表中指定样式使用，如[{“value”: 1048, “name”: “Search Engine”},{“value”: 735,”name”: “Direct”}]
• 嵌套的子图表参数列表，图表支持嵌套的形式=

性能

简单的图表生成PNG在20ms左右，而SVG的性能则更快，性能上比起使用加载图表展示页面再截图生成的方式大幅度提升，满足简单的图表生成需求。

中文字符

默认使用的字符为为英文字体库，因此如果需要显示中文字符需要增加中文字体库，函数可添加对应的字体库，成功添加之后则指定即可。 在浏览器中使用时，如果指定的不支持中文字符，展示的中文并不会乱码，但是会导致在计算字符宽度等错误。

V1.11.0.2.20(荣耀)  

祝贺中国喜得季军，美国紧随后面。

Bee，互联网新时代的Java ORM工具，更快、更简单、更自动，开发速度快，运行快，更智能！

Bee让程序员/软件工程师，从手工编码中解放出来，Bee更适合智能软件制造时代！

立志做最懂用户的软件!

V1.11.0.2.20(荣耀)  
multi-DS同时使用不同类型DB优化  
PreparedSql(自定义sql),MapSuid:拦截器，多数据源支持  
Suid,PreparedSql,MapSuid支持设置数据源名称,获取拦截器链  
Suid,PreparedSql,MapSuid,MoreTable增加方法:setDataSourceName,getDataSourceName,getInterceptorChain  
增加注解:
AnnotationHandler,AutoSetString自动设置字符值  
Desensitize,敏感信息模糊处理  
ReplaceInto,MySQL replace into转换  
MultiTenancy多租户  
BeforeReturnAnnotationHandler,AbstractDictI18nDefaultHandler  
Dict字典转化  
DictI18n多语言国际化字典转化  

下期功能预告:

准备向复杂的分库分表进军了。。。

近期已添加功能:

ORM 框架 Bee V1.11.0.1.1（2022新年版）发布，更快、更简单、更自动

ORM 框架 Bee V1.11.0.2.1（2022 春节版）发布，拦截器、多租户(过年不打烊)

ORM 框架 Bee V1.11.0.2.4 (2022北京冬奥版)发布,二级缓存扩展支持(Redis)

ORM 框架  2022 Romantic 版发布,加 JustFetch,Datetime 等注解和 Jndi 支持

https://gitee.com/automvc/bee#bee主要功能特点介绍

————————————————————————

Bee 是一个简单，易用，功能强大，开发速度快，编码少的 JAVA ORM 框架。连接，事务都可以由Bee框架负责管理. Bee 简化了与DB交互的编码工作量, 是 编码复杂度 为 O(1) 的Java 框架!

Bee简单易用：单表操作、多表关联操作，可以不用写sql,极少语句就可以完成SQL操作；概念简单,10分钟即可入门。
Bee功能强大：复杂查询也支持向对象方式，分页查询性能更高，一级缓存即可支持个性化优化；具有分布式特性。高级要求，还可以方便自定义SQL语句。

码云上的项目首页:

https://gitee.com/automvc/bee

https://gitee.com/automvc/bee-springboot

github:

https://github.com/automvc/bee

相关框架设计信息也可关注微信公众号：软件设计活跃区

Erupt  通用后台管理框架

Erupt 是一个低代码 全栈类 框架，它使用 Java 注解 动态构建页面，及增、删、改、查、权限控制等功能。

零前端代码、零 CURD、自动建表，仅需 一个类文件 + 简洁的注解配置，快速开发企业级 Admin 管理后台。

提供企业级中后台管理系统的全栈解决方案，大幅压缩研发周期，专注核心业务

本次更新内容 

🐞 修复erupt-monitor JVM内存占用量，显示不正确的 BUG
🐞 修复自定义首页菜单刷新后未重新跳转的 BUG
🐞 修复地图组件搜索功能不可用的 BUG
🌟 移除菜单管理编码配置，code 列用随机数填充
🌟 移除报表管理编码配置，移除图表管理编码配置
🌟 登录日志移除用户关联外键，使用当前登录的用户名字符串填充
🌟 操作日志移除用户关联外键，使用当前登录的用户名字符串填充
🌟 优化 erupt-job 启动速度
🌟 全面兼容 JDK 17
🌟 使用动态代理的方式重构注解解析
🌟 erupt-monitor 增加 erupt 类与模块统计可视化
🌟 菜单管理支持erupt类增、删、改、查、导入、导出动态配置
🌟 用户管理增加超管用户的配置，非超管用户不可创建管理员用户
🌟 非超管用户拥有用户管理菜单时，只能看到当前用户添加的用户
🌟 新建用户登录后会弹出重置密码弹窗
🌟 解决 erupt-magic-api 页面缓存问题
🌟 解决 app.js、app.js、home.html 页面缓存问题
🌟 增加 index.html 页面转发功能，使用版本号作为转发依据
🌟 erupt-magic-api支持数据源与函数的权限控制
🌟 erupt-bi 数据源管理支持驱动自动获取
🌟 erupt-bi 支持图表缓存与报表缓存功能
🌟 增加 MetaModel 工具类，可不关联用户表的情况下记录当前操作用户
🌟 新增 EruptModule 类，用于管理与实现扩展模块
🌟 增加字段覆盖功能，子类可覆盖父类的字段，提高复用性，可配置字段用@EruptSmartSkipSerialize修饰

项目官网：www.erupt.xyz

特性 | Features

• 自动建表：表结构自动生成，无需手动建表

• 易于上手：会简单的 Spring Boot 基础知识即可

• 使用简单：仅需了解 @Erupt 与 @EruptField 两个注解即可上手开发

• 代码简洁：仅需一个  文件, template、controller、service、dao 都不需要创建

• 功能强大：动态条件处理，逻辑删除，LDAP，自定义登录逻辑，RedisSession，操作日志等

• 多数据源：支持：MySQL、Oracle、SQL Server、PostgreSQL、H2，甚至支持 MongoDB

• 高扩展性：支持自定义数据源实现、自定义登录逻辑、动态权限管理、生命周期函数、自定义 OSS

• 大量组件：滑动输入、时间选择、一对多、图片上传、代码编辑、自动完成、树、多对多、地图等23类组件

• 丰富展示：普通文本、二维码、链接、图片、HTML、代码段、iframe、swf等

---

• 低侵入性：几乎所有功能都围绕注解而展开，不影响Spring Boot其他功能或三方库库的使用

• 前后端分离：后端与前端可分开部署

• 响应式布局：支持PC端手机端等各种规格的设备中使用

• 自定义页面：支持自定义页面，自定义弹出层，且支持：原生H5 / Freemarker / Thymeleaf等方式渲染

• 前端零代码：前端布局自动构建，一行前端代码都不用写

• 无需二次开发：仅需引用 jar 包即可 ！

完全不需要了解 Angular / React / Vue / Jquery

而且不需要了解 JavaScript / HTML / CSS

甚至不需要了解 Spring MVC / Mybatis / SQL

在线体验 | Demo

演示地址：https://www.erupt.xyz/demo
账号密码：

支持主流 4 款现代浏览器，以及 Internet Explorer 11+，可直接运行在 Electron 等基于 Web 标准的环境上

演示截图 | Screenshot ⛰

Appium 是一个开源、跨平台的自动化测试工具，最初主要用于测试原生和轻量移动应用，包括 iOS 和 Android ，目前还支持对 Windows 平台上的应用的自动化测试。

Appium 1.22.2 已发布，这是一个补丁版本。Appium 1.x 只有在 XCTest 获得 breaking updates 或在 EOL 之前出现重大 bugs 时，才会收到小版本或补丁版本更新。

主要更新内容如下：

iOS(XCUITest)

• 添加settings api，以帮助capability/setting 考虑设备是否在 Safari 窗口的顶部或底部具有 tab bar。可阅读 Settings API 中的以了解更多详细信息 appium-xcuitest-driver#1361
• iOS 15 环境下不显示模拟器的键盘教程 appium-ios-simulator#315
• 修复在 Install App 命令中 pass installation options 的问题 appium-xcuitest-driver#1357
• 禁用 XCTest 默认的通知检查器，以避免在 iOS 15.2 上出现问题 WebDriverAgent#540
• 略微提升 XML source generation 的性能 appium-xcuitest-driver#1351 WebDriverAgent#544

详情可查看 CHANGELOG

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

ImageMagick 7.1.0-26 已发布，该版本可以在 Linux，Windows，Mac Os X，iOS，Android OS 等平台上运行。

ImageMagick 是一个用来创建、编辑、合成图片的软件。它可以读取、转换、写入超过 200 种格式的图片，包括 PNG、JPEG、GIF、HEIC、TIFF、DPX、EXR、WebP、Postscript、PDF 和 SVG 等等。

ImageMagick 可被用于图片切割、颜色替换、各种效果的应用，图片的旋转、组合，文本，直线， 多边形，椭圆，曲线，附加到图片伸展旋转等。支持 Linux、Windows、Mac OS X、iOS、Android OS 平台。

7.1.0-26 版本的更新内容包括有：

• 无法识别的颜色，因为在定义之前就被使用了（参考 https://github.com/ImageMagick/ImageMagick/issues/4843）。
• 优化缩略图调整算法的性能（参考 https://github.com/ImageMagick/ImageMagick/discussions/4755）。

详细更新内容，以及了解以往版本更新可查阅更新记录。 

橙单开源

橙单已完整开源全部脚手架代码，同时提供面向不同技术栈和架构场景的工程样例。与此同时，我们还会提供非常详尽、专业、完全免费的线上开发文档。希望通过我们共同的努力，让每一位对技术有兴趣的开发者，可以轻松迈过这个小小的门槛。 如果橙单对您确有帮助，Fork 的同时，也请 Star 一下。

再次确认你没看错，极高质量和成熟度的脚手架代码全部开源，18万字的线上文档也完全开放，包括完整的工作流、在线表单和数据过滤等组件 ( 同类竞品售价几近万 )，橙单全部源码可见，没有一丝遮蔽。

新功能

• 在线表单，支持主表数据的批量删除。

• 在线表单，支持一对多从表数据的批量删除。

• 在线表单，支持批量导出，配置时可指定主表、一对一从表和一对多从表聚合计算等导出字段。

• 在线表单，工作流数据添加接口支持一对一关联数据的级联插入。

• 在线表单，工作流数据更新接口支持一对一关联数据的级联更新。

• 基础功能，升级工作流、在线表单、静态表单等所有模块，提供 PostgreSQL 的支持。

• 基础功能，升级 Spring Cloud 版本至 2020.0.4。

• 基础功能，升级 Spring Boot 版本至 2.5.8。

• 基础功能，基于远程过程调用的数据查询，支持多字段联合的模糊搜索过滤。

• 生成器，支持表单组件配置的批量添加。

• 生成器，支持批量指定，前端表单、后台接口、工作流和定时任务的独立生成，持续提升代码合并的效率。

• 线上文档，根据用户的反馈，修复部分不同步的章节，同时新增生产部署、数据库迁移、Spring版本升级等实用部分

其他更新

• 提供微服务版本 Spring Cloud 和 单体版本 Spring Boot 升级在线文档，便于用户升级。

• 直接升级 common-core、common-online、common-flow、common-log、common-online-api 模块。

Linux 5.17-rc5 已作为 Linux 5.17 的第五个预览版本发布，该版本依旧是一些补丁修复，并未包含重大功能更新，Linux 5.17 稳定版应该会在 3 月推出。

Linus 在 Linux 5.17-rc5 邮件中的说法：

一切看起来都很正常。到处都有补丁，这次发布的补丁也没有比平时多，统计数据看起来也很正常，大部分变化都发生在驱动身上。

diffstat 看起来有点不同寻常，英特尔 iwlwifi 驱动程序显示了很多修改，但这几乎完全是由于删除了已弃用的广播过滤，它甚至不适用于较新的硬件。在驱动子系统之外，主要是架构更新（kvm 再次出现）、工具和网络。

Linux 5.17 稳定版将于 3 月中下旬发布，并将被 Fedora 36 和其他 Linux 发行版采用。但 Ubuntu 除外，据外媒 Phoronix 介绍： Ubuntu 22.04 LTS 由于其 LTS 状态而坚持使用 Linux 5.15，而不是已经稳定的 v5.16 或 v5.17 。

RocksDB 6.29.3 现已发布，RocksDB 是一个来自 Facebook 的可嵌入的支持持久化的 key-value 存储系统，也可作为 C/S 模式下的存储数据库，基于 LevelDB 构建。 

6.29.3 版本(02/17/2022)

修复了并发事务提交和 memtable 开关导致 2PC 写提交事务数据丢失的 bug (#9571)

6.29.2 版本(02/15/2022)

DisableManualCompaction() 不需要等待调度的手动压缩在线程池中执行来取消作业。 

6.29.1 版本(01/31/2022)

Bug修复

• 修复了当启用 memtable Bloom 过滤器 (memtable_prefix_bloom_size_ratio > 0) 时，批量 MultiGet 可能返回由 DeleteRange 删除的键的旧值的主要错误。

（该修复包括在 memtable_whole_key_filtering 和 prefix_extractor 的异常情况下显著的 MultiGet 性能改进。）

下一个主要版本将是 7.0 版本，详细信息请参阅#9390。

更新公告：https://github.com/facebook/rocksdb/releases/tag/v6.29.3

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

我们用一个系列来讲解从需求到上线、从代码到k8s部署、从日志到监控等各个方面的微服务完整实践。

整个项目使用了go-zero开发的微服务，基本包含了go-zero以及相关go-zero作者开发的一些中间件，所用到的技术栈基本是go-zero项目组的自研组件，基本是go-zero全家桶了。

实战项目地址：https://github.com/Mikaelemmmm/go-zero-looklook

序言

在介绍之前，我先说一下整体思路，如果你的业务日志量不是特别大恰好你又使用的是云服务，那你直接使用云服务日志就可以了，比如阿里云的SLS，基本就是点点鼠标配置几步就可以将你的日志收集到阿里云的SLS里面了，直接就可以在阿里云中查看收集上来的日志了，感觉也没必要折腾。

如果你的日志量比较大，那就可以上日志系统了。

1、日志系统

我们将业务日志打印到console、file之后，市面上比较常用的方式是elk、efk等基本思路一样，我们拿常说的elk来举例，基本思路就是logstash收集过滤到elasticsearch中，然后kibana呈现

但是logstash本身是使用java开发的，占用资源是真滴高，我们用go做业务，本身除了快就是占用资源少构建块，现在在搞个logstash浪费资源，那我们使用go-stash替代logstash，go-stash是go-zero官方自己开发的并且在线上经过长期大量实践的，但是它不负责收集日志，只负责过滤收集上来信息。

go-stash: https://github.com/kevwan/go-stash

2、架构方案

filebeat收集我们的业务日志，然后将日志输出到kafka中作为缓冲，go-stash获取kafka中日志根据配置过滤字段，然后将过滤后的字段输出到elasticsearch中，最后由kibana负责呈现日志

3、实现方案

在上一节错误处理中，我们可以看到已经将我们想要的错误日志打印到了console控制台中了，现在我们只需要做后续收集即可

3.1 kafka

先配置好kafka、zookeeper

然后我们进入kafka中先创建好filebeat收集日志到kafka的topic

进入kafka容器

修改kafka监听配置(或者你把配置文件挂载到物理机在修改也可以)

创建topic

3.2 filebeat

在项目根目录下 docker-compose-env.yml文件中可以看到我们配置了filebeat

filebeat的配置我们挂载到 deploy/filebeat/conf/filebeat.yml

配置比较简单，可以看到我们收集所有日志直接 输出到我们配置的kafka中 , topic配置上一步kafka中创建的topic即可

3.3 配置go-stash

我们来看下go-stash的配置文件 deploy/go-stash/etc/config.yaml

配置消费的kafka以及输出的elasticsearch ， 以及要过滤的字段等

3.4 elastic search、kibana

访问kibana http://127.0.0.1:5601/ ， 创建日志索引

左上角菜单(三个横线那个东东)，找到Analytics – > discover

然后在当前页面，Create index pattern->输入looklook-* -> Next Step ->选择@timestamp->Create index pattern

然后左上角菜单，找到Analytics->discover ，稍等一会，日志都显示了 （如果不显示，就去排查filebeat、go-stash，使用docker logs -f filebeat查看）

我们在代码中添加一个错误日志尝试一下，代码如下

我们访问这个业务方法，去kibana中搜索 data.log : “测试”，如下图

4、结尾

到此日志收集就完成了，接下来我们要实现链路追踪

项目地址

https://github.com/zeromicro/go-zero

https://gitee.com/kevwan/go-zero

欢迎使用 并 star 支持我们！

微信交流群

关注『微服务实践』公众号并 交流群 获取社区群二维码。

问题

要疯了，IDEA 居然自动修改代码？

明明我已经修改保存了，怎么测试都不行，后来我检查一看，并通过复现，发现，代码被 IDEA 自动改了。。

如下面动图所示：

本来是 ，我改成了 调用了

原来，每次当我保存完之后，代码又复原了，太诡异了。。

这样一来，那我的实例对象不是没用到？又直接访问类的静态方法了。。

定位

看到上图，栈长突然灵机一动，这让我想起了之前分享过的《IntelliJ IDEA 2021.2 发布，这次要干掉 FindBugs 了！》这篇文章中的新功能：保存时动作，即可以在保存的时候执行代码优化操作，不用去逐一检查优化了，保存时就能做到。

更多 IDEA 教程，可以关注公众号：全栈程序员社区，我分享了一大堆了，关注后在菜单中就可以阅读。

如下图设置所示：

我确实开启了各项保存时动作，其中我就勾选了一个自动清理修复的选项。

然后在 Inspections 菜单中：

通过实例对象访问静态成员的警告也是打开的，意思就是不允许/不建议通过实例对象访问静态成员。

所以，我猜测可能就是保存时的清理动作触发了这条规则，然后就被自动优化了。

所以，我把它先取消勾选：

然后再测试下：

现在通过实例对象访问静态方法，再保存，实例对象不再被替换为类了，生效了，就是可以允许通过实例.静态成员这种调用方式了。

同时我也发现 Spring Boot 这个启动 run 方法也是提供了普通方法版本的，传入 args 即可，这样就不是静态调用了。现在再把那个选项再次勾选上：

如图，它再也不会被替换为类的调用了，因为它调用的就是普通方法。

总结

IDEA 的一个小优化，确实把我折腾了一翻， IDEA 真的太智能了，有时候帮你优化了，你可能还不知道，这个确实要值得注意！！

其实通过 这种访问形式，语法上是可以的，但不建议，静态成员毫无疑问是类级别的，自然需要通过类来调用，所以，我建议那个选项也不要取消勾选，默认的就是符合正常规则的。

好了，解决了这个疑惑，现在又可以继续愉快的写代码了。。

其实 IDEA 也有开源的社区版本，收费的专业版也很容易申请到免费激活码，可以参考教程：

http://www.javastack.cn/article/2020/intellij-idea-by-open-source-project/

也可以关注公众号全栈程序员社区，回复：IDEA，阅读我分享过的获取正版 IDEA 激活码的教程，很多粉丝都反馈说轻松得到了，感兴趣的都可以去申请，不能太容易了。

关注我，后面栈长会继续分享 IDEA 系列教程，带你打通 IDEA 的任督二脉!

版权声明： 本文系公众号 “全栈程序员社区” 原创，转载、引用本文内容请注明出处，抄袭、洗稿一律投诉侵权，后果自负，并保留追究其法律责任的权利。

近期热文推荐：

1.1,000+ 道 Java面试题及答案整理(2022最新版)

2.劲爆！Java 协程要来了。。。

3.Spring Boot 2.x 教程，太全了！

4.20w 程序员红包封面，快快领取。。。

5.《Java开发手册（嵩山版）》最新发布，速速下载！

觉得不错，别忘了随手点赞+转发哦！

前言

wangEditor v5 正式版发布在即，为了验证它的扩展性，我开发了几个常用的第三方插件。本文介绍一下 formula 插件的设计和使用。

插入数学公式要使用 LateX 语法，渲染公式需要依赖工具 KateX。如 将渲染为下图的公式。

PS：本插件不依赖于任何框架，JS Vue React 等任何框架都可以正常使用。

使用

首先要了解 wangEditor v5 最基本的安装和使用，可参考文档。然后再查阅 wangEditor-plugin-formula 插件的文档。

安装和注册

安装 和

注册到 wangEditor

此时 wangEditor 就已经具备了显示公式的能力，但还需要配置菜单：插入公式，编辑公式。

配置菜单

配置工具栏，把 和 插入到 指定的位置。

当然， 也可以配置到编辑器的悬浮菜单中

此时，即可通过菜单来插入公式：

选中公式节点时，还可以编辑公式：

显示 HTML

执行 获取的公式节点的 HTML 格式如下，就是一个普通的 ，其中 即 LateX 语法的字符串。

将这个 渲染为公式卡片，依然可以借助 KateX ，简单方便。

回显 HTML （重新编辑）

获取的 HTML 依然支持回显到编辑器中，可以正常解析为公式卡片。这些能力早在注册 之后就已经具备了。

设计

一些基本的扩展能力，如注册菜单、生成 html ，解析 html 等，这些 wangEditor 都早已具备且成熟，参考文档和该插件的源码即可。

编辑器内部渲染公式卡片

本文重点介绍：如何使用 KateX 在编辑器中渲染公式卡片？
因为，wangEditor 中渲染流程是比较复杂的，如下图：

要借助 KateX 渲染是直接操作 DOM ，而 wangEditor 内部渲染需要先生成 VDOM ，然后再使用 snabbdom.js 来 patch DOM 。两者无法兼容。

最后找到的解决方案是：自定义 DOM 素。注册一个 素，即可像普通的 一样生成 VDOM ，然后 patch 渲染。

注册 自定义素

借助 KateX ，开发起来非常简单。注册一个自定义素，内部使用 Shadow DOM 渲染即可。

总结

本文重点

• 公式使用 LateX 语法，使用 KateX 工具来渲染
• 编辑器内部注册自定义素 渲染公式
• 开发 formula 插件验证了 wangEditor v5 全面的扩展能力

1 背景

石墨文档全部应用部署在上，每时每刻都会有大量的日志输出，我们之前主要使用和作为日志存储。但是我们在使用这些组件的时候，发现了一些问题。

• 成本问题：

  • 个人觉得是一个非常优秀的产品，速度快，交互方便，但是SLS索引成本比较贵

  • 我们想减少索引成本的时候，发现云厂商并不支持分析单个索引的成本，导致我们无法知道是哪些索引构建的不够合理

  • 使用的存储非常多，并且耗费大量的内存

• 通用问题：

  • 如果业务是混合云架构，或者业务形态有和私有化两种方式，那么并不能通用

  • 日志和链路，需要用两套云产品，不是很方便

• 精确度问题：存储的精度只能到秒，但我们实际日志精度到毫秒，如果日志里面有，中无法通过根据信息，将日志根据毫秒时间做排序，不利于排查错误

我们经过一番调研后，发现使用能够很好的解决以上问题，并且Clickhouse省存储空间，非常省钱，所以我们选择了方案存储日志。但当我们深入研究后，作为日志存储有许多落地的细节，但业界并没有很好阐述相关采集日志的整套流程，以及没有一款优秀的日志查询工具帮助分析日志，为此我们写了一套日志系统贡献给开源社区，并将的日志采集架构的经验做了总结。先上个日志查询界面，让大家感受下石墨最懂前端的后端程序员。

2 架构原理图

我们将日志系统分为四个部分：日志采集、日志传输、日志存储、日志管理。

• 日志采集：采用方式部署，将宿主机日志目录挂载到的容器内，通过挂载的目录能够采集到应用日志、系统日志、K8S审计日志等

• 日志传输：通过不同映射到中不同的，将不同数据结构的日志做了分离

• 日志存储：使用中的两种引擎数据表和物化视图

• 日志管理：开源的系统，能够查询日志，设置日志索引，设置配置，设置表，设置报警等

以下我们按照这四大部分，阐述其中的架构原理

3 日志采集

3.1 采集方式

容器内日志收集的方式通常有以下三种方案

• DaemonSet方式采集：在每个 节点上部署，并将宿主机的目录挂载为容器的日志目录，读取日志内容，采集到日志中心。

• 网络方式采集：通过应用的日志 ，直接将日志内容采集到日志中心 。

• SideCar方式采集：在每个 内部署，只读取这个 内的日志内容，采集到日志中心。

以下是三种采集方式的优缺点：

我们主要采用方式和网络方式采集日志。方式用于、应用日志的采集，网络方式用于大数据日志的采集。以下我们主要介绍下方式的采集方式。 ​

3.2 日志输出

从上面的介绍中可以看到，我们的会有两种方式采集日志类型，一种是标准输出，一种是文件。 引用乙的描述：虽然使用 打印日志是 官方推荐的方式，但大家需要注意：这个推荐是基于容器只作为简单应用的场景，实际的业务场景中我们还是建议大家尽可能使用文件的方式，主要的原因有以下几点：

• 性能问题，从应用输出 到服务端，中间会经过好几个流程（例如普遍使用的 ）：应用 -> -> -> 序列化成 -> 保存到文件 -> 采集文件 -> 解析 -> 上传服务端。整个流程相比文件的额外开销要多很多，在压测时，每秒 10 万行日志输出就会额外占用 1 个 核；

• 不支持分类，即所有的输出都混在一个流中，无法像文件一样分类输出，通常一个应用中有 、、（调用外部接口的日志）、 等，而这些日志的格式、用途不一，如果混在同一个流中将很难采集和分析；

• 只支持容器的主程序输出，如果是 方式运行的程序将无法使用 ；

• 文件的 方式支持各种策略，例如同步/异步写入、缓存大小、文件轮转策略、压缩策略、清除策略等，相对更加灵活。

从这个描述中，我们可以看出在中输出文件在采集到日志中心是一个更好的实践。所有日志采集工具都支持采集文件日志方式，但是我们在配置日志采集规则的时候，发现开源的一些日志采集工具，例如、在部署下采集文件日志是不支持追加例如、、、等信息，并且也无法通过这些做些定制化的日志采集。

基于无法追加信息的原因，我们暂时放弃了部署下文件日志采集方式，采用的是基于部署下标准输出的采集方式。 ​

3.3 日志目录

以下列举了日志目录的基本情况

因为我们采集日志是使用的标准输出模式，所以根据上表我们的只需要挂载，两个目录。

3.3.1 标准输出日志目录

应用的标准输出日志存储在目录下，​文件名是按照K8S日志规范生成的。这里以的日志作为一个示例。我们通过指令，可以看到的文件名。 ​

我们参照K8S日志的规范：。可以将日志解析为：

• ：nginx-ingress-controller-mt2w

• ：kube-system

• ：nginx-ingress-controller

• ：beeca1621ec4415fd87546b1beb29480ac74ab1cdd9f52003cf4abf0a

通过以上的日志解析信息，我们的 就可以很方便的追加、、、的信息。 ​

3.3.2 容器信息目录

应用的容器信息存储在目录下，目录下的每一个文件夹为容器，我们可以通过获取应用的docker基本信息。

3.4 LogCollector采集日志

3.4.1 配置

我们采用的是，该工具是旗下的，能够更好的与云原生相结合。通过系统可以选择集群，很方便的设置 的配置规则。

3.4.2 数据结构

​的默认采集数据结构

• 字段：string or float，用于记录采集日志的时间

• 字段：string，用于记录日志的完整内容

如果使用的时候，因为里面有特殊字符，会处理的有问题。所以我们在处理的采集数据结构，会做一些映射关系，并且规定双下划线为系统日志索引，避免和业务日志的索引冲突。

• 字段：string or float，用于记录采集日志的时间

• 字段：string，用于记录日志的完整内容

例如你的日志记录的是，那么实际采集的日志会是 该日志结构会直接写入到中，系统会根据这两个字段、设置中的数据表。

3.4.3 采集

如果我们要采集日志，我们需要在配置里，设置的日志目录，会把日志采集到内存里。

然后我们在配置里，将改写为

 然后我们在配置里，将追加的日志采集时间设置为，设置好日志写入的和，那么里内存的日志就会写入到中

日志写入到中需要为，如果你的应用写入的日志不是，那么你就需要根据的文档，调整你的日志写入的数据结构：https://docs.fluentbit.io/manual/pipeline/filters/parser

4 日志传输

主要用于日志传输。上文说到我们使用采集日志的默认数据结构，在下图工具中我们可以看到日志采集的内容。 在日志采集过程中，会由于不用业务日志字段不一致，解析方式是不一样的。所以我们在日志传输阶段，需要将不同数据结构的日志，创建不同的表，映射到不同的。这里以为例，那么我们在中需要创建一个的Kafka引擎表，然后映射到的里。

5 日志存储

我们会使用三种表，用于存储一种业务类型的日志。

• 引擎表：将数据从采集到的数据表中

• 物化视图：将数据从数据表读取出来，根据配置的索引，提取字段在写入到结果表里

• 结果表：存储最终的数据

6 总结流程

• 日志会通过的规则采集到，在这里我们会将日志采集到两个字段里

  • 字段用于存储采集的时间

  • 字段用于存放原始日志

• 通过，在里设置了三个表

  • ： 将数据从采集到的引擎表

  • ： 视图表用于存放设置的索引规则

  • ：根据索引解析规则，消费里的数据，存放于结果表中

• 最后的界面，根据的数据，查询日志信息

7 Mogo界面展示

查询日志界面

 设置日志采集配置界面

以上文档描述是针对石墨的日志采集，想了解物理机采集日志方案的，可以在下文中找到《使用文档》的链接，运行体验 全部流程，查询日志。限于篇幅有限，的日志报警功能，下次在讲解。 ​

8 资料

• github地址: https://github.com/shimohq/mogo

• Mogo文档：https://mogo.sigusoft.com

• Mogo使用文档：https://mogo.sigusoft.com/doc/AV62KU4AABMRQ

• fluent-bit文档：https://docs.fluentbit.io/

• K8S日志

  • 6 个 K8S 日志系统建设中的典型问题，你遇到过几个：https://developer.aliyun.com/article/

  • 一文看懂 K8S 日志系统设计和实践：https://developer.aliyun.com/article/

  • 9 个技巧，解决 K8S 中的日志输出问题：https://developer.aliyun.com/article/

  • 直击痛点，详解 K8S 日志采集最佳实践：https://developer.aliyun.com/article/?spm=a2c6h..0.0.UoPfIX

• Clickhouse

  • Clickhouse官方文档：https://clickhouse.com/

  • Clickhouse作为Kubernetes日志管理解决方案中的存储：http://dockone.io/article/9356

  • Uber 如何使用 ClickHouse 建立快速可靠且与模式无关的日志分析平台？：https://www.infoq.cn/article/l4thjgnr7hxpkgpmw6dz

  • 干货 | 携程ClickHouse日志分析实践：https://sigusoft.com/s/IjOWAPOJXANRQqRAMWXmaw

  • 为什么我们要从ES迁移到ClickHouse：https://sigusoft.com/s/l4RgNQPxvdNIqx52LEgBnQ

  • ClickHouse 在日志存储与分析方面作为 ElasticSearch 和 MySQL 的替代方案：https://sigusoft.com/s/nJXorcgi0QfXPCKr_HdUZg

  • 快手、携程等公司转战到 ClickHouse，ES 难道不行了？：https://sigusoft.com/s/hP0ocT-cBCeIl9n1wL_HBg

  • 日志分析下ES/ClickHouse/Loki比较与思考：https://sigusoft.com/s/n2I94X6tz2jOABzl1djxYg

持续测试是 DevOps 开发流程中的重要一环。在很多已经在尝试进行 DevOps 开发的团队中，开发人员往往会将测试自动化等同于实施了持续测试，这种观念其实是错的。

事实上，测试自动化只是持续测试众多要素中的一部分。实施完整的持续测试，需要一个多维度的测试策略，这些策略涵盖开发过程中所有需要的测试类型 —— 包括单、集成、功能、探索性和自动化。持续测试还必须有一个完整的战略，将测试纳入整个 CI/CD （持续集成/持续交付）的流程。

DevOps 本质上来说是一系列软件开发实践的模型，强调开发人员（Dev）和运维人员（Ops）之间的沟通合作，通过自动化流程，使得软件构建、测试、交付更加快捷、频繁和可靠。这种开发模式的特点是可以把产品的每个迭代，或者每修复一个线上缺陷就立即部署到生产环境，这样一来，开发者就能够迅速从用户处获得反馈并快速做出响应。企业开发团队转向 DevOps，必须在不牺牲软件产品质量的情况下，最大限度地提高交付速度来增加价值和改善用户体验，这些都需要在 DevOps 流程中通过实施 CI/CD 流程来实现，而持续测试在这其中发挥着重要的作用。

总而言之，持续测试不仅仅是在整个软件交付流程中执行自动化测试，还需要持续的业务和技术风险分析，以及整个持续集成过程的流程改进和自动化。从本质上来说，持续测试还是伴随 DevOps 发展出来的一种文化，它要求开发团队中的每个成员都把产品质量当作是共同的责任。此外，持续测试也是一种管理风险的方法，它可以通过提高测试流程的有效性和效率来消除测试瓶颈。

下面是由业内专家总结的持续测试策略四大关键步骤：

1. 简化测试流程

简化测试流程包含三部分内容：关注业务风险、解决测试瓶颈以及优化测试。

业务风险

DevOps 以及持续测试的最终目标都是降低业务风险，而所谓的业务风险实际上是来自于客户和组织两方面的风险组成。

客户风险涉及了解应用程序工作流程中哪个环节对客户来说最为重要，并相应地规划基于这些环节可能出现风险的测试覆盖率。

组织风险涉及了解商业环境以及产品本身的复杂性。例如，是为了抢占市场而让产品率先上市重要，还是产品本身的健康度或安全性更重要？

一旦准确评估了整体业务风险，开发团队应该将需求、应用程序组件和测试映射到这些风险中。

解决瓶颈

在开发测试流程中，识别和缓解可能出现的瓶颈至关重要，这些瓶颈通常是阻碍最终交付产品质量和交付速度最重要的因素。这一过程通常贯穿产品需求到生产上线后的整个软件开发生命周期。

举几个例子，比如在某项待办事项中缺乏测试人员，没有在这一环节建立验收标准，没有及时解决缺陷，导致项目上线延期；比如某自动化测试套件运行时间过长，以及手动完成后期生产检查，导致效率低下。

这一步通常需要开发团队使用一些自动化工具来解决。自动化测试工具是测试人员用来提高测试效率的辅助工具。

就比如在业界家喻户晓的Selenium ，它被认为是 Web 应用程序用户界面自动化测试的行业标准。根据”测试自动化挑战调查”显示，十分之九的测试人员在其项目中使用或曾经使用过 Selenium。但为了有效地使用 Selenium，用户必须具备高级编程技能，并且需要花费大量时间来构建自动化所需的自动化框架和库，这是 Selenium 的主要缺点，虽然可以通过 Katalon Studio 等集成工具解决，但其依然对测试人员的能力提出了较高的要求。

对于测试人员并不充足的团队，也可以使用一些自动化测试平台来解决测试瓶颈。例如由飞算独立研发的飞算 SoFlu 全自动软件工程平台，其全自动测试平台提供了测试生命周期管理、测试数据管理和精准回归测试等一站式自动化测试功能。依托平台的测试用例自动生成等特性，可以让测试人员无需编写脚本，即可快速完成自动化测试工作，提升项目上线效率。

优化测试

如果说依靠自动化测试工具可以解决团队在 DevOps 流程中遇到的效率瓶颈，那么测试优化则是在持续测试流程中实施自动化策略的基础，它要求测试团队选择正确的测试方法，这些测试以最少的测试用例提供团队所需的测试覆盖率，即从策略层面提升测试的效率。

这是一个动态的、持续的过程，尤其是作为连续测试框架的一部分应用时。测试优化应该在自动化之前进行，并且必须在整个连续测试过程中持续进行。第一步通常是通过了解关键用户工作流程中涉及的所有集成来优化测试范围——包括这些应用程序中采用的技术（网络、移动、消息/API 层等）。

一旦团队对测试范围有了清晰的了解，下一步就是优化测试用例。这不仅包括分析测试用例的质量和详细程度，还包括选择提供最高测试覆盖率的测试。团队的测试套件应设计为以最少的测试用例提供最大的覆盖量，以提高质量和速度。前文提到的飞算 SoFlu 全自动测试平台就可以通过录制工具把测试人员的操作过程记录下来，并能够自动识别相关的接口并创建相应的测试用例场景，实现自动优化测试用例。

一些团队默认「每次运行所有的测试」来保证代码覆盖率。这不但浪费资源还延长了测试周期，而且没有真正保证代码覆盖率。测试那些需要测试的部分，以节省时间和资源。可视化模型可以让各种路径被探索优化，以便只用少量的测试用例就能提供最大化的覆盖率。

2. 在整个 CI 流程中实现自动化测试

持续测试需要在整个交付流程中实现测试自动化。测试自动化提高了部署速度并降低了持续交付中固有的风险。

但持续测试框架内的自动化不仅仅是开发和维护自动化回归测试组件。事实上，很多不间断运行自动化回归测试组件会在持续部署过程中造成瓶颈。持续测试需要一个测试自动化策略来增强而不是阻碍持续交付过程。

例如飞算 SoFlu 全自动测试平台提供的精准回归测试功能，该功能在项目测试时能够自动识别所有变动的接口，自动查找接口关联的所有测试用例进行精准回归测试。

自动化测试策略必须在构建过程的每一步都包含自动检查点。首先是验证单个代码片段的单测试和验证关键特性的组件测试。基于风险的回归测试套件应根据开发者当前正在实施的功能进行定制。

在项目上线到生产环境中时，持续测试要求团队通过部署健康检查系统来确保应用正常运行，生产监控应在客户发现之前发现产品的功能和性能问题。

总而言之，在持续测试策略中，测试自动化必须设计为高效运行（可利用自动化工具），同时提供可靠、一致、可重复的结果。

3. 左移原则 

传统测试主要集中在软件开发周期的最后，即产品发布之前的集中测试。为了迎合不断加快的交付频率，越来越多团队的测试活动开始向左右两侧移动。一般问题修复成本较高和面向企业收费的软件，一旦生产环境中出现了问题会造成比较大的损失，通常采取测试左移的方式；对于具有展示功能的软件产品，更容易在生产环境中发现问题，通常采取测试右移的方式。

测试左移是 DevOps 流程中常见的模式，指的是测试人员更早地参与到软件项目前期的各项活动中，在功能开发之前定义好相关的测试用例，提前发现质量问题。早期引入测试过程有助于防止缺陷，并为开发人员提供在整个开发阶段应用动态变更的灵活性。

4. 对质量负责

这一步是持续测试策略的基础，它要求团队中的所有成员（包括开发、测试和运维）都需要为项目的质量负责。

业内专家认为，DevOps 中质量保证不再是测试人员的专属责任，而是全体人员都要为之努力的方向。持续测试的成功实施离不开团队内部及跨团队的协作。测试人员需提前介入到开发工作中，与开发人员一起制定测试计划；开发人员可以参与配置部署；运维人员可以向自动化测试用例库填写测试用例；测试人员随时将自动化测试用例配置到持续交付链中，所有成员的共同目的都是交付高效、高质量的产品。

这种趋势也催生了很多自动化开发、测试和运维工具以降低这些领域的技术门槛。同样以飞算 SoFlu 全自动软件工程平台为例，该平台提供了全自动开发、全自动测试和全自动运维工具，可以管理从需求、研发、测试、部署、上线到运维的整个软件生命周期，真正实现了软件工程开发、测试、运维全流程自动化。这种新兴的全自动工具降低了开发、测试和运维门槛，能够帮助任何一家企业快速构建一支 DevOps 开发团队。

DevOps 打破了开发和运维之间的障碍，缩短了开发周期。其中，持续集成、持续测试、持续交付都是提高质量的关键催化剂，而持续测试则更具挑战性。掌握 DevOps 生命周期的持续测试，对于我们充分理解 DevOps 起着至关重要的作用。

iot-modbus

介绍

物联网通讯协议，基于netty框架，支持COM（串口）和TCP协议，支持服务端和客户端两种模式，实现Java控制智能设备，同时支持设备组多台设备高并发通讯。采用工厂设计模式，代码采用继承和重写的方式实现高度封装，可作为SDK提供封装的接口，让具体的业务开发人员无需关心通讯协议的底层实现，直接调用接口即可使用。实现了心跳、背光灯、扫码、刷卡、指静脉、温湿度和门锁（支持多锁）、LCD显示屏等指令控制。代码注释丰富，包括上传和下发指令调用例子，非常容易上手。

版本说明

1. V1.0.0版本仅支持TCP服务端通讯模式；
2. V2.0.0版本支持TCP服务端和客户端两种模式，客户端模式还增加了心跳重连机制。
3. V3.0.0版本支持COM（串口）和TCP协议，增加logback日志按文件大小和时间切割输出。
4. V3.1.0版本代码优化，抽取公共模块子工程。
5. V3.2.0版本TCP通讯增加支持LCD显示屏控制指令，支持批量控制LCD显示屏。 6.  V3.2.1版本串口通讯增加支持LCD显示屏控制指令，支持批量控制LCD显示屏。

软件架构

软件架构说明 基础架构采用Spring Boot2.x + Netty4.X + Maven3.6.x，日志采用logback。

安装教程

1. 系统Windows7以上；
2. 安装Jdk1.8以上；
3. 安装Maven3.6以上；
4. 代码以Maven工程导入Eclipse或Idea。

使用说明

1. 工程结构说明：

• iot-modbus                //物联网通讯父工程
• ├── doc                   //文档管理
• ├── iot-modbus-client     //netty通讯客户端
• ├── iot-modbus-common     //公共模块子工程
• ├── iot-modbus-netty      //netty通讯子工程
• ├── iot-modbus-serialport //串口通讯子工程
• ├── iot-modbus-server     //netty通讯服务端
• ├── iot-modbus-test       //使用样例子工程
• └── tools                 //通讯指令调试工具

2. 配置文件查看iot-modbus-test子工程resources目录下的application.yml文件；
3. 启动文件查看iot-modbus-test子工程App.java文件；
4. 服务启动后，服务端端口默认为：8080，网口通讯端口默认为：4000，串口通讯默认串口为：COM1；
5. 通讯指令调试工具，TCP通讯模式使用tools目录下的NetAssist.exe，串口通讯模式使用tools目录下的UartAssist.exe；
6. 通讯指令采用Hex编码（十六进制）；
7. 串口通讯依赖文件查看doc/serialport目录，Windows环境下rxtxParallel.dll和rxtxSerial.dll文件拷贝到JDK安装的bin目录下，Linux环境将librxtxParallel.so和librxtxSerial.so文件拷贝到JDK安装的bin目录下；
8. postman指令下发样例请查看doc/postman/通讯指令下发.postman_collection.json文件，包括门锁（单锁/多锁）、扫码、背光灯、LCD显示屏灯指令。

Laravel 9.0 于 2020年2月8日发布，在发布后的第一时间 ModStart 技术团队进行了新技术研究和新框架的适配。ModStart + Laravel 9.0 版于2月11日开始内测。

经过两个星期的内测，目前 3.2.0 正式对外发布。

框架将支持两个LTS版本

ModStart 后续的迭代同时支持 Laravel 5.1 和 Laravel 9.0 两个版本，无论使用的是哪个版本，都将保持持续迭代更新，让您无需担忧。

模块市场

模块市场中的模块默认支持 Laravel 5.1，经过技术架构的改造，目前部分已经适配 Laravel 9.0，在模块功能介绍页面中，环境表示对于两个版本的支持情况。laravel5表示支持5.1版本，laravel9表示支持9.0版本，在模块下载前请查看模块对于框架的支持情况。

ModStart 将会不断创新，保持跟进前沿技术，帮您的业务稳步向前。

form-create 是一个可以通过 JSON 生成具有动态渲染、数据收集、验证和提交功能的表单生成组件。支持4个UI框架，并且支持生成任何 Vue 组件。内置20种常用表单组件和自定义组件，再复杂的表单都可以轻松搞定。

文档 | 源码 

3.1 版本主要更新了以下内容:

如果不需要导入UI框架的全部组件,可以通过 auto-import.js 一次导入 form-create 需要的组件. 以 element-ui 为例

安装

根据自己使用的 UI 安装对应的版本

element-plus^2.0

 npm install @form-create/element-ui@next

ant-design-vue^3.0

 npm install @form-create/ant-design-vue@next

arco-design^2.0

 npm install @form-create/arco-design@next

naive-ui^2.0

 npm install @form-create/naive-ui@next 

引入 form-create

浏览器

NodeJs

在 main.js 中写入以下内容：

生成表单

使用  标签创建表单

关注公众号

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。

持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。

转载内容版权归作者及来源网站所有，本站原创内容转载请注明来源。

✨ Better

• 带嵌入参数的字段也能参与过滤条件
• 带嵌入参数的字段也能参与字段统计

参见：
https://github.com/ejlchina/bean-searcher/releases
https://gitee.com/ejlchina-zhxu/bean-searcher/releases

还不了解的同学这里都有介绍哦：

我这样写代码效率提高了100倍：https://juejin.cn/post/
系统教程：https://searcher.ejlchina.com/

smart-doc 是一款同时支持 java restful api 和 Apache Dubbo rpc 接口文档生成的工具，smart-doc 颠覆了传统类似 swagger 这种大量采用注解侵入来生成文档的实现方法。

smart-doc 完全基于接口源码分析来生成接口文档，完全做到零注解侵入，你只需要按照 java 标准注释编写，smart-doc 就能帮你生成一个简易明了的 markdown 或是一个像 GitBook 样式的静态 html 文档。如果你已经厌倦了 swagger 等文档工具的无数注解和强侵入污染，那请拥抱 smart-doc 吧！

功能特性

• 支持接口 debug。
• 零注解、零学习成本、只需要写标准 java 注释。
• 基于源代码接口定义自动推导，强大的返回结构推导。
• 支持 Spring MVC,Spring Boot,Spring Boot Web Flux(controller 书写方式),JAX-RS规范。
• 支持 Callable,Future,CompletableFuture 等异步接口返回的推导。
• 支持 JavaBean 上的 JSR303 参数校验规范，支持分组验证。
• 对 json 请求参数的接口能够自动生成模拟 json 参数。
• 对一些常用字段定义能够生成有效的模拟值。
• 支持生成 json 返回值示例。
• 支持从项目外部加载源代码来生成字段注释(包括标准规范发布的 jar 包)。
• 支持生成多种格式文档：Markdown、HTML5、Asciidoctor、Postman collection、Open Api 3.0+。
• 轻易实现在 Spring Boot 服务上在线查看静态 HTML5 api 文档。
• 开放文档数据，可自由实现接入文档管理系统。

• 一款代码注释检测工具，不写注释的小伙伴逃不过法眼了。
• 插件式快速集成(支持 maven 和 gradle 插件)。
• 支持 Apache Dubbo rpc 文档生成。

Smart-doc 和其他工具的支持

Smart-doc 从 2.0.0 后几乎实现了 swagger ui 的功能，并且比 swagger ui 更简洁大方，也更符合国内开发者的诉求。当然 smart-doc 的功能也已经

超过了 swagger 为 java 开发者提供的功能。当然 smart-doc 本身是只支持扫描代码生成 openapi 3.0 的文档的，也可以将生成的 openapi 3.0 文档导入到其他ui中渲染展示。

更新内容

1.  支持泛型多层继承解析
2.  优化生成postman post请求文档。
3.  完善JAX-RS规范支持。

debug 页面效果

maven 或 gradle 插件

smart-doc 官方为了方便用户快速和无侵入的集成 smart-doc 的文档 api 生成能力，我们开发可相关的 maven 或者 gradle 插件。这里也推荐使用插件的方式来使用 smart-doc。

https://gitee.com/smart-doc-team/smart-doc-maven-plugin

官方推荐方案

smart-doc + Torna 组成行业领先的文档生成和管理解决方案，使用smart-doc无侵入完成Java源代码分析和提取注释生成API文档，自动将文档推送到Torna企业级接口文档管理平台。

smart-doc+Torna文档自动化

smart-doc在国内很多企业中被用来替换了swagger，甚至是在国内Top 3内的大厂都有smart-doc的二次开发版本。Torna未来的目标是追赶和超越Yapi。smart-doc针对java spring技术栈的解析能力目前为业内最强(不服就拿工具来跑smart-doc的解析demo)。所以smart-doc+Torna的方案威力巨大，Torna目前处于高速迭代期，欢迎体验Torna，我们努力为社区提供高效好用的接口文档解决方案。

升级建议

 smart-doc 可基于以前的版本平滑升级，建议升级。

DEMO

使用demo轻松玩转接口文档生成，其他用户案例文档效果展示：https://api.doubans.com/

知名用户

• 科大讯飞
• 一加
• 小米
• 马蜂窝

在今年2021年8月 smart-doc 也新增了一些外海的用户。

本周更新内容：

1、增加手工结算单FORM视图，满足扩展更多业务类型需要。

Idea激活2022.1.3

2、修复列表视图颜色从colors属性改为decoration-xx。

本周最佳贡献者：大连-张涛

更新提示：

1、所有基于Odoo13框架的GoodERP用户支持升级到此版本

2、更新源码后重启并升级core模块

===================

GoodERP采取收费会员更新模式

Idea激活2022.1.3

月会员 400

年会员 3000

终身会员 10000