WebStorm 2022.3 正式发布，该版本带来了新的 UI 预览、Vitest 支持、适用于 Vite 和 Next.js 的项目模板、针对 JavaScript 和 TypeScript 的 Code Vision、适用于 Angular 模板的类型缩小支持以及 Vue 更新。

框架和技术

更新了项目模板

我们重做了 WebStorm 欢迎屏幕中的 New Project（新建项目）向导。 在 v2022.2 中，我们移除了适用于 AngularJS、Cordova 和 Meteor 的项目模板。 在此版本中，我们添加了适用于 Vite 和 Next.js 的新项目模板，并更新了 Vue 模板，使其符合最新标准。

Vitest 支持

WebStorm 现在支持 Vitest，这是一个 Vite 原生单测试框架！ 您可以用所有您能想到的主要方式运行、重新运行和调试测试，包括通过间距图标。 此外，监视模式在所有测试场景下默认均已启用。 在监视模式下还支持快照测试和覆盖率，从而在编码时为您提供几乎即时的覆盖率反馈。

Vue 更新

WebStorm 现在可以处理未解析的导入，并为导入 Vue 组件提供建议。 我们也已支持 props 析构语法，改进了针对 Vue 库组件 props 的代码补全和类型检查行为，并修正了几个 Nuxt 3 问题。

Vue 的新代码段

此版本中，还有一项针对 Vue 的改进值得仔细研究 – 新代码段，也就是 WebStorm 中的实时模板。 您可以使用它们更快添加常见构造，例如 或 。 转到 Preferences / Settings | Editor | Live Templates（偏好设置/设置 | 编辑器 | 实时模板），展开 Vue 部分即可浏览可用代码段。

Angular 模板中的类型缩小

我们在 Angular 模板中添加了对类型缩小的支持，这将提供更精确的类型信息和更好的代码补全建议。 此外，WebStorm 现在会从全局搜索中排除 缓存文件夹，帮助提供更好的搜索结果。

关于 Svelte 支持的更新

对 Svelte 支持（作为单独插件提供）的改进现在将随新 IDE 构建一起推出，就像 Angular 和 Vue 一样。 这将帮助我们避免不兼容版本范围的问题并更快获得反馈。

对新 CSS 功能的支持

WebStorm 2022.3 支持新的 CSS 功能，例如 at-rule，它将语句块与 条件相关联。 视口单、范围媒体查询、容器查询、级联层和颜色修改函数现在也已获得支持。

JavaScript 和 TypeScript

针对 JavaScript 和 TypeScript 的 Code Vision

来自 Rider 和 IntelliJ IDEA 的 Code Vision 功能现已加入 WebStorm！ Code Vision 可以收集类型和类型成员的各种指标，并在声明附近显示此信息。 这将使代码中各种类、方法、类型别名和接口的用法更易跟踪。 转到 Preferences / Settings | Editor | Inlay Hints（偏好设置/设置 | 编辑器 | 内嵌提示）配置 Code Vision。

更出色的 monorepos 和 TypeScript 体验

我们为在 WebStorm 中处理 monorepos 和 TypeScript 发布了多个修正。 导航、自动导入和重命名重构功能都将更可靠地运行。 这适用于所有主流软件包管理器，包括 npm、Yarn 和 pnpm。

字母排序意图

WebStorm 2022.3 包含按字母顺序对 JavaScript 和 TypeScript 对象进行排序的新意图。 运行此意图时，它将按字母顺序重新格式化对象内所有属性的代码。 要使用此意图，首先高亮显示方法中的对象，按 ⌥⏎，然后选择 Sort properties alphabetically（按字母顺序对属性排序）。

用户体验

通过设置使用新 UI

今年早些时候，我们宣布了 JetBrains IDE 中新 UI 的封闭预览计划。 对于这第一步，我们的目标是向有限数量的用户提供重做的 IDE 外观。 我们邀请您在 Preferences / Settings | Appearance & Behavior / New UI（偏好设置/设置 | 外观与行为/新 UI）中切换到新 UI 并告诉我们您的想法。

将工具窗口停靠到浮动编辑器选项卡的选项

为了让您可以更轻松地安排工作空间并在多个显示器上与 WebStorm 交互，我们实现了将工具窗口拖出主窗口并将其停靠到浮动编辑器选项卡的选项。

改进了 Search Everywhere（随处搜索）结果

Search Everywhere（随处搜索）结果列表背后的算法经过微调，行为更加可预测和准确。 IDE 将冻结出现的第一个搜索结果，并且不会在找到更多选项时对其重新排序。 此外，ML 排名现在对 Files（文件）选项卡启用，可以提高查找结果的准确性。

新的 Settings Sync（设置同步）解决方案

新的 Settings Sync（设置同步）插件现在可用于 WebStorm。 新的解决方案能够同步来自平台、捆绑插件和一些第三方插件的大部分可共享设置。 请注意，我们将停止支持旧的 IDE Settings Sync（IDE 设置同步）插件并取消捆绑 Settings Repository（设置仓库）。

改进了每日小技巧

WebStorm 的内置学习工具 Tip of the Day（每日小技巧）得到微调。 我们添加了技巧评分功能，并重做了技巧显示方式的算法。 这应该使它们与您的 IDE 体验和您手头的项目更加相关。

适用于 Windows 和 Linux ARM64 的安装程序

现在，可以在带有 ARM64 处理器的 Windows 和 Linux 机器上运行 WebStorm。 IDE 安装程序处于测试版阶段，网站和 JetBrains Toolbox App 均提供 Windows 版，但 Linux 版仅可从网站获得。

针对书签的 UI 改进

我们为 Bookmarks（书签）功能实现了多项 UI 改进。 例如，右键选项卡并从上下文菜单中选择 Bookmarks（书签）即可从编辑器选项卡为文件添加书签。

编辑器

改进了复制剪切粘贴行为

我们重做了粘贴操作 (⌘V) 的行为。 现在，如果在没有选择代码的情况下复制 (⌘C) 或剪切 (⌘X) 一行，粘贴操作会将剪贴板的内容添加到当前行上方，而不是像旧版本一样添加到文本光标处。 您可以在 Preferences / Settings | Advanced Settings（偏好设置/设置 | 高级设置）中禁用此行为。

意图操作预览

我们添加了新功能来预览和解释应用所选操作会发生什么。 打开可用意图操作列表并将鼠标悬停在不同选项上时会显示预览。 在意图操作列表打开时，您可以按 F1 禁用此功能。

软件包的漏洞检查器

WebStorm 2022.3 将对照 Checkmarx SCA 数据库和 National Vulnerability Database 检查软件包，检测项目中所用软件包的漏洞。 IDE 将高亮显示被认为易受攻击的软件包，并在可用时建议修正。

针对 YAML 的编辑改进

新增的快速修复可以通过 YAML 文件中的注释禁止检查，包括 docker-compose.yml、Kubernetes 文件和 OpenAPI 规范。 我们还引入了一个方便的选项，用于折叠组成 3 行或更多行的块并以 开头的多行注释 – 使用注释左侧的加号和减号图标。

集成开发者工具

针对 Docker 的改进

WebStorm 现已支持连接到 WSL 中运行的 Docker。 此外，还有新增的 Pull Docker image（拉取 Docker 镜像）意图、对 文件和 heredoc 语法的完全支持，以及使用 Docker 上下文设置 Docker 连接的功能。

为 GitHub 和 Space 重新设计了 Review list（审查列表）

我们重做了 Review list（审查列表）UI，帮助减少认知负担并清晰提供有关请求的最重要信息。 其中，我们还确保在所有受支持的审查平台上保持一致的外观。

处理 WSL2 中的项目的新方式

WebStorm 2022.3 带来了处理在 WSL2 文件系统中运行的项目的替代方式。 您可以直接在 WSL2 中启动 IDE 后端，而不是在 Windows 上运行完整的 IDE。 然后，您可以像在 WebStorm 中使用远程开发时连接到远程机器一样连接到它。

针对 HTTP 客户端的新功能

HTTP 客户端现在支持在请求之前执行的脚本块。 您可以在请求执行之前生成一些数据，并使用变量将其放入最终请求。 WebStorm 现在还提供 сrypto API，使代码能够计算 HTTP 请求的 md5 或 sha1 哈希值。

针对 HTTP 客户端的代码样式改进

HTTP 客户端现在为具有长 URL 的请求提供了更好的格式设置选项。 您也可以使用 Put query parameters on separate lines（将查询形参置于单独的行中）意图操作，将查询拆分成不同行中的小片段。 转到 Preferences / Settings | Editor | Code Style | HTTP Request | Wrapping and Braces（偏好设置/设置 | 编辑器 | 代码样式 | HTTP 请求 | 换行和大括号）即可控制有关 HTTP 请求格式设置的偏好设置。

更多详情可查看：https://blog.jetbrains.com/webstorm/2022/11/webstorm-2022-3/

关注公众号

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

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

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

漏洞描述

Apache Fineract 是一个用于金融服务的开源软件。

Apache Fineract 在 1.8.1 之前的版本中由于 FileSystemContentRepository.java 类对用户传入的文件路径名限制不当从而存在路径遍历漏洞，经过身份验证的攻击者可利用此漏洞上传包含恶意代码的文件到系统任意目录，在 Fineract 加载恶意文件时远程执行恶意代码。

影响范围

apache/fineract@(-∞, 1.8.1)

修复方案

升级apache/fineract到 1.8.1 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-62935

https://nvd.nist.gov/vuln/detail/CVE-2022-44635

https://github.com/apache/fineract/commit/90f854ba466b048807c26ccf31a6f555

情报订阅

OSCS(开源软件供应链安全社区)通过最快、最全的方式，发布开源项目最新的安全风险动态，包括开源组件安全漏洞、事件等信息。同时提供漏洞、投毒情报的免费订阅服务，社区用户可通过配置飞书、钉钉、企业微信机器人，及时获得一手情报信息推送：

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

背景

字节跳动特征存储痛点

当前行业内的特征存储整体流程主要分为以下四步：

特征存储的整体流程

1. 业务在线进行特征模块抽取；

2. 抽取后的特征以行的格式存储在 HDFS，考虑到成本，此时不存储原始特征，只存抽取后的特征；

3. 字节跳动自研的分布式框架会将存储的特征并发读取并解码发送给训练器；

4. 训练器负责高速训练。

字节跳动特征存储总量为 EB 级别，每天的增量达到 PB 级别，并且每天用于训练的资源也达到了百万核心，所以整体上字节的存储和计算的体量都是非常大的。在如此的体量之下，我们遇到了以下三大痛点：

1. 特征抽取周期长。在特征抽取上，当前采用的是在线抽取的方式。大量的算法工程师，每天都在进行大量的特征相关的试验。在当前的在线抽取模式下，如果有算法工程师想要调研一个新的特征，那么他首先需要定义特征的计算方式，等待在线模块的统一上线，然后需要等在线抽取的特征积累到一定的量级后才可以进行训练，从而判断这个特征是否有效果。这个过程通常需要2周甚至更长的时间。并且，如果发现特征的计算逻辑写错或想要更改计算逻辑，则需重复上述过程。在线特征抽取导致当前字节特征调研的效率非常低。基于当前的架构，离线特征调研的成本又非常高。

2. 特征存储空间占用大。字节的特征存储当前是以行存的形式进行存储。如果基于当前的行存做特征调研，则需要基于原来的路径额外生成新的数据集。一方面需要额外的空间对新的数据集进行存储，另一方面还需要额外的计算资源去读取原来的全量数据生成新的数据，且很难做数据的管理和复用。行存对于特征存储来说，也很难进行优化，占用空间较大。

3. 模型训练带宽大，数据读取有瓶颈。字节当前将每个业务线的绝大部分特征都存储在一个路径下，训练的时候会直接基于这个路径进行训练。对于每个模型，训练所需的特征是不一样的，每个业务线可能存有上万个特征，而大部分模型训练往往只需要几百个特征，但因为特征是以行存格式进行存储，所以训练时需要将上万特征全部读取后，再在内存中进行过滤，这就使得模型训练的带宽需求非常大，数据的读取成为了整个训练的瓶颈。

基于痛点的需求梳理

基于上述问题，我们与业务方一同总结了若干需求：

1. 存储原始特征：由于在线特征抽取在特征调研上的低效率，我们期望能够存储原始特征；

2. 离线调研能力：在原始特征的基础上，可以进行离线调研，从而提升特征调研效率；

3. 支持特征回填：支持特征回填，在调研完成后，可以将历史数据全部刷上调研好的特征；

4. 降低存储成本：充分利用数据分布的特殊性，降低存储成本，腾出资源来存储原始特征；

5. 降低训练成本：训练时只读需要的特征，而非全量特征，降低训练成本；

6. 提升训练速度：训练时尽量降低数据的拷贝和序列化反序列化开销。

字节跳动海量特征存储解决方案

在字节的整体架构中，最上层是业务层，包括抖音、头条、小说等字节绝大部分业务线；

其下我们通过平台层，给业务同学提供简单易用的 UI 和访问控制等功能；

在框架层，我们使用 Spark 作为特征处理框架（包括预处理和离线特征调研等），字节自研的 Primus 作为训练框架；

在格式层，我们选用Parquet 作为文件格式，Iceberg 作为表格式；

最下层是调度器 Yarn & K8s 以及存储 HDFS。

下面我们重点针对格式层进行详细介绍。

技术选型

为了满足业务方提到的6个需求，我们首先想到的是通过 Parquet 列存的格式，降低行存的存储成本，节省的空间可用来存储原始特征。同时由于 Parquet 选列可以下推到存储层的特性，在训练时可以只读需要的特征，从而降低训练时反序列化的成本，提升训练的速度。

但是使用 Parquet 引入了额外的问题，原来的行存是基于 Protobuf 定义的半结构化数据，不需要预先定义 Schema，而使用 Parquet 以后，我们需要先知道 Schema，然后才能进行数据的存取，那么在特征新增和淘汰时，Schema 的更新就是一个很难解决的问题。Parquet 并不支持数据回填，如果要回填历史几年的数据，就需要将数据全量读取，增加新列，再全量写回，这一方面会浪费大量的计算资源，另一方面做特征回填时的 overwrite 操作，会导致当前正在进行训练的任务由于文件被替换而失败。

为了解决这几个问题，我们引入了 Iceberg 来支持模式演进、特征回填和并发读写。

Iceberg 是适用于大型数据集的一个开源表格式，具备模式演进、隐藏分区&分区演进、事务、MVCC、计算存储引擎解耦等特性，这些特性匹配了我们所有的需求。因此，我们选择了 Iceberg 作为我们的数据湖。

整体上 Iceberg 是一个分层的结构，snapshot 层存储了当前表的所有快照；manifest list 层存储了每个快照包含的 manifest 云数据，这一层的用途主要是为了多个 snapshot 可以复用下一层的 manifest；manifest 层，存储了下层 Data Files 数据；最下面的 Data File 是就是实际的数据文件。通过这样的多层结构，Iceberg 可以支持上述包括模式演进等几个特性。

下面我们来一一介绍 Iceberg 如何支持这些功能。

字节跳动海量特征存储解决方案

并发读写

在并发读取方面，Iceberg 是基于快照的读取，对 Iceberg 的每个操作都会生成新的快照，不影响正在读取的快照，从而保证读写互不影响。

在并发写入方面，Iceberg 是采用乐观并发的方式，利用HDFS mv 的原子性语义保证只有一个能写入成功，而其他的并发写入会被检查是否有冲突，若没有冲突，则写入下一个 snapshot。

模式演进

Iceberg 的模式演进原理

我们知道，Iceberg 数据和 Parquet 数据都有 Column，而中间的映射关系，是通过 ID 字段来进行一对一映射。

例如上面左图中，Iceberg 和 Parquet 分别有 ABC 三列，对应 ID 1、2、3。那最终读取出的 Dataframe 就是 和 Parquet 中一致包含 ID 为1、2、3的 ABC 三列。而当我们对左图进行两个操作，删除旧的 B 列，写入新的 B 列后， Iceberg 对应的三列 ID 会变成1、3、4，所以右图中读出来的 Dataframe，虽然也是 ABC 三列，但是这个 B 列的 ID 并非 Parquet 中 B 列的 ID，因此最终实际的数据中，B 列为空值。

特征回填

• 写时复制

如上图所示，COW 方式的特征回填通过一个 Backfill 任务将原快照中的数据全部读出，然后写入新列，再写出到新的 Data File 中，并生成新的快照。

这种方式的缺点在于虽然我们只需要写一列数据，但是需要将整体数据全部读出，再全部写回，不仅浪费了大量的计算资源用来对整个 Parquet 文件进行编码解码，还浪费了大量的 IO 来读取全量数据，且浪费了大量的存储资源来存储重复的 ABC 列。

因此我们基于开源 Iceberg 自研了 MOR 的 Backfill 方案。

• 读时合并

如上图所示，在 MOR 方案中，我们仍然需要一个 Backfill 任务来读取原始的 Data File 文件，但是这里我们只读取需要的字段。比如我们只需要 A 列通过某些计算逻辑生成 D 列，那么 Backfill 任务则只读取 A 的数据，并且 Snapshot2 中只需要写包含 D 列的 update 文件。随着新增列的增多，我们也需要将 Update 文件合并回 Data File 文件中。

为此，我们又提供了 Compaction 逻辑，即读取旧的 Data File 和 Update File，并合并成一个单独的 Data File。

MOR原理如上图，假设原来有一个逻辑 Dataframe 是由两个 Data File 构成， 现在需要回填一个  ColD 的内容。我们会写入一个包含 ColD 的 Update File，这样 Snapshot2 中的逻辑 Dataframe 就会包含ABCD 四列。

实现细节：

• Data File 和 Update File 都需要一个主键，并且每个文件都需要按照主键排序，在这个例子中是 ID；
• 读取时，会根据用户选择的列，分析具体需要哪些 Update File 和 Data File；
• 根据 Data File 中主键的 min-max 值去选择与该 Data File 相对应的 Update File；
• MOR 整个过程是多个 Data File 和 Update File 多路归并的过程；
• 归并的顺序由 SEQ 来决定，SEQ 大的数据会覆盖 SEQ 小的数据。

• COW与 MOR 特性比较

相比于 COW 方式全量读取和写入所有列，MOR 的优势是只读取需要的列，也只写入更新的列，没有读写放大问题。在计算上节省了大量的资源，读写的 IO 也大大降低，相比 COW 方式每次 COW 都翻倍的情况， MOR 只需要存储新增列，也大大避免了存储资源浪费。

考虑到性能的开销，我们需要定期 Compaction，Compaction 是一个比较重的操作，和 COW 相当。但是 Compaction 是一个异步的过程，可以在多次 MOR 后进行一次 Compaction。那么一次 Compaction 的开销就可以摊销到多次 MOR 上，例如10次 COW 和10次 MOR + 1次 Compaction 相比，存储和读写成本都从原来的 10x 降到当前的 2x 。

MOR 的实现成本较高，但这可以通过良好的设计和大量的测试来解决。

而对于模型训练来说，由于大多数模型训练只需要自己的列，所以大量的线上模型都不需要走 MOR 的逻辑，可以说基本没有开销。而少数的调研模型，往往只需读自己的 Update File 而不用读其他的  Update File ，所以整体上读取的额外资源也并未增加太多。

训练优化

从行存改为 Iceberg 后，我们也在训练上也做了大量的优化。

在我们的原始架构中，分布式训练框架并不解析实际的数据内容，而是直接以行的形式把数据透传给训练器，训练器在内部进行反序列化、选列等操作。

原始架构

引入 Iceberg 后，我们要拿到选列带来的 CPU 和 IO 收益就需要将选列下推到存储层。最初为了保证下游训练器感知不到，我们在训练框架层面，将选列反序列化后，构造成原来的 ROW 格式，发送给下游训练器。相比原来，多了一层序列化反序列化的开销。

这就导致迁移到 Iceberg 后，整体训练速度反而变慢，资源也增加了。

列式改造

为了提升训练速度，我们通过向量化读取的方式，将 Iceberg 数据直接读成 Batch 数据，发送给训练器，这一步提升了训练速度，并降低了部分资源消耗。

向量化读取

为了达到最优效果，我们与训练器团队合作，直接修改了训练器内部，使训练器可以直接识别 Arrow 数据，这样我们就实现了从 Iceberg 到训练器端到端的 Arrow 格式打通，这样只需要在最开始反序列化为 Arrow ，后续的操作就完全基于 Arrow 进行，从而降低了序列化和反序列化开销，进一步提升训练速度，降低资源消耗。

Arrow

优化收益

最终，我们达到了最初的目标，取得了离线特征工程的能力。

在存储成本上，普遍降低了40%以上；在同样的训练速度下，CPU 降低了13%，网络IO 降低40%。

未来规划

未来，我们规划支持以下4种能力：

1. Upsert 的能力，支持用户的部分数据回流；

2. 物化视图的能力，支持用户在常用的数据集上建立物化视图，提高读取效率；

3. Data Skipping 能力，进一步优化数据排布，下推更多逻辑，进一步优化 IO 和计算资源；

4. 基于 Arrow 的数据预处理能力，向用户提供良好的数据处理接口，同时将预处理提前预期，进一步加速后续的训练。

字节跳动基础架构批式计算团队持续招聘中，批式计算团队负责字节跳动离线数据处理&分布式训练，支撑公司内离线 ETL&机器学习等业务场景，涉及的组件包括离线计算引擎 Spark/自研分布式训练框架 Primus /特征存储 Feature Store(如Iceberg/Hudi)/Ray 等。面对字节超大规模的场景，在 Spark/Primus/Feature Store 等方面都做了大量的功能&性能优化，同时支持新一代分布式应用框架 Ray 在公司相关场景的落地。

• 工作地点：北京/杭州

• 联系方式：微信 bupt001，或发送简历至邮件 qianhan@bytedance.com 

HSE 是一个快速可嵌入的键值存储，专为 SSD 和持久化内存设计。HSE 通过协调跨 DRAM 和多类固态存储的数据放置，优化了性能和耐久性。

HSE 是支持数据库、软件定义存储（SDS）、高性能计算（HPC）、物联网（IoT）和机器学习（ML）的理想选择。

主要特征：

• 丰富的键值运算符集
• 用于优化单个数据存储中的混合用例工作负载的数据模型
• 键值压缩
• 灵活的耐久性控制
• 可配置的数据编排方案
• 可以嵌入任何应用程序的本地 C 库

优势：

• 每个存储可扩展到数 TB 的数据和数千亿个密钥
• 高效处理数千个并发操作
• 显着改善吞吐量、延迟、写放大、 和读取放大
• 可选地组合多种固态存储类别，以优化性能和耐久性

构建 HSE

克隆 仓库并 checkout 最新的发布标签。 此标签必须适用于 HSE 2.0 或更高版本。

例如

git clone https://github.com/hse-project/hse.git cd hse git checkout <release tag>

使用 Meson 和 Ninja 构建和安装。

可以在 meson.build 目录中找到构建 HSE 所需的最低版本的 Meson。 在那里，你会在文件开头发现一个 关键字参数的 函数。

如果你的系统没有提供足够新的 Meson 版本来构建 HSE，请参阅安装说明 。

meson setup build meson compile -C build meson install -C build

IEEE 发布了一项最新的调查结果，主要研究技术对 2023 及未来发展的影响。该调查基于来自美国、英国、中国、印度和巴西的 350 名首席技术官、首席信息官和 IT 主管等全球技术领导者的反馈。

调查指出，云计算 (40%)、5G (38%)、宇宙 (37%)、电动汽车 (EV) (35%) 和工业物联网 (IIoT) (33%) 将成为 2023 年最重要的五个技术领域。其中，宇宙尚处于起步阶段；71% 的受访者认为“5G 和无处不在的连接”对推动宇宙发展非常重要，还有 58% 的认为 VR 耳机和 AR 眼镜也同样重要。

2023 年受技术影响最大的行业部门有：

• (40%) 电信
• (39%) 汽车和运输
• (33%) 能源
• (33%) 银行和金融服务

另一方面，2023 年的网络安全问题也依旧是各方关注的重点。数据表明，2022 年上半年，全球共发生 28 亿次恶意软件攻击和 2.361 亿次勒索软件攻击。截至 2022 年底，预计将发起 60 亿次网络钓鱼攻击。技术领导者们对网络安全的关注更甚于往年，51% 的受访者将云漏洞列为头等大事 (高于 2022 年的 35%)，还有 43% 的担忧数据中心漏洞 (高于 2022 年的 27%)。

网络安全专业人员关注的其他领域还包括：

• 勒索软件攻击 (30%)
• 对组织网络的协同攻击 (30%)
• 缺乏对安全解决方案的投资 (26%)

IT 部门在 2023 年可能遇到的 10 大安全威胁有：

• 恶意软件：可以提取机密信息、拒绝服务并获得对系统的访问权限。
• 勒索软件：截至 2022，勒索软件对公司的攻击比 2021 年高出 33%。许多公司同意支付赎金以恢复其系统，结果却再次遭到同样的勒索软件攻击者的攻击。
• 供应链漏洞：可以采取的步骤之一是审核其供应商和供应商使用的安全措施，以确保端到端供应链的安全。
• 网络钓鱼：网络钓鱼是企业所面临的主要威胁。对员工进行关于如何识别虚假电子邮件、报告它们以及永远不要打开它们的培训将很有帮助。IT 应与 HR 合作，以确保培养良好的电子邮件使用习惯。
• 物联网：2020 年，有 61% 的公司在使用物联网，这一比例还在继续增加。随着物联网的扩展，安全风险也在增加。
• 内部员工：心怀不满的员工可能会破坏网络或窃取知识产权和专有信息，而养成不良安全习惯的员工可能会无意中共享密码并使设备不受保护。
• 数据中毒：数据中毒是进入企业系统的新攻击媒介。
• 新技术：一些组织正在采用生物识别等新技术。这些技术带来了巨大的好处，但它们也引入了新的安全风险，因为 IT 对它们的经验有限。
• 多层安全：IT 部门可以通过为工作流程中的每个安全漏洞点建立一个检查清单来加强安全。
• 云安全

Linus 近日对内核维护者表示，由于项目的开发周期节奏将与即将到来的圣诞夜产生冲突，维护者要确保在假期之前完成他们的开发工作。

Linus 在刚刚过去的周末发布了 Linux 6.1-rc7。他在邮件中表示，本以为感恩节会影响内核的开发工作，但现实情况与他的判断相反——假期并没有减缓开发进度。因此，Linus 决定再为 Linux 6.1 发布一个 rc8。若按照这个节奏，Linux 6.2 合并窗口刚好处于圣诞节假期期间。

对此，Linus 表示在下一个合并窗口期间，自己会比平时更“强硬”地执行规则。按照社区规则，开发者应该在合并窗口开启之前就准备好要提交的补丁。但现在，他希望所有要提交的补丁在圣诞节之前就完成，如果他收到的 PR 比这个时间晚。他将推迟到下一个周期在合并。

最后，Linus 希望大家对此达成完全一致的共识，并且不要再给他发送明显不是错误的信息。

延伸阅读

• Linus 批评内核开发者赶 Deadline

U-Boot 是一个开源引导加载程序，主要用于嵌入式系统。它支持多种不同的结构，包括 PPC、ARM、AVR32、MIPS、x86、68k、Nios 与 MicroBlaze。

此前，U-Boot 引导加载程序只支持 UDP 协议，仅限通过 tftp（简单文件传输协议） 或 NFS（网络文件系统） 进行文件传输。在开发人员的长期努力之下，如今 U-Boot 终于提供了 TCP 协议支持，可通过 HTTP 下载文件或其他内容。

经过五年开发，整整二十轮的修改，对 U-Boot 网络的 TCP 基础支持补丁终于完成并合并到主线。除了对  TCP 协议的兼容，该系列补丁还添加了一个基础的 wget 应用程序。U-Boot 上的的 wget 应用是一个命令行下载器，允许通过 TCP 从 HTTP 服务器下载文件到指定的内存地址，目前 wget 仅支持 80 端口上的 HTTP 服务器，且不支持 HTTPS。

提供 HTTP 和 TCP 支持意味着 U-Boot 可以从 HTTP 服务器下载内核或其他文件，而不仅限使用 NFS 或 TFTP 进行远程加载，它可以简化一些 U-Boot 嵌入式设备的部署。

开源固件基金会（Open-Source Firmware Foundation, OSFF）近日在社交平台宣布，Coreboot 将正式加入 OSFF，共同推进开源固件的开发。

Coreboot 原名 LinuxBIOS，是一个旨在取代计算机中专有固件（BIOS 或 UEFI）的软件项目，它采用轻量级固件设计，只执行加载和运行现代 32 位或 64 位操作系统所需的最少量任务。

由于 Coreboot 要初始化硬件，所以必须为所要支持的每个芯片组和主板做移植。因此 Coreboot 只适用于有限的硬件平台和主板型号。

开源固件基金会由 9elements Cyber Security 和 Mullvad VPN 共同成立，在官方网站的介绍中他们写道：

开源固件基金会（OSFF）是一个非营利组织，其总体目标是加强开源固件领域各方的沟通。OSFF 于 2021 年由业界领先的开源固件公司成立。

该基金会将其目标设定为通过共享知识资源、基础设施、服务、活动和培训，研究并教育企业和个人了解开源固件。

目前，除了两位创始成员和刚刚加入组织的 Coreboot，OSFF 的成员还有今年年中加入组织的 LinuxBoot。作为一家刚刚成立没多久的基金会，希望 OSFF 未来一切顺利。

Midori 是一个基于 Chromium 的轻量级开源网络浏览器，并以 Electron 构建，虽然基于 Chromium，但 Midori 去掉了很多来自 Google 的服务和一些涉及隐私的内容。它的目标是快速、隐私、简洁的 UI、可扩展和功能性。

注：Midori 曾是 Xfce 桌面环境 Goodies 组件的一部分，也是 elementary OS “Freya” 和 “Luna”，以及其他很多 Linux 发行版的默认浏览器。

2019年，Midori 项目与 Astian 基金会合并，然后已经完全改头换面，并从 WebKitGTK 转为使用 Electron。

由于该浏览器最新的稳定版本还停留在 2020 年，不少用户都觉得该项目已经停止维护了。

近日，官方带来了一些新的消息，首先 Midori 网络浏览器没有停止维护，仍然在持续开发中；此外，在即将到来的浏览器更新中，他们计划将自己的开源搜索引擎 AstianGO 整合到浏览器中。这与 Brave 跟 Brave Search 整合有些类似，但 Brave Search 并不是开源的。

在 Reddit 的帖子中，Astian 的工作人员表示他们计划在 Midori 网络浏览器的下一次更新中增加一个集成的开源搜索引擎，即 AstianGO。目前这项开发工作的细节并不多，但 Astian 提到：

我们已经实现并开发了一个完全开源的搜索引擎，没有使用第三方 API，也不存储用户的 IP 地址、不存储搜索历史。我们把这个搜索引擎称为 AstianGO，这个搜索引擎是用 PHP 开发的，它是自托管的，尽管它还没有一个集成的更新系统，不过人们可以把它部署在他们的服务器上。

AstianGO 搜索引擎使用来自 Google、Qwant 和 Brave Search 的数据提供结果，并且托管在冰岛、挪威、瑞士、罗马尼亚、荷兰、瑞典等多个国家，这样可以确保用户的数据并不总是流经一个国家。

目前 Astian 已经在 GitLab 上放出了开源搜索引擎 AstianGO 的源代码，用户还可以直接访问 https://astiango.com/ 这个网址来使用搜索引擎，尝试搜索一些内容来验证这个搜索引擎是否好用。

大家好，我是张晋涛。

