IntelliJ IDEA 2023.2 EAP 6 现已推出，提供了许多更新，例如新的 AI 助手 (AI Assistant)、对 Dev Containers for Gateway 的支持以及 IDE 新 UI 的一些有价值的增强功能。

AI Assistant (Beta)

此 EAP 版本为 IntelliJ IDEA 带来了一个重要的补充 —— AI 助手。它由 JetBrains AI 服务提供支持，并结合了 OpenAI 的功能以及 JetBrains 自己的小型模型。IntelliJ IDEA 2023.2 EAP 6 提供了一组初始的 AI 驱动功能，包括集成的 AI 聊天、自动文档生成、名称建议和提交消息生成。

要访问这些 AI 功能，你需要使用 JetBrains 帐户登录 JetBrains AI 服务；JetBrains AI 服务的可用性最初可能会有所不同。有关 AI Assistant 的更多信息以及如何访问它的说明可参阅此博客文章。

对 Dev Containers 的支持

IntelliJ IDEA 现在支持 Dev Containers，允许你使用容器作为功能齐全的开发环境来编辑、构建和运行你的项目。Dev Containers 可以通过 SSH 连接远程运行，也可以使用 Docker 在本地运行。

要使用此功能，需确保你的计算机上安装了 Docker。在“Welcome”屏幕中，选择“Remote Development”部分中的“Dev Containers”选项，并提供 Git 仓库链接以设置连接。

此外，你还可以通过打开 devcontainer.json 文件直接在编辑器中配置本地或远程环境。

初始支持包括数量有限的 devcontainer.json 选项。

新 UI 中的彩色项目标题

IntelliJ IDEA 2023.2 EAP 6 引入了彩色标题来简化多个打开项目之间的导航。现在可以为每个项目分配唯一的颜色和图标，以便更轻松地在工作区中区分它们。标题现在默认带有预定义的颜色，但用户可以自定义。

在新 UI 中删除了 Linux 上的 title bar

为了方便 Linux 用户，新 UI 中删除了操作系统的 native header ，从而使界面更加干净。默认情况下，用户现在将看到自定义 IDE 的标题，其中提供了一系列自定义选项来定制你的工作区。

支持 Maven 4.0.0-alpha

IntelliJ IDEA 现在与最新版本的 Maven Maven 4.0.0-alpha 完全兼容。

已弃用的插件

根据对插件使用情况的研究，决定弃用 IntelliJ IDEA 中的多个插件，包括 Struts2、Resin、tc Server、Play 和 Cloud Foundry。从 2023.2 版本开始，将不再构建他们的新版本。

更多详情可查看官方博客。

关注公众号

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

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

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

据《华尔街日报》报道，美国计划进一步收紧对中国出口 AI 计算显卡的限制。美国商务部最早可能在 7 月初采取行动，在未获得许可证的情况下，英伟达等 AI 芯片厂商将被禁止向中国和其他相关国家的客户销售多种型号的 AI 计算芯片和显卡等产品。

去年秋天，美国出台了 AI 芯片相关的首轮贸易限制措施，对 Nvidia 和 AMD 等公司施加出口许可证要求。当时限制贸易的产品覆盖了 Nvidia A100、H100 等高端 GPU 产品。英伟达方面表示，美国的限制令是在担心先进的 AI 芯片可能会被竞争对手用于训练强大的 AI 应用程序中，继而对美国的 AI 领先地位产生影响。

为了在不丢掉中国市场的同时满足限制令，芯片制造商开始生产功能较弱的计算显卡产品，比如 Nvidia 向中国客户提供 A800 GPU，该系列计算卡于 2022 年第三季度投入生产，它既可作为 A100 的替代品，又低于美国政府的禁令门槛。

但美国政府似乎对显卡厂商变相绕过监管的做法相当不满，相关立法者正计划扩大禁令范围，第二轮禁令限制的类型甚至会覆盖到 A800 等性能较差的计算显卡。

（其实 A800 和 A100 的硬件参数并没有差多少，只是 A800 为了过禁令阉割了卡间通信带宽，可以理解为 A100 特供版）

扩大 AI 芯片限制令的消息一经报道便不胫而走，虽然截止目前还没有任何美国政府的官方公告，但消息传出来一天之内，英伟达股价下跌 3.2%，AMD 股价下跌约 3%。

WhatsApp 已正式宣布弃用 Windows 上基于 Electron 的桌面应用程序，促使用户转而使用新推出的原生应用程序以实现不间断访问。此举旨在在桌面设备上提供更加优化、稳定且功能丰富的消息传递体验。

早在一个月前，WhatsApp 就在应用程序的主屏幕上显示了一个弃用倒计时，以提前告知用户。虽然有一些用户表达了对快速过渡、以及原生应用程序中业务工具（如目录管理和快速回复）短缺的不满。但现在所有打开基于 Electron 的 WhatsApp 桌面应用程序的用户，都会看到一个“APP expired”的通知消息，明确通知其该应用程序已不再受支持。

目前，Electron 应用程序的弃用似乎仅限于 WhatsApp Desktop for Windows。

Electron 框架允许开发人员通过开发可跨 Windows 和 macOS 等不同操作系统运行的单一代码库，使用 Web 技术创建跨平台桌面应用程序。但 WABetaInfo 指出，“由于它们是为了在不同的操作系统上工作而开发的，所以并没有真正优化，且可能会占用大量的资源。原生应用程序肯定可以提供更流畅、更直观的用户界面，更好的响应性和更强的稳定性，提供更强大和可靠的信息服务，这也是 WhatsApp 决定为其用户构建原生解决方案的原因。”

用户需要从 Microsoft Store 下载适用于 Windows 的原生桌面应用程序。对于仍然需要使用商业工具的用户，可以考虑使用 WhatsApp Web 作为临时解决方案。

谷歌基于团队内部使用 Rust 的体验和经历，分享了他们对这门“网红”编程语言的见解，其中包括对常见 Rust 谣传的澄清。

1. Rust 至少需要学习 6 个月

谷歌驳斥了此说法。

谷歌内部调查显示，超过 2/3 的受访者有信心在学习 Rust 时，用两个月或更短时间内就能为 Rust 代码库做出贡献。此外， 1/3 的受访者在两个月或更短的时间内使用 Rust 变得与其他语言一样高效。四个月内，这一数字增加到 50% 以上。

2. Rust 编译器速度并没有想象的那么快

谷歌证实了此说法。

他们表示，到目前为止，构建速度慢是开发者在使用 Rust 时遇到的第一大挑战，只有略多于 40% 的受访者认为速度可以接受。

3. unsafe 代码和互操作始终是最大的挑战

谷歌驳斥了此说法。

对于当前的谷歌开发者来说，他们在 Rust 领域面临的三大挑战是：

• Macros（宏）
• Ownership and borrowing（所有权和借用）
• Async programming（异步编程）

编写 unsafe 代码和处理 C/C++ 互操作也是谷歌开发者遇到的问题，但并不是最大的挑战。

4. Rust 的编译器错误消息十分有用

谷歌证实了此说法。

谷歌内部只有 9% 的受访者对 Rust 中的诊断和调试信息质量不满意。

综合社区的反馈来看，大家惊叹于编译器消息的出色表现。虽然起初有些惊讶——毕竟大家习惯于忽略大的编译器错误，但习惯之后，大家就喜欢它了。

5. Rust 的代码质量很高

谷歌证实了此说法。

受访者表示 Rust 代码的质量很高——77% 的开发者对 Rust 代码的质量感到满意。事实上，当被要求比较他们是否认为 Rust 代码比他们用其他语言编写的代码更正确时，绝大多数受访者 85% 相信他们的 Rust 代码是正确的。

除了正确，Rust 代码也便于 review，超过一半的受访者表示 Rust 代码非常容易 review。

原文地址

美团于 6 月 29 日在香港联交所发布公告称，已经订立交易协议以收购光年之外境内外主体 100% 股权，收购价约为 20.65 亿人民币。

收购价格包括现金 2.34 亿美、债务承担 3.67 亿人民币以及现金 1 人民币。

美团在公告中解释称，将通过此收购事项获得领先的 AGI 技术及人才，有机会加强其于快速增长的人工智能行业中的竞争力。

光年之外是一家大模型创业公司，成立于 2018 年；致力于推动实现 AGI（通用人工智能）与普惠人类。由美团联合创始人、前董事及关联人士王慧文创立及控制，光年之外集团的净现金为 2.85 亿美。日前，光年之外联合创始人王慧文曾因身体原因离岗就医及休养，引发外界诸多关注。

美团方面表示，并购完成后，将支持光年团队继续在大模型领域进行探索和研究。

摘要：索引就是数据表中数据和相应的存储位置的列表，利用索引可以提高在表或视图中的查找数据的速度。

本文分享自华为云社区《数据库开发指南（六）索引和视图的使用技巧、方法与综合应用》，作者： bluetata 。

一、索引

1.1 什么是索引

索引就是数据表中数据和相应的存储位置的列表，利用索引可以提高在表或视图中的查找数据的速度。它类似于书籍的索引，可以帮助快速定位和检索数据。在数据库中，索引是对一个或多个列的值进行排序和存储的结构，它们包含指向实际数据位置的指针。

1.2 索引分类

数据库中索引主要分为两类：聚集索引和非聚集索引。SQL Server 还提供了唯一索引、索引视图、全文索引、XML 索引等等。聚集索引和非聚集索引是数据库引擎中索引的基本类型，是理解其他类型索引的基础。

1.2.1 聚集索引

聚集索引是值表中数据行的物理存储顺序和索引的存储顺序完全相同。聚集索引根据索引顺序物理地重新排列了用户插入到表中的数据，因此，每个表只能创建一个聚集索引。聚集索引经常创建在表中经常被搜索到的列或按顺序访问的列上。在默认情况下，主键约束自动创建聚集索引。

1.2.2 非聚集索引

非聚集索引不改变表中数据列的物理存储位置，数据与索引分开存储，通过索引指向的地址与表中的数据发生关系。

非聚集索引没有改变表中物理行的位置，索引可以在以下情况下使用非聚集索引：

• 如果某个字段的数据唯一性比较高
• 如果查询所得到的数据量比较少

1.2.3 聚集索引和非聚集索引的区别

这里用一个表格简单的总结一下聚集索引和非聚集索引的区别：

1.2.4 其他类型索引

除了以上索引，还有以下类型索引：

• 唯一索引：如果希望索引键都不同，可以创建唯一索引。聚集索引和非聚集索引都可以是唯一索引。
• 包含新列索引：索引列的最大数量是16个，索引列的字节总数的最高值是900。如果当多个列的字节总数大于900，切又想在这些劣种都包含索引是，可以使用包含新列索引
• 视图索引：提供视图查询效率，可以视图的索引物理化，也就是说将结果集永久存储在索引中，可以创建视图索引。
• XML索引：是与xml数据关联的索引形式，是XML二进制blob的已拆分持久表示形式
• 全文索引：一种特殊类型的基于标记的功能性功能，用于帮助在字符串中搜索赋值的词

1.3 创建索引

1.3.1 语法

参数解释

unique 唯一索引
clustered 聚集索引
noclustered 非聚集索引
fillfactor 填充因子大小，范围在 0-100 直接，表示索引页填满的空间所占的百分比。

1.3.2 创建索引的命名规则最佳实践

在 MSSQL 中，索引的命名规则的最佳实践可以有一些常见的准则，以提高可读性和维护性。这个潜在的要求不仅试用于 SQL Server 数据库，同样在其他数据库例如 MySQL、Oracle 中都同样值得注意。

下面是个人总结的一些命名规则与建议：

1. 命名应该具有描述性：索引的名称应该能够清晰地表达其作用和关联的列或表。使用有意义的名称可以使其他开发人员更容易理解索引的用途。
2. 包含表名和列名：在索引名称中包含相关表名和列名（长表名可适当缩写，但要确保可以定位到表），可以使索引更具可读性，并且可以避免在不同表之间使用相同名称的索引时的冲突。
3. 使用统一的命名约定：为了提高一致性，可以定义一套命名约定，并在整个数据库中使用。例如，可以使用特定的前缀或后缀来标识索引的类型（如 idx_ 表示非聚集索引）。
4. 避免过长的名称：索引名称不应该过长，以免在使用索引时引起不便。尽量使用简洁但描述性的名称。
5. 避免使用保留关键字和特殊字符：确保索引名称不与 MSSQL 的保留关键字或特殊字符冲突，以避免语法错误。

1.3.3 创建索引示例

1.4 适合的创建索引的列

一般情况，可以选择那些对查询性能有积极影响的列进行索引创建，下面进行一定的总结：

列的选择性：选择性是指列中不同值的数量与总行数的比例。如果某列具有较高的选择性，即不同的值较多，那么为该列创建索引可能会有更好的效果。例如，在表示性别的列上创建索引可能没有太大的帮助，因为只有两个可能的值。

查询频率：观察经常用于查询条件的列。如果某个列经常用于搜索、过滤或连接操作，那么为该列创建索引可以提高查询性能。

数据表的大小：对于大型表，创建索引的影响可能更加显著。较小的表可能不需要太多的索引，因为全表扫描的开销相对较小。

数据更新频率：索引的创建和维护也会增加对数据的写操作的开销。如果某个列的数据经常发生变化，那么创建索引可能会带来一定的性能开销。

查询性能优化需求：通过分析查询执行计划，可以确定是否存在潜在的性能瓶颈，并考虑为相关的列创建索引以改善查询性能。

请注意过多的索引也可能会带来维护开销和存储成本，因此需要在权衡索引数量和性能提升之间找到平衡点。定期监控和评估索引的使用情况也是重要的，以确保索引仍然对数据库性能产生积极影响。

1.5 不适合创建索引的列

虽然在某些情况下创建索引可以提高查询性能，但并不是所有列都适合创建索引。以下是一些不适合创建索引的列的情况：

低选择性列：如果某个列的选择性很低，即该列的不同值较少，创建索引可能不会带来明显的性能提升。例如，对于性别这样只有几个可能值的列，创建索引可能不会有太大意义。

经常更新的列：如果某个列的值经常被修改，那么为该列创建索引可能会带来额外的维护成本和性能开销。每次更新操作都需要更新索引，这可能会影响写入性能。在这种情况下，需要仔细评估是否真的需要为该列创建索引。

过于频繁的查询列：某些列可能经常被查询，但它们的选择性较低，即不同的值较少。在这种情况下，尽管查询频率高，但为该列创建索引可能不会带来明显的性能提升，因为索引的使用效果有限。

大文本或大二进制列：对于存储大文本或大二进制数据的列，如长文本字段或图像字段，创建索引的效果通常较差。这是因为索引本身需要占用额外的存储空间，并且对于大型数据的索引操作可能变得非常耗时。

不常用的列：对于很少用于查询的列，创建索引可能没有太大意义。如果一个列很少用于查询条件或连接操作，那么为其创建索引可能只会增加额外的开销而不带来实际的性能提升。

需要注意的是，以上列举的情况只是一般性的指导原则，具体是否适合创建索引还取决于具体的数据库结构、查询模式和性能需求。在设计和创建索引时，应根据具体情况进行评估，并进行性能测试和优化以确保索引的有效性。

二、视图

2.1 什么是视图

视图就是一个虚拟的数据表，该数据表中的数据记录是由一条查询语句的查询结果得到的。

2.2 为什么要使用视图，而不是表（面试可能会被问到）

如果你在面试的时候被问到这个问题，建议从下面这个流程来回答一下面试官。

首先介绍一下表的作用（比如表是直接存储结构化数据，可以扩展增删改之类的），之后在介绍一下视图是什么，之后从两个切入点来讲解视图的好处以及必要性，这两个切入点是：复用性和安全性，这里来简单总结一下：

1. 简化查询，提高复用性
   想象一下，一个人员宽表，里面有几百个字段，但是你每次只需要用到这个表中的姓名、性别、年龄这三个字段，那么你可以创建一个视图来直接使用，或者你这个人员表经常和另外一个履历表 join 组合在一起，而只取了其中的部分字段，并且频繁使用这几个字段。那么无疑创建视图是一个好做法。当然这种情况也可以说明使用视图能够简化查询。
2. 提高安全性

• 通过视图，可以限制用户对敏感数据的直接访问。视图可以控制用户可以看到和操作的数据的范围，提供更好的安全性和隐私保护。这里还拿刚才我讲的姓名、性别、年龄三个字段，假如年龄是一个比较敏感的字段，那么对某些数据库用户只能查询姓名和性别的话，那么就可以设置一个视图分配给这个用户。
• 另外就是如果你要更新视图的时候，也只能更新视图所见的字段，用户对视图不可以随意的更改和删除，可以一定程度的保证数据的安全性。

讲解完上述的两个大的关键点后，也可以适当自行发挥，比如视图你可以调整表字段的显示顺序，或者字段名字等等。这些也是优点。可以适当进行讲解。

2.3 创建视图

创建视图的时候，对命名视图大家一般也有默认的规则，一般情况可以使用 v_ 或 view_ + 表名（表缩写）的形式。

例如：v_student

2.4 创建视图准则

创建视图需要考虑一下准则：

1. 视图名称必须遵循标识符的规则，该名称不得与该架构的任何表的名称相同。
2. 你可以对其他视图创建视图。允许嵌套视图，但嵌套不得超过32层。视图最多可以有1024个字段。
3. 不能将规则和 default 定义于视图相关联。
4. 视图的查询不能包含 compute 子句、compute by 子句或 into 关键字。
5. 定义视图的查询不能包含 order by 子句，除非在 select 语句的选择列表中还有 top 子句。

下列情况必须指定视图中每列的名称：

• 有列顺序需求（在某些情况下，您可能希望定义视图的结果集中列的顺序，并且这与基础表中的顺序不同。）
• 视图中的任何列都是从算术表达式、内置函数或常量派生而来
• 视图中有两列或多列具有相同名称（通常由于视图定义包含联接，因此来自两个或多个不同的列具有相同的名称）
• 有指定列别名的需求。注意无论是否重命名，视图列都需继承原列的数据类型

2.5 修改视图

修改视图和修改表有点类似，可以直接使用 alter 关键字进行修改，示例如下：

2.6 加密视图

如果你对某一个视图有保护查询逻辑、防止修改或者查询加密的需求的时候，可以使用加密视图操作。

在 SQL Server 中 使用with encryption后，可以在创建视图时对其定义的 SQL 查询进行加密。也就是说 MSSQL 会对该视图的定义中的查询语句进行加密。这意味着其他人无法直接查看或分析该视图的查询逻辑。压根就看不到这个视图内部结构了。

如何解密被加密的视图，或者修改已经被加密的视图：

一般情况一个视图被加密后，你需要修改它，那么大致有3个方法：

1. 重新创建视图（先删除已加密的视图，然后使用新的查询逻辑重新创建视图。）。
2. 创建新视图（创建一个新的，视图名称不同，之后调用这个新的）。
3. 暴力解密之后修改（一般需要借助第三方工具或辅助，该方式个人不推荐）

2.7 视图能否被更新 update （面试可能会被问到）

如果面试官问了这两个问题，那么他还算友好的提醒了你，如果直接问了一句话“视图可以被更新吗？”，那么我感觉有被挖坑的嫌疑。

视图可以被更新，但不是所有的情况都可以。

视图更新必须遵循以下规则：

1. 当视图的字段是通过字段表达式（Field Expression）或常数（Constant）计算得出的结果时，对该视图执行 INSERT 和 UPDATE 操作是不允许的，但可以执行 DELETE 操作。
2. 若视图的字段是来自库函数，则此视图不允许更新；
3. 若视图的定义中有 GROUP BY 子句或聚集函数时，则此视图不允许更新；
4. 若视图的定义中有 DISTINCT 任选项，则此视图不允许更新；
5. 若视图的定义中有嵌套查询，并且嵌套查询的 FROM 子句中涉及的表也是导出该视图的基表，则此视图不允许更新；
6. 若视图是由两个以上的基表导出的，此视图不允许更新（源表单一才可以被更新）；
7. 一个不允许更新的视图上定义的视图也不允许更新；
8. 由一个基表定义的视图，只含有基表的主键或候补键，并且视图中没有用表达式或函数定义的属性，才允许更新。

关注，第一时间了解华为云新鲜技术~

摘要：在本篇文章中，我们将深入探讨Spring框架中的重要组件——BeanPostProcessor。首先，我们将了解其设计理念和目标，然后通过实际的例子学习如何基础使用它，如何通过BeanPostProcessor改变Bean的初始化结果以及如何利用它修改Bean的属性。

本文分享自华为云社区《Spring高手之路6——Bean生命周期的扩展点：BeanPostProcessor》，作者：砖业洋__ 。

1. 探索Spring的后置处理器（BeanPostProcessor）

1.1 BeanPostProcessor的设计理念

BeanPostProcessor的设计目标主要是提供一种扩展机制，让开发者可以在Spring Bean的初始化阶段进行自定义操作。这种设计理念主要体现了Spring的一种重要原则，即“开放封闭原则”。开放封闭原则强调软件实体（类、模块、函数等等）应该对于扩展是开放的，对于修改是封闭的。在这里，Spring容器对于Bean的创建、初始化、销毁等生命周期进行了管理，但同时开放了BeanPostProcessor这种扩展点，让开发者可以在不修改Spring源码的情况下，实现对Spring Bean生命周期的自定义操作，这种设计理念大大提升了Spring的灵活性和可扩展性。

BeanPostProcessor不是Spring Bean生命周期的一部分，但它是在Spring Bean生命周期中起重要作用的组件。

1.2 BeanPostProcessor的文档说明

我们来看看这个方法的文档注释，从图中可以看到，BeanPostProcessor 接口定义了两个方法，postProcessBeforeInitialization和postProcessAfterInitialization

postProcessBeforeInitialization方法会在任何bean初始化回调（如InitializingBean的afterPropertiesSet方法或者自定义的init-method）之前被调用。也就是说，这个方法会在bean的属性已经设置完毕，但还未进行初始化时被调用。

postProcessAfterInitialization方法在任何bean初始化回调（比如InitializingBean的afterPropertiesSet或者自定义的初始化方法）之后被调用。这个时候，bean的属性值已经被填充完毕。返回的bean实例可能是原始bean的一个包装。

2. BeanPostProcessor的使用

2.1 BeanPostProcessor的基础使用示例

全部代码如下:

首先定义两个简单的Bean：Lion和Elephant

Lion.java

Elephant.java

然后定义一个简单的BeanPostProcessor，它只是打印出被处理的Bean的名字：

接着我们定义一个配置类，其中包含对Lion、Elephant类和MyBeanPostProcessor类的Bean定义：

最后，我们在主程序中创建ApplicationContext对象：

运行结果:

以上代码在执行时，将先创建Lion和Elephant对象，然后在初始化过程中和初始化后调用postProcessBeforeInitialization和postProcessAfterInitialization方法，打印出被处理的Bean的名字。

细心的小伙伴可能观察到这里有红色日志
信息: Bean ‘animalConfig’ of type [com.example.demo.configuration.AnimalConfig$$EnhancerBySpringCGLIB$$ee4adc7e] is not eligible for getting processed by all BeanPostProcessors (for example: not eligible for auto-proxying)

在Spring中，BeanPostProcessor是被特殊处理的，它们会在其他普通Bean之前被实例化和初始化，这样设计的原因是BeanPostProcessor的存在可以影响其他Bean的创建和初始化过程。 Spring应用上下文中可以存在多个BeanPostProcessor，Spring本身就提供了很多内置的BeanPostProcessor。

但是，如果在初始化BeanPostProcessor的过程中需要依赖其他的Bean，那么这些被依赖的Bean会先于后置处理器进行初始化。然而，由于这些被依赖的Bean是在该BeanPostProcessor初始化完成之前就已经进行了初始化，它们就会错过这个BeanPostProcessor的处理。在这个例子中，MyBeanPostProcessor就是这样的一个BeanPostProcessor，而”animalConfig”是它所依赖的Bean。所以这个日志信息就是说，’animalConfig’这个Bean在初始化的时候，没有被所有的BeanPostProcessor处理，这里它无法得到MyBeanPostProcessor的处理。

我们只需要把实例化过程直接交给Spring容器来管理，而不是在配置类中手动进行实例化，就可以消除这个提示信息，也就是在MyBeanPostProcessor上加@Component即可。

在第3节的例子中就使用了@Component处理这个MyBeanPostProcessor，这个提示就消失了。

2.2 利用BeanPostProcessor修改Bean的初始化结果的返回值

还是上面的例子，我们只修改一下MyBeanPostProcessor 类的方法后再次运行

运行结果:

BeanPostProcessor的两个方法都可以返回任意的Object，这意味着我们可以在这两个方法中更改返回的bean。例如，如果我们让postProcessBeforeInitialization方法在接收到Lion实例时返回一个新的Elephant实例，那么我们将会看到Lion实例变成了Elephant实例。

那既然BeanPostProcessor的两个方法都可以返回任意的Object，那我搞点破坏返回null会怎么样，会不会因为初始化bean为null而导致异常呢？

答案是不会的，我们来看一下：

我们运行看结果

结果发现还是正常初始化的bean类型，不会有任何改变，我们继续调试看看是为什么

我们通过堆栈帧看到调用postProcessBeforeInitialization方法的上一个方法是applyBeanPostProcessorsBeforeInitialization，双击点开看一看这个方法

从我这个调试图中可以看到，如果postProcessBeforeInitialization返回null，Spring仍然用原始的bean进行后续的处理，同样的逻辑在postProcessAfterInitialization也是一样。这就是为什么我们在BeanPostProcessor类的方法中返回null，原始bean实例还是存在的原因。

2.3 通过BeanPostProcessor实现Bean属性的动态修改

来看看是怎么拦截 bean 的初始化的

全部代码如下：

首先，我们定义一个Lion类：

接下来，我们定义一个BeanPostProcessor，我们称之为MyBeanPostProcessor ：

然后我们定义一个配置类，其中包含对Lion类的Bean定义和对MyBeanPostProcessor 类的Bean定义：

最后，我们在主程序中创建ApplicationContext对象，并获取Lion对象：

运行结果:

上面代码在执行时，先创建一个Lion对象，然后在初始化过程中和初始化后调用postProcessBeforeInitialization和postProcessAfterInitialization方法，修改Lion的名字为”Simba”，最后在主程序中输出Lion对象，显示其名字为”Simba”。

3. 深度剖析BeanPostProcessor的执行时机

3.1 后置处理器在Bean生命周期中的作用及执行时机

在这个例子中，我们将创建一个名为Lion和Elephant 的Bean，它会展示属性赋值和生命周期的各个步骤的执行顺序。同时，我们还将创建一个BeanPostProcessor来打印消息并显示它的执行时机。

全部代码如下：

首先，我们定义我们的Lion：

创建Lion所依赖的Elephant

然后，我们定义一个简单的BeanPostProcessor：

创建一个配置类AnimalConfig

主程序：

控制台上看到所有的方法调用都按照预期的顺序进行，这可以更好地理解Bean属性赋值和生命周期以及BeanPostProcessor的作用。

根据打印日志我们可以分析出

1. 首先，Bean Constructor Method Invoked! 表明 Lion 的构造器被调用，创建了一个新的 Lion 实例。
2. 接着，Bean Setter Method Invoked! name: my lion 和 Bean Setter Method Invoked! elephant: com.example.demo.bean.Elephant@f 说明 Spring 对 Lion 实例的依赖注入。在这一步，Spring 调用了 Lion 的 setter 方法，为 name 属性设置了值 “my lion”，同时为 elephant 属性注入了一个 Elephant 实例。
3. 然后，postProcessBeforeInitialization Method Invoked! 说明 MyBeanPostProcessor 的 postProcessBeforeInitialization 方法被调用，这是在初始化 Lion 实例之前。
4. @PostConstruct Method Invoked! 说明 @PostConstruct 注解的方法被调用，这是在 Bean 初始化之后，但是在 Spring 执行任何进一步初始化之前。
5. afterPropertiesSet Method Invoked! 说明 Spring 调用了 InitializingBean 的 afterPropertiesSet 方法
6. customInitMethod Method Invoked! 表示调用了 Lion 实例的 init-method 方法。
7. postProcessAfterInitialization Method Invoked! 说明 MyBeanPostProcessor 的 postProcessAfterInitialization 方法被调用，这是在初始化 Lion 实例之后。
   然后 Spring 完成了整个初始化过程。
8. 主程序中手动调用了 Lion 实例的 setter 方法，因此在 Bean Setter Method Invoked! name: oh!!! My Bean set new name 可见，name 属性被设置了新的值 “oh!!! My Bean set new name”。
   当容器准备关闭时：
9. @PreDestroy Method Invoked! 说明 @PreDestroy 注解的方法被调用，这是在 Bean 销毁之前。
10. destroy Method Invoked! 表示 Lion 实例开始销毁。在这一步，Spring 调用了 DisposableBean 的 destroy 方法。
11. customDestroyMethod Method Invoked! 表示 Lion 实例开始销毁，调用了Lion 实例的 destroy-method 方法。

最后，Spring 完成了整个销毁过程，容器关闭。

这个日志提供了 Spring Bean 生命周期的完整视图，显示了从创建到销毁过程中的所有步骤。

注意：DisposableBean 的 destroy 方法和 destroy-method 方法调用，这个销毁过程不意味着bean实例就被立即从内存中删除了，Java的垃圾收集机制决定了对象什么时候被从内存中删除。Spring容器无法强制进行这个操作，比如解除bean之间的关联和清理缓存，这并不是Spring在销毁bean时会做的，而是由Java的垃圾回收器在一个对象不再被引用时做的事情。

BeanPostProcessor 的执行顺序是在 Spring Bean 的生命周期中非常重要的一部分。例如，如果一个 Bean 实现了 InitializingBean 接口，那么 afterPropertiesSet 方法会在所有的 BeanPostProcessor 的 postProcessBeforeInitialization 方法之后调用，以确保所有的前置处理都完成了。同样，BeanPostProcessor 的 postProcessAfterInitialization 方法会在所有的初始化回调方法之后调用，以确保 Bean 已经完全初始化了。

我们可以注册多个 BeanPostProcessor。在这种情况下，Spring 会按照它们的 Ordered 接口或者 @Order 注解指定的顺序来调用这些后置处理器。如果没有指定顺序，那么它们的执行顺序是不确定的。

3.2 图解：Bean生命周期与后置处理器的交互时序

综合上面的执行结果，我们来总结一下，下面是Spring Bean生命周期的时序图，它详细地描绘了Spring Bean从实例化到准备使用的整个过程，包括Bean的实例化、属性赋值、生命周期方法的执行和后置处理器的调用。

关注，第一时间了解华为云新鲜技术~

摘要：随着企业数据空间在内部的成功实践，2022年，华为正式推出云服务产品——华为云交换数据空间EDS（Exchange Data Space），秉持“你的数据你做主”的宗旨，以保护企业数据主权为基础，促进企业数据高效流通，实现数据价值最大化。

本文分享自华为云社区《数据交换不失控——华为云EDS，让你的数据你做主》，作者：开天aPaaS小助手。

数字社会，每时每刻都有海量数据产生，数据也逐渐从生产过程的附属产物，逐渐成为数字经济的关键生产要素。作为生产要素，数据只有流通起来才能产生大规模的经济价值。

数据在企业中的流通模式经历了数据集成、数据共享到数据交换的三个阶段：

阶段一，数据沿着企业的业务流流通，主要是系统间的集成对接。

阶段二，企业开始通过跨业务的数据分析来支撑企业经营和日常运营，此时的数据流通就突破业务流的约束，通过数据汇聚实现数据在企业内的安全共享。

阶段三，随着数据成为生产要素，要素价值分配的特征使数据增值，并激发了数据进一步参与流通的动力。因此，企业数据的流通开始在数据集成和共享这两种模式的基础上，逐步以独立的生产要素的身份参与数据交换，释放要素价值。

华为的整个数据工作历程与之类似：

第一阶段，做数据清洁，使数据定义在不同系统中保持一致，把主业务打通。

第二阶段，打破数据的部门墙，把数据汇聚到数据底座再分享出去，华为有3000多个系统，这时候把重要的业务数据入到数据湖里，然后再加工做个服务开放出去。

第三阶段，此时数据范围扩大了，不仅是企业内部的共享，还需要和供应商、客户、其他组织进行交换，这就要建立数据空间，使数据能够可控的交换，使数据成为企业高质量发展的核心竞争力。

在这个数据交换的过程中，关键解决了数据的两个特征：

一个是非排他性，其他生产要素都是可以排他的，而数据是你可以用，他也可以用，没有排他性；第二个是数据复制的“零成本”。

不解决非排他性和零成本复制问题，企业不愿意把数据给出去，数据流通就做不起来。

2017年，华为作为国内第一家正式加入国际数据空间协会（IDSA）（首次提出主权保护的“数据空间”理念）的企业，开始对数据可控交换解决方案进行探索。

2021年，基于多年不断的探索成果和内部实际诉求，正式启动企业数据交换空间的内部试点建设。并成功在鲲鹏/昇腾生态、企业投后管理、财经外审等重点领域取得了一定的效果。

实践一：华为内部高密数据的跨领域安全共享

行政、HR、采购等领域开通数据空间，实现高密数据的安全共享，月均共享数据5000+，在确保数据安全的前提下，充分发挥数据价值。

实践二：华为生态产业链上下游数据的可控交换

EDS构建鲲鹏、昇腾两个生态数据交换空间，为15个上下游企业开通数据连接器，月均交换研发、供应、服务等领域数据3000+，支撑了质量追溯、产品开发协同等业务场景的可控数据交换。

随着企业数据空间在内部的成功实践，2022年，华为正式推出云服务产品——华为云交换数据空间EDS（Exchange Data Space），秉持“你的数据你做主”的宗旨，以保护企业数据主权为基础，促进企业数据高效流通，实现数据价值最大化。

华为云EDS在“可信、可控、可证”的框架基础上进行数据空间的关键设计，打造数据可控交换的全栈能力。

可信：构造多方信任的生态环境

通过资质评估、证书发放等环节，对组织、个人及技术组件进行可信认证，建立统一的信任机制，实现参与方身份与平台环境可信任。

可控：打造可组合的策略控制数据的使用

平台提供21种策略，在数据使用过程中基于策略（比如“有效期限、查看次数、是否下载” 等）做出相应的使用控制，确保在数据主权可控的基础上合规使用数据。

可证：支撑提供方查证追溯、消费方可免证清白

提供全流程可信、可视的审计追溯服务，支持提供方查证追溯，也能让消费方免证清白，同时为第三方监管提供相应的审计信息。

华为云EDS可用在多种数据交换场景中：

在企业内部，EDS可与企业内各部门间的系统对接集成，在现有业务中嵌入使用控制能力，使业务流程自动化，增强数据的管控和追溯能力。

在企业间的数据交换，EDS通过缔造数据合约型的契约管理，保障双方数据可控交换及交易，保证过程的机密性。

在产业上下游间敏感业务的可控交换，EDS可以让产业生态上下游多方参与，支持多种数据格式及多交换模式的双向交换。

华为云交换数据空间EDS自2022年作为一款云服务产品推出后，逐渐在外部医疗、工业等领域积累了一些成功实践。

EDS助力XX医疗集团实现健康医疗数据安全共享

XX医疗集团拥有庞大的健康医疗数据，向公立医院、医疗科研机构、保险公司等组织进行数据共享时，存在数据共享不可控、不可追溯等安全隐患。

XX医疗集团基于华为云EDS构建数据交换空间，为公立医院、医疗科研机构等开通数据连接器，实现医疗数据的安全可控共享。既保护了各机构的医疗数据主权，也增强了行业互信，释放数据价值的同时，也提升了患者的就医体验。

华为云EDS“让你的数据你做主”！

了解更多：https://www.huaweicloud.com/product/eds.html

号外

7月7日，华为开发者大会2023 ( Cloud )将拉开帷幕，并将在国内30多个城市、海外10多个国家开设分会场，诚邀您参加这场不容错过的年度开发者盛会，让我们一起开启探索之旅！

我们将携手开发者、客户、合作伙伴，为您呈现华为云系列产品服务与丰富的创新实践，并与您探讨AI、大数据、数据库、PaaS、aPaaS、媒体服务、云原生、安全、物联网、区块链、开源等技术话题，展开全面深入的交流。

大会将汇聚全球科学家、行业领袖、技术专家、社区大咖，开设200多场开发者专题活动，为全球开发者提供面对面交流与合作的机会，共同探讨技术创新和业务发展。

大会官网：https://developer.huaweicloud.com/HDC.Cloud2023.html

参会购票：https://www.vmall.com/product/10086352254099.html?cid= 211761

参与开发者社区活动，观赏技术大咖秀、玩转技术梦工厂，有机会赢取4000开发者礼包！

欢迎关注“华为云开发者联盟”公众号，获取大会议程、精彩活动和前沿干货。

关注，第一时间了解华为云新鲜技术~

摘要：在本文中，我们将介绍如何使用Vue3和Spring Framework进行开发，并创建一个简单的TodoList应用程序。

本文分享自华为云社区《Vue3搭配Spring Framework开发【Vue3应用程序实战】》，作者：黎燃。

一、介绍

Vue3和Spring Framework都是现代Web应用程序开发中最流行的框架之一。

Vue3是一个流行的JavaScript框架，可以帮助我们构建交互式的前端应用程序。Spring Framework是一个流行的Java框架，可以帮助我们构建高性能的后端应用程序。在本文中，我们将介绍如何使用Vue3和Spring Framework进行开发，并创建一个简单的TodoList应用程序。

二、创建Vue3应用程序

首先，我们需要创建一个新的Vue3应用程序。我们可以使用Vue CLI来创建应用程序，具体步骤如下：

• 在终端中，使用以下命令安装Vue CLI：

• 创建一个新的Vue3应用程序：

• 选择默认配置，并等待Vue CLI安装所需的依赖项。
• 进入新创建的应用程序目录，并启动开发服务器：

现在，我们已经准备好使用Vue3来创建我们的TodoList应用程序了。

三、创建TodoList组件

接下来，我们需要创建一个Vue3组件来显示我们的TodoList。我们可以使用以下命令在src/components目录下创建一个新的组件文件：

然后，我们可以使用以下代码创建我们的TodoList组件：

在这里，我们使用了Vue3的数据绑定功能来将我们的TodoList数据渲染为HTML。我们使用v-for指令来循环渲染每个TodoList项目，并使用key属性来提高性能。

四、创建Spring控制器

现在，我们需要创建一个Spring控制器来处理我们的TodoList数据。我们可以使用以下命令在src/main/java/com/example/demo目录下创建一个新的Java文件：

然后，我们可以使用以下代码创建我们的Spring控制器：

在这里，我们使用了Spring Framework的@RestController注解来标记我们的控制器，并使用@GetMapping注解来指定HTTP GET请求的路径。我们的getTodos方法返回一个包含TodoList项目的字符串数组。

五、创建Vue3服务

接下来，我们需要创建一个Vue3服务来获取我们的TodoList数据。我们可以使用以下命令在src/services目录下创建一个新的JavaScript文件：

然后，我们可以使用以下代码创建我们的Vue3服务：

在这里，我们使用了Axios库来发出HTTP GET请求，并从我们的Spring控制器中获取TodoList数据。我们将baseUrl设置为我们的Spring控制器的路径。

六、将Vue3服务与组件集成

现在，我们已经准备好将我们的Vue3服务与我们的TodoList组件集成。我们可以使用以下代码更新我们的TodoList.vue组件：

在这里，我们将我们的Vue3服务导入我们的TodoList.vue组件，并在created生命周期钩子中使用await关键字来异步获取TodoList数据。

七、启动应用程序

现在，我们已经完成了我们的Vue3和Spring Framework应用程序的开发。我们可以使用以下命令启动我们的应用程序：

然后，我们可以在浏览器中访问http://localhost:8080来查看我们的TodoList应用程序。

八、总结

在本文中，我们介绍了如何使用Vue3和Spring Framework创建一个简单的TodoList应用程序。我们使用Vue CLI创建了一个新的Vue3应用程序，并创建了一个Vue3组件来显示我们的TodoList。然后，我们使用Spring Framework创建了一个控制器来处理我们的TodoList数据，并使用Axios库创建了一个Vue3服务来获取数据。最后，我们将我们的Vue3服务与我们的Vue3组件集成，并启动了我们的应用程序。希望这篇文章对您有所帮助！

关注，第一时间了解华为云新鲜技术~

1.1 分布式ID应用的场景

随着系统的业务场景复杂化、架构方案的优化演进，我们在克服问题的过程中，也总会延伸出新的技术诉求。分布式ID也是诞生于这样的IT发展过程中，在不同的关联模块内，我们需要一个全局唯一的ID来让模块既能并行地解耦运转，也能轻松地进行整合处理。以下，首先让我们一起回顾这些典型的分布式ID场景。

1.1.1 系统分库分表

1.1.2 系统多活部署

1.1.3 链路跟踪技术

1.2 分布式ID核心的难点

1.3 分布式ID常见的方案

常用系统设计中主要有下图9种ID生成的方式：

1.4 分布式ID鲁班的方案

我们的系统跨越了公共、生产制造、营销、供应链、财经等多个领域。在分布式ID诉求下还有如下的特点：

综合参考了业界优秀的开源组件与常用方案均不能满足，为了统一管理这类基础技术组件的诉求，我们选择基于公司业务场景自研一套分布式ID服务：鲁班分布式ID服务。

2.1 架构说明

3.1 支持多种类型的ID规则

目前鲁班分布式ID服务共提供”Long类型“、“String类型”、“MixId类型”等三种主要类型的ID，相关ID构成规则与说明如下：

3.1.2 Long类型

（1）构成规则

静态结构由以下三部分数据组成，组成部分共19位：

（2）降级机制

主要自增部分在服务器获取初始值后，由客户端SDK维护，直到自增99后再次访问服务端获取下一轮新的ID以减少服务端交互频率，提升性能，服务端获取失败后抛出异常，接入业务侧需介入进行处理。

（3）样例说明

3.1.2 String类型

（1）构成规则

静态结构由以下五部分数据组成，组成部分共25~27位：

（2）降级机制

主要自增部分由客户端SDK内部维护，一般情况下只使用001–999 共999个全局ID。也就是每向服务器请求一次，都在客户端内可以自动维护999个唯一的全局ID。特殊情况下在访问服务器连接出问题的时候，可以使用带字符的自增来做服务器降级处理，使用产生00A, 00B… 0A0, 0A1,0A2….ZZZ. 共有36 * 36 * 36 – 1000 （999纯数字，000不用）= 45656个降级使用的全局ID。

（3）样例说明

3.1.3 MixId类型

（1）构成规则

静态结构由以下三部分数据组成，组成部分共17位：

（2）降级机制

无，每次ID产生均需到服务端请求获取，服务端获取失败后抛出异常，接入业务侧需介入进行处理。

（3）样例说明

3.2 业务自定义ID规则实现

鲁班分布式ID服务内置“Long类型”，“String类型”，“MixId类型”等三种长度与规则固定的ID生成算法，除以上三种类型的ID生成算法外，业务侧往往有自定义ID长度与规则的场景诉求，在鲁班分布式ID服务内置ID生成算法未能满足业务场景时，为了能在该场景快速支持业务，鲁班分布式ID服务提供了业务自定义接口并通过SPI机制在服务运行时动态加载，以实现业务自定义ID生成算法场景的支持，相关能力的实现设计与接入流程如下：

3.3 保证ID生成不重复方案

3.4 ID服务无状态无损管理

服务部署的环境在虚拟机上，ip是固定，常规的做法是在配置表里配置ip与机器码的绑定关系（这样在服务扩缩容的时候就需要人为介入操作，存在一定的遗漏配置风险，也带来了一定的运维成本），但在容器的部署场景，因为每次部署时IP均是动态变化的，以前通过配置表里ip与机器码的映射关系的配置实现方式显然不能满足运行在容器场景的诉求，故在服务端设计了通过心跳上报实现机器码动态分配的机制，实现服务端节点ip与机器码动态分配、绑定的能力，达成部署自动化与无损发布的目的。

相关流程如下：

【注意】

3.5 ID使用方接入SDK设计

SDK设计主要以”接入快捷,使用简单“的原则进行设计。

（1）接入时:

（2）使用时:

3.6 关键运行性能优化场景

3.6.1 内存使用优化

3.6.2 锁颗粒度优化

客户端SDK再自增值使用完或一定时间后会向服务端请求新的id生成，这个时候需要保证该次请求在多线程并发时是只请求一次，当前设计是基于用户申请ID的接入配置，组成为key，去获取对应key的对象锁，以减少同步代码块锁的粒度，避免不同接入配置去在并发去远程获取新的id时，锁粒度过大，造成线程的阻塞，从而提升在高并发场景下的性能。

当前鲁班分布式ID服务日均ID生成量亿级，平均RT在0~1ms内,单节点可支持 万级QPS，已全面应用在公司IT内部营销订单、支付单据、库存单据、履约单据、资产管理编码等多个领域的业务场景。

本文通过对分布式ID的3种应用场景，实现难点以及9种分布式ID的实现方式进行介绍，并对结合vivo业务场景特性下自研的鲁班分布式id服务从系统架构，ID生成规则与部分实现源码进行介绍，希望对本文的阅读者在分布式ID的方案选型或自研提供参考。

全生命周期管理业务证书，我们建设的平台需具备以下特性和能力：

3.1 技术选型

（1）前端框架：

3.2 架构设计

证书管理平台整体架构设计：

3.3 模块设计

证书管理平台包含四个非常重要的子模块：

4.1 前端

4.2 后端

后端使用Go语言来编写业务逻辑和API接口。其中架构可以参考3.2设计图，管理平台核心逻辑通过代码片段展示如下：

（1）基于casbin实现的权限管理：通过角色控制权限，并按需赋予用户角色默认访问权限（如下图创建角色时AddMenuAuthority、UpdateCasbin方法）。

（2）证书相关数据加密处理：获取前端用户选择的相关算法进行加密。

（3）基于证书管理标准化流程的业务代码实现，覆盖证书的信息管理&变更推送&监控告警&平台的角色权限控制。

经过多个开发迭代，平台相关的核心功能如下：

5.1 证书信息概览

概览首页收敛证书管理的功能入口，以及收纳管理证书的全貌，方便管理员了解所管理的证书状态和最近的申请进度。

5.2 证书信息管理

汇总了目前内销所有证书信息，后续平台上申请的证书信息管理也会收敛于此，并提供证书私钥相关的查看和下载。 

5.3 证书申请/续期

通过平台场景化证书申请续期的操作，解决过往碎片化操作以及无经验人员需通过文档阅读或者人员指导完成证书申请问题。

5.4 证书变更管理

平台覆盖云上、NGINX 集群、CDN 以及 VUA 的证书白屏化、可追溯操作历史更新能力。

5.5 证书监控

收敛在平台上管理的证书都会有逾期监控提醒，来提醒运维人员及时完成对应的证书更新管理，确保业务不受影响。

证书管理平台的实践落地，通过流程标准化以及管理平台的建立，规范证书的信息、变更、告警、变更审计相关管理，上线后至今，也无证书管理相关的问题导致的可用性告警，解决了传统域名证书管理场景下人效、可用性隐患的痛点，是业务运维 SRE 可用性保障&运维提效的一个成功案例。

目前我们获取的证书，依旧依赖于传统的域名证书分发模式(站点管理员需要花费金钱购买数字证书，并且证书的签发和更新需要时间和人力成本)。随着区块链和Web 3.0技术的发展，新增了去中心化身份验证和身份管理技术，在证书的分发上具备以下优势：

摘要：大模型是新一轮AI发展的核心，其已在推进产业智能化升级中已表现出巨大潜力，并将在未来三年里形成风起云涌之势。

本文分享自华为云社区《探秘华为云盘古大模型：AI for industries的身体力行》，作者：华为云头条。

大模型是新一轮AI发展的核心，其已在推进产业智能化升级中已表现出巨大潜力，并将在未来三年里形成风起云涌之势。

华为云于2021年正式发布了盘古基础大模型，包括CV计算机视觉大模型、NLP自然语言处理大模型和科学计算大模型。在基础大模型之上，华为云践行AI for industries，陆续推出了矿山、药物分子、电力、气象、海浪等盘古行业大模型，加速各行各业数字化的进程。

▶货运列车智慧检测，盘古轨道大模型为铁路物流安全护航

随着海内外经济复苏，货运铁路的班次及载重均迎来新高潮。

在传统的货运铁路巡检中，TFDS（货车运行故障动态图像检测）系统作为5T检测技术的重要组成部分，通过高速拍摄的“电子眼”，动态采集列车车底配件、车体侧部等部位图像，实时判别货运列车是否存在故障。

一列50辆车厢的货车，“电子眼”会拍摄4000张照片，检测员每秒需审阅1张图。动态检车员不仅工作强度大、难度高，而且需对车辆专业理论与实际运用有较高水平，要在短时间内完成整列车的故障分析，确保整列车的运行安全。

华为云在现有设备和平台架构的基础上，基于盘古轨道行业大模型，推出TFDS故障智能识别方案，实现从图像采集、数据收发、列车拆分，到实时故障判别的全局分析，能够对多工位、多辆车关联等全局故障进行精准预报。

盘古铁路行业大模型具备五项核心竞争力：

• 自监督行业预训练模型

盘古预训练大模型基于语义相似样本、等级化语义聚集的对比表示学习方法，利用百万级无标注铁路行业图像生成轨道行业大模型；

• 图像质量自动增强&评估

通过底层视觉特征以及高层视觉特征对增强后的图像进行自动评估，对正常图像做进一步故障识别，非正常图像返回人工审核；

• 依托车型先验模板匹配

根据已知的车型信息建立零部件的相对位置模板，具有可解释性地预报部件异常情况，如脱落、丢失、错位等；

• 小样本故障定位、识别

基于轨道行业预训练大模型，结合当前最优的目标检测、图像识别框架，进行部件定位、故障识别，具有更强的泛化能力，仅需传统1/3的样本即可完成。

在实际应用中，盘古轨道大模型单张照片识别仅需4毫秒，可智能过滤95%的正常图片，实现了400多种故障的自动化识别以及严重故障的“零漏报”，比人工识别更准确，大幅度提升TFDS系统作业效率，动态检车员可腾出更多精力处理难度更高的辨图工作，确保列车安全运行。

▶AI辅助药物设计，盘古药物分子大模型加速新药研发

自1987年达托霉素被发现以来，人类已经有近40年没有新的抗生素被研发出来。药物研发专家需要花费超过10年时间、超过10亿美成本，才有可能研发出一款新药。

为了帮助药物研发专家从海量药物分子中高效挑选出适合成药的小分子，华为云联合中国科学院上海药物研究所推出了盘古药物分子大模型，基于全流程AI辅助药物设计的能力，以靶点预测、分子设计、活性评估、毒性筛选等环节为抓手，帮助医药公司实现快速、精准、低成本的药物发现，开启药物研发的新模式。

• 在药物虚拟筛选方面

依靠华为云创新的iFitDock算法以及虚拟筛选服务，盘古药物分子大模型的成药性预测准确率比传统方式高20%，进而让药物筛选效率提升十倍；

• 在药物优化方面

基于华为云盘古药物分子大模型的结构优化器，研发专家可对先导药进行定向优化，通过更科学的药物结构设计，减弱对人体正常细胞可能产生的毒副作用。

盘古药物分子大模型四大核心技术特点：

• “图-序列不对称条件变分自编码器”

全新提出“图-序列不对称条件变分自编码器”深度学习架构，更好地提取化合物关键的分子特征指纹，提升下游任务的准确性；

• 超大规模的化合物表征模型训练

对17亿个小分子的化学结构进行预训练，结构重构率、唯一性等方面优于现有方法；

• 生成1亿个创新的类药物小分子库

其结构新颖性为99.68%，为发现新药创造可能性；

• 实现了领先的药物发现任务性能

在化合物-靶标相互作用预测、化合物ADME/T属性评分、化合物分子生成与优化等方面实现性能最优，赋能药物发现全链条任务。

西安交通大学第一附属医院刘冰教授在盘古药物分子大模型的辅助下，突破性地研发出一款超级抗菌药Drug X，其有望成为全球近40年来首个新靶点、新类别的抗生素。华为云盘古药物分子大模型让先导药的研发周期从数年缩短至几个月，研发成本降低70%。AI技术与基础科学的结合与创新，不仅解决了研发成本高和时间周期长的痛点，更为初创型科研团队提供了施展能力的舞台。

▶让风云可测，盘古气象大模型精准呈现台风轨迹

在气象气候预报任务中，除了短期天气预报，全球中长期预报也是业界最为关注、重要性非常高的预测任务，它以预测未来14天内的大气系统状态为目标，在气象、航海、农业、旅游等多个行业发挥着举足轻重的作用。

当前人工智能技术虽已广泛应用在气象预测领域，受大气系统中物理过程的复杂性影响，以及求解大气模型所需资源规模巨大，基于传统数值方法进行的中长期天气预报通常会累计误差，导致准确度低，且需在超级计算机上运算数小时。

基于近40年的全球气象数据，华为云盘古气象大模型在中长期确定性预报上超越当前最强的数值预报方法（欧洲气象中心的IFS系统），是业内首个精度超过传统数值预报方法的全球AI气象预测模型。平均预报误差降低了10%-15%，速度提升10000倍以上，实现秒级全球气象预报。

盘古气象大模型核心技术特点：

• 3D高分辨率的神经网络

首次采用3D高分辨率的神经网络（3D Earth-Specific Transformer）：与二维的神经网络和低分辨率的神经网络相比，盘古气象大模型水平空间分辨率达到0.25∘×0.25∘，约28公里x28公里，可以精准地预测细粒度气象特征。在时间维度上，盘古气象大模型将预测频率从6小时/次提升至1小时/次，使气象预测结果更准确；

• 层次化时域聚合策略

使用层次化时域聚合策略：训练了4个不同预报间隔的模型（分别为1小时间隔、3小时间隔、6小时间隔、24小时间隔），使得预测特定时间气象状况的迭代次数最小，从而减少迭代误差，也避免了由递归训练带来的训练资源消耗。

华为云盘古气象大模型在极端天气过程（如台风）的预报中已展现出精准、快速的优势：

• 2022年8月，盘古气象大模型实现秒级预测台风“马鞍”的轨迹和登陆时间，准确率达90%，远超行业平均水平。
• 今年5月22日至23日，今年第2号台风“玛娃”在24小时内，中心附近最大风力从38米/秒（台风级）迅速加强到60米/秒（超强台风级）。

中央气象局指出，华为云盘古大模型在“玛娃”的路径预报中表现优异，提前五天预报出其将在台湾岛东部海域转向路径。

人工智能触发的产业变革正在改变每一个行业，人工智能也在越来越多的行业场景发挥重要价值。华为云以“AI for industries”为发力点，提升大模型通用能力，贴近客户业务场景的现实需求，让人工智能开发标准化、可复制、批量化生产，加速AI深入千行百业，推动人类社会进入智能世界。华为开发者大会2023 ( Cloud )大会将于7月7日在东莞拉开帷幕，华为云盘古大模型将迎来重大升级，敬请期待！

号外

7月7日，华为开发者大会2023 ( Cloud )将拉开帷幕，并将在国内30多个城市、海外10多个国家开设分会场，诚邀您参加这场不容错过的年度开发者盛会，让我们一起开启探索之旅！

我们将携手开发者、客户、合作伙伴，为您呈现华为云系列产品服务与丰富的创新实践，并与您探讨AI、大数据、数据库、PaaS、aPaaS、媒体服务、云原生、安全、物联网、区块链、开源等技术话题，展开全面深入的交流。

大会将汇聚全球科学家、行业领袖、技术专家、社区大咖，开设200多场开发者专题活动，为全球开发者提供面对面交流与合作的机会，共同探讨技术创新和业务发展。

大会官网：https://developer.huaweicloud.com/HDC.Cloud2023.html

参会购票：https://www.vmall.com/product/10086352254099.html?cid= 211761

参与开发者社区活动，观赏技术大咖秀、玩转技术梦工厂，有机会赢取4000开发者礼包！

欢迎关注“华为云开发者联盟”公众号，获取大会议程、精彩活动和前沿干货。

关注，第一时间了解华为云新鲜技术~

摘要：本期结合示例，详细介绍华为云数字工厂平台的数据分析模型和数据图表视图模型的配置用法。

本文分享自华为云社区《数字工厂深入浅出系列（六）：数据分析与图表视图模型的配置用法》，作者：云起MAE 。

华为云数字工厂平台基于“数据与业务一体化”理念，提供统一的制造全域数据平台底座，内置轻量级制造数据分析引擎与可视化工具，支持IT/OT全域多模态数据的动态建模、采集、存储、分析和可视化应用，提供图形化的数据分析模型配置器，自动读取数字工厂平台的9类业务信息模型及其数据关联关系，能够让不懂技术的业务人员也可以自助式完成数据分析建模。数据分析模型，可搭配平台提供的视图模型配置器，快速搭建数据图表与看板，实现数据分析结果的可视化呈现。

华为云数字工厂平台的数据分析模型目前支持两类：

• 数据集：用于关联聚合多个业务模型的数据，支持多层关联、数据计算和多维度聚合统计；也支持手工创建外部数据集，来存储从外部系统采集的数据，以及进一步实现数据可视化或者与数字工厂平台的业务模型数据进行关联分析；
• 统计指标：用于实时统计或者周期性统计业务数据，业务数据可来自原始业务模型的实例数据字段值，也可来自分析模型的某个数据集字段；支持复合指标建模，即引用已有的统计指标进行组合计算。

本期结合示例，详细介绍华为云数字工厂平台的数据分析模型和数据图表视图模型的配置用法。

（一）示例场景说明

本期通过配置实现以下3个数据分析建模示例，来详细介绍分析模型的使用方法：

（1）“订单执行明细”数据集：以销售订单行为主线，串联后续生产工单、完工入库、销售发货等业务环节数据，透视订单的执行进度明细。通过该分析模型示例，介绍分析数据集模型的“关联分析”节点组件的用法；

（2）“订单执行汇总”数据集：基于订单行数据串联生产工单、完工入库和销售发货数据，然后以销售订单和订购产品为维度，汇总统计工单排产数量、完工入库数量、销售发货数量，并计算未发货数量。通过该分析模型示例，介绍分析数据集模型的“聚合分析”和“计算分析”节点组件的用法；

（3）“订单统计分析”指标集：基于订单和生产工单数据，实时统计当月销售额，按周统计每周销售数量、生产数量、产销率。通过该分析模型示例，介绍“实时统计”、“周期性统计”和“复合性”指标模型的配置用法。

（二）详细步骤说明

1.“订单执行明细”数据集建模

使用华为云数字工厂企业平台的“建模工作台>分析模型”系统功能，可创建与配置数据分析模型。

首先新建分析主题“订单分析”，方便分组管理与使用检索：

然后在“订单分析”主题下，创建数据集“订单执行明细”：

接下来需要编排数据集的取数逻辑模型：

• 配置主业务模型

“主业务模型”是数据集的数据逻辑起点，用于指定数据集的数据主线维度，即指定以哪个模型的数据为基准来关联分析相关数据，比如我们需要以订单行数据为基准，来串联透视后续业务环节数据，则数据集的“主业务模型”选择“订单”事务模型的子模型“订单行”：

选择主业务模型后，进一步勾选配置所需的数据字段范围以及数据过滤规则。

• 增加关联分析节点

在当前主业务模型节点后面可添加“关联分析”节点，用来串联获取与当前模型存在“关联或者被关联关系”的相关模型数据。“关联分析”节点可配置多个关联模型，实现同时串联到多个相关数据。

当前示例中，主业务模型“订单行”需要：

a.关联“订单”模型获取“订单金额”、“客户”、“交货日期”等字段信息；

b.关联“产品”模型获取“规格”、“库存量”等字段信息；

c.关联“生产工单”模型获取“生产工单号”、“计划产量”、“实际产量”等字段信息；

d.关联“销售发货明细”模型获取“发货数量”等字段信息。

其中配置关联模型时，默认使用“左外连接”的关联类型，即在返回的数据集结果中关联模型数据无论是否存在不影响主业务模型数据，可按需切换为“全连接”，即在返回的数据集结果中如果主业务模型数据的关联模型数据不存在，则相应的主业务模型数据会一并丢弃。

• 增加二级关联节点

在某个关联节点之后，可再添加关联节点，实现数据多级关联与追溯。

当前示例中，主业务模型“订单行”关联“生产工单”模型数据后，需要进一步：

a.通过“生产工单”关联追溯“完工入库”模型获取“入库数量”、“入库日期”等字段信息；

b.通过“销售发货明细”关联追溯“销售发货”模型获取“发货日期”等字段信息。

数据集配置完成后，右上角的“发布”按钮，自动生成相应的数据分析模型：

其中分析信息模型的“列表视图显示”和“列表过滤字段”两列支持编辑，用来设置分析模型在被报表视图组件使用时，相应字段是否作为报表显示列字段和查询字段。

2.“订单执行汇总”数据集建模

在“订单分析”主题下，创建数据集“订单执行汇总”，然后编排数据集的逻辑模型：

• 准备明细数据

编排逻辑模型，准备订单执行汇总数据集所需的明细数据，即通过订单行串联生产工单、完工入库和销售发货数据：

• 聚合汇总数据

通过添加“聚合分析”节点，实现以销售订单和产品为维度，汇总统计工单排产数量、完工入库数量和销售发货数量，配置示例如下：

• 补充计算字段

通过添加“计算分析”节点，实现计算未发货数量=订购数量-已发货数量，配置示例如下：

“订单执行汇总”数据集的逻辑模型配置结果如下：

数据集配置完成后，右上角的“发布”按钮，自动生成相应的数据分析模型。

3.“订单统计分析”指标集建模

在“订单分析”主题下，切换到“统计指标”页签，然后创建指标集“订单统计分析指标”：

“统计指标集”需要指定统计的来源明细数据模型，可选择原始业务模型，也可选择已发布的分析“数据集”模型，示例这里选择前面步骤创建的分析数据集模型“订单执行明细”。

接下来，在统计指标集下新建与配置所需的指标项：

• 实时性统计指标：“当月销售额”

对于“当天”、“当月”等实时性统计指标，在新建指标项时需要取消勾选“启用统计周期”，然后选择“统计类型”和“统计值字段”（即统计对象字段），最后配置“统计过滤规则”的条件：条件字段选择统计依据的日期字段，条件值类型选择“相对日期”，最后选择相应的日期区间，比如当天、昨天、最近1周（当周）、最近1个月（当月）等。

当前示例“当月销售额”的配置结果如下：

• 周期性统计指标：“每周销售数量”、“每周生产数量”

对于“每天”、“每周”、“每月”等周期性统计指标，在新建指标项时默认勾选“启用统计周期”，然后选择“统计类型”、“统计值字段”（即统计对象字段）、“统计时间字段”（即统计周期依据的日期字段）、“统计周期”（每小时/每天/每周/每月/每季度/每年）和“统计起始时间”（即统计指标第一个统计周期的起始时间，通常与“统计周期”有关，比如统计周期是“每周”，则统计起始时间通常选第一个统计周的周一的某个工作起始时间）。

当前示例“每周销售数量”的配置结果如下：

“每周生产数量”统计指标的配置方法同上，不再赘述。

• 复合性统计指标：“每周产销率”

在新建指标项时，“统计类型”选择“复合”，即可创建复合性统计指标。复合指标用于引用已发布的统计指标项作为原子指标进行组合计算，计算公式支持四则运算符。

复合性统计指标也分为两类：

a.周期性的复合指标：需要勾选“启用统计周期”，然后进一步选择“统计时间字段”（即统计周期依据的日期字段）、“统计周期”（每小时/每天/每周/每月/每季度/每年）和“统计起始时间”（即统计指标第一个统计周期的起始时间，通常与“统计周期”有关，比如统计周期是“每周”，则统计起始时间通常选第一个统计周的周一的某个工作起始时间）；

b.实时性的复合指标：取消勾选“启用统计周期”即可。

对于比率性的复合指标，支持配置其数据显示样式：百分比或者常规数值。当前示例“每周产销率”的配置结果如下：

“订单统计分析”指标集的最终配置结果如下：

统计指标集配置完成后，右上角的“发布”按钮，自动生效相应的数据分析模型。

（三）配置数据图表视图，验证数据分析结果

1.创建视图模型

使用华为云数字工厂企业平台的“建模工作台>视图模型”系统功能，可创建与配置数据视图模型。

首先新建场景分组和业务场景“销售>订单分析”，在可视工作台会根据场景分组和业务场景来动态构建相应的数据应用卡片：

选中业务场景“销售>订单分析”，然后在“数据看板”页签下，新建视图模型“订单执行分析”：

其中“终端范围”用来设置视图模型在哪些终端展示，可选项为全部/PC端/移动端，默认选择“全部”。

2.配置数据报表：展示订单执行明细与汇总数据集

从左侧“组件库”拖动“报表”组件到中间看板画布区，然后在右侧“属性栏”配置报表组件属性，其中：

“标题”：用来设置报表卡片的前端展示标题；

“数据模型”：用来选择报表的数据来源模型，当前示例选择前面步骤创建的数据集“订单执行汇总”或者“订单执行明细”。选定数据模型后，在右侧可进一步配置在数据报表中需要展示的字段列及其顺序；

“过滤条件”：用来设置所展示数据的过滤条件。

报表配置完成后，可右上角的“预览”按钮，查看与验证运行效果：

3.配置指标卡：展示订单统计分析指标集

从左侧“组件库”拖动“指标”组件到中间看板画布区，然后在右侧“属性栏”配置报表组件属性，其中：

“标题”：用来设置指标卡片的前端展示标题；

“数据指标”：用来选择指标卡片的数据来源指标，当前示例选择前面步骤创建的数据集“订单统计分析指标”下的相应指标项；

“显示统计环比”：针对“数据指标”选择了周期性统计指标项的情况，用来设置指标卡片上是否显示统计指标当期值与上期值的环比。

拖动指标卡片的边框可以调整其前端显示的宽度和高度，或者手工填写属性栏中的“宽度”、“高度”配置项来调整。

4.配置数据图表：每周产销率趋势图

从左侧“组件库”拖动“折线图”组件到中间看板画布区，然后在右侧“属性栏”配置报表组件属性，其中：

“标题”：用来设置折线图卡片的前端展示标题；

“数据模型”：用来选择折线图的数据来源模型，当前示例选择前面步骤创建的统计指标集“订单统计分析”；

“过滤条件”：用来设置所展示数据的过滤条件；

“维度”：用来选择折线图的X轴维度坐标值字段；

“指标字段”：用来选择折线图的Y轴指标坐标值字段；

“显示样式”：支持三种显示样式风格：普通折线、平滑线和梯形阴影折线。

拖动折线图卡片的边框可以调整其前端显示的宽度和高度，或者手工填写属性栏中的“宽度”、“高度”配置项来调整。

5.在可视工作台，使用数据图表看板

数据图表视图模型发布后，业务用户在 “可视工作台”的相应业务场景卡片下，可使用数据视图看板：

查看并验证前面配置的数据视图的使用效果：

数据视图模型也支持IoT设备时序数据可视化分析，提供时序趋势图和时间状态图两种组件：

华为云数字工厂平台，内置轻量级制造数据分析引擎与数据可视化工具，能够对制造过程的全域数据进行统一管理和分析，支持业务人员自助式开发数据可视化图表，满足中小型企业制造业务运营分析与洞察需求，实现基于数据持续驱动业务流程优化。

号外

7月7日，华为开发者大会2023 ( Cloud )将拉开帷幕，并将在国内30多个城市、海外10多个国家开设分会场，诚邀您参加这场不容错过的年度开发者盛会，让我们一起开启探索之旅！

我们将携手开发者、客户、合作伙伴，为您呈现华为云系列产品服务与丰富的创新实践，并与您探讨AI、大数据、数据库、PaaS、aPaaS、媒体服务、云原生、安全、物联网、区块链、开源等技术话题，展开全面深入的交流。

大会将汇聚全球科学家、行业领袖、技术专家、社区大咖，开设200多场开发者专题活动，为全球开发者提供面对面交流与合作的机会，共同探讨技术创新和业务发展。

大会官网：https://developer.huaweicloud.com/HDC.Cloud2023.html

参会购票：https://www.vmall.com/product/10086352254099.html?cid= 211761

参与开发者社区活动，观赏技术大咖秀、玩转技术梦工厂，有机会赢取4000开发者礼包！

欢迎关注“华为云开发者联盟”公众号，获取大会议程、精彩活动和前沿干货。

关注，第一时间了解华为云新鲜技术~

摘要：业务应用对数据库的数据请求分写请求（增删改）和读请求（查）。当存在大量读请求时，为避免读请求阻塞写请求，数据库会提供只读实例方案。通过主实例+N只读实例的方式，实现读写分离，满足大量的数据库读取需求，增加应用的吞吐量。

业务应用对数据库的数据请求分写请求（增删改）和读请求（查）。当存在大量读请求时，为避免读请求阻塞写请求，数据库会提供只读实例方案。通过主实例+N只读实例的方式，实现读写分离，满足大量的数据库读取需求，增加应用的吞吐量。

对于只读实例，如果采用单机无备节点作备份的方案，当实例出现故障或有重建需求的时候，会出现较长时间的不可用，通常需要客户做业务连接上的调整或是创建新只读实例等繁琐操作。单机只读架构如下所示，一旦单机只读发生故障，则业务中断，直至故障修复实例复位。

RDS for MySQL只读节点稳定性解决方案

为了保证业务的连续性及稳定性，RDS for MySQL在原来单机只读的基础上，推出了“高可用只读”。高可用只读在故障的容错能力、异常的应对能力方面具有比较大的优势。相比较单机只读动辄小时级的中断，高可用只读在故障倒换时，仅有秒级中断。

高可用只读架构图如下，异常发生时（比如数据库异常，虚拟机异常等），HA组件可将主只读节点的VIP（虚拟IP）自动切换到备只读节点上，从而快速恢复业务。

除高可用只读方案外，多只读实例Proxy轮询的方案也有相同效果。即购买多个只读实例，并开启数据库代理（proxy）的方案，在发生异常情况时，数据库代理自动把流量切换到其他正常只读实例，从而避免出现业务中断发生。Proxy方案架构图如下：

单机只读、高可用只读、多只读+ proxy，在应用并发连接数、异常反应、成本方面的对比如下：

以上的多方案给用户提供了灵活的可选择性，用户可以基于业务量、成本、业务运行效率等方面综合评估选择适合自己的方案。这篇文章中将重点介绍下高可用只读，未来我们还会基于proxy做一期介绍，敬请期待。

高可用只读使用办法

高可用只读在页面上的展示

如图所示，replica-86e2为单机只读实例，replica-bb17及replica-b947为高可用只读实例。需要注意的是，高可用只读实例是一组（主、备）实例，其底层会自动实现故障机制响应。

如何购买高可用只读

直接购买高可用只读

1.登录管理控制台。

2. 单击管理控制台左上角的符号，选择区域和项目。

3. 单击页面左上角的符号，选择“数据库 > 云数据库 RDS”。

4. 在“实例管理”页面，选择指定的实例，单击操作列的“更多 > 创建只读”，进入“创建只读”页面。

也可在实例的“基本信息”页面，单击实例拓扑图中，主实例下方的添加按钮，创建只读实例。

5. 在“创建只读”页面，只读模式选择“只读（高可用）”，填选实例相关信息后，单击“立即创建”。

6. 在“规格确认”页面，进行信息确认。如果需要重新选择，单击“上一步”，回到服务选型页面修改基本信息。对于按需计费的实例，信息确认无误后，单击“提交”，下发新增只读实例请求。对于包年/包月的实例，订单确认无误后，单击“去支付”，进入“付款”页面。

7. 高可用只读实例创建成功后，可以对其进行查看和管理。

只读实例转换为高可用只读

除了上述新建只读实例时选择高可用只读模式，RDS for MySQL也支持已有的单机只读升级为高可用只读，操作简单，无需进行老实例回收等操作。

说明：

非高可用只读可以转换为高可用只读实例，但高可用只读不允许转换为非高可用只读实例。

1. 登录管理控制台。

2. 单击控制台左上角的符号，选择区域和项目。

3. 单击页面左上角的符号，选择“数据库 > 云数据库 RDS”，进入RDS信息页面。

4. 在实例列表中，单击实例名称前的符号，单击非高可用只读实例的名称，进入实例的基本信息页面，即进入只读实例的管理页面。

5. 在转高可用页面，确认信息无误后，单击“立即申请”，即可将普通只读实例转换为高可用只读实例。

高可用只读使用注意事项

• 高可用只读支持的磁盘类型有：SSD云盘、本地盘以及极速型SSD；支持的规格类型有：通用型、独享型、鲲鹏通用增强型、x86通用型以及x86独享型。
• 不建议修改高可用只读实例的参数，否则会影响高可用只读的可靠性。
• 高可用只读不允许进行如下操作：修改端口、转换到非高可用只读实例。
• 创建高可用只读或是变更到高可用只读时，需要保证实例所在子网的IP充足。

关注，第一时间了解华为云新鲜技术~

在一个工程里，同时使用 Mongodb 和 MySQL, 可以吗？  不但可以，还可以使用一套 Dao 的代码。

Java ORM Bee 不但支持 JDBC 类型的数据库，还支持 Mongodb, 也支持Android,鸿蒙.

最新功能介绍:

V2.1.6 (2023・父亲节版)

1.添加开关closeDefaultParaResultRegistry,控制是否需要默认加载参数类型转换器和查询结果类型转换器
2.支持JAP新的API包jakarta.persistence.*
3.批量插入支持配置是否由框架捕获主键等异常catchModifyDuplicateException,默认不捕获
4.关闭UtilDotDateTypeConvert因少了 HH🇲🇲ss
5.fixed bug 更新配置的默认值
fixed bug NullPointerException for PreparedSql preparedValue
fixed bug for StringUtils

一行代码，即可完成某个表的分片配置：

上期发布:

支持 jdbc, android 和 NoSQL 数据库的 ORM Bee 2.1 LTS 版发布 (上传 Maven)

开发微服务更方便：

实例： https://my.oschina.net/u//blog/

Spring Cloud 微服务使用数据库更方便：Bee + Spring Boot; 轻松支持多数据源，Sharding, Mongodb.

更快的开发 Spring Cloud 微服务的新组合，Bee 整合 Spring Boot, 让你瞬间拥有两样快速开发利器！

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

Spring Boot 是用来简化新 Spring 应用的初始搭建以及开发过程。该框架使用了特定的方式来进行配置，
从而使开发人员不再需要定义样板化的配置。通过这种方式，Spring Boot 可以帮助我们进行快速应用开发。

Mongodb ORM (Bee) 详细功能列表

更多实例，请参考 Bee-exam 实例工程:

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

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

Bee，互联网新时代的 Java ORM 框架，支持 Sharding；JDBC，Android，HarmonyOS；支持多种关系型数据库，还支持 NoSQL 的 Cassandra，Mongodb 等；更快、更简单、更自动，开发速度快，运行快，更智能！

支持多种关系型数据库：MySQL,MariaDB,Oracle,H2,SQLite,PostgreSQL,SQL Server,Access 等。

下期功能预告:

你还想添加什么功能，请到评论区告诉我们

项目首页:

https://gitee.com/automvc/bee

https://github.com/automvc/bee

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

关注公众号

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

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

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

关注公众号

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

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

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

关注公众号

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

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

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

GIMP 团队最近结束了为期一周的线下“GIMP 贡献者会议”，会议地点由 Blender 基金会总部提供。

▲ GIMP 核心开发者

虽然 GIMP 3.0 的发布计划仍存在很多变数，但开发团队透露应该会在今年发布 GIMP 3.0 首个 RC——进入候选版本阶段。

目前他们正在开发 GIMP 2.99.16 版本，如果一切顺利，这个版本发布后就是 GIMP 3.0 的第一个 RC。

GIMP 3.0 最显著的变化之一是从 GTK2 过渡到 GTK3 工具包，团队在年初宣布 GIMP 的 GTK3 移植已正式完成。

GIMP 即 GNU Image Manipulation Program（GNU 图像处理程序）的首字母组成，是一个自由开源的位图图像编辑器，用于图像照片润饰及编辑、自由绘图、调整大小、裁剪、照片蒙太奇、装换图像格式以及其他专业任务。

GIMP 几乎拥有所有图象处理所需的功能，号称 Linux 下的 Photoshop。

延伸阅读

• GIMP 3.0 计划今年推出

Vitess 是一个用于部署、扩展和管理大型 MySQL 实例集群的数据库解决方案。Vitess 集 MySQL 数据库的很多重要特性和 NoSQL 数据库的可扩展性于一体。它的架构设计使得用户可以像在物理机上一样在公有云或私有云架构中有效运行。它结合并扩展了许多重要的 MySQL 功能，同时兼具 NoSQL 数据库的可扩展性。

Vitess 17 近日正式发布，在这个版本中，Vitess 引入了一些重要的改进措施，以提高系统的兼容性、性能和可用性。

GA 公告

在 v15 版本中引入的 VTTablet 设置连接池功能，在这个版本中现在默认启用。该功能简化了系统设置的管理和配置，为用户提供了更加精简和便的体验。

新的基于 Tablet Throttler 的 Topology Service 现在已 GA 并默认启用。

MySQL 兼容性改进

Vitess 现在支持额外的语句，例如 、 和 以及许多附加函数，包括比较运算符、数字函数、日期和时间函数、 函数等。

查询计划器经历了一些改进，带来了更有效的查询计划，特别是复杂的操作，如聚合、分组和排序，从而提高查询性能。执行查询时使用的评估引擎也得到了显著的改进，带来了超过 2 倍的性能改进。新版本还添加了一个基于新虚拟机的引擎，它将最终取代基于 AST 的引擎，并提供更大的性能改进（在 v17 中默认没有启用）。

在这个版本中，模式跟踪也得到了加强，使 Vitess 查询计划器能够快速检测到数据库模式的任何变化。这确保了查询能够保持最新的模式修改，提高了整体数据的一致性。

复制增强功能

Vitess 现在支持在与 Vitess 分片相对应的每个复制集中更有效的 MySQL 复制。

新版本已经为 类型增加了支持。如果你使用 TEXT、BLOB 或 JSON 列，这可以大大减少你的二进制日志的整体大小，减少磁盘 I/O 和存储以及网络 I/O 和相关 CPU 的开销。

新版本还为 MySQL 8.0 中新增加的二进制日志事务压缩增加了支持。用于压缩每个 的内容，然后将压缩的事件存储到二进制日志中。这也大大减少了磁盘 I/O 和存储以及网络 I/O，不过代价是读写日志时会有一些额外的 CPU 开销。

其他

• 流量限制改进
• VTorc 改进
• VTAdmin 改进

更多详情可查看：https://github.com/vitessio/vitess/releases/tag/v17.0.0

实时移动和 web 分析报告平台 Countly 23.06.1 发布了。

 

Countly 是一个创新、实时、开源的移动和 web 分析，推送通知和崩溃报告平台，为超过 2500 个网站和 12000 个移动应用提供支持。 它从手机、平板电脑、Apple Watch 和其他互联网连接的设备收集数据，并可视化此信息以分析应用使用情况和终端用户行为。

 

新版更新内容主要有：

修复：

• [核心] 在会话分析中添加了缺失的 %
• [核心] 添加了报表迁移到书签的脚本
• [核心] 修复了安装时的 mongodb 配置
• [仪表板] 空仪表板的本地化和样式修复
• [依赖] xml2js 修复
• [成员] 编辑成员时设置权限

企业修复：

• [cohorts] 修复了仪表板小部件与上一时期相比显示无效百分比的问题。
• [核心] 修复CE标签版本更新
• [drill] 修复“细分过滤器未显示群组”的问题
• [drill] 在书签中存储可视化类型
• [drill] byVal 查询的默认图表类型为“bar”
• [flows] 数据请求的权限检查。
• [push] 通过推送令牌和消息查询用户个人资料
• [users] 修复空白值格式

更新公告：https://github.com/Countly/countly-server/releases/tag/23.06.1

关注公众号

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

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

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

Karafka v2.1.6 现已发布。Krafka 是一个用于简化基于 Apache Kafka 的 Ruby 应用开发的框架，它允许开发者在使用异步 Kafka 消息时使用类似于标准 HTTP 约定（params 和 params_batch）的方法。Karafka 不仅可以处理传入的消息，而且还提供了用于构建接收和发送消息的复杂数据流应用程序的工具。

此版本更新内容如下：

• [改进] 为迭代器提供时间支持
• [改进] 为admin 提供时间支持
• [改进] 为consumer 提供时间支持。
• [改进] 删除客户端操作不再需要的锁。
• [改进]尝试迭代不存在的主题时引发。
• [改进] 确保 Kafka 多命令操作在 mutex 下一起运行。
• [更改] 要求 
• [更改] 要求 
• [重构] 清理迭代器代码。
• [修复] 提高 Rails 应用程序开发环境中的性能 (juike)
• [修复] 重命名为以与其他 errors 的命名保持一致。
• [修复] 修复不稳定的规范。
• [修复] 修复运行 LRJ 时自动会覆盖用户手动搜索的情况。
• [修复] 确保用户直接的和操作优先于系统操作。
• [修复] 确保和在一个底层连接不会出现 race-condition。

更新说明：https://github.com/karafka/karafka/releases/tag/v2.1.6

漏洞描述

Parse Server 是一个用于构建移动应用程序和Web应用程序开源框架，使用了 MongoDB 进行数据存储，通过 MongoDB BSON 解析器来解析和处理 BSON 数据。

受影响版本中，由于 DatabaseController#update 方法未对用户可控的参数进行过滤，攻击者可将恶意代码注入到 BSON 数据的 _bsontype 属性中(如：foo: { _bsontype: ‘Code’, code: ‘shell’ })，当 MongoDB BSON 解析器解析恶意 BSON 数据时远程执行恶意代码。

影响范围

parse-server@[6.0.0, 6.2.1)

parse-server@[1.0.0, 5.5.2)

修复方案

官方已发布 MongoDB BSON 解析器过滤恶意字符的补丁：https://github.com/parse-community/parse-server/commit/3dd99dd80e27e5e1d99bd90c7aa90

升级parse-server到 5.5.2 或 6.2.1 或更高版本

参考链接

https://www.oscs1024.com/hd/MPS-6zr0-bcsh

https://nvd.nist.gov/vuln/detail/CVE-2023-36475

https://github.com/parse-community/parse-server/security/advisories/GHSA-462x-c3jw-7vr6

https://github.com/parse-community/parse-server/commit/3dd99dd80e27e5e1d99bd90c7aa90

免费情报订阅&代码安全检测

OSCS是国内首个开源软件供应链安全社区，社区联合开发者帮助全球顶级开源项目解决安全问题，并提供实时的安全漏洞情报，同时提供专业的代码安全检测工具为开发者免费使用。社区开发者可以通过配置飞书、钉钉、企业微信机器人获取一手的情报。

免费代码安全检测工具： https://www.murphysec.com/?src=osc

免费情报订阅： https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见： https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

漏洞描述

GitLab 是一个开源的代码托管平台。

GitLab Premium/Ultimate的受影响版本中，如果启用了Merge Request的批准设置(approval settings)，当用户在分支中提交Merge Request后的5-10秒内，用户在该支中新的提交仍然会添加到Merge Request中，具有审批权限的用户同意合并后新的提交代码将会合并到受保护分支中，攻击者可利用该漏洞向Gitlab仓库中注入任意代码。

影响范围

GitLab Premium/Ultimate@[15.9, 15.9.4)

GitLab Premium/Ultimate@[15.10, 15.10.1)

GitLab Premium/Ultimate@[15.7, 15.8.5)

修复方案

升级GitLab Premium/Ultimate到 15.8.5 或 15.9.4 或 15.10.1 或更高版本

关闭Merge Request的批准设置(approval settings)功能

参考链接

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

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

https://gitlab.com/gitlab-org/gitlab/-/issues/

https://hackerone.com/reports/

免费情报订阅&代码安全检测

OSCS是国内首个开源软件供应链安全社区，社区联合开发者帮助全球顶级开源项目解决安全问题，并提供实时的安全漏洞情报，同时提供专业的代码安全检测工具为开发者免费使用。社区开发者可以通过配置飞书、钉钉、企业微信机器人获取一手的情报。

免费代码安全检测工具： https://www.murphysec.com/?src=osc

免费情报订阅： https://www.oscs1024.com/cm/?src=osc

具体订阅方式详见： https://www.oscs1024.com/docs/vuln-warning/intro/?src=osc

作者 | 把酒问青天

导读 

经过近几年的技术演进，语义模型在百度搜索场景中被广泛地应用，消耗了大量的GPU资源，模型压缩技术也随之得到大量研究和实践。通过兼顾推理性能、业务效果和迭代效率的优化目标，我们成功地将INT8量化技术大面积地应用到了搜索场景中，极大地提高了资源效能。此外，目前大模型正在被研究和应用，算力资源已经成为瓶颈，如何以更低的成本进行落地是一个非常热点的问题。基于对模型压缩技术的实践和积累，我们能够更好地助力大模型的探索和应用。

全文6287字，预计阅读时间16分钟。

01 搜索语义模型现状

ERNIE: Enhanced Representation through Knowledge Integration是百度在2019年4月的时候，基于BERT模型做的进一步优化，在中文的NLP任务上得到了state-of-the-art的结果。

近年来，ERNIE 1.0/2.0/3.0等语义模型在搜索各个重点业务场景下得到了广泛应用，包括相关性、排序等多个子方向，消耗了大量GPU资源。每个业务方向一般由多个模型组成链路来完成最终计算，整体搜索业务所涉及的模型数量多、迭代快。目前，线上全流量模型超过几百个，月级迭代近百次。语义模型的大量应用对搜索产生了巨大影响，相关业务指标对模型精度的变化非常敏感。总的来说，在模型压缩技术的工程实践中，推理性能、业务指标和迭代效率三者的优化目标应当统一考虑：

1、推理性能：采用INT8量化，ERNIE模型的性能加速平均达25%以上。其主要影响因素包含输入数据量大小（batch size、sequence length等）、隐藏节点数、非标准网络结构与算子融合优化。

2、业务指标：以某相关性场景下的ERNIE模型为例，模型输出在数值上的diff率不超过1%，在离线测试集上的评价指标达到几乎无损。

3、迭代效率：离线量化达小时级，流水线式快速产出量化模型，不阻塞模型全生命周期的相关环节（如模型多版本迭代、小流量实验、全量化推全等）。

02 模型量化简述

简而言之，模型量化就是将高精度存储（运算）转换为低精度存储（运算）的一种模型压缩技术。优势如下：

• 更少的存储开销与带宽需求：如每层权重量化后，32位比特压缩到8比特甚至更低比特，模型占用空间变小；内存访问带宽的压力自然也会变小。

• 更快的计算速度：单位时间内执行整型计算指令比浮点计算指令更多；另，英伟达安培架构芯片还有专用INT8 Tensor core。

如果我们从不同的技术角度来看待它，那么：

• 从映射函数是否是线性，分为线性和非线性。非线性量化计算较为复杂，一般主要研究线性量化，其公式如下：

  Q = clip(round(R/S) + Z)，其中R: high precision float number，Q：quantized integer number，s：scale，z：zero point。

• 从零点对应位置区分，线性量化又分为对称和非对称。

△1：对称与非对称量化

以矩阵乘为例，计算公式如下：

𝑹𝟏𝑹𝟐 = 𝒔𝟏𝑸𝟏𝒔𝟐𝑸𝟐 = 𝒔𝟏𝒔𝟐𝑸𝟏𝑸𝟐

𝑹𝟏𝑹𝟐 = 𝒔𝟏(𝑸𝟏 − 𝒛𝟏) 𝒔𝟐(𝑸𝟐 − 𝒛𝟐) = 𝒔𝟏𝒔𝟐𝑸𝟏𝑸𝟐 − 𝒔𝟏𝒔𝟐𝒛𝟐𝑸𝟏 − 𝒔𝟏𝒔𝟐𝒛𝟏𝑸𝟐 + 𝒔𝟏𝒔𝟐𝒛𝟏𝒛𝟐

在实际应用中，两者精度差异不大，对称量化在推理上更容易实现、计算更快。

• 从量化粒度上，分为逐层量化、逐组量化和逐通道量化。第一种在推理上最易实现，性能更好，一般应用在输入矩阵。第二和第三种在推理上难实现，但业务精度好，一般应用在权重矩阵。

• 从浮点矩阵中统计最大值是否截断上，分为饱和量化和非饱和量化。一般权重采用非饱和量化；输入/输出矩阵数据分布不均匀，采用饱和量化。

• 从是否参与训练上，分为训练后量化（Post-Traning Quantization，PTQ）和量化感知训练（Quantization Aware Training, QAT）。从实践上看，前者性价比最高，在精度损失可接受范围内能够快速产出量化后模型，并获得不错的性能加速；后者需要结合训练来看，往往是在PTQ造成精度损失过大时采取的进一步手段。

△图2：PTQ与QAT流程

• 从是否在推理中动态生成尺度因子，分为在线（动态）量化和离线（静态）量化。在线量化需要在推理过程中根据实际激活计算量化参数，会影响推理速度。

03 训练后量化

结合实际的应用场景，我们率先对训练后INT8量化技术进行了细致研究和大规模实践。本文中涉及到的硬件测试环境为GPU A10，CUDA 11.2，TensorRT8，工具链包括PaddlePaddle、PaddleInference、PaddleSlim等。

3.1 量化损失的精细化分析

低精度表示空间远远小于高精度表示空间，无论采用何种校准方法和校准数据，量化一定会带来不同程度上的数值误差。为了尽可能的减小误差、不影响模型业务指标，那么误差的来源和解决方案应当被全面细致地探究与分析。比如，哪些算子适合量化，每个算子量化后带来的端到端误差如何衡量，能否将误差较大的部分算子不作量化等问题。

3.1.1 量化算子的选择

通常情况下，应该优先对计算密集型算子（如mul、matmul；conv2d、depthwise_conv2d；pooling(pool2d)；concat；elementwise_add等）进行量化，对非线性算子（如softmax，tanh，sigmoid，GeLU等）和非计算密集layer的算子不做量化。

△图3：ERNIE模型经过算子融合后的FP16推理耗时占比情况

在ERNIE模型推理时，利用性能分析工具（nsight等）观察会发现，FC（对应paddle中mul）相关kernel耗时占比超过70%，BGEMM（对应paddle中matmul）相关kernel占比接近10%。因此可以重点从这两类算子入手进行量化，某线上ERNIE模型（输入数据batch size=10，max sequence length=128）的测试情况如下：

△图4：ERNIE模型FP16和INT8推理时性能加速与离线指标对比

对于FC，如果按照在推理时算子融合后网络中所处的位进行划分的话，可以人为地分成4类：

• QKV FC：推理时Q、K、V位置的3个FC会被融合在1个kernel进行计算，后续将其作为一个整体来看待。

• multi-head att-FC：经过多头注意力计算后的线性算子。

• FFN FC：FFN中的2个FC，第1个FC和激活函数（如relu）会融合成1个kernel，第2个FC是独立的kernel。

• 业务FC（未体现在示意图中）：在主体ERNIE结构后增加若干FC进行微调，应用于不同的业务场景。推理时可能也会有算子融合操作。

之所以按照上述方式进行划分：一是划分粒度更精细，便于观察和判定量化误差来源；二是尽可能与当前的推理实现逻辑保持一致，减少不必要的复杂改动。在算子类别+数量的多重组合下，更细粒度的量化，能更好地平衡性能加速和精度。

3.1.2 量化算子的敏感性

某层算子量化不当所带来的损失会在层间逐渐传递累积，模型层数越深、宽度越大，损失可能也会越大。每层内算子的量化误差对端到端指标的影响也是不一样的。在实践中，不同业务场景或者不同模型版本之间，量化后的业务指标损失不同，不一定都能在可接受范围内。这种情况下，最直接的方法是找出造成损失较大的算子，并将其跳过不做量化。被量化的算子减少，损失也会随之降低。一个12层ERNIE模型结构中至少有12*6个FC算子，绝大部分按INT8计算，只有几个仍按FP16计算，其性能加速变化不会大，模型指标损失却能更小。通过遍历每个FC算子对模型指标的敏感性大小，就能判定哪些FC可以不做量化。

△图5：量化算子的敏感性分析方法

其中，打skip quant标记的粒度与上一节中提到的FC划分方法保持一致，比如QKV内3个FC全量化或全不量化。EMD距离是指量化前后在某个小数据集上的输出值之间的分布距离，距离越小则被认为敏感性越强。

案例1：线上某ERNIE模型经过多次微调迭代后，全FC量化后的离线评价指标下降了约1.4%。利用敏感性分析方法后，跳过前8个敏感FC后，量化模型的离线评价指标损失已经很小，性能加速仍有30%以上。

△图6：全FC量化与跳过4个FC不作量化时的推理加速与离线指标对比

案例2：线上某ERNIE模型，全FC量化后的离线评价指标下降了2%左右。只跳过前1个敏感FC后，就很好地拉回了离线评价指标。

△图7：全FC量化与跳过1个FC不做量化时的推理加速与离线指标对比

通过这个方法，我们能很好地兼顾性能加速和模型精度。经过大量实验后发现，FFN内FC往往更加敏感，对业务指标的影响更大。

3.1.3 数值统计分析

量化过程本质上是寻找合适的映射函数，让量化前后的输入/出矩阵或权重矩阵更加拟合。溯源分析，输入/出矩阵和权重矩阵分布情况从根本上决定了量化效果的好坏。对于量化效果极差的模型，一般会对相关矩阵再进行可视化地数值统计分析，这样我们能够发现是否存在大量异常点，校准算法是否适用等，进而倒推出更优的解决方法。

△图8：ERNIE模型某FC权重数值分布的直方图统计

3.2 校准数据增强

校准数据的优劣是决定量化损失大小的重要因素之一。

在搜索某资讯业务场景中，使用了多头输出（一个输出打分对应一个子任务）的ERNIE模型，如下：

△图9：多头输出的模型结构示意图

针对这个模型进行量化时，采用了训练时部分数据作为校准集，结果发现子任务二的离线效果变得很差。通过分析模型训练微调的过程后，将子任务一和子任务二的训练数据进行等比例混合随机后再作为校准集，量化后的离线效果均得到了满足。

△图10：数据增强前，子任务一和子任务二在测试集上的打分分布情况

△图11：数据增强后，子任务一和子任务二在测试集上的打分分布情况

校准数据是从训练/测试数据中抽取的一个小集合，应当尽可能地保持数据分布的一致性。有些模型的离线测试集并不完善，离线指标不能很好的反应量化损失，也可能会出现离线效果与在线实验评价不一致的情况，此时可以将在线数据混入离线数据共同作为校准数据。另外，模型迭代通常是在解决bad case，校准数据中也应当注意bad case的比例。

3.3 超参自动寻优

量化包括不同的校准算法（正在使用avg、abs_max、mse、KL、hist等）、校准数据量大小（batch size/num）、是否开启偏置校准等超参，不同模型采用一组相同的量化参数，其损失变化也不同，因此超参自动寻优是必不可少的。一方面，通过自动化可以提高迭代效率；另一方面，更大的搜索空间能够获得比人工调参更优的量化后模型。

△图12：超参自动寻优方法

具体实现步骤：

• 选择初始若干组参数产出量化后模型，推理计算量化前后模型在校准集上的输出值之间的分布距离（earth mover’s distance，EMD）

• 根据超参和分布距离，构建随机树

• 随机采样若干组不同的参数组合，依次插入随机树内进行推理并计算相关距离

• 按照上一个步骤中分布距离最短的若干组参数进行实际量化

• 从第一步再循环执行，直到分布距离收敛

相比于人工调优，这种方法能够更快地搜寻到更优的量化后模型。比如：

△图13：超参自动寻优实践案例

实际上，同类型业务场景下，模型结构不会有很大变动，多次微调迭代后，超参自动寻优的参数往往会被锁定在一个小范围内。因此，我们会以类漏斗形式进行量化模型寻优，即优先在事先圈定的小范围参数内遍历量化，损失不满足要求后再进行大范围的搜索。

3.4 效果评估

搜索业务场景多种多样，离线评价方式各异。如果考虑量化方案的通用性和多维度评估能力，建设独立量化损失评价指标是必要的。类似于EMD的距离度量，打分分桶分布等方法可以作为辅助性指标来使用。

△图14：一组模型量化前后在测试集上打分/输出的数值diff情况

04 量化感知训练

相对于训练后量化，量化感知训练的模型精度更好，但流程较为复杂。一般情况下，量化感知训练作为改善训练后量化损失的进阶技术手段。

4.1 无侵入式量化训练

为了降低量化训练难度，实际上我们会采用无侵入式方法，即推理模型+训练数据。首先，对推理模型进行梯度恢复，转换成参数可训练的网络，并插入fake quant op再转换成量化后网络；然后使用量化推理模型对量化后网络进行块量化损失监督，进而降低量化损失。

4.2 全算子量化

因为精度问题，训练后量化中一般只对部分算子做量化。进一步提升推理性能，对全算子量化的话，需要和量化感知训练结合起来。全算子量化是除了mul或者matmul算子进行量化外，又增加了layer norm相关算子和中间传参过程。

△全算子与部分算子INT8量化的模型网络示意图

全算子量化在中文场景下表现出一些特异性：

• 量化后激活分布异常值多，推理端量化累计误差变大。

• QKV的输出激活scale值较大，推理端中间层输出为0，导致精度错误。

经过摸索，可行的解决方案如下：

• 先进行训练后量化，采用直方图校准方式，将激活scale值限制在某个较小范围内。

• 固定离线量化产出的激活scale值，再进行权重逐通道的量化训练。

在搜索相关性某ERNIE模型上，输入数据batch size=20，max sequence length=128时，具体实验情况如下：

△图16：全算子INT8量化的性能加速与离线评价实验结果

4.3 SmoothQuant

SmoothQuant是无训练、保持精度和通用的训练后量化方案，试图解决大模型（>6.7B）量化问题。简单来说，基于权重易量化、激活不易量化的事实，通过离线的数学等价变换将激活的难度迁移到权重上，将激活和权重都变得较容易量化。

△17：SmoothQuant核心原理 [1]

在某些量化损失较大的小模型上，我们采用量化感知训练+SmoothQuant进行了相关实验，也能有不错的表现。比如：

△图18：SmoothQuant实验结果

05 展望

目前INT8量化技术已经在线上大规模应用，使整体GPU资源利用效率得到了极大提升，也支撑了更多更复杂模型的演进。

通过总结大量实践经验和技术调研，更低比特量化（如INT4）、INT8量化+Token剪枝多压缩手段融合等正在实验和落地中。

因为线上业务子方向众多，模型多&迭代快，将实践经验抽象出通用方案势在必行，建设平台化、流水线式管理模型整个生命周期能够大幅度提高效率。同时，也可以将通用方法论应用到其他模型压缩技术的工程应用上。

近期，大模型相关技术方向的研究相当火热，模型压缩也是热点之一。初步调研后，在小模型上有效的技术手段有一部分是可以直接平迁到大模型上的，有一些则需要改进。比如，大模型训练相当复杂，量化感知训练看起来不是那么经济。根据相关业界动态，PTQ-Weight Only，LLM.int8()，SmoothQuant等技术正在被研究和使用。

——END——

参考资料：

[1]https://arxiv.org/pdf/2211.10438.pdf

推荐阅读：

如何设计一个高效的分布式日志服务平台

视频与图片检索中的多模态语义匹配模型：原理、启示、应用与展望

百度离线资源治理

百度APP iOS端包体积50M优化实践(三) 资源优化

代码级质量技术之基本框架介绍

基于openfaas托管脚本的实践

Xline是一个面向多集群的高性能分布式键值存储引擎。可以为多集群场景提供统一的数据管理，使相互访问、发现、修改变得简单方便。它还提供KV接口、多版本并发控制并兼容etcd和K8S。

Xline 是第一个基于 CURP（一种 WAN 共识协议，请阅读论文了解更多详细信息）的地理分布式一致性管理服务。它解决了跨云融合和一致性的挑战。

它提供以下功能：

• etcd 兼容 API。
• 地理分布式友好部署。
• 兼容K8s。

该项目针对多数据中心场景，旨在实现高性能的多云数据管理解决方案，这对于具有地域分布式、多活部署需求的企业至关重要。

Xline 实例由以下层组成：

• 客户端层：提供简单易用的API供客户端使用，可以大大降低使用Xline进行业务的复杂度。后续版本将实现不同语言的 Xline 客户端，目前 Xline API 与 etcd 兼容，可以使用 etcdctl 发起请求。
• 接入层：接入层主要包括客户端到服务器或者服务器到服务器之间的通信协议。Xline API 基于 gRPC 协议。
• CURP协议层：CURP协议层实现了Leader选举、日志复制、快路径和慢路径等核心算法功能，用于保证Xline多节点之间的数据一致性，提高服务可用性。CURP协议是Xline的基石和亮点。
• 功能逻辑层：该层实现Xline业务逻辑，包括典型的KV Server、Auth Server、Lease Server和Watch Server等。Client通过接入层向Xline Server发送请求，Xline Server将请求调度到特定服务器执行。
• 存储层：该层包含两个组件，Index和DB，其中Index基于BTreeMap，DB主要负责数据的持久存储。目前Xline还处于开发初期，所以DB主要是基于内存实现的。我们将在下一版本中引入持久存储。

主要特点：

• 一种面向多集群的分布式KV存储引擎。多集群场景的数据统一管理，相互访问、发现、修改简单便捷。
• 统一的数据管理系统。通过将热点数据缓存在内存中进行跨云数据访问，并提供统一的数据管理，实现数据迁移和备份的自动化。
• 高性能多数据中心共识协议。它是第一个基于WAN共识协议的地理分布式一致性管理服务。它解决了跨云融合和一致性的挑战。
• 兼容ETCD接口。提供KV接口，多版本并发控制，兼容K8S。

近日，开源共识（上海）网络技术有限公司（开源中国/Gitee）完成了 B+ 轮战略融资，此轮融资由天际资本领投，上海科创旗下海望资本联合泰达实业、浦东软件园及张江科投、君联资本、上海国际创投、瑞壹投资、容亿资本、中国移动旗下中移北京基金、中网投、国调科改、联想创投及上海科创共同出资，融资总额达 7.75 亿人民币。

至此，原股东百度（传课计算机系统〔北京〕有限公司）股比由51.54%降至14.04%，公司创始团队重新成为实际控制人，经此股份重组企业成为完全中立平台。

开源中国创立于2008年，收录全球知名开源项目近10万款，涉及几百个不同的分类，并于2022年发布了中国开源社区 Landscape，收录200+ 开源社区；同年收购日本老牌开源社区 OSDN，该社区前身为 Sourceforge.jp。

开源中国于2013年发布代码托管平台 Gitee，是目前国内领先的代码托管服务平台，并于2020年开始牵头建设工信部国家开源托管平台项目。Gitee 于2017年上线发布针对企业级的研发效能平台 Gitee 企业版。

截至目前，Gitee已经服务1000 万开发者用户、26 万家企业（含1200 家中大型私有化部署企业）以及2000多家高等院校。

开源中国董事长马越对开源中国十五年来的发展表示：“我们经历了从开源社区，到开源代码托管平台，再到今天 DevOps 研发效能平台的演进，实现了从流量平台，到可闭环商业化平台的转变。这个过程中，不仅为中国开源生态贡献了价值，也为中国企业软件研发效能贡献了商业化力量。”

马越还提到，目前海外几家知名开发者工具服务商，其总市值共计可达千亿美以上，开源中国的目标是对标海外上市公司填补国内 A 股空白。

具体来说，除代码托管服务平台对标的 GitHub 外，其他对标厂商分别为美国Atlassian（市值500亿美，曾一度突破千亿美市值）、美国 GitLab（市值80亿美）、以色列 JFrog（市值30亿美）。其中，Atlassian 是全球最大的项目管理和解决方案提供商，旗下 Jira、Confluence、Trello 几乎已经成为海外互联网公司开发过程中的基础设施，GitLab 是开源代码管理平台，JFrog 是二进制制品管理仓库，三者都被全球开发者所熟知并使用。

想要同时对标这些产品，不仅单点产品要做好，更是要做好 DevOps 全生命周期 All-in-One 的整套产品，满足开发者的一体化需求。

为了达成该目标，开源中国自2020年就开始深耕相应产品的国产替代方案，在满足开发者需求的同时，打造出一个自主创新、安全可信的本土开源软件工具与生态，减少开发者对海外开源软件的过度依赖，构建安全可控的中国信息化体系——这也是开源中国最重要的商业化路径。

目前，Gitee产品矩阵已构建了完整替代解决方案：Gitee Team 替代 Jira，Gitee Code 替代 GitLab，Gitee Pipe 替代 Jenkins，Gitee Repo 替代 JFrog，系列产品覆盖了软件工程的需求管理、代码管理、协作管理、制品管理等流程。尤其是针对私有云部署需求，Gitee 能够给国家大量政府、军工、金融、制造业等大客户提供一站式开发服务。

在马越看来，Gitee 之所以要做一站式产品，就是因为在服务中国大部分国央企类企业时，他们更希望在同一个平台里使用工具，而并非对接好几个系统和供应商。

同时，在国产替代浪潮袭来的当下，研发数据也是国家的重要资源，使用国产工具更能保障其安全性。马越表示，在互联网时代，中国1000万开发者都是国家重要的发展力量，而开源中国要做的是中国开发者的“兵工厂”。

目前，开源中国研发团队规模占总员工的85%以上，在本次战略融资后，团队将把更多资金用于产品及 AI 领域研发和商业化拓展，在软件自主可控的时代背景下，期望用两到三年的时间，成为中国资本市场的软件/AI 工程工具厂商第一股。

Mozilla 在博客中宣布：以后旗下的 Pocket 应用只能使用 Firefox 帐户登陆。

Pocket是一项免费的商业服务，允许用户保存在网络上找到的文章、对文章进行分类，以及阅读和收听这些文章。高级用户还可以获得无广告的体验、全文搜索选项等等。Pocket 还包括发现和推荐功能。

自 2017 年被收购以来，Pocket 一直是 Mozilla 产品系列的一部分。

之前 Pocket 用户有四种注册选项：可以使用 Firefox 帐户或创建一个帐户，或使用 Apple / Google 帐户登录，或使用其他电子邮箱进行注册。但使用第三方帐户登录的选项将在未来几个月内被删除，Firefox 帐户将成为唯一的选择。

从 2023 年 7 月 11 日开始，系统将提示 Pocket 用户转换到 Firefox 帐户。而在 2023 年 8 月 15 日之后，只有 Firefox 帐户才能登录。

Mozilla 对用户的疑问发布了详细的 QA 文档，里面详细解释了为何要限制仅 Firefox 登陆，以及 Apple / Google 帐户的内容如何迁移到 Firefox 帐户等内容。

ECMAScript 2023 现已获得 ECMA International 的批准。ECMAScript 是标准化的 JavaScript 语言，于 1997 年发布了第一版，现已发展成为世界上使用最广泛的通用编程语言之一。

本 Ecma 标准定义了 ECMAScript 2023 Language，是 ECMAScript 语言规范的第 14 版。

ECMAScript 2023，第 14 版，在和上引入了、、、和方法，以及上的方法；在文件开头增加了对注释的支持，以更好地促进 ECMAScript 文件的可执行；并允许在弱集合中使用大多数 Symbols 作为 keys 。

最终提案由 ECMA TC39 在 GitHub 上发布，详细阐述了今年将发布的四个功能：

Array find from last

该提案在和原型上增加了和 方法。这与 Array.prototype.find 和 Array.prototype.findIndex 的行为相同，但会从最后一个迭代到第一个

 const array = [{ value: 1 }, { value: 2 }, { value: 3 }, { value: 4 }]; array.find(n => n.value % 2 === 1); // { value: 1 } array.findIndex(n => n.value % 2 === 1); // 0 // ======== Before the proposal ===========  // find [...array].reverse().find(n => n.value % 2 === 1); // { value: 3 } // findIndex array.length - 1 - [...array].reverse().findIndex(n => n.value % 2 === 1); // 2 array.length - 1 - [...array].reverse().findIndex(n => n.value === 42); // should be -1, but 4 // ======== In the proposal ===========  // find array.findLast(n => n.value % 2 === 1); // { value: 3 } // findIndex array.findLastIndex(n => n.value % 2 === 1); // 2 array.findLastIndex(n => n.value === 42); // -1

Hashbang Grammar

Hashbang，也称为 shebang，是可执行脚本开头的字符序列，用于定义要运行的程序的解释器。当 Unix 内核的程序加载器执行 JavaScript 程序时，主机会剥离 hashbang 以生成有效源，然后再将其传递给引擎。Hashbang Grammar 提案标准化了它的完成方式。

 #!/usr/bin/env node // in the Script Goal 'use strict'; console.log(1);

 #!/usr/bin/env node // in the Module Goal export {}; console.log(1);

Symbols as WeakMap keys

该提案扩展了 WeakMap API，以允许使用 unique Symbols 作为 keys。

 const weak = new WeakMap(); // Pun not intended: being a symbol makes it become a more symbolic key const key = Symbol('my ref'); const someObject = { /* data data data */ }; weak.set(key, someObject);

Change Array by Copy

在和上提供了额外的方法，通过返回一个带有变化的新 copy 来实现对数组的改变。

 const sequence = [1, 2, 3]; sequence.toReversed(); // => [3, 2, 1] sequence; // => [1, 2, 3] const outOfOrder = new Uint8Array([3, 1, 2]); outOfOrder.toSorted(); // => Uint8Array [1, 2, 3] outOfOrder; // => Uint8Array [3, 1, 2] const correctionNeeded = [1, 1, 3]; correctionNeeded.with(1, 2); // => [1, 2, 3] correctionNeeded; // => [1, 1, 3]

具体可查看：

• https://262.ecma-international.org/14.0/
• https://www.ecma-international.org/wp-content/uploads/ECMA-262_14th_edition_june_2023.pdf

关注公众号

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

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

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

ECharts 宣布诞生 10 周年。

ECharts 是一款基于 JavaScript 的开源可视化图表库，提供了开箱即用的 20 多种图表和十几种组件，并且支持各种图表以及组件的任意组合。

ECharts 最初由百度团队开源，并于 2018 年初捐赠给 Apache 基金会，成为 ASF 孵化级项目。

2021 年，Apache ECharts 顺利毕业晋升为 ASF 顶级项目。开源中国在 ECharts 从 ASF 毕业成为顶级项目时，对 ECharts 团队进行了专访，点此查看：专访 Apache ECharts 团队：从 ASF 毕业经历了什么？

华为董事、ICT 产品与解决方案总裁杨超斌在 2023 MWC 上海展 5G Advanced 论坛上宣布：2024 年，华为将会推出面向商用的 5.5G 全套网络设备。这也标志着 ICT 行业即将迈入 5.5G 时代。

目前全球已经有超过260张5G商用网络，超过12亿5G用户，1.15亿F5G千兆用户。与此同时，新的业务形态与内容，也在持续地演进升级，包括裸眼3D等在内技术的突破，将个人沉浸式体验带上了新高度，这些新业务也对5G网络的能力提出了更高的要求。

华为倡导的5.5G时代，包含5.5G、F5.5G、Net5.5G等全面演进升级的端到端解决方案，5.5G时代一方面可以保护运营商的5G投资；另一方面将会带来10倍的网络性能提升。不仅实现下行万兆、上行千兆的峰值能力，以满足丰富多样的业务需求，同时还引入无源物联等全新技术以打开千亿物联新空间，开创新的产业愿景。

杨超斌表示：“面向5.5G时代的技术和商业验证均已就绪，标准节奏明确，5.5G时代正蓄势待发。2024年，华为将会推出面向商用的5.5G全套网络设备，为5.5G的商用部署做好准备! 华为期待和产业携手，共同开启5.5G时代新征程！”

2023年6月17日，中国开源软件推进联盟 PostgreSQL 分会在成都举办了数据库技术峰会。此次峰会以“新机遇、新态势、新发展”为主题，结合当下信创热潮、人工智能等产业变革背景，探讨 PostgreSQL 数据库在这些新机遇下的发展前景。峰会邀请众多行业大咖、学术精英、技术专家、技术爱好者等参加本次盛会，分享 PostgreSQL 数据库未来的发展机遇、新技术和新方向，推动 PostgreSQL 在中国的发展。 

拓数派作为 PG 分会的生态伙伴受邀参与本次峰会。拓数派 PieCloudDB 产品经理陈金豹在活动中发表主题演讲《云原生虚拟数仓 PieCloudDB 的架构和关键模块实现》。 

图为 拓数派 PieCloudDB 产品经理陈金豹

陈金豹认为公有云是未来数据库发展的重要方向之一，而以关系型数据库为基础的数据仓库缺乏弹性，难以利用公有云的优势；NoSQL 和数据湖的解决方案又缺乏对事务 ACID 的支持，且难以胜任复杂的数据分析场景。用户期望一个兼顾关系型数仓和公有云优势的产品，这也是 PieCloudDB Database 的设计目标。 

PieCloudDB 在计算引擎方面提供了完备的 SQL 支持、ACID 事务支持以及高效的查询优化和执行器，完全胜任各种复杂的数据分析场景；而在公有云特性方面，PieCloudDB 实现存算分离，提供弹性的计算集群，用户可以按需为计算和存储付费，实现降本增效。 

PieCloudDB 的云原生架构中包含了两条重要特性：弹性伸缩的集群和 Multi-Cluster。PieCloudDB 使用完全无状态的 Segment 节点提供极致的计算集群弹性；而多集群特性则是通过独立的系统表以及分布式锁和事务共同实现。最后，陈金豹介绍了未来 PieCloudDB 即将发布的一些关键特性：Time Travel、Branch、Data Sharing 以及已经发布的性能优化特性聚集下推和预聚集。 

2023 PostgreSQL 数据库技术峰会成都站圆满结束。PostgreSQL 历经三十多年的发展，越来越受到用户的欢迎和认可，在 DB-Engines 稳定保持在前列。根据 Stack Overflow 2023 年度调查报告，PostgreSQL 取代 MySQL 位居第一，成为年度最受欢迎的数据库。这些无一不表明了 PostgreSQL 的生态优势，拓数派作为PostgreSQL 社区生态伙伴，秉持拥抱开放的企业文化，一直以代码贡献、讲师布道、会议赞助等多种形式参与到 PostgreSQL 的社区贡献中，在未来拓数派将继续为社区贡献一份力量。 

进入拓数派B站官方账号，观看完整演讲视频。

2023年7月4日~5日，由中国信息通信研究院、中国通信标准化协会指导，中国通信标准化协会大数据技术标准推进委员会（CCSA TC601）主办的2023可信数据库发展会将于北京国际会议中心隆重召开。

大会以“自主·创新·引领”为主题，开设金融、电信、互联网、汽车四大行业分论坛以及云原生与开源数据库、搜索与分析型数据库、数据库运维及生态工具、时序时空及图数据库四大分论坛，邀请众多知名院士、行业协会领导、数据库学术大咖、产业链各环节数据库负责人、资深技术专家等共同论道新形势下数据库产业可持续、高质量发展的方法，并针对性解决上述产业发展中的痛点问题。

杭州拓数派科技发展有限公司（也称“OpenPie”）立足于国内，基础数据计算领域的高科技创新企业，也将参与本次大会。届时，拓数派 CTO 郭罡将于搜索与分析型数据库分论坛中与大家分享《PieCloudDB 云原生数仓虚拟化的演进与发展》。

1 问题现象

路由计算服务是路由系统的核心服务，负责运单路由计划的计算以及实操与计划的匹配。在运维过程中，发现在长期不重启的情况下，有TP99缓慢爬坡的现象。此外，在每周例行调度的试算过程中，能明显看到内存的上涨。以下截图为这两个异常情况的监控。

TP99爬坡

内存爬坡

机器配置如下

CPU: 16C RAM: 32G

Jvm配置如下：

-Xms20480m （后面切换到了8GB） -Xmx20480m （后面切换到了8GB） -XX:MaxPermSize=2048m -XX:MaxGCPauseMillis=200 -XX:+ParallelRefProcEnabled -XX:+PrintReferenceGC -XX:+UseG1GC -Xss256k -XX:ParallelGCThreads=16 -XX:ConcGCThreads=4 -XX:MaxDirectMemorySize=2g -Dsun.net.inetaddr.ttl=600 -Dlog4j2.contextSelector=org.apache.logging.log4j.core.async.AsyncLoggerContextSelector -Dlog4j2.asyncQueueFullPolicy=Discard -XX:MetaspaceSize=1024M -XX:G1NewSizePercent=35 -XX:G1MaxNewSizePercent=35

例行任务调度情况：

每周一凌晨2:00触发执行。上面截图，共包含了两个周期的任务。可以看到，在第一次执行时，内存直接从33%爬升至75%。在第二次执行时，爬坡至88%后，OOM异常退出。

2 问题排查

由于有两种现象，所以排查有两条主线。第一条是以追踪OOM原因为目的的内存使用情况排查，简称内存问题排查。第二条是TP99缓慢增长原因排查，简称性能下降问题排查。

2.1 性能下降问题排查

由于是缓慢爬坡，而且爬坡周期与服务重启有直接关系，所以可以排出外部接口性能问题的可能。优先从自身程序找原因。因此，首先排查GC情况和内存情况。下面是经过长期未重启的GC log。这是一次YGC，总耗时1.16秒。其中Ref Proc环节消耗了1150.3 ms，其中的JNI Weak Reference的回收消耗了1.秒。而在刚重启的机器上，JNI Weak Reference的回收时间为0.0000162秒。所以可以定位到，TP99增加就是JNI Weak Reference回收周期增长导致的。

JNI Weak Reference顾名思义，应该跟Native memory的使用有关。不过由于Native memory排查难度较大。所以还是先从堆的使用情况开始排查，以碰碰运气的心态，看是否能发现蛛丝马迹。

2.2 内存问题排查

回到内存方面，经过建哥提示，应该优先复现问题。并且在每周触发的任务都会稳定复现内存上涨，所以从调度任务这个方向，排查更容易一些。通过@柳岩的帮助，具备了在试算环境随时复现问题的能力。

内存问题排查，仍然是从堆内内存开始。多次dump后，尽管java进程的总内存使用量持续上涨，但是堆内存使用量并未见明显增长。通过申请root权限，并部署arthas后，通过arthas的dashbord功能，可以明显看到，堆(heap)和非堆(nonheap)都保持平稳。

arthas dashboard

内存使用情况，存在翻倍现象

由此可以断定，是native memory使用量增长，导致整个java应用的内存使用率增长。分析native的第一步是需要jvm开启-XX:NativeMemoryTracking=detail。

2.2.1 使用jcmd查看内存整体情况

jcmd可以打印java进程所有内存分配情况，当开启NativeMemoryTracking=detail参数后，可以看到native方法调用栈信息。在申请root权限后，直接使用yum安装即可。

jcmd结果展示

上图中，共包含两部分，第一部分是内存总体情况摘要，包括总内存使用量，以及分类使用情况。分类包括：Java Heap、Class、Thread、Code、GC、Compiler、Internal、Symbol、Native Memory Tracking、Arena Chunk、Unknown，每个分类的介绍，可以看这篇文档；第二部分是详情，包括了每段内存分配的起始地址和结束地址，具体大小，和所属的分类。比如截图中的部分，是描述了为Java heap分配了8GB的内存（后面为了快速复现问题，heap size从20GB调整为8GB）。后面缩进的行，代表了内存具体分配的情况。

间隔2小时，使用jcmd dump两次后，进行对比。可以看到Internal这部分，有明显的增长。Internal是干什么的，为什么会增长？经过Google，发现此方面的介绍非常少，基本就是命令行解析、JVMTI等调用。请教@崔立群后，了解到JVMTI可能与java agent相关，在路由计算中，应该只有pfinder与java agent有关，但是底层中间件出问题的影响面，不应该只有路由一家，所以只是问了一下pfinder研发，就没再继续投入跟进。

2.2.2 使用pmap和gdb分析内存

首先给出此方式的结论，这种分析由于包含了比较大的猜测的成分，所以不建议优先尝试。整体的思路是，使用pmap将java进程分配的所有内存进行输出，挑选出可疑的内存区间，使用gdb进行dump，并编码可视化其内容，进行分析。
网上有很多相关博客，都通过分析存在大量的64MB内存分配块，从而定位到了链接泄漏的案例。所以我也在我们的进程上查看了一下，确实包含很多64MB左右的内存占用。按照博客中介绍，将内存编码后，内容大部分为JSF相关，可以推断是JSF netty 使用的内存池。我们使用的1.7.4版本的JSF并未有内存池泄漏问题，所以应当与此无关。
pmap：https://docs.oracle.com/cd/E56344_01/html/E54075/pmap-1.html
gdb：https://segmentfault.com/a/35739

2.2.3 使用strace分析系统调用情况

这应该算是碰运气的一种分析方法了。思路就是使用strace将每次分配内存的系统调用输出，然后与jstack中线程进行匹配。从而确定具体是由哪个java线程分配的native memory。这种效率最低，首先系统调用非常频繁，尤其在RPC较多的服务上面。所以除了比较明显的内存泄漏情况，容易用此种方式排查。如本文的缓慢内存泄漏，基本都会被正常调用淹没，难以观察。

2.3 问题定位

经过一系列尝试，均没有定位根本原因。所以只能再次从jcmd查出的Internal内存增长这个现象入手。到目前，还有内存分配明细这条线索没有分析，尽管有1.2w行记录，只能顺着捋一遍，希望能发现Internal相关的线索。

通过下面这段内容，可以看到分配32k Internal内存空间后，有两个JNIHandleBlock相关的内存分配，分别是4GB和2GB，MemberNameTable相关调用，分配了7GB内存。

通过对比两个时间段的jcmd的输出，可以看到JNIHandleBlock相关的内存分配，确实存在持续增长的情况。因此可以断定，就是JNIHandles::make_weak_global 这部分内存分配，导致的泄漏。那么这段逻辑在干什么，是什么导致的泄漏？

通过Google，找到了Jvm大神的文章，为我们解答了整个问题的来龙去脉。问题现象与我们的基本一致。博客：https://blog.csdn.net/weixin_/article/details/

其中，寒泉子给出了一个复现问题的代码。在我们的代码中有一段几乎一摸一样的，这确实包含了运气成分。

jvm bug：https://bugs.openjdk.org/browse/JDK-

就是上面这个bug，频繁使用MethodHandles相关反射，会导致过期对象无法被回收，同时会引发YGC扫描时间增长，导致性能下降。

3 问题解决

由于jvm 1.8已经明确表示，不会在1.8处理这个问题，会在java 重构。但是我们短时间也没办法升级到java 。所以没办法通过直接升级JVM进行修复。由于问题是频繁使用反射，所以考虑了添加缓存，让频率降低，从而解决性能下降和内存泄漏的问题。又考虑到线程安全的问题，所以将缓存放在ThreadLocal中，并添加LRU的淘汰规则，避免再次泄漏情况发生。

最终修复效果如下，内存增长控制在正常的堆内存设置范围内（8GB），增涨速度较温和。重启2天后，JNI Weak Reference时间为0.0001583秒，符合预期。

4 总结

Native memory leak的排查思路与堆内内存排查类似，主要是以分时dump和对比为主。通过观察异常值或异常增长量的方式，确定问题原因。由于工具差异，Native memory的排查过程，难以将内存泄漏直接与线程相关联，可以通过strace方式碰碰运气。此外，根据有限的线索，在搜索引擎上进行搜索，也许会搜到相关的排查过程，收到意外惊喜。毕竟jvm还是非常可靠的软件，所以如果存在比较严重的问题，应该很容易在网上找到相关的解决办法。如果网上的内容较少，那可能还是需要考虑，是不是用了过于小众的软件依赖。

在开发方面，尽量使用主流的开发设计模式。尽管技术没有好坏之分，但是像反射、AOP等实现方式，需要限制使用范围。因为这些技术，会影响代码的可读性，并且性能也是在不断增加的AOP中，逐步变差的。另外，在新技术尝试方面，尽量从边缘业务开始。在核心应用中，首先需要考虑的就是稳定性问题，这种意识可以避免踩一些别人难以遇到的坑，从而减少不必要的麻烦。

作者：京东物流 陈昊龙

来源：京东云开发者社区

本篇文章中我们将对机器学习做全面的了解与介绍，其中第一章 初识机器学习分为上下两个小章节，对机器学习是什么、机器学习由来以及机器学习的理论等展开说明。目的是能让即便完全没接触过机器学习的人也能在短时间对机器学习有一个全面了解。后续将推出机器学习的进阶内容，包括经典基础篇（线性模型、决策树、集成学习、聚类等），实战进阶篇（特征工程、模型训练与验证、融合与部署等）。本篇为第一章 初识机器学习（上），我们从这里开始，开启一个全新的学习旅程。

1 机器学习描述

1.1 机器学习是什么？

机器学习（Machine Learning，ML）是使用统计（或数学）技术从观察到的数据中构建模型（或系统）的一个计算机科学领域。机器学习用计算机程序模拟人的学习能力，从样本数据中学习得到知识和规律，然后用于实际的推断和决策。

从广义上来说，机器学习能够赋予“机器”学习的能力，使其实现直接编程无法完成的工作。但从实践意义上来说，机器学习是利用数据训练出模型，并使用模型进行预测的一种方法。“训练”与“预测”是机器学习的两个过程，“模型”则是过程中间的输出结果，“训练”产生“模型”，“模型”指导 “预测”。接下来我们把机器学习的过程与人类对历史经验归纳演绎的过程做个比对。

机器学习中的“训练”与“预测”过程可以对应到人类的“归纳”和“演绎”过程。通过这样的对应，我们可以发现，机器学习的思想并不复杂，仅仅是对人类在生活中学习成长的一个模拟。由于机器学习不是基于编程形成的结果，因此它的处理过程不是因果的逻辑，而是通过归纳思想得出的相关性结论。

人类对历史经验归纳过程

人类在成长、生活过程中积累了很多的历史与经验。人类定期地对这些经验进行“归纳”，获得了生活的“规律”。当人类遇到未知的问题或者需要对未来进行“推测”的时候，人类将使用这些“规律”，对未知问题与未来进行“演绎”，从而指导自己的生活和工作。

1.2 机器学习的应用范围

机器学习应用广泛，在各方面都有其施展的空间，包括：数据分析与挖掘、模式识别、虚拟助手和交通预测等。从行业来看，在金融领域（检测信用卡欺诈、证券市场分析等）、互联网领域（自然语言处理、语音识别、搜索引擎等）、医学领域、自动化及机器人领域（无人驾驶、信号处理等）、游戏领域、刑侦领域等也都有所涉及。

1.2.1 数据分析与挖掘

“数据挖掘”和”数据分析”通常被相提并论，但无论是数据分析还是数据挖掘，都是在帮助人们收集与分析数据，使之成为信息并做出推测与判断。因此可以将这两项合称为数据分析与挖掘。数据分析与挖掘是机器学习技术和大数据存储技术结合的产物，利用机器学习手段分析海量数据，同时利用数据存储机制实现数据的高效读写。机器学习在数据分析与挖掘领域中拥有无可取代的地位，2012年Hadoop进军机器学习领域就是一个很好的例子。

1.2.2 模式识别

模式识别的应用领域广泛，包括计算机视觉、医学图像分析、光学文字识别、自然语言处理、语音识别、手写识别、生物特征识别、文件分类、搜索引擎等，而这些领域也正是机器学习大展身手的舞台，因此模式识别与机器学习的关系越来越密切。

1.2.3 虚拟助手

Siri，Alexa，Google Now都是虚拟助手。在交互过程中，虚拟助手会协助查找信息，搜索相关历史行为，或向其他资源（如电话应用程序）发送命令收集更多信息，以满足人们提出的需求。

1.2.4 交通预测

生活中我们经常使用GPS导航服务，机器学习能够帮助我们预测交通堵塞。当前高德地图，腾讯地图等都应用了机器学习技术，识别拥挤路段，规划最优路线。

2 机器学习发展史

2.1 浅层学习阶段

1. 1957年，Rosenblatt发明了感知机（Perceptron），是神经网络的雏形，同时也是支持向量机的基础，在当时引起了不小的轰动。
2. 1959年，IBM的写出了可以学习的西洋棋程序，并在 IBM Journal of Research and Development期刊上发表了一篇名为《Some Studies in Machine Learning Using the Game of Checkers》的论文中，定义并解释了一个新词——机器学习（Machine Learning，ML）。将机器学习非正式定义为“在不直接针对问题进行编程的情况下，赋予计算机学习能力的一个研究领域”。
3. 1960年，Widrow发明了Delta学习规则，即如今的最小二乘问题，立刻被应用到感知机中，并且得到了一个极好的线性分类器。
4. 1970年，Seppo Linnainmaa首次完整地叙述了自动链式求导方法（Automatic Differentiation，AD），是著名的反向传播算法（Back Propagation，BP）的雏形，但在当时并没有引起重视。
5. 1974年，Werbos首次提出把BP算法的思想应用到神经网络，也就是多层感知机（Multilayer Perception，MLP），并在1982年实现，就是现在通用的BP算法，促成了第二次神经网络大发展。
6. 1985-1986年，Rumelhart，Hinton等许多神经网络学者成功实现了实用的BP算法来训练神经网络，并在很长一段时间内BP都作为神经网络训练的专用算法。
7. 1986年，J.R.Quinlan提出了另一个同样著名的ML算法—决策树算法（Iterative Dichotomiser 3，ID3），决策树作为一个预测模型，代表的是对象属性与对象值之间的一种映射关系，而且紧随其后涌现出了很多类似或者改进算法，如ID4，回归树，CART等。
8. 1995年，Yan LeCun提出了卷积神经网络（Convolution Neural Network，CNN），受生物视觉模型的启发，通常有至少两个非线性可训练的卷积层，两个非线性的固定卷积层，模拟视觉皮层中的V1，V2，Simple cell和Complex cell，在手写字识别等小规模问题上，取得了当时世界最好结果，但是在大规模问题上表现不佳。
9. 1995年，Vapnik和Cortes提出了强大的支持向量机（Support Vector Machine，SVM），主要思想是用一个分类超平面将样本分开从而达到分类效果，具有很强的理论论证和实验结果。至此，ML分为NN和SVM两派。
10. 1997年，Freund和Schapire提出了另一个坚实的ML模型AdaBoost，该算法最大的特点在于组合弱分类器形成强分类器，可以形象地表述为：“三个臭皮匠赛过诸葛亮”，分类效果比其它强分类器更好。
11. 2001年，随着核方法的提出，SVM大占上风，它的主要思想就是通过将低维数据映射到高维，从而实现线性可分。至此，SVM在很多领域超过了NN模型。除此之外，SVM还发展了一系列针对NN模型的基础理论，包括凸优化、范化间隔理论和核方法。
12. 2001年，Breiman提出了一个可以将多个决策树组合起来的模型随机森林（Random Forest，RF），它可以处理大量的输入变量，有很高的准确度，学习过程很快，不会产生过拟合问题，具有很好的鲁棒性。
13. 2001年，Hochreiter发现使用BP算法时，在NN单饱和之后会发生梯度损失（梯度扩散）。简单来说就是训练NN模型时，超过一定的迭代次数后，容易过拟合。NN的发展一度陷入停滞状态。

2.2 深度学习阶段

二十一世纪初，学界掀起了以“深度学习”为名的热潮。所谓深度学习？狭义地说就是“很多层”的神经网络。在若干测试和竞赛上，尤其是涉及语音、图像等复杂对象的应用中，深度学习技术取得了优越性能。以往机器学习技术在应用中要取得好性能，对使用者的要求较高；而深度学习技术涉及的模型复杂度非常高，以至于只要下工夫“调参”，只要把参数调节好，性能往往就好。因此，深度学习虽缺乏严格的理论基础，但它显著降低了机器学习应用者的门槛，为机器学习技术走向工程实践带来了便利。那么它为什么此时才热起来呢？有两个原因，一是数据量增大了，二是计算能力强了。深度学习模型拥有大量参数，若数据样本少，则很容易“过拟合”。如此复杂的模型、如此大的数据样本，若缺乏强力计算设备，根本无法求解。恰恰人类进入了大数据时代，数据储量与计算设备都有了大发展，才使得深度学习技术又焕发一春。

1. 2006年，Hinton和他的学生在《Nature》上发表了一篇深度置信网络（Deep Belief Network，DBN）的文章，从此开启了深度学习（Deep Learning，DL）阶段，掀起了深度神经网络即深度学习的浪潮。
2. 2009年，微软研究院和Hinton合作研究基于深度神经网络的语音识别，历时两年取得成果，彻底改变了传统的语音识别技术框架，使得相对误识别率降低25%。
3. 2012年，Hinton又带领学生在目前最大的图像数据库ImageNet上，基于深度神经网络对图分类问题取得了惊人的结果，将Top5错误率由26%大幅降低至15%。（ImageNet 是一个计算机视觉系统识别项目，是目前世界上图像识别最大的数据库。是美国斯坦福的计算机科学家，模拟人类的识别系统建立的。能够从图片识别物体。）
4. 2012年，由人工智能和机器学习顶级学者Andrew Ng和分布式系统顶级专家Jeff Dean领衔的梦幻阵容，开始打造Google Brain项目，用包含16000个CPU核的并行计算平台训练超过10亿个神经的深度神经网络，在语音识别和图像识别等领域取得了突破性的进展。该系统通过分析YouTube上选取的视频，采用无监督的方式训练深度神经网络，可将图像自动聚类。在系统中输入“cat”后，结果在没有外界干涉的条件下，识别出了猫脸。
5. 2012年，微软首席研究官Rick Rashid在21世纪的计算大会上演示了一套自动同声传译系统，将他的英文演讲实时转换成与他音色相近、字正腔圆的中文演讲。同声传译需要经历语音识别、机器翻译、语音合成三个步骤。该系统一气呵成，流畅的效果赢得了一致认可，深度学习则是这一系统中的关键技术。
6. 2013年，Google收购了一家叫DNN Research的神经网络初创公司，这家公司只有三个人，Geoffrey Hinton和他的两个学生。这次收购并不涉及任何产品和服务，只是希望Hinton可以将深度学习打造为支持Google未来的核心技术。同年，纽约大学教授，深度学习专家Yann LeCun加盟Facebook，出任人工智能实验室主任，负责深度学习的研发工作，利用深度学习探寻用户图片等信息中蕴含的海量信息，希望在未来能给用户提供更智能化的产品使用体验。
7. 2013年，百度成立了百度研究院及下属的深度学习研究所（Institute of Deep Learning，IDL），将深度学习应用于语音识别和图像识别、检索，以及广告CTR预估（Click-Through-Rate Prediction，CTR），其中图片检索达到了国际领先水平。
8. 2014年，谷歌宣布其首款成型的无人驾驶原型车制造完毕，将会在2015年正式进行路测。
9. 2016年，谷歌旗下DeepMind公司开发的人工智能程序AlphaGo击败围棋职业九段选手李世石。
10. 2017年，DeepMind团队公布了最强版AlphaGo，代号AlphaGo Zero，它能在无任何人类输入的条件下，从空白状态学起，自我训练的时间仅为3天，自我对弈的棋局数量为490万盘，能以100:0的战绩击败前辈。

3 易混淆领域梳理

3.1 机器学习与人工智能

人工智能（Artificial Intelligence，AI）是计算机科学的一个分支，它企图了解智能的本质，生产出一种能比肩人类，并做出智能反应的机器。我们都知道机器学习是人工智能最重要的一种实现方法，但机器学习并不是人工智能一开始就采用的方法。人工智能的发展主要经历了逻辑推理，专家系统，机器学习三个阶段。

1. 第一阶段的重点是逻辑推理，例如数学定理的证明，这类方法采用符号逻辑来模拟人类智能。
2. 第二阶段的重点是专家系统，这类方法为各个领域的问题建立专家知识库，利用这些知识来完成推理和决策。比如将医生的诊断经验转化成一个知识库，然后用这些知识对病人进行诊断。
3. 第三阶段的重点即为机器学习，如今的人工智能主要依赖的不再是逻辑推理和专家系统，而是建立在机器学习的基础上解决复杂问题。无论是基于数学的机器学习模型，还是基于神经网络的深度学习模型，都活跃在如今大多数人工智能应用程序之中。

3.2 机器学习与深度学习

深度学习（Deep Learning，DL）是机器学习的一个重要分支，深度学习和机器学习的关系属于继承和发展的关系。在很多人工智能问题上，深度学习的方法加上大数据的出现以及计算机运行速度的提高，更突出了人工智能的前景。比如，自动驾驶汽车，足以彻底改变我们的出行方式，它的实现就需要深度学习的图像识别技术，需要用到卷积神经网络（Convolutional Neural Networks, CNN）来识别马路上的行人、红绿灯等。
为了更清晰的认识深度学习，我们首先介绍神经网络（Neural Networks, NN），顾名思义，它是一种模仿动物神经网络行为特征，进行分布式并行信息处理的算法数学模型。神经网络有输入层、隐藏层（中间层）以及输出层，其中输入层负责神经网络的输入，输出层负责产生输入的映射。机器学习中的逻辑回归，可以看作是一层的神经网络，即除了输入层、输出层之外只有一个隐藏层。

而深度学习，就是指神经网络使用了很多隐藏层。

那么深度学习的每一层都在学什么？？

当你输入一张脸部的照片时，神经网络的第一中间层，可以看成是一个特征探测器或者边缘探测器，它会去找这张照片的各个边缘（第一张图片）；第二中间层又把照片里组成边缘的像素们放在一起看，然后它可以把被探测到的边缘组合成面部的不同部分（第二张图片），有眼睛、鼻子等；最后再把这些部分放在一起，比如鼻子眼睛嘴巴，就可以识别或者探测不同的人脸（第三张图片）。

3.3 机器学习与数据挖掘

数据挖掘（Data Mining，DM）是指从大量的数据中搜索隐藏于其中信息的过程。机器学习是数据挖掘的重要工具之一，但数据挖掘不仅仅要研究、拓展、应用一些机器学习方法，还要通过许多非机器学习技术解决大规模数据与数据噪音等实际问题。大体上看，数据挖掘可以视为机器学习和大数据的交叉，它主要利用机器学习提供的技术来分析海量数据，利用大数据技术来管理海量数据。

3.4 机器学习与统计学

1.统计学简述

统计学（Statistics）是基于数据构建概率统计模型并运用模型对数据进行分析与预测的一门学科。统计学依托背后的数学理论，在远早于机器学习大爆发的几十年，率先从解释因果的角度，努力寻找最优函数（或模型）。统计学里最重要的两个部分是回归分析和假设检验。其他的方法或者技术在统计学这个大框架下，最终也是为了这两者服务的。回归分析提供了解释因果的武器，假设检验则给这项武器装上了弹药。单纯的线性回归用最小二乘法求解逼近事实的真相，再使用显著性检验，检测变量的显著性、模型的显著性、模型的拟合精度。当然是否属于线性，也可以使用假设检验的方法检测。非线性回归的问题，使用极大似然估计或者偏最小二乘回归求解模型，后续的显著性检验仍然是一样的思路。

2.机器学习与统计学对比

统计学是个与机器学习高度重叠的学科，统计学近似等于机器学习。但是在某种程度上两者是有分别的，这个分别在于：统计学是理论驱动，对数据分布进行假设，以强大的数学理论解释因果，注重参数推断，侧重统计模型的发展与优化；机器学习是数据驱动，依赖于大数据规模预测未来，弱化了收敛性问题，注重模型预测，侧重解决问题。

3.5 机器学习算法与“普通”算法的异同

这里我们以《算法导论》中所诠释的算法作为机器学习算法的比较对象。其相同点，两者的目的都是通过制定目标，增加约束，求得最优的模型。不同点是《算法导论》里的“算法”，本质上是如何更有效率地求解具有精确解的问题。效率，可以是计算时间更短，也可以是计算过程所需要的空间更少。而机器学习算法要解决的问题一般没有精确解，也不能用穷举或遍历这种步骤明确的方法求解。这里需要强调的是“学习”这个属性，即希望算法本身能够根据给定的数据或变化的计算环境而动态地发现新的规律，甚至改变机器学习算法的逻辑和行为。

作者：京东物流 星火团队

来源：京东云开发者社区

2023年5月，由 Stackoverflow 发起的2023年度开发者调查数据显示，PostgreSQL 已经超越 MySQL 位居第一，成为开发人员首选。PostgreSQL 在国内的热度也越来越高。6月17日，PostgreSQL 数据库技术峰会在成都顺利召开。本次大会以“新机遇、新态势、新发展”为主题，邀请众多行业大咖参与本次活动。PieCloudDB 产品总监陈金豹也受邀在大会中发表演讲《云原生虚拟数仓 PieCloudDB 的架构和关键模块实现》。 

随着云计算时代的到来，云平台提供了近似无限丰富的计算资源，同时也使得计算成本极大的降低，释放出数据计算产生智能的更多机会。早在2019年，Gartner 便做出预测：数据库市场的未来在云上。随着云计算技术的发展，企业也都在向这一趋势靠拢，越来越多的将自己的业务数据往云上迁移。我们相信数据库的未来在云上，这也是我们打造 PieCloudDB 这款云原生数据仓库的原因。

PieCloudDB 于2022年10月正式问世。它是一款云原生分布式数据仓库，提供完备的 SQL 语言支持，高效的分布式计算能力和完备的事务支持。同时又实现了单一数据集的多集群，秒级的弹性和只为必要的计算和存储付费的能力。 

1. Why We Need PieCloudDB？

1.1 NoSQL 和数据湖已不能满足用户的分析需求

在过去的很长一段时间里，NoSQL + 数据湖解决方案在数据分析领域占据了主流市场，而 Hadoop、HDFS 等 NoSQL 数据库也是主要的数据分析平台。然而，随着 Cloudera 宣布停止对 CDH 技术支持，对 Hadoop 等 NoSQL 平台的质疑声音也越来越大。

这一现象正是因为 NoSQL + 数据湖体系在复杂查询支持、高并发隔离性和一致性等重要数据分析特性方面存在明显不足，现有基于标准 SQL 的 BI 工具难以集成，且 NoSQL 本身对高级分析（如图形分析、地理信息分析等）的支持较弱。因此，NoSQL 开始被人们贴上“过时”的标签，不再占据数据分析领域的主要市场份额。 

此外，基于 NoSQL 和数据湖的基础设施所需的分析工具不容易集成和部署。使用数据湖进行数据分析需要整合部署多个组件，而这需要大量的开发工作。由于缺乏对 ANSI SQL 的支持，用户通常需要具备专门的技术技能，并且需要承担较高的技术和成本要求。此外，平台所需的专用引擎/工具（如图形数据库）往往难以与记录系统集成，降低了数据分析的可操纵性和创新性。

这些限制和挑战推动了对更强大、更易于集成、更易于使用的数据分析平台的需求。企业和组织越来越倾向于采用基于标准 SQL 的分析平台，这些平台能够满足用户广泛的分析功能、易于集成和部署等需求，并且与现有的数据存储和处理技术相兼容，对技术和成本的要求更低。

1.2 以关系型数据库为基础的数据仓库很难适应云环境

包括 Teradata、Greenplum 等众多主流传统数据仓库都是以关系模型来组织数据的关系型数据库。这些数据仓库具有许多优点，包括良好的 SQL 兼容性、高效运行复杂查询以及支持事务 ACID 特性。然而，这些传统的 MPP 数据库也存在一些缺陷，例如弹性性能较差、高可用性方面不够满足要求、数据孤岛等问题。

这些问题导致传统的数据仓库在云环境中无法充分利用公有云的优势。公有云相对于私有环境具有许多优势，其中最显著的两个是：

• 近乎无限的弹性计算资源：公有云提供了弹性计算资源，用户可以根据实际需求按需分配资源，并根据需要进行弹性扩缩容。用户可以根据业务需求申请所需的计算资源，而不需要维护和管理自己的硬件基础设施。
• 廉价且无限容量的对象存储：公有云提供廉价且具有几乎无限容量的对象存储。对象存储的价格相对较低，可以为用户提供大规模的存储容量，帮助用户降低成本并提高效率。 

为了更好地适应云环境并充分利用公有云的优势，新一代的数据仓库逐渐崛起。新一代云原生数据仓库具有云原生的架构设计，能够更好地利用公有云的弹性计算和对象存储能力。它们可以在公有云中快速部署和扩展，并提供高性能的数据处理和分析能力，以满足现代数据分析的需求。 

1.3 一个兼顾关系型数仓和公有云优势的产品

用户需要一个能够兼顾关系型数仓和公有云优势的产品，来适应云时代的到来。计算引擎方面，需要具有关系型数仓的众多优势，能够具备支持完备的 SQL 语言，具有高效的分布式计算能力，且能够具有完备的事务 ACID 特性。公有云特性方面，实现存算分离，提供弹性的计算集群，让用户得以只为必要的计算付费，充分利用公有云带来的优势。这就是 PieCloudDB 的设计目标。

2. PieCloudDB 能给用户带来什么？

作为新一代的云原生数据仓库，PieCloudDB 实现了云上数仓计算与存储的分离，兼顾了传统关系型数仓的众多优势和公有云带来的众多利好。

2.1 对 SQL 的完备支持

PieCloudDB 对 PostgreSQL 进行了重大改进，实现了分布式计算和存算分离的功能。并对锁、事务、日志、系统表和用户表的存储等模块进行了彻底重写，带来了颠覆性的变革。同时，PieCloudDB 也保留了 PostgreSQL 对 SQL 标准的完整支持，包括复杂查询如聚合（Agg）、子计划（Subplan）、子链接（Sublink）、外连接查询（Outer Join）、窗口聚合函数（Window agg）和物化视图（Materialized View）等。这些改进使得 PieCloudDB 能够提供更高效、更强大的查询功能，同时保持与 SQL 标准的兼容性。

2.2 高效的查询优化和与之匹配的执行器

PieCloudDB 实现了专为复杂查询设计的优化器和与之匹配的高效执行器。

• 专为复杂查询设计的优化器

PieCloudDB 的优化器提供了一系列全面的逻辑优化功能，其中包括谓词下推、子查询子连接提升和外连接消除等。此外，优化器基于纯粹的代价模型进行深度优化，在多阶段聚集过程中对每个节点进行代价估算，并利用动态规划等算法生成多条路径，最终选择代价最低的路径来执行查询。这些功能旨在提高查询性能和效率，从而优化 PieCloudDB 的查询执行过程。

作为一款分布式数据库，PieCloudDB 需要实现众多分布式运算，包括多次数据重分布（reshuffle）和分布式聚合运算（agg）。为了能够在跨表查询时进行高效的分布式表连接，PieCloudDB 的优化器需要全面描述数据分布特性，以便进行分布式代价估算。

通过全面的数据分布特性描述，PieCloudDB 的优化器能够考虑到数据在不同节点上的分布情况，从而更准确地估算跨表查询的代价。这使得优化器能够生成高效的查询计划，避免不必要的数据重分布操作，提高查询性能和效率。

• 分布式环境高效执行器

为了配合专为复杂查询设计的优化器，PieCloudDB 实现了高效的执行器，以在分布式环境下执行查询操作。通过采用多组别多阶段执行模型，并进行大量的数据交换，PieCloudDB 的执行器能够在分布式环境下高效地执行查询操作。这种执行模型可以充分利用分布式系统的计算资源，并提高查询的并行性和整体性能。同时，通过与优化器的紧密配合，PieCloudDB 可以根据优化器生成的查询计划特性来优化执行器的执行策略，进一步提高查询性能和效率。

2.3 对事务（ACID）的完备支持

PieCloudDB 提供了对事务的完备支持，包括事务的 ACID 特性：原子性、一致性、隔离性和持久性。

• 原子性（Atomicity）：PieCloudDB 确保事务中的操作要么全部成功完成，要么全部失败回滚。如果一个事务中的某个操作失败，那么该事务中的所有操作都将被回滚，数据库状态会回到事务开始之前的状态，保持数据的一致性。
• 一致性（Consistency）：PieCloudDB 在事务提交之前，会检查事务的操作是否符合预定义的约束和规则，以确保数据库的一致性。如果事务执行完成后，数据库仍然保持一致性，那么该事务被认为是成功的。
• 隔离性（Isolation）：PieCloudDB 支持两个常用的隔离级别：Read Committed（读提交）和 Repeatable Read（可重复读）。在 Read Committed 级别下，事务只能看到其他事务已经提交的修改，而在 Repeatable Read 级别下，事务在整个事务过程中能够看到一个一致的快照，不受其他并发事务的修改影响。
• 持久性（Durability）：PieCloudDB 确保一旦事务提交成功，其对数据库的修改将永久保存，即使发生系统故障或崩溃。这是通过将事务日志记录在稳定的存储介质上来实现的，以便在恢复过程中可以重放事务日志。

通过提供对事务 ACID 特性的完备支持，PieCloudDB 提供了可靠和一致的数据管理机制。无论是在并发环境中还是在面临故障的情况下，PieCloudDB 都能确保数据的完整性和可靠性。

2.4 极致的计算集群弹性

PieCloudDB 具备极致的计算集群扩缩容能力，能够实现计算集群快速的扩展和收缩操作。PieCloudDB 的 Executor 节点并不持有持久化的数据，扩展和收缩操作不涉及数据的移动。此外，Executor 节点也不直接访问系统表、事务和锁。在进行计算集群的扩展时，PieCloudDB 只需要在新的虚拟机节点上部署二进制并向数据服务注册。这样的设计确保了扩缩容操作的高效性。

PieCloudDB 为用户提供了一个独立的计算池，该计算池是为了支持快速的扩缩容而准备的。在这个计算池内，PieCloudDB 可以在一定范围内实现秒级的扩容和收缩操作。这意味着当用户需要增加计算资源时，PieCloudDB 可以迅速添加新的计算节点，使得整个集群能够处理更多的并发请求。反之，当用户需要减少计算资源时，PieCloudDB 也能够快速地收缩计算节点，以节省成本和资源。

2.5 多集群与高可用

PieCloudDB 支持多集群。用户可以在同一个数据集上起多个集群。在生产环境中，常常会遇到不同的部门对集群大小的需求不一样。这种情况下，如果只有单集群，就需要根据最大的集群需求来创建集群，造成资源的浪费。在多集群场景下，不同部门可根据自身需求创建不同大小的集群，任务结束时可以关闭集群，多个集群访问同一个数据集，并共享同一个 ACID 特性。

由于 PieCloudDB Executor 是无状态的，当某个 Executor 出现故障，Coordinator 会执行下个 Query 时，由剩下的 Executor 来执行任务。此过程中，用户无感知，不会对业务产生影响。

通过这些特性，PieCloudDB 在 OLAP 场景下，可以让用户像使用 PostgreSQL 一样使用 PieCloudDB。用户只需为已经发生的计算和存储付费。用户可以按需启动和关闭多个不同大小的集群，以适应不同类型的任务，从而取得性能和开发效率的平衡。

3. PieCloudDB 云原生架构的实现

为了适应云环境，PieCloudDB 实现了弹性伸缩的集群和多集群这两个主要的云原生特性，打造了完全无状态的 Executor 节点、独立的系统表和分布式的锁。

3.1 虚拟数仓

PieCloudDB 为了实现在扩缩容过程中无需移动数据，将用户数据分离到对象存储中。此外，Executor 节点上不存储系统表、事务和锁信息，而是依赖 Coordinator 来解决这些问题，从而使 Executor 节点成为无状态的节点，实现秒级扩缩容。

为了实现 Multi-master 架构，并实现有状态的 Coordinator 节点，PieCloudDB 使用数据服务来完成这些功能。系统表以 Key-Value 的形式存储在 KV 数据库 FoundationDB 中，并通过 FoundationDB 的短时间、小体量的事务特性，实现了分布式锁和分布式事务。这样，PieCloudDB 能够在Coordinator 节点上处理分布式锁和事务，并保证系统的一致性和可靠性。

通过这一系列的设计和操作，PieCloudDB 实现了完全无状态的虚拟数仓。用户可以根据需要创建和关闭虚拟数仓，而在扩缩容过程中无需移动数据，并且能够快速进行节点的扩展和收缩。这使得 PieCloudDB 能够高效地适应不同规模和负载的需求，并提供灵活的数据存储和计算资源管理。

• 系统表：mStore

PieCloudDB 将组以 Key-Value 的形式存储到 FoundationDB 中，并利用FoundationDB Key 的自然排序来实现索引。在 PieCloudDB 中，每个组都被编码为一个 Key-Value 对，其中 Key 表示组的索引信息，而 Value 则包含了组的数据内容。通过利用 FoundationDB Key 的自然排序，可以高效地进行范围查询和索引查找，从而实现快速的数据检索和访问。

为了实现多版本并发控制，PieCloudDB 使用了 Xmin、Xmax 和 cid 等机制。Xmin 和 Xmax 记录了事务对组的可见性信息，其中 Xmin 表示最早可见的事务，而 Xmax 表示最晚可见的事务。cid（Commit ID）则表示事务的提交标识。通过这些机制，PieCloudDB 可以实现并发事务的隔离性和一致性，并支持多版本的查询和回滚操作。

通过将组存储为 Key-Value 对，利用 FoundationDB 的自然排序和采用 MVCC 机制，PieCloudDB 能够高效地处理数据的存储、索引和并发访问，从而提供高性能和可靠的数据库服务。

• 数据表：oStore

PieCloudDB 通过将数据分离到对象存储（如S3）上，利用 oStore 构建了对象存储上的用户表。由于对象存储本身只支持插入（insert）和删除（delete）操作，而不支持更新（update）和追加（append）操作。PieCloudDB 在 mStore 中创建辅助表来实现 MVCC（多版本并发控制）的特性。

在 mStore 的辅助表中，每 个 tuple 对应 oStore 的一个 block，oStore 的 block 中存储了一部分的用户数据。这样，辅助表的每个 tuple 的可见性就与对应的 block 的可见性相关联，从而实现了 MVCC 的特性。当执行更新（update）或删除（delete）操作时，PieCloudDB 会生成一个新的 block，将未发生变化的 tuple 放入新的 block 中，并将更新后的用户数据放入新的 block 中（例如，在 block 4 上执行更新操作后，生成一个新的block 5，将更新后的用户数据放入新的 block 5 中）。最后，辅助表将完成更新（update）操作。 

通过这种设计和操作，PieCloudDB 能够在对象存储上实现 MVCC 特性，并通过辅助表来管理数据的版本和可见性。这使得 PieCloudDB 能够支持更新和删除操作，同时保持数据的一致性和并发控制的正确性。

• 分布式锁和事务

PieCloudDB 利用 FoundationDB 的事务提交冲突（commit conflict）机制来实现锁的共享区的正确访问，从而实现了分布式的锁。

在 PieCloudDB 中，多个事务需要访问共享区时，它们会通过 FoundationDB 的事务机制进行竞争和协调。每个事务尝试获取锁并执行对共享资源的操作。如果多个事务同时请求同一个共享锁，FoundationDB 的事务提交冲突机制会确保只有一个事务能够成功获取锁并进行操作，而其他事务将被阻塞或回滚。

通过利用 FoundationDB 的事务提交冲突机制，PieCloudDB 能够实现分布式的锁管理，确保对共享区的正确访问和资源的互斥操作。这种机制保证了多个事务之间的隔离性和一致性，避免了数据竞争和冲突的发生，并提供了可靠的分布式锁功能。

此外，PieCloudDB 还在 FoundationDB 上实现了分布式的事务，并通过 mStore、oStore、分布式锁和事务的实现，构建了一个云原生的分布式架构。这样的架构能够提供高可靠性、高性能的数据库服务，并支持分布式的数据操作和管理。

优秀的架构设计是一款数据库产品成功的第一步，OpenPie 研发团队将对 PieCloudDB 产品进行不断迭代，针对性能推出了聚集下推、预计算、Block Skipping 等功能，并很快将推出Time Travel、Branch、Data Sharing等系列提高用户的使用体验。PieCloudDB 将继续前进，在 eMPP 分布式专利技术、服务器无感知（Serverless）及 透明数据加密（TDE）等多项核心技术加持下，为企业构建高安全性，高可靠性，高可用性的「坚如磐石」的云原生虚拟数仓，助力企业实现数据价值最大化，欢迎关注！ 

Rainbond v5.14.2 版本，又称信创版本。从这个版本开始，开源用户也可以利用 Rainbond 管理符合信创要求的硬件计算资源。在这个版本中，产品团队将此前只在企业版产品中存在的信创相关功能拆分出来，融入到了开源产品路线之中。本文围绕如何在信创环境中将应用迁移上云这一主题，结合 Rainbond 信创版本的能力，给出可行的落地方案。

向信创环境迁移应用的必要性

信创产业即信息技术应用创新产业，是我国数字化转型的重要组成部分，也是关键基础设施的重要支撑。其核心在于通过行业应用拉动构建国产化信息技术软硬件底层架构体系和全周期生态体系，解决核心技术关键环节卡脖子的问题，为中国发展奠定坚实的数字基础。

对一般的软件供应商而言，在面向党政军企售卖软件时，符合国产化信创要求已经逐渐成为无法绕过的硬性标准。即使是已经交付完成的软件，在后期的建设计划中，处于信创转型时期的党政军企也会提出向国产化信创环境中迁移的硬性要求。需求的背后总是隐藏着商机，掌握国产化信创背景下的应用迁移能力，将软件产品转化为信创应用是当下所有 ToB/ToG 信创应用供应商必须掌握的能力。Rainbond 信创版本在这样的场景中可以发挥极大的作用。

信创硬件生态

信创应用必须运行在国产化硬件和操作系统之上。国产化硬件生态中最重要的是 CPU 芯片，CPU 芯片的架构直接影响信创应用是否可以在国产化硬件上运行。目前主流的国产化 CPU 厂商包括飞腾、华为、龙芯、海光、兆芯等，其指令集集中在 、 以及自主性极高的 (MIPS 指令集的后继者) 之中。而指令集的不同，直接影响到信创应用是否需要重新编译来进行适配。

不难看出，国产化 CPU 芯片的生态有这么几个特点：

• 自主程度最强，但是其生态受限严重，短时间内无法很好的面向市场推广。
• 海光、兆芯手持生态最为繁茂的 指令集授权，然而自主化程度最弱。 过于成熟稳定，前人大厦已成，很难在此基础上做出创新。
• 华为、飞腾拥有 指令集授权，自主化程度适中，而且 生态正处于蓬勃发展中，可以和 生态掰一掰手腕。

市场的反馈非常理性，在当前国内的 CPU 芯片市场中，飞腾在党政领域PC市占率领先，海光与鲲鹏占据运营商服务器主要份额。回到信创应用供应商的视角，如何打好 Arm 这张牌，将会是闯入国产化信创赛道的关键点。Rainbond 信创版本通过一云多芯能力，方便的纳管包括 Arm 在内的多架构集群。

“一云多芯”统管Arm & x86集群

顾名思义，一云多芯的异构集群，指的是在同一个集群中的计算节点中，其 CPU 芯片架构不唯一。

一般情况下，CPU 芯片的架构都是基于 Intel 公司推出的 指令集，作为后起之秀的 AMD 也推出完全兼容 的 指令集，二者可以视为等同。而在国产化信创场景中，很多国产 CPU 架构都是基于 指令集开发，常见的鲲鹏920、飞腾芯片等都属于该架构类型。为了能够融入国产化信创 IT 生态，Rainbond 自信创版本开始，全面兼容了 架构。

国产化信创绝非一朝一夕之事，大量在传统 架构下开发的应用都需要很长时间的调整甚至重构才能完全在国产化芯片上运行，一云多芯主打同时能够运行多种架构应用的能力，在国产化替代的过渡阶段中将发挥重大作用。

Rainbond 信创版本可以在同个集群中统一管理和调度多种不同 CPU 架构计算节点，同时也可以借助多集群管理能力纳管多个单架构集群。超高的灵活性，可以让决策者自行决定异构计算资源的部署策略。

除 Arm 架构之外，Rainbond 信创版本也兼容主流国产化软硬件，全面支持信创场景，并且获得了国内各大 CPU 厂商、操作系统厂商的认证。一体化管理信创应用的开发、运维、交付全流程，极大降低国产化信创场景下的应用管理成本。

信创应用迁移难点

对于信创应用供应商而言，从头开发一套信创应用并不是难事。我国信创生态已经日趋完整，无论是操作系统、开发工具还是数据库，都不存在空白区域，它们为全新信创应用的开发提供了全面的支持。真正的难点在于如何将已经运行在传统服务器中的遗留业务系统迁移到国产化信创环境中去。从传统的 跨越到 架构基本意味着业务系统中所有服务组件的重新编译，甚至重构。在保障业务连续性的前提下，完成传统应用向信创应用的转化是我们无法回避的课题。

首先，让我们按照服务的开发语言、运行方式做个分类：

解释型语言

以 Python、PHP、Shell 为代表的解释型语言，也称脚本语言，是完全与 CPU 架构无关的。我们只需要提供能在信创环境中可用的语言解释器，即可在不改动一行代码的前提下将这种服务运行起来。

字节码型的编译文件

这种类型以 Java 语言编译出的 Jar、War 包为代表。Jar 、War 包是非常常见的软件交付物。由于其打包的是与 CPU 架构无关的字节码，最终运行由跨平台的 JVM 虚拟机负责，故而我们只需要提供能在信创环境中可用的 JDK 、JRE工具，即可在不改动一行代码的前提下将这种服务运行起来。

编译型语言

这里的描述是不严格的，因为字节码型的编译文件也产自编译型语言。在这里，我们特指的是以 C、C++、Golang 为代表的编译型语言，它们在编译时与 CPU 架构强相关，编译出的二进制产物只能在指定的 CPU 架构下运行。这一特性也意味着迁移过程必须经过重新编译，才可以在信创环境中运行起来。

遗留业务系统向国产化信创环境迁移绝非易事，需要甲方与供应商的密切合作。然而由于遗留业务系统的特性，导致供应商能够提供的支持是不一样的。支持力度的不同，直接影响迁移的效果。

提供支持

当甲方决意对某个遗留业务系统进行信创迁移时，恰好供应商承诺的支持期限还没有到期，供应商可以对业务系统的迁移提供全面的支持时，问题会简单很多。即使是面对编译型语言，只要能够提供源代码进行重新编译，则可以完成信创迁移，只是耗时费力罢了。

不提供支持

当甲方决意对某个遗留业务系统进行信创迁移时，恰好供应商承诺的支持期限已经到期，甚至已经无法联系到供应商时，事情就难办许多。甲方对遗留业务系统的了解不会太深，只能找到软件交付物进行分析，重新基于信创环境搭建编译、运行环境。然而对有些经年日久的业务系统而言，很难找到当年的源代码，如果这个服务恰好是编译型语言编译出的二进制文件，基本意味着信创迁移走入了死路。此时，甲方不得不考虑重新招标另一家供应商来重构这个系统，新的替代系统落地绝非一朝一夕之事，期间不能因为这一个服务阻碍国产化信创的整体落地进程。

Rainbond “信创” 版本的核心功能是支持传统应用在信创环境中的云迁移。它紧密关注用户所使用的不同语言类型，并自动化完成信创迁移的工作。一旦所有组件成功部署，通过内置的 ServiceMesh 微服务架构，可以实现跨架构的微服务编排，将服务组件连接起来形成完整的业务系统。

传统应用迁移上云

Rainbond 信创版本自动屏蔽架构差异，以最低成本将应用迁移到国产化信创环境之中。仅需要提供源代码，即可在指定架构环境中编译运行。开源应用商店提供不同架构的应用模板，上百种开源软件一键部署。信创应用供应商可以以最小的技术成本和时间成本，即可将不同类型的服务重新编译，并部署到信创环境中去。

异构微服务编排能力

Rainbond 信创版本凭借一云多芯管理能力， 可以在同个集群中统一调度管理不同 CPU 架构的计算节点。应用中的服务组件也可以按照要求部署到指定的架构中去。但是只有不同架构的微服务组件之间可以相互编排、相互通信，那么它们才能够成为一个有机的整体，形成完整的业务系统。同时也满足信创应用从传统的 向 国产化迁移的过渡期的特殊要求。

借助于 Service Mesh 亦或是 Kubernetes Service 的能力，Rainbond 天生支持跨架构微服务之间的编排与通信。使用方法与 Rainbond 一直以来的拖拉拽拼积木式的微服务编排方法无异。

在流程开始执行前，会进行采样判断，但在实际使用中，存在需要分析耗时较长链路的场景。基于此需求，1.1.1版本中新增了采样后置过滤。用户可以根据此功能点决定上报执行耗时较长的链路日志。 更多链路采集上报查看 链路采集上报

例如，执行时间大于500ms的日志进行上报，否则本次采集日志。

 reporter.setSampleStrategy(new TraceSampleStrategy() { @Override public <T, S> boolean sampled2(EngineContext<T, S> ctx) { return ctx.escaped() > 500; } });

实时视图

Keka 是一个 macOS/iOS 端的应用程序，可以快速创建具有高压缩率的压缩文件，还支持从多种类型的文件中解压缩文件，其中包括 7z、ISO、DMG、TAR、ZIP 和 Bzip2 等类型的文件格式。

Keka 1.3 近日正式发布，不过由于该版本在 RAR 提取方面存在严重问题，Keka 已紧急发布了 1.3.1 版本修复该问题。

从现在起，Keka 将会改变版本号的迭代方式，未来的任何功能发布将增加次要版本，这就是为什么上一个版本还是 Keka v1.2.62，而现在是 v1.3.x 的原因。

特性

• 与 macOS 14 Sonoma 完全兼容
• 新的 Kekafied 文件图标
• 增加了验证压缩的功能
• 增加了 DMG 加密支持和格式选择
• 在 macOS 12+ 上增加了 AAR 加密/解密支持

格式

• 增加了 WebArchive 提取支持
• 在首选项中增加了自动安装更新的检查
• 增强了 AAR 压缩，以支持 macOS 12+ 上的多个文件/文件夹
• 增强了 RAR 密码压缩的安全性
• 增强了对多个扩展名的提取命名
• 增强的 PDF 照片提取
• 增强了 LHA/LZH 与旧版本的兼容性
• 将 UNRAR从6.21-b1 更新到 6.21
• 将 ZSTD 从 1.5.4 更新到 1.5.5

更多详情可查看：https://github.com/aonez/Keka/releases/tag/v1.3.1

Rainbond 信创版本发布，不改代码迁移到信创环境

信创产业即信息技术应用创新产业，是我国数字化转型的重要组成部分，也是关键基础设施的重要支撑。而 Rainbond 长期深耕国产化 IT 生态，已经与多家国产 CPU 架构完成兼容性认证，能够在不同的架构下快速部署运行。现在为了全面降低应用系统向信创环境中迁移的技术成本，助力信创应用零成本迁移上云。Rainbond 专门针对国产化信创场景推出了 Rainbond “信创”版本。信创应用可以被轻松地发布成为适用于不同架构的应用模板，在国产化信创环境中一键安装。

“一云多芯”，统一管理异构集群

顾名思义，“一云多芯”的异构集群，指的是在同一个集群中的计算节点中，其 CPU 芯片架构不唯一。在之前的版本中，大家使用 Rainbond 主要管理的都是 的集群，这种单架构的集群在部署和使用时相对简单。但在信创环境下，就会面临如下问题：

• 信创场景下，如何快速部署一套基于 的集群？
• 传统 X86 应用如果未改造完成时，如何在信创场景下使用？

在面对这类问题时，Rainbond 的解决思路如下：

首先，Rainbond 支持部署和管理多个单架构集群。你可以通过填写机器的 IP 地址，快速部署出一套 信创集群，你可以通过 Rainbond 单独部署 普通集群和 信创集群。并统一纳管，此时你可以用同一套源码，在两个集群中分别部署业务，用于验证业务在两种架构下的可用性。

其次，传统 架构下开发的应用都需要很长时间的调整甚至重构才能完全在国产化芯片上运行，可能一套业务系统会同时存在已改造的模块和未改造的模块。如果使用多个单架构集群管理的方式，那么对于整套业务系统的管理和通信也会存在一定的问题。

在这种情况下，“一云多芯” 就非常重要，业务已改造的模块和未改造的模块同时运行在多架构混合集群上，可以实现整套业务系统的统一管理和集群内通信，可以通过逐步改造，将业务完整迁移到 架构下。

目前 Rainbond 也支持了 集群、 集群、混合架构集群的一键部署和管理。

国产化操作系统和芯片适配

Rainbond 还是一个符合信创要求的一体化应用管理平台，兼容主流国产化 CPU，获得了国内各大 CPU 厂商的认证。同时与多个国产化操作系统进行了适配。目前 Rainbond 已适配的国产化 CPU 主要包含鲲鹏、龙芯、飞腾等；已适配过的国产化操作系统主要有超聚变、中科方德、统信软件、龙蜥操作系统、麒麟软件等。

传统应用快速迁移到信创环境

在传统应用迁移到信创环境的过程中，往往可以提供的介质有源代码、镜像、Jar、War包这几类，而对于这几类业务系统的迁移和部署，Rainbond 提供了以下解决方式：

• 源代码：对于提供了源代码的应用系统，只需要提供代码托管地址，选择 架构，Rainbond 将自动配置合适的构建环境、运行环境，将其运行到对应的计算节点中去，基本可以实现不改业务代码，构建出对应架构的镜像。
• Jar、War包：对于 Java 类型的业务而言，其 Jar/War 包本身与 CPU 架构无关，只要提供合适的运行环境即可。因此，只需要选择部署架构，Rainbond 将会自动将其打包成对应架构的镜像并运行到指定的计算节点中去。
• 镜像：对于提供了 架构的容器镜像，通过指定 架构，就可以拉取对应版本的镜像并将其部署到对应的计算节点中去。

应用市场机制全面支持 arm64 架构

为了更好的助力信创应用、遗留业务系统零成本完成向国产化信创环境迁移，我们进一步拓展了云原生应用商店的功能，使其支持发布和安装 架构的应用。现在开源应用商店中已上架了 Mysql、Redis、Nacos 等可以在 架构下可以运行的信创应用。可以在 架构下一键部署和运行。

未来我们还将会逐渐把一些常用的中间件应用上架到开源应用商店，并在开源应用商店设立信创专区。同时也欢迎大家通过 Rainbond 的发布功能，一键制作出适合在 架构下安装的应用模板，并将其发布到开源应用商店，助力国产化信创迁移改造。

如何安装？

信创版本的安装和普通安装方式一致，如果你想在 架构下快速安装体验，你可以通过执行以下脚本一键部署和使用。

如果需要搭建多架构混合集群，可以参考基于主机安装，主要流程如下：

1. 首先运行起来 Rainbond 控制台容器，并注册登录
2. 登录后，进入 平台管理 > 集群 -> 添加集群 -> 从主机开始安装 进入图形化安装页面
3. 填写节点信息，此处不需要关注各个节点的 CPU 架构信息，只需要填写各节点 IP 即可
4. 节点信息填写完毕后，根据页面提示复制节点初始化命令在集群内所有节点上执行
5. 初始化完成后， 下一步，等待 Kubernetes 集群安装成功即可，待状态为 运行中 状态时进行下一步操作
6. 勾选 我已阅读并已清楚认识上述注意事项 后， ，等待安装完成即可。

如何使用？

平台整体使用流程与体验和之前保持一致，对于信创方面的能力，可以参考官方文档的使用指南，它将详细指引你如何通过 Rainbond 轻松部署异构集群，并实现业务的快速迁移和高效管理。

wecom-sdk 是开源的企业微信开放 API 的 Java 实现，是目前最完整的Java开源实现。经过近三年的迭代，目前已经实现了企业微信通讯录管理、上下游、客户管理、微信客服、素材管理、消息推送、企微机器人、身份验证、应用管理、OA办公相关接口，开发人员不需要很高的学习成本就能快速优雅地接入企业微信。本次更新的亮点是彻底拥抱Retrofit2这一优秀的网络请求框架，为未来增加更多的可能性；改善了过度依赖Spring Boot的局面，简化了底层依赖，同时也保证了向后的兼容性。

仓库地址

gitee: https://gitee.com/felord/wecom-sdk

github: https://github.com/NotFound403/wecom-sdk

特性

• 支持多企业微信同时配置作业

• 目前实现企业微信接口 200 多个，能满足大部分场景的需求

• 全参数封装，入参、出参高度语义化封装，再也不担心组织参数、解析参数的问题

• 实现统一回调，所有回调事件可集中异步处理，开发者只需要关心业务逻辑的处理

• 由 SDK 接管 AccessToken 生命周期，开发者无需关心 Token 的管理。

Maven 中央仓库坐标

• 普通版本

 <dependency>  <groupId>cn.felord</groupId>  <artifactId>wecom-sdk</artifactId>  <version>1.1.0</version> </dependency>

• 响应式版本

 <dependency>  <groupId>cn.felord</groupId>  <artifactId>rx-wecom-sdk</artifactId>  <version>1.1.0</version> </dependency>

采用技术栈

• Retrofit2

• Rxjava3

• Okhttp4

• Jackson2

• XStream

🚀1.1.0 更新

• 移除 Spring Boot 全面使用Retrofit作为Rest引擎

• 移除无用依赖

• 实现企业支付中的企业红包、向员工付款、对外收款

• XML转换优化

• 🐞 回调请求体参数错误修复 #I7ERVA

• Okhttp 升级到 4.11.0

• Jackson 升级到 2.15.2

• 增加新的samples样例

更新内容：

[新增] layer 组件 btn 属性 style 配置，自定义按钮 Style。
[新增] layer 组件 btn 属性 class 配置，自定义按钮 Class。
[新增] select 组件 options 属性代替 items 属性。
[新增] tree 组件 tail-node-icon 属性，用于设置尾节点图标，通过设置 false 关闭。
[修复] table 组件 childrenColumnName 属性无效的问题。
[修复] config-provider 组件 locales 属性 build 时的类型检测问题。
[优化] layer 组件 layui-layer-btn0 素跟随主题色。
[补充] table 文档 sort-change 事件说明。
[补充] select 组件 items 属性说明。
[过时] select 组件 items 属性，但仍生效。

更多详情：http://www.layui-vue.com/

SQL 审核工具 SQLE 2.2306.0 于今天发布。以下对新版本的 Release Notes 进行详细解读。

文章主要分为以下三部分内容：

一、SQLE 项目介绍

二、新版本主要功能介绍

三、完整的 Release 信息

一、SQLE 项目介绍

爱可生开源社区的 SQLE 是一款面向数据库使用者和管理者，支持多场景审核，支持标准化上线流程，原生支持 MySQL 审核且数据库类型可扩展的 SQL 审核工具。目前支持各种数据库规则 700+。

SQLE 获取

二、新版本主要功能介绍

【社区版】

1. 新增 3 条 MySQL 规则

根据业务需求，本期新增 3 条 MySQL 规则，分别为：

1. 建表时，自增字段只能设置一个。

2. 不建议对同一张表连接多次。

3. 为至少一个索引添加非空约束。

【社区版】

1. 新增 3 条 MySQL 审核规则

根据业务需求，本期新增 3 条 MySQL 规则，分别为：

1. 建表时，自增字段只能设置一个；

2. 不建议对同一张表连接多次；

3. 为至少一个索引添加非空约束。

2. 新增百度云 RDS MySQL 慢日志智能扫描

本期新增百度云 RDS MySQL 慢日志智能扫描任务，配置后，SQLE 可以对百度云 RDS 实例上的慢 SQL 进行监管。通过 SQLE 平台给出的审核结果，用户可以有针对性地优化数据库性能。以下是简单的功能试用： 

1. 前置操作：用户创建的百度云 RDS 实例需为双机高可用版本，并对实例开通慢日志。

2. 在扫描任务列表页面，用户创建扫描任务，选择 MySQL 数据库类型，选择任务类型为百度云 RDS MySQL 慢日志，填写相关信息后，提交，完成扫描任务创建。

• 实例 ID：百度云 RDS 实例的 ID；

• Access Key：为账号安全认证中的 Access Key，用于登录百度云 RDS，需要与 Secret Key 一同使用；

• Access Secret Key：账号安全认证中 Access Key 对应的 Secret Key；

• 启动任务时拉取慢日志时间范围：扫描任务读取慢日志的时间范围，单位为小时，最大范围为 7 天；

• 审核过去时间段内抓取的 SQL： 审核该时间段内抓取到的慢 SQL，单位分钟；

• RDS Open API 地址：RDS 的地址前缀，用以调用 RDS 服务，需根据实例所在区域进行填写。如当前实例在华东 – 上海范围，则应填写 rds.fsh.baidubce.com

3. 进入扫描任务详情，可查看扫描任务抓取到的慢 SQL。

4. 立即审核，可查看对慢 SQL 的审核结果。

3. 在线输入 SQL 时，支持格式化 SQL

创建工单场景下，在输入 SQL 时，通常会出现一长条的 SQL 语句，难以阅读和理解。为此，本期新增了对在线输入 SQL 进行格式化的功能，以提高 SQL 的可读性。以下是简单的功能体验：

1. 进入创建工单页面，并输入一条 SQL。

2. SQL 美化，平台将对输入的 SQL 进行格式化。

【企业版】

1. 支持对 TDSQL InnoDB 模式数据源的工单审核及上线

用户现在可以将 TDSQL InnoDB 模式数据源纳入平台的 SQL 审核管理中。

目前，平台已经支持对该数据源进行工单审核，并支持 122 条审核规则。以下是简要的使用说明：

1. 纳管 TDSQL InnoDB 模式数据源之前，用户需在 SQLE 环境中配置最新的 TDSQL 插件，插件配置方法可参考数据库审核插件使用（https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse）。 

2. 用户可以在 项目 -> 数据源管理 页面添加 TDSQL 数据源。在新增数据源时，需要选择数据库类型为 TDSQL For InnoDB，并填写相关信息，然后提交即可完成添加。

添加数据源

3. 用户可以进入工单列表页面， “ 创建工单 ” 按钮，选择添加 TDSQL for InnoDB 数据源，输入 SQL 并提交审核。最后， “ 创建 ” 按钮即可完成对 TDSQL 数据源的工单创建。

2. 支持对 Mycat 类型的数据源的工单审核及上线

用户现在可以将 Mycat 类型数据源纳入平台的 SQL 审核管理中。

目前，平台已经支持对该数据源进行工单审核，并支持 129 条审核规则。以下是简要的使用说明： 

1. 纳管 Mycat 数据源之前，用户需在 SQLE 环境中配置最新的 Mycat 插件，插件配置方法可参考数据库审核插件使用（https://actiontech.github.io/sqle-docs/docs/dev-manual/plugins/howtouse）。 

2. 用户可以在 项目 -> 数据源管理 页面添加 Mycat 数据源。在新增数据源时，需要选择数据库类型为 Mycat，并填写相关信息，然后提交即可完成添加。

3. 用户可以进入工单列表页面， “ 创建工单 “按钮，选择添加的 Mycat 数据源，输入 SQL 并提交审核。最后，” 创建 ” 按钮即可完成对 Mycat 数据源的工单创建。

3. 支持自定义操作记录过期时间

SQLE 支持记录、展示和导出用户的操作记录，并且定期清理历史操作记录，默认的历史记录过期时间为 90 天。

为了满足用户的自定义需求，SQLE 新增了配置入口，用户现在可以根据实际需求设置操作记录的过期时间。

如果需要回收过期 30 天以上的历史操作记录，可以按照以下步骤进行操作：

1. 平台管理员进入系统设置，查看全局配置，默认情况下，操作记录的过期时间为 2160 小时（90 天）。

4. 支持更多 DB2 规则

本期完善了对 DB2 规则的支持，目前已支持从 DDL 规范、DML 规范、DQL 规范、使用建议、命名规范及索引规范多个维度对 DB2 数据源上的 SQL 进行审核。

5. DB2 审核支持生成回滚语句

新增 DB2 回滚语句功能：当用户在 DB2 数据源上进行 SQL 审核时，可查看执行语句对应的回滚语句。

6. DB2 审核支持 SQL 上下文

新增 DB2 的 SQL 上下文审核功能。

用户在 DB2 数据源上进行 SQL 审核时，若同时输入多条 SQL，平台将结合 SQL 上下文，给出相应的审核意见。

例如，如果用户在工单中输入了两条 SQL：创建一张新表 T11，并向其中插入一个新字段。在审核第二句 SQL 时，平台将模拟执行建表语句，并根据上下文给出相应的审核意见。因此，即使实际数据库中不存在表 T11，第二条 SQL 的审核结果也不会触发表不存在的告警。

7. DB2 审核支持 SQL 分析

新增 DB2 数据源上的 SQL 分析功能。

现在用户可以在 SQL 审核时查看该条 SQL 语句的解析结果，包括执行计划、性能统计、表结构信息等。目前该功能仅支持对 DML 语句进行 SQL 分析。

三、完整的 Release 信息

【社区版】

新特性：

• [#1589] 智能扫描任务支持百度云 RDS MySQL 慢日志

• [#1584] 新增 3 条 MySQL 审核规则

• [#1583] 支持 SQL 美化功能

优化：

• [#1549] 界面优化

• [#1597] 优化 scannerd 采集慢日志文件后上传 SQL 的流程

• [#1592] 优化社区版页面上对于企业版功能的提示信息

• [#1580] 优化规则加载流程

• [#1563] 系统设置部分功能“开启”/“关闭”交互流程优化

• [#1536] 界面优化，将成员设为项目管理员后，无需设置数据源及操作权限

• [#1535] 删除规则模板时增加校验条件，限制被使用的规则模版可以被删除

• [#1365] SMTP 配置新增配置项可关闭 SSL 安全认证

Bug 修复：

• [#1614] 解决更新扫描任务时，无法移除数据源和数据库的问题

• [#1618] 解决当工单为带上线状态时，无法中止上线的问题

• [#1599] 修复 MySQL update 生成回滚语句有误的问题

• [#1588] 修复智能扫描任务审核时报错”Error 1046: Data too long”的问题

• [#1482] 修复慢日志扫描任务 SQL 详情出现空白 SQL，阻碍扫描任务执行的问题

• [#1576] 修复审核规则”子查询不支持 LIMIT“可能出现 panic 的问题

• [#1553] 修复 MySQL 审核规则“表中包含有太多的列”，在扫描任务中无效的问题；

• [#1487] 修复重复安装 SQLE，钉钉无法收到审批的问题

• [#1556] 修复 MySQL 规则”对条件字段使用负向查询”触发不成功的问题

• [#1554] 规则“复合索引的列数量不建议超过阈值” 触发存在不成功的问题

• [#1545] 修复 AuditPlanSQLV2 model 的 GetFingerprintMD5() 方法极小概率出现死循环的问题

• [#1518] 智能扫描任务中，修复【SQL分析】操作返回的 “database not selected” 错误

• [#1396] 即时通讯工具的配置加密保存

【企业版】

新特性：

• 支持对 Mycat 进行工单审核

• 支持对 TDSQL MySQL 进行工单审核

• 支持操作记录的过期时间配置

• 支持更多 DB2 规则

• DB2 审核支持 SQL上下文

• DB2 审核支持生成回滚语句

• DB2 审核支持 SQL 分析

• DB2 审核支持基础对象验证

优化：

• MySQL 智能扫描慢日志表采集优化

Bug 修复：

• 修复添加白名单时在弹窗中无法输入 SQL 语句的问题

• 修复 OB for MySQL TopSQL 存在空值导致智能扫描审核失败报错 “the node is empty after parse” 的问题

• 修复智能扫描 MySQL 慢日志审核中 scanner 扫描慢日志文件时，当 SQL 存在换行则解析不完整的问题

最新消息，powershell，10多年的癌症被治好了！

问：癌症是指什么？

答：
powershell一直有个特性，它的管道会传递对象,请看：
‘abc’ | ForEach-Object {$_.toupper()} #返回ABC
它管道传递的是【字符串对象】。它会把管道左面的【内容】强行对象化。这导致【二进制数据经管道传输】有问题。
常见的问题场景是：管道下载图片损坏；压缩程序经管道传递损坏；二进制程序经管道import传递失败等。
例：
curl.exe https://www.baidu.com/img/PCtm_d9c8750bed0b3c7d089fa7d55720d6cf.png > a:pscodeTEMP_2023 emp152b.png
输出的图片，和在网页上另存为的图片，大小不一致。内容也坏了。

关于修复的版本：psv7.4-preview4

上述命令，我在psv7.4-preview4中亲自试验。下载的文件和我用网页另存的文件，完全相同。
建议去官网，下载安装psv7.4-preview4：
https://github.com/PowerShell/PowerShell/releases

问：和哪些管道相关？

答： 和【|】，【>】相关。

问：低于psv7.4-preview4的老版本，怎么解决这个癌症的？

答：低于psv7.4-preview4，没解决这个癌症。
缓解方法是:在powershell中用cmd /c,或bash -c。如：
cmd /c “curl.exe https://www.baidu.com/img/PCtm_d9c8750bed0b3c7d089fa7d55720d6cf.png > a:pscodeTEMP_2023 emp152c.png”

关于10年：

https://github.com/PowerShell/PowerShell/issues/1908
上述问题提交于7年前，但何止7年。powershell没开源之前一直就有这个问题。甚至超过15年了！

相关链接：

https://github.com/PowerShell/PowerShell/issues/1908
https://github.com/MicrosoftDocs/PowerShell-Docs/issues/10134
https://github.com/PowerShell/PowerShell/pull/17857

这证明了，没有做不到，只有想不到。爱.net人，你要多给powershell贡献啊。别总想着白嫖。

—谢谢观看，完—

Oracle 开源了一个基于 BPF 的 Linux 参数自动调优工具 “bpftune”，这是一个自动配置器，可以监控 Linux 系统的工作负载并自动设置正确的内核参数值。

Linux 内核包含超过 1,500 个可调参数 ，bpftune 会随着系统的状态不断地自动调整多项参数，一切参数的更改都是轻量级且完全实时，无需重新启动设备即可生效。

其主要好处是：

• 使用 BPF（伯克利数据包过滤器）可观测性功能持续监控和调整系统行为。
• 由于可以使用 BPF 观察系统状态的更多细节，因此可以在细粒度级别调整系统行为。

目前 bpftune 可以自动调整的参数：

• Congestion tuner: 自动调节拥塞控制算法的选择。
• Neighbour table tuner: 在接近满载时通过增长表来自动调整 Neighbour table 的大小。
• Route table tuner: 在接近满时通过增长表来自动调整路由表大小。
• sysctl tuner: 监视 sysctl 设置，如果它与自动调整的 sysctl 值冲突，则禁用关联的调谐器。
• TCP buffer tuner: 自动调整最大和初始缓冲区大小。
• net buffer tuner: 自动调整与核心网络相关的可调参数。
• netns tuner: 监控网络命名空间的添加和删除，有助于增强 bpftune 整体的命名空间感知能力。

   

Oracle Linux 用户可以使用 DNF 包管理器轻松安装 bpftune。bpftune 代码在 GPLv2 许可下开源，可从 GitHub 仓库获取。

AI 开发框架 BentoML 宣布了完成了 900 万美的种子轮融资，由 DCM 风险投资公司领投、Bow Capital 参投；资金将用于扩充产品体系和提升产品水平。DCM 的普通合伙人林欣禾（Hurst Lin）在此轮融资后加入了 BentoML 的董事会。

BentoML 是一家成立于 2019 年专注于 AI 应用的开发者平台，总部位于旧金山；其联合创始人兼 CEO 杨超予曾是 Databricks 的早期软件工程师。BentoML 提供了一个高层次的 API，抽象出在云上运行 AI 模型所需的基础设施的细节，旨在使开发 AI 服务更加顺畅。具体来说，BentoML 的目标是训练人工智能模型的数据科学家、管理其生命周期的 DevOp 工程师、以及在模型之上实际构建应用程序的开发人员。

杨超予在接受 TechCrunch 采访时表示，有了 BentoML，开发人员可以在短短两天内使 Visual ChatGPT 具有可扩展性和成本效益，供生产使用。用户还可以使用该框架在云端运行 Stable Diffusion 和开源的 LLMs。

他还将 BentoML 与 Next.js 框架背后的开发商 Vercel 进行了比较，称 BentoML 的目标是成为人工智能领域的 Vercel。2021 年 Vercel 宣布完成 1.5 亿美金 D 轮融资，估值达 25 亿美金。

杨超予预计，未来 AI 应用开发者将占平台用户的 90% 以上。“如果你一年前问我，我会说可能 90% 的公司会训练自己的模型，但最近出现的基础模型非常强大，即使给定一个从未见过的数据集，它们也能表现良好。开发人员现在不需要专注于模型训练，而是只需要进行微调和产品工程；这本身就构成了瓶颈，因为专注于 AI 的开发人员现在很短缺。”

并袒露，蓬勃发展的 AI 市场对 BentoML 来说是一个福音，但快速变化的行业也让团队很难兼顾短期和长期目标。“你可能必须构建顺应当前趋势的东西，但从长远来看，我们当然希望拥有自己的护城河。问题是我们如何在两者之间平衡时间和人力资源。”

在上个月的 Build 2023 大会上，微软宣布在 Windows 11 中加入名为 Windows Copilot 的 AI 助手。

这是一个集成在操作系统中的侧边栏工具，可以帮助用户完成各种任务，如内容摘要、重写、解释等。微软表示，Copilot 可以让每个用户都成为高效能者，提升工作和学习效率。

Copilot 并不会完全的取代目前 Windows 11 上的搜索功能，而是相对独立的存在，它有一个独立的按钮，用户后就能获得相应的 AI 能力。

今日，微软通过 Dev Channel 向加入测试的用户 (Windows Insiders) 发布了新的 Windows 11 测试版——内置了 Windows Copilot 预览版。

要体验 Windows Copilot，用户需要运行 Windows Build 23493 及以上版本， Microsoft Edge 版本需要 115.0.1901.150 及以上。

用户只需任务栏上的新按钮 (or WIN + C) 即可启动 Windows Copilot。Windows Copilot 将使用 Microsoft 账户或 Azure Active Directory 账户登录。

首个预览版的重点是集成 UI 体验，未来的版本会逐步加入额外的功能。

如上图所示，Windows Copilot 作为侧边栏在屏幕右侧显示，不会与桌面内容重叠，并且可以在打开的应用程序窗口旁边正常运行，以便随时与 Windows Copilot 进行交互。

关注公众号

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

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

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

关注公众号

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

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

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

关注公众号

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

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

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

关注公众号

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

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

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

关注公众号

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

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

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

Dante Cloud 一款企业级微服务架构和服务能力开发平台，是采用领域驱动模型(DDD)设计思想的、全面拥抱 Spring Authorization Server 的、基于 OAuth2.1 协议的微服务架构。基于Spring Authorization Server 0.4.3、Spring Boot 2.7.13、Spring Cloud 2021.0.8、Spring Cloud Alibaba 2021.0.5.0、Nacos 2.2.4 等最新版本开发的多租户系统，遵循SpringBoot编程思想，高度模块化和可配置化。具备服务发现、配置、熔断、限流、降级、监控、多级缓存、分布式事务、工作流等功能

平台定位

• 构建成熟的、完善的、全面的，基于 OAuth2.1 的、前后端分离的微服务架构解决方案。
• 面向企业级应用和互联网应用设计开发，既兼顾传统项目的微服务化，又满足互联网应用开发建设、快速迭代的使用需求。
• 平台架构使用微服务领域及周边相关的各类新兴技术或主流技术进行建设，是帮助快速跨越架构技术选型、研究探索阶段的利器。
• 代码简洁规范、结构合理清晰，是新技术开发应用的典型的、综合性案例，助力开发人员对新兴技术的学习和掌握。

[1]、为什么更名为 Dante Cloud

Dante Cloud (但丁)， 原项目名称 Eurynome Cloud，很多朋友都反映名字太长、读起来拗口、不容易记等问题。因此在加入 Dromara 开源社区之际，将名字进行了变更。

Dante，即但丁·阿利基耶里(公1265年-公1321年)，13世纪末意大利诗人，现代意大利语的奠基者，欧洲文艺复兴时代的开拓人物之一，以长诗《神曲》(原名《喜剧》)而闻名，后来一位作家叫薄伽丘将其命名为神圣的喜剧。

他被认为是中古时期意大利文艺复兴中最伟大的诗人，也是西方最杰出的诗人之一，最伟大的作家之一。恩格斯评价说：“封建的中世纪的终结和现代资本主义纪的开端，是以一位大人物为标志的，这位人物就是意大利人但丁，他是中世纪的最后一位诗人，同时又是新时代的最初一位诗人”

更名为 Dante Cloud，寓意本项目会像恩格斯对但丁的评价一样，在行业变革的时期，可以成为一款承上启下，助力企业信息化建设变革的产品。

[2]、版本说明

自11月24日，Spring Boot 3.0 以及 Spring Cloud 2022.0.0 等全新版本发布，整个Java 社区也步入的 Java 17 和 Spring Boot 3 的新时代。紧跟 Java 技术和 Spring 社区的发展，让更多质量更好、性能更优的新特性服务于实际的开发工作，Dante Cloud 也同步进行升级及适配，开发了基于 Spring Authorization Server 1.1.1、Spring  Boot 3.1.1、Spring Cloud 2022.0.3、Spring Cloud Alibaba 2022.0.0.0-RC2、Spring Cloud Tencent 1.11.7-2022.0.1、Nacos 2.2.4 全新 Dante Cloud 版本。关注请移步 master 分支

[3]、本次更新内容

• 【主要更新】
  • [升级] Spring Boot 版本升级至 2.7.13
  • [升级] Spring Cloud 版本升级至 2021.0.8
  • [升级] spring-security-oauth2-authorization-server 版本升级至 0.4.3
  • [升级] nacos 版本升级至 2.2.4
  • [升级] Debezimu 版本升级至 2.3
• 【依赖更新】
  • [升级] guava 版本升级至 32.1.0-jre
  • [升级] bcprov-jdk15to18 版本升级至 1.75
  • [升级] minio 版本升级至 8.5.4
  • [升级] wxjava 版本升级至 4.5.1.B
  • [升级] tencentcloud-sdk-java-sms 版本升级至 3.1.787
  • [升级] alipay-sdk-java 版本升级至 4.35.171.ALL
  • [升级] aliyun-sdk-oss 版本升级至 3.17.0
  • [升级] hutool 版本升级至 5.8.20
  • [升级] docker-maven-plugin 版本升级至 0.43.0
  • [升级] commons-io 版本升级至 2.13.0
  • [升级] guava 版本升级至 32.0.1-jre
  • [升级] redisson 版本升级至 3.22.1
  • [升级] logstash-logback-encoder 版本升级至 7.4
  • [升级] skywalking 版本升级至 8.16.0
  • [升级] minio 版本升级至 8.5.3
  • [升级] fastjson2 版本升级至 2.0.34
  • [升级] qiniu-java-sdk 版本升级至 7.13.1
  • [升级] aliyun-sdk-oss 版本升级至 3.16.3
  • [升级] jackson 版本升级至 2.15.2

[4]、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(对称加密) 算法，实现秘钥动态生成加密传输。利用“一人一码机制”，实现密码模式登录数据进行动态加密传输。配合 验证，保护接口调用和前后端数据传输的合理性及安全性。

[5]、界面预览

Dromara 开源社区

一、社区愿景

让每一位开源爱好者，体会到开源的快乐。

二、社区官网

https://dromara.org 是 Dromara 开源社区官方网站。

三、成员项目

关注公众号

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

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

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

一、前言

京东到家小程序最初只有微信小程序，随着业务的发展，同样的功能需要支持容器越来越多，包括支付宝小程序、京东小程序、到家APP、京东APP等，然而每个端分开实现要面临研发成本高、不一致等问题。

为了提高研发效率，经过技术选型采用了taro3+原生混合开发模式，本文主要讲解我们是如何基于taro框架，进行多端能力的探索和性能优化。

二、多端能力的探索

1.到家小程序基于taro3的架构流程图

框架分层解释

1.配置层：主要包含编译配置、路由配置、分包加载、拓展口子。

2.视图层：主要完成App生命周期初始化、页面初始化、注入宿主事件、解析配置为页面和组件绑定事件和属性。

3.组件库：是一个单独维护的项目，多端组件库包括业务组件和原子组件，可由视图层根据配置动态加载组件。

4.逻辑层：包括业务处理逻辑，请求、异常、状态、性能、公共工具类，以及与基础库对接的适配能力。

5.基础库: 提供基本能力，定位、登录、请求、埋点等基础功能，主要是抹平各端基础功能的差异。

2、基础库

1.统一接口，分端实现，差异内部抹平

关于基础库我们采用分端实现的方式，即统一接口的多端文件。

基础库如何对接在项目里，修改config/index.js，结合taro提供的MultiPlatformPlugin插件编译。

业务里使用方式

2.高复用

基础库不应该耦合框架，那么基础库应该如何设计，使其既能满足taro项目又能满足原生项目使用呢？

npm基础库 在taro经过编译后生成为 vendors文件

npm基础库 在小程序原生项目npm构建后 生成miniprogram_npm

一样的基础库经过编译后会存在2种形态，多占了一份空间呢。

我们对小程序包体积大小是比较敏感的，为了节约空间，那么如何让taro使用小程序的miniprogram_npm呢？

先简单说一下思路，更改 webpack 的配置项，通过 externals 配置处理公共方法和公共模块的引入，保留这些引入的语句，并将引入方式设置成 commonjs 相对路径的方式，详细代码如下所示。

3、组件库

想要实现跨端组件，难点有三个

第一：如何在多个技术栈中找到最恰当的磨平方案，不同的方案会导致 开发适配的成本不同，而人效提升才是我们最终想要实现的目的；

第二：如何在一码多端实现组件之后，确保没有对各个组件的性能产生影响

第三：如何在各项目中进行跨端组件的使用

基于以上，在我们已经确定的以Taro为基础开发框架的前提下，我们进行了整体跨端组件方案实现的规划设计：

在组件层面，划分为三层：UI基础组件和业务组件 为最底层；容器组件是中间层，最上层是业务模板组件；我们首先从UI基础组件与业务组件入手，进行方案的最终确认；

调研过程中，UI组件和业务组件主要从API、样式、逻辑三个方面去调研跨端的复用率：

经过以上调研得出结论：API层面仍需要使用各自技术栈进行实践，通过属性一致的方式进行API层面的磨平；样式上，基础都使用Sass语法，通过babel工具在转化过程中生成各端可识别的样式形式；逻辑上基本是平移，不需要做改动；所以当我们想做跨端组件时，我们最大工作量在于：API的磨平和样式的跨端写法的探索；

例：图片组件的磨平：

基于以上，跨端组件的复用方案经过调研是可行的，但是接下来，我们该如何保证转化后的组件能够和原生组件的性能媲美呢？我们的跨端组件又该如何在各个项目中使用呢？

在这个过程中，我们主要调研对比两种方案：

第一：直接利用Taro提供的跨端编辑功能进行转换，转换编译成RN . 微信小程序 以及H5；

第二：通过babel进行编译，直接转换成RN原生代码，微信小程序原生代码，以及H5原生代码

经过以上几组对比，我们最终选用了babel转义的方式。在项目中使用时，发布到Npm服务器上，供各个项目进行使用。

方案落地与未来规划：

在确认整体的方案方向之后，我们进行了项目的落地，首先搭建了跨端组件库的运行项目：能够支持预览京东小程序、微信小程序以及H5的组件生成的页面；以下是整个组件从生成到发布到对应项目的全部流程。

目前已经完成了个5种UI组件的实现，4种业务组件；其中优惠券模块已经落地在到家小程序项目中，并已经沉淀了跨端组件的设计规则和方案。未来一年中，会继续跨端组件的实现与落地，从UI、业务层到复杂容器以及复杂页面中。

4、工程化构建

1.构建微信小程序

因为存在多个taro项目由不同业务负责，需要将taro聚合编译后的产物，和微信原生聚合在一起，才能构成完整的小程序项目。

下面是设计的构建流程。

为了使其自动化,减少人工操作，在迪迦发布后台（ 到家自研的小程序发布后台 ） 创建依赖任务即可，完成整体构建并上传。

其中执行【依赖任务】这个环节会进行，taro项目聚合编译，并将产物合并到原生项目。

迪迦发布后台

2.构建京东小程序

yarn deploy:jd 版本号 描述

3.构建发布h5

yarn deploy:h5

h5的应用通常采用 cdn资源 +html入口 这种模式。先发布cdn资源进行预热，在发布html入口进行上线。

主要进行3个操作

1.编译出h5dist产物，即html+静态资源

2.静态资源，利用集成 @jd/upload-oss-tools 工具上传到 cdn。

3.触发【行云部署编排】发布html文件入口

关于cdn: 我们集成了cdn上传工具，辅助快速上线。

三、性能优化

性能优化是一个亘古不变的话题，总结来说优化方向：包下载阶段、js注入阶段、请求阶段、渲染阶段。

以下主要介绍在下载阶段如何优化包体积，请求阶段如何提高请求效率。

（一）体积优化

相信使用过taro3的同学，都有个同样的体会，就是编译出来的产物过大，主包可能超2M！

1.主包是否开启

优化主包的体积大小 ：optimizeMainPackage。

像下面这样简单配置之后，可以避免主包没有引入的 module 不被提取到中，该功能会在打包时分析 module 和 chunk 的依赖关系，筛选出主包没有引用到的 module 把它提取到分包内。

2.使用压缩插件 terser-webpack-plugin

3.把公共文件提取到分包。

mini.addChunkPages​为某些页面单独指定需要引用的公共文件。

例如在使用小程序分包的时候，为了减少主包大小，分包的页面希望引入自己的公共文件，而不希望直接放在主包内。那么我们首先可以通过 webpackChain 配置 来单独抽离分包的公共文件，然后通过 为分包页面配置引入分包的公共文件，其使用方式如下：

配置为一个函数，接受两个参数

• 参数为 Map 类型，用于为页面添加公共文件

• 参数为当前应用的所有页面标识列表，可以通过打印的方式进行查看页面的标识

例如，为 页面添加 和 两个抽离的公共文件：

4.代码分析

如果以上方式，还达不到我们想要的效果，那么我们只能静下心来分析下taro的打包逻辑。

.LICENSE.txt文件， 里面罗列打包了哪些文件，需要自行分析去除冗余。

以下以vendors.LICENSE.txt 为例

•: webpack 运行时入口 ,只有2k，没有优化空间。

•: node_modules 中 Taro 相关依赖，112k，可以魔改源码，否则没有优化空间。

•: node_modules 除 Taro 外的公共依赖，查看vendors.js.LICENSE.txt文件分析包括哪些文件

•: 项目中业务代码公共逻辑，查看 .js.LICENSE.txt文件分析包括哪些文件

•app.js app生命周期中依赖的文件。查看app .js.LICENSE.txt文件分析包括哪些文件

•app.wxss 公共样式文件 ，看业务需求优化，去除非必要的全局样式。

•base.wxml 取决于使用组件的方式，可优化空间较小。

（二）网络请求优化：

相信大家的业务里有多种类型的请求，业务类、埋点类、行为分析、监控、其他sdk封装的请求。然而在不同的宿主环境有不同的并发限制，比如，微信小程序请求并发限制 10个，京东等小程序限制为5个。

如下图，以微信小程序为例，在请求过多时，业务与埋点类的请求争抢请求资源，造成业务请求排队，导致页面展示滞后，弱网情况甚至造成卡顿。

那么基于以上问题，如何平衡业务请求和非业务请求呢？

这里我们有2个方案：

1.动态调度方案 https://www.cnblogs.com/rsapaper/p/15047813.html

思路就行将请求分为高优和低优请求，当发生阻塞时，将高优请求放入请求队列，低优进入等待队列。

请求分发器 QueueRequest：对新的请求进行分发。

◦加入等待队列：正在进行的请求数超过设置的 threshold，且请求为低优先级时；

◦加入请求池：请求为高优先级，或并发数未达到 threshold。

等待队列 WaitingQueue：维护需要延时发送的请求等待队列。在请求池空闲或请求超过最长等待时间时，补发等待请求。

请求池 RequestPool：发送请求并维护所有正在进行的请求的状态。对外暴露正在进行的请求数量，并在有请求完成时通知等待队列尝试补发。

2.虚拟请求池方案

该思路是将微信的10个请求资源，分成3个请求池，业务请求：埋点类：其他请求的比例为6:2:2。比例可以自行调整。

这样各类型请求都在自己的请求池，不存在争抢其他请求池资源，保障了业务不被其他请求阻塞。

实现方式

方案对比

2个方案都可以完成请求资源的分配，但结合业务实际采用的是虚拟请求方案，经测试在弱网情况下，请求效率可以提升15%.

四、总结和展望

未来一定是一码多端的方向，所以我们未来在基础建设上会投入更多的精力，包括框架层升级优化、基础库建设、组件库建设、工程化建设快速部署多端。

在性能优化上我们还可以探索的方向有京东小程序分包预加载、分包异步化、京东容器flutter渲染、腾讯skyLine渲染引擎等。

在团队沟通协作上会与Taro团队、京东小程序容器团队、nut-ui、拼拼等团队进行学习沟通, 也希望能与大家合作共建。

五、结束语

京东小程序开放平台是京东自研平台，提供丰富的开放能力和底层的引擎支持，目前有开发者工具、转化工具、可视化拖拽等多种开发工具可供内部研发同事使用，提升开发质量同时快速实现业务功能的上线。内部已有京东支付、京东读书、京东居家等业务使用京东小程序作为技术框架开展其业务。

如您想深入了解和体验京东小程序，可前往京东小程序官网（https://mp.jd.com/?entrance=shendeng）查看更多信息。

参考：

https://www.cnblogs.com/rsapaper/p/15047813.html

https://taro-docs.jd.com/docs/next/config-detail#minioptimizemainpackage

https://taro-docs.jd.com/docs/next/dynamic-import

https://zhuanlan.zhihu.com/p/

作者：京东零售 邓树海、姜微

来源：京东云开发者社区

DragGAN 是由 Google 的研究人员与 Max Planck 信息学研究所和麻省理工学院 CSAIL 一起开发的项目，是一个非常直观的图像编辑工具，用户只需要控制图像中的像素点和方向，就可以快速调整照片主体的位置、姿态、表情、大小和角度等。

下载预训练的 StyleGAN2 权重

要下载预训练的权重，只需运行：

sh scripts/download_model.sh

运行 DragGAN GUI

要启动 DragGAN GUI，只需运行：

sh scripts/gui.sh

此 GUI 支持编辑 GAN 生成的图像。要编辑真实图像，需要首先使用 PTI 等工具执行 GAN 反演。然后将新的潜在代码和模型权重加载到 GUI 中。

Proton 是由来自欧洲核研究组织 (CERN) 的科学家于 2014 年在瑞士日内瓦创立的一家公司，其最知名的应该就是电子邮件服务 Proton Mail，主打端到端加密、安全和隐私保护。Proton 由科学家领导，其中包括万维网的发明者 Tim Berners-Lee。

该公司曾于今年 4 月份宣布推出一个新的开源密码管理器 Proton Pass，但彼时处于封闭测试阶段，只有订阅了 Proton Lifetime 和 Visionary 计划的用户可以使用它。现在，他们则宣布面向全球推出 Proton Pass，可作为大多数主要浏览器（Chrome、Firefox、Edge、Brave 等）以及 iPhone/iPad 和 Android 上的浏览器扩展使用。

“Proton Pass 不仅仅是一个密码管理器，它还是一个身份管理器，这是一个更强大的概念。”

Proton Pass 使用了端到端的加密技术来安全地存储用户数据。与一些密码管理器最大的不同在于，它不仅对密码字段进行加密，而且还对诸如用户名、电话、URL，甚至注释部分所包含的数据进行加密。

Proton Pass 还允许用户创建“隐藏我的电子邮件别名”。根据介绍，电子邮件别名是随机生成的电子邮件地址，位于第三方（例如 Amazon、Facebook 或 Netflix）和用户的真实电子邮件帐户之间。这不仅可以防止第三方识别用户身份，而且可以在将消息转发到用户的主收件箱之前过滤掉跟踪器和其他营销工具。

这些电子邮件别名还限制了数据泄露的影响，当用户使用“隐藏我的电子邮件”别名注册的网站受到黑客攻击时，所暴露的信息只有该别名，真实电子邮件地址将保持安全。“如果发生这种情况并且你开始通过该别名接收网络钓鱼电子邮件或垃圾邮件，只需将其禁用即可”。 

Proton Pass 免费版本支持无限登录、无限加密笔记以及有限数量的隐藏我的电子邮件别名和 2FA 登录。付费订阅可以获得用于组织登录的额外保管库、无限制的电子邮件别名和无限制的 2FA 登录。

更多详情可查看官方博客。

外媒 TechCrunch 消息称，苹果公司成为首家在交易日收盘时市值达到 3 万亿美的上市公司，公司股价在本周五上涨约 2.31%，创历史新高。早在 2022 年 1 月，该公司的市值就曾首次短暂达到了 3 万亿美，但最终收盘时未能保持住这个水平。

今年以来，苹果公司的股票已经暴涨了近 46%，与 2022 年的表现形成了鲜明的对比。今年 1 月份，苹果交易市值自 2021 年初以来首次跌破 2 万亿美。

2022 年底，OpenAI 的 ChatGPT 首次亮相引发了一片 AI 炒作。从那时起，微软、谷歌、Nvidia 和 Meta 等公司纷纷加入人工智能浪潮。Nvidia 今年在标准普尔 500 指数中领先，跃升 181%；Meta 紧随其后，跃升了 137%。反观苹果，在竞争对手都在全力投入这项新兴技术的时候，该公司则鲜少提及 AI。

在达到这一里程碑式估值前不久，苹果公司刚推出了其传闻已久的 AR 头盔 Apple Vision Pro。价值 3499 美，预计将于明年上市销售。尽管销售额和利润有所下降，但苹果公司 5 月份公布的第二季度收益也强于预期。

值得注意的是，还有四家美国公司的估值超过了 1 万亿美，分别是 Alphabet、微软、亚马逊和 Nvidia。

大家好，我是 Kagol。

非常高兴跟大家宣布，2023年6月29日，OpenTiny Vue 发布了 v3.9.0 🎉。

OpenTiny 每次大版本发布，都会给大家带来一些实用的新特性，5.18 我们发布了 v3.8.0 版本，推出了一套全新的极客黑主题。

🎉OpenTiny 3.8.0 正式发布：推出「极客黑」新主题！

本次 3.9.0 版本主要推出以下新特性：

• 新增 Drawer 抽屉组件
• 新增 Guide 引导组件
• 新增 PopConfirm 气泡确认框组件
• 支持 SSR 服务器端渲染

OpenTiny 新增了一名贡献者 @KevinAndrewDong，感谢 对 OpenTiny Vue 3.9.0 版本的贡献🤝

大家可以更新 进行体验！

Drawer 抽屉

3.9.0 版本之前，大家要使用抽屉组件，需要使用 Dialog 组件的 right-slide 属性。

效果如下：

由于抽屉组件没有一个单独的 Drawer 组件，大家在咱们的组件库官网搜索 或者 等关键字时，搜索不到这个组件，经常有人问我们有没有抽屉组件。

另外由于 DialogBox 组件的 属性只能配置从右侧进行弹出，如果有用户想要从左边弹出就没法支持啦。

出于以上原因，我们决定单独抽取一个 Drawer 组件，包含丰富的功能：

• 支持4个方向弹出抽屉
• 支持定制抽屉宽度，以及动态拖拽改变抽屉的宽度
• 支持 default/header/footer 等丰富的插槽

更多丰富的功能可以在 OpenTiny 官网体验，也可以尝试单独安装 Drawer 组件进行体验。

安装 OpenTiny 的 Drawer 组件

在 App.vue 中使用

效果如下：

Guide 引导

当我们的产品推出一个比较复杂的新特性时，一般会在用户第一次使用产品时弹出一个用户指引，让用户更好地使用我们的产品，提升用户体验和满意度。

这时就需要用户指引组件 Guide，OpenTiny 的 Guide 组件效果如下：

使用方式也很简单：

效果如下：

PopConfirm 气泡确认框

PopConfirm 组件用于删除确认提示等场景，基于 Popover 组件进行封装。

使用起来很方便：

效果如下：

支持 SSR

为了扩展 OpenTiny Vue 组件库的使用场景，支持在 Vitepress、Nuxt 等 SSG/SSR 场景中使用，我们在 3.9.0 版本中增加了对 SSR 的支持，欢迎大家体验。

更多版本特性，请查看以下链接：https://github.com/opentiny/tiny-vue/releases/tag/v3.9.0

关于 OpenTiny

OpenTiny 是一套华为云出品的企业级组件库解决方案，适配 PC 端 / 移动端等多端，涵盖 Vue2 / Vue3 / Angular 多技术栈，拥有主题配置系统 / 中后台模板 / CLI 命令行等效率提升工具，可帮助开发者高效开发 Web 应用。

核心亮点：

1. ：使用 Renderless 无渲染组件设计架构，实现了一套代码同时支持 Vue2 / Vue3，PC / Mobile 端，并支持函数级别的逻辑定制和全模板替换，灵活性好、二次开发能力强。
2. ：PC 端游80+组件，移动端游30+组件，包含高频组件 Table、Tree、Select 等，内置虚拟滚动，保证大数据场景下的流畅体验，除了业界常见组件之外，我们还提供了一些独有的特色组件，如：Split 面板分割器、IpAddress IP地址输入框、Calendar 日历、Crop 图片裁切等
3. ：组件支持模板式和配置式两种使用方式，适合低代码平台，目前团队已经将 OpenTiny 集成到内部的低代码平台，针对低码平台做了大量优化
4. ：提供了基于 Angular + TypeScript 的 TinyNG 组件库，提供包含 10+ 实用功能、20+ 典型页面的 TinyPro 中后台模板，提供覆盖前端开发全流程的 TinyCLI 工程化工具，提供强大的在线主题配置平台 TinyTheme

联系我们：

• 官方公众号：
• OpenTiny 官网
• Vue 组件库（欢迎 Star 🌟）

往期文章推荐

• 🎉OpenTiny 3.8.0 正式发布：推出「极客黑」新主题！
• 🌈使用 TinyCLI 两行命令创建一个美观大气的 Admin 系统
• 🌈一个 OpenTiny，Vue2 Vue3 都支持！
• 🌈历史性的时刻！OpenTiny 跨端、跨框架组件库正式升级 TypeScript，10 万行代码重获新生！
• 🌈OpenTiny 的这些特色组件，很实用，但你应该没见过

ShopWind 多商户商城系统 v4.2 发布更新，PHP+MySQL，服务端 Yii2 框架，移动端 uniapp。使用 vue3/vite、Element Plus UI、 axios 数据请求、页面异步加载。 本次更新新增虚拟商品，服务类型商品，虚拟商品，支持线下到店二维码核销，无需发货，修复优化了 webIM 客服系统等多项。

移动端预览：

平台后台预览

新增部分功能如下：

1. 产品发布新增商品类型选择（实物商品、服务商品、虚拟商品）。实物商品：走常规的发货物流流程；服务商品：线下到店二维码核销，无需发货，下单无需收货地址；虚拟商品：无需收货地址，虚拟发货，如软件行业，充值卡券

2. 新增api接口，服务商品订单核销接口。

3. 新增服务商品订单核销二维码，买家订单展示二维码，商家通过扫码核销。

4. WebIM客服聊天增加回车发送消息，支持表情、图片上传，支持回话窗口展示订单。

5. 演示数据增加完整地区数据。数据库表region（地区表）字段增加letter（首字母）

6. 页面装修支持自定义新增新的页面，pc端，移动端均支持自定义增加新页面，增加新页面diy可视化组件编辑页面，发布新的页面。

7. 优惠券新增领券页面，增加作废操作

… … …

PC 端预览

商家管理预览

自定义页面装修预览

演示体验

• 后台体验： https://v4.shopwind‍.net/admin 平台管理员账号：admin 密码：

• 前台体验： https://v4.shopwi‍n‍d.net 自行微信登录、、支付宝登录

• 商家体验： https://v4.shopwind.n‍et/seller/login 商家测试账号： 密码：

移动端体验

• H5 端体验： ‍https://v4.shopwind.net/h5
• Android（安卓版）体验： 下载安装
• iOS（苹果版）体验： https://apps.apple.com/cn/app/id 

扫码体验其他端

更新内容如下：

• 新增商品类型（实物商品、服务商品、虚拟商品）
• 新增订单列表中筛选参数（商品类型）条件筛选
• 新增服务商品订单核销二维码
• 新增服务商品订单核销接口
• 新增虚拟商品订单发货流程处理
• 新增数据库表 region（地区表）字段增加 letter（首字母）
• 新增管理后台增加对上传图片 / 文件的格式和大小控制
• 新增 WebIM 客服聊天增加回车发送消息
• 优化移动端购物车页将商品购买数量修改为 0 后，即快速删除该商品
• 优化移动端价格显示问题，去掉价格数据未获取时显示 “0.00”
• 优化发货模块，增加对服务商品，虚拟商品的发货流程兼容
• 优化微信 JSAPI 获取微信签名错误提示
• 修复 pc 端频道页在没有安装演示数据（或没有商品分类）的情况下加载有误的问题
• 修复移动端新增 / 编辑收货地址出现重复 “加载中” 提示
• 修复移动端瀑布流商品列表数据显示有误的问题
• 修复移动端购物车页加入商品后，回到购物车页面不刷新问题，以及没有购物车商品时页面报 js 错误
• 修复移动端商品详情页输入购买数量未保存的问题

关注公众号

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

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

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

web 文件传输工具（ trzsz.js 组件 ）发布 v1.1.1 ，做了一些细节上的优化。

 trzsz (trz /tsz) 是一个兼容 tmux 的文件传输工具，和 lrzsz ( rz /sz ) 类似，并且有进度条，支持目录传输，支持拖动上传。

https://github.com/trzsz/trzsz.js 支持在 web 浏览器中使用类似 rz /sz 上传和下载文件，也支持 electron 开发的跨平台应用。

 版的 trzsz.js，可以在 Chrome 浏览器中使用 trzsz (trz /tsz) 上传和下载文件，如图：

 版的 trzsz.js，可以集成到 electron 开发的终端中，使用 trzsz (trz /tsz) 上传和下载文件，如图：

Calibre 开源项目是 Calibre 官方出的电子书管理工具。它可以查看，转换，编辑和分类所有主流格式的电子书。Calibre 是个跨平台软件，可以在 Linux、Windows 和 macOS 上运行。

Calibre 6.22 现已正式发布，此次更新内容如下：

New features

• Kobo driver：添加对最新固件的支持
• Trash bin：允许将已删除的书籍设置为在图书馆关闭时永久删除
• Windows：当文件/文件夹被另一个程序锁定时，出现更好的错误消息

Bug 修复

• PDF Output：修复了将具有大量内部 HTML 文件的书籍转换为 PDF 时导致速度大幅下降的回归问题
• CHM Input：修复使用不支持的片段的 ToC entries
• E-book viewer：修复搜索隐藏文本旁边的文本不滚动到匹配项的问题
• E-book viewer：修复了当选择内容位于顶行时，某些平台上的某些书籍不显示选择弹出窗口的问题
• DOCX Output：修复输入文档中的多个 SVG 图像，导致输出中的所有 SVG 图像只是输入图像之一
• MOBI Input：忽略 trailing bytes 中另一种形式的损坏

更多详情可查看：https://calibre-ebook.com/whats-new

Semi Design 是现代、全面、灵活的设计系统和 UI 库，由字节跳动抖音前端与 UED 团队设计、开发并维护，是一款包含设计语言、React 组件、主题等开箱即用的中后台解决方案，可用于快速搭建美观的 React 应用。

Semi Design v2.38.0 现已发布，此版本带来如下更新内容：

• 【Fix】
  • 修复 AutoComplete 长按无法选中，onSelect 未触发问题 #1665
  • 修复 Cascader 禁用态 Tag 背景色与其他输入类组件不一致问题 #1651
  • 修复 min-Width 属性大小写拼写错误导致的 warning，影响范围 (2.37.0-beta.0 – 2.38.0-beta.0) #1680
  • 修复 tooltip 在 custom trigger 的情况下，特殊场景小概率不消失的问题 #1676
  • 修复在 changeWithObject 时的 Select 中，treeData 中的 id 项无法出现的 onChange 回调的 value 值中问题 #1678
• 【Design Token】
  • Toast padding token 拆分细化，$spacing-toast_content-paddingY 拆分为 $spacing-toast_content-paddingTop、$spacing-toast_content-paddingBottom，$spacing-toast_content-paddingX 拆分为 $spacing-toast_content-paddingLeft、$spacing-toast_content-paddingRight #1674

更新说明：https://github.com/DouyinFE/semi-design/releases/tag/v2.38.0

关注公众号

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

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

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

背景

前端文件上传本来是一个常规交互操作，没什么特殊性可言，但是最近在做文件上传，需要实现截图粘贴上传，去找了下有没有什么好用的组件，网上提供的方法有，但是没找完整的组件来支持cv上传，经过了解发现可以用剪贴板功能让自己的cv实现文件上传，于是自己就整合了目前几种文件上传的交互方式，码了一个支持cv的vue3文件上传组件（造个轮子）。

介绍

作为一个完整的组件内容还是挺多的，这里主要介绍下上传交互中一些主要功能，包括上传的几种交互方式，

上传进度的获取，上传类型的限制，默认上传请求和自定义上传请求。

以下代码都是非完整代码，大家用于参考实现过程，可以通过以下代码修改来完成自己想要的交互功能。

几种交互

1，选择上传

选择是最常见的上传交互，之前原生上传控件，样式修改比较麻烦，为了修改上传样式，我们可以把该控件设置隐藏，用其他素通过从click交互, 来触发该文件选择控件。在选择文件控件上绑定onchange事件，该控件在change后获取到文件，然后调用上传方法，实现如下：

2，拖动上传

拖拽文件上传，首先在页面上建立一个拖放区域，在拖放区域上绑定拖放事件，监听拖放事件drop内容中datTransfer中是包含files,如果存在files，获取files然后调用上传附件方法。

拖放区域可以通过事件dragover来检查拖放文件是否进入拖放区域来设置拖放区域悬浮样式，通过dragleave来检查离开拖放区取消悬浮样式。

进行交互提示

实现如下：

3，复制上传（复制检测区域设置）

复制上传的交互步骤

•将文件保存到剪贴板: 执行键盘快捷键或者使用鼠标复制

•将鼠标移动到可粘贴区： 判断是否移动到可粘贴区，来确定是否在执行粘贴后上传，否则整个页面都会作为粘贴区，

•执行粘贴操作：执行键盘粘贴快捷键（ctrl+v）

粘贴区绑定paste事件，在触发paste事件前将鼠标移到粘贴区，复制会被检查不在粘贴区，阻止上传操作，实现如下：

上传模式

根据以上三种交互，大家可自由组合上传形式，比如和拖拽，拖拽和粘贴组合等等，我这边目前按，拖拽，粘贴叠加组合，设置为：

•上传，click

•拖拽上传 drag（包括上传和拖拽上传）

•粘贴上传 paste （包括，拖拽和复制上传）

通过传参 uploadeMode设置 （click, drag, paste）

组件设置：

组件应用

文件限制

文件限制包括是否多文件上传限制multiple， 上传数量limit限制，上传类型accept限制，这些设置参考了element-plus上传组件，在其基础上做了简化。实现如下

multiple 和 accept 首先需要在控件上绑定，以便于在选择上传时就能够过滤对应文件，拖拽上传和粘贴上传，无法通过input[type=file] 组件控制需要在上传方法中判断过滤，(以粘贴上传为例)

组件实现

上传进度设置

获取文件上传进度，使用ajax中的progress 事件监听机制，回传数据loaded进度，和ttotal进行计算，获取到计算的百分比通过process插槽线上在界面上。

具体实现如下:

组件实现

文件限制后执行组件上传，默认情况下走内置的上传方法，如果做了自定义，上传进度也需要自己实现（自己实现过程可以参考内置方法中的实现）

同样文件上传成功，异常等方法也可以通过监听load并且判断 xhr.status 来实现，

组件使用

•配置获取进度数据回调函数 onProgress

•配置接收回传的进度数据进行赋值

•配置进度条插槽显示进度数据

自定义上传请求

默认情况下，不需要自定义上传请求，组件内置了上传请求，如果个人有需求可以自定义上传请求，子定义上传请求，是在文件限制流程后，检查是否有自定义请求方法，如果存在就将文件传入自定义请求方法。

组件实现：

组件应用：

注意点： 通过自定义上传方法实现时，在原来组件上的属性action无效

总结

通过以上可以实现一个支持多种交互方式的文件上传组件，同时也将element-plus中文件上传的流程做了一个学习，因为该组件的实现过程就是参考了element-plus的实现，在element-plus上传的基础上添加了粘贴上传交互, 该组件的实现重在交互方式，各个样式风格通过插槽自定义。

作者：京东物流 刘海鼎

来源：京东云开发者社区

di18n  是滴滴开源的自动转换、基于配置的前端国际化方案。它能自动扫描代码中的主语言，将其替换成国际化标记；同时将语言抽取成配置，可以放到服务端保存及更新。

工作原理

di18n 会先按如下步骤扫描源码：

• 使用 Babel 解析得到 AST，遍历 AST，并对特殊的节点进行检查，抽取出需要翻译的字符串；
• 自动为每一个字符串分配一个 key 因随机 key 可读性差，已改成使用主语言（如中文）文案为 key；
• 自动调用 Google 翻译服务（可选），得到一个英文的字符串。

注：对于 React，上面提到的特殊节点包括：    等。

扫描之后，对于源代码：

• 构造  表达式 ；
• 替换原有节点 ；
• 将新的 AST 通过 Babel 转换为代码；
• 使用 Prettier 格式化代码；
• 将新的代码落盘。

对于国际化资源：

• 将 key-value 转换为 i18n 配置文件格式。

流程图

安装

初始化

React

注意： 需要将配置文件 di18n.config.js 的  改为 。

Vue

转换

时至今日，Linus Torvalds 实际上已经很少会亲自动手写内核代码；更多的是忙于监督上游的内核开发社区、审查代码、管理发布，并在邮件列表中进行讨论。不过近日，他就为 Linux 6.5 进行了将近 500 行的 code rework ，以改进用户模式的堆栈扩展代码。

他在合并报告中解释称：

这修改了我们的用户模式堆栈扩展代码，使其在修改 VM 布局之前始终获取 mmap_lock 进行写入。

实际上这是我们在技术上应该做到的事情，但是因为我们并不严格地需要它，所以我们有点偷懒（”机会主义”听起来好多了，不是吗？）。并且在我们需要的地方设置了这个 hack，会在不进行适当锁定的情况下就地扩展堆栈 vma。

而且效果很好。我们只需要改变 vm_start（或者，在 grow-up stacks 的情况下，vm_end），再加上一些使用 anon_vma 锁和 mm>page_table_lock 的特殊的临时锁，这一切都相当简单明了。

也就是说这一切都很好，直到 Ruihan Li 指出，现在 vma 布局使用 maple tree code，我们真的不只是改变 vm_start 和 vm_end 了，而且 locking 真的被打破了。

一劳永逸地解决这个问题并做适当的 locking 其实并不可怕，但有点痛苦。 我们基本上有三种不同的堆栈扩展情况，它们的工作方式都略有不同。

目前，Linux 6.5 中的这个问题应该已经得到了解决。更多详情可查看此处。

上海一游戏公司三名离职员工利用职务之便，盗取了公司开发的手游源代码；并“换皮”成新游戏上线，半年内成功盈利 1.5 亿。

事情的起始经过具体为，该公司在 2022 年 11 月发现网上出现了一款与自家产品十分类似的游戏，让他们开始怀疑是否存在源代码泄露问题，于是向公安进行了报案。警方立案调查后发现，最初开发该游戏的员工有较大嫌疑。

据悉，这三名离职员工曾是该公司手游的开发人员；游戏上线后收获了不错的热度，他们也因此获得了丰厚的提成。之后，3 人向公司提出开发升级版的新游戏，但遭到了管理层的否定。这致使他们产生了离职自行发展的想法，并在深圳注册了一家公司。

三人在协商之后将该手游的源代码提供给了另一家网络公司，对方进行简单“换皮”之后就开始上线经营。而此时，3 人还没有从原公司离职。且为了成功上线，他们还套用了《计算机软件著作权登记证》和《网络游戏出版核发单》。

图片来源/上海警方

警方将三人抓捕归案后经过审理得知，双方达成合作协议之后按比分配所得利润，对方公司占 85%，3 人所在公司占 15%；自“盗版”游戏上线以来，盈利超过 1. 5亿，三人分得利润超过1500万。上游新闻从警方出了解到，除了游戏名称、人物和背景图片稍有差别外，两款游戏在服务器数据表和服务器战斗服上的相似度 100%，服务器游戏服和客户端相似度也在 90%左右。

目前，这 3 人因涉嫌非法获取计算机信息系统数据罪，已被采取刑事强制措施，并处于取保候审阶段。与其合作的网络公司负责人和经理在明知代码来源的情况下，仍然选择使用并上线游戏获利，涉嫌侵犯著作权罪被普陀警方强制调查。案件正在进一步侦办中。

主要更新内容 

• 文章归档功能
• 文章页打印样式

关于 Fluid

Fluid  是一款基于 Hexo 框架的 Material Design 风格主题。

该主题相较于其他主题的优势：

1. 优雅的颜值，使用 Material Design 风格突出层次感，但又不失简约，让用户能专注于写作；
2. 提供大量定制化配置项，使每个用户使用该主题都能具有独特的样式；
3. 响应式页面，适配手机、平板等设备，包括极端的分辨率都能轻松应对；
4. 主题中少有的整合了 LaTeX 和 mermaid 的支持

目前具有的功能特性：

• 图片懒加载
• 自定义代码高亮方案
• 内置多语言
• 支持多款评论插件
• 支持使用数据文件存放配置
• 自定义静态资源 CDN
• 无比详实的用户文档
• 内置文章搜索
• 页脚备案信息
• 网页访问统计
• 支持脚注语法
• 支持 LaTeX 数学公式
• 支持 mermaid 流程图
• 暗色模式

详情查看：https://github.com/fluid-dev/hexo-theme-fluid

关注公众号

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

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

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

关注公众号

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

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

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

作者：刘霖

背景现状

随着 ChatGPT 的广泛应用，各种大规模语言模型层出不穷，其中包括 EleutherAI 推出的 200 亿参数的 GPT-NeoX-20B 和 BigScience 发布的 1760 亿参数的 Bloom 模型。

由于模型越来越大，单张 GPU 已无法加载整个模型，分布式模型训练成为了一种必然的趋势。在 GPT-NeoX 和 Bloom 的背后，DeepSpeed 框架是实现分布式模型训练的关键。

DeepSpeed 是一个开源的深度学习训练优化库，提供了多种优化策略，如混合精度训练、数据并行、模型并行、流水线并行等，这些策略可用于加速大规模模型的训练。此外，DeepSpeed 还提供了高性能的分布式训练框架，支持多种主流的深度学习框架，并且可以在不同的硬件和云平台上进行训练。借助 DeepSpeed，算法工程师可以更加快速地训练大规模深度学习模型，从而提高模型的准确性和效率。

当前，越来越多企业在云上基于容器和 Kubernetes 进行大规模的分布式深度学习训练，充分利用弹性、扩展性、自动化、高可用等优势，大幅提高分布式训练的效率和可靠性，同时降低管理成本和复杂性。

然而，随着模型规模扩大以及企业对生产效率的不断追求，将 DeepSpeed 分布式训练任务在 Kubernetes 中搭建和运行仍然存在着很多挑战和难点。例如，GPU资源利用率低，分布式训练扩展性差，以及难以方便地获取实时日志和监控等。

方案介绍

目前，阿里云容器服务 ACK 云原生 AI 套件已经支持 DeepSpeed 分布式训练，为您提供高效便捷的解决方案。

您只需准备好训练代码和数据，就可以利用命令行工具 Arena 快速在 ACK 集群中部署基于 DeepSpeed 的分布式训练任务。此外，可以通过 TensorBoard 可视化工具方便地查看训练作业的状态和结果，从而使 DeepSpeed 分布式训练变得更加容易和高效。

关于 ACK 云原生 AI 套件的更多信息，请通过往期文章进行了解：摆脱 AI 生产“小作坊”：如何基于 Kubernetes 构建云原生 AI 平台

核心优势

基于阿里云容器服务 ACK 云原生 AI 套件搭建和运行 DeepSpeed 分布式训练任务具备以下优势：

1. 大规模异构资源管理

使用容器服务 ACK，您可以轻松管理大规模异构资源，快速搭建基于 CPU、GPU、FPGA 等不同类型计算资源的标准 Kubernetes 集群，实现对各类异构资源进行统一、灵活的管理、调度和运维。云原生 AI 套件还支持多种 GPU 调度策略（共享+隔离、优先级、拓扑感知等）和丰富的 GPU 监控告警等能力，帮您进一步优化资源利用率。

2. 灵活弹性与成本优化

使用 ACK 弹性节点池和 HPA/VPA，您可以灵活按需自动伸缩 GPU 节点数和 Pod 数，并基于 GPU 指标实现 AHPA 弹性预测。云原生 AI 套件支持 ECS、ECI 等弹性资源混合的高级调度，包括 affinity/anti-affinity、pod topology spreading、deploymentset 感知等调度。此外，通过支持资源不足到时终止、checkpoint 自动保存、容错、Failover 等能力，解决基于抢占式实例进行分布式训练的可用性问题，减少训练成本的同时，近乎不影响训练作业成功率。ACK 还提供了成本监控和分析等能力，能够面向任务去管理和优化分布式训练的成本。

3. 高效的任务管理调度

云原生 AI 套件提供命令行工具 Arena，对深度学习核心生产环节（包括数据管理、模型开发、模型训练、模型评估、推理服务部署等）任务进行简单抽象和高效管理。通过 Arena，您可以快速提交分布式训练任务，并提升训练任务从提交到运行的性能，以及进行任务的生命周期管理。此外，云原生AI套件还提供针对分布式场景优化的调度策略，例如按 GPU 卡的 Binpack 算法分配策略，提升 GPU 卡利用率，还支持自定义的任务优先级管理和租户弹性资源配额控制，在确保用户资源分配的基础上，通过资源共享的方式来提升集群的整体资源利用率。

快速使用

下面将介绍如何基于阿里云容器服务 ACK 云原生 AI 套件快速搭建和运行 DeepSpeed 分布式训练：

前提条件

• 已创建包含 GPU 的 Kubernetes 集群。具体操作，请参见创建包含 GPU 的 Kubernetes 集群 [ 1] 。
• 已安装云原生 AI 套件（ack-arena 版本不低于 0.9.6）。具体操作，请参见部署云原生 AI 套件 [ 2] 。
• 已安装 Arena 客户端（版本不低于 0.9.6）。具体操作，请参见安装 Arena [ 3] 。
• 已给集群配置了 Arena 使用的 PVC，具体操作，请参见配置 NAS 共享存储 [ 4] （或者配置 CPFS 共享存储 [ 5] ）。

使用说明

本示例使用 DeepSpeed 训练一个掩码语言模型（Masked Language Model）。为方便运行，已将示例代码 [ 6] 和数据集下载至示例镜像中；若您无需使用示例镜像，也支持从 Git URL下载源代码，并将数据集存放在共享存储系统（基于 NAS 的 PV 和 PVC）中。本示例假设您已经获得了一个名称为 training-data 的 PVC 实例（一个共享存储），用来存放训练结果。

如需自定义训练镜像，请参考如下方式：

• 方式一：

参考该 Dockerfile [ 7] ，在基础镜像中安装 OpenSSH

• 方式二：

使用 ACK 提供的 DeepSpeed 基础镜像：

registry.cn-beijing.aliyuncs.com/acs/deepspeed:v072_base

示例介绍

本示例中创建了一个 Transformer Bert 模型，根据句子前后的上下文来填充句子。比如在下列句子中：

根据提供的’In the beautiful season of’ 和 ‘shed their leaves’，可以预测到空白处应该填入 ‘Autumn’ 和 ‘trees’。

本示例通过整合 DeepSpeed 的能力来提高训练的速度和效率，在下列几个方面进行了优化：

• 混合精度训练：DeepSpeed 支持使用 fp16 数据类型进行混合精度训练。通过在 ds_config 中设置以下配置，即可启用混合精度训练。

• ZeRO 数据并行：Zero Redundancy Optimizer（零冗余优化器）可以支持每个 GPU 都只存储模型参数、梯度和优化器状态的一部分，从而降低 GPU 显存占用，支持更大的模型。当前支持 3 个阶段，阶段 1 对优化器状态进行分片。阶段2还会对梯度进行分片。阶段 3 进一步对模型权重进行分片。通过在 ds_config 中设置以下配置，即可启动阶段 1。

• ZeRO-Offload：通过同时利用 GPU 和 CPU 的计算和存储资源，比如将优化器状态和梯度保存在内存上，从而使单 GPU 可以支持的模型更大。比如在一张 P40 GPU 上，无法训练一个 20 亿参数的模型，但是使用 ZeRO-Offload 可以做到。通过在 ds_config 中设置以下配置，即可启用 ZeRO-Offload。

本示例中 DeepSpeed 的完整配置文件 ds_config 参考如下。

DeepSpeed 是基于 AllReduce 的分布式训练框架，在 hostfile 中保存了所有的 worker 信息，luancher 读取 hostfile 文件获取 worker 信息，通过 PDSH 的方式在每个 worker 上启动训练任务。

ACK 云原生 AI 套件中的 Operator 组件会自动生成上述配置。准备好模型训练代码和数据后，即可通过 Arena 提交 DeepSpeed 分布式训练任务。如下图所示，Operator 会创建一个 Launcher Pod 和多个 Worker Pod 并在 Worker Pod 上启动训练任务。

操作步骤

1. 提交 DeepSpeed 作业

通过以下代码示例提交包含 1 个 Launcher 节点，3 个 Worker 节点的 DeepSpeed 训练任务。该任务将使用 3 台机器，每台机器上的一张 GPU 卡进行训练。

预期输出如下：

2. 执行以下命令获取作业详情

预期输出如下：

3. 通过浏览器查看 TensorBoard

执行以下命令，将集群中的 TensorBoard 映射到本地 9090 端口。

在浏览器中访问 localhost:9090，即可查看 TensorBoard。

执行以下命令可获取作业日志信息：

更多操作命令及参数解释可参考云原生 AI 套件文档 [ 8] 。

相关链接：

[1] 创建包含 GPU 的 Kubernetes 集群

https://help.aliyun.com/document_detail/171074.html?spm=a2c4g.171073.0.0.4c78f95a00Mb5P

[2] 部署云原生 AI 套件

https://help.aliyun.com/document_detail/201997.htm#section-2al-4w3-dpd

[3] 安装 Arena

https://help.aliyun.com/document_detail/212117.htm#task-1917487

[4] 配置 NAS 共享存储

https://help.aliyun.com/document_detail/212177.htm#task-1917776

[5] 配置 CPFS 共享存储

https://help.aliyun.com/document_detail/212178.htm#task-1917776

[6] 示例代码

https://github.com/microsoft/DeepSpeedExamples/tree/master/training/HelloDeepSpeed

[7] Dockerfile

https://github.com/kubeflow/arena/blob/master/samples/deepspeed/Dockerfile

[8] 云原生 AI 套件文档

https://help.aliyun.com/document_detail/2249322.html?spm=a2c4g.201994.0.0.23257371FAcYuc

如果您希望深入了解更多关于 ACK 云原生 AI 套件的信息，或者需要与我们就 LLM/AIGC 等相关需求进行交流，欢迎加入我们的钉钉群：。

作者：斜阳

高可用架构演进背景

在分布式系统中不可避免的会遇到网络故障，机器宕机，磁盘损坏等问题，为了向用户不中断且正确的提供服务，要求系统有一定的冗余与容错能力。RocketMQ 在日志，统计分析，在线交易，金融交易等丰富的生产场景中发挥着至关重要的作用，而不同环境对基础设施的成本与可靠性提出了不同的诉求。在 RocketMQ v4 版本中有两种主流高可用设计，分别是主备模式的无切换架构和基于 Raft 的多副本架构（图中左侧和右侧所示）。生产实践中我们发现，两副本的冷备模式下备节点资源利用率低，主宕机时特殊类型消息存在可用性问题；而 Raft 高度串行化，基于多数派的确认机制在扩展只读副本时不够灵活，无法很好的支持两机房对等部署，异地多中心等复杂场景。RocketMQ v5 版本融合了上述方案的优势，提出 DLedger Controller 作为管控节点（中间部分所示），将选举逻辑插件化并优化了数据复制的实现。

如何实现高可用系统

副本组与数据分片

在 Primary-Backup 架构的分布式系统中，一份数据将被复制成多个副本来避免数据丢失。处理相同数据的一组节点被称为副本组（ReplicaSet），副本组的粒度可以是单个文件级别的（例如 HDFS），也可以是分区级 / 队列级的（例如 Kafka），每个真实存储节点上可以容纳若干个不同副本组的副本，也可以像 RocketMQ 一样粗粒度的独占节点。独占能够显著简化数据写入时确保持久化成功的复杂度，因为每个副本组上只有主副本会响应读写请求，备机一般配置只读来提供均衡读负载，选举这件事儿等价于让副本组内一个副本持有独占的写锁。

RocketMQ 为每个存储数据的 Broker 节点配置 ClusterName，BrokerName 标识来更好的进行资源管理。多个 BrokerName 相同的节点构成一个副本组。每个副本还拥有一个从 0 开始编号，不重复也不一定连续的 BrokerId 用来表示身份，编号为 0 的节点是这个副本组的 Leader / Primary / Master，故障时通过选举来重新对 Broker 编号标识新的身份。例如 BrokerId = {0, 1, 3}，则 0 为主，其他两个为备。

一个副本组内，节点间共享数据的方式有多种，资源的共享程度由低到高来说一般有 Shared Nothing，Shared Disk，Shared Memory，Shared EveryThing。典型的 Shared Nothing 架构是 TiDB 这类纯分布式的数据库，TiDB 在每个存储节点上使用基于 RocksDB 封装的 TiKV 进行数据存储，上层通过协议交互实现事务或者 MVCC。相比于传统的分库分表策略来说，TiKV 易用性和灵活程度很高，更容易解决数据热点与伸缩时数据打散的一系列问题，但实现跨多节点的事务就需要涉及到多次网络的通信。另一端 Shared EveryThing 的案例是 AWS 的 Aurora，Aliyun 的 PolarStore，旁路 Kernal 的方式使应用完全运行于用户态，以最大程度的存储复用来减少资源消耗，一主多备完全共用一份底层可靠的存储，实现一写多读，快速切换。

大多数 KV 操作都是通过关键字的一致性哈希来计算所分配的节点，当这个节点所在的主副本组产生存储抖动，主备切换，网络分区等情况下，这个分片所对应的所有键都无法更新，局部会有一些操作失败。消息系统的模型有所不同，流量大但跨副本组的数据交互极少，无序消息发送到预期分区失败时还可以向其他副本组（分片）写入，一个副本组的故障不影响全局，这在整体服务的层面上额外提供了跨副本组的可用性。此外，考虑到 MQ 作为 Paas 层产品，被广泛部署于 Windows，Linux on Arm 等各种环境，只有减少和 Iaas 层产品的深度绑定，才能提供更好的灵活性。这种局部故障隔离和轻依赖的特性是 RocketMQ 选则 Shared Nothing 模型重要原因。

副本组中，各个节点处理的速度不同，也就有了日志水位的概念。Master 和与其差距不大的 Slave 共同组成了同步副本集（SyncStateSet）。如何定义差距不大呢？衡量的指标可以是日志水位（文件大小）差距较小，也可以是备落后的时间在一定范围内。在主宕机时，同步副本集中的其余节点有机会被提升为主，有时需要对系统进行容灾演练，或者对某些机器进行维护或灰度升级时希望定向的切换某一个副本成为新主，这又产生了优先副本（PriorityReplica）的概念。选择优先副本的原则和策略很多，可以动态选择水位最高，加入时间最久或 CommitLog 最长的副本，也可以支持机架，可用区优先这类静态策略。

从模型的角度来看，RocketMQ 单节点上 Topic 数量较多，如果像 kafka 以 topic / partition 粒度维护状态机，节点宕机会导致上万个状态机切换，这种惊群效应会带来很多潜在风险，因此 v4 版本时 RocketMQ 选择以单个 Broker 作为切换的最小粒度来管理，相比于其他更细粒度的实现，副本身份切换时只需要重分配 Broker 编号，对数据节点压力最小。由于通信的数据量少，可以加快主备切换的速度，单个副本下线的影响被限制在副本组内，减少管理和运维成本。这种实现也一些缺点，例如存储节点的负载无法以最佳状态在集群上进行负载均衡，Topic 与存储节点本身的耦合度较高，水平扩展一般会改变分区总数，这就需要在上层附加额外的处理逻辑。

为了更规范更准确的衡量副本组的可用性指标，学术上就引入了几个名词：

• RTO（Recovery Time Objective）恢复时间目标，一般表示业务中断到恢复的时间。
• RPO（Recovery Point Object）恢复点目标，用于衡量业务连续性。例如某个硬盘每天备份，故障时丢失最近备份后的所有更新。
• SLA（Service-Level Agreement）服务等级协议，厂商以合约的形式对用户进行服务质量承诺，SLA 越高通常成本也越高。

节点数量与可靠性关系密切，根据不同生产场景，RocketMQ 的一个副本组可能会有 1，2，3，5 个副本。

1. 单副本成本最低，维护最简单，宕机时其他副本组接管新消息的写入，但已写入的数据无法读取，造成部分消息消费延迟。底层硬件故障还可能导致数据永久丢失，一般用于非关键日志，数据采集等低可靠性成本诉求较强的场景。
2. 两副本较好的权衡了数据冗余的成本与性能，RocketMQ 跨副本组容灾的特性使得两副本模式适用于绝大部分 IOPS 比较高的场景。此时备机可以分摊一定的读压力（尤其是主副本由于内存紧张或者产生冷读时）。两副本由于不满足多数派（quorum）原则，没有外部系统的参与时，故障时无法进行选举切换。
3. 三副本和五副本是业界使用最为广泛的，精心设计的算法使得多数情况下系统可以自愈。基于 Paxos / Raft 属于牺牲高可用性来保证一致性的 CP 型设计，存储成本很高，容易受到 IO 分布不均匀和水桶效应的影响。每条数据都需要半数以上副本响应的设计在需要写透（write through）多副本的消息场景下不够灵活。

日志复制还是消息复制

如何保证副本组中数据的最终一致性？那肯定是通过数据复制的方式实现，我们该选择逻辑复制还是物理复制呢？

逻辑复制： 使用消息来进行同步的场景也很多，各种 connector 实现本质上就是把消息从一个系统挪到另外一个系统上，例如将数据导入导出到 ES，Flink 这样的系统上进行分析，根据业务需要选择特定 Topic / Tag 进行同步，灵活程度和可扩展性非常高。这种方案随着 Topic 增多，系统还会有服务发现，位点和心跳管理等上层实现造成的性能损失。因此对于消息同步的场景，RocketMQ 也支持以消息路由的形式进行数据转移，将消息复制作为业务消费的特例来看待。

物理复制： 大名鼎鼎的 MySQL 对于操作会记录逻辑日志（bin log）和重做日志（redo log）两种日志。其中 bin log 记录了语句的原始逻辑，比如修改某一行某个字段，redo log 属于物理日志，记录了哪个表空间哪个数据页改了什么。在 RocketMQ 的场景下，存储层的 CommitLog 通过链表和内核的 MappedFile 机制抽象出一条 append only 的数据流。主副本将未提交的消息按序传输给其他副本（相当于 redo log），并根据一定规则计算确认位点（confirm offset）判断日志流是否被提交。这种方案仅使用一份日志和位点就可以保证主备之间预写日志的一致性，简化复制实现的同时也提高了性能。

为了可用性而设计的多副本结构，很明显是需要对所有需要持久化的数据进行复制的，选择物理复制更加节省资源。RocketMQ 在物理复制时又是如何保证数据的最终一致性呢？这就涉及到数据的水位对齐。对于消息和流这样近似 FIFO 的系统来说，越近期的消息价值越高，消息系统的副本组的单个节点不会像数据库系统一样，保留这个副本的全量数据，Broker 一方面不断的将冷数据规整并转入低频介质来节约成本，同时对热数据盘上的数据也会由远及近滚动删除。如果副本组中有副本宕机较久，或者在备份重建等场景下就会出现日志流的不对齐和分叉的复杂情况。在下图中我们将主节点的 CommitLog 的首尾位点作为参考点，这样就可以划分出三个区间。在下图中以蓝色箭头表示。排列组合一下就可以证明备机此时的 CommitLog 一定满足下列 6 种情况之一。

下面对每种情况进行讨论与分析：

• 1-1 情况下满足备 Max <= 主 Min，一般是备新上线或下线较久，备跳过存量日志，从主的 Min 开始复制。
• 1-2，2-2 两种情况下满足 主 Min < 备 Max <= 主 Max，一般是由于备网络闪断导致日志水位落后，通过 HA 连接追随主即可。
• 1-3，2-3 两种情况下备 Max > 主 Max，可能由于主异步写磁盘宕机后又成为主，或者网络分区时双主写入造成 CommitLog 分叉。由于新主落后于备，少量未确认的消息丢失，非正常模式的选举（RocketMQ 将这种情况称为 unclean 选举）是应该尽量避免的。
• 3-3 理论上不会出现，备的数据长于主，原因可能是主节点数据丢失又叠加了非正常选举，因此这种情况需要人工介入处理。

租约与节点身份变更

前文提到 RocketMQ 每个副本组的主副本才接受外部写请求，节点的身份又是如何决定的呢？

分布式系统一般分为中心化架构和去中心化架构。对于 MultiRaft，每个副本组包含三个或者五个副本，副本组内可以通过 Paxos / Raft 这样的共识协议来进行选主。典型的中心化架构，为了节省数据面资源成本会部署两副本，此时依赖于外部 ZK，ETCD，或者 DLedger Controller 这样的组件作为中心节点进行选举。由外置组件裁决成员身份涉及到分布式中两个重要的问题：1. 如何判断节点的状态是否正常。2. 如何避免双主问题。

对于第一个问题，kubernetes 的解决方案相对优雅，k8s 对与 Pod 的健康检查包括存活检测（Liveness probes）和就绪检测（Readiness probes），Liveness probes 主要是探测应用是否还活着，失败时重启 Pod。Readiness probes 来判断探测应用是否接受流量。简单的心跳机制一般只能实现存活检测，来看一个例子：假设有副本组中有 A、B、C 三个副本，另有一个节点 Q（哨兵） 负责观测节点状态，同时承担了全局选举与状态维护的职责。节点 A、B、C 周期性的向 Q 发送心跳，如果 Q 超过一段时间（一般是两个心跳间隔 ）收不到某个节点的心跳则认为这个节点异常。如果异常的是主副本，Q 将副本组的其他副本提升为主并广播告知其他副本。

在工程实践中，节点下线的可能性一般要小于网络抖动的可能性。我们假设节点 A 是副本组的主，节点 Q 与节点 A 之间的网络中断。节点 Q 认为 A 异常。重新选择节点 B 作为新的 Master，并通知节点 A、B、C 新的 Master 是节点 B。节点 A 本身工作正常，与节点 B、C 之间的网络也正常。由于节点 Q 的通知事件到达节点 A、B、C 的顺序是未知的，假如先达到 B，在这一时刻，系统中同时存在两个工作的主，一个是 A，另一个是 B。假如此时 A、B 都接收外部请求并与 C 同步数据，会产生严重的数据错误。上述 “双主” 问题出现的原因在于虽然节点 Q 认为节点 A 异常，但节点 A 自己不认为自己异常，在旧主新主都接受写入的时候就产生了日志流的分叉，其问题的本质是由于网络分区造成的系统对于节点状态没有达成一致。

租约是一种避免双主的有效手段，租约的典型含义是现在中心节点承认哪个节点为主，并允许节点在租约有效期内正常工作。如果节点 Q 希望切换新的主，只需等待前一个主的租约过期，则就可以安全的颁发新租约给新 Master 节点，而不会出现双主问题。这种情况下系统对 Q 本身的可用性诉求非常高，可能会成为集群的性能瓶颈。生产中使用租约还有很多实现细节，例如依赖时钟同步需要颁发者的有效期设置的比接收者的略大，颁发者本身的切换也较为复杂。

在 RocketMQ 的设计中，希望以一种去中心化的设计降低中心节点宕机带来的全局风险，（这里认为中心化和是否存在中心节点是两件事）所以没有引入租约机制。在 Controller （对应于 Q ）崩溃恢复期间，由于 Broker 对自己身份会进行永久缓存，每个主副本会管理这个副本组的状态机，RocketMQ Dledger Controller 这种模式能够尽量保证在大部分副本组在哨兵组件不可用时仍然不影响收发消息的核心流程。而旧主由于永久缓存身份，无法降级导致了网络分区时系统必须容忍双主。产生了多种解决方案，用户可以通过预配置选择 AP 型可用性优先，即允许系统通过短时分叉来保障服务连续性（下文还会继续谈谈为什么消息系统中分叉很难避免），还是 CP 型一致性优先，通过配置最小副本 ack 数超过集群半数以上节点。此时发送到旧主的消息将因为无法通过 ha 链路将数据发送给备，向客户端返回超时，由客户端将发起重试到其他分片。客户端经历一个服务发现的周期之后，客户端就可以正确发现新主。

特别的，在网络分区的情况下，例如旧主和备，Controller 之间产生网络分区，此时由于没有引入租约机制，旧主不会自动降级，旧主可以配置为异步双写，每一条消息需要经过主备的双重确认才能向客户端返回成功。而备在切换为主时，会设置自己只需要单个副本确认的同步写盘模式。此时，客户端短时间内仍然可以向旧主发送消息，旧主需要两副本确认才能返回成功，因此发送到旧主的消息会返回 SLAVE_NOT_AVAILABLE 的超时响应，通过客户端重试将消息发往新的节点。几秒后，客户端从 NameServer / Controller 获取新的路由时，旧主从客户端缓存中移除，此时完成了备节点的提升。

外置的组件可以对节点身份进行分配，上图展示了一个两副本的副本组上线流程：

1. 多个 Controller 通过选举和对 Broker 的请求进行重定向，最终由一个 Controller 做为主节点进行身份分配。
2. 如果 RocketMQ 副本组存在多个副本且需要选主，节点默认以备的身份启动，备节点会将自己注册到 Controller。
3. 节点从 Controller 获取 BrokerMemberGroup，包含了这个副本组的描述和连接信息。

<!—->

1. 1. 若分配的身份为备，解析出主节点的对外服务的地址并连接，完成日志截断后进行 HA 同步。
   2. 若分配的身份为主，等待备机连接到自身的 HA 端口，并向 NameServer 再次宣告自己是主节点。

<!—->

4. 主节点维护整个副本组的信息，向备发起数据复制，周期性的向 Controller 汇报主备之间水位差距，复制速度等。

RocketMQ 弱依赖 Controller 的实现并不会打破 Raft 中每个 term 最多只有一个 leader 的假设，工程中一般会使用 Leader Lease 解决脏读的问题，配合 Leader Stickiness 解决频繁切换的问题，保证主的唯一性。

• Leader Lease: 租约，上一任 Leader 的 Lease 过期后，等待一段时间再发起 Leader 选举。
• Leader Stickiness：Leader Lease 未过期的 Follower 拒绝新的 Leader 选举请求。

注：Raft 认为具有最新已提交的日志的节点才有资格成为 Leader，而 Multi-Paxos 无此限制。

对于日志的连续性问题，Raft 在确认一条日志之前会通过位点检查日志连续性，若检查到日志不连续会拒绝此日志，保证日志连续性，Multi-Paxos 允许日志中有空洞。Raft 在 AppendEntries 中会携带 Leader 的 commit index，一旦日志形成多数派，Leader 更新本地的 commit index（对应于 RocketMQ 的 confirm offset）即完成提交，下一条 AppendEntries 会携带新的 commit index 通知其它节点，Multi-Paxos 没有日志连接性假设，需要额外的 commit 消息通知其它节点。

计算日志分叉位点

除了网络分区，很多情况导致日志数据流分叉。有如下案例：三副本采用异步复制，异步持久化，A 为旧主 B C 为备，切换瞬间 B 日志水位大于 C，此时 C 成为新主，B C 副本上的数据会产生分叉，因为 B 还多出了一段未确认的数据。那么 B 是如何以一个简单可靠的方法去判断自己和 C 数据分叉的位点？

一个直观的想法就是，直接将主备的 CommitLog 从前向后逐渐字节比较，一般生产环境下，主备都有数百 GB 的日志文件流，读取和传输大量数据的方案费时费力。很快我们发现，确定两个大文件是否相同的一个好办法就是比较数据的哈希值，需要对比的数据量一下子就从数百 GB 降低为了几百个哈希值，对于第一个不相同的 CommitLog 文件，还可以采取局部哈希的方式对齐，这里仍然存在一些计算的代价。还有没有优化的空间呢，那就是利用任期 Epoch 和偏移量 StartOffset 实现一个新的截断算法。这种 Epoch-StartOffset 满足如下原则：

1. 通过共识协议保证给定的一个任期 Epoch 只有一个Leader。
2. 只有 Leader 可以写入新的数据流，满足一定条件才会被提交。
3. Follower 只能从 Leader 获取最新的数据流，Follower 上线时按照选举算法进行截断。

下面是一个选举截断的具体案例，选举截断算法思想和流程如下：

主 CommitLog Min = 300，Max = 2500，EpochMap = {<6, 200>, <7, 1200>, <8,2500>}备 CommitLog Min = 300，Max = 2500，EpochMap = {<6, 200>, <7, 1200>, <8,2250>}

1. 备节点连接到主节点进行 HA 协商，获取主节点的 Epoch-StartOffset 信息并比较
2. 备从后向前找到任期-起始点相同的那个点作为分叉任期，在上述案例里是 <8,2250>
3. 选择这个任期里主备结束位点的最小值（如果主副本没有切换且为最大任期，则主副本的结束位点是无穷大）

实现的代码如下：

数据回发与日志截断

故障发生后，系统将会对分叉数据进行修复，有很多小小细节值得深究与探讨。

在实现数据截断的过程中，有一个很特殊的动作，当备切主的时候要把 ConsumeQueue 的 Confirm Offset 提升到 CommitLog 的 MaxPhyOffset，即使这一部分数据在主上是否被提交是未知的。回想起几年前看 Raft 的时候，当一条日志被传输到 Follower，Follower 确认收到这条消息，主再把这条日志应用到自己的状态机时，通知客户端和通知所有的 follower 去 commit 这条日志这两件事是并行的，假如 leader 先回复 client 处理成功，此时 leader 挂了，由于其他 follower 的确认位点 confirm offset 一般会略低于 leader，中间这段未决日志还没应用到 follower 的状态机上，这时就出现了状态机不一致的情况，即已经写入 leader 的数据丢失了。让我们来举一个具体的案例，假设两副本一主一备：

1. 主的 max offset = 100，主向备发送当前 confirm offset = 40 和 message buffer = [40-100] 的数据
2. 备向主回复 confirm offset = 100 后主需要同时做几件事

<!—->

1. 1. 本地提交（apply） [40-100] 区间的数据，用后台的 dispatch 线程异步构建这段数据的索引
   2. 向 producer 响应 [40-100] 这段数据是发送成功的。
   3. 向多个备机异步的提交，实际上是发送了 confirm offset = 100

<!—->

3. 此时主突然宕机，备机的 confirm offset 可能是 [40-100] 中的值

所以当备切换为主的时候，如果直接以 40 进行截断，意味着客户端已经发送到服务端的消息丢失了，正确的水位应该被提升至 100。但是备还没有收到 2.3 的 confirm = 100 的信息，这个行为相当于要提交了未决消息。事实上新 leader 会遵守 “Leader Completeness” 的约定，切换时任何副本都不会删除也不会更改旧 leader 未决的 entry。新 leader 在新的 term 下，会直接应用一个较大的版本将未决的 entry 一起提交，这里副本组主备节点的行为共同保证了复制状态机的安全性。

那么备切换成功的标志是什么，什么时候才能接收 producer 新的流量呢？对于 Raft 来说一旦切换就可以，对于 RocketMQ 来说这个阶段会被稍稍推迟，即索引已经完全构建结束的时候。RocketMQ 为了保证构建 consume queue 的一致性，会在 CommitLog 中记录 consume queue offset 的偏移量，此时 confirm offset 到 max offset 间的数据是副本作为备来接收的，这部分消息在 consume queue 中的偏移量已经固定下来了，而 producer 新的流量时由于 RocketMQ 预计算位点的优化，等到消息实际放入 CommitLog 的再真实的数据分发（dispatch）的时候就会发现对应位置的 consume queue 已经被占用了，此时就造成了主备索引数据不一致。本质原因是 RocketMQ 存储层预构建索引的优化对日志有一些侵入性，但切换时短暂等待的代价远远小于正常运行时提速的收益。

消息中间件场景

a. 数据变更是否依赖于日志

目前 RocketMQ 对于数据是在内存中单独管理的，备机间隔 5 秒向当前的主节点同步数据。例如当前主节点上创建了一个临时 Topic 并接受了一条消息，在一个同步周期内这个 Topic 又被删除了，此时主备节点数据可能不一致。又比如位点更新的时候，对于单个队列而言，多副本架构中存在多条消费位点更新链路，Consumer 拉取消息时更新，Consumer 主动向 broker 更新，管控重置位点，HA 链路更新，当副本组发生主备切换时，consumer group 同时发生 consumer 上下线，由于路由发现的时间差，还可能造成同一个消费组两个不同 consumer 分别消费同一副本组主备上同一个队列的情况。

原因在于备机重做数据更新和消息流这两件事是异步的，这有一定概率会造成脏数据。由于 RocketMQ 单个节点上 Topic / Group 数量较多，通过日志的实现会导致持久化的数据量很大，在复杂场景下基于日志做回滚依赖 snapshot 机制也会增加计算开销和恢复时间。这个问题和数据库很像，MySQL 在执行 DDL 修改数据时通过会创建 MDL 锁，阻塞用户其他操作访问表空间的访问。备库同步主库也会加锁，数据修改开始点和结束点所代表的两个日志并不是一个原子操作，这意味着主库上在修改数据的过程中如果宕机了，备库上持有的 MDL 锁就无法释放。MySQL 的解决方案是在主库每次崩溃恢复后，都写一条特殊的日志，通知所有连接的备库释放其持有的所有 MDL 排他锁。对所有操作都走日志流进行状态机复制要求存储层有多种日志类型，实现也更加复杂。RocketMQ 选择以另一种同步的模式操作，即类似 ZAB 这样二阶段协议，例如位点更新时的可以选择配置 LockInStrictMode 让备都同步这条修改。事实上 RocketMQ 为了优化上述位点跳跃的现象，客户端在未重启时，遇到服务端主备切换还会用优先采纳本地位点的方式获取消息，进一步减少重复消费。

b. 同步复制与异步复制

同步复制的含义是用户的一个操作在多个副本上都已经提交。正常情况下，假设一个副本组中的 3 个副本都要对相同一个请求进行确认，相当于数据写透 3 个副本（简称 3-3 写），3-3 写提供了非常高的数据可靠性，但是把所有从节点都配置为同步复制时任何一个同步节点的中断都会导致整个副本组处理请求失败。当第三个副本是跨可用区时，长尾也会带来一定的延迟。

异步复制模式下，尚未复制到从节点的写请求都会丢失。向客户端确认的写操作也无法保证被持久化。异步复制是一种故障时 RPO 不为 0 的配置模式，由于不用考虑从节点上的状态，总是可以继续响应写请求，系统的延迟更低，吞吐性能更好。为了权衡两者，通常只有其中一个从节点是同步的，而其他节点是异步的模式。只要同步的从节点变得不可用或性能下降，则将另一个异步的从节点提升为同步模式。这样可以保证至少有两个节点（即主节点和一个同步从节点）拥有最新的数据副本。这种模式称为 2-3 写，能帮助避免抖动，提供更好的延迟稳定性，有时候也叫称为半同步。

在 RocketMQ 的场景中，异步复制也被广泛应用在消息读写比极高，从节点数量多或者异地多副本场景。同步复制和异步复制是通过 Broker 配置文件里的 brokerRole 参数进行设置的，这个参数可以被设置成 ASYNC_MASTER、SYNC_MASTER、SLAVE 三个值中的一个。实际应用中要结合业务场景合理设置持久化方式和主从复制方式，通常，由于网络的速度高于本地 IO 速度，采用异步持久化和同步复制是一个权衡性能与可靠性的设置。

c. 副本组自适应降级

同步复制的含义是一条数据同时被主备确认才返回用户操作成功，可以保证主宕机后消息还在备中，适合可靠性要求较高的场景，同步复制还可以限制未同步的数据量以减少 ha 链路的内存压力，缺点则是副本组中的某一个备出现假死就会影响写入。异步复制无需等待备确认，性能高于同步复制，切换时未提交的消息可能会丢失（参考前文的日志分叉）。在三副本甚至五副本且对可靠性要求高的场景中无法采用异步复制，采用同步复制需要每一个副本确认后才会返回，在副本数多的情况下严重影响效率。关于一条消息需要被多少副本确认这个问题，RocketMQ 服务端会有一些数量上的配置来进行灵活调整：

• TotalReplicas：全部副本数
• InSyncReplicas：每条消息至少要被这个数量的 Broker 确认（如果主为 ASYNC_MASTER 或者 AllAck 模式则该参数不生效）
• MinInSyncReplicas：最小的同步副本数，如果 InSyncReplicas < MinInSyncReplicas 会对客户端快速失败
• AllAckInSyncStateSet：主确认持久化成功，为 true 表示需要 SyncStateSet 中所有备确认。

因此，RocketMQ 提出了副本组在同步复制的模式下，也可以支持副本组的自适应降级（参数名称为 enableAutoInSyncReplicas）来适配消息的特殊场景。当副本组中存活的副本数减少或日志流水位差距过大时进行自动降级，最小降级到 minInSyncReplicas 副本数。比如在两副本下配置 。对于正常情况下，两个副本会处于同步复制，当备下线或假死时，会进行自适应降级，保证主节点还能正常收发消息，这个功能为用户提供了一个可用性优先的选择。

d. 轻量级心跳与快速隔离

在 RocketMQ v4.x 版本的实现中，Broker 周期性的（间隔 30 秒）将自身的所有 Topic 序列化并传输到 NameServer 注册进行保活。由于 Broker 上 Topic 的数据规模较大，带来了较大的网络流量开销，Broker 的注册间隔不能设置的太短。同时 NameServer 对 Broker 是采取延迟隔离机制，防止 NameServer 网络抖动时可能瞬间移除所有 Broker 的注册信息，引发服务的雪崩。默认情况下异常主宕机时超过 2 分钟，或者备切换为主重新注册后才会替换。容错设计的同时导致 Broker 故障转移缓慢，RocketMQ v5.0 版本引入轻量级心跳（参数liteHeartBeat），将 Broker 的注册行为与 NameServer 的心跳进行了逻辑拆分，将心跳间隔减小到 1 秒。当 NameServer 间隔 5 秒（可配置）没有收到来自 Broker 的心跳请求就对 Broker 进行移除，使异常场景下自愈的时间从分钟级缩短到了秒级。

RocketMQ 高可用架构演进路线

无切换架构的演进

最早的时候，RocketMQ 基于 Master-Slave 模式提供了主备部署的架构，这种模式提供了一定的高可用能力，在 Master 节点负载较高情况下，读流量可以被重定向到备机。由于没有选主机制，在 Master 节点不可用时，这个副本组的消息发送将会完全中断，还会出现延迟消息、事务消息、Pop 消息等二级消息无法消费或者延迟。此外，备机在正常工作场景下资源使用率较低，造成一定的资源浪费。为了解决这些问题，社区提出了在一个 Broker 进程内运行多个 BrokerContainer，这个设计类似于 Flink 的 slot，让一个 Broker 进程上可以以 Container 的形式运行多个节点，复用传输层的连接，业务线程池等资源，通过单节点主备交叉部署来同时承担多份流量，无外部依赖，自愈能力强。这种方式下隔离性弱于使用原生容器方式进行隔离，同时由于架构的复杂度增加导致了自愈流程较为复杂。

切换架构的演进

另一条演进路线则是基于可切换的，RocketMQ 也尝试过依托于 Zookeeper 的分布式锁和通知机制进行 HA 状态的管理。引入外部依赖的同时给架构带来了复杂性，不容易做小型化部署，部署运维和诊断的成本较高。另一种方式就是基于 Raft 在集群内自动选主，Raft 中的副本身份被透出和复用到 Broker Role 层面去除外部依赖，然而强一致的 Raft 版本并未支持灵活的降级策略，无法在 C 和 A 之间灵活调整。两种切换方案都是 CP 设计，牺牲高可用优先保证一致性。主副本下线时选主和路由定时更新策略导致整个故障转移时间依然较长，Raft 本身对三副本的要求也会面临较大的成本压力，RocketMQ 原生的 TransientPool，零拷贝等一些用来避免减少 IO 压力的方案在 Raft 下无法有效使用。

RocketMQ DLedger 融合模式

RocketMQ DLedger 融合模式是 RocketMQ 5.0 演进中结合上述两条路线后的一个系统的解决方案。核心的特性有以下几点：

1. 利用可内嵌于 NameServer 的 Controller 进行选主，无外部依赖，对两副本支持友好。
2. 引入 Epoch-StartOffset 机制来计算日志分叉位点。
3. 消息在进行写入时，提供了灵活的配置来协调系统对于可用性还是一致性优先的诉求。
4. 简化日志复制协议使得日志复制为高效。

几种实现对比表如下：

与其他消息系统的对比

控制节点

1. 是否强制要求选主
   Kafka 的 Controller 是 Broker 选举产生，这需要有一个存储节点间的服务发现机制。RocketMQ 的 Controller 可以作为管控节点单独存在。对 Kafka，Pulsar 而言必须选择主副本进行写入，随着时间的运行节点之间负载需要通过复杂的方案进行再均衡。对 RocketMQ 的融合架构而言，由于选主是可选的，静态布局的方案（例如无需依赖复杂的动态调度就可以较为均衡的实现跨机架跨可用区），并且无切换与切换架构可以相互转换。
2. Controller 的逻辑复杂度
   RocketMQ Controller 相比 Kafka Controller 更加轻量，Kafka 的 Controller 承担 Partition 粒度的 ISR 维护和选举等功能，而RocketMQ 的 Controller 维护的数据是副本组粒度的，对于数据只维护节点身份，更加简单。RocketMQ Controller 可以独立部署，也可以内嵌 NameServer 运行。
3. Controller 依赖程度
   RocketMQ Broker 的同步副本集维护是 Master Broker 节点上报，由于不强依赖中心节点来提供租约，controller 宕机时虽然无法为同时有主故障的副本组选举，但不影响绝大部分副本组可用性。Pulsar 中通过 fencing 机制防止有多个 writer（pulsar 中的计算节点称为 broker）同时写同一个 partition，是对外部有依赖的。

数据节点

1. 副本存储结构的抽象与最小粒度不同，在这一点上其实三者的设计各有优势

• • Kafka 的存储抽象粒度是 Partition，对每个分区进行维护多副本，扩容需要进行数据复制，对于冷读支持更好。
  • RocketMQ 的日志流是 Broker 粒度的，顺序写盘效率更高，在磁盘空间不足时一般选择水平扩容，只需复制数据。
  • Pulsar 其实抽象了一个分布式日志流 Journal，分区被进一步分成分片，根据配置的时间或大小进行滚动，扩容只需复制数据。

2. 复杂的参数配置被收敛至服务端
   Kafka 和 RocketMQ 都支持灵活的配置单条消息的 ack 数，即权衡数据写入灵活性与可靠性。RocketMQ 在向云原生演进的过程希望简化客户端 API 与配置，让业务方只需关心消息本身，选择在服务端配置统一配置这个值。
3. 副本数据的同步方式不同
   Pulsar 采用星型写：数据直接从 writer 写到多个 bookeeper。适合客户端与存储节点混部场景。数据路径只需要 1 跳，延迟更低。缺点是当存储计算分离时，星型写需要更多的存储集群和计算集群间网络带宽。
   RocketMQ 和 Kafka 采用 Y 型写：client 先写到一个主副本，由其再转发给另外 Broker 副本。虽然服务端内部带宽充裕，但需要 2 跳网络，会增加延迟。Y 型写利于解决文件多客户端写的问题，也更容易利用 2-3 写克服毛刺，提供更好的延迟稳定性。

高可用架构的未来

仔细阅读 RocketMQ 的源码，其实大家也会发现 RocketMQ 在各种边缘问题处理上细节满满，节点失效，网络抖动，副本一致性，持久化，可用性与延迟之间存在各种细微的权衡，这也是 RocketMQ 多年来在生产环境下所积累的核心竞争力之一。随着分布式技术的进一步发展，更多更有意思的技术，如基于 RDMA 网络的复制协议也呼之欲出。RocketMQ 将与社区协同进步，发展为 “消息，事件，流” 一体化的融合平台。

参考文档：

1. Paxos design

https://lamport.azurewebsites.net/pubs/paxos-simple.pdf

2. SOFA-JRaft

https://github.com/sofastack/sofa-jraft

3. Pulsar Geo Replication

https://pulsar.apache.org/zh-CN/docs/next/concepts-replication

4. Pulsar Metadata

https://pulsar.apache.org/zh-CN/docs/next/administration-metadata-store

5. Kafka Persistence 

https://kafka.apache.org/documentation/#persistence

6. Kafka Balancing leadership

https://kafka.apache.org/documentation/#basic_ops_leader_balancing

7. Windows Azure Storage: A Highly Available Cloud Storage Service with Strong Consistency 

https://azure.microsoft.com/en-us/blog/sosp-paper-windows-azure-storage-a-highly-available-cloud-storage-service-with-strong-consistency/

8. PolarDB Serverless: A Cloud Native Database for Disaggregated Data Centers

https://www.cs.utah.edu/~lifeifei/papers/polardbserverless-sigmod21.pdf

RocketMQ 学习社区体验地址

RocketMQ 学习社区重磅上线！AI 互动，一秒了解 RocketMQ 功能源码。RocketMQ 学习社区是国内首个基于 AIGC 提供的知识服务社区，旨在成为 RocketMQ 学习路上的“贴身小二”。

PS：RocketMQ 社区以 RocketMQ 5.0 资料为主要训练内容，持续优化迭代中，回答内容均由人工智能模型生成，其准确性和完整性无法保证，且不代表 RocketMQ 学习社区的态度或观点。

此处，立即体验 RocketMQ 学习社区（建议 PC 端体验完整功能）

2023 年 3 月，操作系统开源社区 OpenCloudOS 正式发布首个全自研社区 9.0 版本（以下简称 OC 9.0），OC 9.0 的内核及用户态软件均为自主选型、独立演进，在操作系统发行版的全链路均实现自主可控。

当前，服务器操作系统发行版包含从 L1 到 L3 的不同层级。其中，L1 基于 Linux 内核及核心组件构建，是最上游的「源社区」版本；L2 企业版基于 L1 源社区版本加固，提供企业级的技术支持及服务，可用于真实业务场景，是稳定可靠的发行版本；L3 社区版基于 L2 企业版进一步优化，是代码完全开源、生态全面开放的发行版本。

本次发布的 L3 社区版 OC 9.0，是基于 L1 源社区的 OpenCloudOS Stream 优化推出，由腾讯与 Intel、北京红旗、中兴、龙芯、中科方德等二十余家单位共同研发。OC 9 使用上游社区最新内核 Kernel 6.1，提供多体系架构和新硬件支持，多核性能优化，混部隔离特性增强。

一、技术亮点

1、全栈版本升级

本次发布的 OC 9.0 使用上游社区最新内核 Kernel 6.1，应用了上游及自研的最新组件，包括 GCC 12、LLVM 14、Kona JDK 11/17 、Glibc 2.35、Python 3.10、Rust 1.64.0 等。

在系统服务方面，OC 9.0 也进行了全栈版本升级。基于 Systemd 251，支持 Cgroup v2 更多特性；dracut 支持 zstd 固件、并行探测；GRUB2 支持 TPM、NVMe 设备、RAID5；存储、文件及设备管理也进行了全面的版本升级，如逻辑卷管理 LVM2 2.03.16，文件系统工具 e2fsprogs 1.46.5，分区工具 Parted 3.5。网络服务方面，集成 Nftables 1.0.4，iptables 1.8.8 等网络工具。

2、安全性提升

在安全方面，OC 9.0 对系统内核进行了优化，提供 GPG 加解密加速，PAM 新增验证模块等能力，并支持 OpenSSL 3.0 及更多密码算法，部分软件原生支持 SM3、SM4 国密算法。部分软件原生支持国密算法，提供了更加安全的数据保障。

3、内存管理效率提升

OC 9.0 提升了内存管理效率，基于 MGLRU、Mapple Tree 等特性，具备完善的 Cgroup V2 支持、多架构热补丁支持，并提供细致化的调优与系统适配。

4、性能增强

相对于已发布的 OC 8.6 版本，OC 9.0 在性能上也有明显提升。基于两个典型业务场景的数据对比，Mariadb 数据库性能上，OC 9.0 在多线程（4096 clients）下比 OC 8.6 数据库读写性能提升 50.49%；Nvme 读写性能上在随机读（rndrd_1m）下比 OC 8.6 性能提升26.5%，顺序写（seqwr_1m）提升 21.16%。

OpenCloudOS 9.0 全部特性汇总，请查看：

https://docs.opencloudos.org/release/v9.0/

二、安装方式及支持平台

OpenCloudOS Stream 提供 Netinst（网络安装镜像）、everything（标准安装镜像）、QCOW2（虚拟机镜像）、Docker（容器镜像）四种安装方式，方便用户快速部署。

下载地址：

https://www.opencloudos.org/iso

支持硬件：

OpenClousOS 9 支持 Intel、AMD 和 ARM 64 位架构，已验证的物理机平台如下：

已验证的虚拟机平台如下：

三、技术支持

如果你对 OpenCloudOS 9.0 有任何疑问，或使用过程中遇到问题，可以扫描下方二维码，加入开发者交流群，即可免费获取各种 OpenCloudOS 相关的技术支持，参与群内抽奖活动。

相关链接

OpenCloudOS 社区官网：https://www.opencloudos.org

软件兼容性列表：https://github.com/OpenCloudOS/SysDocs/blob/master/software.md

硬件兼容性列表：https://github.com/OpenCloudOS/SysDocs/blob/master/hardware.md

OpenCloudOS图形安装指南：https://docs.opencloudos.org/quickstart/V9_install/

代码仓库：https://gitee.com/src-opencloudos-rpms问题反馈：https://bugs.opencloudos.tech

作者：溪恒、谢石、遐宇

Kubernetes 本身比较复杂，使用门槛较高，用户在开始容器化迁移时经常遇到各种各样的问题，由于缺乏故障定位的技能和工具，用户常常产生挫败感，甚至放弃业务容器化。其中网络问题表现尤为突出，Kubernetes 网络虚拟化导致网络问题排查的难度巨大。

KubeSkoop 是阿里云容器服务团队开源的 Kubernetes 容器网络诊断工具，支持主流的网络插件和云厂商的 Kubernetes 集群诊断。它正是为了降低网络问题排查难度，让没有网络知识的人也可以自动化地定位网络问题。

Kubernetes 容器网络诊断工具：https://github.com/alibaba/kubeskoop

KubeSkoop 能够自动构建出给定源和目的地址在容器网络中的访问路径，自动化地采集和分析链路上每一个网络节点的配置，结合 eBPF 内核监控以及 IaaS 层的网络配置检查，定位出导致网络不通的根因，极大地降低了网络问题定位的时间，即使没有任何网络技能的用户也可以使用。目前在阿里云容器服务的环境中，作为自运维工具解决了大量客户在大规模 Kubernetes 集群场景下遇到的网络问题。

本文将会对容器网络和传统定位手段带来的问题进行简单的介绍，以及对 KubeSkoop 的功能设计等方面进行总体解说。

容器网络

网络连通性-CNI

容器网络是 Kubernetes 集群中及其重要的一部分，包括了构成集群网络连通性的 CNI 插件、Service 服务发现机制、NetworkPolicy 网络策略等。Kubernetes 集群网络保证了每个 Pod 拥有自己独立的网络空间，并且能够与集群中的 Pod 和 Node 互相通信。

CNI 插件是构成集群容器网络中的核心，实现集群级别唯一的地址分配，将集群维度的网络打通。

不同的 CNI 插件，如 Flannel、Calico、Cilium、Terway 等，有其不同的网络实现，包括地址分配，网络虚拟化实现，网络连通性实现等。服务发现和网络策略除 CNI 插件外，Kubernetes 还提供了 Service 作为服务发现，以及 NetworkPolicy 作为网络策略能力。这些能力也是通过可替换的组件来实现的。

复杂性和网络问题定位

由于概念繁多，以及插件实现选择的丰富性，导致 Kubernetes 网络问题存在着相当的复杂性，包括：

• 逻辑概念的复杂性
• Ingress/Service/NetworkPolicy 配置灵活，可能导致配置错误/规则冲突等问题。
• 使用 ServiceMesh 或第三方 CNI 插件，带来更复杂的网络策略和扩展能力。
• 数据面实现的复杂性
• 数据平面经过不同组件的多层处理，且存在多种实现。
• 协议栈链路复杂，涉及到网卡驱动 /netfilter/route/bridge 等配置。
• 不同云厂商的底层配置不同，安全组、路由表等配置复杂。

传统的容器网络问题定位手段，主要是通过抓包定位丢包点、压测复现、人工查配置等方式。存在着定位流程长、大量时间开销、人员经验要求高等问题。

在日常的工作中，排查容器网络问题占用了相当大部分的精力。因此，我们开发了 KubeSkoop 项目，来实现针对容器网络场景下问题的自动诊断系统。

KubeSkoop 功能

在我们的分析中，常见的 Kubernetes 网络问题可以分为以下两类：

• 网络持续不通问题
• 持续的无法访问：ping 不同、connect 超时、DNS 无法解析等。
• 网络抖动问题
• 偶发的网络问题：偶尔的业务超时、504、偶发 reset 等。
• 网络性能问题：网络性能低、QPS 压不上去等。

在这些问题中，80% 都是可以依赖经验解决的已知问题。而问题的处理时间主要浪费在问题上报、信息收集和验证上。

KubeSkoop 即是针对这两类场景，通过信息收集（包括 CNI 插件、ServiceMesh、Kernel/eBPF、基础设施等）、推导和展示（容器服务智能运维、Prometheus、Grafana/Loki 等），实现全链路一键诊断、网络栈延迟分析、网络异常事件识别回溯，快速定位问题根因。

项目可分为两部分：诊断网络持续不通问题的 KubeSkoop 连通性诊断， 和分析网络抖动问题的 KubeSkoop 深度网络监控。

连通性诊断

通过 KubeSkoop，能够对网络持续不通问题进行一键诊断。

用户通过指定网络不通的来源 IP 和目的 IP 发起一次诊断。在诊断中，KubeSkoop 将会自动构建网络访问链路，收集网络栈信息，分析链路问题。

同时，诊断包含了 Service、NetworkPolicy 等 Kubernetes 概念的分析，全面覆盖协议栈、底层 IaaS 的连通性相关检查，让用户无需了解网络插件的实现，也无需拥有复杂网络问题排查经验，就能够一键定位网络问题并自助解决。

连通性诊断目前提供了 Flannel、Calico（内部包括 Terway）网络插件插件的诊断支持，以及阿里云作为基础设施的支持。关于诊断能力的完整使用文档，可见：https://kubeskoop.io/docs/guide/diagnose/intro

深度网络监控

针对网络抖动问题，KubeSkoop 深度网络监控提供了基于 eBPF 的，Pod 级别的容器网络异常监控能力。

基于 eBPF，KubeSkoop 提供了精简、低开销的内核异常监控能力，覆盖驱动、netfilter、TCP 等完整协议栈，几十种异常场景的识别。同时，基于云原生部署，提供了与 Prometheus 等可观测体系的对接，支持网络问题的 Metrics 查看和事件回溯。

关于深度网络监控能力的指标透出，可参考：https://kubeskoop.io/docs/guide/exporter/exporter-description

KubeSkoop 设计

KubeSkoop 的设计，同样分为连通性诊断和深度网络监控两部分。

连通性诊断

工作流程

KubeSkoop 连通性诊断的工作流程可分为三步：拓扑构建、信息采集和链路模拟。

• 拓扑构建

通过用户所提供的信息，再通过 API Server 获取集群内的 Pod/Node 资源和 Service/NetworkPolicy 规则，匹配对应的 CNI 插件、基础设施，构建集群内的访问关系。

• 信息采集

在构建链路的过程中，KubeSkoop 会按需向集群中的节点下发信息采集任务。采集的内容包括运行时信息、协议栈采集（路由、iptables、IPVS 等）和基础设施信息（ECS metadata）。采集后的信息用于后续的网络拓扑构建和诊断模拟过程。

• 链路模拟

KubeSkoop 会根据网络拓扑和所收集到到的信息，进行检查和模拟。包括对路径上的拓扑点和链路的转发模拟、对于 CNI 插件实现的模拟、云厂商的模拟，快速发现链路中存在的丢包或错误路由配置。

最终，结合网络拓扑以及诊断中发现的异常链路，KubeSkoop 会输出诊断结果和链路中存在的问题，或在 Web UI 中进行直观地展示。

扩展性

KubeSkoop 连通性诊断提供了对 CNI 插件和基础设施架构的扩展，能够轻松地在框架中提供对其它 CNI 插件和云厂商的支持。

深度网络监控

工作流程

KubeSkoop 深度网络监控通过在需要采集信息的集群节点上运行 KubeSkkop exporter 的方式，采集节点上 Pod 的网络监控信息并以多种形式导出，包括：

• 深度容器网络采集
• 通过 eBPF 采集协议栈关键点
• 采集 procfs 下内核透出信息用于回溯
• 采用 CRI 接口关联采集点和 Pod
• 容器指标和异常事件预处理
• 网络异常 Metrics 过滤，减少开销
• 多指标聚合生成异常 Event
• 网络 Metrics 和 Event 展示
• 通过 Prometheus+Grafa 存储和回溯异常时间点指标
• Grafana Loki 记录异常事件
• KubeSkoop Inspector 查看实时异常事件流

实现

在实现中，采用了 eBPF 作为 KubeSkoop 主要数据的采集来源。eBPF 可以达到在内核中动态注入代码的目的，eBPF 代码在内核中执行效率高，并且可以通过 map 和 pert_event 与用户态通信。eBPF 还自带了校验机制，避免了因挂载的程序问题而导致宕机。

为了兼容性和性能考虑，在使用 eBPF 的过程中，我们也做了许多优化措施：

• 采用 CO-RE 方式减少编译开销，提升内核兼容性
• 减少在关键路径上的注入
• 尽量在 eBPF 程序中过滤异常数据，以减少内存开销
• 默认注入低开销程序，根据需求可动态插拔 eBPF 采集模块和修改过滤参数

未来规划

目前，KubeSkoop 项目仍旧处于早期阶段。我们下一步的规划包括：

• 增加更多云厂商和网络插件的支持。
• 支持模拟发包和追踪以定位未知问题点，缩小排查范围。
• 提供 KubeSkoop Analysis 工具，智能分析 KubeSkoop 的指标和事件，降低诊断结果理解门槛。
• 不限于网络诊断，增加存储、性能诊断。
• 应用层感知能力，提供对7层协议（如 http、redis 等）的感知和处理。

KubeSkoop 的官网位于：https://kubeskoop.io

欢迎大家前来试用&提供建议&贡献代码！也欢迎通过搜索群号的方式加入 KubeSkoop 用户钉钉交流群~（群号：）

此处了解 KubeSkoop 更多详情

作者： 赵炳堃(秉钧)

在传统的微服务体系中，Spring Cloud Alibaba 和 Zuul 常被用作配合 Spring Cloud 使用的微服务网关。然而，这些传统的 Java 网关在面对大规模流量的场景下仍存在种种问题。例如 Zuul 由于采用了非异步 IO 的架构，导致了其在面对高流量的情况下容易出现阻塞的现象，Spring Cloud Gateway 也会在流量很大的情况下产生 Full GC 的情况，导致请求 RT 变长，影响用户体验和业务稳定性。因此我们需要寻找一个新的选项，来替代这些传统的微服务网关。

Higress: Spring Cloud生态下微服务网关的新选择

Higress 是阿里巴巴开源的一款下一代云原生微服务网关。Higress 可以对接多种注册中心，包括Nacos/Zookeeper/Eureka 等，能够无缝集成 Spring Cloud 应用，对 Dubbo/Sentinel/OpenSergo 等微服务生态也有着深度的集成。与此同时，Higress 采用 C++内核，相比于传统的 Java 网关来说性能更高，更稳定，对比Spring Cloud Gateway 和 Zuul 来说，性能可以提升至2-4倍。另外，Higress 还天然兼容 K8s 的Ingress/Gateway API 标准，是一款更符合云原生时代标准的微服务网关。

更多性能压测试验，请参考：https://sigusoft.com/s/45ZAc5CGfND46Ao3lbHefQ

Higress无缝对接Spring Cloud应用发布实战

在现代软件架构逐渐走向微服务化、云原生化的过程中，应用的更新和迭代的频率变得越来越快，如何在尽可能保证用户体验不受影响的情况下完成应用的迭代发布就显得至关重要。目前业界普遍采用的几种典型的应用发布策略包括蓝绿发布、金丝雀发布、A/B Testing发布等。接下来本文将介绍如何使用Higress来实现Spring Cloud Alibaba应用发布的最佳实践。

前提条件

1. 安装Higress，并安装Istio CRD，参考Higress安装部署文档。
2. 安装Naocs，参考Nacos安装部署文档。

Higress支持将Nacos，Spring Cloud应用部署于K8s集群内，或者独立于K8s进行部署。为了演示方便，本文将Higress，Nacos，Spring Cloud应用都部署在本地K8s集群。

1. 通过Higress实现Spring Cloud应用的服务发现和路由

1.1. 部署SpringCloudAlibaba应用

我们在k8s集群中部署如上Deployment，其中通过NACOS_REGISTRY_ADDRESS和SPRING_CLOUD_NACOS_DEMO_VERSION两个环境变量指定了Nacos的地址以及注册时携带的version信息。SpringCloud应用的application.properties配置会读取这两个环境变量，如下所示：

1.2. 配置服务来源

Higress支持多种服务来源，包括Nacos/Zookeeper/DNS/固定IP，通过创建Nacos服务来源，Higress就可以发现注册到Nacos上的服务，从而完成转发请求到这些服务上。

进入Higress控制台（http://console.higress.io/）, 服务来源-创建服务来源 以创建服务来源。这里选择Nacos 2.X，然后填写注册中心的地址，端口，命名空间，服务分组等信息。注册中心的地址可以填写ip或者域名，本文将Nacos部署在本地K8s中，通过K8s service暴露Nacos端口，因此这里填写对应的service域名。

Higress 控制台：http://console.higress.io/

配置好Nacos服务来源后，我们可以在服务列表中看到我们刚刚部署好的应用。

1.3. 创建域名和路由

在Higress控制台上域名管理-创建域名，创建一条demo.springcloud.com域名用于后续的访问。

路由配置-创建路由，创建一条名为demo的路由，域名选择我们刚刚创建好的demo.springcloud.com，目标服务选择我们在1.2中看到的Spring Cloud应用，path配置为/version。

1.4. 请求验证

接下来我们就可以用配置好的路由来访问SpringCloud应用了，在请求时需要将demo.springcloud.com域名解析到本地ip，如下所示，可以成功得到返回结果。

注：如果您将Higress的80和443端口通过LoadBalancer的方式暴露出来，这里需要将本地ip替换为对应LoadBalancer的ip，详见Higress快速开始文档。

2. 利用Higress进行蓝绿发布

在蓝绿发布中，有两套相同的运行环境，一套是当前正在使用的生产环境（蓝色环境），另一套是新版本的测试环境（绿色环境）。新版本的代码只在绿色环境中运行，测试通过后，直接将流量切换到绿色环境中，从而完成新版本的上线。与此同时蓝色环境作为热备环境，当绿色环境出现问题需要回滚时，也可以直接将流量全部再切换回蓝色环境。

2.1. 部署新版本应用

在本地K8s集群中apply如下资源，以部署v2版本的SpringCloud应用。

部署完毕后，我们可以在Higress控制台的服务列表中看到应用已经有两个endpoint了，如下图所示：

2.2. 为服务划分子集

部署完v2版本的应用后，我们可以在Nacos控制台（http://localhost:8848/nacos）上看到service-provider这个服务有两个ip，它们的metadata中的version字段分别为v1和v2。Higress可以根据服务的信息将服务划分为不同的子集（subset），从而将请求转发到新版本或者老版本的应用中去。

在本地K8s集群中apply如下资源，从而根据应用信息中的version字段将服务划分为v1和v2两个子集。

2.3. 修改ingress路由规则

新版本应用上线后，我们需要把流量全部切到新版本应用中去，这时只需要简单地修改一下我们在1.3中创建的路由即可。我们可以在本地K8s集群中找到如下ingress资源，这对应了我们在1.3中创建的那条路由。

我们直接编辑这条ingress资源，将higress.io/destination这条annotation的value改为service-provider.DEFAULT-GROUP.public.nacos v2，即可将路由的目标服务修改为v2子集。

2.4. 请求验证

我们再发送请求，可以看到此时得到的是v2版本应用的返回结果，如此便实现了新版本的上线发布。

如果发现已上线的新版本出现问题需要回滚，只需要修改ingress路由中的higress.io/destination，将值更改为service-provider.DEFAULT-GROUP.public.nacos v1即可完成回滚。

3. 利用Higress进行金丝雀发布

金丝雀发布是将少量的请求引流到新版本上，因此部署新版本服务只需极小数的实例。验证新版本符合预期后，逐步调整流量权重比例，使得流量慢慢从老版本迁移至新版本，期间可以根据设置的流量比例，对新版本服务进行扩容，同时对老版本服务进行缩容，使得底层资源得到最大化利用。

3.1. 修改ingress路由规则

Higress可以通过一条Ingress注解轻松完成应用的金丝雀发布。我们编辑2.3中的ingress资源，将ingress中的higress.io/destination注解按如下方式进行修改：

这样Higress就可以把80%的流量转发到v1版本的应用，将20%的流量转发到v2版本的应用。

3.2. 请求验证

连续发送20条请求，可以看到v1和v2的比例符合我们在ingress中配置的比例。随着灰度的进行，可以逐渐调大v2版本的流量比例，最终完成新版本的平滑上线。

4. 利用Higress进行A/B Testing发布

A/B测试基于用户请求的信息将流量路由到新版本，这是一种基于请求内容匹配的灰度发布策略。只有匹配特定规则的请求才会被引流到新版本，常见的做法包括基于HTTP Header和Cookie。基于HTTP Header方式，例如User-Agent的值为Android的请求 （来自安卓系统的请求）可以访问新版本，其他系统仍然访问旧版本。基于Cookie方式，Cookie中通常包含具有业务语义的用户信息，例如普通用户可以访问新版本，VIP用户仍然访问旧版本。

4.1. 修改ingress路由规则

在本示例中，我们通过HTTP header中的User-Agent对流量进行区分，将Android系统的流量转发到v2版本，其他系统的流量仍保持v1版本。首先修改2.3中名叫demo的ingress资源，将higress.io/destination修改为v1版本，代表目前线上的流量全部会打到原来的v1版本：

当新版本部署完成后，再新建一条如下所示的ingress路由。这里采用正则匹配的方式，当User-Agent中含有Android时，将请求转发到v2版本的服务。

4.2. 请求验证

可以看到来自安卓系统的请求被转发到了v2版本，其余系统仍访问v1版本。

当新版本验证完毕需要全量上线时，只需要将demo路由的higress.io/destination注解修改为v2版本，并删除demo-ab路由，这样所有流量就都会访问v2版本了。

加入Higress和Spring Cloud Aliaba社区

Spring Cloud Alibaba社区交流群：钉钉群号

Higress社区交流群：钉钉群号

Higress 社区交流钉钉群中有历次 Higress 社区周会录屏，包括本文中提到的结合 Spring Cloud 应用发布的完整实操视频。

作者｜云科NearFar X Lab团队 左益、周志银、洪守伟、陈超、武超

一、导读

无锡拈花云科技服务有限公司（以下简称：拈花云科）是由拈花湾文旅和北京滴普科技共同孵化的文旅目的地数智化服务商。2022年底，拈花云科NearFar X Lab团队开始测试DolphinScheduler作为交付型项目和产品项目的任务调度工具。本文主要分享了拈花云科在任务调度工具的选择、迭代和实践过程中的经验，希望对大家有所启发。

二、业务背景

我们的服务对象主要是国内各个景区、景点，业务范围涵盖文旅行业的多个板块，如票务、交通、零售、住宿、餐饮、演绎、游乐、影院、KTV、租赁、服务、会务、康乐、康养、电商、客服、营销、分销、安防等。由于业务系统来源较多，多系统下的数据源类型差异化较大，所以在实施数据项目时我们需要能够支持多种数据来源（Mysql、Oracle、SqlServer、Hive、Excel……）的数据集成任务。同时根据大部分景区为国有化的特点，我们也需要具备能够提供私有化交付部署及SAAS化数据中台产品解决方案的双重服务支撑能力。

三、DolphinScheduler 调度系统选型过程

在团队成立之初为了快速构建MVP业务版本，我们沿用了团队同事之前用过的Kettle调度方案。该方案下通过Kettle完成可视化调度的配置及对于异构数据的集成任务，通过Python 调用HQL脚本完成基于Hive的传参数据计算。 基于MVP的构建，我们也开始思考，在我们的整体中台架构下该需要一个什么样的调度系统，以及除了调度这件事本身我们还需要哪些功能和能力。带着这些问题我们开始整理自己的需求，以及每个需求下有什么样的产品可以适配。

调度系统需要支撑的应用场景

文旅业态下的数据使用场景与其它业态下的使用场景大体相同，主要分为以下四类：

调度系统需要支撑的项目类型

我们选择的调度系统需要同时具备实施类项目、SAAS产品两种需求下的数据中台支撑能力

基于以上需求我们进行了调度系统的选型对比。网上有非常多关于Oozie、Azkaban、Airflow、DolphinScheduler、Xxl-job、Kettle等调度选型的文章及介绍，在此不过多的展开他们的优缺点。我们觉得每个产品的设计都有它自身的考量，都有适用与不适用的场景。结合我们自身的使用需求最终我们选择了使用DolphinScheduler作为数据中台的调度平台。

主要原因如下：

1. High Reliability（高可靠性） 高可靠性是我们看重的第一要点，因为不管是实施项目还是SAAS产品，只有系统稳定产品才可以正常运行。DolphinScheduler通过去中心化设计、原生 HA 任务队列支持、过载容错能力支持提供了高度稳健的环境。在我们半年的使用过程中也验证了其非常稳定。
2. High Scalability：（高扩展性） 由于我们要支持实施项目/SAAS产品两种场景下的使用，DolphinScheduler的多租户支持很好的契合了SAAS场景下资源隔离的使用需求。同时其扩缩容能力、高度的调度任务上限（10万+）都能很好的支撑我们业务的扩展性需求。
3. 丰富的数据集成能力 DolphinScheduler提供的任务类型已经远远涵盖了我们经常使用的任务类型（DataX、SeaTunnel的支持本身就涵盖了较多的Source2Target同步/推送场景）。
4. 支持Kubernetes部署 上文提到在私有化的部署方式下客户的部署环境大不相同，对于实施团队来说，如果能够简单、高效、一致的完成部署则会极大的提高项目投递部署效率，同时也能减少很多因环境原因而产生的问题。
5. 不仅仅是调度 在调研DolphinScheduler的过程中我们发现，除了调度本身这个环节，结合DCMM（数据管理能力成熟度评估模型）的国标8个能力域，DolphinScheduler在数据质量模块也做了很多实现，这无疑又命中了我们对于数据质量能力建设的需求。同时Apache DolphinScheduler的服务架构中还有AlertServer服务。作为整体数据中台方案来说后期完全可以将所有报警需求集成在Apache DolphinScheduler的报警服务中，避免多系统重复造轮子。从这些点考虑DolphinScheduler它不仅仅是一个调度工具而更像是一个数据开发平台。（期待随着社区的迭代会有更完整的生态实现）
6. 问题处理难度 DolphinScheduler社区非常的活跃，在加入DolphinScheduler社区群后每天都可以看到非常多的伙伴在交流关于Apache DolphinScheduler使用过程中的问题，社区人员也都积极的予以回复。同时Dolphinscheduler又是咱们国产开源软件，所以完全不必担心存在沟通上的障碍。

四、基于DolphinScheduler的项目实践

1、DolphinScheduler ON Kubernetes

DolphinScheduler支持多种部署方式:单机部署(Standalone)、伪集群部署(Pseudo-Cluster)、集群部署(Cluster)、Kubernetes部署(Kubernetes)。在项目实施的场景下由于客户提供的部署环境千变万化，我们需要一种稳定、快速、不挑环境的部署方式。Apache DolphinScheduler on K8S的部署方式很好的满足了我们的需求，此部署方式能极大的提高整体项目的部署效率及动态扩展性。

• Kubernetes是一个开源的容器编排平台，可以实现容器的自动化部署、扩缩容、服务发现、负载均衡，可以提高DolphinScheduler的可用性、可扩展性和可维护性
• Kubernetes可以支持多种存储类型，包括本地存储、网络存储和云，可以满足DolphinScheduler多节点共享持久化存储需求
• Kubernetes可以支持多种调度策略，包括亲和性、反亲和性、污点和容忍，可以优化DolphinScheduler的资源利用率，提高任务执行效率。
• Kubernetes可以支持多种监控和日志方案，包括Prometheus、Grafana、ELK等等，可以方便地对DolphinScheduler的运行状态和性能进行监控，分析和告警

在部署Apache DolphinScheduler on K8S 的过程中我们也曾遇到过一些问题，下面是我们总结的一些Kubernetes部署要点：

自定义镜像

dolphinscheduler-api

dolphinscheduler-master

dolphinscheduler-tools

dolphinscheduler-worker

配置文件修改

官方教程中的helm进行安装，在安装过程中需要修改源码中 “” 路径下的 “” 里的相关镜像和版本(注:原配置没有指定持久化储存类，会使用默认的存储类，建议是修改并使用可多节点读写并且可以弹性扩展的，多节点读写便于worker节点共用同一套lib)

生产配置

• dolphinscheduler-api 3 副本（注：默认是 1副本，但是实际使用中发现，平台页面在使用过程中会有卡顿，增加副本数之后，会有明显改善）
• dolphinscheduler-alert 1副本
• dolphinscheduler-zookeeper 1副本
• dolphinscheduler-worker 3副本
• dolphinscheduler-master 3副本

k8s部署总结

采用k8s部署后，最大感受就是可排除环境干扰，快速扩展，迁移，部署，帮助我司实现了数据中台私有化中的调度标准化，该方案已在多个景区中进行快速落地并应用。

2、基于SQL脚本血缘的DolphinScheduler工作流自动化实现

项目背景

基于景区中各个业务系统（票务、营销、安防、酒店、商业、能耗、停车等）在景区机房下建设数据中台，完成以下应用需求：

• 满足各个业务部门日常的报表需求
• 支持各类大屏看板展示
• 为景区的管理层决策提供数据依据

技术选型

数据仓库：Doris 调度工具：DolphinScheduler 使用版本：3.0.0 版本管理：Gitlab 容器编排：Kubernete

处理流程

• 业务分析与指标确认：与业务部门沟通，了解业务需求和目标，明确数据指标的定义、计算逻辑和展示方式。
• 数据仓库分层和设计：根据数据仓库的四层架构（ODS、DWD、DWS、ADS），设计数据模型和表结构，规范命名和注释。
• 数据脚本开发：编写数据抽取、清洗、转换、加载等脚本，实现数据从源系统到目标表的流转和处理。
• 数据任务调度：入仓后的执行脚本通过血缘识别依赖自动录入DolphinScheduler形成工作流任务调度（设置任务依赖、触发条件、重试策略等参数）监控任务运行状态和日志。
• 数据输出和文档：输出标准指标库和相关文档，供BI、可视化报表等使用，同时编写数据开发文档，记录数据开发过程中的关键信息和问题。

下面介绍下我们根据SQL血缘识别自动生成Apache DolphinScheduler调度任务的实现过程：

在DolphinScheduler平台上开发数据调度工作流的过程中我们遇到一个问题：如果一个工作流下的任务量太多，在原有的UI界面中想通过界面方式完成配置更改以及血缘关系的建立等操作会非常不便捷。即便是通过任务定义去配置，当上百个任务同时需要配置依赖关系时也是一个不小的工作量开销而且还容易出错，后期的更新迭代也较为不便。

我们结合工作流下SQL任务本身的特点（数仓SQL任务是整体按照Apache DolphinScheduler、DWD、DWS、Apache DolphinScheduler 的计算流程进行计算，每个表对应一个Apache DolphinScheduler的Task既每个Task都会包含SourceTable及TargetTabe。通过这层关系我们就可以构建起完整的数仓任务血缘依赖）。基于以上想法我们实现了从数据脚本自动生成对应的工作流和任务的自动化方案：

• 数据入仓后的开发脚本以每个表单为单位对应生成一个TaskSQL脚本提交到git。
• 自动化工具生成工作流及任务前自动从git库中获取最新的数据脚本。
• 自动化工具拉取到最新代码后识别和分析所有数据脚本之间的血缘关系。
• 自动化工具通过血缘关系自动将所有的任务关联并组装到一个工作流中：每个任务执行完成后，会立即触发下游任务，最大化地利用服务器资源。

以下是该实现的核心代码：

sql解析

节点对象定义

树型结构组装

部分效果图展示：

自动化生成的任务定义

自动化生成的工作流定义图 增量运行结果

自动化实现总结

1. 数仓调度任务的秒级上线与切换 通过该方式将数仓开发与DolphinScheduler解耦，实现了整体数据调度任务的秒级上线与切换。这样，我们可以快速复制标品化数据建模，极大地简化了实施的难度。
2. 血缘进行的任务关联与生成 通过血缘进行的任务关联与生成，大大提升了整体的资源利用率，也减少了人工的投入和成本。
3. 血缘监控和管理 通过血缘监控和管理，可以帮助我们及时发现和纠正任务执行过程中的问题和错误，保证数据质量和准确性。

五、未来规划

• 离在线统一调度 :实现基于Apache SeaTunnel的离线与实时数据同步调度，使得两个场景在一个平台完成。
• 应用基线管理：根据各任务的上下游依赖构建数据应用基线，并监控各目标任务及其依赖任务是否按时成功运行，以确保目标任务的准时产出。
• 任务指标监控：支持实时查看每个组件的指标，例如输入记录数、输出记录数和执行时间等。
• 数据血缘关系：上报数据源、目标表、字段等信息，构建数据血缘关系图，方便追溯数据的来源和影响。
• 资源文件版本管理：支持资源文件等的简单多版本管理，可以查看历史版本、回滚到指定版本等。

六、总结与致谢

1. 通过使用DolphinScheduler替换原有的调度工具，使得数据开发运维实现了平台统一化。基于Apache DolphinScheduler提供的强大集成扩展插件能力大大提升了数据集成与数据开发的效率。
2. DolphinScheduler自带的告警管理功能非常全面。配合此功能我们建立了运维值班制度以及微信告警通知的功能。故障发生时，运维人员可以第一时间收到报警通知，有效提高了故障的感知能力。
3. 基于DolphinScheduler调度技术方案在多个项目中的优异表现，使得我们更好的推动了公司的数据驱动战略。从实践中沉淀出公司的数据实施SOP，为各个客户、业务部门提供了及时、准确、全面的数据分析和决策支持。
4. 我们第一次部署时使用的是3.0.0 版本。目前社区已经发布了 3.1.7 迭代速度非常快。如果你们的项目正在选型调度工具，我们强烈建议使用DolphinScheduler。加入社区进群会有非常多的前辈、大佬带你起飞。DolphinScheduler 值得大力推荐，希望大家都能从中受益，祝愿DolphinScheduler生态越来越繁荣，越来越好！

本文由 白鲸开源科技 提供发布支持！

AI 时代，DevOps 与 AI 共价结合。AI 由业务需求驱动，提高软件质量，而 DevOps 则从整体提升系统功能。DevOps 团队可以使用 AI 来进行测试、开发、监控、增强和系统发布。AI 能够有效地增强 DevOps 驱动流程，从开发人员的业务实用性和支持的角度来看，评估 AI 在 DevOps 中的重要性是十分必要的。  

在本篇文章中，我们将一同探讨 DevOps 如何利用 AI 实现业务上的增强与提升。  

DevOps 中存在的摩擦

在 DevOps 实践中，摩擦可能源于软件开发和运营生命周期中的各种挑战和瓶颈。这里我们将总结6个 DevOps 中常见的摩擦。  

DevOps 中的一个主要摩擦就是开发和运营团队之间存在孤岛。孤岛团队通常有不同的目标、优先级和流程，导致沟通障碍、协作延迟以及实现共同目标的困难。这种摩擦会阻碍开发和运营的无缝集成，影响软件交付的速度和质量。  

此外，DevOps 中的手动流程，例如手动代码部署、环境设置和配置管理，同样会导致效率低下。手动任务耗时、容易出错，并且可能导致跨环境的不一致。这些过程会减慢开发周期，增加人为错误的可能性，并在企业实现高效可靠的软件交付的道路上制造障碍。各种 DevOps 实践中缺乏自动化会效率低下。当构建、测试和部署软件等重复性任务没有自动化时，会增加出错的机会，延长发布过程，并从更具战略意义的活动中转移宝贵的资源。自动化不足也会影响可扩展性，阻碍有效处理不断增加的工作负载的能力。  

不充分的反馈循环也会在 DevOps 中产生摩擦。当对代码更改、测试结果或部署的反馈延迟时，会妨碍快速迭代和及时响应问题的能力。缓慢的反馈循环会阻碍缺陷的检测，限制持续集成的有效性，并影响整个开发周期。对软件系统的性能、健康状况和用户体验的可见性不足会在 DevOps 中造成摩擦。如果没有对系统指标、日志和应用程序性能的全面监控和强大的可见性，识别问题、解决问题以及主动响应潜在瓶颈或故障就变得很困难。有限的可见性会导致停机时间延长、系统可靠性降低以及维护服务水平协议困难重重。当事件响应和管理流程定义不明确或缺乏自动化时，就会在 DevOps 中引入摩擦。缓慢的事件检测、低效的沟通和手动事件处理会延长解决时间，影响系统可用性、客户满意度和 DevOps 团队的整体效率。  

AI 时代下的 DevOps

DevOps 和 AI 在很多方面都非常匹配。DevOps 需要自动化才能尽可能有效，而 AI 是处理重复性活动的自然选择。当我们盘点 DevOps 团队软件发布延迟的最常见原因是什么时，回答提到了手动、耗时、费力且可能容易出错的活动，例如软件测试、代码审查、安全测试和代码开发。由此可见 AI 可能对许多团队简化这些程序至关重要。  

使用 AI 减少 DevOps 摩擦

AI 可以通过提供简化流程和增强协作的自动化、智能和洞察力，从而减少 DevOps 中的摩擦。

• 自动化流程：AI 可以自动化手动和重复性任务，例如环境设置、配置管理和部署流程。通过利用 AI 支持的工具和平台，DevOps 团队可以加快工作流程，减少人为错误，并释放资源用于更具战略意义的活动。

• 持续反馈和测试：AI 通过自动化代码分析、测试用例生成和质量保证来实现持续集成和测试。AI 算法分析代码存储库、识别潜在问题并提供可操作的建议。这通过提高代码质量、增加测试覆盖率和启用更快的反馈循环来减少摩擦。

• 智能监控和警报：AI 监控工具可以分析来自日志、指标和用户行为的大量数据。AI 算法检测异常、预测性能问题并触发智能警报。这提高了对系统健康状况的可见性，减少了平均检测时间 (MTTD)，并促进了更快的事件响应和解决。

• 预测分析和容量规划：AI 能够分析历史使用模式、用户行为和工作负载趋势，以提供准确的容量规划和资源分配建议。通过利用 AI 算法，DevOps 团队可以优化资源配置、预测峰值负载并避免过度配置和利用不足，从而减少由可扩展性和资源管理问题引起的摩擦。

• 智能事件管理：AI 可以自动进行事件检测、分类和解决。AI算法可以分析事件数据、识别模式并建议适当的补救措施。AI 驱动的聊天机器人和虚拟助手可以协助事件报告和响应，减少响应时间，最大限度地减少停机时间，并提高事件管理效率。

  通过利用 AI 在自动化、数据分析和智能决策方面的能力，企业可以减少 DevOps 中的摩擦。AI 可以更快、更准确地执行任务，提高可见性，增强协作，并使团队能够做出数据驱动的决策，从而实现更顺畅的工作流程、更高的效率和加速的软件交付。  

利用 AI 实现持续的安全性和合规性

利用 AI 来实现 DevOps 中的持续的安全性和合规性可以提供实时的风险评估、自动化的安全测试和合规检查，并通过智能化驱动的决策支持来减少潜在的安全漏洞和风险。  

• 实时风险评估：AI 监测和分析各种安全事件和数据源，包括日志、监控指标、网络流量等，以了解别潜在的威胁和漏洞。AI 算法以自动分析异常行为、恶意活动和安全事件模型，提供实时的风险评估，帮助 DevOps 团队快速识别和应对安全威胁。

• 合规性检查和自动化：AI 可以分析合规性要求、标准和方法，并自动检查系统的合规性。AI 算法自行扫描配置文件件、访问控制策略和日志数据，识别违反合规性规则的为此，并提供自动化的合规性报告。这有助于确保系统满足标准和标准的要求，并降低合规性风险。

• 智能决策支持：AI 为DevOps团队提供智能决策支持，帮助他们在安全和符合规范方面做出更明确的决策。通过分析。大量的安全数据和历史案例，AI 可以提供针对特定安全事件或合规问题的建议和最佳实践。这可以帮助团队更好地理解和评估风险，并采纳适当的措施来提出更高的安全性和合规性性。

• 自动化安全审计和日志分析：AI 分析和审计大纲模型的安全日志和事件数据，以便检测异常活动、入试测试和数据暴露。AI 算法可以自动识别别潜在的威胁模型，提供实时的报警和响应，帮助团队及时间发现并应对安全事件。

  其中自动合规性测试应确保满足所有要求，并且使功能可用于生产。自动合规性检查的复杂性可以从一个框架到自动化基础设施合规性，再到一些基本的东西，比如专门为检查合规性而创建的一组测试。  

成功案例一览

以下是在 DevOps 中利用 AI 的组织的著名示例、通过 AI 集成实现了对业务的正面影响并获得可观收益。  

• Netflix – Netflix 高度依赖于在其 DevOps 流程中使用 AI。他们复杂的推荐系统利用 AI 算法来分析用户数据并提供个性化的内容推荐。这个 AI 驱动的系统通过留住订阅者和提供个性化的用户体验，在很大程度上为他们的成功做出了贡献。

• Google – Google 在 (CI/CD) 流水线中使用 AI。其 Cloud Build 平台采用 AI 算法来检测代码漏洞、推荐修复并自动运行测试，以确保已部署软件的完整性和安全性。

• Facebook – 在 Facebook 的 DevOps 实践中使用 AI 提高了它们的性能。其 AI 系统 Proxygen 使用机器学习算法分析网络流量并优化网络服务器性能。此实施显著改善了更快的响应时间和更好的用户体验。

AI 与 DevOps 未来趋势

随着对有效且可扩展的软件开发流程的需求不断增长，AI-Enabled DevOps 的未来不可估量。为了最大限度地发挥其优势并保证无缝集成，AI 与 DevOps 集成需要仔细考虑。此外，预测分析、智能决策以及自动化测试和监控是 AI 在 DevOps 中的一些可能用途。为了降低漏洞风险并保持对法律法规的遵守，在 DevOps 中实施 AI 时优先考虑安全和数据隐私至关重要。  

最重要的是，企业如果想要实现支持 AI 的 DevOps，就必须在基础设施和培训方面进行投资，以支持 AI 驱动的解决方案的创建和实施。

在平时和开发者们交流的过程中，发现许多开发朋友尤其是新入门 Taier 的开发者，对于本地调试都有着诸多的不理解和问题。本文就大家平时问的最多的三个问题，服务编译，配置&本地运行，如何在 Taier 运行 Flink-standalone，进行简单的介绍，希望和大家共同交流学习。

服务编译

在本章将介绍服务编译中的两大插件 WorkerPlugins 及 DataSourcePlugin，以及 Taier 的前后端 UI & datadevelop 的作用。

WorkerPlugins 的作用

平台通过在 Taier-UI 运行任务之后，在 Taier-data-develop 中通过集群绑定到租户，再通过当前租户绑定集群中的组件类型以及版本号获取到不同的 WorkerPlugin，通过不同组件类型以及版本号进行提交任务。下图为整体的运行架构图：

WorkerPlugins 的编译

运行任务时这是一个必要的选项，当我们需要本地调试或者部署运行时，WorkerPlugins 的编译是必须进行的，在编译之后会获取到一个 WorkerPlugins 的目录，具体的编译过程请看文末视频链接中的演示讲解。

DataSourcePlugin 的作用

介绍完 WorkerPlugins 这个插件之后，来介绍一下另一个插件 DataSourcePlugin。

在 Taier-UI 中我们可以配置诸多不同类型的数据源，如 MySQL，Doris，Oracle 等，这些功能都是依赖着强大的 DataSourcePlugin 来进行实现。同时在使用离线同步中的 GUI 任务配置相关功能时，获取数据库信息也都是依赖 DataSourcePlugin 来完成的。

DataSourcePlugin 的编译

运行任务时这是一个必要的选项，当我们需要本地调试或者部署运行时，DataSourcePlugin 的编译是必须进行的，在编译之后会获取到一个 DataSourcePlugin 的目录，具体的编译过程请看文末视频链接中的演示讲解。

Taier-UI 的作用

在 Taier-UI 中我们可以进行配置不同类型的数据源、创建任务、任务运维、提交调度、集群配置、集群绑定等各种操作。

TaierDataDevelop 的作用

在 Taier- UI 中进行操作的所有后端服务 API 的支持都是来自于 TaierDataDevelop 的支持，该服务主要是与前后端交互。

配置&本地运行

该节内容主要介绍 TaierDataDevelop 的配置，在此进行后端服务的端口 ZK、WorkerPlugins、DataSourcePlugin 数据库等相关配置，前后端的启动，以及集群配置(Flink-standalone)和绑定。

具体的代码流程请看文末视频链接中的演示讲解。

运行 Flink-Standalone 实践

配置集群

在任务运行时，通过配置的 CDH 集群，使用配置 YARN 组装任务，通过 ChunJun 或直接提交任务至 Flink、Doris、Spark 等计算引擎中。

配置&运行任务

通过任务 GUI 组装任务配置，包括数据来源和去向，通过字段映射、任务自定义参数等相关配置从而进行任务配置。

视频课程&PPT获取

视频课程：

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

课件获取：

https://www.dtstack.com/resources/1031

《数栈产品白皮书》：https://www.dtstack.com/resources/1004?src=szsm

《数据治理行业实践白皮书》下载地址：https://www.dtstack.com/resources/1001?src=szsm 想了解或咨询更多有关袋鼠云大数据产品、行业解决方案、客户案例的朋友，浏览袋鼠云官网：https://www.dtstack.com/?src=szkyzg

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

摘要：解决SimpleDateFormat类在高并发场景下的线程安全问题可以有多种方式，这里，就列举几个常用的方式供参考。

本文分享自华为云社区《【高并发】更正SimpleDateFormat类线程不安全问题分析的错误》，作者： 冰 河 。

解决SimpleDateFormat类在高并发场景下的线程安全问题可以有多种方式，这里，就列举几个常用的方式供参考，大家也可以在评论区给出更多的解决方案。

1.局部变量法

最简单的一种方式就是将SimpleDateFormat类对象定义成局部变量，如下所示的代码，将SimpleDateFormat类对象定义在parse(String)方法的上面，即可解决问题。

此时运行修改后的程序，输出结果如下所示。

至于在高并发场景下使用局部变量为何能解决线程的安全问题，会在【JVM专题】的JVM内存模式相关内容中深入剖析，这里不做过多的介绍了。

当然，这种方式在高并发下会创建大量的SimpleDateFormat类对象，影响程序的性能，所以，这种方式在实际生产环境不太被推荐。

2.synchronized锁方式

将SimpleDateFormat类对象定义成全局静态变量，此时所有线程共享SimpleDateFormat类对象，此时在调用格式化时间的方法时，对SimpleDateFormat对象进行同步即可，代码如下所示。

此时，解决问题的关键代码如下所示。

运行程序，输出结果如下所示。

需要注意的是，虽然这种方式能够解决SimpleDateFormat类的线程安全问题，但是由于在程序的执行过程中，为SimpleDateFormat类对象加上了synchronized锁，导致同一时刻只能有一个线程执行parse(String)方法。此时，会影响程序的执行性能，在要求高并发的生产环境下，此种方式也是不太推荐使用的。

3.Lock锁方式

Lock锁方式与synchronized锁方式实现原理相同，都是在高并发下通过JVM的锁机制来保证程序的线程安全。通过Lock锁方式解决问题的代码如下所示。

通过代码可以得知，首先，定义了一个Lock类型的全局静态变量作为加锁和释放锁的句柄。然后在simpleDateFormat.parse(String)代码之前通过lock.lock()加锁。这里需要注意的一点是：为防止程序抛出异常而导致锁不能被释放，一定要将释放锁的操作放到finally代码块中，如下所示。

运行程序，输出结果如下所示。

此种方式同样会影响高并发场景下的性能，不太建议在高并发的生产环境使用。

4.ThreadLocal方式

使用ThreadLocal存储每个线程拥有的SimpleDateFormat对象的副本，能够有效的避免多线程造成的线程安全问题，使用ThreadLocal解决线程安全问题的代码如下所示。

通过代码可以得知，将每个线程使用的SimpleDateFormat副本保存在ThreadLocal中，各个线程在使用时互不干扰，从而解决了线程安全问题。

运行程序，输出结果如下所示。

此种方式运行效率比较高，推荐在高并发业务场景的生产环境使用。

另外，使用ThreadLocal也可以写成如下形式的代码，效果是一样的。

5.DateTimeFormatter方式

DateTimeFormatter是Java8提供的新的日期时间API中的类，DateTimeFormatter类是线程安全的，可以在高并发场景下直接使用DateTimeFormatter类来处理日期的格式化操作。代码如下所示。

可以看到，DateTimeFormatter类是线程安全的，可以在高并发场景下直接使用DateTimeFormatter类来处理日期的格式化操作。

运行程序，输出结果如下所示。

使用DateTimeFormatter类来处理日期的格式化操作运行效率比较高，推荐在高并发业务场景的生产环境使用。

6.joda-time方式

joda-time是第三方处理日期时间格式化的类库，是线程安全的。如果使用joda-time来处理日期和时间的格式化，则需要引入第三方类库。这里，以Maven为例，如下所示引入joda-time库。

引入joda-time库后，实现的程序代码如下所示。

这里，需要注意的是：DateTime类是org.joda.time包下的类，DateTimeFormat类和DateTimeFormatter类都是org.joda.time.format包下的类，如下所示。

运行程序，输出结果如下所示。

使用joda-time库来处理日期的格式化操作运行效率比较高，推荐在高并发业务场景的生产环境使用。

解决SimpleDateFormat类的线程安全问题的方案总结

综上所示：在解决解决SimpleDateFormat类的线程安全问题的几种方案中，局部变量法由于线程每次执行格式化时间时，都会创建SimpleDateFormat类的对象，这会导致创建大量的SimpleDateFormat对象，浪费运行空间和消耗服务器的性能，因为JVM创建和销毁对象是要耗费性能的。所以，不推荐在高并发要求的生产环境使用。

synchronized锁方式和Lock锁方式在处理问题的本质上是一致的，通过加锁的方式，使同一时刻只能有一个线程执行格式化日期和时间的操作。这种方式虽然减少了SimpleDateFormat对象的创建，但是由于同步锁的存在，导致性能下降，所以，不推荐在高并发要求的生产环境使用。

ThreadLocal通过保存各个线程的SimpleDateFormat类对象的副本，使每个线程在运行时，各自使用自身绑定的SimpleDateFormat对象，互不干扰，执行性能比较高，推荐在高并发的生产环境使用。

DateTimeFormatter是Java 8中提供的处理日期和时间的类，DateTimeFormatter类本身就是线程安全的，经压测，DateTimeFormatter类处理日期和时间的性能效果还不错（后文单独写一篇关于高并发下性能压测的文章）。所以，推荐在高并发场景下的生产环境使用。

joda-time是第三方处理日期和时间的类库，线程安全，性能经过高并发的考验，推荐在高并发场景下的生产环境使用。

关注，第一时间了解华为云新鲜技术~

2023年6月24日，北京数变科技有限公司和腾讯云计算（北京）有限责任公司（以下简称：腾讯云）完成了 Databend Cloud 在腾讯云兼容性认证。

本公司的产品《Databend 云数据仓库系统 V1.0》 正式通过了腾讯云产品《腾讯云容器服务 v3 COS 对象存储》的技术认证，并收到了腾讯云颁发的产品认证证书。 测试结果显示，经过严格联合测试，双方产品相互兼容良好、运行稳定。

腾讯云是由腾讯集团倾力打造的云计算品牌，面向全世界各个国家和地区的政府机构、企业组织和个人开发者，提供全球领先的云计算、大数据、人工智能等技术产品与服务。以卓越的科技能力打造丰富的行业解决方案，构建开放共赢的云端生态，推动产业互联网建设，助力各行各业实现数字化升级。

Databend Cloud 是基于开源云原生数仓项目 Databend 打造的一款易用、低成本、高性能的新一代大数据分析平台，实现按需、按量付费的 Data Cloud, 让你专注于数据价值的挖掘，算你所想。

Databend Cloud 已经支持了腾讯云广州区，欢迎体验使用（https://app.databend.cn/qcloud-landing）。 如果有其它区需求的朋友也可以联系我们。

图左：北京数变科技有限公司（Databend）联合创始人—王吟

图右：腾讯云存储产品负责人—崔剑

提到主从复制，我们可能立马会联想到 MySQL 的主从复制。

MySQL 主从复制是 MySQL 高可用机制之一，数据可以从数据库服务器主节点复制到一个或多个从节点。

这篇文章，我们聊聊 RocketMQ 的主从复制，希望你读完之后，能够理解主从复制的精髓。

1 同步与异步

在 RocketMQ 的集群模式中，Broker 分为 Master 与 Slave，一个 Master 可以对应多个 Slave，但是一个 Slave 只能对应一个 Master。

每个 Broker 与 Name Server 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 Name Server。

Master 节点负责接收客户端的写入请求，并将消息持久化到磁盘上。而 Slave 节点则负责从 Master 节点复制消息数据，并保持与 Master 节点的同步。

• 同步复制

生产者发送消息后，Master 接收到存储消息请求，将消息数据同步给 Slave 后，才将存储结果返回给生产者。同步复制模式下，发送消息会有一定延迟，系统吞吐量也会降低。

• 异步复制

生产者发送消息后，Master 接收到存储消息请求，将消息存储后，直接将存储结果返回给生产者。 Master 和 Slave 再通过异步的方式同步数据，这种复制模式具有较小的延迟，可以实现比较高的吞吐量。

若 Master 出现故障，有些数据可能未写入 Slave ，未同步的数据可能丢失。

复制流程分为两个部分：数据复制和消息数据复制。

• 主从服务器同步主题，消费者进度，延迟消费进度，消费者配置数据
• 主从服务器同步消息数据

2 数据复制

Slave Broker 定时任务每隔 10 秒会同步数据，包括主题，消费进度，延迟消费进度，消费者配置。

同步主题时, Slave Broker 向 Master Broker 发送 RPC 请求，返回数据后，首先加入本地缓存里，然后持久化到本地。

3 消息数据复制

下图是 Master 和 Slave 消息数据同步的流程图。

1、Master 启动后监听指定端口；

Master 启动后创建 AcceptSocketService 服务 , 用来创建客户端到服务端的 TCP 链接。

RocketMQ 抽象了链接对象 HAConnection , HAConnection 会启动两个线程，分别用于读服务和写服务：

• 读服务：处理 Slave 发送的请求
• 写服务：用于向 Slave 传输数据

2、Slave 启动后，尝试连接 Master ，建立 TCP 连接；

HAClient 是客户端 Slave 的核心类 ，负责和 Master 创建连接和数据交互。

客户端在启动后，首先尝试连接 Master , 查询当前消息存储中最大的物理偏移量 ，并存储在变量 currentReportedOffset 里。

3、Slave 判定拉取间隔是否大于 5 秒，则向 Master 汇报已拉取消息偏移量；

上报进度的数据格式是一个 Long 类型的 Offset , 8个字节 , 非常简洁 。

发送到 Socket 缓冲区后 , 修改最后一次的写时间 lastWriteTimestamp 。

4、Master 解析请求偏移量，从消息文件中检索该偏移量后的所有消息；

当 Slave 上报数据到 Master 时，触发 SelectionKey.OP_READ 事件，Master 将请求交由 ReadSocketService 服务处理：

当 Slave Broker 传递了自身 commitlog 的 maxPhyOffset 时，Master 会马上中断 ，执行 方法。

processReadEvent 方法的核心逻辑是设置 Slave 的当前进度 offset ，然后通知复制线程当前的复制进度。

写服务 WriteSocketService 从消息文件中检索该偏移量后的所有消息，并将消息数据发送给 Slave。

5、Slave 接收到数据，将消息数据 append 到消息文件 commitlog 里 。

首先 HAClient 类中调用 dispatchReadRequest 方法 ， 解析出消息数据 ；

然后将消息数据 append 到本地的消息存储。

4 同步的实现

从数据复制流程图，我们发觉数据复制本身就是一个异步执行的，但是同步是如何实现的呢？

Master Broker 接收到写入消息的请求后 ，调用 Commitlog 的 aysncPutMessage 方法写入消息。

这段代码中，当 commitLog 执行完 appendMessage 后， 需要执行刷盘任务和同步复制两个任务。

但这两个任务并不是同步执行，而是异步的方式，使用了 CompletableFuture 这个异步神器。

当 HAConnection 读服务接收到 Slave 的进度反馈，发现消息数据复制成功，则唤醒 future 。

最后 Broker 组装响应命令 ，并将响应命令返回给客户端。

5 总结

1、主从复制包含数据复制和消息数据复制两个部分；

2、数据复制

​ Slave Broker 定时任务每隔 10 秒向 Master Broker 发送 RPC 请求，将数据同步到缓存后，然后持久化到磁盘里；

3、消息数据复制

• Master 启动监听指定端口
• Slave 启动 HaClient 服务，和 Master 创建 TCP 链接
• Slave 向 Master 上报存储进度
• Master 接收进度，消息文件中检索该偏移量后的所有消息，并传输给 Slave
• Slave 接收到数据后，将消息数据 append 到本地的消息存储。

4、同步的实现

​ 当 commitLog 执行完 appendMessage 后， 需要执行刷盘任务和同步复制两个任务，这里用到了 CompletableFuture 这个异步神器。

​ 当 HAConnection 读服务接收到 Slave 的进度反馈，发现消息数据复制成功，则唤醒 future 。最后 Broker 组装响应命令 ，并将响应命令 返回给客户端 。

如果我的文章对你有所帮助，还请帮忙点赞、在看、转发一下，你的支持会激励我输出更高质量的文章，非常感谢！

原文链接： Go 语言 context 都能做什么？

很多 Go 项目的源码，在读的过程中会发现一个很常见的参数 ，而且基本都是作为函数的第一个参数。

为什么要这么写呢？这个参数到底有什么用呢？带着这样的疑问，我研究了这个参数背后的故事。

开局一张图：

核心是 接口：

包含四个方法：

• ：返回一个 channel，当 times out 或者调用 cancel 方法时。
• ：返回一个错误，表示取消 ctx 的原因。
• ：返回截止时间和一个 bool 值。
• ：返回 key 对应的值。

有四个结构体实现了这个接口，分别是：, , 和 。

其中 是空类型，暴露了两个方法：

一般情况下，会使用 作为根 ctx，然后在其基础上再派生出子 ctx。要是不确定使用哪个 ctx，就使用 。

另外三个也分别暴露了对应的方法：

遵循规则

在使用 Context 时，要遵循以下四点规则：

1. 不要将 Context 放入结构体，而是应该作为第一个参数传入，命名为 。
2. 即使函数允许，也不要传入 的 Context。如果不知道用哪种 Context，可以使用 。
3. 使用 Context 的 Value 相关方法只应该用于在程序和接口中传递和请求相关的数据，不要用它来传递一些可选的参数。
4. 相同的 Context 可以传递给不同的 goroutine；Context 是并发安全的。

WithCancel

返回带有新 通道的父级副本。当调用返回的 函数或关闭父上下文的 通道时，返回的 的 通道将关闭。

取消此上下文会释放与其关联的资源，因此在此上下文中运行的操作完成后，代码应立即调用 。

举个例子：

这段代码演示了如何使用可取消上下文来防止 goroutine 泄漏。在函数结束时，由 启动的 goroutine 将返回而不会泄漏。

输出：

WithDeadline

返回父上下文的副本，并将截止日期调整为不晚于 。如果父级的截止日期已经早于 ，则 在语义上等同于 。

当截止时间到期、调用返回的取消函数时或当父上下文的 通道关闭时，返回的上下文的 通道将关闭。

取消此上下文会释放与其关联的资源，因此在此上下文中运行的操作完成后，代码应立即调用取消。

举个例子：

这段代码传递具有截止时间的上下文，来告诉阻塞函数，它应该在到达截止时间时立刻退出。

输出：

WithTimeout

返回 。

取消此上下文会释放与其关联的资源，因此在此上下文中运行的操作完成后，代码应立即调用取消。

举个例子：

这段代码传递带有超时的上下文，以告诉阻塞函数应在超时后退出。

输出：

WithValue

返回父级的副本，其中与 关联的值为 。

其中键必须是可比较的，并且不应是字符串类型或任何其他内置类型，以避免使用上下文的包之间发生冲突。 的用户应该定义自己的键类型。

为了避免分配给 ，上下文键通常具有具体的 类型。或者，导出的上下文键变量的静态类型应该是指针或接口。

举个例子：

这段代码演示了如何将值传递到上下文以及如何检索它（如果存在）。

输出：

本文的大部分内容，包括代码示例都是翻译自官方文档，代码都是经过验证可以执行的。如果有不是特别清晰的地方，可以直接去读官方文档。

以上就是本文的全部内容，如果觉得还不错的话欢迎点赞，转发和关注，感谢支持。

官方文档：

• https://pkg.go.dev/context@go1.20.5

源码分析：

• https://mritd.com/2021/06/27/golang-context-source-code/
• https://www.qtmuniao.com/2020/07/12/go-context/
• https://seekload.net/2021/11/28/go-context.html

推荐阅读：

• Go 语言 map 如何顺序读取？
• Go 语言 map 是并发安全的吗？
• Go 语言切片是如何扩容的？
• Go 语言数组和切片的区别
• Go 语言 new 和 make 关键字的区别
• 为什么 Go 不支持 []T 转换为 []interface
• 为什么 Go 语言 struct 要使用 tags

虽然本周 GitHub 热榜都是一些熟悉的面孔，但还是有不少新开源的项目，比如受启发于 Stripe IDs 的 UUIDv7 扩展 typeid，相信有了它，数据标识问题就迎刃而解了。此外，还有刚开源就获得近 2k star 的抠背景项目 background-removal-js，一键就能去掉图片背景。

还有一个非常有意思的 IDE，它是运行在容器里的 devpod，还有老牌的 GIS 项目，你可以用喜欢的画作来绘制地图的 QGIS。

至于 AFFiNE、Tkinter-Designer、google-ctf 是什么，就要留给你自己去发现了。

以下内容摘录自微博@HelloGitHub 的 GitHub Trending 及 Hacker News 热帖（简称 HN 热帖），选项标准： | | ，根据项目 release 时间分类，发布时间不超过 14 day 的项目会标注 ，无该标志则说明项目 release 超过半月。由于本文篇幅有限，还有部分项目未能在本文展示，望周知 🌝

• 本文目录
  • 1. 本周特推
    • 1.1 运行在容器里的 IDE：devpod
    • 1.2 跨平台 GIS：QGIS
  • 2. GitHub Trending 周榜
    • 2.1 知识管理工具：AFFiNE
    • 2.2 唯一标识：typeid
    • 2.3 快速构建 Python 应用：Tkinter-Designer
    • 2.4 快速去背景：background-removal-js
    • 2.5 安全挑战：google-ctf
  • 3. HelloGitHub 热评
    • 3.1 隐私计算平台：primihub
    • 3.2 PyQt 组件库：PyQt-Fluent-Widgets
  • 4. 往期回顾

1. 本周特推

1.1 运行在容器里的 IDE：devpod

主语言：Go

DevPod 是一个仅限客户端使用的工具，它可基于 devcontainer.json 在任何存储端创建可复现的开发环境。每个开发环境都在容器中运行，并通过 devcontainer.json 进行指定存储。目前，devpod 支持 K8s 集群、云端虚拟机、任何可访问的远程机器。

GitHub 地址→https://github.com/loft-sh/devpod

1.2 跨平台 GIS：QGIS

主语言：C++

一个功能齐全、用户友好、免费的开源地理信息系统，即 GIS，它可运行在 Unix、Windows、macOS 等系统之上。具有以下特性：

1. 可管理空间数据
2. 精美的制图，下图便是根据梵高的经典画作绘制的地图
3. 地理空间分析
4. 支持高度定制化，具有良好的可扩展性

GitHub 地址→https://github.com/qgis/QGIS

2. GitHub Trending 周榜

2.1 知识管理工具：AFFiNE

本周 star 增长数：1,250+，主语言：TypeScript

一个类 Notion 的知识管理工具，支持离线使用。同 Notion 一样，集成了笔记、表格、数据库等功能。

GitHub 地址→https://github.com/toeverything/AFFiNE

2.2 唯一标识：typeid

本周 star 增长数：1,600+，主语言：Go

受启发于 Stripe IDs（用于跟踪提现的追踪 ID）的全局唯一标识符 typeid，它是类型安全，且支持 K 排序的 UUIDv7 扩展。

TypeIDs 的规范编码为由三个部分组成的小写字符串：

1. 类型前缀（最多 63 个字符，全部为小写 ASCII [a-z]）
2. 下划线 作为分隔符
3. 一个 128 位 UUIDv7 编码，使用修改后的 base32 编码表示为 26 个字符的字符串。

以下便是一个示例：

GitHub 地址→https://github.com/jetpack-io/typeid

2.3 快速构建 Python 应用：Tkinter-Designer

本周 star 增长数：800+，主语言：Python

一个简单快捷的方法来创建 Python 图形用户界面，Tkinter Designer 旨在加速 Python 中的 GUI 开发过程。因为使用到 Figma，所以它能方便地在 Python 中创建漂亮的 Tkinter GUI。它借助 Figma API 来分析设计文件并创建 GUI 所需的相应代码和文件。

GitHub 地址→https://github.com/ParthJadhav/Tkinter-Designer

2.4 快速去背景：background-removal-js

本周 star 增长数 1,950+，主语言：TypeScript

不知道有多少小伙伴用过一个去背景服务叫做 remove.bg，这是一个开源的去背景服务，不用受限于 remove.bg 的清晰度限制，你可以自己抠掉图像中的背景。当然它提供了在线试用链接：https://img.ly/showcases/cesdk/web/background-removal/web

GitHub 地址→https://github.com/imgly/background-removal-js

2.5 安全挑战：google-ctf

本周 star 增长数：550+

google-ctf 收录了自 2017 年以来 Google CTF（安全网络竞赛）的挑战，如果你想试试你的密码学、逆向工程、漏洞检测等安全技能到底如何，不妨试试这些难题。

GitHub 地址→https://github.com/google/google-ctf

3. HelloGitHub 热评

在这个章节，我们将会分享下本周 HelloGitHub 网站上的热评项目，HG 开源项目评价体系刚上线不久，期待你的评价。

3.1 隐私计算平台：primihub

主语言：C++

随着《数据安全法》和《个人信息保护法》的相继颁布，隐私计算技术在近两年迎来了前所未有的热度。该项目是由密码学专家团队打造的隐私计算平台，它开箱即用、安全可靠，支持隐匿查询、隐私求交、联合统计、数据资源管理等功能，实现了“数据可用不可见”，为数据安全流通保驾护航。

HG 评价地址→https://hellogithub.com/repository/686b51bae1becc94f72f7646a

3.2 PyQt 组件库：PyQt-Fluent-Widgets

主语言：Python

基于 PyQt/PySide 的 Fluent Design 风格组件库，内含多种美观、实用的组件，支持亮暗主题切换和自定义主题色。

HG 评价地址→https://hellogithub.com/repository/80b9c3ecfbb10851d08834

4. 往期回顾

往期回顾：

• 这就是艺术，优雅的二维码生成器「GitHub 热点速览」
• 未来的编程语言「GitHub 热点速览」

以上为 2023 年第 26 个工作周的 GitHub Trending 🎉如果你 Pick 其他好玩、实用的 GitHub 项目，来 HelloGitHub 和大家一起分享下哟 🌝

高可用指标与问题

高可用，英文单词High Availability，缩写HA，它是分布式系统架构设计中一个重要的度量。业界通常用多个9来衡量系统的可用性，如下表：

既然有可用率，有一定会存在不可用的情况。系统宕机一般分为有计划的和无计划的，有计划的如日常维护、系统升级等，无计划的如设备故障、突发断电等。我们对此作如下分类：

1.设备故障：机房断电、硬盘损坏、交换机故障。

2.网络故障：网络带宽拥堵、网络连接中断。

3.安全问题：利用系统漏洞进行网络攻击。

4.性能问题：CPU利用率太高、内存不足、磁盘IO过载、数据库慢SQL。

5.升级维护：由于业务变更或技术改进而引起的系统升级。

6.系统问题：分布式系统中存在服务的依赖而导致数据的不一致性，或是核心服务出现异常。

高可用主要手段

负载均衡

负载均衡（Load Balance），它将工作任务分发到多个工作单上进行运行，它可以提高网络设备的带宽，提升网络数据处理能力，增强网络的稳定性。可防止机房断电、网络设备故障等问题。

负载均衡的实现可分为硬件负载与软件负载。硬件负载由专门的设备完成专门的任务，这种方式性能较高同时成本也高；软件负载通过软件代码实现，此种方式耗费操作系统资源，性能较低，容易出现BUG，也容易引起安全问题。

负载策略一般有轮询策略、随机策略、最小连接策略以及最短响应时间策略。

轮询策略：讲用户请求轮流分配给服务器，这种算法比较简单。

随机策略：随机选择一台服务器来执行任务。

最小连接策略：把请求分配给活动连接数最小的后端服务器。

最短响应时间策略：将请求分配给平均响应时间最短的服务器。

限流

限流就是避免服务过载，随着流量的提高，无论负载策略如何高效，系统的某个环节总会过载。就如木桶能装多少水取决于最短的那块木板，我们是无法保证系统的每个部分都保持同样的高吞吐量，因此要考虑如何优雅地提供有损服务。

常用的三种限流算法：计数器算法、滑动窗口算法、漏桶算法、令牌桶算法。

计数器算法：使用计数器在一定周期内累加某个接口的访问次数，当达到限流阈值时，触发限流策略，进入下一个周期后，重新开始计数。此算法较为简单，但会降低服务器的负载能力。

滑动窗口算法：将时间周期划分成更小的周期，按小周期来进行计数，根据时间滑动删除过期的小周期。这种算法使得周期划分得越小服务器的负载能力越高。

漏桶算法：将请求直接放入漏桶中，如果当前访问量超出漏桶的限流值，则把后来的请求予以丢弃，这样可以最大限度地提高服务器的负载能力。

令牌桶算法：以（时间周期/限流值）的速度向令牌桶里增加令牌，直到装满桶的容量，当请求到达时，分配一个令牌让其通过，如果没有获取到令牌则触发限流机制。

异步调用

异步调用一般有两种方式：一种是异步回调，一种是消息队列。消息队列方式也算是限流的一种手段，可以让请求一个一个地被处理，避免并发太高而引起的应用无法及时处理。这种方式相对与限流来讲，是一种无损的解决方案。但这种方案仅适用于非实时响应的业务。

超时重试与幂等设计

很多文章把超时重试与幂等设计分开来讨论，但我却认为它们是相辅相成，密切相关的。在设计超时重试时，一定要考虑幂等设计

超时重试机制：由于服务器宕机、网络延时、服务器线程死锁等原因，导致应用程序无法先限定时间内对服务调用方进行响应。因此当发生调用超时后，应用程序可根据调度策略进行重试。被调用的服务没有及时响应，可能会存在两种情况，一是服务内部发生异常，导致执行失败，没有返回任何消息；一是执行的服务耗时太长，没有及时响应，但实际已经执行成功。所以针对第二种情况要做幂等设计。

幂等设计：多次相同参数的请求对系统造成的作业都是相同的。常见的幂等方案有：MCVV多版本并发、唯一索引、token机制、悲观锁、状态机幂等、只读操作等。

降级与熔断

服务降级与服务熔断都是为了解决服务雪崩的问题，但不要把他们混为一谈，它们是有本质区别的。

降级是对系统的某个功能进行降级，可以只提供部分功能也可以完全停止该功能。降级一般由开关来进行控制，在不重启服务的情况下，对功能进行降级。它常常发生在高并发时段、机器卡顿、下游不太重要的服务异常等情况下。

熔断没有开关，它是一个框架级的设计，常常被称作断路器。它的主要作用是，当下游的服务因为某种原因变得不可用或服务不及时，为了保证整体服务的可用性，不再调用目标服务，直接返回默认处理或容错处理，从而使得整体服务可以快速响应。例如SpringCloud中的Hystrix。

降级与熔断的主要区别是手动与自动。降级主要是通过配置中心的热刷新功能，人为地对开关进行打开与关闭操作。而熔断则是根据事先设计好的策略，系统自动地根据策略来进行开关操作。但它们都是对功能进行关闭。

架构模式

主备模式

实际是一主多备，master负责提供读写服务，slave作为数据备份，一旦主机宕机，将其中一个备节点作为主节点。

主从复制

实际是一主多从，master对外提供读写服务，slave作为数据备份提供只读服务。主机定期复制数据给从机。多副本的关键问题是保证数据一致性，通常需要考虑数据同步延时的问题。

集群分片

集群分片是为了解决每台机器上存储全量数据的问题，面对大数据单机的存储量总是有上限的，当面对PB级数据时，单机是无法支撑的，因此就需要对数据进行分片。

异地多活

异地就是指在地理位置上不同的地方，可分为同城异地、跨城异地、跨国异地，多活就是指不同地理位置上的系统都能够提供服务。这种架构的复杂度较高，且部署成本也会提高。

设计原则：

1、 只把核心业务设计为异地多活，比如流量大、盈利高的业务

2、 保证核心数据的一致性与实时性，且可丢失、可恢复

3、 可采用多种数据同步的方案，比如存储系统同步、消息队列同步

4、 异地多活仅适用于大部分用户，以地区来论，覆盖主要城区

总结

在互联网架构设计中，高可用是必不可少的环节，要从网络架构、服务架构、数据架构以及软硬件架构等多方面来分析设计，是架构师必备的技能之一。

作者：京东零售 谷伟

来源：京东云开发者社区

一、引言

Excel表格在后台管理系统中使用非常广泛，多用来进行批量配置、数据导出工作。在日常开发中，我们也免不了进行Excel数据处理。

那么，如何恰当地处理数据量庞大的Excel文件，避免内存溢出问题？本文将对比分析业界主流的Excel解析技术，并给出解决方案。

如果这是您第一次接触Excel解析，建议您从第二章了解本文基础概念；如果您已经对POI有所了解，请跳转第三章阅读本文重点内容。

二、基础篇-POI

说到Excel读写，就离不开这个圈子的的老大哥——POI。

Apache POI是一款Apache软件基金会用Java编写的免费开源的跨平台的 Java API，全称Poor Obfuscation Implementation，“简洁版的模糊实现”。它支持我们用Java语言和包括Word、Excel、PowerPoint、Visio在内的所有Microsoft Office文档交互，进行数据读写和修改操作。

（1）“糟糕”的电子表格

在POI中，每种文档都有一个与之对应的文档格式，如97-2003版本的Excel文件（.xls），文档格式为HSSF——Horrible SpreadSheet Format，意为“糟糕的电子表格格式”。虽然Apache幽默而谦虚地将自己的API冠以“糟糕”之名，不过这确实是一款全面而强大的API。

以下是部分“糟糕”的POI文档格式，包括Excel、Word等：

（2）OOXML简介

微软在Office 2007版本推出了基于XML的技术规范：Office Open XML，简称OOXML。不同于老版本的二进制存储，在新规范下，所有Office文档都使用了XML格式书写，并使用ZIP格式进行压缩存储，大大提升了规范性，也提高了压缩率，缩小了文件体积，同时支持向后兼容。简单来说，OOXML定义了如何用一系列的XML文件来表示Office文档。

Xlsx文件的本质是XML

让我们看看一个采用OOML标准的Xlsx文件的构成。我们右键一个Xlsx文件，可以发现它可以被ZIP解压工具解压（或直接修改扩展名为.zip后解压），这说明：Xlsx文件是用ZIP格式压缩的。解压后，可以看到如下目录格式：

打开其中的“/xl”目录，这是这个Excel的主要结构信息：

其中workbook.xml存储了整个Excel工作簿的结构，包含了几张sheet表单，而每张表单结构存储在/wooksheets文件夹中。styles.xml存放单格的格式信息，/theme文件夹存放一些预定义的字体、颜色等数据。为了减少压缩体积，表单中所有的字符数据被统一存放在sharedStrings.xml中。经过分析不难发现，Xlsx文件的主体数据都以XML格式书写。

XSSF格式

为了支持新标准的Office文档，POI也推出了一套兼容OOXML标准的API，称作poi-ooxml。如Excel 2007文件（.xlsx）对应的POI文档格式为XSSF（XML SpreadSheet Format）。

以下是部分OOXML文档格式：

（3）UserModel

在POI中为我们提供了两种解析Excel的模型，UserModel（用户模型）和EventModel（事件模型） 。两种解析模式都可以处理Excel文件，但解析方式、处理效率、内存占用量都不尽相同。最简单和实用的当属UserModel。

UserModel & DOM解析

用户模型定义了如下接口：

1. Workbook-工作簿，对应一个Excel文档。根据版本不同，有HSSFWorkbook、XSSFWorkbook等类。

2. Sheet-表单，一个Excel中的若干个表单，同样有HSSFSheet、XSSFSheet等类。

3. Row-行，一个表单由若干行组成，同样有HSSFRow、XSSFRow等类。

4. Cell-单格，一个行由若干单格组成，同样有HSSFCell、XSSFCell等类。

可以看到，用户模型十分贴合Excel用户的习惯，易于理解，就像我们打开一个Excel表格一样。同时用户模型提供了丰富的API，可以支持我们完成和Excel中一样的操作，如创建表单、创建行、获取表的行数、获取行的列数、读写单格的值等。

为什么UserModel支持我们进行如此丰富的操作？因为在UserModel中，Excel中的所有XML节点都被解析成了一棵DOM树，整棵DOM树都被加载进内存，因此可以进行方便地对每个XML节点进行随机访问。

UserModel数据转换

了解了用户模型，我们就可以直接使用其API进行各种Excel操作。当然，更方便的办法是使用用户模型将一个Excel文件转化成我们想要的Java数据结构，更好地进行数据处理。

我们很容易想到关系型数据库——因为二者的实质是一样的。类比数据库的数据表，我们的思路就有了：

1. 将一个Sheet看作表头和数据两部分，这二者分别包含表的结构和表的数据。

2. 对表头（第一行），校验表头信息是否和实体类的定义的属性匹配。

3. 对数据（剩余行），从上向下遍历每一个Row，将每一行转化为一个对象，每一列作为该对象的一个属性，从而得到一个对象列表，该列表包含Excel中的所有数据。

接下来我们就可以按照我们的需求处理我们的数据了，如果想把操作后的数据写回Excel，也是一样的逻辑。

使用UserModel

让我们看看如何使用UserModel读取Excel文件。此处使用POI 4.0.0版本，首先引入poi和poi-ooxml依赖：

我们要读取一个简单的Sku信息表，内容如下：

如何将UserModel的信息转化为数据列表？

我们可以通过实现反射+注解的方式定义表头到数据的映射关系，帮助我们实现UserModel到数据对象的转换。实现基本思路是： ① 自定义注解，在注解中定义列号，用来标注实体类的每个属性对应在Excel表头的第几列。 ② 在实体类定义中，根据表结构，为每个实体类的属性加上注解。 ③ 通过反射，获取实体类的每个属性对应在Excel的列号，从而到相应的列中取得该属性的值。

以下是简单的实现，首先准备自定义注解ExcelCol，其中包含列号和表头：

接下来，根据Sku字段定义Sku对象，并添加注解，列号分别为0，1，2，并指定表头名称：

然后，用反射获取表头的每一个Field，并以列号为索引，存入Map中。从Excel的第二行开始（第一行是表头），遍历后面的每一行，对每一行的每个属性，根据列号拿到对应Cell的值，并为数据对象赋值。根据单格中值类型的不同，如文本/数字等，进行不同的处理。以下为了简化逻辑，只对表头出现的类型进行了处理，其他情况的处理逻辑类似。全部代码如下：

最后，将转换完成的数据列表打印出来。运行结果如下：

Tips：如果您的程序出现“NoClassDefFoundError”，请引入ooxml-schemas依赖：

版本选择见下表，如POI 4.0.0对应ooxml-schemas 1.4版本：

UserModel的局限

以上处理逻辑对于大部分的Excel文件都很适用，但最大的缺点是内存开销大，因为所有的数据都被加载入内存。实测，以上3列的Excel文件在7万行左右就会出现OOM，而XLS文件最大行数为65535行，XLSX更是达到了行，如果将几万甚至百万级别的数据全部读入内存，内存溢出风险极高。

那么，该如何解决传统UserModel无法处理大批量Excel的问题呢？开发者们给出了许多精彩的解决方案，请看下一章。

三、进阶篇-内存优化的探索

接下来介绍本文重点内容，同时解决本文所提出的问题：如何进行Excel解析的内存优化，从而处理百万行Excel文件？

（1）EventModel

前面我们提到，除了UserModel外，POI还提供了另一种解析Excel的模型：EventModel事件模型。不同于用户模型的DOM解析，事件模型采用了SAX的方式去解析Excel。

EventModel & SAX解析

SAX的全称是Simple API for XML，是一种基于事件驱动的XML解析方法。不同于DOM一次性读入XML，SAX会采用边读取边处理的方式进行XML操作。简单来讲，SAX解析器会逐行地去扫描XML文档，当遇到标签时会触发解析处理器，从而触发相应的事件Handler。我们要做的就是继承DefaultHandler类，重写一系列事件处理方法，即可对Excel文件进行相应的处理。

下面是一个简单的SAX解析的示例，这是要解析的XML文件：一个sku表，其中包含两个sku节点，每个节点有一个id属性和三个子节点。

对照XML结构，创建Java实体类：

自定义事件处理类SkuHandler：

其中，SkuHandler重写了三个事件响应方法：

startElement（）——每当扫描到新XML素时，调用此方法，传入XML标签名称qName，XML属性列表attributes；

characters（）——每当扫描到未在XML标签中的字符串时，调用此方法，传入字符数组、起始下标和长度；

endElement（）——每当扫描到XML素的结束标签时，调用此方法，传入XML标签名称qName。

我们用一个变量tagName存储当前扫描到的节点信息，每次扫描节点发送变化时，更新tagName；

用一个Sku实例维护当前读入内存的Sku信息，每当该Sku读取完成时，我们打印该Sku信息，并执行相应业务逻辑。这样，就可以做到一次读取一条Sku信息，边解析边处理。由于每行Sku结构相同，因此，只需要在内存维护一条Sku信息即可，避免了一次性把所有信息读入内存。

调用SAX解析器时，使用SAXParserFactory创建解析器实例，解析输入流即可，Main方法如下：

输出结果如下：

以上演示了SAX解析的基础原理。EventModel的API更复杂，同样通过重写Event handler，实现SAX解析。有兴趣的读者，请参见POI官网的示例代码： https://poi.apache.org/components/spreadsheet/how-to.html

EventModel的局限

POI官方提供的EventModel API虽然使用SAX方式解决了DOM解析的问题，但是存在一些局限性：

① 属于low level API，抽象级别低，相对比较复杂，学习使用成本高。

② 对于HSSF和XSSF类型的处理方式不同，代码需要根据不同类型分别做兼容。

③ 未能完美解决内存溢出问题，内存开销仍有优化空间。

④ 仅用于Excel解析，不支持Excel写入。

因此，笔者不建议使用POI原生的EventModel，至于有哪些更推荐的工具，请看下文。

（2）SXSSF

SXSSF简介

SXSSF，全称Streaming XML SpreadSheet Format，是POI 3.8-beta3版本后推出的低内存占用的流式Excel API，旨在解决Excel写入时的内存问题。它是XSSF的扩展，当需要将大批量数据写入Excel中时，只需要用SXSSF替换XSSF即可。SXSSF的原理是滑动窗口——在内存中保存一定数量的行，其余行存储在磁盘。这么做的好处是内存优化，代价是失去了随机访问的能力。SXSSF可以兼容XSSF的绝大多数API，非常适合了解UserModel的开发者。

内存优化会难以避免地带来一定限制：

① 在某个时间点只能访问有限数量的行，因为其余行并未被加载入内存。

② 不支持需要随机访问的XSSF API，如删除/移动行、克隆sheet、公式计算等。

③ 不支持Excel读取操作。

④ 正因为它是XSSF的扩展，所以不支持写入Xls文件。

UserModel、EventModel、SXSSF对比

到这里就介绍完了所有的POI Excel API，下表是所有这些API的功能对比，来自POI官网：

可以看到，UserModel基于DOM解析，功能是最齐全的，支持随机访问，唯一缺点是CPU和内存效率不稳定；

EventModel是POI提供的流式读取方案，基于SAX解析，仅支持向前访问，其余API不支持；

SXSSF是POI提供的流式写入方案，同样仅能向前访问，支持部分XSSF API。

（3）EasyExcel

EasyExcel简介

为了解决POI原生的SAX解析的问题，阿里基于POI二次开发了EasyExcel。下面是引用自EasyExcel官网的介绍：

Java解析、生成Excel比较有名的框架有Apache poi、jxl。但他们都存在一个严重的问题就是非常的耗内存，poi有一套SAX模式的API可以一定程度的解决一些内存溢出的问题，但POI还是有一些缺陷，比如07版Excel解压缩以及解压后存储都是在内存中完成的，内存消耗依然很大。 easyexcel重写了poi对07版Excel的解析，一个3M的excel用POI sax解析依然需要100M左右内存，改用easyexcel可以降低到几M，并且再大的excel也不会出现内存溢出；03版依赖POI的sax模式，在上层做了模型转换的封装，让使用者更加简单方便。

如介绍所言，EasyExcel同样采用SAX方式解析，但由于重写了xlsx的SAX解析，优化了内存开销；对xls文件，在上层进一步进行了封装，降低了使用成本。API上，采用注解的方式去定义Excel实体类，使用方便；通过事件监听器的方式做Excel读取，相比于原生EventModel，API大大简化；写入数据时，EasyExcel对大批数据，通过重复多次写入的方式从而降低内存开销。

EasyExcel最大的优势是使用简便，十分钟可以上手。由于对POI的API都做了高级封装，所以适合不想了解POI基础API的开发者。总之，EasyExcel是一款值得一试的API。

使用EasyExcel

引入easyexcel依赖：

首先，用注解定义Excel实体类：

接下来，重写AnalysisEventListener中的invoke和doAfterAllAnalysed方法，这两个方法分别在监听到单行解析完成的事件时和全部解析完成的事件时调用。每次单行解析完成时，我们打印解析结果，代码如下：

测验一下，用它解析一个十万行的excel，该文件用UserModel读取会OOM，如下：

运行结果：

（4）Xlsx-streamer

Xlsx-streamer简介

Xlsx-streamer是一款用于流式读取Excel的工具，同样基于POI二次开发。虽然EasyExcel可以很好地解决Excel读取的问题，但解析方式为SAX，需要通过实现监听器以事件驱动的方式进行解析。有没有其他的解析方式呢？Xlsx-streamer给出了答案。

译自官方文档的描述：

如果您过去曾使用 Apache POI 读取 Excel 文件，您可能会注意到它的内存效率不是很高。 阅读整个工作簿会导致严重的内存使用高峰，这会对服务器造成严重破坏。 Apache 必须读取整个工作簿的原因有很多，但其中大部分与该库允许您使用随机地址进行读写有关。 如果（且仅当）您只想以快速且内存高效的方式读取 Excel 文件的内容，您可能不需要此功能。 不幸的是，POI 库中唯一用于读取流式工作簿的东西要求您的代码使用类似 SAX 的解析器。 该 API 中缺少所有友好的类，如 Row 和 Cell。 该库充当该流式 API 的包装器，同时保留标准 POI API 的语法。 继续阅读，看看它是否适合您。 注意：这个库只支持读取 XLSX 文件。

如介绍所言，Xlsx-streamer最大的便利之处是兼容了用户使用POI UserModel的习惯，它对所有的UserModel接口都给出了自己的流式实现，如StreamingSheet、StreamingRow等，对于熟悉UserModel的开发者来说，几乎没有学习门槛，可以直接使用UserModel访问Excel。

Xlsx-streamer的实现原理和SXSSF相同，都是滑动窗口——限定读入内存中的数据大小，将正在解析的数据读到内存缓冲区中，形成一个临时文件，以防止大量使用内存。缓冲区的内容会随着解析的过程不断变化，当流关闭后，临时文件也将被删除。由于内存缓冲区的存在，整个流不会被完整地读入内存，从而防止了内存溢出。

与SXSSF一样，因为内存中仅加载入部分行，故牺牲了随机访问的能力，仅能通过遍历顺序访问整表，这是不可避免的局限。换言之，如果调用StreamingSheet.getRow(int rownum)方法，该方法会获取sheet的指定行，会抛出“不支持该操作”的异常。

Xlsx-streamer最大的优势是兼容UserModel，尤其适合那些熟悉UserModel又不想使用繁琐的EventModel的开发者。它和SXSSF一样，都通过实现UserModel接口的方式给出解决内存问题的方案，很好地填补了SXSSF不支持读取的空白，可以说它是“读取版”的SXSSF。

使用Xlsx-streamer

引入pom依赖：

下面是一个使用xlsx-streamer的demo：

如代码所示，Xlsx-streamer的使用方法为：使用StreamingReader进行参数配置和流式读取，我们可以手动配置固定的滑动窗口大小，有两个指标，分别是缓存在内存中的最大行数和缓存在内存的最大字节数，这两个指标会同时限制该滑动窗口的上限。接下来，我们可以使用UserModel的API去遍历访问读到的表格。

使用十万行量级的excel文件实测一下，运行结果：

StAX解析

Xlsx-streamer底层采用的解析方式，被称作StAX解析。StAX于2004年3月在JSR 173规范中引入，是JDK 6.0推出的新特性。它的全称是Streaming API for XML，流式XML解析。更准确地讲，称作“流式拉分析”。之所以称作拉分析，是因为它和“流式推分析”——SAX解析相对。

之前我们提到，SAX解析是一种事件驱动的解析模型，每当解析到标签时都会触发相应的事件Handler，将事件“推”给响应器。在这样的推模型中，解析器是主动，响应器是被动，我们不能选择想要响应哪些事件，因此这样的解析比较不灵活。

为了解决SAX解析的问题，StAX解析采用了“拉”的方式——由解析器遍历流时，原来的响应器变成了驱动者，主动遍历事件解析器（迭代器），从中拉取一个个事件并处理。在解析过程中，StAX支持使用peek()方法来”偷看”下一个事件，从而决定是否有必要分析下一个事件，而不必从流中读取事件。这样可以有效提高灵活性和效率。

下面用StAX的方式再解析一下相同的XML：

这次我们不需要监听器，把所有处理的逻辑集成在一个方法中：

以上代码与SAX解析的逻辑是等价的，用XMLEventReader作为迭代器从流中读取事件，循环遍历事件迭代器，再根据事件类型做分类处理。有兴趣的小伙伴可以自己动手尝试一下，探索更多StAX解析的细节。

四、结论

EventModel、SXSSF、EasyExcel和Xlsx-streamer分别针对UserModel的内存占用问题给出了各自的解决方案，下面是对所有本文提到的Excel API的对比：

建议您根据自己的使用场景选择适合的API：

1. 处理大批量Excel文件的需求，推荐选择POI UserModel、EasyExcel；

2. 读取大批量Excel文件，推荐选择EasyExcel、Xlsx-streamer；

3. 写入大批量Excel文件，推荐选择SXSSF、EasyExcel。

使用以上API，一定可以满足关于Excel开发的需求。当然Excel API不止这些，还有许多同类型的API，欢迎大家多多探索和创新。

页面链接：

POI官网： https://poi.apache.org/

EasyExcel官网：https://easyexcel.opensource.alibaba.com

Xlsx-streamer Github： https://github.com/monitorjbl/excel-streaming-reader

作者：京东保险 孙昊宇

来源：京东云开发者社区

编者按：随着大规模预训练模型的发展和应用，大模型微调技术已经在很多领域都有了突破性的进展，并推动了人工智能技术的发展与应用。

本文会简要介绍上下文学习（in-context learning）的含义，并介绍对LLMs进行微调的各种可行方式。还能够帮助我们了解如何选择大语言模型的微调方法。

快快阅读此文，开启一趟大模型微调学习之旅吧！

以下是译文，Enjoy!

本文经原作者授权，由Baihai IDP编译。如需转载译文，请联系获取授权。

原文链接：https://magazine.sebastianraschka.com/p/finetuning-large-language-models

作者 | SEBASTIAN RASCHKA, PHD

编译 | 岳扬

在如今高速发展的人工智能领域，高效地利用大语言模型（LLMs）已经变得越来越重要。但是，利用大语言模型的方式太多了，如果你才刚刚开始接触它，可能会感到不知所措。

实质上，我们可以通过两种主要方式将预训练大语言模型用于新任务：上下文学习（in-context learning）以及微调（finetuning） 。

本文我们将简要介绍上下文学习（in-context learning）的含义，并介绍对LLMs进行微调的各种可行方式。

01 In-Context Learning和Indexing

自从GPT-2（Radford等人[1]）和GPT-3（Brown等人[2]）问世以来，我们发现，在通用文本语料库上进行预训练的生成式大语言模型（LLMs）可以进行上下文学习。这意味着，如果我们想要执行新的特定任务，我们无需对预训练的LLM进行进一步的训练或微调，可以通过输入Prompt直接提供一些目标任务的示例，如下面的例子所示。

上下文学习的例子

如果我们不能直接访问模型（例如如果我们通过API使用模型），那么上下文学习就用处非常大。

与上下文学习相关的是hard prompt tuning，即试图通过修改输入改善输出，如下图所示。

An illustration of (hard) prompt tuning顺便说一下，我们称这种方法为hard prompt tuning，因为在这种方法中，我们直接修改了输入的单词或tokens。稍后我们将讨论另外一种版本的方法，称为soft prompt tuning（或通常称为prompt tuning）。

刚刚提到的prompt tuning方法为参数微调（parameter finetuning）提供了一种替代方案（且这种方案更节省资源）。然而，它的性能通常不及微调（finetuning），因为这种方法不会针对特定任务更新模型的参数，这可能会限制它对不同特定任务间细微差别的适应能力。此外，prompt tuning可能需要进行大量工作，耗费大量人力财力，因为这种方法需要人工参与比较不同prompt的质量。

在我们更进一步地讨论微调之前，先来了解另一种利用纯粹的上下文学习的方法——indexing。在大语言模型领域中，indexing可以被视为一种上下文学习的变通方法，其使得LLMs能够转变为信息检索系统（information retrieval systems），从外部资源和网站中提取数据。在这个过程中，indexing模块将文档或网站分解成较小的片段，并将它们转换为可以存储在向量数据库中的向量（vectors） 。然后，当用户提交查询（query）时，indexing模块计算嵌入查询（embedded query）与数据库中每个向量之间的向量相似度（vector similarity）。最终，indexing模块检索出与查询最相似的前k个嵌入（embeddings），生成响应。

An illustration of indexing.

02 常规的基于特征的方法和微调方法

如果我们无法直接访问大型语言模型（LLM），例如通过API或使用用户界面与LLM进行交互，那么上下文学习是一种有价值且用户友好的方法。

然而，如果我们可以直接接触到LLM，使用目标领域的数据对其进行调整（adapting）和微调（finetuning）通常会获得更好的结果。那么，如何使一个模型适应目标任务呢？下图概述了三种常见的方法：

3种常规的基于特征的方法和微调的方法

下文中，我们将以对编码器类型（encoder-style）的大型语言模型（例如BERT）微调为例，解析具体的微调方式原理和示例代码。下述示例微调任务为分类器任务，在这个任务中，我们试图预测电影评论是正面情感还是负面情感。需要注意的是，除了对编码器类型（encoder-style）的LLM进行微调外，同样的方法也适用于类似GPT的解码器类型（decoder-style）的LLM。在后续的文章中，我将会举例说明这一点。

此外，我们还可以对解码器类型（decoder-style）的LLM进行微调，以生成对特定指令的多句子回答（multiple-sentence answers），而不仅仅是进行文本分类。关于这个问题，我会在未来的文章中提供实战案例，敬请期待。

2.1 基于特征的方法

在基于特征的方法（feature-based approach）中，我们需要加载一个预训练LLM，并将其应用于目标数据集。在这种方法中，我对生成训练集的输出嵌入（output embeddings）特别感兴趣，这些嵌入可以作为输入特征（input features）用于训练分类模型（classification model）。虽然这种方法在像BERT这样以嵌入为重点的模型中非常常见，但我们也可以从生成式的 GPT-style 模型中提取嵌入。

接下来，我们可以使用逻辑回归模型（logistic regression model）、随机森林（random forest）或XGBoost等任何我们想要使用的模型作为分类模型。（然而，根据我的经验，在这种情况下，像逻辑回归（logistic regression）这样的线性分类器（linear classifiers）表现最佳）

理论上，我们可以用下面这段代码来解释基于特征的方法：

(对此感兴趣的读者可以在此处[4]找到完整的代码）

2.2 微调方法 I —— 更新输出层（Output Layers）

有一种方法与上述基于特征的方法比较相关，叫做微调输出层（本文称之为微调方法 I）。与基于特征的方法类似，这种方法不改变预训练LLM的参数，只会训练新增加的输出层，类似于在嵌入特征（embedded features）上训练逻辑回归分类器（logistic regression classifier）或小型多层感知器（small multilayer perceptron）。

相关代码如下：

（对此感兴趣的读者可以在此处[4]找到完整的代码）

从理论上讲，这种方法的建模性能和速度（modeling performance and speed）应该与基于特征的方法差不多，因为都会去冻结骨干模型（frozen backbone model）（译者注：通过冻结骨干模型，我们可以保持其模型权重不变，仅对任务模块进行训练。这样可以减少需要更新的参数数量，提高训练效率，并在一定程度上保留原始骨干模型的特征提取能力）。然而，由于基于特征的方法使得预计算（pre-compute）和存储训练数据集的嵌入特征（embedded features）稍微更容易一些，所以在具体场景中，基于特征的方法可能更加方便。

2.3 微调方法 II – 更新所有层（All Layers）

虽然BERT那篇论文（Devlin等人）说过，仅微调输出层（output layer）可以实现与微调所有层相当的模型性能，但由于后者涉及的参数更多，所以成本要高得多。 例如，BERT基础模型约有1.1亿个参数。然而，用于二分类的BERT基础模型最后一层仅包含1500个参数。此外，BERT基础模型的最后两层共有6万个参数，这仅占总模型大小的0.6%左右。

我们选择走哪条路径会根据目标任务和目标领域与模型预训练的数据集的相似程度而有所不同。但是在具体实践中，微调所有层几乎总是能获得更优的模型性能。

因此，在优化模型性能时，使用预训练LLM的黄金标准（the gold standard）是更新所有层（本文称之为微调方法 II）。从理论上讲，微调方法 II 与微调方法 I 非常相似。唯一的区别是方法II不会冻结预训练LLM的参数，而是对其进行微调：

（对此感兴趣的读者可以在此处[4]找到完整的代码）

上面的这段代码被用来训练一个基于DistilBERT基础模型的电影评论分类器（你可以去the code notebooks看一看[4]）

1）基于特征的方法与逻辑回归：83%的测试准确率（accuracy）；

2）微调方法 I，更新最后两层：87%准确率（accuracy）；

3）微调方法 II，更新所有层：92%准确率（accuracy）。

这些准确率结果符合预期，即微调更多层通常会获得更好的性能，但也需要花费更高的成本。

本文3种方法的训练效率和模型性能权衡经验之谈

上述场景强调了微调的三种最不同或最极端的情况：即仅训练最后一层（或几层）与训练所有层。当然，具体效果可能会因模型和数据集而异，但在探索两者之间的各种情况也是值得的。 例如，有时候我们只需训练一半的模型，就能获得与训练完成的模型相同的性能（更多关于轻量化微调（parameter-efficient finetuning）的内容将在下一节介绍）。如果你是一个好奇宝宝，下图描述了在IMDB电影评论数据集（IMDB movie review dataset）的2万个训练实例上进行微调的DistilBERT模型的预测性能（predictive performances）和训练时间。

在IMDB电影评论数据集上微调的预训练DistilBERT模型的性能。相关代码可以在GitHub上找到[5]

正如我们可以看到的，仅训练最后一层是最快速的，但模型性能也最差。 符合预期的是，训练更多层会提高模型性能，但也会增加计算成本。 有一件事情非常有趣，可以看到当训练两个全连接的输出层（fully connected output layers）和最后两个transformer blocks（从左边数起的第三个block）时，预测性能（predictive performance）就已经趋于饱和。因此，在这种特定情况下（即对于这个特定的模型和数据集组合），训练超过这些层（layers）似乎是一种计算资源的浪费。

03 轻量化微调(Parameter-Efficient Fine-Tuning)

轻量化微调让我们能够重复使用预训练的模型，同时最大限度地减少算力和资源的占用。总体来说，轻量化微调具有以下五个优点：

1. 能够降低计算成本（需要更少的GPU和GPU运行时间）；

2. 拥有更快的训练时间（更快地完成训练）；

3. 具备更低的硬件要求（适用于较小显存的GPU和较小的内存）；

4. 具有更好的模型性能（降低过拟合）；

5. 需要更少的存储空间（大部分weights可以在不同任务（tasks）之间共享）。

在之前的章节中，我们了解到微调更多的层通常会带来更好的结果。上面的实验是基于一个相对较小的DistilBERT模型。但是，如果我们想微调那些几乎无法容纳在GPU显存中的较大模型（例如最新的生成式LLM模型），我们该怎么办呢？当然，我们可以使用上述基于特征的方法或者微调方法I。但假设我们想要获得与微调方法II类似的模型质量呢？

这些年来，研究人员们开发了几种技术（Lialin等人[6]）来微调LLM，使其只需要训练少量的参数，也能具有较高的模型性能。这些方法通常被称为参数高效微调技术（parameter-efficient finetuning techniques，PEFT，本文亦译作轻量化微调）。

一些目前最受欢迎的PEFT技术在下图中可见。

最受欢迎的轻量化微调（PEFT）技术可选择项

那么，这些技术是如何工作的呢？简单来说，都涉及到引入少量额外的参数进行微调（而不是像我们在上面的微调方法 II中那样对所有层进行微调）。从某种意义上说，微调方法 I（只微调最后一层）也可以被认为是一种轻量化微调（PEFT）技术。然而，像前缀微调（prefix tuning）、adapters和Low-Rank Adaptation (LoRA,低秩自适应))等技术，它们都“修改”了多个层（layers），以极低的成本实现了更好的预测性能（predictive performance）。

由于本文的篇幅目前已经很长了，而且这些都是超级有趣的技术，我将在未来单独介绍这些技术。

04 基于人类反馈的强化学习（Reinforcement Learning with Human Feedback）

在基于人类反馈的强化学习（Reinforcement Learning with Human Feedback，RLHF）中，使用一种结合了监督学习（supervised learning）和强化学习（reinforcement learning）的方法对预训练模型进行微调——这一方法被 ChatGPT 使用而得到大力推广，而 ChatGPT 又是基于InstructGPT（Ouyang等人[7]）的。

在RLHF中，通过让人类对不同的模型输出进行排序或评分来收集人类反馈，从而提供奖励信号（reward signal） 。收集到的奖励标签（reward labels） 可以用来训练奖励模型（reward model） ，进而反过来指导LLM（Language Model）适应人类的喜好。

奖励模型本身是通过监督学习（supervised learning）来学习的（通常使用预训练的LLM作为基础模型）。接下来，使用奖励模型来更新预训练的LLM，使其适应人类偏好——训练过程使用一种被称为近端策略优化（proximal policy optimization，Schulman等人[8]）的强化学习方法。

InstructGPT相关论文的截图，概述了RLHF的过程

为什么要使用奖励模型而不是直接在人类反馈的基础上训练预训练模型？这是因为让人类参与模型的学习过程会产生瓶颈（bottleneck），因为我们无法实时获取反馈。

这篇文章的篇幅已经很长了，所以我把更详细的解释推迟到以后的文章中，敬请期待！

05 总结

对预训练LLM的所有层（layers）进行微调仍然是适应新目标任务（new target tasks）的黄金标准（the gold standard），但是对于预训练的Transformer模型，有几种有效的替代方法。诸如基于特征的方法、上下文学习和轻量化微调等这些方法能够有效地将LLM应用于新的任务，同时还能最大限度地减少计算成本和计算资源。

此外，基于人类反馈的强化学习（RLHF）作为监督微调（supervised finetuning，SFT）的一种替代方法，可以提升模型性能。

END

参考资料

1.https://d4mucfpksywv.cloudfront.net/better-language-models/language_models_are_unsupervised_multitask_learners.pdf

2.https://arxiv.org/abs/2005.14165

3.https://arxiv.org/abs/1810.04805

4.https://github.com/rasbt/LLM-finetuning-scripts/tree/main/conventional/distilbert-movie-review

5.https://github.com/rasbt/LLM-finetuning-scripts/tree/main/conventional/distilbert-movie-review/layerwise-experiment

6.https://arxiv.org/abs/2303.15647

7.https://arxiv.org/abs/2203.02155

8.https://arxiv.org/abs/1707.06347

本文经原作者授权，由Baihai IDP编译。如需转载译文，请联系获取授权。

原文链接：

https://magazine.sebastianraschka.com/p/finetuning-large-language-models

1 前言

Jmeter是Apache基金会下的一款应用场景非常广的压力测试工具，具备轻量、高扩展性、分布式等特性。Jmeter已支持实现随机数、计数器、时间戳、大小写转换、属性校验等多种函数，方便使用人员使用。如果在使用过程中存在和业务强耦合的常用功能函数，在Jmeter不支持的情况下，那就需要单独开发自定义函数实现特定功能。

本文介绍如何开发Jmeter自定义函数实现快速生成京东宙斯下单标准sign，同时深刻理解Jmeter的插件化机制及高扩展性特性。

2 开发准备

1. Java基础开发
2. Maven基本使用
3. 开发依赖版本
   JDK 1.8.0Maven 3.6.3Jmeter 5.4.3

3 自定义函数核心实现

3.1 新建项目

• 新建maven项目，这里项目名为：JSF_Sampler
• 因为是基于Jmeter的扩展，需要依赖包Jmeter两个核心包，分别是：
• ApacheJMeter_core
• ApacheJMeter_java
• ApacehJMeter_functions

pom.xml文件核心配置如下

3.2 继承实现AbstractFunction类

实现类依次实现以下几个步骤

1）新建实现类并继承 AbstractFunction

• 注意：实现类的包名必须包含xxx.functions.xxx，Jmeter使用命名规则实现实现类的加载。

2）重写以下方法，每个方法的用途见下方代码注释

• execute()
• setParameters()
• getReferenceKey()
• getArgumentDesc()

3.3 最终项目结构

4 Jmeter加载扩展包

以上开发完成，打包此项目，注意这里的打包要包含依赖包。

4.1 maven构建配置

4.2 项目打包

4.3 Jmeter加载扩展包

将打包后的扩展包放置到Jmeter的ext目录：apache-jmeter-5.4.3/lib/ext/

启动Jmeter后，Jmeter会自动加载ext目录中的扩展包

打开Jmeter函数助手后，可以看到本次实现类中打印的相关日志

5 自定义函数调用调试

5.1 打开Jmeter函数助手，选择自定义函数

5.2 京东宙斯接口验证

这里使用京东快递获取预制运单号接口，输入GET请求后，直接运行函数【Generate & Copy to clipboard】，出参返回32位sign值。

6 总结

本文通过自定义函数实现了京东宙斯下单标准sign的生成，希望通过本项目大家可以学习到：

• 如何二次开发Jmeter，实现自己特有的自定义函数。
• 理解为何官方介绍Jmeter是插件化的，高扩展性特性。
• 更好的理解Jmeter内部处理机制。

作者：京东物流 苗浩冲

来源：京东云开发者社区

• 在进行序列化操作之前，我们还对系统进行压测，通过分析cpu，线程，垃圾回收情况等；运用火焰图分析系统性能，找出程序中占用CPU资源时间最长的代码块。
• 代码放置GitHub：https://github.com/nateshao/leetcode/tree/main/source-code/src/main/java/com/nateshao/source/code/serializable

1.什么是序列化与反序列化？

聊到序列化与反序列化，先看看这个这个是什么或者是干嘛的

定义：序列化是指把转换为的过程；是指把恢复为的过程；

一般都会知道有两个目的：和。

1. 对象持久化。实现了数据的持久化，通过序列化可以把数据永久的保存在硬盘上；
2. 网络传输。我们知道网络传输的是字节序列，那么利用序列化实现远程通信，即在网络上传递对象的字节序列。 （序列化与反序列化则实现了 进程通信间的对象传送，发送方需要把这个Java对象转换为字节序列，才能在网络上传送；接收方则需要把字节序列再恢复为Java对象）

总结：序列化的目的是将对象变成字节序列，这样一来方便持久化存储到磁盘，避免程序运行结束后对象就从内存里消失，另外字节序列也更便于网络运输和传播

2.选择序列化技术有哪些维度

这里并不是说哪个是最好，只能说是各有千秋，所以面对不同的背景采用不同的技术方案。

在同等情况下，编码后的字节数组越大，存储占空间，存储硬件成本高，网络传输时也占带宽，导致系统的吞吐量降低。

1. 开发工作量和难度。工作量越少越好对吧，发挥的价值最大。
2. 性能：需要考虑性能需求，序列化的速度和性能越高越好。
3. 是否支持跨语言，支持的语言种类是否丰富。
4. 安全性：对于安全性的需要考量。JDK序列化可能有卡死线程的漏洞。
5. 占用空间大小：序列化的结果所占用的空间大小，序列化后的字节数据通常会持久化到硬盘（占用存储资源）或者在网络上传输给其他服务器（占用带宽资源），这个指标当然是越小越好。
6. 可维护性：技术流行程序，越流行的技术可维护性就越高，维护成本会越低。

3.为什么采用字节序列MessagePack，有什么依据？

这个要结合当时的项目背景了。当时的项目痛点是：

1. 老项目的结构调整比较大，交易性能上不去，所以先采取细节方面的优化。MessagePack是满足性能要求。
2. 老系统业务变化不多，MessagePack是满足要求。
3. 序列化反序列化效率高（比json快一倍），文件体积小，比json小一倍。MessagePack是满足要求

所以，存在MessagePack也有不好的地方，如果是针对业务变化比较多，那就不适合，需要比较不同的版本，然后选择不同版本去解析。

我在京东內部文章有看到，引用的MessagePack反序列化出现了一些线上的问题，原因是：新增了一些字段导致反序列化失败。

这里对比了JDK(不支持跨语言)，JSON，Protobuf，MessagePack几种序列化的方式。

当然，还有其他的XML、Hessian、Kryo（不支持跨语言）、FST（不支持跨语言）Thrift等。

4.JDK序列化

JDK序列化是Java默认自带的序列化方式。在Java中，一个对象要想实现序列化，实现接口或者接口即可。其中接口继承自接口。

版本控制的作用

1. 序列化的时候也会被写入二进制序列
2. 反序列化时会检查是否和当前类的一致。不一致则会抛出 异常（序列化之后给类增加字段再反序列化的时候就会报错）

serialVersionUID必须保证实体类在序列化前后严格一致，否则将会导致无法反序列化。

JDK默认的序列化机制。需要实现java.io.Serializable接口

1. 序列化后的码流太大：jdk序列化机制编码后的二进制数组大小竟然是二进制编码的5.29倍。
2. 不支持跨语言平台调用， 性能较差（序列化后字节数组体积大）
3. 序列化性能太低：java序列化的性能只有二进制编码的6.17%左右，Java原生序列化的性能实在太差。

JDK默认的序列化机制很差。所以我们通常不会选择Java默认序列化这种

5.JSON序列化

json格式也是常见的一种，但是在json在解析的时候非常耗时，而且json结构非常占内存。JSON不适合存数字，特别是DOUBLE

这里基于Fastjson ，加载maven依赖

序列化对象

利用JSON.toJSONString方法序列化对象：

序列化数组

利用JSON.toJSONString方法序列化数组：

序列化集合

利用JSON.toJSONString方法序列化集合（继承至Collection，比如List、Set等集合）：

序列化映射

利用JSON.toJSONString方法序列化映射：

其中，为了保证每次序列化的映射字符串一致，需要指定序列化参数MapSortField进行排序。

序列化模板对象

利用JSON.toJSONString方法序列化模板对象：

代码

序列化ObjectTest

反序列化UN_ObjectTest

json序列化总结

• 好处

  1. 简单易用开发成本低
  2. 跨语言
  3. 轻量级数据交换
  4. 非冗长性（对比xml标签简单括号闭环）

• 缺点

  1. 体积大，影响高并发
  2. 无版本检查，自己做兼容
  3. 片段的创建和验证过程比一般的XML复杂
  4. 缺乏命名空间导致信息混合

6.Protobuf

Protobuf是谷歌推出的，是一种语言无关、平台无关、可扩展的序列化结构数据的方法，它可用于通信协议、数据存储等。序列化后体积小，一般用于对传输性能有较高要求的系统。前期需要额外配置环境变量，学习他的语法也是需要时间。

但是要使用Protobuf会相对来说麻烦一些，因为他有自己的语法，有自己的编译器，如果需要用到的话必须要去投入成本在这个技术的学习中。

Protobuf有个缺点就是传输的每一个类的结构都要生成相对应的proto文件，如果某个类发生修改，还要重新生成该类对应的proto文件。另外，Protobuf对象冗余，字段很多，生成的类较大，占用空间。维护成本较高。

7.MessagePack（推荐）

1. 序列化反序列化效率高（比json快一倍），文件体积小，比json小一倍。
2. 兼容json数据格式
3. 跨语言，多语言支持(超多)

不好的地方：

1. 缺乏复杂模型支持。msgpack对复杂的数据类型（List、Map）支持的不够，序列化没有问题，但是反序列化回来就很麻烦，尤其是对于java开发人员。
2. 维护成本较高。msgpack通过value的顺序来定位属性的，需要在不同的语言中都要维护同样的模型以及模型中属性的顺序。
3. 不支持模型嵌套。msgpack无法支持在模型中包含和嵌套其他自定义的模型（如weibo模型中包含comment的列表）。

上手

通过配置msgpack的maven依赖

封装MsgPackTemplate抽象类，对原有msgpack进行二次加工，比如int，Short，Byte，BigDecimal进行read和write处理

MsgPackTemplate.java

然后针对实体类进行读和写的序列化与反序列化操作。

User.java

UserTemplate.java

参考文献：

• 官网：MessagePack: It’s like JSON. but fast and small：https://msgpack.org/)
• msgpack-java：https://github.com/msgpack/msgpack-java
• MessagePack for C＃译文：快速序列化组件MessagePack介绍 – 晓晨Master – 博客园：https://www.cnblogs.com/stulzq/p/8039933.html
• 原理分析和使用：https://www.sigusoft.com/p/8c24bef40e2f

1. https://blog.csdn.net/wzngzaixiaomantou/article/details/
2. https://blog.csdn.net/weixin_/article/details/
3. https://www.cnblogs.com/juno3550/p/15431623.html
4. Protobuf：https://blog.csdn.net/wxw1997a/article/details/

作者：京东零售 邵桐杰

来源：京东云开发者社区

本文整理自云原生 Meetup 杭州站上，极狐(GitLab) DevOps 技术布道师马景贺的演讲。

当听到云原生的时候，你会想起什么？

可能很多人很自然地就会想到 Kubernetes、容器、微服务、开源等等，这些关键词是我们接触云原生绕不开的话题。但是以上还少了一个关键词：安全。

云原生从 2013 年出现，2015 年发展起来以后，安全也逐渐被关注和重视。

以云原生中常用的镜像安全为例，下图是通过拉取常用镜像，用 Trivy 进行扫描的结果，不同颜色对应不同等级的漏洞。例如 node.js 这个开源项目，高危漏洞有 544 个，中危级漏洞有 921 个；还有 Jenkins，漏洞数量也不少。

可以看到，容器镜像安全问题比较严重，关于容器镜像安全的更多分析报告，感兴趣的朋友可以参阅 Anchore 发布的 2021 年、2022 年软件供应链安全报告。

一个完整的软件开发生命周期包括源代码开发、构建、测试、部署等环节，每一个步骤都可能存在潜在安全风险。我们应该把安全嵌入到每一个环节中去，也就是将 DevSecOps 应用到云原生应用程序开发的每一个环节中去，再加上 K8s 容器镜像安全扫描，才能打造一个完整的云原生安全生态。

DevSecOps 是什么？如何帮助我们打造云原生安全生态？

DevSecOps 是一个兼具深度和广度的纵深安全防御系统，从 Source code、 Build 、Test 到 Deploy，任何一个阶段，都有对应的安全手段。其次，DevSecOps 是流程、工具、文化的深度结合，传统的研发团队里，开发人员只负责代码的开发，不会关注后续的运维等流程，但在 DevSecOps 标准要求下，安全是团队中每个人的责任，需要贯穿从开发到运维全生命周期的每一个环节。

DevSecOps 强调的安全测试左移，其实就是更早地让研发加入进来。我们软件研发过程中的大部分安全问题，都是在开发阶段引入的，因此，如果从 Source code 阶段就尽早将安全考虑在内，从源头处提升安全能力，就能更有效、更低成本地发现和解决安全问题。

安全持续自动化也是很重要的一个部分，因为一个完整的安全流程，涉及到很多安全工具，如果每个工具都手动配置，手动触发安全测试，那么工作量就会大大提升。所以 DevSecOps 期望的是安全持续自动化，开发写完代码提交变更以后（MR 或者 PR），就可以进行自动扫描，产出报告并建议你如何修复。

当然了现在也进入 ChatGPT 时代，我前段时间做了一个 Demo，ChatGPT 在 Code Review 阶段就告诉你哪些是有安全风险的，甚至还会给出推荐的修复代码，感兴趣的朋友也可以去尝试一下

Gartner 每年会针对新技术会发布一个技术成熟度曲线，上图是 2022 年的数据，DevSecOps 就在最右侧，代表着它已经很成熟了，这也是为什么从 2019 年开始，很多企业都在开始讨论 DevSecOps。

下图是我根据行业数据绘制的示意图，可以看出 DevSecOps 一词是在 2012 年由 Gartner 提出，引起强烈关注，到达高峰期；2016 年慢慢往下走，2018 年前后到达泡沫破灭期；终于在 2022 年到达成熟期。

从 2012 年提出概念，到今年已经有 11 年了，DevSecOps 经历了一个完整的技术成熟度曲线，现在已经到了落地生根的阶段，这也是为什么，现在我们可以分享 DevSecOps 的落地实践，而非停留在概念。

如何寻找云原生 DevSecOps 落地切入点？

安全是一个比较大的概念，当我们提到安全，可能包括主机安全、网络安全、应用安全……本文侧重于应用程序安全领域。

下图虽然只是一个 Yaml 文件，但是已经包含了我们应该如何实践 DevSecOps 的重要信息。

镜像是重点，因为云原生时代都是镜像交付。虽然它是一个简单的二进制文件，但包含了很多东西，比如 OS、代码等，大部分的安全问题由此而生，此外 Yaml 文件本身也可能存在安全问题，比如上图下方红框展示的内容，即把敏感信息写到了 Yaml 文件中。

我们来进行一个拆分：

应用程序部署整体可以拆分成 3 层：

1. 底座是 K8s 集群

2. 中间是容器镜像

3. 顶层是应用程序

我们落地 DevSecOps 时，也是按照这 3 层来打造安全防护体系。

第一层：K8s 安全

首先第一层，基于 K8s 的安全防护手段，可能很多人都知道，比如 RBAC（权限管理）、Network Policy（网络策略）、Audit（审计日志）等。

第二层：容器镜像安全

第二层容器镜像，当我们编写 Dockerfile 时，有一些最佳实践可以遵循，例如如何选择基础镜像。

不同的基础镜像，安全漏洞数量不一样，攻击面大小也不一样。正如前文展示的几个容器镜像的漏洞数量，都是不一样。如果我们选择合适的基础镜像，那么就能减少攻击面。具体的就不展开了，大家可以去搜一下 Dockerfile best practice，网上有很多介绍。

另外就是镜像扫描，这也是非常重要的一环。

现在做镜像扫描的开源工具有不少，比如 Trivy、Clair、Anchore 等。使用这些工具可以帮助扫描我们采用的基础镜像是否安全，发现漏洞，然后进行修复，最后把这个镜像作为单一可信源的镜像，团队内部后续使用此镜像来制作其他镜像，那么安全性就能提高很多。

另外这两年在讲软件供应链安全，有一条就是通过数字签名来提高制品的可信性，比如 OpenSSF 基金会（开源安全基金会）下的 cosign 项目就可以对镜像进行签名，但为什么需要签名呢？

当构建镜像时，使用 1.0.0 tag 来构建，但是我们可以在再次修改代码之后，重新用 1.0.0 这个 tag 来构建镜像，并 push 到制品仓库。如果部署时仍旧拿 1.0.0 进行部署，那么内容其实已经被篡改，这也就是镜像的不可信，是镜像安全的另外一个维度。

如果对镜像进行签名，就能很好的避免这个问题。当镜像构建之后就对其进行签名，在部署时再进行验证，如果验证不通过，那么说明这个镜像被篡改了，就不应该再进行后续的部署。

以上就是关于容器镜像安全的几个方法。接下来我们看下最上层的应用程序安全。

第三层：应用程序安全

大部分公司，都有专门的运维人员或者安全人员帮我们加强 K8s 和容器镜像安全防护，而最上层最靠近业务，也是开发人员关注更多的一层。

这一层有非常多的安全防护手段，例如 Secret Detection、Dependency scanning、SAST、DAST 等，上图只列举了一部分。

以 Secret Detection 为例，根据我的经验，70% 以上的安全问题都来自于敏感信息泄漏。当我们在本地 Debug 时，很容易把 Password 写死，但测试提交代码时，可能忘了删除，直接把 Password Push 到代码仓库，就造成了泄漏，所以 Secret Detection 在应用程序安全这部分的作用非常重要。

云原生 DevSecOps 是一个深度 + 广度的纵深防御体系，从 K8s、Docker 到应用程序安全，每一层展开都有非常多的安全手段。总结来说，有以下落地原则：

• 分层实施，循序渐进

• 由简入繁，化繁为简

• 重视数据，简化工具

• 安全左移，研发闭环

• 持续优化，持续安全

针对以上云原生开发安全防护体系，极狐 GitLab 提供开箱即用的 DevSecOps 功能，包括七大功能：容器镜像扫描、静态应用安全测试 (SAST)、动态应用安全扫描（DAST）、密钥检测、License 合规、依赖项扫描以及模糊测试。

这么多安全功能，如何去实现落地？

一言以蔽之，就是将这些安全功能集成到 CI/CD（持续集成/持续部署）中去，达到持续测试和持续安全的效果。极狐 GitLab 把所有安全功能和 CI/CD 集成到 Workflow 中，这个 Workflow 和研发工作流融合到一块，非常完整。

而且，只需要几行代码，就可以完成对应手段的安全扫描，简单易用。

下图就是每个安全功能对应的 CI/CD Pipeline 代码。在这个过程中，开发不需要知道每个安全功能应用的工具是什么，不需要学习工具如何配置，只需要输入这几行代码，就能进行扫描，非常容易上手。

图中不同安全手段标注不同颜色，是一个简单建议，也就是蓝色的几种安全手段是非常容易实践而且收效不错的，如果要全部落地实践，可以采取这种循序渐进的方式，先落地蓝色部分，再落地绿色部分。

极狐GitLab x KubeSphere 云原生安全体系如何构建？

接下来，我们来聊聊如何把 KubeSphere 和极狐GitLab 进行结合，利用 CI/CD，把安全防护手段集成到软件开发生命周期中。

极狐GitLab 介绍

极狐GitLab 是一个一体化的 DevOps 平台，其提供的一体化 DevOps 能力覆盖软件开发全生命周期（从计划到运维），同时内置安全功能，能够利用开箱即用的安全能力构建 DevSecOps 体系。

KubeSphere 介绍

Kubernetes 是一个非常复杂的容器编排平台，学习成本非常高，KubeSphere 所做的事情就是高度产品化和抽象了底层 Kubernetes，是一个面向云原生的操作系统，解决了 K8s 使用门槛高和云原生生态工具庞杂的痛点。

在 KubeSphere 上使用极狐GitLab 搭建 DevOps 有什么优势？

最典型的优点就是可以实现极狐GitLab & Runner 的云原生运行并实现灵活调度。

可以看下图这个实例，当研发人员提交代码变更之后，就会触发 CI/CD Pipeline，而极狐GitLab CI 如果检测到有 Job 需要运行，就会给 Runner 一个信号，触发背后的调度机制，Executors 帮助完成所有的 Step，例如对 Go 源码进行 Check out、Build、Test。

如何在 KubeSphere 上安装极狐GitLab ？

极狐GitLab 和 KubeSphere 的集成主要有两个方式：

➤ 方式一

直接把极狐GitLab Runner 作为单组件，安装在 KubeSphere 上，当我们的应用程序代码提交之后，开始跑 CI 时，就会自动在 KubeSphere 上完成所有构建操作，并直接反馈数据。

安装步骤如下：

1. 在 KubeSphere 的 App Management 下，通过 App Repositories 添加一个 App Repo； Add 按钮，在出现的界面中输入 Repo name 和 URL（极狐GitLab Runner 的 Helm Chart 地址为 https://charts.gitlab.io）。

2. 在 Create App 中选择“From App Template”：

3. 选择 gitlab runner：

4. 修改 Yaml 文件内容，输入极狐GitLab 实例地址 Runner Token 等， Install 即可。

5. 安装成功以后，就可以在 KubeSphere 上看到 jh-runner namespace 下面有 Pod 在正常运行。

➤ 方式二

把整个极狐GitLab 源代码托管平台安装到 KubeSphere 上面去，目前在 KubeSphere 上部署极狐GitLab 非常便利，只需要利用 KubeSphere 应用商店搜索极狐GitLab 即可一键部署。安装好以后，团队就可以直接在 KubeSphere 上面使用极狐GitLab 进行协作了。

详细安装教程：

https://gitlab.cn/blog/2022/04/01/jihu-kubesphere/?jh=gu0%20%E4%BD%9C%E8%80%85%EF%BC%9ABender%E5%BC%80%E6%BA%90%E4%B8%8D%20https://www.bilibili.com/read/cv/%20%E5%87%BA%E5%A4%84%EF%BC%9Abilibili

以上介绍了如何在 KubeSphere 上安装极狐GitLab/Runner，接下来我们通过一个 Demo 介绍如何在 KubeSphere 上进行 DevSecOps 检测。

极狐GitLab x KubeSphere 安全扫描 Demo

安装完以后，通过 Project → Settings → CI/CD 这个路径找到 Runner 页面，左边是项目专用 Runner，也就是只有这个项目可以用，其他项目用不了；右边共享 Runner 则是可以被此实例下的其他项目所使用的 Runner。

接下来详细演示一下扫描过程：

• 先创建一个 Issue，这是 Workflow 的第一步，然后将这个需求 Issue 指派给自己；接着开始进行本地的代码编写，这里模拟一个场景，把 Token 这个敏感信息写进去，看看安全扫描过程是否能发现。

• 接下来我们创建一个 MR，把这段有问题的代码提交上去，提交时可以选定指派人或审核人，让其他人来帮忙审核代码。

• 创建 MR 以后，就会进行自动扫描，这时候就扫描出来了我们故意放进去的 Token，从而发现这个潜在安全问题。

• 最后，修复后重新提交，再次扫描没有问题就可以合入了。

以上就是一个简单的 Demo，来使用极狐GitLab 的安全扫描功能。

总结

本文给大家介绍了极狐GitLab 和 KubeSphere 各自的优势，并探讨了如何结合 KubeSphere 和极狐GitLab 来构建一个云原生应用安全体系，最后通过一个示例来展示极狐GiLab DevSecOps 功能的工作原理，希望对大家有帮助～

本文由博客一文多发平台 OpenWrite 发布！

各位社区小伙伴们，Databend 于 2023 年 6 月 29 日迎来了 v1.2.0 版本的正式发布！相较于 v1.1.0 版本，开发者们一共新增了 600 次 commit，涉及 3083 个文件变更，约 17 万 行代码修改。感谢各位社区伙伴的参与，以及每一个让 Databend 变得更好的你！

在 v1.2.0 版本中，Databend 新增了 BITMAP 数据类型 、 使用列号直接查询 CSV/TSV/NDJSON 文件 、AI Functions 等特性，设计并实现全新哈希表 大幅提升 Join 的性能。这个版本的发布使得 Databend 更接近实现 LakeHouse 的愿景，能够直接读取和分析储存在对象存储上的 CSV/TSV/NDJSON/Parquet 等格式文件，你也可以在 Databend 内部对这些文件进行 ETL 操作，从而做一些更高性能的 OLAP 分析。

同时，Databend 也设计并实现了 计算列 、VACUUM TABLE 和 Serverless Background Service 等企业级特性，感兴趣的小伙伴可以联系 Databend 团队 了解升级信息，或者访问 Databend Cloud 即时体验。

Databend x 内核

Databend 重要新特性速览，遇到更贴近你心意的 Databend 。

数据类型：

Databend 新增对 数据类型的支持并实现了一系列相关函数。

是一种压缩数据结构，可以高效地存储和操作布尔值集合。它提供了快速的集合运算和聚合能力，在数据分析和查询方面应用广泛。常见的使用场景包括：去重计数、过滤选择和压缩存储。 Databend 中的 数据类型实现采用 。与其他位图实现相比，使用这种数据结构可以提高性能并减少内存使用。

如果你想要了解更多信息，请查看下面列出的资源。

• Docs | Data Types – BITMAP
• Docs | SQL Functions – Bitmap Functions
• Paper | Consistently faster and smaller compressed bitmaps with Roaring

使用列号直接查询 CSV/TSV/NDJSON 文件

要想查询 CSV/TSV/NDJSON 这类没有 schema 的文件，以前需要将其加载到表中再进行查询。但是有时候用户事先并不了解文件的具体情况（例如 CSV 文件有多少列），或者只是想做临时的查询。

为此，Databend 引入了列号（column position）, 使用 语法来表示第 列。CSV/TSV 文件所有列都视作 类型，如果某行的列数少于使用到的列号，则会用空字符串进行补齐。NDJSON 文件只有一列 ， 类型是 。

将这一能力与 COPY 语句结合使用，可以实现按需加载部分列，并在加载同时使用函数进行数据转换。

如果你想要了解更多信息，请查看下面列出的资源。

• Docs | SELECT – Column Position

设计并实现全新哈希表以提高 Hash Join 性能

在过去，Databend 的哈希表是为了满足聚合算子的需求而专门设计的，为了进一步提高 Hash Join 的性能，我们着手设计并实现了一种专为 Hash Join 优化的全新哈希表，通过并行化的设计，使 Databend 能够充分利用计算资源，同时在内存控制方面也变得更为精准，避免了不必要的内存开销，显著提高了 Hash Join 的性能。

商业智能分析师 Mimoune Djouallah 评论称：Databend 性能出色，在 8 核和 32GB 内存的条件下，运行 TPCH-SF10 只需要 25 秒。他甚至撰写了一篇题为《Databend and the rise of Data warehouse as a code》的博客文章。

如果你想要了解更多信息，请查看下面列出的资源。

• Data Infra #12 | Databend’s New Hash Table for Hash Join
• PR #11140 | feat(query): new hash table and parallel finalize for hash join

AI Functions

Databend 在 v1.2.0 版本引入了强大的 AI 功能，实现了 Data 与 AI 的无缝融合，我们可以通过 SQL 来实现：

1. 自然语言生成 SQL
2. Embedding 向量化并存储
3. 相似度计算
4. 文本生成

自然语言生成 SQL

比如，如果你在一个 nginx log 的数据库中提问：”What are the top 5 IP addresses making the most requests”，运用 Databend 的 函数，你将直接得到相应的 SQL 语句，使用非常便捷。

Embedding 向量化

借助 Databend 的 函数，我们可以实现数据的向量化，并将其保存在 Databend 的 类型中。这样一来，Databend 事实上变成了一个向量数据库。

相似度计算

在向量化表示下，可以计算两个词语、句子或文档的相似度。 例如，假设我们有 “dog” 和 “puppy” 两个词语（也可以是句子），我们首先将它们各自转化为向量 v1 和 v2，然后使用余弦相似度来计算它们的相似度。

Databend 中的 函数就是对这个公式的实现。

文本生成

文本生成在很多场景下非常有用，现在你可以在 SQL 中使用 函数来完成。

目前，我们已经利用以上 Data + AI 能力，对 https://databend.rs 的所有文档进行了 Embedding 处理，并将其存储到 Databend 中，构建了一个智能问答网站：https://ask.databend.rs 。 在这个网站上，你可以提问关于 Databend 的任何问题。

Databend 企业级特性

全新企业级特性上线啦！了解 Databend 如何推动更具价值的数据分析服务。

计算列

计算列（Computed Columns）是一种通过表达式从其他列计算生成数据的列，使用计算列可以将表达式的数据存储下来加快查询速度，同时可以简化一些复杂的查询的表达式。计算列包括存储（STORED）和虚拟（VIRTUAL）两种类型。

• 存储计算列在每次插入或更新时生成数据并存储在磁盘，在查询时不需要重复计算，可以更快的读取数据。
• 虚拟计算列不存储数据，不占用额外的空间，在每次查询时实时进行计算。

计算列对读取 JSON 内部字段的数据特别有用，通过将常用的内部字段定义为计算列可以大大减少每次查询过程中提取 JSON 数据的耗时操作。例如：

如果你想要了解更多信息，请查看下面列出的资源。

• Docs | CREATE TABLE – COMPUTED COLUMNS

VACUUM TABLE

命令通过从表中永久删除历史数据文件来释放存储空间，有助于优化系统性能。删除的文件包括：

• 与表相关的快照及其关联的 segments 和 blocks 。
• 孤立文件。在 Databend 中，孤立文件指不再与该表关联的快照、segments 和 blocks 。孤立文件可能由各种操作和错误生成，例如在数据备份和还原期间，并且随着时间的推移会占用宝贵的磁盘空间并降低系统性能。

如果你想要了解更多信息，请查看下面列出的资源。

• Docs | VACUUM TABLE

Serverless Background Service

Databend 的内置存储引擎 是一种与 Apache Iceberg 类似的日志结构表，在数据持续写入的过程中，需要定期执行表压缩、重聚类和清理以合并小数据块。小数据块合并的过程会涉及按聚类键排序数据或清理不需要的分支等阶段。

为了自动化执行这一过程需要使用不同的驱动，增加了基础设施的复杂性。而且必须部署和维护其他服务来触发驱动事件。为简化这一过程，Databend 设计并实现了 Serverless Background Service ，能自动发现数据写入之后需要压缩、重排序、清理的表，无需其他服务，也无需用户手动操作，自动触发对应表的维护工作，降低了用户维护的负担，提升了表查询的性能，也降低了数据在对象存储中的成本。

Databend x 生态

Databend 的生态版图得到了进一步的完善。是时候将 Databend 引入你的数据洞见工作流啦！

databend 的 Python 绑定

Databend 现在提供 Python 绑定，为在 Python 中执行 SQL 查询提供了新选择。该绑定内置 Databend ，无需部署实例即可使用。

从 databend 导入 并创建会话上下文即可开始使用：

结果 DataFrame 可以使用 或 转换为 PyArrow 或者 Pandas 格式：

现在行动起来，将 Databend 集成到你的数据科学工作流中。

• databend · PyPI

BendSQL – Databend 原生命令行工具

BendSQL 是一款专为 Databend 设计的原生命令行工具，现在已经用 Rust 语言重写，并且同时支持 REST API 和 Flight SQL 协议。

使用 BendSQL ，你可以轻松高效地管理 Databend 中的数据库、表和数据，并轻松执行各种查询和运算。

我们期待与你分享更多关于 BendSQL 的更新！欢迎试用并给我们反馈。

• Docs | SQL Clients – BendSQL
• Crates.io – bendsql
• Github – datafuselabs/databend-client | Rust

数据集成和 BI 服务

Apache DolphinScheduler

Apache DolphinScheduler 是一个分布式和可扩展的开源工作流协调平台，具有强大的DAG可视化界面。支持 30+ 的任务类型，包括像 Flink SQL、DataX、HiveCli 等。能够高并发、高吞吐量、低延迟和稳定地执行百万个量级任务，可以根据计划时间（特殊日期范围或特殊的日期列表）批量执行任务，而且在不影响工作流模板的情况下，工作流实例支持修改、回滚和重新运行。

DolphinScheduler 现已支持 Databend 数据源，可以使用 DolphinScheduler 管理 DataX 任务实现从 MySQL 到 Databend 异构数据库数据同步。

Apache Flink CDC

Apache Flink CDC（Change Data Capture）是指 Apache Flink 使用基于 SQL 的查询从各种来源捕获和处理实时数据更改的能力。CDC 允许监视和捕获数据库或流系统中发生的数据修改（插入、更新和删除），并对这些更改进行实时响应。

Databend 现在提供 Flink SQL Connector，可以将 Flink 的流处理能力与 Databend 集成。通过对连接器进行配置，可以以流的形式从各种数据库中捕获数据更改，并将其载入到 Databend 中以进行实时处理和分析。

如果你想要了解更多信息，请查看下面列出的资源。

• Docs | Loading Data with Tools – Flink CDC

Tableau

Tableau 是一款流行的数据可视化和业务智能工具。它提供了直观、交互式的方式来探索、分析和呈现数据，帮助用户更好地理解数据的意义和洞察。

参考 Other Databases (JDBC)，将 databend-jdbc 放置在 Tableau 驱动路径下，就可以使用 Tableau 分析 Databend 中的数据。

如果你想要了解更多信息，请查看下面列出的资源。

• Blog | Databend x Tableau

下载使用

如果你对我们新版本功能感兴趣，欢迎访问 https://github.com/datafuselabs/databend/releases/tag/v1.2.0-nightly 页面查看全部的 changelog 或者下载 release 体验。

如果你还在使用旧版本的 Databend，我们推荐升级到最新版本，升级过程请参考：

https://databend.rs/doc/operations/upgrade

意见反馈

如果您遇到任何使用上的问题，欢迎随时通过 GitHub issue 或社区用户群中提建议

GitHub: https://github.com/datafuselabs/databend/

摘要：本文主要介绍如何进行用户的各种依赖识别与清理，并简单介绍下推荐的权限管理方式。

本文分享自华为云社区《GaussDB(DWS) 用户删除不掉时候总是报错，依赖如何处理干净？》，作者：Malick 。

数据库的使用中，有时会遇到某些用户离职，或者角色变更时，要对其账号进行销户，权限进行回收等操作。此时如果各种对象的权限比较复杂，依赖较多，是很难顺利直接清理掉该用户的。

本文主要介绍如何进行用户的各种依赖识别与清理，并简单介绍下推荐的权限管理方式。

postgres类数据库经常碰到的问题 – role “test1” cannot be dropped because some objects depend on it

如下图所示，要删除用户test1时，出现如下提示：

ERROR的提示信息说明：

• 当前用户时testdb这个数据库的owner
• 有3个依赖的对象在postgres数据库中

OK，那么我们就按照提示信息来一次处理

首先，当前用户是一个数据库的owner，那么有以下两种处理办法

方法一、将数据库owner转移给其他用户，例如如下转移给grantor用户

方法二、如果不需要该库，也可以直接将其删除

PS：对于非数据库的对象：表或者schema等，可以使用如下方法将其全部转移给其他用户

接下来，我们owner的提示信息已经处理完了，处理下一步提示：3 objects in database postgres

这个意思是，在postgres里面有3个对象有依赖该用户。由于库内系统表的依赖，在其他数据库中不会打印出详细的依赖对象信息，那么在postgres库下去执行drop user的时候，会打印出具体的信息。

连接到postgres库执行如下：

这里就可以看到，有两个依赖项：

• privileges for table pg_class：pg_class上test1用户的权限
• schema grator上test1用户的权限

那么，我们就可以直接看一下这两个对象对应的权限，去除即可。

此时再进行用户删除，就没有其他依赖了。

PS:如果不知道具体对象还删不掉的时候，我们怎么操作呢，此处构造一个案例作为演示，新建用户test2，并赋予其grantor的select权限，此时无法drop

用户的依赖内部实际储存，为pg_shdepend系统表，里面记录了各个有依赖的对象的oid及其依赖关系。首先我们获取到用户的oid，再去系统表中找对应的依赖记录。

我们获取到classid之后，这个代表依赖当前用户的对象的记录表的id，那么我们去pg_class表中找到这个依赖即可：

OK，通过看到记录表是pg_namespace，那么就可以确认依赖用户的是一个schema。这里再到pg_namespace中，查上面获取到的objid，就知道了具体的对象

这里看到有两个schema，一个是用户同名的schema，一个是刚才赋权的grantor，赋权的处理掉之后，用户即可删除。

关注，第一时间了解华为云新鲜技术~

CXYGZL 介绍

现在开源的工作流引擎，基本都是以 BPMN.js 为基础的，导致使用门槛过高，非专业人员无法驾驭。本工作流借鉴钉钉 / 飞书的方式，以低代码方式降低用户使用门槛，即使是普通企业用户也可以几分钟内就能搭建自己的工作流引擎。

体验地址：https://pro.cxygzl.com CXYGZL

文档地址：https://www.cxygzl.com CXYGZL

V2.0.2 版本介绍

✨紧急修复了一些bug和添加了一些新功能，详细如下：

1. 🏆 I7GLCU：添加表单组件-明细表
2. 🏆 I7GECI：添加文本描述表单组件
3. 🏆 I7GCIT：审批人支持角色
4. 🏆 I7G8IF：添加并行分支
5. 🏆 I7G8I2：添加表单组件：日期时间组件支持
6. 🏆 I7G7Q4：流程组列表显示发起人范围
7. 🏆 I7G7NU：表单组件库分组显示，流程基础信息的说明改成非必填
8. 🏆 I7G78S：默认流程发起人是当前登录用户
9. 🏆 I7G77S：只有发起人节点禁止保存流程
10. 🏆 I7G77P：没有表单禁止发布流程
11. 🎯 I7GUXL：表单拖拽组件之后会影响到原始表单
12. 🎯 I7GG40：审批人执行人为空 渲染节点显示报空指针
13. 🎯 I7GEBQ：日期显示不全
14. 🎯 I7GBIF：不可用部门和人员，在表单选择时还可以选到
15. 🎯 I7G8JN：用户被禁用了，仍然可以登录
16. 🎯 I7G8J1：人员组件表单，未选择可选自己，仍然能选择自己
17. 🎯 I7G7QY：上传图片组件限制文件格式为图片
18. 🎯 I7G5EQ：流程设计-发起人设置：设置审批人错误，应该是设置发起人

📢注意事项

1. 有新的sql脚本，请先在业务库执行:
2. 已经存在的流程不支持并行分支，请新建流程再创建并行分支（流程节点添加了字段）

关注公众号

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

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

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

发布摘要

• 启动工程增加对流的发布订阅的单测试和基准测试

• 修复发布和订阅并发创建流产生的panic

• 修复IdleTimeout无效问题

• 修复订阅者阻塞导致读写并发问题

• 插件修复https默认端口

• 插件PR合并

   

  升级模块 升级后版本
  e
  ngin
  e
  4.13.
  5 gb28181 4.3.6 hls 4.3.1 preview 4.1.2 record 4.3.7

详细说明

单测试和基准测试

测试用例所在目录：github.com/langhuihui/monibuca工程下的test目录

推荐使用vscode打开工程，方便一键测试单个用例，也可以通过vscode侧边栏里的单测试栏目管理。

TestPubAndSub

该用例会启动一个发布者和一个订阅者，发布者将会写入假数据，订阅者读取后会校验数据是否正确。

BenchmarkPubAndSub

该用例为基准测试，启动10个发布者，每个流会批量订阅，以测试并发性能以及稳定性。

TestSlowSubscriber

这个用例会模拟一个订阅者被阻塞（sleep）后导致发布者写入的位置追上，此时engine通过标记这个写入点废弃来避免并发读写问题，废弃后订阅者如果被唤醒就会自动停止订阅。

通常出现这种情况是订阅者进行了某种耗时操作，比如写文件，或者网络阻塞等。

其他修复问题

并发创建流

修复如下：

原理：当并发调用函数时，前者尚未来得及对赋值，后者就调用了导致空指针错误。

修复读写并发问题

这个问题在前面的单测试中已经提到，就是订阅者阻塞引起的。

订阅者阻塞后，读取点移动很慢或者不移动，导致写入点追上

由于RingBuffer是由链表结构实现，因此很容易将节点剥离主环

废弃后，这个订阅者将无法再读取主环内容，也将遭到抛弃

抛弃

https默认端口