上周在我的交流群里有个小伙伴问到了 Overlay2 相关的问题，这篇就来介绍一下。(想进群的可以留言）

本节，我将为你介绍 Docker 现在推荐使用的存储驱动 Overlay2，在开始之前，你可以执行以下命令来查看 Docker 正在使用的存储驱动：

如果你看到的结果也是 说明你的 Docker 已经在使用 overlay2 存储驱动了。我在个人工作站上用的是 btrfs，这是因为自从 Fedora 33 开始，btrfs 就成为了 Fedora 默认的文件系统。不过服务器上就都是 overlay2 了。

你也可能会看到其他不同的结果，可以在启动 docker daemon 的时候，通过 参数进行指定，也可以在 文件中通过 字段进行配置。

目前对于 Docker 最新版本而言，你有以下几种存储驱动可供选择：

但它们对于你使用的文件系统之类的都有不同的要求，且实现方式也不尽相同。我以本节的重点 存储驱动为例，它需要你使用 Linux 4.x 以上版本的内核，或者是对于 RHEL/CentOS 等需要使用 3.10.0-514 以上的内核（旧版本中存在一些兼容性问题，我在之前的文章中有提到过）。

同时，它支持你使用 ext4 的文件系统，或者增加了 的 xfs 文件系统。可以通过 进行得到文件系统相关的信息。

存储驱动的作用

前面虽然已经聊了如何设置和检查当前在用的存储驱动，但尚未介绍为何一定要使用存储驱动，以及它的作用。

还记得我在之前的文章《万字长文：彻底搞懂容器镜像构建》中为你介绍的 Docker 如何存储镜像相关的内容吗，如果忘了可以回头复习一下。

Docker 将容器镜像做了分层存储，每个层相当于包含着一条 Dockerfile 的指令。而这些层在磁盘上的存储方式，以及在启动容器时，如何组织这些层，并提供可写层，便是存储驱动的主要作用了。

另外需要注意的是：不同的存储驱动实现不同，性能也有差异，同时使用不同的存储驱动也会导致占用的磁盘空间有所不同。

同时：由于它们的实现不同，当你修改存储驱动后，可能会导致看不到原有的镜像，容器等，这是正常的，不必担心，切换回原先的驱动即可见。

OverlayFS

了解完前面的背景知识后，你也看到了我刚才列出的可用存储驱动中有两个 和 ，其实 算是 的升级版，这两个存储驱动所用的都是 。

驱动是在 2014 年 8 月份首次进入 Docker 的，而 则是在 2016 年 6 月份被合并，并首次出现在 Docker 1.12 中的。它的出现是为了解决 存储驱动可能早层 inode 耗尽的问题。

简单介绍完 和 ，我们将重点回归到 上。

我们启动一个容器，以此为切入点来认识下 OverlayFS，注意：以下内容使用 Linux 5.4 内核以及 Docker 20.10.21，不同环境下可能结果略有差异。

可以看到，在启动容器后，系统上多了一个 OverlayFS (overlay) 的挂载。注意看其中的几个内容：

• 挂载点在：

  其中的内容，看着很熟悉，是我们所启动容器根目录中的内容。为了验证这一说法，我在容器中新写一个文件：

  再次查看此挂载点中的内容：

  可以看到刚才写的内容已经在这个挂载点的目录中了。

• : 这是 OverlayFS 中必要的目录。

  这个 中包含两个目录，这是使用了内核对 OverlayFS multi layer 特性的支持，我们分别查看下其中内容：

  这两个目录，是不是看着很熟悉？
  

  是的，它们就是我们所启动容器根目录中的大部分内容。为什么说是大部分内容呢？当我们查看其中的内容时，你也会发现它们的内容也并不完整。比如我们刚才新写入的 文件，或者当我们查看 目录下的文件，你也会发现其中都只是常规系统 目录下的部分内容。

• 是另一个重要的目录，我们来看看其中的内容

  我们发现这个目录中包含着刚才创建的 文件。同时，其中也包含一个 目录，这个目录便是我们默认使用的 用户的家目录。

  如果去查看其中的内容，也会发现刚才我们执行命令的历史记录。

• 这个目录和 在同一个父目录下，查看其内容发现里面只有一个 目录

看完以上的介绍，想必你已经发现了它们之间的部分联系，在此之前，我们在额外看一个目录，那就是 和 以及挂载点共同的父目录：

你会发现这个目录下的内容就比较直观了。我们刚才已经看了其中 ， 和 目录的内容了，现在看看 中的内容吧：

我们发现， 文件中的内容是以 分隔的两个 的目录名称。

至此，我们可以得到以下结论：

• 是基础层，可以包含多个 ；
• 是可写层，即挂载时的 ，在容器内变更的文件都在这一层存储；
• 是最终的合并结果，即容器给我们呈现出来的结果；

Overlay2

经过前面对 Docker 启动容器后挂载的 OverlayFS 的介绍后，Overlay2 的工作流程想必你也就比较清楚了。

将镜像各层作为 基础层，同时增加 这个可写层，通过 OverlayFS 的工作机制，最终将 作为容器内的文件目录展示给用户。

你可能会有疑问，如果只是这样简单的组织，会不会有什么限制呢？答案是肯定的，当然有限制，我们可以通过 Overlay2 的代码来看

可以看到其对 lower 的深度有硬编码的限制，当前硬编码的限制是 128 。如果你在使用的过程中遇到这个错误，那表示你超过了最大深度限制，你就需要找些办法来减少层级了。

总结

本节，我为你介绍了 OverlayFS 及 Overlay2 存储驱动相关的内容。通过实际启动容器生成的相关目录来介绍 overlay2 的工作流程，想必通过这种方式能更易理解。

欢迎订阅我的文章公众号【MoeLove】

hello，大家好，我是张张，「架构精进之路」公号作者。

1、前言

随着互联网从简单的单向浏览请求，发展为基于用户个性信息的定制化以及社交化的请求，这要求产品需要做到以用户和关系为基础，对海量数据进行分析和计算。对于后端服务来说，意味着用户的每次请求都需要查询用户的个人信息和大量的关系信息，此外大部分场景还需要对上述信息进行聚合、过滤、排序，最终才能返回给用户。

CPU是信息处理、程序运行的最终执行单，如果它的世界也有“秒”的概念，假设它的时钟跳一下为一秒，那么在CPU（CPU的一个核心）眼中的时间概念是什么样的呢？

可见I/O的速度与CPU和内存相比是要差几个数量级的，如果数据全部从数据库获取，一次请求涉及多次数据库操作会大大增加响应时间，无法提供好的用户体验。

对于大型高并发场景下的Web应用，缓存更为重要，更高的缓存命中率就意味着更好的性能。缓存系统的引入，是提升系统响应时延、提升用户体验的唯一途径，良好的缓存架构设计也是高并发系统的基石。

缓存的思想基于以下几点：

• 时间局限性原理 程序有在一段时间内多次访问同一个数据块的倾向。例如一个热门的商品或者一个热门的新闻会被数以百万甚至千万的更多用户查看。通过缓存，可以高效地重用之前检索或计算的数据。

• 以空间换取时间 对于大部分系统，全量数据通常存储在MySQL 或者Hbase，但是它们的访问效率太低。所以会开辟一个高速的访问空间来加速访问过程，例如Redis读的速度是次/s，写的速度是81000次/s 。

• 性能和成本的Tradeoff 高速的访问空间带来的是成本的提升，在系统设计时要兼顾性能和成本。例如，在相同成本的情况下，SSD 硬盘容量会比内存大 10～30 倍以上，但读写延迟却高 50～100 倍。

   

引入缓存会给系统带来以下优势：

• 提升请求性能

• 降低网络拥塞

• 减轻服务负载

• 增强可扩展性

   

同样的，引入缓存也会带来以下劣势：

• 毫无疑问会增加系统的复杂性，开发复杂性和运维复杂性成倍提升。

• 高速的访问空间会比数据库存储的成本高。

• 由于一份数据同时存在缓存和数据库中，甚至缓存内部也会有多个数据副本，多份数据就会存在数据双写的不一致问题，同时缓存体系本身也会存在可用性问题和分区的问题。

   

在缓存系统的设计架构中，还有很多坑，很多的明枪暗箭，如果设计不当会导致很多严重的后果。设计不当，轻则请求变慢、性能降低，重则会数据不一致、系统可用性降低，甚至会导致缓存雪崩，整个系统无法对外提供服务。

2、缓存的主要存储模式

三种模式各有优劣，适用于不同的业务场景，不存在最佳模式。

● Cache Aside（旁路缓存）

写： 更新db时，删除缓存，当下次读取数据库时，驱动缓存的更新。

读： 读的时候先读缓存，缓存未命中，那么就读数据库，并且将数据回种到缓存，同时返回相应结果

特点：懒加载思想，以数据库中的数据为准。在稍微复杂点的缓存场景，缓存都不简单是数据库中直接取出来的，可能还需要从其他表查询一些数据，然后进行一些复杂的运算，才能最终计算出值。这种存储模式适合于对数据一致性要求比较高的业务，或者是缓存数据更新比较复杂、代价比较高的业务。例如：一个缓存涉及多个表的多个字段，在1分钟内被修改了100次，但是这个缓存在1分钟内就被读取了1次。如果使用这种存储模式只删除缓存的话，那么1分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低。

● Read/Write Through（读写穿透）

写： 缓存存在，更新数据库，缓存不存在，同时更新缓存和数据库

读： 缓存未命中，由缓存服务加载数据并且写入缓存

特点：

读写穿透对热数据友好，特别适合有冷热数据区分的场合。

1）简化应用程序代码

在缓存方法中，应用程序代码仍然很复杂，并且直接依赖于数据库，如果多个应用程序处理相同的数据，甚至会出现代码重复。读写穿透模式将一些数据访问代码从应用程序转移到缓存层，这极大地简化了应用程序并更清晰地抽象了数据库操作。

2）具有更好的读取可伸缩性

在多数情况下，缓存数据过期以后，多个并行用户线程最终会打到数据库，再加上数以百万计的缓存项和数千个并行用户请求，数据库上的负载会显著增加。读写穿透可以保证应用程序永远不会为这些缓存项访问数据库，这也可以让数据库负载保持在最小值。

3）具有更好的写性能

读写穿透模式可以让应用程序快速更新缓存并返回，之后它让缓存服务在后台更新数据库。当数据库写操作的执行速度不如缓存更新的速度快时，还可以指定限流机制，将数据库写操作安排在非高峰时间进行，减轻数据库的压力。

4）过期时自动刷新缓存

读写穿透模式允许缓存在过期时自动从数据库重新加载对象。这意味着应用程序不必在高峰时间访问数据库，因为最新数据总是在缓存中。

● Write Behind Caching（异步缓存写入）

写：只更新缓存，缓存服务异步更新数据库。

读：缓存未命中由封装好的缓存服务加载数据并且写入缓存。

特点：写性能最高，定期异步刷新数据库数据，数据丢失的概率大，适合写频率高，并且写操作需要合并的场景。使用异步缓存写入模式，数据的读取和更新通过缓存进行，与读写穿透模式不同，更新的数据并不会立即传到数据库。相反，在缓存服务中一旦进行更新操作，缓存服务就会跟踪脏记录列表，并定期将当前的脏记录集刷新到数据库中。作为额外的性能改善，缓存服务会合并这些脏记录，合并意味着如果相同的记录被更新，或者在缓冲区内被多次标记为脏数据，则只保证最后一次更新。对于那些值更新非常频繁，例如金融市场中的股票价格等场景，这种方式能够很大程度上改善性能。如果股票价格每秒钟变化 100 次，则意味着在 30 秒内会发生 30 x 100 次更新，合并将其减少至只有一次。

3、缓存7大经典问题

问题的常用解决方案

  1  缓存集中失效

缓存集中失效大多数情况出现在高并发的时候，如果大量的缓存数据集中在一个时间段失效，查询请求会打到数据库，数据库压力凸显。比如同一批火车票、飞机票，当可以售卖时，系统会一次性加载到缓存，并且过期时间设置为预先配置的固定时间，那过期时间到期后，系统就会因为热点数据的集中没有命中而出现性能变慢的情况。

解决方案：

• 使用基准时间+随机时间，降低过期时间的重复率，避免集体失效。即相同业务数据设置缓存失效时间时，在原来设置的失效时间基础上，再加上一个随机值，让数据分散过期，同时对数据库的请求也会分散开，避免瞬时全部过期对数据库造成过大压力。

  2  缓存穿透

缓存穿透是指一些异常访问，每次都去查询压根儿就不存在的key，导致每次请求都会打到数据库上去。例如查询不存在的用户，查询不存在的商品id。如果是用户偶尔错误输入，问题不大。但如果是一些特殊用户，控制一批肉鸡，持续的访问缓存不存在的key，会严重影响系统的性能，影响正常用户的访问，甚至可能会让数据库直接宕机。我们在设计系统时，通常只考虑正常的访问请求，所以这种情况往往容易被忽略。

解决方案：

• 第一种方案就是，查询到不存在的数据时，首次查询数据库，即便数据库没有数据，仍然回种这个 key 到缓存，并使用一个特殊约定的value表示这个key的值为空。后面再次出现对这个key的请求时，直接返回null。为了健壮性，设置空缓存key时，一定要设置过期时间，以防止之后该key被写入了数据。

• 第二种方案是，构建一个 BloomFilter 缓存过滤器，记录全量数据，这样访问数据时，可以直接通过 BloomFilter 判断这个 key 是否存在，如果不存在直接返回即可，压根儿不需要查询缓存或数据库。比如，可以使用基于数据库增量日志解析框架（阿里的canal），通过消费增量数据写入到BloomFilter 过滤器。BloomFilter的所有操作也是在内存里实现，性能很高，要达到 1% 的误判率，平均单条记录占用 1.2 字节即可。同时需要注意的是BloomFilter 只有新增没有删除操作，对于已经删除的key可以配合上述缓存空值解决方案一起使用。Redis提供了自定义参数的布隆顾虑器，可以使用bf.reserve进行创建，需要设置参数error_rate（错误率）和 innitial_size。error_rate越低需要的空间越大，innitial_size表示预计放入的素数量，当实际数量超过这个值以后，误判率会上升。

   

  3  缓存雪崩

缓存雪崩是缓存机器因为某种原因全部或者部分宕机，导致大量的数据落到数据库，最终把数据库打死。例如某个服务，恰好在请求高峰期间缓存服务宕机，本来打到缓存的请求，这是时候全部打到数据库，数据库扛不住在报警以后也会宕机，重启数据库以后，新的请求会再次把数据库打死。

解决方案：

• 事前：缓存采用高可用架构设计，redis使用集群部署方式。对重要业务数据的数据库访问添加开关，当发现数据库出现阻塞、响应慢超过阈值的时候，关闭开关，将一部分或者全都的数据库请求执行failfast操作。

• 事中：引入多级缓存架构，增加缓存副本，比如新增本地 ehcache 缓存。引入限流降级组件，对缓存进行实时监控和实时报警。通过机器替换、服务替换进行及时恢复；也可以通过各种自动故障转移策略，自动关闭异常接口、停止边缘服务、停止部分非核心功能措施，确保在极端场景下，核心功能的正常运行。

• 事后：redis持久化，支持同时开启两种持久化方式，我们可以综合使用 AOF 和 RDB 两种持久化机制，用 AOF 来保证数据不丢失，作为数据恢复的第一选择; 用 RDB 来做不同程度的冷备，在 AOF 文件都丢失或损坏不可用的时候，还可以使用 RDB 来进行快速的数据恢复。同时把RDB 数据备份到远端的云服务，如果服务器内存和磁盘的数据同时丢失，依然可以从远端拉取数据做灾备恢复操作。

   

  4  缓存数据不一致

同一份数据，既在缓存里又在数据库里，肯定会出现数据库与缓存中的数据不一致现象。如果引入多级缓存架构，缓存会存在多个副本，多个副本之间也会出现缓存不一致现象。缓存机器的带宽被打满，或者机房网络出现波动时，缓存更新失败，新数据没有写入缓存，就会导致缓存和 DB 的数据不一致。缓存 rehash 时，某个缓存机器反复异常，多次上下线，更新请求多次 rehash。这样，一份数据存在多个节点，且每次 rehash 只更新某个节点，导致一些缓存节点产生脏数据。再比如，数据发生了变更，先删除了缓存，然后要去修改数据库，此时还没修改。一个请求过来，去读缓存，发现缓存空了，去查询数据库，查到了修改前的旧数据，放到了缓存中。随后数据变更的程序完成了数据库的修改，数据库和缓存中的数据不一样了。

解决方案：

• 设置key的过期时间尽量短，让缓存更早的过期，从db加载新数据，这样无法保证数据的强一致性，但是可以保证最终一致性。

  cache更新失败以后引入重试机制，比如连续重试失败以后，可以将操作写入重试队列，当缓存服务可用时，将这些key从缓存中删除，当这些key被重新查询时，重新从数据库回种。

  延时双删除策略，首先删除缓存中的数据，在写数据库，休眠一秒以后（具体时间需要根据具体业务逻辑的耗时进行调整）再次删除缓存。这样可以将一秒内造成的所有脏数据再次删除。

  缓存最终一致性，使客户端数据与缓存解耦，应用直接写数据到数据库中。数据库更新binlog日志，利用Canal中间件读取binlog日志。Canal借助于限流组件按频率将数据发到MQ中，应用监控MQ通道，将MQ的数据更新到Redis缓存中。

  更新数据的时候，根据数据的唯一标识，将操作路由之后，发送到一个 jvm 内部队列中。读取数据的时候，如果发现数据不在缓存中，那么将重新执行“读取数据+更新缓存”的操作，根据唯一标识路由之后，也发送到同一个 jvm 内部队列中。该方案对于读请求进行了非常轻度的异步化，使用一定要注意读超时的问题，每个读请求必须在超时时间范围内返回。因此需要根据自己的业务情况进行测试，可能需要部署多个服务，每个服务分摊一些数据的更新操作。如果一个内存队列里居然会挤压 100 个业务数据的修改操作，每个操作操作要耗费 10ms 去完成，那么最后一个读请求，可能等待 10 * 100 = 1000ms = 1s 后，才能得到数据，这个时候就导致读请求的长时阻塞。

   

  5  竞争并发

当系统的线上流量特别大的时候，缓存中会出现数据并发竞争的现象。在高并发的场景下，如果缓存数据正好过期，各个并发请求之间又没有任何协调动作，这样并发请求就会打到数据库，对数据造成较大的压力，严重的可能会导致缓存“雪崩”。另外高并发竞争也会导致数据不一致问题，例如多个redis客户端同时set同一个key时，key最开始的值是1，本来按顺序修改为2,3,4，最后是4，但是顺序变成了4,3,2，最后变成了2。

解决方案：

分布式锁+时间戳

可以基于redis或者zookeeper实现一个分布式锁，当一个key被高并发访问时，让请求去抢锁。也可以引入消息中间件，把Redis.set操作放在消息队列中。总之，将并行读写改成串行读写的方式，从而来避免资源竞争。对于key的操作的顺序性问题，可以通过设置一个时间戳来解决。大部分场景下，要写入缓存的数据都是从数据库中查询出来的。在数据写入数据库时，可以维护一个时间戳字段，这样数据被查询出来时都会带一个时间戳。写缓存的时候，可以判断一下当前数据的时间戳是否比缓存里的数据的时间戳要新，这样就避免了旧数据对新数据的覆盖。

  6  热点Key问题

对于大多数互联网系统，数据是分冷热的，访问频率高的key被称为热key，比如热点新闻、热点的评论。而在突发事件发生时，瞬间会有大量用户去访问这个突发热点信息，这个突发热点信息所在的缓存节点由于超大流量而达到理网卡、带宽、CPU 的极限，从而导致缓存访问变慢、卡顿、甚至宕机。接下来数据请求到数据库，最终导致整个服务不可用。比如微博中数十万、数百万的用户同时去吃一个新瓜，秒杀、双11、618 、春节等线上促销活动，明星结婚、离婚、出轨这种特殊突发事件。

解决方案：

要解决这种极热 key 的问题，首先要找出这些 热key 。对于重要节假日、线上促销活动、凭借经验可以提前评估出可能的热 key 来。而对于突发事件，无法提前评估，可以通过 Spark或者Flink，进行流式计算，及时发现新发布的热点 key。而对于之前已发出的事情，逐步发酵成为热 key 的，则可以通过 Hadoop 进行离线跑批计算，找出最近历史数据中的高频热 key。还可以通过客户端进行统计或者上报。找到热 key 后，就有很多解决办法了。首先可以将这些热 key 进行分散处理。redis cluster有固定的16384个hash slot，对每个key计算CRC16值，然后对16384取模，可以获取key对应的hash slot。比如一个热 key 名字叫 hotkey，可以被分散为 hotkey#1、hotkey#2、hotkey#3，……hotkey#n，这 n 个 key 就会分散存在多个缓存节点，然后 client 端请求时，随机访问其中某个后缀的热key，这样就可以把热 key 的请求打散。

其次，也可以 key 的名字不变，对缓存提前进行多副本+多级结合的缓存架构设计。比如利用ehcache，或者一个HashMap都可以。在你发现热key以后，把热key加载到系统的JVM中，之后针对热key的请求，可以直接从jvm中获取数据。再次，如果热 key 较多，还可以通过监控体系对缓存的 SLA 实时监控，通过快速扩容来减少热 key 的冲击。

  7  大Key问题

有些时候开发人员设计不合理，在缓存中会形成特别大的对象，这些大对象会导致数据迁移卡顿，另外在内存分配方面，如果一个key特别大，当需要扩容时，会一次性申请更大的一块内存，这也会导致卡顿。如果大对象被删除，内存会被一次性回收，卡顿现象会再次发生。在平时的业务开发中，要尽量避免大key的产生。如果发现系统的缓存大起大落，极有可能是大key引起的，这就需要开发人员定位出大key的来源，然后进行相关的业务代码重构。Redis官方已经提供了相关的指令进行大key的扫描，可以直接使用。

解决方案： 

• 如果数据存在 Redis 中，比如业务数据存 set 格式，大 key 对应的 set 结构有几千几万个素，这种写入 Redis 时会消耗很长的时间，导致 Redis 卡顿。此时，可以扩展新的数据结构，同时让 client 在这些大 key 写缓存之前，进行序列化构建，然后通过 restore 一次性写入。

• 将大 key 分拆为多个 key，尽量减少大 key 的存在。同时由于大 key 一旦穿透到 DB，加载耗时很大，所以可以对这些大 key 进行特殊照顾，比如设置较长的过期时间，比如缓存内部在淘汰 key 时，同等条件下，尽量不淘汰这些大 key。

希望今天的讲解对大家有所帮助，谢谢！

Thanks for reading!

关注公众号，免费领学习资料

如果您觉得还不错，欢迎关注和转发~     

作者：乔克

引言

自动化已经常态化，99% 的公司或多或少都实现了部分自动化功能，比如应用的打包部署、服务器的批量维护、自动化测试等。

在实际工作中，我基本完成了前端、后端、移动端的自动化，但是一直没有涉及到小程序，主要原因在于：

• 小程序的开发受限平台的开发工具。

• 在开发小程序过程中，编译以及部署，都是开发通过可视化开发工具实现。

• 小程序应用比较少，容易忽略。

这就导致在开发小程序过程中，构建发布程序到生产或测试环境的时候，都是开发人员手动操作，发布不同的环境可能需要切换不同的分支，这样不仅增加了重复性工作，也大大增加了出错的概率。

鉴于此，我们决定将小程序实现自动化，减少开发的工作量，提升工作效率。

工具介绍

要实现小程序的自动发布并不难，我们可以借助 miniprogram-ci 工具实现，在改工具之前，大佬们大都是自己开发各种自动化脚本，现在我们就不用那么麻烦了。

 miniprogram-ci 是从微信开发工具中抽离的关于小程序/小游戏项目代码的编译模块，开发者可以不使用一些开发者工具，独立使用它就可以完成小程序代码的上传、预览等操作。其主要提供以下功能：

1. 上传代码，对应小程序开发者工具的上传。

2. 预览代码，对应小程序开发者工具的预览。

3. 构建 npm，对应小程序开发者工具的：菜单 – 工具 – 构建 npm。

4. 上传云开发云函数代码，对应小程序开发者工具的上传云函数能力。

5. 上传云托管代码，对应小程序开发者工具的上传云托管能力。

6. 上传云存储/静态托管文件，对应小程序开发者工具 – 云开发 – 云存储和静态托管文件管理。

7. 代理，配置 miniprogram-ci 的网络请求代理方式。

8. 支持获取最近上传版本的 sourceMap。

9. 支持 node 脚本调用方式和命令行调用方式。

前置工作

申请 APP ID

APP ID 是在微信后台申请，开发一般会提供。

制作构建镜像

要使用 miniprogram-ci ，需要我们安装该模块，安装命令如下：

为此，我们准备好具有 miniprogram-ci 命令的镜像。

然后制作镜像并推送到镜像仓库。

PS：根据实际情况选择 node 版本。

Zadig 配置

前置条件

• 拥有可用的 Zadig 服务，版本>=1.15.0

• 已经关联好代码仓库

开始配置

1、添加构建镜像

在 Zadig 的 系统配置 -> 构建镜像管理 处添加上面制作出来的构建镜像，如下：

2、创建项目

在 Zadig 中，选择 项目 -> 新建项目 ，添加一个小程序专属的项目，如下：

然后跳过向导，我们不需要环境，如下：

3、添加服务

添加服务的方式根据自己的情况来，不论是 YAML 项目还是 Helm Chart 项目，实际中我们都不会使用这些方式进行部署，随意选择就好，比如我这里选择的是 Helm Chart 项目。

之所以配置 Helm values，是为了让服务组件显示正常。

4、添加构建脚本

首先选择 构建环境 以及 代码信息 ，如下：

我们选择的是自定义的构建镜像。

然后添加一个构建变量，该变量的作用是设定推送机器人编号，我定义为 ROBOT_NUM，如下：

我选择的是枚举类型，定义了三个机器人代码（机器人可选 1 ~ 30），如下：

最后，我们编写构建脚本，如下：

注意：

• 我们是将小程序版本以及描述信息放在了 project.config.json 文件中，每个企业用法可能不一样。

• 我将小程序的密钥放在代码仓库的 secret 文件夹下。

然后保存构建退出。

5、添加工作流

现在，我们添加工作流进行应用发布，我这里选择的是自定义工作流，如下：

新增阶段，如下：

然后新增任务，选择构建，如下：

选择对应的服务组件，如下：

固定 ROBOT_NUM 参数（我们约定测试环境用机器人 1，生产环境用机器人 6），如下：

配置默认分支，测试环境用 test 分支，如下：

最后，配置触发器，实现开发将代码推送到对应分支，则自动触发流水线进行发布，如下：

然后保存退出即完成配置。

6、添加 IM 通知

IM 通知有助于团队小伙伴及时知道工作流的结果状态，不至于每次都需要在 Zadig 上查看，节约时间，提升效率。

选择工作流->配置->通知，如下：

填写具体的 IM 信息，配置完保存即可。

到这，执行工作流就可以在钉钉群里接收到工作流消息了。

7、测试

配置完成后，需要测试工作流是否正常。

首先进行手动测试。在工作流中选择对应的服务并执行，如下：

待流水线运行成功表示配置正常，如下：

再次进行 webhook 测试，我们需要在代码仓库更改代码并推送。

我在测试分支添加一个文件并推送，如下：

然后在 Zadig 上发现流水线正常被触发，如下：

不论是手动触发还是 webhook 触发，都能在钉钉群里接收到任务状态，如下：

到此我们完成了小程序测试环境的自动化，其他应用和环境相似操作即可。

最后

单纯想实现小程序自动化并不难，只要适配到企业本身的架构，使用哪种方式都可以，我们之所以选择 Zadig，主要还是因为其操作简单、使用便捷以及开发测试人员使用成本比较低。

目前我们已经将所有的发布工作都迁移到 Zadig 上了。

不过在使用自定义工作流配置小程序自动发布过程中，还是需要一些优化：

• 类似 App、小程序这种类型的应用，不属于 Helm、Yaml、主机类服务，在选择添加服务的时候容易产生混淆（虽然开发并不关心）

• 执行工作流的时候，默认是勾选了所有应用，当应用很多且不需要发布所有的时候，需要挨个去取消（个人觉得手动勾选比手动取消更容易接受）

整体使用上面没有太大的问题，小伙伴们在测试小程序自动发布的时候和我的可能有所区别，根据实际情况来做调整即可。

Zadig，开放，链接，专业。

关注公众号

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

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

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

作者：郝建伟

k3s 简介

官方文档：k3s

什么是k3s

1. 打包为单个二进制文件。

2. 使用基于 sqlite3 的轻量级存储后端作为默认存储机制。同时支持使用 etcd3、MySQL 和 PostgreSQL 作为存储机制。

3. 封装在简单的启动程序中，通过该启动程序处理很多复杂的 TLS 和选项。

4. 默认情况下是安全的，对轻量级环境有合理的默认值。

5. 添加了简单但功能强大的batteries-included功能，例如：本地存储提供程序，服务负载均衡器，Helm controller 和 Traefik Ingress controller。

6. 所有 Kubernetes control-plane 组件的操作都封装在单个二进制文件和进程中，使 k3s 具有自动化和管理包括证书分发在内的复杂集群操作的能力。

7. 最大程度减轻了外部依赖性，k3s 仅需要 kernel 和 cgroup 挂载。 k3s 软件包需要的依赖项包括：

为什么叫 k3s?

适用场景

k3s 适用于以下场景：

1. 边缘计算-Edge

2. 物联网-IoT

3. CI

4. Development

5. ARM

6. 嵌入 k8s

架构介绍

单节点架构

高可用架构

1. k3s Server 节点：两个或更多的server节点将为 Kubernetes API 提供服务并运行其他 control-plane 服务

2. 外部数据库：与单节点 k3s 设置中使用的嵌入式 SQLite 数据存储相反，高可用 k3s 需要挂载一个external database外部数据库作为数据存储的媒介。

k3s高可用架构:

固定 worker 节点的注册地址

如下图所示：

注册 worker 节点

自动部署的清单

k3s默认容器运行时

验证:

准备工作

关闭SELinux

关闭swap

设置主机名

离线安装

概述

离线安装的过程主要分为以下两个步骤：

步骤 1：部署镜像

步骤 2：安装 k3s

离线升级 k3s 版本: 完成离线安装 k3s 后，您还可以通过脚本升级 k3s 版本，或启用自动升级功能，以保持离线环境中的 k3s 版本与最新的 k3s 版本同步。

部署私有镜像仓库

前提条件

搭建参考Harbor安装

创建镜像仓库 YAML

手动部署镜像
前提条件

假设已经在离线环境中创建了节点。
这种方法需要您手动将必要的镜像部署到每个节点，适用于运行无法部署镜像仓库的边缘部署场景。

操作步骤

请按照以下步骤准备镜像目录和 k3s 二进制文件

1. 从k3s GitHub Release页面获取你所运行的 k3s 版本的镜像 tar 文件。

2. 将 tar 文件放在images目录下，例如：

3. 将 k3s 二进制文件放在 /usr/local/bin/k3s路径下，并确保拥有可执行权限。完成后，现在可以转到下面的安装 k3s部分，开始安装 k3s。

安装 k3s

更多安装选项参考 安装选项介绍 | Rancher文档

前提条件

1. 在安装 k3s 之前，完成上面的部署私有镜像仓库或手动部署镜像，导入安装 k3s 所需要的镜像。

2. 从 release 页面下载 k3s 二进制文件，k3s 二进制文件需要与离线镜像的版本匹配。将二进制文件放在每个离线节点的 /usr/local/bin 中，并确保这个二进制文件是可执行的。

3. 下载 k3s 安装脚本：https://get.k3s.io 。将安装脚本放在每个离线节点的任意地方，并命名为 install.sh。

当使用 INSTALL_K3S_SKIP_DOWNLOAD 环境变量运行 k3s 脚本时，k3s 将使用本地的脚本和二进制。

单节点安装

server节点

worker节点

注意：k3s 还为 kubelets 提供了一个–resolv-conf标志，这可能有助于在离线网络中配置 DNS


添加worker角色标签

kubectl命令行补全

高可用安装

需要调整安装命令，以便指定INSTALL_K3S_SKIP_DOWNLOAD=true并在本地运行安装脚本。您还将利用INSTALL_K3S_EXEC=’args’为 k3s 提供其他参数。

例如，使用外部数据库实现高可用安装指南的第二步提到了以下内容：

由于在离线环境中无法使用curl命令进行安装，所以您需要参考以下示例，将这条命令行修改为离线安装：

升级 k3s

通过脚本升级

离线环境的升级可以通过以下步骤完成：

1. 从k3s GitHub Release页面下载要升级到的 k3s 版本。将 tar 文件放在每个节点的/var/lib/rancher/k3s/worker/images/目录下。删除旧的 tar 文件。

2. 复制并替换每个节点上/usr/local/bin中的旧 k3s 二进制文件。复制https://get.k3s.io 的安装脚本（因为它可能在上次发布后发生了变化）。再次运行脚本。

3. 重启 k3s 服务。

启用自动升级功能

除了可以通过脚本升级 k3s 以外，您还可以启用自动升级功能，以保持离线环境中的 k3s 版本与最新的 k3s 版本同步。

从 v1.17.4+k3s1 开始，k3s 支持自动升级。要在离线环境中启用此功能，您必须确保所需镜像在您的私有镜像仓库中可用。

1. 你将需要与你打算升级到的 k3s 版本相对应的 rancher/k3s-upgrade 版本。

   注意，镜像标签将 k3s 版本中的+替换为-，因为 Docker 镜像不支持+。

2. 你还需要在你要部署的system-upgrad-controller manifestYAML 中指定的 system-upgrad-controller和kubectl的版本。

   在这里检查 system-upgrad-controller 的最新版本，并下载 system-upgrad-controller.yaml来确定你需要推送到私有镜像仓库的版本。例如，在system-upgrade-controller的 v0.4.0 版本中，在 manifest YAML 中指定了这些镜像：

3. 将必要的 rancher/k3s-upgrade、rancher/system-upgrade-controller 和 rancher/kubectl 镜像添加到您的私有镜像仓库中以后 ，就可以按照k3s 自动升级指南进行操作。

停止k3s

server节点停止k3s

worker节点停止k3s

卸载 k3s

卸载 k3s 会删除集群数据和所有脚本。

要使用不同的安装选项重新启动集群，请使用不同的标志重新运行安装脚本。

server 节点卸载 k3s

worker 节点卸载 k3s

Helm简介

​ Helm 是 Kubernetes 生态系统中的一个软件包管理工具。本文将介绍 Helm 中的相关概念和基本工作原理，并通过一个具体的示例学习如何使用 Helm 打包、分发、安装、升级及回退 Kubernetes 应用。

Kubernetes 应用部署的挑战

​ Kubernetes 是一个提供了基于容器的应用集群管理解决方案，Kubernetes 为容器化应用提供了部署运行、资源调度、服务发现和动态伸缩等一系列完整功能。

​ Kubernetes 的核心设计理念是: 用户定义要部署的应用程序的规则，而 Kubernetes 则负责按照定义的规则部署并运行应用程序。如果应用程序出现问题导致偏离了定义的规格，Kubernetes 负责对其进行自动修正。例如：定义的应用规则要求部署两个实例（Pod），其中一个实例异常终止了，Kubernetes 会检查到并重新启动一个新的实例。

​ 用户通过使用 Kubernetes API 对象来描述应用程序规则，包括 Pod、Service、Volume、Namespace、ReplicaSet、Deployment、Job等等。一般这些资源对象的定义需要写入一系列的 YAML 文件中，然后通过 Kubernetes 命令行工具 Kubectl 调 Kubernetes API 进行部署。

​ 以一个典型的三层应用 WordPress 为例，该应用程序就涉及到多个 Kubernetes API 对象，而要描述这些 Kubernetes API 对象就可能要同时维护多个 YAML 文件。

从上图可以看到，在进行 Kubernetes 软件部署时，我们面临下述几个问题：

• 如何管理、编辑和更新这些这些分散的 Kubernetes 应用配置文件。

• 如何把一套相关的配置文件作为一个应用进行管理。

• 如何分发和重用 Kubernetes 的应用配置。

Helm 的出现就是为了很好地解决上面这些问题。

Helm 是什么？

Helm 是Deis开发的一个用于 Kubernetes 应用的包管理工具，主要用来管理 Charts。有点类似于 Ubuntu 中的 APT 或 CentOS 中的 YUM。

Helm Chart 是用来封装 Kubernetes 原生应用程序的一系列 YAML 文件。可以在你部署应用的时候自定义应用程序的一些 Metadata，以便于应用程序的分发。

对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。

对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。

Helm 组件及相关术语

• Helm

Helm 是一个命令行下的客户端工具。主要用于 Kubernetes 应用程序 Chart 的创建、打包、发布以及创建和管理本地和远程的 Chart 仓库。

• Tiller

Tiller 是 Helm 的服务端，部署在 Kubernetes 集群中。Tiller 用于接收 Helm 的请求，并根据 Chart 生成 Kubernetes 的部署文件（ Helm 称为 Release ），然后提交给 Kubernetes 创建应用。Tiller 还提供了 Release 的升级、删除、回滚等一系列功能。

• Chart

Helm 的软件包，采用 TAR 格式。类似于 APT 的 DEB 包或者 YUM 的 RPM 包，其包含了一组定义 Kubernetes 资源相关的 YAML 文件。

• Repoistory

Helm 的软件仓库，Repository 本质上是一个 Web 服务器，该服务器保存了一系列的 Chart 软件包以供用户下载，并且提供了一个该 Repository 的 Chart 包的清单文件以供查询。Helm 可以同时管理多个不同的 Repository。

• Release

使用命令在 Kubernetes 集群中部署的 Chart 称为 Release。

注：需要注意的是：Helm 中提到的 Release 和我们通常概念中的版本有所不同，这里的 Release 可以理解为 Helm 使用 Chart 包部署的一个应用实例。

Helm 工作原理

这张图描述了 Helm 的几个关键组件 Helm（客户端）、Tiller（服务器）、Repository（Chart 软件仓库）、Chart（软件包）之间的关系。

Chart Install 过程

• Helm 从指定的目录或者 TAR 文件中解析出 Chart 结构信息。

• Helm 将指定的 Chart 结构和 Values 信息通过 gRPC 传递给 Tiller。

• Tiller 根据 Chart 和 Values 生成一个 Release。

• Tiller 将 Release 发送给 Kubernetes 用于生成 Release。

Chart Update 过程

• Helm 从指定的目录或者 TAR 文件中解析出 Chart 结构信息。

• Helm 将需要更新的 Release 的名称、Chart 结构和 Values 信息传递给 Tiller。

• Tiller 生成 Release 并更新指定名称的 Release 的 History。

• Tiller 将 Release 发送给 Kubernetes 用于更新 Release。

Chart Rollback 过程

• Helm 将要回滚的 Release 的名称传递给 Tiller。

• Tiller 根据 Release 的名称查找 History。

• Tiller 从 History 中获取上一个 Release。

• Tiller 将上一个 Release 发送给 Kubernetes 用于替换当前 Release。

Chart 处理依赖说明

Tiller 在处理 Chart 时，直接将 Chart 以及其依赖的所有 Charts 合并为一个 Release，同时传递给 Kubernetes。因此 Tiller 并不负责管理依赖之间的启动顺序。Chart 中的应用需要能够自行处理依赖关系。

部署 Helm

安装 Helm 客户端

Helm 的安装方式很多，这里采用二进制的方式安装。更多安装方法可以参考 Helm 的官方帮助文档。

• 使用官方提供的脚本一键安装

• 手动下载二进制包安装

Tiller 是以 Deployment 方式部署在 Kubernetes 集群中的，只需使用以下指令便可简单的完成安装。

注：storage.googleapis.com默认是不能访问的，该问题请自行解决。如果不清楚是否能访问，当你把这行命令cp linux-amd64/helm /usr/local/bin/完，看一下是否都是ok的

由于 Helm 默认会去storage.googleapis.com拉取镜像，如果你当前执行的机器不能访问该域名的话可以使用以下命令来安装：

接下来查看状态

上图可看出：现在，已经能够查看到服务器的版本信息了，部署完成

后面下载包会报错，是因为从 Kubernetes 1.6 版本开始，API Server 启用了 RBAC 授权。目前的 Tiller 部署时默认没有定义授权的 ServiceAccount，这会导致访问 API Server 时被拒绝。所以我们需要明确为 Tiller 部署添加授权。

生成.kube配置

安装NFS

部署说明

Kubernetes网络文件系统，主要用于ES、Kafka、Minio等持久化存储。

nfs搭建

配置共享目录

部署Pod遇到的问题

Helm部署Chart时报错

部署 nfs pod时报错

Pod拉取镜像超时报错

常用命令行

kubectl命令

node的标签操作

ctr 命令使用

containerd 相比于docker , 多了namespace概念, 每个image和container 都会在各自的namespace下可见

ctr，crictl，docker命令对比

crictl 命令使用

配置containerd镜像加速

其他命令：

几种Containerd常用命令对比

作者：毛辰飞

背景

在mysql中设计表的时候，mysql官方推荐不要使用uuid或者不连续不重复的雪花id(long形且唯一)，而是推荐连续自增的主键id，官方的推荐是auto_increment，那么为什么不建议采用uuid，使用uuid究竟有什么坏处？今天我们就来分析这个问题，探讨一下内部的原因。

数据展示

user_auto_key，user_uuid，user_random_key，分别表示自动增长的主键，uuid作为主键，随机key作为主键，其它我们完全保持不变。根据控制变量法，我们只把每个表的主键使用不同的策略生成，而其他的字段完全一样，然后测试一下表的插入速度和查询速度：

注：这里的随机key其实是指用雪花算法算出来的前后不连续不重复无规律的id:一串18位长度的long值







可以看出在数据量100W左右的时候,uuid的插入效率垫底，并且在后续增加了130W的数据，uuid的时间又直线下降。

时间占用量总体可以打出的效率排名为：auto_key>random_key>uuid，uuid的效率最低，在数据量较大的情况下，效率直线下滑。

原因分析

对比一下mysql关于两者索引的使用情况.

自增的主键的值是顺序的,所以Innodb把每一条记录都存储在一条记录的后面。当达到页面的最大填充因子时候(innodb默认的最大填充因子是页大小的15/16,会留出1/16的空间留作以后的修改)：

①下一条记录就会写入新的页中，一旦数据按照这种顺序的方式加载，主键页就会近乎于顺序的记录填满，提升了页面的最大填充率，不会有页的浪费

②新插入的行一定会在原有的最大数据行下一行,mysql定位和寻址很快，不会为计算新行的位置而做出额外的消耗

③减少了页分裂和碎片的产生

因为uuid相对顺序的自增id来说是毫无规律可言的,新行的值不一定要比之前的主键的值要大,所以innodb无法做到总是把新行插入到索引的最后,而是需要为新行寻找新的合适的位置从而来分配新的空间。这个过程需要做很多额外的操作，数据的毫无顺序会导致数据分布散乱，将会导致以下的问题：

①：写入的目标页很可能已经刷新到磁盘上并且从缓存上移除，或者还没有被加载到缓存中，innodb在插入之前不得不先找到并从磁盘读取目标页到内存中，这将导致大量的随机IO

②：因为写入是乱序的,innodb不得不频繁的做页分裂操作,以便为新的行分配空间,页分裂导致移动大量的数据，一次插入最少需要修改三个页以上

③：由于频繁的页分裂，页会变得稀疏并被不规则的填充，最终会导致数据会有碎片

在把随机值（uuid和雪花id）载入到聚簇索引(innodb默认的索引类型)以后,有时候会需要做一次OPTIMEIZE TABLE来重建表并优化页的填充，这将又需要一定的时间消耗。

自增ID的缺点：

那么使用自增的id就完全没有坏处了吗？并不是，自增id也会存在以下几点问题：

①. 别人一旦爬取你的数据库,就可以根据数据库的自增id获取到你的业务增长信息，很容易分析出你的经营情况

②. 对于高并发的负载，innodb在按主键进行插入的时候会造成明显的锁争用，主键的上界会成为争抢的热点，因为所有的插入都发生在这里，并发插入会导致间隙锁竞争

③. Auto_Increment锁机制会造成自增锁的抢夺,有一定的性能损失

TIS整合ChunJun实操

B站视频：

https://www.bilibili.com/video/BV1QM411z7w5/?spm_id_from=333.999.0.0

一、ChunJun 概述

ChunJun是一款易用、稳定、高效的批流统一的数据集成框架，可基于实时计算引擎Flink实现多种异构数据源之间的数据同步与计算，既可以采集静态的数据，比如MySQL，HDFS等，也可以采集实时变化的数据，比如Binlog，Kafka等。

目前的核心功能包括：

· 多源异构数据汇聚

作为一个开放式系统，用户可以根据需要开发新的插件，接入新的数据库类型，也可以使用内置的数据库插件。目前兼容30+异构数据源的数据读写与SQL计算。

· 断点续传

针对网络波动等异常情况，导致数据同步失败的任务，在下一次任务时自动从上一次失败的数据点进行数据同步，避免全部重跑。

· 数据还原

除了DML操作以外，一些源端数据库的DDL操作也能做到同步，最大程度保证源端数据库和目标端数据库的数据统一和结构统一，做到数据还原。

· 脏数据管理

数据传输过程中，因数据质量或主键约束等其他因素导致数据无法同步到目标数据库，针对这些脏数据进行统计和管理，便于后续进行脏数据分析。

· 速率控制

数据同步过程中，数据传输效率是关键。ChunJun针对各种场景，有的放矢地控制速率，最大程度保证数据同步的正常进行。

更多详见：

Github：https://github.com/DTStack/chunjun

Gitee：https://gitee.com/dtstack_dev_0/chunjun

官网：https://dtstack.github.io/chunjun/

ChunJun架构：

二、TIS 概述

TIS最早是基于Solr为用户提供一站式开箱即用、自助服务的搜索引擎中台产品。在2020年之前，当Flink和MPP引擎还没有形成影响力时 ，TIS就已经在为互联网企业内部提供实时OLAP分析需求的服务。

为满足大数据业务需求，快速将工具栈进行整合。TIS从2019年底开始转型，开始全方位支持现有实时数仓中台，从原先与搜索引擎强耦合的技术架构进行重构。从只处理搜索引擎一个场景，兼容到所有数据端的大数据生态场景。

经过TIS开发者的努力，现在的TIS内部有一套强大的数据管理系统，根据用户需求大部分的工作脚本可自动生成（TIS是基于模型的DataOps，区别于市面上其他基于脚本任务的DevOps系统，摒弃掉所有繁琐的脚本操作），等到任务所需资源准备好，用户轻点数据系统就开始运行。

另外更为关键的是，TIS能够将专业大数据技术人员和大数据分析师这两种角色解耦。一个实时数仓中台，使用它的人并不需要了解里面的技术细节，并不需要知道Flink、Hive、Hadoop的技术细节，只要知道他们是干什么的就行。基于以上，TIS改造之初并没有针对实时数仓进行编码，而是花了将近一年时间对TIS产品底座进行构建，着重进行了以下几方面的构建：

插件仓库/热生效机制

现有行业中提供的工具栈，需要在后台系统中自行部署，TIS则简化了这一流程，TIS在构建项目之时会统一将第三方的依赖包进行打包，预先部署到远端仓库中，用户在TIS中可以查看到可用插件清单。在使用时，只需鼠标下载且热生效就可使用，操作体验流畅。

全流程建模

针对ETL的各流程进行建模，将可变因素进行抽象，抽取成一个TIS系统中的扩展点，统一归档到TIS的主工程中，在主工程中没有任何具体业务代码的实现，这样在进行具体业务逻辑实现中就不需要更改任何主工程的代码，在架构层面最大限度地贯彻了OCP原则。

例如以下是对ETL中，针对结构化（支持JDBC接口）和非结构化数据源的执行流程图：

构建UI-DSL系统

随着整合进TIS的功能组件越来越多，需要单独开发的UI工作量巨大且风格难以统一，大量重新代码维护困难，同时由于行业分工精细化，流程需要前后端工程师相互协作，导致开发效率低，如何让没有前端开发经验的后端开发工程师，能够独立且畅快地完成一个UI组件的开发，成为一个重要的课题。为解决这个问题，TIS在底座中实现了一个UI-DSL的系统，后端开发工程师使用JAVA语言编写一个表单对应的MetaData脚本，里面定义表单的布局，输入项的校验等信息，运行期会自动将MetaData脚本渲染成前端的表单，从而完美解决这个课题。

如上，是TIS中定义的MySQL数据源插件，只需要在对应POJO上为对应的属性添加FormFieldAnnotation标识，在配上字段对应的默认值、label等信息描述文件：

DataSourceFactory.json

三、整合 ChunJun 完善 TIS 生态

经过几个月时间的研发，TIS V3.6.0-alpha版本终于发布了。该版本的最大亮点，即整合了大数据领域数据同步工具的翘楚ChunJun，将TIS的业务能力提升到了新高度。

TIS的最新版本：

https://github.com/qlangtech/tis/releases/tag/v3.6.0-alpha

早在 V3.6.0-alpha之前，TIS已经整合了Alibaba DataX和 Flink-CDC。离线批量同步利用DataX组件实现，而在实时数据变更Source组件方面，TIS是基于Flink-CDC来实现的。至于Sink部分，则一直是基于各种数据端提供的生态API包经过二次开发完成的。

其中存在的问题是，开发周期长，调试困难，例如，仅仅为了实现StarRocks一个Sink端实现一个基于StreamFunction的Sink实现，连开发带测试花去了整整三个星期的时间。

直到整合ChunJun之后才解决了这些问题。ChunJun已经很好地支持了大数据领域的大部分数据端，包括Source和Sink。它的Source端基于Polling轮询机制来实现，相较与Flink CDC实现的Source端是有自己的特色的。

例如，并不是所有的端都支持类似MySQL binlog这样的实时同步机制，即使支持类似Oracle的LogMiner，如需开启，也需要专业Oracle DBA协助，不然设置权限就会吓退很多用户。而基于Polling机制的实时更新订阅却可以支持所有的Source端，只要实现了JDBC接口就行。

所以ChunJun的Source端通用性非常好，比之于Flink CDC的唯一劣势是实时性要低，不过一般在大部份OLAP的场景下用户对实时性的要求并没有那么高，所以一般情况下推荐使用ChunJun的Source来监听实时数据变更。

另外，ChunJun的Sink端实现也是一大特色，一般情况下数据端的生态产品中会提供Flink Sink的实现，例如：ElasticSearch的Flink官网提供了一个基于SinkFunction的实现，StarRocks在官网也提供了Sink实现。但是各家实现方式各不相同，没有一个统一的抽象模型。另外各厂商提供的实现中基本上只是一些半成品，像容灾、监控等都没有提供，导致TIS在整合各家Sink端时着实花了不少精力且很难做得完美。

因此在 TIS v3.6.0 中利用 ChunJun v1.12.5 全面改写了TIS原有的Sink端实现，由于ChunJun实现是一个封装好并且已经在生产环境中经过检验的，并且在实现方式上已经通过统一建模，每种端的接入方式可以统一，对TIS来说大大提高了整合开发效率，而且将容灾、监控、脏数据管理也一并实现。

ChunJun支持的Connector端非常丰富，TIS v3.6.0 中只是拣取了几个用户高频使用的端来封装，其他端的封装会在后续版本中逐步实现。以下是 v3.6.0版本中实现的端类型：

四、TIS 是如何整合 ChunJun

利用 TIS数据管理系统接管 ChunJun流数据类型控制

ChunJun 流处理中构建的RowData实例是通过目标端Jdbc MetaData自动生成的（用户不需要在JSON配置文件中设置），内部需要通过目标端（Source/Sink）字段JDBC中的数据信息的fieldType作为参数来映射 flink的DataType实例，调用的接口是com.dtstack.chunjun.converter.RawTypeConverter，

在实际处理过程中发现，仅仅利用 JDBC col metaDatafieldType作为参数还是不够, 例如：MySQL的表定义为bigint，int，smallint的整型，当用户添加unsigned修饰，bigint在Flink中的映射类型需要从BigIntType变成DataTypes.DECIMAL，原smallint类型需要变成IntType，不然执行就会出错。另外像 Oracle的Jdbc内部实现了一套区别于Jdbc标准的类型规范oracle.jdbc.OracleTypes，当得到Oracle的类型之后需要归一化成Jdbc的类型java.sql.Types，不然没法正常执行。

类型映射虽然很简单，但由于Java是强类型语言，在流处理执行过程中稍有不慎就会出现ClassCastException，所以得格外小心地处理，因此TIS在ChunJun中引入了一个新的类型抽象com.qlangtech.tis.plugin.ds.ColMeta来封装Jdbc MetaData的列信息，在具体执行过程中可以更加细腻地控制Flink 内部的列类型。

取代基于JSON配置驱动的任务变为基于数据模型驱动任务

有了TIS底层数据关系管理的支持，数据同步任务定义的大部分工作可以自动生成，用户只需要做一些辅助工作，例如，用户需要导入一个张表，表有10列，用户需要做的是辅助确认：对于Source端确认表主键，Polling策略的轮询间隔时间及轮询列名，对于Sink端选取Insert的插入策略，这些都只需要鼠标就能完成,页面UI中的显示逻辑和ChunJun的规则相一致。

为ChunJun添加新的TIS扩展点

想要在 v3.6.0 版本顺利地将ChunJun Connector整合进TIS，需要添加两个功能扩展点，一是为增量Source端表的属性设置com.qlangtech.tis.plugins.incr.flink.chunjun.source.SelectedTabPropsExtends，二是为Sink端表的属性设置com.qlangtech.tis.plugins.incr.flink.chunjun.sink.SinkTabPropsExtends

五、开源共建，繁荣生态

TIS的构建理念是坚决避免重复造轮子，必须站在行业的巨人的肩膀上，做大数据行业中优秀工具栈的粘合剂。TIS V3.6.0alpha 有幸能按时发布，得益于行业中有像ChunJun、DataX、Flink-CDC、Flink这样优秀的开源项目存在 ，使得TIS整体可靠性得到保障。特别要感谢Apache Flink，提供了一个强大的实时计算生态，Flink CDC、ChunJun和TIS都是生长在这个生态中的茁壮成长的小树苗，每个项目都专注于自己擅长的领域，且相互补充。

临近发布，发现一个很有意思的使用场景，那就是用户可以选择基于Flink-CDC的MySQL Source插件来监听MySQL 表的增量变更，将数据同步到以 ChunJun 构建的 Sink中去，这样的混搭使用方式给用户带来了更多的选择自由度，也避免了在Flink-CDC和ChunJun各自的框架内部重复造轮子从而造成生态内卷。

六、拥抱CloudNative

云原生（CloudNative）时代的到来为我们描绘了一副美好的画卷，对于终端用户来说提供了低成本、可靠的IT基础服务，可以专注于业务开发，这非常好。

但对于互联网技术从业者来说，似乎有隐忧，那就是互联网红利将会被阿里云这样的云厂商通吃，小厂商只有干瞪眼的份，那我们煞费苦心构建的像TIS这样的开源项目在云时代还有用武之地吗？其实这样的担心是多余的。

一个健康的生态，必须要保证生物多样性，生态中各个物种并不是独立，他们之间存在相互依存的关系。同样在大数据生态中如果只有像阿里云、亚马逊这样互联网大厂活得很滋润，并且构成了一个人才黑洞，把其他小厂的资源全部吸干了，想必这样的生态也不可能长远。

从本质来说，促成任何个人或组织之间的合作都有一个前提，那就是存在比较优势，就如同瞎子背瘸子相互协助前行，国家之间的合作也是，中国具有廉价劳动力和广阔的市场与发达国家的技术优势进行互补，这种合作是可持续的。

云大厂可以把昂贵的互联网基础设置，用集约化采购的规模优势大大地降低成本，然后用技术手段将这些设备云化成IAAS服务提供给客户，小厂技术具有灵活高效与较低的技术人员薪资成本优势，以这种优势在IAAS之上构建PAAS服务，类似任务调度，实时数仓非常合适。国外也已经有成功的案例，比如Snowflake提供的云原生实时数仓和亚马逊等云厂商之间的合作，有同学肯定会问：”为啥亚马逊不能自己搞一个像snowflake呢？”，其实答案前面已经提到。

想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友，浏览袋鼠云官网：https://www.dtstack.com/?src=szkyzg

添加【小袋鼠：dtstack001】入qun，免费获取大数据&开源干货

同时，欢迎对大数据开源项目有兴趣的同学加入「袋鼠云开源框架钉钉技术qun」，交流最新开源技术信息，qun号码：，项目地址：https://github.com/DTStack

从录音带、MP3到专业的耳机、音箱，随着音乐消费方式的不断升级，音乐创作的专业“门槛”也在AI技术的加持下逐渐大众化，创作者的创新设计、创作频率也在持续增强，能降低创作门槛且智能化的创作工具就显得尤为重要。

怀揣着“人人都能玩点音乐”的初衷，唱鸭搭建了自己的音乐社区，希望为普通用户提供智能有趣的音乐“玩法”。唱鸭是一款将乐器和曲谱标记融合的新型弹唱软件，用户通过 App内的图标提醒，不需要乐器知识，就可以轻松实现创作、弹唱音乐，降低了非专业音乐人“玩音乐”的难度。

在华为开发者大会2022（Together）智慧AI技术论坛中，唱鸭作为一款作为深受用户喜爱的音乐社区软件，讲述为满足用户不断增强的创意设计，如何与HMS Core音频编辑服务合作，打造更具创意的音乐“玩法”。11月5日唱鸭正式推出，由HMS Core音频编辑服务歌声合成技术打造的“AI创作歌姬”功能。基于华为独创的AI Singer模型，歌声合成可以精准预测颤音、扰动和换气声等演唱技巧，让拟真的呼吸音与歌曲节奏完美契合，实现歌手级的高水准演唱，给用户带来了令人惊喜的新奇体验，释放更具创意的音乐创作力。

用户选择“AI创作歌姬”后，只需输入歌词，选择喜欢的音乐风格，就会自动生成动听的歌曲，并通过细腻自然、情感充沛的歌声演唱出来。在演唱节奏方面，“AI创作歌姬”实现了歌词和曲谱在“字”级别的对齐，提升了演唱自然度和节奏准确性。

唱鸭创始人李阳说到：“与HMS Core音频编辑服务的合作后，唱鸭让用户能够通过简单地输入歌词即可合成歌声，轻松完成各种类型的演唱，让没有专业学习音乐的人也能够享受到音乐互动的乐趣。AI技术赋能提升了我们的用户体验，也助力了唱鸭的业务创新。”

HMS Core音频编辑服务提供的歌声合成能力还可广泛应用于音视频创意制作、影音娱乐、音乐教育、虚拟偶像等领域。例如，在短视频或音乐创作中为用户提供歌词歌曲合成、演唱等能力，激发更多创作灵感；或是为虚拟偶像选择独特音色，使其形象更加生动逼真；或是设定为不同情景的参考声音，提高音频制作效率。

未来，HMS Core将为音乐创作者，提供更高效智能、新奇有趣的音乐“玩法”。让灵感，成就创作，真正实现“让每一个人都成为音乐家！”的愿景。

Data Catalog 通过汇总技术和业务数据，解决大数据生产者组织梳理数据、数据消费者找数和理解数的业务场景。本篇内容源自于火山引擎大数据研发治理套件 DataLeap 中的 Data Catalog 功能模块的实践，主要介绍 Data Catalog 在公有云部署和发布中遇到挑战及解决方案。

背景

• Data Catalog 是一种数据管理的服务，会收集技术数据，并在其基础上提供更丰富的业务上下文与语义，通常支持数据编目、查找、详情浏览等功能。目前 Data Catalog 作为火山引擎大数据研发治理套件 DataLeap 产品的核心功能之一，经过多年打磨，服务于字节跳动内部几乎所有核心业务线，解决了数据生产者和消费者对于数据和资产管理的各项核心需求。

• DataLeap 作为一站式数据中台套件，汇集了字节内部多年积累的数据集成、开发、运维、治理、资产、安全等全套数据中台建设的经验，助力 ToB 市场客户提升数据研发治理效率、降低管理成本。

• Data Catalog 作为 DataLeap 的核心功能之一，本文汇集了 Data Catalog 团队在最近一年公有云从 0 到 1 实践的整体经验，主要讲解遇到的各项挑战和对应的解决方案。

Data Catalog 公有云发展历程

Data Catalog 已经随着 DataLeap 一起作为公有云产品正式在火山引擎对外发布，下面是 Data Catalog 在功能演进上的一些重要时间节点：

• 2021 年 9 月，Data Catalog 随着 DataLeap 完成在火山引擎公有云首个版本部署和发布，包含 60%内部核心功能，支持 EMR Hive 数据源数据管理。

• 2022 年 2 月，Data Catalog 随着 DataLeap 完成火山引擎公有云 Beta 版本发布，吸引了一批客户试用。

• 2022 年 5 月，Data Catalog 随着 DataLeap 完成火山引擎公有云 GA 版本发布，正式对外开放。

• 2021 年 9 月至 2022 年 5 月，Data Catalog 发布 10+版本，对齐 95%内部核心功能以及发布新功能 20+，包括支持 LAS/ByteHouse 数据源、OpenAPI 和数据采集等 ToB 场景新特性。

Data Catalog 公有云整体架构

Data Catalog 支持综合搜索、血缘分析、库表管理、数据采集、备注问答、专题管理、OpenAPI 等功能，和 DataLeap 其他功能模块（如数据开发、数据集成、数据质量、数据安全等）一起提供了大数据研发和治理场景的一站式解决方案。同时，Data Catalog 公有云产品是基于火山引擎提供的数据引擎和云基础设施来部署和服务的，下面会简单介绍下我们所依赖和使用的产品和服务：

• 数据引擎：是火山引擎提供的数据分析、数据仓库和数据湖相关产品，包括 ByteHouse/EMR/LAS 等产品。通常 Data Catalog 会从这类系统内采集并存储数据，进行处理加工后，再提供搜索、血缘分析等功能；另外，库表管理模块也会依赖这类系统提供对应的接口来做建库建表等操作。

• 内部公共服务：是火山引擎为支持公司内部产品上公有云提供的若干公共基础服务，主要作用是方便内部产品能快速在公有云部署，提供和公司内部兼容性比较高的公共服务，降低改造和迁移成本。其中 Data Catalog 使用较多的包括：API 网关、网络代理、访问控制、安全认证、监控报警等。

• 基础服务：这类服务或产品相较于上面说的内部公共服务主要区别是，他们是火山引擎对外售卖的标准云服务，内外部用户都可使用，且和业界主流云厂商能力是基本对齐的，不过会和公司内部一些类似的基础服务会有不少差异。Data Catalog 主要使用这类基础服务来进行自身服务的部署运维，并且进行较多的兼容性改造，包括容器部署、网络打通、内外部 CICD 和监控报警流程一致性等方面。

• 数据库和中间件：是和业界主流云厂商对齐的存储和中间件领域的标准云服务，和公司内部对应组件也会有若干差异，Data Catalog 为此也做了多版本的兼容。Data Catalog 在数据存储上使用到了 Hbase/MySQL/ES/Redis，然后在数据采集和同步场景使用了 Kafka，同时用到了日志服务来提高研发运维效率。

Data Catalog 公有云遇到的挑战

Data Catalog 经历了一个从 0 到 1 在火山引擎公有云部署并逐步优化和迭代发布 10+版本的过程，在这个过程中经历不少挑战，下面将介绍其中比较典型的问题以及我们探索并实践的一些解决方案。

网络和数据安全

为保证网络安全和多租户数据安全，火山引擎上公有云产品部署的环境划分为“公共服务区”和“售卖区”，同时售卖区又分割为若干私有网络（即 VPC），然后公共服务区和售卖区以及售卖区的 VPC 之间都是网络隔离的。

Data Catalog 会依赖一些内部公共服务，这类服务通常都部署在公共服务区，而按照网络和数据安全规范，Data Catalog 作为独立云产品需要部署在售卖区独立 VPC 内，类似的情况 Data Catalog 依赖的数据中台产品也需部署在独立 VPC 内，例如 EMR、LAS 和 Bytehouse。另外，Data Catalog 对外会提供 OpenAPI，外部客户可以通过火山引擎的 API 网关来访问这些 API，但 API 网关服务是在公共服务区，无法直接访问到 Data Catalog 服务，基于以上情况，为了正常对外提供服务，我们需要解决网络隔离问题同时还要保证安全性。

解决方案：

服务部署：为了能够在售卖区部署，经过调研我们选择火山引擎提供的容器服务（VKE）和负载均衡（CLB）来进行基础服务部署和构建，其中 CLB 提供四层负载均衡能力，容器服务是高性能 Kubernetes 容器集群管理服务。Data Catalog 基于容器服务提供的无状态负载（Deployment）、定时任务（CronJob）、服务（Service）等云原生容器管理功能进行基本服务和调度任务部署，同时也使用火山引擎的存储和中间件，以上组件均在同一个 VPC 内，能够保证网络连通以及数据安全。

• 网络打通：为解决上文所说的网络隔离问题，经过调研我们使用了公司通用的网络代理服务（PLB/Shuttle），该网络代理可做到网络打通的同时保证四层网络流量的安全，从而达到我们和各依赖方如公共服务（API 网关、IAM 等、独立部署的云服务（EMR/LAS 等）的网络连通目标。

• 数据安全：火山引擎部署环境做网络隔离，主要是保证安全性，我们虽然使用网络代理打通网络，但是仍需保证各个环节的安全性，考虑到服务间交互都是通过 HTTP 请求，我们对和外部交互的接口都增加了 SSL 和双向认证的机制，同时在安全认证方面，我们没有使用 Nginx 或 Java 原生的方案，而是借助于火山引擎内部安全服务中的 ZTI 团队的 envoy 组件来实现，同时使用 sidecar 模式和我们后端服务容器集成部署，既降低了服务端部署改造成本，也解耦了服务端业务逻辑和安全认证逻辑。

多租户适配

这里先对多租户相关概念做一些解释：

• 租户：一个客户、公司、个人开通或购买了火山引擎的云产品，火山引擎就会通知对应的服务提供者，对应云产品会感知到他的开通，这个客户就是这个云产品的一个租户，实际场景可以类比于一个公司是一个租户，不同的公司是不同的租户。

• 多租户服务：云服务要为多个租户提供服务，需要做到租户隔离，保证各租户的访问控制、数据、服务响应等各方面的使用都是隔离的，彼此互不感知互不影响的。要做到租户隔离，就需要云服务能通过逻辑或物理隔离的方式来将各租户对应数据和访问隔离开来，避免互相影响。

此前，在字节跳动内部实践中不存在多租户场景，所以面向公有云用户服务时，Data Catalog 针对支持多租户服务的能力，需要进行专门适配。

解决方案：

Data Catalog 在数据存储层借用了 Apache Atlas 的设计与实现。Atlas 的底层使用 JanusGraph 做图引擎，JanusGraph 是基于 Gremlin 图查询语义实现的计算引擎，而社区版 Atlas 不支持多租户场景。我们通过在 Atlas 上增加 JanusGraph Partition Strategy 适配，实现存储层租户逻辑隔离。

参考以上示例，JanusGraph 的 Partition Strategy 可以支持设置的 read/write Partition 的 value，并保证只读/写指定 Partition 的数据，从而达到数据隔离，我们将租户信息和 Partition Strategy 相结合，实现了多租户场景下读写数据的逻辑隔离，保证了数据安全性。

内外部功能一致

Data Catalog 在字节跳动内部已打磨多年，产品形态和技术架构比较成熟，但随着公有云部署和 ToB 产品迭代，因内部外基础服务差异和 ToB 引入新的使用场景和上下游组件导致内外部产品功能和技术实现的差异也越来越多。

在前几个版本中，我们尝试使用独立的代码分支和版本来支持 ToB 功能，避免内部新功能对 ToB 产生影响，但我们发现随着版本差异越来越大，代码和功能的合并和兼容就变得非常困难，在其中一次整体代码合并时，出现了好几千的文件 diff 和上百处 merge conflict，我们花费了一周时间多的时间合并代码和进行多环境测试回归验证，最终完成了合并。功能和代码的不一致已经成为影响研发效率和需求交付进度的很重要因素，必须要进行优化。

解决方案：

我们主要从产品功能和代码版本两方面来处理内外部一致性问题：

产品功能

• 产品功能的标准化：原则上所有功能都应做到内外部一致，只允许部分功能点的实现区别。我们期望能将各功能都进行标准化，基础模块和通用能力（如数据模型、搜索、血缘）原则上需保持内外一致，内外部依赖或需求场景差异较大的功能（如数据接入和采集、库表管理）改造为标准化流程，将差异部分尽量减小，做到只通过配置、插件、版本控制工具等方式就能适配，减少研发和运维成本。

• 明确的一致性规划：从模块到功能点逐个对比内部外实现情况，制定长期 roadmap，明确差异点的支持排期，并提高对齐内部功能的工作优先级，逐步减少差异。

• 新功能的兼容性：新功能的设计需考虑内外部一致性，包括产品的交互和研发的技术方案都需考虑外部场景并明确兼容方案，原则上对特殊场景定制化功能都需考虑通用场景适配，尽量保持多环境的兼容性。

技术实现

• 统一的代码分支管理规范：原则上内外部的代码是一致的即统一的分支。具体来说，不管域内外功能都需兼容多环境并在多环境验证才能合并代码，外部如公有云在发版周期中会基于内部主分支代码（如 master 分支）创建一个新的 release-x.x.x 分支，进行回归验证和公有云上线，同时线上持续使用 release-x.x.x 分支以保证线上环境稳定，release-x.x.x 分支需定期合回主分支。新的版本会继续基于主分支开发，并持续保持该规范。

• 明确的发版规划：根据实际情况，内部通常迭代比较敏捷发版频率较快，而外部通常要求稳定性，会定期发版（如每月一个版本），考虑到发版周期的差异，我们会以外部固定周期为标准，细粒度控制需求评估、功能开发、QA 测试、回归测试等各环节所在时间段，明确封板时间，降低内外部互相影响。

• 一致性意识和自动化多环境验证：通过多轮分享和培训在技术团队内部对齐一致性意识，清楚内外部差异点 FAQ 等，另外，如上所说新功能技术设计方案需明确多环境兼容性。同时，引入自动化的多环境验证环节，尽早发现不兼容或不一致的问题，减少人工判断和测试的成本。

OpenAPI

在 DataLeap Beta 版本发布之后，有内外部客户在试用，当时就有客户提出 OpenAPI 的需求，但在 Beta 版本我们还未支持 OpenAPI。公司内部有 OpenAPI 规范和平台，Data Catalog 也借助相关平台实现了内部的 OpenAPI，但是 ToB 场景的公共平台不同且会遇到 ToB 场景特定的问题（如安全认证、多租户、API 开通计费等），需要综合考虑来对外提供解决方案。

解决方案：

如前文介绍，火山引擎内部公共服务有 API 网关的通用服务（TOP），并有若干 API 发布规范，Data Catalog 调研了该 API 网关并解决以上核心问题来支持 ToB OpenAPI。以下介绍一下主要流程和关注点：

API 管理

• Data Catalog 借助于 API 网关管理 OpenAPI，包括注册和开通、访问控制、限流等。

• API 规范：火山引擎 OpenAPI 有明确的参数规范，Data Catalog 也需符合该规范，但因内部 OpenAPI 参数格式不同，需做兼容，考虑到新 API 的支持成本，借助于 Spring 的 Interceptor 和 Advice 以及定制 JSON 序列化和反序列化逻辑，实现了自动的参数格式转化，降低 API 格式兼容的开发成本。

• 访问控制：火山引擎作为云服务提供商，使用业界规范的 AKSK 密钥管理规范，API 使用者需创建 AKSK 并通过该信息来访问 API 才可通过访问控制，而 API 网关会通过 IAM 进行鉴权，通过后会给服务提供者也就是 API 注册者透传用户的身份（如租户 ID，用户 ID），方便 API 提供者使用。

• 安全认证：处理 API 网关提供的基础鉴权，Data Catalog 也增加了更多机制来保障安全性，包括双向认证、租户开通状态检测等。

• API 文档：对于每一个 OpenAPI 都根据火山引擎规范编写了详细的参数说明，汇总为一个正式 API 文档，方便用户查阅使用。

API 请求流程

1. 用户或服务通过 AKSK 访问 API，或者通过前端控制台间接访问 API。

2. API 网关通过 IAM 进行鉴权，将识别到的用户身份通过 HTTP header 透传给服务提供者。

3. 服务提供者接收到请求并通过 HTTP header 获取用户身份，进行下一步处理。

总结

火山引擎 Data Catalog 产品是基于字节跳动内部平台，经过多年打磨业务场景和产品能力，在公有云进行部署和发布，期望帮忙更多外部客户创造数据价值。目前公有云产品已包含内部成熟的产品功能同时扩展若干 ToB 核心功能，正在逐步对齐业界领先 Data Catalog 云产品各项能力。

文中提及的内容其实还有继续优化的空间，以及随着客户的使用，还有面临一些新的问题，包括多租户性能优化、服务稳定性保障等，我们都在持续探索和解决，期望能更好的支持 ToB 客户的业务诉求并实现商业价值的同时，提供优质稳定的服务和丰富的扩展能力。

跳转火山引擎大数据研发治理套件DataLeap了解更多

值得信赖

为什么使用

桌面软件（办公方向、 个人工具），仍然是未来十几年 PC 端需求之一，提高工作效率

electron 技术是流行趋势，百度翻译、阿里网盘、迅雷、有道云笔记 ……

ee 框架使用 b（浏览器）s（主进程）s（远程后端服务）开发思想

前端、服务端同学都能快速入门

愿景

所有开发者都能学会桌面软件研发

简单

只需懂 JavaScript

开源

gitee：https://gitee.com/wallace5303/electron-egg 2200+

github：https://github.com/wallace5303/electron-egg 500+

关注公众号

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

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

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

腾讯 APIJSON 生态项目 SQLAuto 1.1.0 更新内容：

• 新增回归测试完继续深度测试等功能；
• 新增 Headless 模式 Node 环境无 UI 测试；
• 自动生成文档：解决不显示数据字典，解决名称不是原始的表名；

具体见 Release 发布版本。

SQLAuto-智能零代码数据库功能测试工具

☔ 智能零代码测试 SQL、任意增删改查、任意 SQL 模板变量、一键批量生成

本项目前端工具是基于 APIAuto 改造的纯静态 SPA 网页，下载源码解压直接浏览器打开。

后端需要部署 APIJSON-Demo 5.2.5+ 的 APIJSONBoot-MultiDataSource。

感谢开源

• jsonon
• editor.md
• vue.js

技术交流

关于作者

如果有什么问题或建议可以 提ISSUE，交流技术，分享经验。
如果你解决了某些bug，或者新增了一些功能，欢迎 贡献代码，感激不尽。

其它项目

APIJSON 腾讯零代码、全功能、强安全 ORM 库 🏆 后端接口和文档零代码，前端(客户端) 定制返回 JSON 的数据和结构

APIAuto 敏捷开发最强大易用的 HTTP 接口工具，机器学习零代码测试、生成代码与静态检查、生成文档与光标悬浮注释

UnitAuto 机器学习单测试平台，零代码、全方位、自动化 测试 方法/函数 的正确性和可用性

APIJSON.NET C# 版 APIJSON ，支持 MySQL, PostgreSQL, SQL Server, Oracle, SQLite

apijson-go Go 版 APIJSON ，支持单表查询、数组查询、多表一对一关联查询、多表一对多关联查询 等

apijson-hyperf PHP 版 APIJSON，基于 Hyperf 支持 MySQL

apijson-node Node.ts 版 APIJSON，提供 nestjs 和 typeorm 的 Demo，由字节跳动工程师开发

uliweb-apijson Python 版 APIJSON，支持 MySQL, PostgreSQL, SQL Server, Oracle, SQLite 等

apijson-practice BAT 技术专家开源的 APIJSON 参数校验注解 Library 及相关 Demo

Android-ZBLibrary Android MVP 快速开发框架，Demo 全面，注释详细，使用简单，代码严谨

我要赞赏

创作不易，右上角点 ⭐Star 支持下本项目吧，谢谢 ^_^
https://github.com/TommyLemon/SQLAuto

OMP平台(Operation Management Platform)是云智慧公司自主设计、研发的轻量级、聚合型、智能运维管理平台。是一款为用户提供便捷运维能力和业务管理的综合平台。具备纳管、部署、监控、巡检、自愈、备份、恢复等功能。在提高运维人员等工作效率的同时，也提升了业务的连续性和安全性。

更新内容：

[新增] 主题配置 – 菜单配置 – 菜单分组。
[新增] 主题配置 – 菜单配置 – 侧边分栏 与 顶部分栏 选项。
[新增] 菜单数据 type 属性，model 与 blank 可选值, 菜单项支持弹层打开外部链接。
[新增] 工作空间 – 控制台新增选项卡案例。
[新增] 选项卡 工具栏, 增加关闭当前，关闭全部，关闭其他。
[修复] 选项卡切换，导致页面状态重置的问题。
[修复] 选项卡 在 router 刷新后不存在的问题。
[修复] echarts 图表在切换标签后，变为空白。
[修复] 顶部菜单前景色为白色的问题。
[优化] 移动端布局兼容，更好的适配 768px 下的设备。
[优化] 顶部菜单项 hover 效果。
[集成] npm run build 打包分析, 支持报告打印。
[升级] layui-vue 1.7.10。

详细内容：

本次的重要更新，我们新增了分栏布局，并且支持在顶部 或 侧边显示。

你可以通过主题配置页面来切换两种不同的分栏布局，或直接关闭分栏模式使用传统的布局方式。

更多详情：https://gitee.com/layui-vue/layui-vue-admin

MrDoc 觅思文档是基于 Python 语言的 Django 框架开发并开源的在线文档系统。

其功能类似于国内的语雀平台、看云平台、为知笔记和飞书文档，国外的 GitBook 平台。

如果你在寻找可私有化部署的在线文档系统，那么 MrDoc 觅思文档可以说是不二之选。

MrDoc 以「文档」作为系统的主要承载形式，支持用 Markdown 和富文本进行「普通文档」的写作，支持类似 Excel 的在线表格用来「表格文档」的记录。

同时以书籍形式的结构化文集作为文档的呈现形式，非常适合个人和小型团队作为私有化的文档、笔记和知识管理工具。

全平台多终端支持

浏览器扩展

MrDoc 通过官方浏览器扩展 ——MrDoc 速记（支持 Chromium 系列浏览器和火狐浏览器）（项目地址为：https://gitee.com/zmister/mrdoc-webclipper）和接入「简悦」扩展，实现了网站内容剪藏，可以化身成为互联网内容收藏神器。

桌面客户端

MrDoc 还提供了基于 Electron 开发的桌面客户端，跨平台支持 Windows、Linux 和 macOS。

移动端 APP

通过移动端 APP，你可以在手机上快速新建文集、文档，修改文档、上传图片、阅读文档……

总而言之，你所写的一切都在你自己的掌控之中，不用担心哪家的产品突然宣布停止服务，不用担心收藏在互联网平台上的内容被各种原因清理掉。

根据 MrDoc 交流 群里的使用反馈，很多朋友用来做个人私有云笔记、团队知识库、公司产品手册、组织规章制度和办事指南等

更新内容

在 2022 年 11 月 30 日，MrDoc 归版发布了 0.8.5 版本，本次版本发布带来了一大波的更新、优化和 Bug 修复，详细的更新内容如下：

• [新增]邮箱配置信息测试发送功能；
• [新增]禁用更新检测功能及其配置项；
• [修复]修复部分设备importlib-metadata版本变动导致项目运行失败的问题；
• [优化]取消iframe白名单相关配置及限制；
• [优化]增加card类型代码块颜色位；
• [优化]合并PR#153；

MrDoc 官网：

https://mrdoc.pro

MrDoc 文档站点：

https://doc.mrdoc.pro

开源仓库地址：

https://gitee.com/zmister/MrDoc

https://github.com/zmister2016/MrDoc

浏览器扩展：

https://gitee.com/zmister/mrdoc-webclipper

桌面客户端：

https://gitee.com/zmister/mrdoc-desktop-release

移动 APP：

https://gitee.com/zmister/mrdoc-app-release

示例站点：

http://mrdoc.zmister.com/ 

测试账号：test1 测试密码：

Spring Framework 6.0 已于11月份上旬正式发布 GA 版本。Spring Boot 3.0 也于11月25日正式发布 GA 版本。那么 Spring Cloud 2022 它还远吗？

前言

Java 8 目前是国内主流生产环境 Java 版本之一。虽然近几年陆续发布了 Java 11、Java 17 官方 LTS 版本，但是 “你发任你发，我用Java8” 的声音反应了大部分开发者的心声。不过 Java 17 版本在性能上做了大量的优化特别是 ZGC 的发布，促进了国内不少企业升级到 Java 17。

Spring 在 Java 语言的作用不言而喻，Spring Framework 5.0 发布已至今五年，是时候需要一个大的版本来革新技术栈了。借着 Java 17 的东风我们认为

“Java 17 + Spring Framework 6.0 + Spring Boot 3.0 + Spring Cloud 2022”

组合一定会在不久的将来被大家所接受，成为主流技术栈。当然任何新技术大规模被认可、落地都会有一定的滞后性，技术的发展 “稳”字当头。

Spring Cloud Tencent 是基于腾讯开源的一站式微服务平台北极星（集服务注册发现、配置中心、服务限流熔断、服务路由于一身）实现的 Spring Cloud 微服务解决方案套件。真正做到 “All In One”、 开箱即用，极大的降低企业的微服务实践门槛。

无论北极星还是 Spring Cloud Tencent 当前都在积极的修复 Bug、完善用户体验、迭代新功能。所以 Spring Cloud Tencent 也第一时间适配了 Spring Cloud 2022 版本。此篇文章详细讲述了 Spring Cloud Tencent 从 2021 版本升级到 2022 版本的改动点，为尝鲜 2022 版本的广大开发者提供一些参考。

一、升级过程

1.1 升级安装 JDK 17

Oracle 官网下载 JDK 17 并安装。安装之后，本地修改 JAVA_HOME 环境变量，如下以我的 Mac 为例：

安装好 JDK 17 之后，同时需要在 Idea 里设置项目的编译和运行环境为 SDK 17。

1.2 升级依赖版本

Spring Cloud Tencent 项目引用的 Parent Pom 是 spring-cloud-build，所以需要升级到最新版本。

可以看到 Spring-cloud-build 4.0.0-RC2 版本里定义的 Java 和 Spring Boot 版本已是最新的 Java 17 和 Spring Boot 3.0

普通项目一般不需要继承 spring-cloud-build ，而是通过 bom 的方式引入 Spring 全家桶。如果你的项目里定义了 Java、Spring Framework、Spring Boot、Spring Cloud 版本则需要同时升级。如下所示：

注意：Spring 非 GA 版本会先发布到 Spring 自己的 Maven 仓库，而不会发布到中央仓库。所以如果拉不到包 ，则需要在项目根 Pom 或者本地 ~/.m2/settings.xml 里配置 Spring Maven 仓库。

在升级过程中，大概率会出现包冲突的情况，例如 SCT 在升级过程中发现日志依赖有问题导致 example 启动失败。最后排查到原因：SCT 自己定义了 logback版本为 1.2.11，但是升级 Spring Boot 3.0 里传递依赖的版本为 1.4.5，所以导致版本冲突。最后解决方案就是把 SCT 定义的版本去掉，只用传递依赖的版本。

Tips：解决版本冲突大概率会占用比较多的时间，升级过程需要有耐心 😭

1.3 修改不兼容代码

javax 包替换为 jakarta 包

这是Java17 最大变更点之一，代码所有 import javax 都要替换为 jakarta。编译不通过的地方直接通过 Idea 自动导入的方式变更即可。

spring-web 6.0 不兼容升级

SCT 在升级过程中发现 spring-web 包下有些 API 不兼容，例如 ClientHttpResponse.getStatusCode() 老版本返回 HttpStatus，新版本返回的是 HttpStatusCode，改动量很小。

AutoConfiguration 自动装配方式变更

在 Spring Boot 3.0 以前的版本，通过在 META-INF/spring.factories 文件中定义需要自动装配类，Spring Boot 在启动过程中就会执行装配 Bean，如下所示：

但是在 Spring Boot 3.0 中，则是通过在

META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports

文件定义需要自动装配的类。所以迁移过程就是把org.springframework.boot.autoconfigure.EnableAutoConfiguration 下配置的类都放到新的文件中。

这里需要注意的是原来在 spring.factories 可以定义多种类型的自动装配例如：

1. org.springframework.boot.autoconfigure.EnableAutoConfiguration

2. org.springframework.cloud.bootstrap.BootstrapConfiguration

3. org.springframework.context.ApplicationListener

4. … …

只需要把 org.springframework.boot.autoconfigure.EnableAutoConfiguration 部分迁移到 org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件，其它部分还是放在 spring.factories 中无需迁移。

至此 SCT 2022 升级适配工作即已完成，可以看出升级工作量并不大。

1.4 升级总结

SCT 属于比较底层的基础框架组件，依赖的第三方库少，所以整体适配工作量较少。如果您的应用是上层业务应用依赖了大量的组件，例如： spring-security、spring-stream等。那升级的成本也会高很多。

下面是 github 网友 @herodotus-cloud 总结的升级关键点：

1. 更换 JDK 17 后，少部分第三方依赖包版本选择和控制问题

2. 新依赖包过时代码替换。大多数没问题，就怕遇到像 spring security 6 用法的变化

3. starter 自动配置注册格式不同导致的，大多数第三方依赖都倒在这里

4. 最怕的就是核心机制的变化，比如说反射。好像一些反射在 JDK 17 会有问题

5. 最大的问题就是基础设置组件升级不同步或者缓慢问题，比如依赖的某个 SDK 没有升级 SDK 17，如果传递依赖了就会导致编译问题。

6. 如果还要考虑向下的兼容性，怕就难了

Spring 官方建议先升级到 Spring Boot 2.7 小版本，然后再升级到 Spring Boot 3.0 版本。通过小步升级的方式，可以更加的平滑。

二、尝鲜使用 Spring Cloud Tencent 2022.0 版本

Spring Cloud Tencent 1.8.1-2022.0.0-RC2 版本已发布。通过引入 SCT BOM 的方式即可引入，如下所示：

在此解释一下 SCT 的版本号规则，版本号分为两段：

${SCT 版本}-${对应的 Spring Cloud 版本}

SCT 版本号在各个 Spring Cloud 版本之间对齐，例如 1.8.1-Hoxton.SR12 和 1.8.1-2022.0.0-RC2 ，SCT 版本号都是 1.8.1，功能完全对齐，只是引用的 Spring Cloud 不同。1.8.1-Hoxton.SR12 对应的是 Spring Cloud Hoxton.SR12 版本，而 1.8.1-2022.0.0-RC2 对应的是2022.0.0-RC2 版本。版本号中引入 Spring Cloud 版本为了一眼就能识别 Spring Cloud 版本对应关系。开发者优先选择跟自己版本一致的 Spring Cloud 版本，再选择最新的 SCT 版本。

使用 SCT 各个子模块的功能，请参考 SCT Github Wiki 文档。

三、 呼吁

第三方基础组件的升级节奏会直接影响上层应用的升级，在此也呼吁第三方基础组件的维护者能够尽快跟进适配。为广大愿意尝鲜的开发者和企业提供便利。

四、欢迎共建

如果您对微服务、Spring Cloud 技术感兴趣，欢迎加入我们。您的一个建议、Issue、Pull Request 甚至只是一个小小的 Star 都是对 Spring Cloud Tencent 社区极大的支持。

SCT Github 地址：https://github.com/Tencent/spring-cloud-tencent

北极星官网：https://polarismesh.cn/

Forest + IDEA = 双倍快乐! ForestX 隆重登场

Forest 是一款声明式的 Java 开源 HTTP 框架，相比它的前辈 Httpclient 和 OkHttp 更简明易懂、也更容易维护

废话不多说，先让我们康康用它写出来的代码长什么样子

轻轻松松完成了从高德地图获取经纬度所在的地理信息的 Rest API 接口定义，之后只要调用这个 Java 方法即可自动发送 HTTP 请求，并接受响应数据，然后转换成 Map 类型对象再交到你手上

这样做确实比以前手动组装 OkHttp 的 Client 对象、 OkRequest 对象好上很多倍，就算要调用的 HTTP 接口很多、结构再复杂，也不用怕了

但当一个项目中有成千上万个 HTTP 请求要调用，接口的管理和维护成本也会上升到一个吃力的高度

比如哪个接口对应哪个网站平台哪个URL往往不能一眼看出、项目中散落的接口具体有哪些也没法一下子就知道

另一个问题是 Forest 中的模板字符串中的占位符可以方便的引用配置文件中定义的变量已经通过标签定义的参数，但语法高亮和一个表达式语言应用的基本支持（如代码补全和提示）

这在代码少的时候不算问题，代码接口躲到一定程度，字符串模板中的变量引用写错的概率就大大增加，因为配置也多了，就容易搞不清楚谁再调用谁

这个时候就有请我们今天的主角 ForestX 登场啦~~

专为 Forest 量身定做的 IDEA 插件

ForestX 是一款专为 Forest 提供支持的 IDEA 插件

它能大幅提高您使用 Forest 框架时的开发体验

仓库地址: https://gitee.com/CHMing7/ForestX

接下来，就让我们康康它有哪些功能:

侧边导航工具栏

右边的logo小鸟图标，可打开的导航工具栏，它会把项目中定义的 Forest 接口都罗列在一起，方便管理

• 接口列表分三个层次：最顶层的项目(目录)、Forest 接口(小鸟图标)、请求方法
• 在 Forest 接口列表中，方法名左侧的图标代表了该请求的类型(/)
• 方法名/接口的右侧，则是用灰色字体展示的 URL 路径 （一般不是全路径，而是定义在方法上的路径）

代码补全

1. 根据配置文件中下定义的全局变量来补全代码

2. 根据YAML配置文件中定义的YAML配置项来补全代码

3. 根据请求方法的参数定义来补全代码

4. 根据注解定义的方法来补全代码

5. 在编程式的代码中，也可出现代码补全的智能提示

不过目前仅对 、 等请求方法开放次功能

代码跳转

按住键盘键，将鼠标移动到 Forest 模板表达式中的标识符上(比如变量名)，并悬停一小段时间，就会跳出该标识符所引用的配置变量或Java属性的简短信息

此时鼠标左键，即可跳转到该标识符所引用的变量/配置的定义代码

结语

程序猿的工作是创造工具，而工具亦可以用来服务程序猿，这是一种正向循环，也是一次次迭代的缩影，正是在一次次的迭代中，程序猿们不断地创造出很好、更完善、更可能改变世界的工具

而 ForestX 的迭代才刚刚开始！

漏洞描述

exporter-toolkit 是 Prometheus 的导出工具包，

exporter-toolkit 为减少使用 bcrypt 哈希验证用户身份所需要的时间和资源，从而采用缓存 cacheKey = hex(username + hashed password + input password）验证用户身份信息。为了避免侧信道攻击，对于缓存中不存在的用户（validUser）采用固定 hashed password 进行缓存验证。

攻击者在已知散列密码（hashed password）的情况下可通过毒化缓存进行身份绕过：

1. 发动请求毒化缓存：

username = username+hashed password

password = “fakepassword”

2. 身份绕过：

username = username

password = bcrypt(fakepassword)+”fakepassword”

Prometheus 是一个开源的系统和服务监控系统，目前在 GitHub 具有 45.7k stars，Prometheus 在 2.37.4 和 2.40.4 之前的版本中受此漏洞影响。

影响范围

github.com/prometheus/exporter-toolkit@(-∞, 0.7.2)

github.com/prometheus/exporter-toolkit@[0.8.0, 0.8.2)

修复方案

升级github.com/prometheus/exporter-toolkit到 0.7.2 或 0.8.2 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-65539

https://github.com/prometheus/exporter-toolkit/security/advisories/GHSA-7rg2-cxvp-9p7p

https://github.com/prometheus/exporter-toolkit/commit/5b1eab34484dddbce736cd119d863e4ff5

https://nvd.nist.gov/vuln/detail/CVE-2022-46146

情报订阅

OSCS(开源软件供应链安全社区)通过最快、最全的方式，发布开源项目最新的安全风险动态，包括开源组件安全漏洞、事件等信息。同时提供漏洞、投毒情报的免费订阅服务，社区用户可通过配置飞书、钉钉、企业微信机器人，及时获得一手情报信息推送：

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

2022年11月，经openKylin社区技术委员会审议通过，Phytium内核补丁特别兴趣小组—PhytiumKernelPatch SIG正式成立。

PhytiumKernelPatch SIG由openKylin社区共建单位飞腾信息技术有限公司发起成立，在openKylin社区中负责为搭载飞腾系列处理器的服务器及桌面平台提供支持飞腾特性的内核补丁，包括但不限于双路特性支持补丁、Kdump功能修复补丁、中断堆积修复补丁、SMMU特性支持补丁以及系统驱动适配补丁等。

01

SIG目标

• 维护已提交至社区的飞腾内核补丁代码；
• 完善飞腾高性能服务器芯片内核适配并同步最新补丁代码；

• 提交并维护飞腾高效能桌面芯片内核补丁代码。

02

SIG职责

1、面向飞腾高性能服务器芯片的Linux内核适配

提交并维护面向飞腾高性能服务器芯片的Linux内核功能适配及修复补丁，为搭载飞腾腾云S2500、FT-2000+/64等处理器的服务器提供高效、可靠的运行环境及完善、健全的功能支持。

2、面向飞腾高效能桌面芯片的Linux内核适配

提交并维护面向飞腾高效能桌面芯片的Linux内核功能适配及修复补丁，为搭载飞腾腾锐D2000、FT-2000/4等处理器的桌面端提供系统驱动的功能适配与性能优化。

03

欢迎加入SIG

PhytiumKernelPatch SIG负责openKylin社区中面向飞腾服务器及桌面平台的操作系统内核相关的功能适配及性能优化，为拓展openKylin的操作系统内核生态提供支撑，欢迎各位小伙伴们的加入！

• 邮件列表：

• phytiumkernelpatch@lists.openkylin.top

• SIG主页：
• https://gitee.com/openkylin/community/tree/master/sig/PhytiumKernelPatch

openKylin（开放麒麟）社区旨在以“共创”为核心，在开源、自愿、平等、协作的基础上，通过开源、开放的方式与企业构建合作伙伴生态体系，共同打造桌面操作系统顶级社区，推动Linux开源技术及其软硬件生态繁荣发展。

社区首批理事成员单位包括麒麟软件、普华基础软件、中科方德、麒麟信安、凝思软件、一铭软件、中兴新支点、心科技、中国电科32所、技德系统、北京麟卓、先进操作系统创新中心等13家产业同仁和行业机构。

审核：openKylin

“大数据时代”的概念最早由著名咨询公司麦肯锡提出。麦肯锡表示：”数据已渗透到今天的每个行业和业务功能领域，并已成为重要的生产要素。” 数据在精巧的算法中被挖掘，数据分析变得至关重要，大家开始达成一个共识：”数据计算，能够找到新发现。”

博思艾伦咨询公司的合伙人 Josh Suillivan 在其著作《数字时代的企业进化》一书中提到，其团队研究了数百个组织，提炼出构成未来成功组织模型的要素，这类成功组织被称为”数据公司”。而进化成”数字公司”的关键，是”组织是由数据驱动的”。 在大数据时代，企业不再随便删除数据，而是希望把数据存储起来用于分析。数据库也成为了企业基础架构必不可少的一部分。

什么是MPP？

MPP（Massive Parallel Processing，大规模并行处理），一直被誉为当今数据库的主流架构，被广泛用于众多数据库产品中，包括Greenplum、Teradata、Vertica等。MPP数据库是针对分析工作负载进行了优化的数据库，以满足用户聚合和处理大型数据集的需求。 MPP分析型数据库将任务并行的分布到多个服务器和节点上，并在完成计算后，将结果返回并汇总，从而完成对海量数据的分析处理。

MPP数据库的优势

MPP数据库集群有可扩展性、高可用性、高性能等众多优势。MPP数据库的诞生解决了单个SQL数据库无法存放海量数据，很难在一台物理机器上完成分析需求的难题。

海量数据处理能力

MPP架构的数据库以PC服务器为单位，通过如下图所示的集群方式来扩展存储和计算。假设一个宽表有3亿条记录，MPP数据库会尝试在每台PC服务器的硬盘上分布1亿条记录。数据计算时，所有机器同时并行计算，理论上最高可以把计算时间降低到单机部署的1/n（n为机器数量），节省了海量数据的处理时间。

对SQL的完美兼容

大部分传统MPP数据库均实现了对SQL的完美兼容，包括ANSI SQL 2008标准，以及 SQL 2003 OLAP 扩展。对SQL的全面支持使得MPP数据库可以无缝集成业内常见的提取/转换/加载（ETL）和BI（商业智能）工具，完全支持和认证标准数据库接口。企业只需安排少量的集成工作，就可以使用现有的使用标准 SQL 结构和接口的分析工具让应用在 数据库上运行，从而避免了企业受制于供应商，帮助企业在抑制业务风险的同时推动创新。

计算的高度并行化

MPP架构给数据库的高并发性带来了极大的弹性。架构赋予数据库数据和查询的自动并行化能力，数据可以做到自动在数据库的所有节点上分区，并以高度协调的方式使用所有节点来规划和执行查询。企业可以根据自身的并发需求扩展集群，达到所需的并发需求。

水平扩展能力

MPP数据库具有良好的水平扩展能力，企业可以根据业务需求，通过增加服务器，用更多的节点支撑更大的分析需求。

传统MPP数据库的瓶颈

虽然MPP数据库有众多优势，因而成为众多分析型数据库产品的主流架构。然而，传统MPP数据库也有众多瓶颈和限制。

存算耦合

传统数据仓库的计算和存储是紧密耦合的，计算资源和存储资源按某一比例强绑定，因此用户在扩容时，必须同时扩容计算资源和存储资源，在扩容、运维、迁移上都存在一定的挑战。企业业务发展的不确定性，当企业遇到负载高峰时刻，传统数据仓库无法及时扩资源，可能会导致大数据系统无法及时分析业务数据，错失了充分挖掘数据价值所带来的商业机会。

业务受限

传统的 MPP 数据库虽然实现了水平扩展，但是由于存算耦合，水平扩展流程复杂且缓慢。随着用户的数据规模增长，每次扩缩容进行增加节点的操作时，大量的I/O请求会影响业务的处理速度，对业务的持续性会造成一定的影响。当用户负载突然增大时，无法迅速提高算力以响应业务变化，在负载降低时也无法收缩以节约成本。存算的紧密耦合，导致用户无法根据实际需求申请资源，动态扩展，导致用户的业务受限。

成本高昂

传统数据库价格高昂的软硬件导致巨大的前期投入。随着存储和工作负载需求的日益增长，面临数据库的扩容和升级时，由于传统MPP数据库架构存储和计算的紧密耦合，往往需要企业花费巨大的运维和时间成本，且操作繁琐。

木桶效应 

传统MPP数据库架构存在”木桶效应”，数据库整体执行速度取决于最”短板”单机（Straggler）的性能。单机故障会”拖垮”整个数据库的性能，导致查询速度变慢。 因此传统的MPP架构往往要求新增的PC机和之前的PC机是一样的老配置，不然任何一个集群的”短板”就会影响整个数据库的性能，也就说摩尔定理不管多厉害，MPP集群拿老机器的存储和性能”一刀切”而取低值。

数据孤岛 

随着业务的发展，数据量的增加，和信息化建设的需求，企业会为不同部门建设相应的业务信息化系统。然而MPP的水平”扩展“能力和事实上的”静态“项目实施是矛盾的。“扩展”理论上是和时间关联的一个概念，而基于PC机的MPP设计并不是”时间的朋友“。由于前面提到的存算耦合和”木桶效应”，企业在购买新机器的时候，往往会选择”另起炉灶”，新建一个集群，从而造成”数据孤岛”，严重阻碍了企业实现大数据目标。

全新的eMPP：传统MPP数据库的进阶版

面对传统MPP数据库的短板，OpenPie 团队打造的云原生数据库 PieCloudDB，创造了全新的eMPP分布式架构，构建以云原生、分析型分布式数据库为引擎数据计算平台。

什么是eMPP？

eMPP由OpenPie团队打造，全称是 Elastic Massive Parallel Processing（Elastic MPP，弹性大规模并行计算）。

eMPP超越传统MPP架构，更符合云时代的需求。云平台在信息技术发展过程中具有划时代意义，它带给用户的不仅仅是快捷和便利，更是极大的灵活性和可配置性。用户可以自行定义云主机的配置，定义云主机的数量等，并且可以便捷的增加和删除云主机。一句话来说，云平台给企业应用架构带来了极大的弹性。

MPP架构和云平台相结合，就诞生了eMPP。为了适应云平台的弹性，新的eMPP架构实现了云上存储计算分离。也就是说，计算资源和存储资源可以在云上实现独立的进行水平扩展。

eMPP的优势

存算分离赋予 eMPP 数据库 ”真正” 的弹性。eMPP架构继承了前文中提到的MPP数据库所有优势，并从根本上规避了传统MPP数据库的缺陷，拥有众多优势。

• 
  

  弹性扩展

基于云计算平台、存算分离的eMPP（弹性大规模并行计算）架构赋予数据库多维度、智能弹性扩展能力，让用户能够根据业务需求进行横向或纵向的弹性伸缩。

存储侧支持标准对象存储，可以充分利用云计算平台的优势，让对象存储接近无限的容量，避免了企业对集群进行扩容时，因计算资源和存储资源的绑定而造成的资源浪费，可单独进行计算或者存储资源的扩展，存储扩容性价比高。

计算侧在设计上充分考虑无状态实现，计算节点可以充分利用云平台海量的计算节点池，可以按需扩容和缩容。企业可以灵活考虑业务和数据量的变化，动态调整 数据库集群中计算节点的数量，用最适合的资源量来满足其业务需求。

• 
  

  灵活敏捷

eMPP架构计算和存储分离，避免了资源的浪费。企业可根据对资源的需求，灵活的以低成本和高效的方式，单独地进行存储或计算资源的弹性扩展，提高了资源的利用率，节省空间成本和能耗开销。

• 
  

  降本增效

eMPP架构带来的动态扩展能力，企业可根据自己对资源的需求进行扩展，避免了资源的浪费，相比于传统数据库，具有更高的性价比。

• 
  

  高可用性

eMPP架构中，计算节点不存储用户数据，保证了计算节点的无状态性。无状态的计算节点启动和停止非常容易，企业可以根据自身的需求启动足够的冗余计算节点保证eMPP数据库的高可用性。在 eMPP 数据库 中，用户数据存储在云计算平台的对象存储中，充分利用云存储的优势保障用户数据高可用性。

PieCloudDB Database：基于云计算的全新 eMPP 架构

PieCloudDB，采用基于云计算的全新 eMPP（Elastic MPP）弹性并行计算架构，集成了MPP数据库的众多优点，并完美解决了基于PC的传统MPP数据库的缺陷。计算和存储分离。存储和计算作为两个独立变量，可以在云端进行独立的弹性伸缩，避免了资源的浪费。企业可根据业务对资源的需求，灵活的以低成本和高效的方式，单独地进行存储或计算资源的弹性扩展，提高了资源的利用率，节省空间成本和能耗开销。

数据-计算-数据分离的三层独立架构让 PieCloudDB 实现了将数据集中存储，而数据独立存储。企业可以像管理商品数据一样来管理自己的数据产品的数据。企业可以将所有数据在云中存储，为已有和未来的应用真正实现数据共享。

一、Kafka存在哪些方面的优势

1. 多生产者

可以无缝地支持多个生产者，不管客户端在使用单个主题还是多个主题。

2. 多消费者

支持多个消费者从一个单独的消息流上读取数据，而且消费者之间互不影响。

3. 基于磁盘的数据存储

支持消费者非实时地读取消息，由于消息被提交到磁盘，根据设置的规则进行保存。当消费者发生异常时候，意外离线，由于有持久化的数据保证，可以实现联机后从上次中断的地方继续处理消息。

4. 伸缩性

用户在开发阶段可以先试用单个broker，再扩展到包含3个broker的小型开发集群，然后随着数据量不断增长，部署到生产环境的集群可能包含上百个broker。

5. 高性能

Kafka可以轻松处理巨大的消息流，在处理大量数据的同事，它还能保证亚秒级的消息延迟。

二、Kafka常见的使用场景

1. 消息

kafka更好的替换传统的消息系统，消息系统被用于各种场景（解耦数据生产者，缓存未处理的消息等），与大多数消息系统比较，kafka有更好的吞吐量，内置分区，副本和故障转移，这有利于处理大规模的消息。

根据我们的经验，消息往往用于较低的吞吐量，但需要低的端到端延迟，并需要提供强大的耐用性的保证。

在这一领域的kafka比得上传统的消息系统，如ActiveMQ或RabbitMQ等。

2. 网站活动追踪

kafka原本的使用场景是用户的活动追踪，网站的活动（网页游览，搜索或其他用户的操作信息）发布到不同的话题中心，这些消息可实时处理，实时监测，也可加载到Hadoop或离线处理数据仓库。

3. 指标

kafka也常常用于监测数据。分布式应用程序生成的统计数据集中聚合。

4. 日志聚合

许多人使用Kafka作为日志聚合解决方案的替代品。日志聚合通常从服务器中收集物理日志文件，并将它们放在中央位置（可能是文件服务器或HDFS）进行处理。Kafka抽象出文件的细节，并将日志或事件数据更清晰地抽象为消息流。这允许更低延迟的处理并更容易支持多个数据源和分布式数据消费。

5. 流处理

kafka中消息处理一般包含多个阶段。其中原始输入数据是从kafka主题消费的，然后汇总，丰富，或者以其他的方式处理转化为新主题，例如，一个推荐新闻文章，文章内容可能从“articles”主题获取；然后进一步处理内容，得到一个处理后的新内容，最后推荐给用户。这种处理是基于单个主题的实时数据流。从0.10.0.0开始，轻量，但功能强大的流处理，就可以这样进行数据处理了。

除了Kafka Streams，还有Apache Storm和Apache Samza可选择。

6. 事件采集

事件采集是一种应用程序的设计风格，其中状态的变化根据时间的顺序记录下来，kafka支持这种非常大的存储日志数据的场景。

7. 提交日志

kafka可以作为一种分布式的外部日志，可帮助节点之间复制数据，并作为失败的节点来恢复数据重新同步，kafka的日志压缩功能很好的支持这种用法，这种用法类似于Apacha BookKeeper项目。

三、Kafka架构深度剖析

1. Kafka数据处理步骤

1.1 Producer产生消息，发送到Broker中

1.2 Leader状态的Broker接收消息，写入到相应topic中

1.3 Leader状态的Broker接收完毕以后，传给Follow状态的Broker作为副本备份

1.4 Consumer消费Broker中的消息

2. Kafka 核心组件

2.1 Producer：消息生产者，产生的消息将会被发送到某个topic

2.2 Consumer：消息消费者，消费的消息内容来自某个topic

2.3 Topic：消息根据topic进行归类，topic其本质是一个目录，即将同一主题消息归类到同一个目录

2.4 Broker：每一个kafka实例（或者说每台kafka服务器节点）就是一个broker，一个broker可以有多个topic

2.5 Zookeeper： Zookeeper集群不属于kafka内的组件，但kafka依赖 Zookeeper集群保存meta信息，所以在此做声明其重要性。

3. broker和集群

一个独立的Kafka服务器称为broker，broker接收来自生产者的消息，为消息设置偏移量，并提交消息到磁盘保存。broker为消费者提供服务，对读取分区的请求作出响应，返回已经提交到磁盘上的消息。根据特定的硬件及其性能特征，单个broker可以轻松处理数千个分区以及每秒百万级的消息量。

broker是集群的组成部分。每个集群都有一个broker同时充当了集群控制器的角色（自动从集群的活跃成员中选举出来）。控制器负责管理工作，包括将分区分配给broker和监控broker。在集群中，一个分区从属于一个broker，该broker被称为分区的首领。一个分区可以分配多个broker，这个时候会发生分区复制。这种复制机制为分区提供了消息冗余，如果一个broker失效，其他broker可以接管领导权。不过，相关的消费者和生产者都要重新连接到新的首领。

4. Consumer与topic关系

kafka只支持Topic

• 每个group中可以有多个consumer，每个consumer属于一个consumer group；通常情况下，一个group中会包含多个consumer，这样不仅可以提高topic中消息的并发消费能力，而且还能提高”故障容错”性，如果group中的某个consumer失效那么其消费的partitions将会由其它consumer自动接管。

• 对于Topic中的一条特定的消息，只会被订阅此Topic的每个group中的其中一个consumer消费，此消息不会发送给一个group的多个consumer；那么一个group中所有的consumer将会交错的消费整个Topic，每个group中consumer消息消费互相独立，我们可以认为一个group是一个”订阅”者。

• 在kafka中,一个partition中的消息只会被group中的一个consumer消费(同一时刻)； 一个Topic中的每个partions，只会被一个”订阅者”中的一个consumer消费，不过一个consumer可以同时消费多个partitions中的消息。

• kafka的设计原理决定,对于一个topic，同一个group中不能有多于partitions个数的consumer同时消费，否则将意味着某些consumer将无法得到消息，而处于空闲状态。

kafka只能保证一个partition中的消息被某个consumer消费时是顺序的；事实上，从Topic角度来说,当有多个partitions时,消息仍不是全局有序的。

5. Kafka消息的分发

• Producer客户端负责消息的分发

• kafka集群中的任何一个broker都可以向producer提供metadata信息,这些metadata中包含*”集群中存活的servers列表”、“partitions leader列表”*等信息；

• 当producer获取到metadata信息之后, producer将会和Topic下所有partition leader保持socket连接；

• 消息由producer直接通过socket发送到broker，中间不会经过任何”路由层”。事实上，消息被路由到哪个partition上由producer客户端决定，比如可以采用”random””key-hash””轮询”等。

• *如果一个topic中有多个partitions,那么在producer端实现”消息均衡分发”*是必要的。

• 在producer端的配置文件中,开发者可以指定partition路由的方式。

• Producer消息发送的应答机制

设置发送数据是否需要服务端的反馈,有三个值0,1,-1

0: producer不会等待broker发送ack

1: 当leader接收到消息之后发送ack

2: 当所有的follower都同步消息成功后发送ack

request.required.acks=0

6. Consumer的负载均衡

当一个group中,有consumer加入或者离开时,会触发partitions均衡.均衡的最终目的,是提升topic的并发消费能力，步骤如下：

1. 假如topic1,具有如下partitions: P0,P1,P2,P3

2. 加入group A 中,有如下consumer: C0,C1

3. 首先根据partition索引号对partitions排序: P0,P1,P2,P3

4. 根据consumer.id排序: C0,C1

5. 计算倍数: M = [P0,P1,P2,P3].size / [C0,C1].size,本例值M=2(向上取整)

本文由教研团队发布。

如果本文对您有帮助，欢迎和；如果您有任何建议也可或，您的支持是我坚持创作的动力。

转载请注明出处！

作者：于雄雄 陈其友 | 旷视 MegEngine 架构师

背景

在 CV 领域中，卷积计算是扩充像素的感受野的有效方法，模型大多数的计算量都是卷积操作贡献的。因此在 CV 模型的推理性能优化中，最重要的一项工作是对卷积的优化。MegEngine 在长期的工业界实践和反馈的基础上总结得出卷积优化的基本方法有：

• 直接卷积计算优化

该方法的计算过程为逐通道进行卷积滑窗计算并累加，该优化方法对卷积的参数敏感，为了达到最优的性能，会根据各个卷积参数分别进行 kernel 优化，通用性弱，但是在 Depthwise 的卷积中却是最高效的方法。

• FFT 卷积计算优化

根据卷积的性质，利用傅立叶变换可以将卷积转换为频域上的乘法，在频域上的计算对应乘法，再使用傅立叶变换逆变换，就可以得到卷积对应的计算结果。该方法使用高性能的傅立叶变换算法，如 FFT，可以实现卷积计算的优化，算法性能完全取决于傅立叶变换的性能以及相应卷积参数。

• Im2col+matmul 卷积计算优化

由于卷积计算中有大量的乘加运算，和矩阵乘具有很多相似的特点，因此该方法使用 Im2col 的操作将卷积运算转化为矩阵运算，最后调用高性能的 Matmul 进行计算。该方法适应性强，支持各种卷积参数的优化，在通道数稍大的卷积中性能基本与 Matmul 持平，并且可以与其他优化方法形成互补。

• Winograd 卷积计算优化

Winograd 方法是按照 Winograd 算法的原理将卷积运行进行转变，达到减少卷积运算中乘法的计算总量。其主要是通过将卷积中的乘法使用加法来替换，并把一部分替换出来的加法放到 weight 的提前处理中，从而达到加速卷积计算的目的。Winograd 算法的优化局限为在一些特定的常用卷积参数才支持。

由于 direct 卷积可以直接由公式得来，而 FFT 卷积对于当前业界用到的各种参数的卷积，其性能优势远没有其他优化方法明显，对于这两者本文不做详细展开。这里主要讲述 Im2col 和 Winograd 算法的实现以及优化方法。

Im2col+Matmul 优化

Im2col 算法简介

Im2col+Matmul 方法主要包括两个步骤：

• 使用 Im2col 按照卷积核的需要将输入矩阵展开一个大的矩阵，矩阵的每一列表示卷积核需要的一个输入数据。
• 使用上面转换的矩阵进行 Matmul 运算，得到的数据就是最终卷积计算的结果。

具体 Im2col 的步骤如上图所示：

1. 将输入数据按照卷积窗进行展开并存储在矩阵的列中，多个输入通道的对应的窗展开之后将拼接成最终输出 Matrix 的一列。
2. 以卷积的 stride 为步长展开后续的卷积窗并存在 Matrix 的下一列中。

完成 im2col 的操作之后会得到一个输入矩阵，卷积的 weights 也可以转换为一个矩阵，此时对 weights 的矩阵和 Im2col 的输出矩阵进行 Matmul 计算，就可以得到最终的卷积计算结果。

算法优化

上面介绍的过程是原始 Im2col+Matmul 的过程，实际处理器在执行上面的过程中性能达不到最优，以输入 Tensor 的 shape 为 (1, IC, IH, IW)，weights 的 shape 为 (OC，IC，Fh，Fw)，输出 Tensor 的 shape 为 (1, OC, OH, OW) 为例，主要原因在于：

• Im2col 的输入 Tensor 需要的 CPU 内存大小为 IC*IH*IW，而按照上面 Im2col 之后所需要的内存大小为 IC*Fh*Fw*OH*OW，当卷积的 stride=1 的时候，Im2col 之后需要的内存比之前大很多。
• 由于 Im2col 之后的数据量比较大，难以全部保存在 CPU 的 Cache 中，造成后续 Matmul 计算时，读取数据会存在 Cache Miss。
• Im2col 过程中会将输入进行 relayout 操作，而在后续 Matmul 的计算中，需要对该数据进行 Pack，Pack 操作会引入非必要的读写过程。影响算法实际性能。

优化 1：对 Im2col+Matmul 过程进行分块

上面提到在 Im2col 之后，消耗的内存会超过 CPU 的 Cache 的容量，为了使这部分数据能够保存在 Cache 中，需要对 Im2col+Matmul 的整个过程进行分块，每次 Im2col+Matmul 都只对一个分块进行操作，这样就可以解决内存占用过大，超过 CPU Cache 后造成 Cache Miss 的问题。

分块优化如上图所示：Im2col 每次只对 block_size 大小的数据进行计算，得到的 Fh*Fw*IC*block_size 的数据可以保存在 Cache 中。Im2col 得到数据后，对其直接进行 Matmul 计算，将计算得到的结果写入到输出 Tensor 对应的 block_size 处就可以得到该分块处卷积的计算结果。计算完该分块之后，依次进行下一个 block_size 的计算，直到整个输入计算完成。

结合 Matmul 的相关优化知识，在进行 Matmul A*B=C 计算时将分块 Im2col 得到的数据视作 B 矩阵，A 矩阵为卷积的权重矩阵，根据 sgemm 的分块规则，以及 cache 的性质，A 矩阵会被调度并保存在 L2 上，B 矩阵基于最内层分块的一列和 A 矩阵基于最内存分块的一行以及 C 矩阵基于最内层的部分分块会被调度保存在 L1 上，因此可以通过 L1，L2 的大小以及 A 矩阵的大小，计算出所有的分块大小。下面是分块优化性能的试验结果，可以看出分块优化能有效的减少存储使用，而且还可以提升算子的计算性能。

优化 2：融合 Im2col 和 Matmul PACK 数据操作部分

Im2col 过程中将多个窗的展开同时进行时，实际上是对内存的 copy 以及数据的 relayout 的过程，后续 Matmul 的 Pack 操作业是对数据的 copy 的 relayout，因此可以将上面两次数据的 copy 和 relayout 进行合并优化，减少该过程中对内存的读写次数。

如上图所示 Im2col+Matmul 的 algo 中实现了将 Im2col 和 Matmul 的 Pack 融合的优化，这样能够减少一次数据的读写操作。由于该 fuse 过程和卷积的参数直接相关，不同的卷积参数将对应不同的融合 kernel，所以不具备通用性。通用情况下我们会使用之前的 Im2col+Matmul 的做法，另外针对一些通用的卷积如：kernel=3×3，stride=2 等，因为参数固定，因此可以直接进行上述融合优化，利用这样的组合优化，既可以保证 im2col 算法的通用性，也可以确保大部分常见的卷积的性能。

对融合之后的卷积进行性能测试，如下所示为对应的计算吞吐：

可以看出，大多数情况下，融合之后卷积会有明显的性能提升。

Winograd 优化

Winograd 算法简介

Winograd 算法能够优化卷积计算的乘法计算量，乘法计算量的优化原理可以参考相关论文。在此就不做过多介绍了。虽然 Winograd 可以优化乘法的计算量，但是会增加加法的计算量，优化这些加法的存在可以进一步提高 Winograd 算法的性能。如可以把一部分加法计算提前到 weights 的预处理中，可以把部分加法隐藏在 Winograd 预处理中的 relayout 中。类似这样的优化可以达到减少卷积计算量的目的。

如下图所示为 Winograd 卷积算法的基本步骤，主要包括：

• 把输入的 feature map 和 weight 进行 Winograd 转换；
• 把转换后 feature map 和 weight 做批量 Matmul；
• 把矩阵乘的结果进行输出转换，得到最终结果。

在这些主要步骤中，要如何进行 Winograd 转换，如何 relayout，以及如何进行输出转换呢？下面以 Winograd F(2×2, 3×3) 为例，详细说明下这些过程。

如上图所示，上半部分是 weights 的转换，下半部分是输入 FeatureMap 的转换。其中包括了 Winograd 转换以及 relayout 的过程。

对于 weights 的转换，首先通过 Winograd 变换矩阵 G 和 GT 分别将 3×3 的 weight 转换为 4×4 的矩阵，然后将该矩阵中相同位置的点（如图中蓝色为位置 1 的点）relayout 为一个 IC*OC 的矩阵，最终形成 4×4=16 个转换之后 weights 矩阵。

对于 FeatureMap 的转换，首先将输入 FeatureMap 按照 4×4 tile 进行切分，然后将每个 tile 通过 B 和 BT 转换为 4×4 的矩阵，矩阵 B 和 BT 为 FeatureMap 对应的 Winograd 变换矩阵，然后进行与 weight 处理相似的 relayout，转换为 16 个 nr_tiles*IC 的 FeatureMap 矩阵。

如上图所示，将上述转换后两批矩阵做矩阵乘，得到 16 个 nr_tiles*OC 的矩阵，然后将相同位置的 16 个点转换为 nr_tiles*OC 个 4×4 矩阵，再使用输出的 Winograd 变换矩阵 A 和 AT 将这些 4×4 的矩阵转换为 2×2 的输出矩阵，最后将这些矩阵写回输出矩阵中就可以得到 Winograd 卷积的最终结果。

算法优化

优化 1：weight 提前处理

在上述 Winograd 算法的基础上，鉴于模型中的权重数据在整个 Inference 的时候已经是常量不会再改变，因此可以在真正 Inference 之前就可以对模型进行了 weights 的转换，这样可以优化在 Inference 的时候 weights 转换的开销，特别是在 IC 和 OC 较大时，weight 转换的开销非常大，所以 weights 提前转换，尤其对 Winograd 优化特别重要，下图是 Winograd 中进行 weight 提前转换和不进行 weight 提前转换时各自的性能：

从上图可以看出 weight 转换在 Winograd 中耗时占比很大，进行 weight 提前转换可以带来很大的性能收益。

优化 2：Winograd 分块优化

上述的 Winograd 算法，还会有以下缺点：

1. 输入转换需要跨 channel 读写整个 feature map，数据读写对 Cache 不友好。
2. feature map 转换之后，矩阵乘时需要再 PACK，数据访存增加。

针对这些问题，可以对 Winograd 算法的整个计算流程做进一步的优化，这些优化主要包括：

• 输入转换时，分块 feature map 的 tiles 进行分块，每次只进行一定数量的 tiles 计算；
• 调整分块大小适配 CPU L1 Cache，使得矩阵乘不需要 PACK；

对整个输入 feature map 进行分块后，每次只计算一个分块的 nr 个 tiles，这样就可以保证每个批量矩阵的输入数据（除了转换之后的 weight 数据）保存于 L1 Cache，不会出现 Cache miss， 而且矩阵乘时不需要 PACK。

下面是分块优化前后的速度对比，可以看出分块优化对性能有显著的提升。

总结

CPU 上 Inference 中有关卷积的优化有很多的途径，这里我们主要介绍了 Im2col+matmul 卷积以及 Winograd 卷积中的一些进一步优化的技术手段，通过这些方法可以进一步加速卷积计算的性能，从而加速整个模型的 Inference 性能。如下图所示是 float32 的经典网络开启相关优化后，在骁龙 855 上的测试速度：

对于具体的优化细节，大家可以结合 MegEngine 的代码实现进行研究，欢迎大家提出宝贵意见。

更多 MegEngine 信息获取，您可以：查看文档、 深度学习框架 MegEngine 官网和 GitHub 项目，或加入 MegEngine 用户交流 群：

弹指瞬间，转眼 2022 年已经来到了尾声。在过去的一年里，国内开源力量继续蓬勃发展、稳步向前；与此同时，越来越多的团队开始聚焦于开源社区的运营。

作为本土开源技术社区，OSCHINA 也一直在不遗余力地助力着国内开源发展，为构建良好的中国开源生态献一分微薄之力；平台有一套完整的模式与能力帮助开源项目社区进行运营。

开源项目社区与技术团队是开源生态发展进程中不可或缺的中坚力量，OSCHINA 矢志不渝地为这些群体提供发声渠道，不断向开发者传播最新开源与开发技术的信息，让更多开发者关注到优秀的开源项目与技术。

2022 年，我们综合了 OSCHINA 平台上各大认证官方技术团队、开源社区帐号年度发表的内容频率及质量、开展各种活动运营积极性等多方面的表现，颁发 OSCHINA“2022 年度优秀开源技术团队”奖项，以鼓励大家的积极性与辛勤付出，一起让中国的开源生态更加乐观向上。开源生态的发展离不开你们。这也是 OSCHINA 推出该奖项的第二年，欢迎有更多的技术团队、开源项目社区参与到 OSCHINA 的交流当中来。

具体名单如下（按首字母顺序排名，不分先后）：

Alluxio 官方                                                                                          

阿里巴巴终端技术

阿里云云原生：与你并肩探索云原生技术点滴，分享你需要的

百度Geek说

CloudWeGo：构建企业云原生中间件的领先实践

得物技术：邀请你一起做最潮技术人

袋鼠云数栈DTinsight：以技术为核心，让我们一起将未来变成现在

Dromara开源组织

dubbo-go开源社区

FIT2CLOUD飞致云：软件用起来才有价值，才有改进的机会

HMS Core：与开发者一起，同成长，共精彩

华为云开发者联盟：分享华为云前沿资讯动态，方便开发者快速成长与发展

JetBrains中国：致力于打造世界上最强大、最高效的开发者工具

Juicedata：做最易用的云端共享文件系统

京东云开发者：为 AI、云计算、IoT 等相关领域提供技术分享交流

开务数据库

KubeSphere：一个开源的以应用为中心的容器云平台，支持多云与多集群管理

Kvrocks

MASA技术团队：专注于 .NET 现代应用开发解决方案

NebulaGraph：开源分布式图数据库，千亿顶点和万亿边仅毫秒级查询延时

NGINX开源社区

openKylin：开源聚力，共创未来

OneFlow深度学习框架

Orillusion：致力于打造一款完全开源基于 WebGPU 标准的轻量级渲染引擎

PostgreSQLChina

Rainbond：支持管理多种 Kubernetes 集群，提供企业级应用的全生命周期管理

RT-Thread

SeaTunnel：非常易用的支持海量数据实时同步的超高性能分布式数据集成平台

SelectDB

ShardingSphere社区：第一时间更新知名 Apache 顶级项目 ShardingSphere 技术新闻

声网：全球实时互动云服务开创者和引领者

Shopee技术团队：与你一起探讨前沿技术思考与应用

StarRocks：致力于打造世界顶级的新一代极速全场景 MPP 数据库

StoneDB：企业级一体化实时 HTAP 开源数据库

TakinTalks稳定性社区

涛思数据TDengine

TiDB：定位于 HTAP (Hybrid Transactional/Analytical Processing) 的融合型数据库产品

腾讯云中间件

优麒麟

vivo互联网技术：分享 vivo 互联网技术干货与沙龙活动，推荐最新行业动态与热门会议

VMware中国研发中心

WasmEdge：由 CNCF (云原生计算基金会) 托管的 WebAssembly runtime，是为边缘计算应用程序优化的执行沙箱

微众开源

网易数帆：专注数字化基础软件技术传播

又拍云：加速在线业务

云智慧AIOps社区：秉承 Make Digital Online 的使命，致力于通过先进的产品技术，为企业数字化转型和提升 IT 运营效率持续赋能

云杉网络：DeepFlow 云及云原生可观测性平台

Zadig云原生交付

Zilliz

字节跳动云原生计算：构建新一代海量数据计算平台

中移物联OneOS

作者名称&关注我们

独立站OpenCart——外贸平台自建站/跨境电商独立站专用系统。安装方便，功能强大，操作简单

前言：从2021年8月到2022年11月，历时1年多的时间。我们终于迎来了重大的版本升级，OpenCart专业版正式从v3.8升级到v4.1！

接下来看看我们从 v4.1 的版本中，新增、优化、修复了哪些功能？

✦✦

01 | 新增功能

（1）全新主题模板

首页：

产品展示页：

多功能模块：

OpenCart 专业版4.1中，我们将主题模板做了全新的升级，看上去更加“欧美范儿”让客户更有购买欲！

（2）Tiktok 购物车对接

配置路径：模块管理→通用模块→TikTok Business Extension

新增的TikTok购物车功能，让跨境卖家轻松在TikTok卖货转化客户

用户可以在短视频下方，购物车直接购买商品！

（3）客户组折扣优惠功能

配置路径：营销推广→会员组折扣→添加（编辑）

该功能可以让运营人员，轻松的对不同的客户群，设置不同的折扣优惠力度

该功能还可以选择折扣生效的“分类”。卖家轻松选择参与优惠的商品范围，运营起来更加灵活

（4）Track718 / 17Track 物流跟踪查询

配置路径：模块管理→通用模块→搜索“快递跟踪”

为了满足跨境消费用户，查看物流信息的需求，我们在这次升级中加入了市面上流行的17Track、Track718——国际物流追踪工具

（5）订单删除到回收站功能

配置路径：订单销售→订单管理→回收站

为了避免后台运营人员误操作导致的数据丢失，我们新增了回收站功能

删除订单后，可以在右上角“回收站”中找回、或彻底删除订单

✦✦

02 | 升级功能

（1）升级 第三方PHP包

 升级的第三方PHP包有：Illuminate ORM、阿里云短信、腾讯验证码、AWS存储等第三发包

（2）升级 前端框架/组件

升级前端框架/组件到Bootstrap5、jQuery v3.6.0、Font Awesome 6、Swiper 8

✦✦

03 | 优化功能

（1）多语言url伪静态地址唯一

为了进一步提升独立站商品，在搜索引擎中的收录比率。我们将url伪静态地址，设置成了唯一，避免了多个地址指向同一个页面导致的降权！

（2）左侧菜单栏性能提升

左侧菜单起来，更加的“顺滑”不卡顿！

（3） admin 路径修改后兼容问题

admin的路径可进行修改，进一步提升安全性。

修改后兼容性问题得到了优化！

修改前：

修改后：

（4） 退换货流程优化

我们根据客户提出的优化建议，结合跨境电商退换货场景，优化了退换货流程

用户可以在退换货时，客户直接可以填写寄回快递单号。后台能轻松查看！

（5） 后台商品可搜索子产品

（6） 博客列表排序改为按时间倒序

（7） 免运费功能，结账页显示还差XX免运费

（8） 系统环境持续升级

 支持PHP8.0及以上 / MySQL8.0！

✦✦

04 | 修复功能一览

更多产品更新动态

↓下方链接↓

https://www.opencart.cn/products_update

版权所有，转载需注明出处！

想了解电商独立站怎么做？想了解多商城系统建站？

想了解OpenCart独立站如何推广？对OpenCart有新的功能需求？

欢迎随时联系我们！

漏洞描述

owncast/owncast 是一个开源的实时视频和聊天服务平台。

owncast/owncast 0.0.13 之前的版本中由于 persistence.go 类对用户输入的 sql 语句没有正确转义，导致 /api/chat/users/setenabled API 端点容易受到 sql 注入漏洞的影响。具有 Moderator 权限的攻击者可通过向该端点发送包含恶意 userId 参数的 POST 请求进行基于时间的 SQL 盲注，获得 sqlite 数据库的管理权限，进而窃取 stream_key 访问 owncast 的管理仪表板。

影响范围

owncast/owncast@(-∞, 0.0.13)

修复方案

升级owncast/owncast到 0.0.13 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-60981

https://nvd.nist.gov/vuln/detail/CVE-2022-3751

https://github.com/owncast/owncast/commit/23b6e5868dc27a3fabbecf

https://huntr.dev/bounties/a04cff99-5d53-45e5-a882-771b0fad62c9/

情报订阅

OSCS(开源软件供应链安全社区)通过最快、最全的方式，发布开源项目最新的安全风险动态，包括开源组件安全漏洞、事件等信息。同时提供漏洞、投毒情报的免费订阅服务，社区用户可通过配置飞书、钉钉、企业微信机器人，及时获得一手情报信息推送：

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

前言

对于 ，相信熟悉 Go 语言的程序员基本都不陌生，一般线上的问题都是靠它可以快速定位。但是实际项目中，很多时候我们为了性能都不会开启它，但是出了问题又要靠它来分析。好在 go-zero 已经帮我们很好的集成进来了，我们只需要像开关一样去开启、关闭它即可，这样我们就可以配合运维监控，当出现 cpu、内存等异常情况时候，自动开始开启收集（比如大半夜你睡的正香的时候），那么第二天可以通过分析当时的采样还原现场，那我们看看 go-zero 是如何做的。

源码分析

我们可以看 go-zero 源码位置

服务启动的时候，go-zero 在 初始化了监听信号操作（ 也是通过这里通知的，这里不展开讲了），可以看到在接收到 信号时候，如果是第一次就开始收集，第二次就停止收集，看到这块可能瞬间就明白了，我们只需要在服务器执行 就可以开始收集这个服务的 信息了，再执行一次就停止了收集，就可以将这些文件导出到本地，使用 分析。

一次线上实战

我们线上有一个 的服务监控告警，内存占用比较高，这时候我打开 看到服务内存累计占用的确异常，如下图：

这时候到线上找到这个服务的服务器，执行了 ，查询到了这个 服务的进程 是 21181，我们这时候就可以给这个 服务发送信号收集 信息：

第一次执行了这个命令后，在对应服务的 日志中可以看到 了 ，当我们再次执行 ， 日志中可以看到 了 信息，这时候代表收集完成了。值得注意的是收集的信息都在 文件夹下，以这个服务名命名的如下：

这时候就可以下载对应的 去本地分析，可以使用 ，也可以配合 使用 查看，由于我这边通过命令行就快速定位了问题，就没用使用 。

我使用 然后进入命令行交互，使用 查看前面占用较高的资源。

前面基本是底层序列化等操作，发现主要问题集中在红色框中导致持续上涨的内存，因为业务同学在 中消费完了消息又向下游其他的mq服务使用 发送一个 消息，每次发送都调用一个 然后在 ，恰恰这个 服务又大量消息消费又特别频繁，导致内存不断上涨，最终解决方案将 在 中初始化一个 就可以了，没必要每次都要 ，世界又恢复清净了。

写在最后

想一下 go-zero 给了我们 开关，让我们很方便的实现分析问题，但是不是所有问题都是一直存在的，比如半夜突发内存、cpu 过高，早上起来服务正常了，这怎么排查？所以我们希望如果异常了，能保留问题现场，那我们是不是可以配合运维监控实现自动保存问题现场呢？比如内存、cpu 连续超过 指标3分钟的话，我们就调用这个开关收集，之后我们就可以根据这个文件来分析问题了，这样就达到自动化了。

项目地址

go-zero 微服务框架： https://github.com/zeromicro/go-zero

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

go-zero 微服务最佳实践项目：https://github.com/Mikaelemmmm/go-zero-looklook

欢迎使用 并 star 支持我们！

微信交流群

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

关注公众号

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

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

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

关注公众号

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

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

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

Godot 团队近日发表博客介绍了他们对 4.0 和 Godot 4.x 未来的期望。

团队表示，Godot 4.0 只是 Godot 4 的开始，它当然不会是完美的，但已准备好用于生产环境。他们预计，用户会遇到破坏工作流的错误（尤其是在不太常见的硬件上），许多工作流会感觉不完善，并且性能未能完全达到设定的目标。但团队会快速并定期发布错误修复版本（就像对 Alpha 和 Beta 所做的那样）。因此，Godot 4.0.1、4.0.2 等会在名义上的“4.0”稳定版本发布后不久出现。

同时，为了减轻贡献者的压力并避免延迟发布。从 4.1 版开始，开发团队的目标是加快功能更新的发布周期（4.1、4.2 等，即“4.x”版本）。

目前 Godot 4.0 仍处于测试阶段，团队建议希望获得更稳定、无错误体验的用户继续使用 3.5 系列版本，当他们认为 4.0 已准备好用于生产环境时，就会发布 4.0，而不是等到它完美时再发布。因为它不会是完美的，也不一定要完美。但它将为未来的所有工作奠定基础，在众人的帮助下，它可能会更接近我们设想的《Godot 4》。

4.0 作为重大版本更新，其开发工作于 2020 年启动，在两年多的开发过程中，Godot 4.0 带来的新特性包括：支持 Vulkan API、改进图形渲染系统、改进 OpenGL、添加新的 Physics 特性、增强 GDScript 脚本、更好地支持音频、改进多人游戏模式，以及对 Godot 3.x 的大量其他改进。

Oracle Linux 9 系列发布了第一个版本更新，支持 64 位 Intel 和 AMD () 以及 64 位 Arm () 平台。与所有的 Oracle Linux 版本一样，此版本与相应 RHEL 版本 100% 应用二进制兼容。

对于 64 位英特尔和 AMD 架构，Oracle Linux 提供了两个内核选项，即 Unbreakable Enterprise Kernel (UEK) 和兼容红帽的内核 (RHCK)。在 Arm 平台上，Oracle Linux 只提供 UEK。

此版本使用的 UEK 版本是 Unbreakable Enterprise Kernel Release 7 (UEK R7)。UEK R7 基于上游 Linux Kernel 5.15，同时支持 Oracle Linux 9 和 Oracle Linux 8。

Oracle Linux 9.1 重新引入了 Application Stream 模块，包含错误和安全修复，以及功能更新。最重要的变化是增强了安全性，以及带来新的开发工具。

安全

• OpenSSH 支持设置最小 RSA 密钥长度；此更新使用户能够为 OpenSSH 服务器和客户端设置最小 RSA 密钥长度。

• 默认情况下，加密策略强制执行 OpenSSH 2048 位 RSA 密钥长度最小值，且系统范围的加密策略强制 RSA 的最小密钥长度为 2048 位。如果 OpenSSH 连接失败并显示无效密钥长度错误消息，这意味需要使用更长的 RSA 密钥。

• OpenSSL 选项支持 SHA-1 签名。

• 支持使用 keylime 包。keylime 是一种使用可信平台模块 (TPM) 技术对远程系统进行认证的工具。

开发工具

• 新 Application Stream 模块提供了以下更新：
  • php: 8.1
  • ruby: 3.1
  • maven: 3.8
  • nodejs: 18
• httpd 已更新到 2.4.53 版本并包含 httpd-core 包。它包含带有所有基本文件的 httpd 二进制文件。

详情查看 Oracle Linux 9 Update 1 Release Notes。

发布公告

Oracle Linux 是由 Oracle 支持的企业级 Linux 发行版，它从 RHEL 源代码包生成。Oracle Linux 的独有特性包括一份定制且严格测试过的名为 “Oracle Unbreakable Kernel” 的 Linux 内核，与 Oracle 的多数数据库应用在内的软硬件产品的紧密集成，以及 “零掉线打补丁” 技术 —— 该特性能让系统管理员在不重启的情况下更新内核。

IntelliJ IDEA 2022.3 正式发布，在新版本中，开发者可以通过设置切换到新 UI，即可预览新的 IDE 外观。此版本引入了一个新的 Settings Sync（设置同步）解决方案，用于同步和备份自定义用户设置。此外，新版本的 IDE 还具有以下多项其他改进和升级。

主要更新

通过设置使用新 IntelliJ IDEA UI

在 IntelliJ IDEA 2022.3 中，您可以切换到新 UI 并预览 IDE 完全重做的外观，新外观干净、现代且功能强大。 勾选 Settings/Preferences | Appearance & Behavior（设置/偏好设置 | 外观与行为）中的 New UI preview（新 UI 预览）框，在项目中尝试一下。

新的 Settings Sync（设置同步）解决方案

新的 Settings Sync（设置同步）插件现在可用于所有基于 IntelliJ 的 IDE（Rider 除外），包括免费版和付费版。 新的解决方案能够同步来自平台、捆绑插件和一些第三方插件的大部分可共享设置。 请注意，我们将停止支持旧的 IDE Settings Sync（IDE 设置同步）插件并取消捆绑 Settings Repository（设置仓库）。

处理 WSL 2 中的项目的新方式（Ultimate）

IntelliJ IDEA Ultimate 2022.3 带来了处理在 WSL 2 文件系统中运行的项目的替代方式。 IDE 后端将直接在 WSL 2 中启动，而不是在 Windows 上运行完整的 IDE。 然后，您可以像在 IntelliJ IDEA 中使用远程开发时连接到远程机器一样轻松连接到它。 处理 WSL 2 中的项目时，这种安排可以提供更好的 IDE 性能。

适用于 Spring Bean 自动装配和 OpenAPI 架构生成的新操作（Ultimate）

使用 IntelliJ IDEA Ultimate 2022.3，您现在可以在需要的地方轻松自动装配 Spring Bean。这项新操作适用于 Spring、Micronaut 和 Jakarta EE CDI。此外，我们还增强了使用 OpenAPI 规范记录 Web API 的用户体验，现在可以立即为 Spring 控制器或 JAX-RS 资源生成 OpenAPI 定义。

Redis 支持（Ultimate）

在 IntelliJ IDEA Ultimate 2022.3 中，我们实现了备受期待的对 Redis 的支持。 您现在可以连接到 Redis Single Instance，在数据查看器中探索键值，借助智能编码辅助编写和执行 Redis 查询等。

用户体验

将工具窗口停靠到浮动编辑器选项卡的选项

为了让您可以更轻松地安排工作空间并在多个显示器上与 IntelliJ IDEA 交互，我们实现了将工具窗口拖出主窗口并将其停靠到浮动编辑器选项卡的选项。

意图操作预览默认启用

在 IntelliJ IDEA 2022.3 中，意图操作的预览功能现在默认开启，让您可以立即查看应用 IDE 建议后代码将如何变化。 打开可用意图操作列表并将鼠标悬停在不同选项上时会显示预览。 您可以在意图操作列表打开时按 F1 禁用预览功能，或者在 Settings/Preferences | Editor | General | Appearance（设置/偏好设置 | 编辑器 | 常规 | 外观）中管理。

改进了 Search Everywhere（随处搜索）结果的用户体验

我们微调了 Search Everywhere（随处搜索）结果列表背后的算法，使其行为更可预测，使搜索的素的选择更加准确。 现在，开始输入查询时，IDE 会冻结出现的第一个搜索结果，并且不会在找到更多选项时对其重新排序。此外，机器学习排名现在对 Files（文件）选项卡默认启用，这样可以提高结果的准确性并缩短搜索会话。

Find Usages（查找用法）结果中的相似用法集群

Find Usages（查找用法）现在提供有关代码素如何在项目中使用的更深入信息。 借助集群算法，IDE 现在可以分析搜索结果，检测最常见的用法模式，并根据结构相似性将所有找到的用法分类。 这些用法集群显示在 Find Usages（查找使用）工具窗口的 Preview（预览）选项卡中。

改进了 Tips of the Day（每日小技巧）

我们对 Tips of the Day（每日小技巧）的外观和行为做出了多项更改，使其更实用且更易理解。 我们更新了对话框的设计，为每个小技巧添加了标题以指定描述的 IDE 区域，并实现了技巧评分功能以收集反馈。我们还微调了确定显示哪些提示的算法，让您可以看到与 IDE 体验和正在处理的项目最相关的提示。

改进了 Bookmarks（书签）

我们为 Bookmarks（书签）实现了多项 UI 改进。 首先，又可以从编辑器选项卡为文件添加书签了。只需右键选项卡调用上下文菜单，然后选择 Bookmarks（书签）。 此外，您可以将所有打开的选项卡中的所有文件添加到 Bookmarks（书签）。 为此，可以调用相同上下文菜单并选择 Bookmark Open Tabs（为打开的选项卡添加书签），也可以使用编辑器选项卡窗格右侧的三点图标调用此操作。 IDE 会将所有打开的选项卡放入一个新的书签列表中，您可以随意为其命名。

以偏好代码样式查看库代码

IntelliJ IDEA 2022.3 提供了以偏好样式阅读代码的功能，即使该样式与文件的当前格式不同。 您可以在 Reader（阅读器）模式下应用新的可视格式设置层，根据自定义格式方案调整代码外观，而无需重新格式化实际代码。

性能改进

我们进行了显著性能改进以优化 IDE 的启动体验：我们并行化了一些此前按顺序运行的进程并减少了 Eager 类加载。 我们还将操作更新移至后台线程以改进 UI 响应，并实现多线程 VFS 刷新来增强索引编制。

编辑器

改进了复制剪切粘贴行为

我们重做了粘贴操作 (⌘V) 的行为。 现在，如果在没有选择代码的情况下复制 (⌘C) 或剪切 (⌘X) 一行，粘贴操作会将剪贴板的内容添加到当前行上方，而不是像旧版本一样添加到文本光标处。 此外，Settings/Preferences | Advanced Settings（设置/偏好设置 | 高级设置）中新增了一个选项，可供在未选择任何内容的情况下调用复制操作后禁用复制行的选择。

针对 JavaScript 和 TypeScript 的 Code Vision 提示

我们针对 JavaScript 和 TypeScript 实现了 Code Vision 内嵌提示。 这些提示让您可以直接在编辑器中即时了解代码，显示 inheritors（继承者）、usages（用法）、code authors（代码作者）和 related problems（相关问题）等指标。

Java

新的 Java 检查和其他改进

我们实现了一系列新的 Java 检查和快速修复，保护您的代码免受潜在危害和错误。 新增了一项检查来帮助检测在每个分支中都有一条公共语句的 switch 表达式，并提供了一个快速修复来将语句向上移动到 switch 表达式中，从而缩短代码。 IDE 将报告冗余数组长度检查，以及 之后的冗余 调用。 另一项新检查可以报告仅使用一个素或字符时数组、列表或字符串的多余创建。

Java 19 支持

IntelliJ IDEA 2022.3 支持 2022 年 9 月发布的 Java 19 的新功能。 IDE 现在支持记录模式以及对 switch 表达式模式匹配的更改，提供了代码高亮显示、补全和导航。 现有检查和快速修复已相应更新以支持这些更改。

Kotlin

对 Kotlin 1.7.20 功能的支持

IntelliJ IDEA 2022.3 现在完全支持 Kotlin 1.7.20 中引入的功能，包括新的 运算符和数据对象声明。

针对 Kotlin 改进了 IDE 性能

我们优化了缓存和索引的使用，使代码分析更快、更稳定。 我们还改进了 .gradle.kts 文件中的代码补全算法，根据我们的基准测试，它的速度提高了 4-5 倍。

Scala

更出色的 Scala 3 支持

v2022.3 引入了大量升级以提供更好的 Scala 3 支持。IDE 现在支持形参解组和引用模式，并且在匹配类型和类型变量的支持方面做出了诸多改进。现在有针对类型变量的类型推断，类型变量会被正确解析以用于模式匹配目的。 特征构造函数中的命名实参已得到正确处理，您可以使用一项操作快速创建一个 Scala 3 枚举文件或仅为顶层定义创建一个空 Scala 文件。 我们还有许多 TASTy Reader 增强，提高了高亮显示的准确性并改进了编辑器性能。

新的 Can be private（可为 private）检查

有时可以将 public 类、方法或字段设为 private 或 protected。 然而，当代码较为复杂时就很难判断。 新的 Can be private（可为 private）检查现在可以帮助您确定，还会提出快速修复建议。 将可为 private 的成员实际标记为 private 后，您可以将接口与实现详细信息分离，从而更容易理解代码。 这也减少了自动补全中的噪声，使使用过程更容易、更快，同时减少认知负担。它还提高了编译器和 IDE 的性能。

从用法创建形参

如果在方法中有一个未解析的符号，新增的快速修复可以将这个符号添加到方法的形参列表。

版本控制系统

为 GitHub 和 Space 重新设计了 Review list（审查列表）

我们重做了 Review list（审查列表）UI，帮助减少认知负担并清晰提供有关请求的最重要信息。 在改进中，我们还确保在所有受支持的审查平台上保持一致的外观。

构建工具

针对 Groovy 项目中 build.gradle 文件操作的改进

IntelliJ IDEA 2022.3 为 Groovy 构建脚本中的 Gradle 版本目录提供了代码补全和导航。 我们还微调了 Groovy 的 build.gradle 文件中的代码高亮显示，并实现了一些新检查。 IDE 现在会高亮显示已弃用的配置方法并建议适用替换选项。 它还能够检测构建脚本中插件 DSL 的不正确用法，并提供了一组新检查来鼓励使用任务配置规避 API

使用新 IntelliJ IDEA 工作区模型 API 的 Maven 导入

在 IntelliJ IDEA 2022.3 中，我们使用新的 IntelliJ 工作区模型 API 引入了实验性 Maven 导入功能。 此更改有望在导入 Maven 项目时提高最高 10% 的速度。 选项现在在 Settings/Preferences | Build, Execution, Deployment | Build Tools | Maven | Importing（设置/偏好设置 | 构建、执行、部署 | 构建工具 | Maven | 导入）中默认启用。 请注意，并非所有功能在此阶段都可用，部分手动模块设置在重新导入时不会保留。

Maven2 支持插件

从 v2022.3 开始，我们将解绑对 Maven2 的支持，改为通过一个独立插件提供，您可以从 Settings/Preferences | Plugins（设置/偏好设置 | 插件）查找并安装或从 Marketplace 下载。

运行/调试

增强了 Java 调试器中的数据流分析辅助

我们改进了 Java 调试器中的数据流分析 (DFA) 功能。 DFA 辅助已经预测了某些表达式的未来值。 现在，当分析器可以预测代码的某个分支不会被执行时，它会灰显对应代码部分。

排除覆盖注解的新选项

IntelliJ IDEA 2022.3 引入了一个选项来控制项目中哪些注解应从覆盖统计信息中排除。 要将不想测试的方法通知 IDE，首先用任意注解标记，然后转到 Settings/Preferences | Build, Execution, Deployment | Coverage（设置/偏好设置 | 构建、执行、部署 | 覆盖）并将注解添加到 Exclude annotations（排除注解）列表。

Docker

在不安装 Docker Desktop 的情况下从 WSL 使用 Docker 可执行文件

从 v2022.3 起，IntelliJ IDEA 支持连接到 WSL 中运行的 Docker。 您可以在 Settings / Preferences | Build, Execution, Deployment | Docker（设置/偏好设置 | 构建、执行、部署 | Docker）中设置此类连接。

Pull Docker image（拉取 Docker 镜像）意图操作

新增的方式可供轻松拉取所需镜像，而无需从 Dockerfile、docker-compose.yml 或使用 Testcontainers 的测试中运行。 只需在高亮显示的镜像名称上调用上下文操作 (⌥⏎)，然后选择 Pull Docker image（拉取 Docker 镜像）。

.dockerignore 文件类型支持

我们引入了对 .dockerignore 文件的全面支持，包括代码高亮显示和补全。 从 IDE 构建镜像时，这些文件会被纳入考量。

在 Dockerfile 文件中支持 heredoc 格式

Here 文档允许将后续 Dockerfile 行重定向到 或 命令的输入。 IntelliJ IDEA 现在支持此语法，您可以使用它在 Dockerfile 文件中生成配置文件或多行脚本。

来自 Docker 上下文的 Docker 连接

如果 Docker 配置文件中已经进行了设置，那么您现在可以使用 Docker Contexts（Docker 上下文）设置额外 Docker 连接。 为此，您可以在 Services（服务）视图中调用 Add Service（添加服务）上下文菜单并选择 Docker Connections From Docker Contexts（来自 Docker 上下文的 Docker 连接）。

已弃用的 Docker Machine 已从支持的连接列表中移除

由于 Docker Machine 已被 Docker 弃用，我们也已将其从 Settings/Preferences | Build, Execution, Deployment | Docker（设置/偏好设置 | 构建、执行、部署 | Docker）中的连接列表中移除。 如果您是活跃的 Docker Machine 用户，仍然可以通过 API URL 连接到它。 您可以获取 Docker 机器列表并输入相应 URL，也可以输入 certs 文件夹的路径。

教育功能

IDE 中的编程课程

现在，可以直接在 IDE 中学习 Java、Kotlin、Scala、Python、Go 和其他编程语言或者提高现有技能。 新功能还提供了创建个人教育课程的功能。 要访问此功能，请转到欢迎屏幕上的 Learn（学习）选项卡， Enable Access（启用访问）。 注意，对于 Java 和 Kotlin 以外的语言，您需要安装一个额外插件。

其他

• 现在，可以在带有 ARM64 处理器的 Windows 和 Linux 机器上运行 IntelliJ IDEA 2022.3。IDE 安装程序处于测试版阶段，网站和 JetBrains Toolbox App 均提供 Windows 版，但 Linux 版仅可从网站获得。
• 与 IntelliJ IDEA 捆绑的 Android 插件现在提供了 Android Studio Electric Eel Beta 2 的所有功能，包括对 Android Gradle 插件（AGP）7.4.0-beta02 的支持。

更多详情可查看：https://www.jetbrains.com/idea/whatsnew/

Chrome 108 正式发布，这个版本也是 Chrome 在 2022 年发布的最后一个稳定版，由于中间还有圣诞假期的缘故，下一次更新要到 2023 年的第二周才会到来。

新的 Viewport 尺寸单位

新的 viewport 单位让你有更多的控制权来创建自适应的 UI。这些单位以不同的方式测量 viewport 面积，因为它们考虑到了浏览器中可以展开或折叠的 UI 素，例如地址栏。

单位提供的 viewport 大小是假设这些用户代理界面是折叠的。另一方面， 单位提供的 viewport 尺寸是假设这些界面是展开的。

有了 单位，viewport 尺寸会根据浏览器界面素的显示与否而自动调整。这个值将是 单（最大）和 单（最小）范围内的任何值。

COLRv1 中现在支持可变字体

自 Chrome 98 开始，Chrome 就已支持 COLRv1 彩色矢量字体，但最初的版本只支持 COLRv1 表的静态功能。

但是 COLRv1 规范还包括 OpenType 变体，这意味着允许通过改变变轴的值来改变字体属性。如今 Chrome 108 已经支持这种变化。

这个版本还包括对 CSS 的 和 条件扩展。

有了这样的支持，开发者可以检测到字体功能何时可用，从而给用户带来最新最好的体验，也可以在支持不可用的情况下创建一个回退版本。

FileSystemSyncAccessHandle 方法现在是同步的

开发人员可以通过调用 来访问一种针对性能进行了高度优化的特殊文件，该方法在 对象上公开。这一调用会产生一个 。

其中 、 、 和 方法过去是异步的，但从Chrome 108 开始，它们是同步的。

这一变化会使 与基于 Wasm 的应用所期望的同步、类似 POSIX 的文件 API 相匹配，带来实质性的性能提升。

省电模式

几个月来，Google 一直致力于为 Chrome 和 ChromeOS 开发一些降低电池和内存消耗的功能，其中一些工具终于出现在浏览器的稳定版本中。省电模式默认处于禁用状态，用户可以将省电模式设置为在设备停止充电或电池电量低于 20% 时启用。更新到 108 后，用户可以访问 并将该标志设置为启用，就可以使用了。

更多详情可查看：https://developer.chrome.com/blog/new-in-chrome-108/

分层单体架构风格是分层思想在单体架构中的应用，其关注于技术视角的职责分层。同时，基于不同层变化速率的不同，在一定程度上控制变化在系统内的传播，有助于提升系统的稳定性。但这种技术视角而非业务视角的关注点隔离，导致了问题域与工程实现之间的Gap，这种割裂会导致系统认知复杂度的提升。

作者：倪新明

1 经典单体分层架构

1.1 四层单体架构风格

经典的四层单体分层架构如下图所示，应用在逻辑上划分为展现层、业务层、持久层及数据存储层，每层的职责如下：





这种分层单体架构可能是大多数开发人员最早接触、最为熟悉的应用架构风格，其特点是：

除了关注点隔离这一维度，分层也在 “变化” 的维度进行隔离。每层的变化速率不同，由下级上逐层增加，展现层的变化速率最快，数据存储层变化速率最低。通过严格层依赖关系约束，尽量降低低层变化对上层的影响。这个特点的上下文是分层之间依赖于抽象，而非依赖于具体。当实现发生变化而接口契约不变时，变更范围框定在当前层。但，如果是接口契约的变更，则可能会直接影响到上游的依赖层。

这种分层架构风格具有明显的优势：

1.2 五层单体架构风格

四层架构面临的问题是:

从复用性的角度考虑，如下所示的五层架构中，通过引入中间层解决复用问题。将共享服务从业务层沉淀到通用服务层，以提高复用性。其特点是：





相比于四层架构，五层分层架构的主要优势是：通过中间层的引入一定程度解决系统的复用性问题。但从反向角度看，正是由于中间层的引入导致了如下问题：





2 单体分层架构的共性问题探讨

当然，正是由于其极高的接受度，也造成了大家对分层的认知误区，认为分层是必然的“默认选项” ，从而忽略了分层的本质。分层到底是为了解决什么问题？

分层本质上是处理复杂性的一种方式：将复杂性在不同级别进行抽象，通过分层进行职责隔离，以此降低认知成本。同时，通过分层形成的“屏障”，控制变化在系统间的传播，提升系统稳定性。

不论是四层架构还是五层架构都是分层思想在单体应用架构风格下的实践，这种分层模式存在的固有问题主要体现在以下几个方面：

2.1 分层对系统复杂度和效率的影响

如上文所述，分层架构中各层的变化速度不同。越往上变化越快，稳定性越低，越往下变化越慢，稳定性越高。比如，展现层的用户展示逻辑可能频繁变化，对应于不同的场景诉求展示数据及形式都可能不同。





如果划分层次越多，层间依赖关系越严格，则系统的调用链路和依赖关系会更加清晰。但，请求及响应的链路越长，层间数据转换有额外成本。即使引入各种数据转换工具，比如MapStruct，实现起来依然会感觉非常繁琐和重复。

如果划分层次越多，层间依赖关系宽松，允许跨层调用（如下所示的从展现层调用持久层只是一个示意），则能在一定程度降低数据频繁转换的成本。但:

注：层间的依赖约束是一种架构决策，可以考虑通过自动化单测试机制进行保证，具体参考

《 基于ArchUnit守护系统架构 》

《 轻量级的架构决策记录机制 – ADR》

2.2 变化的隔离

我们对分层有一个普遍的、“先入为主” 的认知，分层能够隔离变化。首先会想到的例子，比如，如果底层的数据库发生了变更，又或者ORM框架发生了变更，那么，我们只需要修改DAO层的实现，而不需要更改上层的业务层代码。

但，这个是变化隔离的全部吗？

所以，引起系统变化的原因很多，场景各异，业务诉求亦不相同，分层对变化隔离程度也不相同：

分层可以控制变化在系统内的传播，由于变化场景的多样化，分层不能完全的隔离变化。





2.3 问题域与解决方案的割裂

重新思考下上文提到的分层单体架构的特点之一：关注点隔离，展现层、业务层、数据访问层、存储层等各层聚焦于自身的职责。这种关注点的本质是什么？

技术视角的隔离！！！

每层都是从技术视角将技术关注点进行隔离，而非业务领域视角。技术视角是研发友好的，作为开发人员，天然的可以理解和接受这种技术维度的统一语言：DAO层只负责处理数据相关逻辑，Controller层之服务处理Restful API相关，RPC层只处理与外部系统的跨进程调用等等。

而对于非常核心的业务概念，比如以订单为例，在单体分层架构下需要回答这样一个问题：“订单组件” 在哪里？

在经典的分层单体架构风格中，典型的实现如下图所示：





订单组件并不是以一个单一的、内聚的事物存在，其组成素OrderService以及其依赖的OrderDAO分散于不同的层，因此，这种模式下订单组件只是逻辑性、概念性的存在。作为业务域的核心抽象，订单组件没有真实的、直观的、内聚的反映在代码实现中。我们在工程代码库中寻找“订单组件”：

在IDE的支持下，这种导航并不会很复杂。但问题的根本在于：认知成本的增加。

我们去了解系统，天然的是从业务域而非技术域出发，单体分层恰恰是从技术域而非业务域出发，这种不同导致业务域与实现间的割裂，增加了对系统的认知成本。

实现要反应抽象，组件化思维本质上一种模块化思维，通过内聚性和封装性，将问题空间进行拆分成子空间，分而治之。对外通过接口提供组件能力，屏蔽内部的复杂性。接口契约的大小粒度需要权衡，粒度越小，能力提供越约聚焦，理解和接入成本越低，但通用性越差。接口契约粒度越大，则通用性越强，但理解和接入复杂性越高。





将组件化思维应用于单体分层架构，引申出模块化单体架构风格。应用架构按照问题域进行模块化组织，而非基于技术关注点进行拆分。组件内部遵循内聚性原则，其内包含了实现组件能力所需要的各个素及交互关系。组件之间通过统一的、合适粒度的接口契约进行交互，不直接依赖于组件的内部能力或模型。同时，组织良好的模块化单体应用架构也是进行微服务拆分的重要保证。如果你无法在单体架构中进行优雅的模块化组织，又何谈合理的微服务拆分呢？



3 结语

单体分层架构风格是分层思想在单体架构中的应用，其关注于技术视角的职责分层。同时，基于不同层变化速率的不同，在一定程度上控制变化在系统内的传播，有助于提升系统的稳定性。但这种技术视角而非业务视角的关注点隔离，导致了问题域与工程实现之间的Gap，这种割裂会导致系统认知复杂度的提升。将组件化思维应用于单体分层架构，模块化单体技术视角的分层拉回至业务域视角的模块化，一定程度上降低业务与工程实现间的隔离。良好的模块化是单体走向微服务的重要基石，如果模块化设计较差的系统，不仅会增加微服务拆分的成本，更为重要的是，会增加形成分布式单体的概率和风险。

Go-IOC 是一款为 Go 语言开发的运行时依赖注入库。Go 语言的语言特性决定了实现一款类型安全的依赖注入容器并不太容易，因此 Go-IOC 大量使用了 Go 的反射机制。如果你的使用场景对性能要求并不是那个苛刻，那 Go-IOC 非常适合你。

并不是说对性能要求苛刻的环境中就不能使用了，你可以把 Go-IOC 作为一个对象依赖管理工具，在你的业务初始化时获取依赖的对象。

使用方式

要创建一个 Container 实例，使用  方法

此时就创建了一个空的容器。

你也可以使用  来创建容器，创建之后，可以自动的把已经存在的  对象添加到容器中，由容器托管。

对象绑定

在使用之前，我们需要先将我们要托管的对象告诉容器。Container 支持三种类型的对象管理

• 单例对象 
• 原型对象（多例对象） 
• 字符串值对象绑定 

所有的对象绑定方法都会返回一个  返回值来说明是否绑定成功，应用在使用时一定要主动去检查这个 。

确定对象一定会绑定成功（一般不违反文档中描述的参数签名方式，都是一定会成功的）或者要求对象必须要绑定成功（通常我们都要求这样，不然怎么进行依赖管理呢），则可以使用  系列方法，比如  方法对应的时 ，当创建出错时，该方法会直接 。

绑定对象时，，， 方法对于同一类型，只能绑定一次，如果多次绑定同一类型对象的创建函数，会返回  错误。

有时候，希望对象创建函数可以多次重新绑定，这样就可以个应用更多的扩展性，可以随时替换掉对象的创建方法，比如测试时  对象的注入。这时候我们可以使用  系列方法：

使用  系列方法时，必须保证第一次绑定时使用的是  系列方法，否则无法重新绑定。

也就是说，可以这样绑定  ->  ， -> ，但是一旦出现 ，后续就无法对该对象重新绑定了。

单例对象

使用  系列的方法来将单例对象托管给容器，单例对象只会在第一次使用时自动完成创建，之后所有对该对象的访问都会自动将已经创建好的对象注入进来。

常用的方法是  方法，该方法会按照你提供的  函数或者对象来完成单例对象的注册。

参数  支持以下几种形式：

• 对象创建函数 

  比如

• 带错误返回值的对象创建函数 

  对象创建函数最多支持两个返回值，且要求第一个返回值为期望创建的对象，第二个返回值为 error 对象。

• 直接绑定对象

  如果对象已经创建好了，想要让 Container 来管理，可以直接将对象传递  方法

当对象第一次被使用时，Container 会将对象创建函数的执行结果缓存起来，从而实现任何时候后访问都是获取到的同一个对象。

原型对象（多例对象）

原型对象（多例对象）是指的由 Container 托管对象的创建过程，但是每次使用依赖注入获取到的都是新创建的对象。

使用  系列的方法来将原型对象的创建托管给容器。常用的方法是 。

参数  可以接受的类型与  系列函数完全一致，唯一的区别是在对象使用时，单例对象每次都是返回的同一个对象，而原型对象则是每次都返回新创建的对象。

字符串值对象绑定

这种绑定方式是将某个对象绑定到 Container 中，但是与  系列方法不同的是，它要求必须指定一个字符串类型的 ，每次获取对象的时候，使用  系列函数获取绑定的对象时，直接传递这个字符串 Key 即可。

常用的绑定方法为 。

依赖注入

在使用绑定对象时，通常我们使用  和  系列方法。

Resolve

 方法执行体 callback 内部能够进行依赖注入， 返回值，表明在注入对象时产生错误或者 callback 返回了 error。

比如，我们需要获取某个用户的信息和其角色信息，使用 Resolve 方法

Call

 方法不仅完成对象的依赖注入，还会返回  的返回值，返回值为数组结构。

比如

Provider

有时我们希望为不同的功能模块绑定不同的对象实现，比如在 Web 服务器中，每个请求的 handler 函数需要访问与本次请求有关的 request/response 对象，请求结束之后，Container 中的 request/response 对象也就没有用了，不同的请求获取到的也不是同一个对象。我们可以使用  配合  方法实现该功能。

AutoWire 结构体属性注入

使用  方法可以为结构体的属性注入其绑定的对象，要使用该特性，我们需要在需要依赖注入的结构体对象上添加  标签。

结构体属性注入支持公开和私有字段的注入。如果对象是通过类型来注入的，使用  来标记属性；如果使用的是  绑定的字符串为key的对象，则使用  来标记属性。

由于  要修改对象，因此必须使用对象的指针，结构体类型必须使用  。

其它方法

HasBound/HasBoundValue

方法签名

用于判断指定的 Key 是否已经绑定过了。

Keys

方法签名

获取所有绑定到 Container 中的对象信息。

CanOverride

方法签名

判断指定的 Key 是否可以覆盖，重新绑定创建函数。

WithCondition

 并不是 Container 实例的一个方法，而是一个工具函数，用于创建  接口。实现  接口后，在创建实例方法时会根据指定条件是否为 true 来判断当前实例方法是否有效。

WithCondition(init interface{}, onCondition interface{}) Conditional

参数  是传递给  和  方法的实例创建方法， 参数则是一个条件，在调用  及  方法时，会执行  函数，该函数支持两种形式

 函数的 bool 返回值用于控制该实例方法是否生效。

Extend

 并不是 Container 实例上的一个方法，而是一个独立的函数，用于从已有的 Container 生成一个新的 Container，新的 Container 继承已有 Container 所有的对象绑定。

容器继承之后，在依赖注入对象查找时，会优先从当前 Container 中查找，当找不到对象时，再从父对象查找。

在 Container 实例上个，有一个名为  的方法，该方法用于指定当前 Container 从 parent 继承。

示例项目

简单的示例可以参考项目的 example 目录。

以下项目中使用了  作为依赖注入管理库，感兴趣的可以参考一下。

• Glacier 一个应用管理框架，目前还没有写使用文档，该框架集成了 Container，用来管理框架的对象实例化。
• Adanos-Alert 使用 Glacier 开发的一款报警系统，它侧重点并不是监控，而是报警，可以对各种报警信息进行聚合，按照配置规则来实现多样化的报警，一般用于配合  来完成业务和错误日志的报警，配合， 等主流监控框架完成服务级的报警。目前还在开发中，但基本功能已经可用。
• Sync 使用 Glacier 开发一款跨主机文件同步工具，拥有友好的 web 配置界面，使用 GRPC 实现不同服务器之间文件的同步。

Elastic 是开源搜索和数据分析引擎 Elasticsearch 背后的母公司。今天 Elastic 的 CEO 宣布了裁员计划，表示将裁减公司大约 13% 的员工。

Elastic CEO 在发给全体员工的邮件中称，目前全球宏观经济环境正在迫使他们的客户收紧预算，并更仔细地审查投资。在市场的某些部分尤其如此，例如中小企业在不确定时期的消费意愿有限。为了渡过这个阶段，公司要将重心放在那些对未来最关键的业务领域，并找到更有效的方法来服务公司业务的某些部分。

Elastic 公司对被裁员工提供了如下方案：

• 遣散费：向所有被裁员工支付至少 14 周的补偿金，另外工作满一年就增加一周的补偿金。
• PTO：对于所有未使用的 PTO 时间（Pay Time Off，带薪休假）支付相应的薪水。
• 医疗保健：对于参与 Elastic 公司医疗保健计划的员工，支付 6 个月的现有医疗保健保费，或将根据工作地点支付等值现金。
• RSU 股票：被裁员工将会获得截至 12 月 8 日的 RSU 股票。
• 职业支持：为受影响的员工提供简历和求职支持。
• 移民支持：为有需要的人提供移民支持。

海外用户常用的社交平台如 WhatsApp、Telegram、Facebook Messenger 等都早已实现了端到端（E2E）加密的通信。反而另一大社交平台 Twitter 一直都没有使用端到端加密（Twitter 使用的是标准加密，使用了由服务提供商持有的密钥，这意味着任何有必要权限的人都可以读取用户的信息），目前用户在 Twitter 中发送私信进行一对一交流的时候，用户的聊天内容并没有足够的安全保障。

Twitter 的首席执行官 Elon Musk 最近就用一个 emoji 表情符号回应了逆向工程师 Jane Manchun Wong 的发现，暗示 Twitter 的加密的 DM 目前正在开发中，将会使用完全的端到端加密。

Jane Manchun Wong 进一步研究发现，Twitter 在 iOS 版应用中有对 Signal 开源协议的引用。这似乎表明，Twitter 计划使用主打信息安全的 Signal 应用程序相同的 E2E 加密技术。

该加密协议是开源的，也就意味着所有开发者都可以对代码进行审查，确保该协议足够安全可靠。至于 Twitter 何时会实现这个功能，目前官方还没有给出具体的时间表。

不过，曾经在 Twitter 任职的开发者 Brandon Carpenter 表示，这是他在 2018 年就写下的代码，并给出了当时删除 Twitter for iOS 中端到端加密原型的提交历史记录，之所以当时没有实现这个功能是因为该协议难以提供与标准协议相同的 DM 功能。

在上一篇文章《HTAP 的下一步？SoTP 初探（上）：数据分析正在从“大”数据趋向“小”而“宽”数据》中，我们从 HTAP 的发展历史脉络出发，结合国际知名咨询机构Gartner 的调研报告，点出了 SoTP（Serving over TP）诞生的背景。今天这篇文章，我们着重来讲一讲，SoTP 的定义、解决的问题和典型应用场景。本文是在第七届中国开源年会上的演讲实录+编辑补充版，权当抛砖引玉，欢迎广大同行批评指正。

SoTP 的重要支撑

“小”数据和“宽”数据的崛起

开篇还是回顾一下，我们提出 SoTP 的重要背景：从“大”数据转向“小”数据和“宽”数据。

根据 Gartner 技术成熟度曲线的判断，小数据正处于“创新出发点”的阶段，可能还需要一段时间才可以进入成熟，不过，随着小数据市场渗透率不断提高，它对 AI 以及更广义的数据分析的影响是显而易见且非常深远的。小数据的优势在于，抛开了对大型单体数据的依赖，实现了对于大型、小型、结构化、非结构化数据源的分析与协同。

这个趋势不仅仅是被 Gartner 一家认可的， 国际权威学者吴恩达教授也在今年 2 月初提出了：AI 的下一个发展方向，是从大数据转向小数据。当然，我们提的 AI 也只是实时事务处理与数据分析的一个重要应用领域而已，并不是全部。不过，未来数据库、数据分析处理与 AI、ML 的结合却是必然的，就比如我们后续将在 StoneDB 架构中加入的 StoneDB Autopilot 功能。作为在人工智能和机器学习领域上有着全球级影响力的领军人物，吴恩达最近几年一直在倡导以数据为中心的人工智能。什么叫以数据为中心？那就是对数据的质要有更高的要求而不是一昧的追求量（优质的小数据集经过训练也能有很好的泛化能力，如果读者感兴趣，可以阅读吴恩达接受 IEEE Spectrum 的采访新闻），而“小”数据和“宽”数据恰恰就是高质量数据集的最佳载体，可以理解为，这是众多数据分析场景逐渐从依托“量”转向提升“质”的重大发展趋势。

大势所趋之下，作为实时数据分析场景的基础底座之一，HTAP 数据库扮演着的角色也越来越重要。如果说通过“小”数据和“宽”数据获得了更高质的数据，那么热数据则是对这个质的再一次提升。

热数据一般是指频繁被访问查询的在线数据，而在一个实时智能决策系统中，近期产生的热数据往往才会发挥最大的价值，但是，并非所有 HTAP 数据库都是专注于热数据场景下的“小”而“宽”数据的，对此，StoneDB 作为国内首个对标 Oracle MySQL HeatWave 的开源实时一体化 HTAP 数据库，率先提出了面向热数据、小数据和宽数据场景的 SoTP 型数据库理念。

SoTP 数据库的定义

2.1 Serving 的定义和分类

先说这个 Serving 场景，一些同学可能有些不熟悉，因为好像之前听到的都是 OLTP 场景（指在线事务处理，比如业务处理，交易系统等） 和 OLAP 场景（指在线分析处理，比如BI、Adhoc等），但其实还有一种场景，是指在线实时服务的，介于 OLTP 和 OLAP 之间，可能还偏向 OLTP 一些，那么这种场景我们就称之为 Serving（英语时态学得好的人，应该可以 Get 到，就是进行时的意思，也即可理解为“进行中的服务”）

Serving 可以和 OLTP 组合，也可以和 BigData 或者 Stream 组合，我们把 Serving 分成了三类：

Type1. Serving over TP（StoneDB）

• 特点：处理事务型热数据，提供实时分析、事务和分析处理一体化

• 典型代表：Oracle MySQL Heatwave，StoneDB
  

Type2. Serving for BigData

• 特点：处理非事务型冷、温数据；适用读多写少BI分析类

• 典型代表：ClickHouse

Type3. Serving for Stream

• 特点：处理非结构化数据，作业状态状态等数据管理

• 典型代表：RocksDB

为了方便大家理解，我们做了一张图，三种类型的 Serving 数据库如图所示：

2.2 SoTP 的定义和解决的问题

那么，SoTP （Serving over TP）的定义也就很清晰了，简单来说，我们把这种有能力对在 OLTP 数据库上的热数据、小数据、宽数据进行 Serving（在线实时服务） 操作的数据库，称之为 SoTP 数据库。具体来讲，比如以 SoTP 数据库 StoneDB 为例，一个 SoTP 产品至少要满足以下几点要求：

• 数据量：一个系统，数据量不超过 100 TB，通常介于 100GB~100TB 之间

• 数据类型：主要处理结构化数据，可处理 Text、JSON 等半结构化数据，不处理非结构化数据

• NoETL：TP 到 Serving 的流转过程中，NOETL，直接基于 TP 数据完成实时分析

• 查询类型：复杂即时的查询，将事务型热数据，从行存变成可被快速读取的列存数据

• 高并发的混合负载：比 AP 查询的并发高 3 个数量级

• 成本控制：TCO 总成本下降 80%

简单举个例子。如下图，右边就 SoTP 据库 StoneDB，对外主要接受两个业务请求，分别是左边的 OLTP 和 Serving，其中，进行 Serving 请求的主要是是 OLTP 产生的热数据。那么这个 SoTP 处理数据的过程就是先把 OLTP 请求交给主引擎——TP 引擎承载（如 InnoDB），然后再把 Serving 请求交给次引擎——Serving 引擎承载（如 Tianmu）。

2.3 SoTP 的典型场景案例

2.3.1 场景一：Native Analytics Query

注意，我们这里重点提出了一个 Native，什么叫 Native，就是指数据源上的原生，我们如果对 OLTP 系统产生的数据进行查询分析，这里的数据应该是同源的热数据，而不是另外一份数据。

客户需要一个数据库，既能执行 OLTP，还能高效、实时地运行Analytics；否则还得需要另外一个数据库运行 Analytics，这引入了额外的复杂性和代价。

传统的 ETL 方案架构就是比较复杂的，比如 MySQL + ETL + Elastic：

这种方案就不能称为是 Native，体现在数据源的不一致、查询语句语法变更等等。但是，使用 SoTP 数据库 StoneDB，就有所不同了，我们是完全一体化架构，如下：

StoneDB 一体化架构

采用 StoneDB 这种一体化架构就可以达成降本增效的效果，下图就是我们在华东地区的一个 CRM 客户使用 StoneDB 的案例：

总结来说，这个厂商获得了以下成果：

高兼容：平行替代MySQL业务，零改动

低成本：节省了成本 52%

强性能：DTU 提升了 68%

易维护：技术难度降低 50%

2.3.2 场景二：Native Autopilot

Autopilot 自动化了实现大规模高查询性能的许多最重要和最具挑战性的方面，包括provisioning、数据加载、查询执行和故障处理。

如图，StoneDB 未来的 Autopilot 将有以下特性：

自动系统配置

• 自动资源占用监测，集群节点按需自动动态伸缩。

• 自动性能监控，对需要分析的表数据进行自适应采样来预测运行工作负载所需的节点数量。

数据加载

• 自动并行加载：自动调整数据表最佳并行度来优化加载时间和内存使用

• 自动数据放置：存储数据自动分区以实现最佳查询

• 自动编码：采用可变长度的字符串编码确保最佳查询性能

查询执行

• 根据历史查询计划执行情况和统计信息优化查询性能，提升查询效率。

故障处理

• 自动错误恢复：当数据库节点访问异常时，StoneDB将自动配置新的数据库节点并完成数据迁移，确保数据快速恢复。

这里也可以举个例子，比如现在我们的需求是减少用户使用成本：要提供自动化的集群配置、加载数据、查询处理和故障处理服务，使得用户可以更多关注业务开发，减少其繁重且易出错的运维操作。

在使用 Autopilot 之前：

1. 依据数据量和数据变化率，估算节点数量；

2. 与业务开发人员确定数据分布方案；

3. 业务运行中，不断优化SQL语句；调整数据分布策略；

4. 集群节点变化导致数据迁移，业务架构，中间件等相关策略需调整；

在使用 Autopilot 之后：

1. 搭建好StoneDB服务；

2. 系统依据运行情况，自动调整相关参数，使得StoneDB处于最佳运行状态；

3. 业务人员和DBA等得到解放，更加关注业务。

SoTP 与 OLTP、OLAP 的差异

我们总结了 SoTP 与 OLTP、OLAP 的差异，具体如下表：

SoTP 数据库——StoneDB

当然，可能有部分同学看到我们上述的定位，会想着说 SoTP 和 HTAP 有一些相同之处，这是当然，毕竟我们的说法是 HTAP 的下一步，SoTP 初探。实际上，SoTP 针对的是更加细分的 HTAP 赛道，我们的核心目标就是对最近产生的热数据、小数据和宽数据进行实时分析，更进一步的是，把数据分析能力与机器学习相结合，而且因为我们是基于 MySQL 生态做的一体化架构，也可以把我们称作是 MySQL 热数据分析加速器。总之，StoneDB 作为 SoTP 数据库的核心特性就是：能够将 Serving 需要的热数据实时分析做到极致。

我们努力的现在，就是为了让下一代热数据分析尽早走上国产数据库的历史舞台，让更多的用户体验到真正的商业智能，从而更好地利用数据协作共享、驱动运营和做出决策。以下便是我们的 StoneDB 2.0 架构图：

StoneDB 的 2.0 架构完全对标 Oracle MySQL MDS（HeatWave），HeatWave 有多强大？我们后面也会出一篇文章给大家分享一下。目前，我们的架构设计方案的RFC文档也完全公布在了 Github 上：

https://github.com/stoneatom/stonedb/issues/436 

如果您想了解更多，也可以关注我们的 Github 仓库：

https://github.com/stoneatom/stonedb

以上，就是本次的分享，欢迎大家批评指正。如果您还有其他疑问，欢迎添加StoneDB小助手，加入StoneDB开源社区技术交流群，在群里您可以随时提问，我们会认真为您解答。

扫码添加小助手

加入StoneDB开源社区用户群

讨论交流，共同进步

2023 年十大战略技术趋势中哪一项最需要 HTAP ？

存算一体 VS 存算分离 ，IT发展下的技术迭代

文｜田阳 （花名：烈）

MOSN Maintainer

专注云原生等技术领域

本文3042字 阅读 10 分钟

1. 背景

Service Mesh 被越来越多的公司认可并实践，在实际落地过程中也遇到了形形色色的问题，同时架构也在持续演进去解决这些问题：有的从初始的 DaemonSet mode 转变为 Sidecar mode，如 Linkerd ；有的从做 CNI 延伸到 Service Mesh 场景， 结合 eBPF 使用 DaemonSet mode，如 Cilium ；如今 Istio 也新增了 Ambient Mesh ，支持 DaemonSet mode 作为其主推模式。

不难看出一个演进趋势就是围绕着是否需要 Sidecar 而展开，那么 Service Mesh 的下一站将会是 Sidecarless 吗？本文将对目前的社区趋势做一个简要分析， 最后也将介绍蚂蚁在这方面的探索和实践。

2. 社区趋势

2.1 Cilium

Cilium[1] 是目前最火的云原生网络技术之一，基于革命性的内核技术 eBPF，提供、保护和观察容器工作负载之间的网络连接。

在 6 月份，Cilium 发布了 1.12 版本，其中发布了 Service Mesh 能力、Sidecarless 架构，它提供了两种模式：

通过图表我们可以发现：针对 L3/L4 的能力，Cilium 使用内核的 eBPF 直接支持；对于 L7 的部分能力，将使用 DaemonSet 部署的 Envoy 来支持。Cilium 认为大部分能力都不需要 L7 的参与，通过 eBPF 就能满足，所以 Cilium 也称自己为内核级服务网格。

针对于此 Cilium 也有一个解释，结合应用程序 TCPD 最终被合入 linux kernel 发展为 iptables 为例，认为 Mesh 也应该作为基础能力下沉到 linux kernel 作为网络的基础组件，就类似于 TCP，作为 Linux 的一部分透明地提供的服务。

在当需要 L7 代理能力的时候，会构建 DaemonSet Envoy 处理 L7 的能力。Envoy 也已经有了 Namespace 的初步概念，它们被称为监听器。监听器可以携带单独的配置并独立运行，从而可以支持多租户的配置隔离 (但目前还做不到资源和故障的隔离） 。

Cilium 认为 DaemonSet 相比 Sidecar 最明显的好处就是代理数大大减少，减少资源和管理成本。

可以看出 Cilium Service Mesh 的发展历程是由下而上，从内核层慢慢向业务层扩展自己的服务边界，由 eBPF 来支持服务网络也是有一定的立场因素。但 eBPF 并不是银弹，DaemonSet mode 也是有一些其他的问题，收益和损失都是相对的。

2.2 Linkerd

当然，Cilium 这个架构也不乏有挑战者，其中来头最大的就是 Linkerd[2] （Service Mesh 概念的提出者） 的创始人 William Morgan ，比较有意思的是 Linkerd 最开始的架构是 DaemonSet mode ，在后面的版本才换成 Sidecar mode ，对于此，作为逆行者的他应该最有发言权。

在 William Morgan 的最新文章[3] 中也客观提出了 eBPF 的一些局限性，为了保证  eBPF  的安全执行而不影响 kernel ，需要通过验证器验证是否有不正确的行为，这就导致 eBPF 的编写存在一定的潜规则，比如不能有无界循环；不能超过预设的大小等，代码的复杂性也就受到了一定限制。所以较复杂的逻辑用 eBPF 来实现也是有较高的成本的。

文章中也提到了 DaemonSet 的一些弊端：

– 资源管理不可评估：这取决于 K8s 调度多少 Pod 到该 Node；

– 隔离性：所有应用公用一个 Proxy ，相互影响稳定性；

– 爆炸半径变大：影响整个 Node 的 Pod 实例；

– 安全问题更复杂：比如 Proxy 保存有整个 Node 的秘钥。

简而言之，Sidecar 模式继续贯彻了容器级别的隔离保护 —— 内核可以在容器级别执行所有安全保护和公平的多租户调度。容器的隔离仍然可以完美的运行，而 DaemonSet 模式却破坏了这一切，重新引入了争抢式的多租户隔离问题。

当然他也认为 eBPF 可以更好的促进 Mesh 的发展，eBPF+Sidecar 的结合是 Mesh 的未来。

我们也比较认可他对于 eBPF 的看法， eBPF 就像是一把瑞士军刀，小巧精湛，作为胶水把各种网络数据面连接起来，提供基础网络能力，比如提供访问加速，透明劫持，网络可观察性等能力。但要开发复杂的业务能力，在实操之后，感觉还是有点力不从心。目前我们团队也正在使用 eBPF 开发 K8s Service 和透明拦截等基础网络能力。

William Morgan 的说法看着也不无道理，我们先不急着站队，再来看看 Istio 是怎么做的，看是否会有新的想法~

2.3 Istio

在 9 月份，Service Mesh 领域的当家花旦 Istio 毫无征兆的发布了 Ambient Mesh ，并作为自己后续的主推架构，简单来讲就是把数据面从 Sidecar 中剥离出来独立部署，Sidecarless 架构，以彻底解决 Mesh 基础设施和应用部署耦合的问题。

比较好奇 Istio 在没有经过社区讨论和落地案例的情况下，是怎样决策笃定这个新的架构方向的呢？

Istio 认为 Sidecar mode 存在如下三个问题：

– 侵入性

必须通过修改应用程序的 Kubernetes pod spec 来将 Sidecar 代理 “注入” 到应用程序中，并且需要将 Pod 中应用的流量重定向到 Sidecar 。因此安装或升级 Sidecar 需要重新启动应用 Pod ，这对工作负载来说可能是破坏性的。

– 资源利用不足

由于每个 Sidecar 代理只用于其 Pod 中相关的工作负载，因此必须针对每个 Pod 可能的最坏情况保守地配置 Sidecar 的 CPU 和内存资源。这导致了大量的资源预留，可能导致整个集群的资源利用不足。

– 流量中断

流量捕获和 HTTP 处理 通常由 Sidecar 完成，这些操作的计算成本很高，并且可能会破坏一些实现和 HTTP 协议不完全兼容的应用程序。

Envoy 的创始人也来凑了个热闹，他对 Sidecar 架构也是颇有微词。

我们在落地过程中也是遇到了类似的痛点，比如随着机房规模和应用规模的变大，应用的连接数继续膨胀导致 CPU 和 MEM 资源占用也在持续增加，但这一切都不是应用本身想去关心的。

那么让我们来解开 Ambient Mesh 架构真面目，是怎样来解决 Sidecar mode 的问题， 架构主要提出了分层：

从图中可以看出，跟 Cilium 有一些类似，这儿的两层数据面都是基于 Envoy 来构建的，Secure Overlay Layer 主要处理 L4 场景，DaemonSet 部署，L7 processing Layer 主要处理 L7 场景，以 gateway 形式通过 Pod 部署，一个应用部署一个 gateway。

图中的 ztunnel 就是 L4 （DaemonSet 部署） ，waypoint 就是 L7 （Pod 部署） ，L4 和 L7 都是可选的，可以根据业务场景灵活组合，比如没有 L7 的场景，直接就用 L4 即可。

注：图中的 ztunnel 就是L4 （DaemonSet 部署） ，waypoint 就是 L7 （Pod 部署） 。

无形之中，Ambient Mesh 架构对 William Morgan 评论中的问题也做了一定的解决和反驳：

– 资源评估

Istio 认为 L4 资源占用少，然后 L7 的资源占用是通过 Pod 部署，可以更好的弹性。

– 隔离性

每个应用都将有一个 L7 集群，相互不影响。

– 爆炸半径

L4 逻辑简单相对比较稳定，L7 独立部署，也只影响自身应用。

– 安全问题

Istio 认为 Envoy 作为被世界上最大的网络运营商使用的久经考验的成熟软件，它出现安全漏洞的可能性远低于与它一起运行的应用程序。DaemonSet 模式下，出现安全问题时的影响范围并不比任何其他依赖每节点密钥进行加密的 CNI 插件差。有限的 L4 攻击面和 Envoy 的安全特性，Istio 觉得这种风险是有限和可以接受的。

针对 William Morgan 提到的 DaemonSet 增加了安全风险，我们也持保留意见，就拿证书场景为例，在没有统一接入层 （南北向接入网关） 这个产品之前 （15 年前，还没有 K8s ） ，应用的 HTTPS 证书和私钥都是放在跟应用一起部署的 Tengine 上，就类似于 Sidecar 模式，但接入层诞生的一个原因恰恰就是为了集中管理证书和私钥来减少安全风险，通过证书和私钥的分离架构，私钥单独存放在更加安全的 key 集群，并且通过 QAT 硬件加速，HTTPS 性能也更加高效。

把 HTTPS 和 L7 服务治理能力从应用空间解耦出来下沉为基础设施，也让我们有更多的机会去做集中的优化和演进，同时也对应用更加透明，那个时代的以应用为中心。

统一接入层和目前 Service Mesh 的 DaemonSet mode 有着不少相似之处，DaemonSet mode 也可以认为是一个东西流量的 Node 接入层。

网络通信作为基础设施，和应用完全解耦后，可以更好的优化和演进，也能更加透明高效的为应用提供相关基础能力，比如网络连接治理，可信身份，链路加密，流量镜像，安全隔离，服务治理等，更好的以应用为中心。

从 Cilium 到 Linkerd，再到 Istio，几大社区相互切磋，归根结底还是大家的业务场景不一样，也或者是立场不一样。在安全性，稳定性，管理成本，资源占用上，总是会有一个侧重点，这是需要根据不同的业务场景去选择，脱离业务场景谈架构，还是比较空洞。

3. 下一站

没有最好的架构，只有最适合自己的架构，在大家的业务场景，你会选择 Sidecar ，还是 Sidecarless ，你认为的下一站是什么呢？

下周我们即将发布 《降本增效: 蚂蚁在 Sidecarless 的探索和实践》，一起来聊聊蚂蚁在这个方向的探索和演进，期待和大家的交流~

4. 引用

[1]Cilium :

https://istio.io/latest/blog/2022/introducing-ambient-mesh/

[2]Linkerd :

https://isovalent.com/blog/post/cilium-service-mesh/

[3]William Morgan 的最新文章:

https://buoyant.io/blog/ebpf-sidecars-and-the-future-of-the-service-mesh

MOSN Star 一下✨：

https://github.com/mosn/mosn

本周推荐阅读

蚂蚁集团 Service Mesh 进展回顾与展望

顺丰科技 Service Mesh：落地半年，最初目标已经实现，将在更多场景进行大规模探索

「网商双十一」基于 ServiceMesh 技术的业务链路隔离技术及实践

MOSN 反向通道详解

全球首创的开源数据编排软件开发商Alluxio，近日宣布2.9免费开源社区版和2.9企业版正式对外发布！

本文将为您快速盘点2.9的那些更新亮点：

2.9正式版本（GA）具备较强的稳定性、良好的支持性以及企业级特性。本文将介绍Alluxio的新架构以及该架构如何赋能世界头部企业在跨区域、跨计算引擎与存储系统的大数据分析和AI 应用场景下实现增长、增强敏捷性。

Alluxio 2.9 版本增加了跨环境集群同步功能，支持横向扩展的多租户架构；显著改进在Kubernetes上部署的工具集和指南，增强了Alluxio的可管理性；此外，新版本还通过优化S3 API 实现安全性和性能上的提升。

企业可以通过Alluxio打造跨计算和跨存储的多云数据平台。Alluxio可以与Spark、Presto、Trino、PyTorch 和 Tensorflow 等一起部署于任何云平台，如 AWS、GCP 和 Azure。同时，Alluxio还可以部署在私有云数据中心或公有云在 Kubernetes 上使用。

Alluxio社区版功能亮点

以下功能Alluxio 2.9社区版和企业版均支持

Master节点健康状态监测

Alluxio master 现在定期检查各类资源的综合使用情况，包括 CPU 和内存使用情况，以及通过几个影响性能的内部关键数据架构推断系统的整体状态。可以通过查看 master.system.status 指标获取Master节点健康状态：

• 闲置
• 正常运行
• 繁忙
• 过载

关于如何使用此功能，可“详细信息”查看文档，了解有关监测功能的更多内容。

Worker 节点上的分页式存储（试验功能）

新版本支持更细粒度的存储。以往Alluxio只支持64MB块存储，新版本支持1MB的分页级存储，数据能以更细的颗粒度缓存在Alluxio worker 节点上。

此功能是为了通过提高缓存的效率而增强性能，当应用首次访问底层存储时，可以减少读放大。

可查看文档，了解如何使用：

Alluxio企业版功能亮点

下列功能仅限于Alluxio企业版

新增跨环境集群同步功能

租户隔离可有效防止不同团队在访问共享数据湖存储时产生竞争。Alluxio通过新增的跨集群同步功能，提高了在Kubernetes上跨租户或跨环境部署多个Alluxio集群时的可扩展性。

多Alluxio集群的联合（federation）是通过数据同步实现的。不同的Alluxio实例之间知道各自对于数据的修改情况，实现数据的互通，从而自动保持数据同步。当部署卫星集群架构时，此功能尤其有用，数据生产者在更新数据湖时可与数据消费者实现隔离。

开始部署前，可通过查看文档

新增Kubernetes Operator，提升Alluxio的可管理性

在Kubernetes上运行Alluxio有助于将部署策略标准化，使得数据技术栈可移植到任何环境。新版本增加了Alluxio Operator，可简化多个Alluxio集群的部署和管理。

管理员如今可以通过CRD（自定义资源）轻松部署和管理Alluxio。使用Alluxio Operator可降低管理多个Alluxio实例的负担。

开始部署前，可查看文档，了解详情。

强化S3 API安全性

新版本进一步强化了S3 API功能，管理员可通过统一命名空间来集中管理身份验证和访问控制策略，实现无论是在本地还是跨云异构存储均能达到统一的安全保护。

新版本增加了对S3 API开放式身份验证协议的支持，确保在处理Alluxio的用户请求之前对其进行验证。这项新功能允许数据平台团队连接到身份管理系统（例如 PingFederate），并使用单点登录 (SSO)。

开始部署前，可查看文档，了解详情。

想要了解更多关于Alluxio的干货文章、热门活动、专家分享，可进入【Alluxio智库】：

引言

当前，数据量呈快速增长态势，给诸如 Presto 等查询引擎带来了挑战。

Presto 作为一种流行的交互式查询引擎，具有可扩展、高性能并可与 Hadoop 进行平滑集成的特性。随着数据量的增长，Presto 需要读取更大的数据块并将其加载到内存中，继而导致IO、内存占用增大以及 GC 时间变长等。

Apache Parquet 是一种可用于高效存储和检索数据的开源列式文件格式，提供高效的数据压缩和编码方案，性能更优，能批量处理复杂的数据。

我们先前已经采取了一些措施来加快 Presto 对 Parquet 数据的读取速度，但需要读取的数据量依旧很大。从 Java 版本的 Parquet(parquet-mr 1.11.0) 开始，Parquet 添加了一个名为 Page Index 的特性，通过在列块（column chunk)中过滤不必要的 Parquet 页(page)来加快查询速度。

本文就该特性、移植到 Presto 的状态以及基准测试结果进行了介绍。

统计信息

Parquet 文件数据包含有关文件中数据的最小/最大值的统计信息。对于一个给定 filter 的查询而言，统计信息的最小/最大值可以用作 filter 要查找的值的范围。如果要查找的值不在范围内，就可以跳过读取该数据块。这样一来提高了 IO、内存和 CPU等资源的利用率，从而加快了查询速度。

下述示例展示了如何将 filter 应用于包含统计信息的表，‘x > 100’的 filter 会查找(100, ∞) 范围内的值。表中的统计信息显示只有第二列（最小值为 1 和最大值为 209） 的数值范围 [1, 209]，与 filter 的过滤范围重叠。因此，我们可以跳过读取剩余 3 列，从而将数据读取的时间减少3/4 。

Parquet Page Index

Parquet 包含列块和页的统计信息。列块的统计信息显示出该列块中数据的取值范围，而页统计信息显示的是页数据，粒度更细、更有效。下述示例展示了页统计信息与列统计信息相比，如何能更好地降低数据读取量。

在第一个示例中，有一个查询中包含了“x = 2000”的filter条件。为便于演示，我们仅在一个列块中显示三个页。图表中的三个页的统计信息构成了三个范围：[-100, 60]、[50, 234]和[800, 1000] 。列块的统计信息构成 [-100, 1000] 的范围。由于我们正在查找的值为2000 ，因此页统计信息和列块统计信息都显示无需读取该列中的数据。在这种情况下，页统计信息和列块统计信息一样，都有效地减少了数据读取量。

在第二个示例中，列块和页中的数据和统计信息与第一个示例相同。唯一不同的是filter “x = 55”。在这种情况下，由于该值在列块统计范围 [-100, 1000] 内，因此对于读取的判断为“yes”。同样地，第一个页统计范围 [50, 234] 和第二个页统计范围 [-100, 60] 对于读取的判断都为“yes”，但对于最后一个页而言，由于超出了 [800, 1000 ]的范围，因此读取判断为“no”。

在第三个示例中，列块和页中的数据和统计信息依旧与第一个示例相同，但filter更改为’x = 700’。该值在列块统计范围 [-100, 1000]内，因此对于读取的判断为“yes”，但对于所有页统计信息而言，由于所有的范围都不包含要查找的值“700”，因此读取的判断结果为“No”, 跳过整列数据，不予读取。

在所有上述示例中，我们在一个列块中只显示3个页，但实际上一个列块中通常有几十甚至几百个页。因此，在现实操作中能节省更多的成本。如果列数据是经过排序的，那么误报的可能性就会降低，从而使得页统计效果更好。

Presto的页统计

在1.11.0 版本之前，页统计信息都放在页头（page header）中。问题是要获取页统计信息必须读取每一个页。即便之后判定无需读取该页，但该页已经被读取。为了解决该问题，parquet-mr 1.11.0 将列块的所有页统计信息放在同一位置，方便reader可以一次性读取并判定应该读取哪个页。由于 Presto 部分重写了 parquet-mr 代码，我们需要将 Parquet 1.11.0 中的修改移植到 Presto 代码库中。代码修改(PR-17284) 已于 2022 年 2 月合并到 Presto master 分支中，并将在 0.273 版本中发布。

基准测试结果

我们基于需要频繁访问的生产数据表对 Parquet 列索引进行了基准测试。我们用原始生产环境的数据表的快照创建了一个测试表，它包含了若干数据分区，并且数据是经过排序的。之后，我们在测试环境中对表运行 Presto 查询。可以针对每个查询通过 Presto 会话属性设置打开和关闭 Page Index 功能，从而实现横向比较。

我们观察到，输入数据扫描存在巨大的优化空间。下图显示了 Parquet Page Index 启用（左）与禁用（右）时运行示例查询的统计信息。可以看出，他们在这一阶段生成了相同的数据，但是在未启用 Parquet 列索引（column index)时需要扫描 149.31MB/239K 行原始输入数据，而在启用 Parquet 列索引的情况下只需要扫描 63.31MB/75.4K 行原始输入数据。后者的输入读取量降低了57%。这是因为在使用 Parquet Page Index 时，operator 可以识别并跳过不符合过滤条件的页。

除了在原始输入读取量方面的提升外，我们还从测试中观察到内存使用量也有所降低。从下面的截图可以看出，在启用 Parquet Page Index（右）时，只需要使用 91.73MB的峰值内存，而在未启用 Parquet Page Index 时，则需要使用141.60 MB的峰值内存。实现此项提升在预期范围内：由于查询需要读取的原始输入数据更少，因此保存数据所需的内存也更小。

值得注意的是，我们测试用的Presto查询在经过排序的列上使用filter，例如：WHERE foo = bar，其中 foo 列是有序的，这也是 Parquet Page Index 降低读取量效果最显著的地方，如果不对 filter 依赖的列数据进行排序，则收益可能降低。

分享嘉宾：

Uber: Xinli Shang

Uber: Chen Liang

想要了解更多关于Alluxio的干货文章、热门活动、专家分享，可进入【Alluxio智库】：

算力在云端澎湃，云计算技术日新月异。

过去十年间，全球云计算市场快速扩张，市场规模爆发性增长。

中心化的云计算架构提供了集中、大规模的计算、网络和存储等资源，解决了泛互联网行业在前二十年快速发展所面临的业务迅速增长、流量急剧扩张和大规模计算需求等问题。

边缘计算是构筑在边缘基础设施之上，位于尽可能靠近事务和数据源头的网络边缘侧，并能够与中心云协作的云计算模式。

相较于集中式云计算，边缘计算可提供弹性扩展的云服务能力，具有快速响应、低延迟和轻量计算等特点。

产业发展，脉络一览

01 稳定增长，激发市场活力

政策环境不断完善，边缘计算发展，恰逢其时。

2021年，我国边缘计算市场规模达到436.4亿人民币，预计未来三年年均增速超过50%，至2024年边缘计算市场整体规模达1803.7亿，边缘计算市场增长空间广阔。

IDC《中国边缘云市场解读，2022》报告显示，2021年中国边缘云市场规模总计达50.4亿人民币，其中，边缘公有云服务细分市场占比超过50%，市场规模达25.6亿人民币，为整个边缘计算发展注入新活力。

02 欣欣向荣，共建边缘生态

边缘生态包括云厂商、电信运营商、软件／行业解决方案厂商、系统集成商等。

边缘计算产业全景图覆盖边缘硬件、物联网边缘、边缘云、边缘软件与工具、边缘应用和边缘安全等各环节要素，助力边缘业务落地。

其中，边缘云作为关键要素，承下对接物联网硬件等基础设施，向上通过计算服务支撑各行各业应用，起到了非常关键的作用。

03 形态丰富，部署模式呈多样化

随着边缘计算的深入发展，企业的部署模式呈现不同的落地形态：

| 云服务延伸：提供针对特定区域或是广域覆盖的边缘计算资源，包括边缘公有云，CDN边缘云等类型。

| 电信网络：利用运营商网络边缘节点，根据需求建设资源池规模、服务种类差异化网络边缘服务，提供类似MEC多接入服务的边缘计算服务。

| 深入用户现场：在靠近用户数据中心或业务现场的地方，实现按需部署，包括混合边缘云、现场边缘云等类型，支持用户在本地部署自己的边缘云服务，并达到数据合规的要求。

04 持续深化，应用部署加速落地

中国信通院《边缘计算市场和用户洞察报告（2022）》深入研究边缘计算在企业用户中的落地现状及未来规划，为产业未来发展提供实践参考和指引。以下数据源自其中，依次展开分析。

| 在边缘部署类型方面，企业客户采用私有化边缘云解决方案和边缘公有云服务的占比较高，分别为59.4%和52.8%，其次是IoT边缘计算和边缘软件解决方案，分别占比48.1%和32.5%。

边缘部署的类型占比

| 在技术应用方面，受访者企业中，边缘数据处理和分析、边缘虚拟化、边缘存储和边缘网络等技术应用较为广泛，占比均超过50%，同时，开发框架、AI、安全、中间价和容器等技术，在边缘的应用仍待进一步发展。

边缘计算的技术应用占比

| 在落地场景方面，数据采集、视频监控、物联感知、远程控制等是目前边缘计算落地应用相对比较广的场景，其中数据采集场景应用占比高达69.3%，其次是视频监控和物联感知，分别为57.1%和50.9%。

而远程医疗、视觉质检、云游戏、边缘渲染、低延时直播等场景应用在受访企业中占比不足20%，未来，仍有更多创新落地的空间。

边缘计算的落地场景占比

05 挑战VS机遇，规划引领发展方向

| 在效益提升方面，提升业务的敏捷部署，在边缘计算应用价值中至关重要，占比高达68.4%。

对于一些大型政企客户来说，相比于集中式的数据中心和云上部署，部署边缘云能够更好地实现业务敏捷部署，从而真正为业务带来新价值。

在企业调研中，降低计算时延、节约带宽成本、加强数据安全均成为企业部署边缘计算之后带来的显著成效，占比分别为63.7%，56.1%和49.5%，极大提升了业务效益和价值。

边缘部署的效益占比

| 在部署挑战方面，边缘系统管理复杂、维护系统可靠性和稳定性、成本等因素成为边缘云部署的主要挑战，在受访企业中占比分别为61.3%、60.8%和53.3%。

同时，部署边缘系统困难、无明显业务需求和具有安全风险，也为企业的边缘计算布局带来阻碍，亟待边缘计算技术的发展而解决。

边缘部署的挑战占比

| 在投入规划方面，企业加大对边缘部署的投入规模，边缘计算相关云服务、软件及解决方案、硬件设备等成为企业投入规划的TOP3，在受访企业中占比高达65.9%、60.3%和52.7%，边缘计算发展前景广阔。

边缘部署的投入规划占比

架构升级，极致演进

以下为边缘计算领域最受关注的五项技术架构，为用户在边缘计算模型的选型与开发提供参考。

01 分布式资源管理：协同统一管控

阿里云通过纳管分布广泛、资源异构、规模多样的边缘节点，实现全球范围内边缘云分布式资源统一视角管理使用、监控运维。

边缘管控需要适度自治能力。

根据阿里云与中国信通院最新联合发布的《边缘云技术演进与发展白皮书》，边缘云分布式管控系统是一对多的分级管控模型，各级管控平台需具备满足自身定位的管控能力。

边缘云分布式管控系统与中心管控系统协同完成管控逻辑，更加适配边缘计算场景。

02 分布式数据管理：释放要素价值

如何在边缘侧进行云边协同的数据管控，是保证业务流通的重要技术点。

边缘云分布式数据管理，通过构建数据采集、处理、汇聚、分析、存储、管理等全环节能力，实现业务生产、应用数据，经营、运营管理数据，第三方数据的统一汇聚和分析，发挥数据要素价值。

| 在终端侧，通过传感器、物联设备实现业务应用数据源全面感知采集；

| 在边缘侧，实现异构数据接入、实时处理、边缘存储、数据转发；

| 在中心云，构建统一数据汇聚集成、大规模存储、智能分析等协同体系，有效提升数据应用水平和能力。

03 分布式应用平台：构建敏捷弹性应用

分布式应用平台将云上的开发方式部署至边缘侧，通过跨边缘节点的应用统一开发、部署、调度、管理、运维等能力，加速构建云边协同下弹性敏捷的边缘原生应用。

| 应用部署：实现应用按需分布式部署；

| 多集群管理：通过集群安全连接，统一管理；

| 分布式应用管理：通过部署策略（地理亲和性、反亲和性等），调度策略（资源池、健康状态等），镜像加速（缓存、P2P等），数据迁移等，实现跨云边端集群的应用统一管理；

| 服务流量治理：通过云边、边边容器网络互通，服务智能路由（位置、时延、网络质量等），流量管理（流量切换、限流、降级、负载均衡等），实现服务统一治理。

04 分布式调度：实现体验、资源最优平衡

如何实现业务体验与资源利用的最优平衡？

边缘云分布式调度技术，从资源调度、流量调度以及应用调度等多个维度，统一全局调度管理，以云边端协同的方式满足业务调度需求，最大化提升业务体验，提高资源使用效率。

| 资源调度：构建全局资源监测和伸缩能力，实现资源监测、弹性伸缩；通过调度算法和策略，优化资源使用、时延、位置、成本等指标，实现资源智能化调度；

| 流量调度：结合业务特点，预先进行业务流量预测，对云边计算、网络带宽等进行拆分和规划（例如建立专用通道）；针对流量接入、回源等方面需求，结合位置、成本等因素，实现流量动态接入和调节；

| 应用调度：通过感知业务特定需求（资源硬件、性能指标等），建立应用模型和资源模型，实现应用迁移、弹性扩展等。

05 安全统一能力：构筑立体化安全防护能力

在分布式的环境下，边缘安全面临全新挑战。

边缘安全行业标准

与集中式云资源相比，边缘节点部署环境复杂多样，并且单个边缘节点受限于资源和成本，安全部署能力较弱。

通过云边端协同安全，实现边缘侧设备的接入，数据的传输，网络的安全，以及和中心云进行统一的安全管控，构筑边缘侧的立体化安全防护能力。

场景拓展，应用创新

边缘计算应用场景不断拓展，云边协同的创新实践案例纷纷涌现。

目前，边缘计算已经在工业、制造、物流、能源、金融、视频、零售等行业应用落地，并取得显著成效，加速各行各业数字化转型。

多维发展，畅想未来

在技术架构方面，边缘原生理念兴起，通过资源管控、数据管理、调度、应用平台等边缘原生技术，推动整体架构升级和边缘应用落地。

在行业应用方面，边缘计算和各行各业进一步紧密融合，推动应用场景的不断拓展，助力企业提升业务价值和用户体验。

在生态融合方面，边缘侧的开源协同不断深化，通过与已有系统的融合，迎接边缘侧异构的新挑战，加速构建丰沛繁荣的边缘生态。

未来，边缘计算创新升级将会带动更多便捷服务和应用实践的落地，进一步推动边缘计算产业的繁荣兴旺发展。

画流程图一直是研发的一个难题，如何画得通俗易懂已经够让人头疼了，还要美观大方。用 d2 的语法描述下流程，d2 会自动帮你生成一张配色极佳的流程图。说到研发的选择，本周特推的 choiceof.dev 罗列了众多开发过程中会遇到的选项，你可以自测下你同主流研发的契合度。

本周周榜呢，有监控网络流量的 sniffnet，监控 API 流量的 kubeshark，还有以便不时之需的开发小抄 cheat.sh，记录日常事项的备忘录 memos 和音频转文字工具 buzz。

以下内容摘录自微博@HelloGitHub 的 GitHub Trending 及 Hacker News 热帖（简称 HN 热帖），选项标准： | | ，根据项目 release 时间分类，发布时间不超过 14 day 的项目会标注 ，无该标志则说明项目 release 超过半月。由于本文篇幅有限，还有部分项目未能在本文展示，望周知 🌝

• 本文目录
  • 1. 本周特推
    • 1.1 文本变图表：d2
    • 1.2 艰难选择：choiceof.dev
  • 2. GitHub Trending 周榜
    • 2.1 轻松监控网络流量：sniffnet
    • 2.2 音频转文本：buzz
    • 2.3 高颜值备忘录：memos
    • 2.4 研发小抄：cheat.sh
    • 2.5 API 流量查看器：kubeshark
  • 3. 往期回顾

1. 本周特推

1.1 文本变图表：d2

主语言：Go

本周刚开源并突破 5k star 关卡的“爆款”项目，只要用文本就可以生成对应的图表。比如下面这段语法讲得到一个流程图。

GitHub 地址→https://github.com/terrastruct/d2

1.2 艰难选择：choiceof.dev

主语言：TypeScript

开发人员日常面对着非常艰难的选择，可能就是技术选型，当然也可能是简单的如何提交代码。choiceof.dev 给出了形形色色同开发相关的选项，有复杂的也有简单的。比如，下图如何提交代码，强制提交的占了 64%。

GitHub 地址→https://github.com/bdebon/choiceof.dev

2. GitHub Trending 周榜

2.1 轻松监控网络流量：sniffnet

本周 star 增长数：900+，主语言：Rust

一个跨平台的网络流量监控工具，可快速、直观查看流量变化。

GitHub 地址→https://github.com/GyulyVGC/sniffnet

2.2 音频转文本：buzz

本周 star 增长数：550+，主语言：Python

转换音频为文本的工具，支持麦克风实时录入转文字，也支持导入已有音频文件。文本可以导出为 TXT、SRT、VTT 格式。

GitHub 地址→https://github.com/chidiwilliams/buzz

2.3 高颜值备忘录：memos

本周 star 增长数：1,850+，主语言：TypeScript

具备知识管理能力的备忘中心，可多人协作。特性：

• 支持自托管，秒拉起来一个 Docker 应用；
• 支持 Markdown 语法；
• 同组内成员协作；
• 自服务的 RESTful API；

GitHub 地址→https://github.com/usememos/memos

2.4 研发小抄：cheat.sh

本周 star 增长数：1,350+，主语言：Python

非必要不小抄，cheat.sh 具有理想小抄的一切特性：简洁、快速、全面、低调、可辅助学习。它能在 100ms 内搜刮完 Stack Overflow 等网站，并返回你所需要的答案。支持 curl / 浏览器 / 编辑器交互。

GitHub 地址→https://github.com/chubin/cheat.sh

2.5 API 流量查看器：kubeshark

本周 star 增长数：900+，主语言：Golang

作为 K8s 的 API 流量查看器，kubeshark 支持对 K8s 所有集群的 API 流量和负载进行监控。

GitHub 地址→https://github.com/kubeshark/kubeshark

3. 往期回顾

往期回顾：

• 视觉享受，兼顾人文观感和几何特征的字体「GitHub 热点速览 v.22.46」
• 一年一度！GitHub 开发者大会「GitHub 热点速递 v.22.45」

以上为 2022 年第 47 个工作周的 GitHub Trending 🎉如果你 Pick 其他好玩、实用的 GitHub 项目，记得来 HelloGitHub issue 区和我们分享下哟 🌝

更新日志 

1. 用户增加区县字段、会员码
2. 展示型商品不校验库存
3. 系统更新必须先更新待更新的插件
4. 购物车汇总优化
5. 拖拽可视化新增[图文、图片魔方、自定义html]模块，商品支持左图右文样式
6. 后台管理操作栏优化、减少上下占据空间
7. 门店详情支持多规格直接加购
8. 分类页面支持多规格直接加购+购物车操作
9. 新增[主导航、logo及搜索栏、页脚]展示开关
10. 新增钱包付款码
11. 新增账号注销
12. 新增base64类库
13. 新增input、select清除操作
14. 小程序新增个人资料修改
15. 小程序新增手机号码修改
16. 小程序购物车分离优化
17. 微信小程序登录适配新规
18. 可视化数据展示新增缓存
19. web端首页轮播样式优化
20. 用户头像上传新增钩子
21. 分页统计优化避免sql浪费
22. 动态数据列表分页支持统计汇总
23. 底层框架升级到tp6.1

进销存效果图片（支持多商户使用）

门店收银台效果图片（O2O多门店）

小程序端效果图片（内置多种配色）

可视化 DIY 拖拽装修展示

PC 端展示

后台管理展示

关注公众号

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

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

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

我们很高兴地告诉大家，EMQX Enterprise 4.4.11 版本正式发布！

在此版本中，我们发布了 CRL 与 OCSP Stapling 为客户端提供更灵活的安全防护，新增了 Google Cloud Pub/Sub 集成帮助您通过 Google Cloud 各类服务发掘更多物联网数据价值，还加入了满足自动化运维需要的预定义 API 密钥功能。除此之外，我们还修复了多项 BUG。

CRL 与 OCSP Stapling

此前版本中，通过 EMQX 内置的 SSL/TLS 支持，您可以使用 X.509 证书实现客户端接入认证与通信安全加密，本次发布的版本在此基础上新增了 CRL 与 OCSP Stapling 功能。

持有数字证书的物联网设备，如果出现私钥泄漏、证书信息有误的情况，或者设备需要永久销毁时，需要吊销对应证书以确保不被非法利用，CRL 与 OCSP Stapling 就是解决这一问题的关键。

CRL（Certificate Revocation List，证书吊销列表） 是由 CA 机构维护的一个列表，列表中包含已经被吊销的证书序列号和吊销时间。EMQX 允许配置 CA 的请求端点并定时刷新获取 CRL，而客户端无需维护 CRL，在连接握手时通过 EMQX 即可完成证书有效性验证。

OCSP（Online Certificate Status Protocol，在线证书状态协议）是另外一个证书吊销方案，相比于 CRL， OCSP 提供了实时的证书验证能力。OCSP Stapling 是该项技术的最新改进，进一步解决了 OCSP 隐私问题和性能问题。

启用 OCSP Stapling 后，EMQX 将自行从 OCSP 服务器查询证书并缓存响应结果，当客户端向 EMQX 发起 SSL 握手请求时，EMQX 将证书的 OCSP 信息随证书链一同发送给客户端，由客户端对证书有效性进行验证。

通过 CRL 与 OCSP Stapling 功能，您可以控制每一张证书的有效性，及时吊销非法客户端证书，为您的物联网应用提供灵活且高级别的安全保障。

Google Cloud Pub/Sub 集成

Google Cloud Pub/Sub 是一种异步消息传递服务，旨在实现极高的可靠性和可扩缩性。

现在，您可以通过 EMQX 规则引擎的 GCP Pub/Sub 集成能力，快速建立与该服务的连接，这能够帮助您更快的基于 GCP 构建物联网应用：

• 使用 Google 的流式分析处理物联网数据：以 Pub/Sub 以及 Dataflow 和 BigQuery 为基础而构建整体解决方案，实时提取、处理和分析源源不断的 MQTT 数据，基于物联网数据发掘更多业务价值。

• 异步微服务集成：将 Pub/Sub 作为消息传递中间件，通过 pull 的方式与后台业务集成；也可以推送订阅到 Google Cloud 各类服务如 Cloud Functions、App Engine、Cloud Run 或者 Kubernetes Engine 或 Compute Engine 上的自定义环境中。

对于 Google IoT Core 用户，您无需做更多改变就能将 MQTT 传输层迁移至 EMQX，继续使用 Google Cloud 上的应用和服务。

通过文件初始化 API 密钥

本次发布提供了 API 密钥初始化能力，允许您在启动 EMQX 前通过特定文件设置密钥对。

预设的密钥可以帮助用户在 EMQX 启动时做一些工作：如运维人员编写运维脚本管理集群状态，开发者导入认证数据到内置数据库中、初始化自定义的配置参数。

EMQX Kubernetes Operator 也基于此特性来实现集群启动时的配置和管理操作。

 # 指定 bootstrap 文件 # etc/plugins/emqx_management.conf management.bootstrap_user_file ="etc/bootstrap_apps_file.txt" ​ # 使用 {appid}:{secret} 的格式初始化密钥对 # etc/bootstrap_apps_file.txt appid1:secret appid2:secret2

BUG 修复

以下是主要 BUG 修复，完整 BUG 修复列表请参考 EMQX 企业版 4.4.11 更新日志。

• 改进规则的 “最大执行速度” 的计数，只保留小数点之后 2 位 #9185。 避免在 dashboard 上展示类似这样的浮点数：。

• 修复在尝试连接 MongoDB 数据库过程中，如果认证失败会不停打印错误日志的问题 #9184。

• 限速 “Pause due to rate limit” 的日志级别从原先的 降级到 #9134。

• 修正了 API 的响应状态代码 #9210。 在修复之前，它总是返回 ，即使 EMQX 应用程序没有运行。 现在它在这种情况下返回 。

• 修复规则引擎的消息事件编码失败 #9226。 带消息的规则引擎事件，例如 和 , 如果消息事件是共享订阅产生的，在编码（到 JSON 格式）过程中会失败。 影响到的版本：, , 和 。

• 修复调用 ‘DELETE /alarms/deactivated’ 只在单个节点上生效的问题，现在将会删除所有节点上的非活跃警告 #9280。

• 在进行消息重发布或桥接消息到其他 MQTT Broker 时，检查 topic 合法性，确定其不带有主题通配符 #9291。

• 关闭管理端口（默认为8081）上对 HTTP API 的认证，Prometheus 对时序数据抓取不在需要配置认证 #9294。

• 修正了在 Kafka Consumer 中选择 偏移重置策略的选项。

• 修复了 SQL Server 资源中，无法在 字段里使用除 之外的端口的问题。

• 解决从 e4.4.5 以及更早的版本升级 EMQX 的时候，Kafka 资源的认证类型从 变成了 的错误。

结语

除了企业版 4.4.11 外，同期 EMQX 还发布了包括开源版在内的另外 3 个版本，请参考：

• EMQX 企业版 4.3.17 更新日志

• EMQX 开源版 4.3.22 更新日志

• EMQX 开源版 4.4.11 更新日志

版权声明： 本文为 EMQ 原创，转载请注明出处。

原文链接：https://www.emqx.com/zh/blog/emqx-enterprise-v-4-4-11-released

前言

上海的天气降温让人猝不及防，但是我们的迭代速度却井然有序。

今天我们带来了LiteFlow v2.9.4版本。

我们每次的发布的issue有很大一部分依托于我们的使用者社区，社区人越来越多。我看到了使用者在使用过程中遇到的问题，也收集了很多使用过程中很有意思的建议。这些也正是我们每一次迭代的方向。谢谢那么多的小伙伴的支持和建议，LiteFlow一直会是一个以社区为驱动的开源框架。

LiteFlow是一个开源编排式规则引擎，能够让你的系统逻辑任意编排，使用脚本书写逻辑，所有的逻辑和规则均可热变更。设计系统和重构系统的神器。

如果你是第一次知道这个项目，可以去官网或相关的主页进行了解：

项目官网:

https://liteflow.yomahub.com

gitee托管仓库：

https://gitee.com/dromara/liteFlow

github托管仓库：

https://github.com/dromara/liteflow

v2.9.4介绍

新版本我们依旧依托于社区，一共完成了14个issue。

其中80%的issue来自于社区使用者。

2.9.4版本完全兼容2.9.3版本，可以无缝升级。

新的脚本引擎

鉴于之前社区有人反应LiteFlow提供的Javascript脚本引擎是基于jdk的，而JDK的Javascript引擎只支持到ES5规范，且不支持Java 17。

所以这次我们新增了一个Javascript引擎：。支持ES6规范，且支持Java 8~17。

当然老的引擎我们还是保留，如果是简单的js语法，你依旧可以用老的引擎。

关于这块详情请参考官网的章节。

提供规则验证接口

虽然LiteFlow在启动时会去编译所有的规则，如果有错也会详细报出，但是在更改脚本前，使用者可能不太确信自己的规则写的有没有问题。所以在社区内，有人提出了希望增加一个验证规则的接口。

那这次我们也提供了相应的接口。详情请参考官网的章节。

Zk和Etcd支持局部刷新机制

如果你使用zk或者Etcd，你在zk和etcd里更改了规则，会自动推送到相应的应用进行无感自动刷新。

但是之前的实现模式是全部刷新，即不管你改了哪个规则，所有的规则刷新一遍。虽然LiteFlow刷新速度非常快速，但是这种实现模式还是不够优雅。

这次我们实现了局部刷新，即你改变哪个即刷新哪个。

声明式组件的二次动态代理问题

在社区内，我们也收到了许多使用声明式组件特性小伙伴们的反馈，在声明式组件上使用类似事务标注等需要动态代理的特性时，LiteFlow的声明式组件会报错。

经过核验，我们发现LiteFlow之前漏考虑了二次动态代理的问题，这次我们修复了。

其他修复

在新版本中，我们修复其他issue也有很多，包括脚本对数据取值的bug，@ScriptBean标注所带来的一些小问题，脚本异常处理的优化等等。

完整更新列表

社区

LiteFlow的社区是一个异常活跃的开源社区，这里有许多的开源大佬，技术大牛，群内的小伙伴也很乐意帮你去回答问题。

如果你在使用和学习中有任何问题，可以通过以下官网或者以下方式进入社区群。

https://liteflow.yomahub.com/pages/73c2c3/

Dante Cloud 是一款企业级微服务架构和服务能力开发平台。首个全面拥抱 Spring Authorization Server 的版本，基于Spring Authorization Server 0.4.0、Spring Boot 2.7.6、Spring Cloud 2021.0.5、Spring Cloud Alibaba 2021.0.4.0、Nacos 2.1.2 等最新版本开发的多租户系统，遵循SpringBoot编程思想，高度模块化和可配置化。具备服务发现、配置、熔断、限流、降级、监控、多级缓存、分布式事务、工作流等功能

平台定位

• 构建成熟的、完善的、全面的，基于 OAuth2.1 的、前后端分离的微服务架构解决方案。
• 面向企业级应用和互联网应用设计开发，既兼顾传统项目的微服务化，又满足互联网应用开发建设、快速迭代的使用需求。
• 平台架构使用微服务领域及周边相关的各类新兴技术或主流技术进行建设，是帮助快速跨越架构技术选型、研究探索阶段的利器。
• 代码简洁规范、结构合理清晰，是新技术开发应用的典型的、综合性案例，助力开发人员对新兴技术的学习和掌握。

[1]、为什么更名为 Dante Cloud

Dante Cloud (但丁)， 原项目名称 Eurynome Cloud，很多朋友都反映名字太长、读起来拗口、不容易记等问题。因此在加入 Dromara 开源社区之际，将名字进行了变更。

Dante，即但丁·阿利基耶里(公1265年-公1321年)，13世纪末意大利诗人，现代意大利语的奠基者，欧洲文艺复兴时代的开拓人物之一，以长诗《神曲》(原名《喜剧》)而闻名，后来一位作家叫薄伽丘将其命名为神圣的喜剧。

他被认为是中古时期意大利文艺复兴中最伟大的诗人，也是西方最杰出的诗人之一，最伟大的作家之一。恩格斯评价说：“封建的中世纪的终结和现代资本主义纪的开端，是以一位大人物为标志的，这位人物就是意大利人但丁，他是中世纪的最后一位诗人，同时又是新时代的最初一位诗人”

更名为 Dante Cloud，寓意本项目会像恩格斯对但丁的评价一样，在行业变革的时期，可以成为一款承上启下，助力企业信息化建设变革的产品。

[2]、本次更新内容

• 主要更新
  • Spring Boot 版本升级至 2.7.6
• 其它更新
  • [修复] 解决使用 edge 浏览器并使用 feign，报错 Unexpected char 0x0a（PR by 狂练胸肌的李大懒）
  • [修复] 修复前端唯一性字段在新建、编辑不同状态下校验不准确、状态不合理问题。解决导致编辑状态下唯一性字段数据未修改仍会校验失败问题。
  • [修复] 优化微服务分布式 Session 共享配置，解决共享 Session 不一致问题。
  • [新增] 数据初始化脚本补充 OIDC 客户端注册相关信息
• 依赖更新
  • [升级] fastjson2 版本升级至 2.0.20
  • [升级] dysmsapi 版本升级至 2.0.23
  • [升级] aliyun-java-sdk-core 版本升级至 4.6.3
  • [升级] tencentcloud-sdk-java-sms 版本升级至 3.1.641
  • [升级] alipay-sdk-java 版本升级至 4.34.71.ALL
  • [升级] aliyun-java-sdk-green 版本升级至 3.6.6
  • [升级] postgresql 版本升级至 42.5.1
  • [升级] jackson 版本升级至 2.14.1

[3]、Dante Cloud 2.7.X 特点

一、前端

1. 未使用任何流行开源模版，使用全新技术栈，完全纯”手写”全新前端工程。
2. 借鉴参考流行开源版本的使用和设计，新版前端界面风格和操作习惯尽量与当前流行方式统一。
3. 充份使用 Typescript 语言特性，解决大量类型校验问题，尽可能规避 “any” 式的 Typescript 编程语言使用方式。
4. 充份使用 Composition Api 和 Hooks 等 Vue3 框架新版特性进行代码编写。
5. 充份利用 Component、Hooks 以及 Typescript 面向对象等特性，抽取通用组件和代码，尽可能降低工程重复代码。
6. 对较多 Quasar 基础组件和应用功能组件进行封装，以方便代码的统一修改维护和开发使用。
7. 对生产模式下，对基于 Vite3 的工程打包进行深度性能优化。
8. 提供以 docker-compose 方式，对工程生产代码进行容器化打包和部署。
9. 支持密码模式、授权码模式、手机短信模式、第三方社会化等多种登录模式。

二、后端

基于 深度定制和扩展:

• 基于 和 实现多租户系统架构， 支持 Database 和 Schema 两种模式。

• 基于 ，重新构建 基础数据存储代码，替代原有 JDBC 数据访问方式，破除 原有数据存储局限，扩展为更符合实际应用的方式和设计。

• 基于 ，在 OAuth 2.1 规范基础之上，增加自定义 (密码)认证模式，以兼容现有基于 OAuth 2 规范的、前后端分离的应用，支持 Refresh Token 的使用。

• 基于 ，在 OAuth 2.1 规范基础之上，增加自定义 (社会化登录)认证模式，支持手机短信验证码、微信小程序、基于JustAuth的第三方应用登录， 支持 Refresh Token 的使用。

• 扩展 默认的 模式，实现 模式支持 Refresh Token 的使用。

• 扩展 默认的 模式，实现真正的使用 Scope 权限对接口进行验证。 增加客户端 Scope 的权限配置功能，并与已有的用户权限体系解耦

• 支持 认证模式

• 支持 的标准的 JWT Token 加密校验方式外，新增基于自定义证书的 JWT Token 加密校验方式，可通过配置动态修改。

• 支持 Opaque Token (不透明令牌) 格式及校验方式，将低 JWT Token 被捕获解析的风险。可通过修改配置参数，设置默认Token 格式是采用 Opaque Token 格式还是 JWT Token 格式。

• 全面支持 OpenID Connect (OIDC) 协议, 系统使用时可根据使用需求，通过前端开关配置，快速切换 OIDC 模式和传统 OAuth2 模式

• 深度扩展 、、 几种模式，全面融合 IdToken、Opaque Token、JWT Token 与现有权限体系，同时提供 IdToken 和 自定义Token 扩展两种无须二次请求的用户信息传递方式，减少用户信息的频繁请求。

• 自定义 授权码模式登录认证页面和授权确认页面，授权码模式登录采用数据加密传输。支持多种验证码类型，暂不支持行为验证码。

• 基于 JetCache 的多级缓存支持，实现自定义 二级缓存，有效解决 Spring Cache 查询缓存更新问题。
• 全面整合 注解权限与 权限，通过后端动态配置，无须在代码中配置 权限注解以及权限方法，即可实现接口鉴权以及权限的动态修改。采用分布式鉴权方案，规避 Gateway 统一鉴权的压力以及重复鉴权问题
• 采用分布式服务独立鉴权方案， 的权限注解、权限方法以及 权限，通过后端动态配置后，实时动态分发至对应服务。
• 核心数据支持直连数据库获取和 远程调用两种模式。 直连数据库模式性能更优， 访问远程调用可扩展性更强。可通过配置动态修改采用策略方式。
• 基于自定义 Session，混合国密 SM2(非对称) 和 SM4(对称加密) 算法，实现秘钥动态生成加密传输。利用“一人一码机制”，实现密码模式登录数据进行动态加密传输。配合 验证，保护接口调用和前后端数据传输的合理性及安全性。

[4]、界面预览

Dromara 开源社区

一、社区愿景

让每一位开源爱好者，体会到开源的快乐。

二、社区官网

https://dromara.org 是 Dromara 开源社区官方网站。

三、成员项目

功能介绍 使用技术 特性注意事项 微服务权限管理系统 RuoYi-Cloud-Plus 重写 RuoYi-Cloud 全方位升级(不兼容原框架) 分布式集群分支 RuoYi-Vue-Plus 重写 RuoYi-Vue (不兼容原框架) 前端开发框架 Vue、Element UI   后端开发框架 SpringBoot   微服务开发框架 SpringCloud   微服务开发框架 SpringCloudAlibaba   容器框架 Undertow 基于 XNIO 的高性能容器 权限认证框架 Sa-Token、Jwt 强解耦、强扩展 关系数据库 MySQL 适配 8.X 最低 5.7 关系数据库(未完成) Oracle 适配 12c 关系数据库(未完成) PostgreSQL 适配 14 关系数据库(未完成) SQLServer 适配 2019 缓存数据库 Redis 适配 6.X 最低 5.X 分布式注册中心 Alibaba Nacos 采用2.X 基于GRPC通信高性能 分布式配置中心 Alibaba Nacos 采用2.X 基于GRPC通信高性能 服务网关 SpringCloud Gateway 响应式高性能网关 负载均衡 SpringCloud Loadbalancer 负载均衡处理 RPC远程调用 Apache Dubbo 原生态使用体验、高性能 分布式限流熔断 Alibaba Sentinel 无侵入、高扩展 分布式事务 Alibaba Seata 无侵入、高扩展 支持 四种模式 分布式消息队列 SpringCloud Stream 门面框架兼容各种MQ集成 分布式消息队列 Apache Kafka 高性能高速度 分布式消息队列 Apache RocketMQ 高可用功能多样 分布式消息队列 RabbitMQ 支持各种扩展插件功能多样性 分布式搜索引擎 ElasticSearch、Easy-Es 以 Mybatis-Plus 方式操作 ElasticSearch 分布式数据同步(未完成) Alibaba Canal 采集数据同步各种数据库 ES Redis Mysql 分布式链路追踪 Apache SkyWalking 链路追踪、网格分析、度量聚合、可视化 分布式日志中心 ELK ELK业界成熟解决方案 分布式锁 Lock4j 注解锁、工具锁 多种多样 分布式幂等 Redisson 拦截重复提交 分布式任务调度 Xxl-Job 高性能 高可靠 易扩展 分布式文件存储 Minio 本地存储 分布式云存储 七牛、阿里、腾讯 云存储 短信模块 阿里、腾讯 短信发送 分布式监控 Prometheus、Grafana 全方位性能监控 服务监控 SpringBoot-Admin 全方位服务监控 数据库框架 Mybatis-Plus 快速 CRUD 增加开发效率 数据库框架 P6spy 更强劲的 SQL 分析 多数据源框架 Dynamic-Datasource 支持主从与多种类数据库异构 序列化框架 Jackson 统一使用 jackson 高效可靠 Redis客户端 Redisson 支持单机、集群配置 校验框架 Validation 增强接口安全性、严谨性 支持国际化 Excel框架 Alibaba EasyExcel 性能优异 扩展性强 文档框架 SpringDoc、javadoc 无注解零入侵基于java注释 工具类框架 Hutool、Lombok 减少代码冗余 增加安全性 代码生成器 适配MP、Knife4j规范化代码 一键生成前后端代码 部署方式 Docker 容器编排 一键部署业务集群 国际化 SpringMessage Spring标准国际化方案

漏洞描述

Solarwinds Orion Platform是美国Solarwinds公司的一套网络故障和网络性能管理平台。

SolarWinds Platform < 2022.4 容易受到命令注入的影响。此漏洞允许完全控制SolarWinds数据库的远程攻击者执行任意操作系统命令。

影响范围

SolarWinds Platform@[0, 2022.4)

修复方案

将组件 SolarWinds Platform 升级至 2022.4 及以上版本

参考链接

https://www.oscs1024.com/hd/MPS-2022-52648

https://nvd.nist.gov/vuln/detail/CVE-2022-36962

情报订阅

OSCS(开源软件供应链安全社区)通过最快、最全的方式，发布开源项目最新的安全风险动态，包括开源组件安全漏洞、事件等信息。同时提供漏洞、投毒情报的免费订阅服务，社区用户可通过配置飞书、钉钉、企业微信机器人，及时获得一手情报信息推送：

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

漏洞描述

QEMU 是一个通用的开源机器和用户空间模拟器和虚拟器，Error Record Serialization Table (ERST) 模块用于将错误记录存储在持久存储器中，便于引用和调试。

QEMU 7.1.0 及之前版本中 erst.c 类中的 read_erst_record() 和 write_erst_record() 函数中存在整数溢出和缓冲区溢出漏洞，由于 ERST 的缓冲区大小在创建 acpi-erst 设备时以前通过 size 参数固定，攻击者可通过控制客户机传输的错误记录大小（record_length）造成缓冲区溢出，从而使 QEMU 进程崩溃。

影响范围

qemu-project/qemu@(-∞, 7.1.0]

修复方案

qemu-project/qemu 暂未发布新版本，请关注官方公告：https://gitlab.com/qemu-project/qemu

参考链接

https://www.oscs1024.com/hd/MPS-2022-65681

https://nvd.nist.gov/vuln/detail/CVE-2022-4172

https://gitlab.com/qemu-project/qemu/-/issues/1268

https://gitlab.com/qemu-project/qemu/-/commit/defb7098

情报订阅

OSCS(开源软件供应链安全社区)通过最快、最全的方式，发布开源项目最新的安全风险动态，包括开源组件安全漏洞、事件等信息。同时提供漏洞、投毒情报的免费订阅服务，社区用户可通过配置飞书、钉钉、企业微信机器人，及时获得一手情报信息推送：

https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见：

https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

引言

尽管 redis 是一款非常优秀的 NoSQL 数据库，但更重要的是，作为使用者我们应该学会在不同的场景中如何更好的使用它，更大的发挥它的价值。主要可以从这四个方面进行优化：Redis键值设计、批处理优化、服务端优化、集群配置优化

1. Redis慢查询日志使用

Redis 提供了慢日志命令的统计功能，它记录了有哪些命令在执行时耗时比较久。

查看 Redis 慢日志之前，你需要设置慢日志的阈值。例如，设置慢日志的阈值为 5 毫秒，并且保留最近 500 条慢日志记录：

设置完成之后，所有执行的命令如果操作耗时超过了 5 毫秒，都会被 Redis 记录下来。

此时，你可以执行以下命令，就可以查询到最近记录的慢日志：

• slowlog len：查询慢查询日志长度
• slowlog get [n]：读取n条慢查询日志
• slowlog reset：清空慢查询列表

有可能会导致操作延迟的情况：

• 经常使用 O(N) 以上复杂度的命令，例如 SORT、SUNION、ZUNIONSTORE 聚合类命令，要花费更多的 CPU 资源
• 使用 O(N) 复杂度的命令，但 N 的值非常大，Redis 一次需要返回给客户端的数据过多，更多时间花费在数据协议的组装和网络传输过程中。

你可以使用以下方法优化你的业务：

• 尽量不使用 O(N) 以上复杂度过高的命令，对于数据的聚合操作，放在客户端做
• 执行 O(N) 命令，保证 N 尽量的小（推荐 N <= 300），每次获取尽量少的数据，让 Redis 可以及时处理返回

2. Redis键值设计

2.1 优雅的key结构

Redis的Key虽然可以自定义，但最好遵循下面的几个最佳实践约定：

• 遵循基本格式：[业务名称]:[数据名]:[id]
• 长度不超过44字节
• 不包含特殊字符

例如：我们的登录业务，保存用户信息，其key可以设计成如下格式：

这样设计的好处：

• 可读性强
• 避免key冲突
• 方便管理
• 更节省内存： key是string类型，底层编码包含int、embstr和raw三种。embstr在小于44字节使用，采用连续内存空间，内存占用更小。当字节数大于44字节时，会转为raw模式存储，在raw模式下，内存空间不是连续的，而是采用一个指针指向了另外一段内存空间，在这段空间里存储SDS内容，这样空间不连续，访问的时候性能也就会收到影响，还有可能产生内存碎片

2.2 拒绝BigKey

2.2.1 什么是BigKey

如果一个 key 写入的 value 非常大，那么 Redis 在分配内存时就会比较耗时。同样的，当删除这个 key 时，释放内存也会比较耗时，这种类型的 key 我们一般称之为 bigkey。

BigKey 通常以 Key 的大小和 Key 中成员的数量来综合判定，例如：

• Key 本身的数据量过大：一个 String 类型的 Key ，它的值为 5 MB
• Key 中的成员数过多：一个 ZSET 类型的 Key ，它的成员数量为 10,000 个
• Key 中成员的数据量过大：一个 Hash 类型的 Key ，它的成员数量虽然只有 1,000 个但这些成员的 Value（值）总大小为 100 MB

那么如何判断素的大小呢？redis 也给我们提供了命令

推荐值：

• 单个 key 的 value 小于 10KB
• 对于集合类型的 key，建议素数量小于 1000

2.2.2 BigKey 的危害

• 网络阻塞

  对 BigKey 执行读请求时，少量的 QPS 就可能导致带宽使用率被占满，导致 Redis 实例，乃至所在物理机变慢

• 数据倾斜

  BigKey 所在的 Redis 实例内存使用率远超其他实例，无法使数据分片的内存资源达到均衡

• Redis 阻塞

  对素较多的 hash、list、zset 等做运算会耗时较旧，使主线程被阻塞

• CPU 压力

  对 BigKey 的数据序列化和反序列化会导致 CPU 的使用率飙升，影响 Redis 实例和本机其它应用

2.2.3 如何发现BigKey

利用 redis-cli 提供的–bigkeys 参数，可以遍历分析所有 key，并返回 Key 的整体统计信息与每个数据类型的 Top1 的 big key

这个命令的原理，就是 Redis 在内部执行了 SCAN 命令，遍历整个实例中所有的 key，然后针对 key 的类型，分别执行 STRLEN、LLEN、HLEN、SCARD、ZCARD 命令，来获取 String 类型的长度、容器类型（List、Hash、Set、ZSet）的素个数。

这里需要提醒你的是，当执行这个命令时，要注意 2 个问题：

• 对线上实例进行 bigkey 扫描时，Redis 的 OPS 会突增，为了降低扫描过程中对 Redis 的影响，最好控制一下扫描的频率，指定 -i 参数即可，它表示扫描过程中每次扫描后休息的时间间隔，单位是秒
• 扫描结果中，对于容器类型（List、Hash、Set、ZSet）的 key，只能扫描出素最多的 key。但一个 key 的素多，不一定表示占用内存也多，你还需要根据业务情况，进一步评估内存占用情况

自己编程，利用 scan 扫描 Redis 中的所有 key，利用 strlen、hlen 等命令判断 key 的长度（此处不建议使用 MEMORY USAGE）

scan 命令调用完后每次会返回 2 个素，第一个是下一次迭代的光标，第一次光标会设置为 0，当最后一次 scan 返回的光标等于 0 时，表示整个 scan 遍历结束了，第二个返回的是 List，一个匹配的 key 的数组

第三方工具

• 利用第三方工具，如 Redis-Rdb-Tools 分析 RDB 快照文件，全面分析内存使用情况
• https://github.com/sripathikrishnan/redis-rdb-tools

网络监控

• 自定义工具，监控进出 Redis 的网络数据，超出预警值时主动告警
• 一般阿里云搭建的云服务器就有相关监控页面

2.2.4 BigKey 解决方案

这里有两点可以优化：

• 业务应用尽量避免写入 bigkey
• 如果你使用的 Redis 是 4.0 以上版本，用 UNLINK 命令替代 DEL，此命令可以把释放 key 内存的操作，放到后台线程中去执行，从而降低对 Redis 的影响
• 如果你使用的 Redis 是 6.0 以上版本，可以开启 lazy-free 机制（），在执行 DEL 命令时，释放内存也会放到后台线程中执行

bigkey 在很多场景下，都会产生性能问题。例如，bigkey 在分片集群模式下，对于数据的迁移也会有性能影响，以及我后面即将讲到的数据过期、数据淘汰、透明大页，都会受到 bigkey 的影响。因此，即使 reids6.0 以后，仍然不建议使用 BigKey

2.3 总结

• Key 的最佳实践
  • 固定格式：[业务名]:[数据名]:[id]
  • 足够简短：不超过 44 字节
  • 不包含特殊字符
• Value 的最佳实践：
  • 合理的拆分数据，拒绝 BigKey
  • 选择合适数据结构
  • Hash 结构的 entry 数量不要超过 1000
  • 设置合理的超时时间

3. 批处理优化

3.1 Pipeline

3.1.1 客户端与服务端交互

单个命令的执行流程

N 条命令的执行流程

redis 处理指令是很快的，主要花费的时候在于网络传输。于是乎很容易想到将多条指令批量的传输给 redis

3.1.2 MSet

Redis 提供了很多 Mxxx 这样的命令，可以实现批量插入数据，例如：

• mset
• hmset

利用 mset 批量插入 10 万条数据

3.1.3 Pipeline

MSET 虽然可以批处理，但是却只能操作部分数据类型，因此如果有对复杂数据类型的批处理需要，建议使用 Pipeline

3.2 集群下的批处理

如 MSET 或 Pipeline 这样的批处理需要在一次请求中携带多条命令，而此时如果 Redis 是一个集群，那批处理命令的多个 key 必须落在一个插槽中，否则就会导致执行失败。大家可以想一想这样的要求其实很难实现，因为我们在批处理时，可能一次要插入很多条数据，这些数据很有可能不会都落在相同的节点上，这就会导致报错了

这个时候，我们可以找到 4 种解决方案

• 第一种方案：串行执行，所以这种方式没有什么意义，当然，执行起来就很简单了，缺点就是耗时过久。

• 第二种方案：串行 slot，简单来说，就是执行前，客户端先计算一下对应的 key 的 slot ，一样 slot 的 key 就放到一个组里边，不同的，就放到不同的组里边，然后对每个组执行 pipeline 的批处理，他就能串行执行各个组的命令，这种做法比第一种方法耗时要少，但是缺点呢，相对来说复杂一点，所以这种方案还需要优化一下

• 第三种方案：并行 slot，相较于第二种方案，在分组完成后串行执行，第三种方案，就变成了并行执行各个命令，所以他的耗时就非常短，但是实现呢，也更加复杂。

• 第四种：hash_tag，redis 计算 key 的 slot 的时候，其实是根据 key 的有效部分来计算的，通过这种方式就能一次处理所有的 key，这种方式耗时最短，实现也简单，但是如果通过操作 key 的有效部分，那么就会导致所有的 key 都落在一个节点上，产生数据倾斜的问题，所以我们推荐使用第三种方式。

3.2.1 串行化执行代码实践

3.2.2 Spring 集群环境下批处理代码

本文由教研团队发布。

如果本文对您有帮助，欢迎和；如果您有任何建议也可或，您的支持是我坚持创作的动力。

转载请注明出处！

大数据
架构向云原生演进是行业的
重要
趋势，
火山引擎
协助关键金融客户在大数据
云原生方向进行了深度实践，形成了整体解决方案，本文将分享火山引擎云原生大数据在金融行业的实践。

▌金融行业大数据需求

云原生相比 Hadoop 的优势

• 强制的容器化能力
  ：
  可以屏蔽
  大数据
  作业的运行环境，提高运行时
  隔离
  能力；

• 可定制化的网络/存储
  能力：
  可以
  支持
  大数据
  作业
  使用复杂
  的
  容器化网络技术，以及
  云原生
  支持的任意存储
  系统
  ；

• 便捷的运维能力
  ：
  可以轻松地进行
  节点
  上下线，
  集群
  扩缩容，降低
  基础设施
  运维成本。

• 在线资源和大数据资源可以高效、灵活地相互转换

• 整个集群的利用率可充分地提升，降本增效

• 资源共池，统一的配额管控、机器运维、软件部署等，降低维护成本。

大数据迁移云原生的难点

• 一个运行在
  Hadoop
  系统上的传统
  大数据
  作业迁移到
  云原生
  系统，
  具有一定的改造成本；而一个大数据集群通常存在数百个、数千个，甚至数万个、数十万个作业，全部迁移到云原生系统上，改造成本巨大，难以实现
  ；

• 传统的
  大数据
  引擎
  ，比如
  Flink
  、
  Spark
  ，最初
  不是针对
  云原生
  系统
  设计，
  其
  AM-Task 作业形态难以
  直接在
  云原生
  系统上
  部署；

• 云原生
  系统的原生调度器
  不具备与
  Hadoop YARN
  
  队列
  类似的多租户资源管控能力；

• 云原生
  系统的
  原生调度器不存在“作业”概念，不具备作业排队能力，不具备作业级调度策略；

• 云原生
  系统的原生
  调度器吞吐能力
  差，不适用于任务量大且运行时间较短的
  大数据
  作业
  ，比如一个
  只需要运行 1 分钟的
  
  Spark
  作业，
  在
  调度
  阶段就花费
  三分钟，不仅
  使作业完成时间大幅增加，
  还
  造成了集群
  资源浪费
  ；

▌云原生大数据部署

• 基于
  Serverless YARN
  的
  Hadoop
  方式
  部署

• 基于
  Arcee
  Operator 的
  云原生
  方式
  部署

基于云原生的 YARN 解决方案 —— Serverless YARN

1. 用户
   在
   计算引擎
   的基础上进行开发
   ，调用 YarnClient
   SDK
   ，提交作业到
   Serverless YARN
   的 Resource Manager 组件
   ；

1. RM 组件为作业创建 AM
   Pod
   （每个作业有一个 Master 实例，负责管控整个作业，
   全
   称为 Application
   
   Master）
   ；

1. AM
   Pod
   经过
   K8s
   的
   API
   Server 和调度器调度到一个具体
   的
   节点
   ，然后由节点上的
   Kubelet
   负责启动和管控；

1. A
   M
   启动后定期向 RM 发送心跳，
   心跳信息包括自身
   运行状态
   ，以及
   资源
   申请
   请求
   ；

1. AM 向 RM 申请更多资源，RM 将这些资源请求转换为
   K8s
   上的
   Pod
   ，由 K8s 负责调度和启动；

1. 作业的其他 Pod 启动，开始实际计算，受 AM 管控。

• 提供
  为作业
  提前
  下载 Jar 包的功能（在
  大数据
  体系中称为 Localization）
  ；

• 启动
  计算引擎的
  Shuffle
  服务
  ；

• 为
  大数据
  作业提供
  日志
  服务
  ；

• 为
  大数据
  作业提供
  监控
  能力
  ，等
  等。

基于云原生的大数据统一 Operator —— Arcee Operator

• Arcee
  定义了统一作业实例
  ：
  Arcee Operator 利用
  K8s
  的自定义资源定义了统一作业实例，无论是
  Spark
  还是
  Flink
  ，
  或者使
  其他类
  YARN
  的
  计算引擎
  ，都
  可以
  使用统一的
  CRD
  描述作业
  ，包括作业配置、作业
  规格
  等信息
  ，而且可以收集
  并展示作业的统一且
  详细
  的
  运行状态，有利于业务的统一表达和处理；

• Arcee
  实现了作业异常处理
  ：Arcee Operator 可以
  实时监控所有作业状态，
  处理作业异常
  ，持续保障作业正常运行；
  比如因为节点磁盘故障而导致 AM 运行异常，Arcee 检测到后在其他节点重新启动 AM，并接管之前启动的 Work
  Pod
  ，使作业恢复正常运行；

• Arcee
  屏蔽了底层调度器
  ：Arcee Operator
  封装
  了
  底层调度功能，降低
  了
  作业使用高级调度策略的门槛
  ，比如优先级调度、Gang 调度等
  大数据
  作业的强需求；并且可以从调度器上收集作业调度信息，然后对外展示，用户可以轻松知道“作业为什么没有进行调度”。

• Spark
  社区推荐
  的
  
  K8s
  Native 方式，Spark
  Pod
  没有统一资源描述，很难进行管理和描述
  ；

• Google
  的
  Spark
  Operator 在
  K8s
  Native
  方式的
  基础上封装了
  CRD
  ，提供
  了
  统一的资源描述
  ，
  但是
  它
  是以旁路的方式实现的，
  基本不存在
  管控策略，
  而且
  不支持 Spark Client 模式。

• 统一的作业描述，以及详细、准确的状态信息；

• 丰富的作业异常处理策略；

• 快速接入高级调度功能的能力。

▌云原生大数据调度

• 全局的
  多机房统一资源湖
  ——
  
  ResLake
  ，负责全局统一的
  资源管理
  、调度、分发和
  容灾
  ；

• 每个集群上，GRO Scheduler
  
  负责集群内的 Quota 管控和
  Pod
  调度；

• 每个节点上，GRO Agent
  
  负责单机调度和隔离增强。

基于云原生的高性能资源管理调度器 —— GRO

GRO Scheduler

• Quota 管控：调度器首先将集群资源分配给各个队列，然后将队列资源分配给该队列的各个作业，最后将作业资源分配给该作业的各 Pod。不是所有 Pod 都可以获得资源，只有获得资源的 Pod 才可以进入后续的 Pod 放置流程；

• Pod
  放置：和原生调度器一样，首先为 Pod 筛选符合条件的节点，然后对筛选出来的节点进行打分，最后将 Pod 绑定到分数最高的节点上。

• Queue
  
  CRD
  ：
  描述了一个“
  队列
  ”，即 Quota（资源配额）的抽象；

• PodGroup
  CRD
  ：
  描述了一个“作业”，标识多个
  Pod
  属于同一个集合，从而可以把多个 Pod 看作整体进行调度。

• Min Quota，又称为保障资源量。调度器为该队列预留 Min Quota 的资源量，不允许其他队列占用，以保障该队列在需要使用时可以立刻获得资源；

• M
  ax
  Quota，又称为资源使用上限。调度器限制该队列使用资源不超过 Max Quota 的资源量。

• 优先级调度：所有作业按照定义的优先级排序，调度器优先分配高优先级的作业；

• Gang 调度：调度器一次性为作业的所有 Pod 分配资源，或者一个 Pod 也不分配，保证不出现一个作业的部分 Pod 启动，部分 Pod 排队等待的情况；一个作业只有部分 Pod 启动，有可能不能正常运行，这样不仅浪费了集群资源，还可能存在多个类似作业相互死锁，导致所有作业都不能正常运行；

• DRF 调度：调度器公平分配资源给各个作业的同时，兼顾多维度资源的比例，尽可能提升资源利用率；比如队列剩余大量 CPU 和少量内存时，优先分配 CPU 需求多、内存需求少的作业，避免队列的内存完全耗尽，大量 CPU 剩余，无法被利用的问题。

• 队列
  间抢占：队列没有使用的 Quota 允许临时被其他队列占用，当队列有资源需求时，可以从其他队列将资源抢占回来；

• 队列
  内抢占：队列没有剩余 Quota，高优作业提交后可以将正在运行的低优作业占用的资源抢占回来；

• 大作业资源预留：资源需求较大的作业很有可能因为节点资源碎片一直无法调度，调度器支持预留节点资源，保证大作业调度成功。

• 在线服务高峰时，离线计算尽量停止运行，在线服务使用集群大部分资源；

• 在线服务低谷时，在线服务让出大部分资源，离线计算开始运行。

GRO Agent

闲置资源利用

1. GRO
   Agent 监控所有
   Pod
   的资源使用情况，结合实时/历史资源变化曲线，实时计算出节点上可以被重复利用的闲置资源量（BestEffort 资源）
   ；

1. GRO Agent 上报 BE 资源量到 GRO Scheduler；

1. GRO
   Scheduler 调度有预期的低优作业到节点上使用 BE 资源
   ；

1. GRO
   Agent 通过单机隔离机制保障正常
   Pod
   的稳定性和性能
   ；

1. GRO
   Agent 根据 BE 资源变化情况压缩
   混部
   
   Pod
   资源或者驱逐混部 Pod
   。

基于云原生的多机房统一资源湖 —— ResLake