关注公众号

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

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

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

Linux Mint 团队确认了 21.1 版本会在圣诞节前发布，代号“Vera”。这延续了该发行版的传统，即同一系列中的每个版本取一个以相同字母开头的女性名称（例如 Linux Mint 21 是”Vanessa”）。

项目负责人 Clem 介绍了 Linux Mint 21.1 的部分变化：

改进驱动管理器

添加”Dummy Test Device”模式，可轻松地对各种不同的场景进行故障排除。

重新设计离线支持界面。如果处于离线状态，驱动程序管理器现在会显示一个专用界面：

如果它检测到 live USB 设备（或 DVD），则会出现不同的界面：

ISO 验证工具

该工具用于检查和校验文件的真实性和 ISO 的完整性。

隐藏部分桌面图标

在未来的版本中，以下桌面图标将默认隐藏：

Computer
Home
Trash
Network

原因是这些快捷方式在用户界面中重复出现，例如：通过面板、Mint 菜单中的链接，或 Nemo文件管理器。

详情查看公告。

关注公众号

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

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

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

DBeaver 22.2.2 现已发布。DBeaver 是免费的多平台数据库工具，适用于开发人员、数据库管理员、分析师和所有需要使用数据库的人，并且支持所有流行的数据库：MySQL、PostgreSQL、SQLite、Oracle、DB2、SQL Server、Sybase、MS Access、Teradata、Firebird、Apache Hive、Phoenix、Presto 等。

更新内容如下：

数据编辑器：
- 添加了“隐藏所有空列”操作
- References panel 现在有一个按钮来打开 target table
- 修复了按多列排序的问题
- 修复了按空间列过滤的问题
- URL transformer 已修复（现在支持原始值编辑）
- LOB 编辑器打开性能显着提升
- SQL 终端现在显示服务器输出日志
- 列注释现在在 record mode 下可见
- 修复了 record mode 的复杂数据类型可视化
数据传输：修复了自定义标题格式的 CSV export 中的错误
SQL 编辑器：
- 自定义查询中的 NULL 列名问题已修复
数据库驱动程序：
- 修复了重新下载驱动程序 jar 的问题
- 现在可以禁用 Windows 证书存储使用
Athena：驱动版本更新到 2.0.30
Clickhouse：添加了 datetime64 数据类型支持
DB2：驱动版本更新到 11.5.7
Exasol：用户列表读取已修复
Greenplum：准备好的语句使用被禁用
MySQL：
- 默认数据库客户端已更改为版本 8+
- JSON 列现在可以在过滤器和 keys 中使用
Oracle：添加了架构完整 DDL
PostgreSQL：
- 修复了新表中缺少主键的问题
- 已修复分区表的 Table DDL
- Role comments 现在可见/可编辑
改进了德语本地化

下载地址 | 发布说明

关注公众号

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

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

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

KDE 社区已发布了 Plasma 5.26 桌面环境。

这个版本进一步完善了桌面小部件，面板中的时钟和日历、通知器、KDE Connect 监视器、音量控制… 现在这些都属于小部件，可以在桌面的任何地方添加、移动、删除，并随时调整大小，甚至可以旋转、浮动放在桌面上的小部件。

这个版本还有一个新的计时器小部件，可以将其放到桌面上进行倒计时。除了提醒功能，Timer 还可以在倒计时结束时运行命令或操作。比如设置

Timer 倒计时结束时，就会自动关掉正在摸鱼的 Firefox 浏览器…

此外，Plasma 5.26 最明显的改进之一是引入适用于大屏幕的 Aura 浏览器，这个新的 Aura 浏览器适用于电视和其他大型显示器，可以用兼容的遥控器操控。看起来是这样的：

其他方面，KDE Plasma 的软件工具 Discover 可以设置新更新通知的频率、显示应用的内容评级，且有一个新的“分享”按钮，可以轻松分享 KDE Plasma 的软件。

最后，KDE Plasma 5.26 优化了对 Wayland 支持，Plasma Wayland 会话现在能够处理图形输入板配置、中键单击粘贴首选项，以及在 XWayland 上运行的精美缩放应用程序。

其他内容可以在 KDE 的官方更新公告中查看。

关注公众号

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

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

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

漏洞描述

Scala是Scala开源的一个 Scala 2 编译器和标准库。

Scala 2.13.9之前的2.13.x版本存在安全漏洞，反序列化方法会调用 tail.prependedAll(init) 来重构 lazy 列表，攻击者伪造序列化流可以使 prependedAll 调用 tail 对象的 lazyState 方法，可以包含 lazyState 字段的任何 Function0 实例，这可能会修改任意文件，建立网络连接，或者可能通过使用 Function0 方法的小工具链运行任意代码。

漏洞名称 scala-lang 反序列化漏洞利用链漏洞类型反序列化发现时间 2022-09-23 漏洞影响广度广 MPS编号 MPS-2022-52625 CVE编号 CVE-2022-36944 CNVD编号 –

影响范围

org.scala-lang:scala-library@[2.13.0, 2.13.9)

修复方案

将组件 org.scala-lang:scala-library 升级至 2.13.9 及以上版本

参考链接

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

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

Commit

情报订阅

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

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

具体订阅方式详见：

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

日前，字节跳动技术社区 ByteTech 举办的第七期字节跳动技术沙龙圆满落幕，本期沙龙以《字节高性能开源微服务框架：CloudWeGo》为主题。在沙龙中，字节跳动字节跳动基础架构服务框架资深研发工程师杨芮，跟大家分享了《高性能 RPC 框架 Kitex 内外统一的开源实践》，本文根据分享整理而成。>

本文将从以下四个方面介绍 CloudWeGo 高性能 RPC 框架 Kitex 的实践及开源：

由内至外 – 开源过渡；

开源一年变更回顾；

社区共建完善生态及企业落地；

总结和展望。

由内至外 – 开源过渡

很多同学可能刚刚了解 CloudWeGo，先介绍一下 CloudWeGo 和 Kitex 的关系。

CloudWeGo 和 Kitex

Kitex 是 CloudWeGo 开源的第一个微服务框架，它是一个支持多协议的 Golang RPC 框架，从网络库、序列化库到框架的实现基本完全自研的。特别地，Kitex 对 gRPC 协议的支持使用了 gRPC 官方的源码，但是我们对 gRPC 的实现做了深度且定制的优化，所以 Kitex 支持的 gRPC 协议性能优于 gRPC 官方框架。同时这也是 Kitex 与目前已经开源的、支持 gRPC 协议的其他 Golang 框架的主要差异。如果用户想使用 gRPC 又对性能有很高的要求，那么 Kitex 框架将会是一个很不错的选择。

继 Kitex 开源后，今年 CloudWeGo 又陆续开源了 Golang HTTP 框架 Hertz，Rust RPC 框架 Volo，同时围绕这些微服务框架和微服务的一些通用能力，我们还开源了一些高性能的基础库。关于更多 CloudWeGo 开源的子项目，可以进入 CloudWeGo 官网详细了解。

CloudWeGo 官网：https://www.cloudwego.io/

根据社区同学反馈，在一些开源群里大家会讨论 Kitex 会不会是一个字节跳动的开源 KPI 项目呢？它的稳定性、持续性能够得到保障吗？我可以负责任地讲，Kitex 不是一个 KPI 项目，它是来自字节跳动内部大规模实践的真实项目。在 Kitex 开源后始终保持内外统一，基于内外代码的统一我们保证了 Kitex 的持续迭代。为了进一步消除大家的顾虑，下面具体介绍一下 Kitex 的诞生和开源历程。

Kitex 发展历史

2014 年，字节跳动开始引入 Golang。2015 年，字节跳动内部的服务化开启。在 RPC 调用的场景选择了 Thrift 协议，在内部开始支持 RPC 框架。2016 年，第一个 Golang RPC 框架 Kite 正式发布。通常在一个公司高速发展的初期，基础能力都是为了快速支持需求落地，面对的需求场景也较单一，设计上不会有较多考量，其实这也是合理的，因为探索阶段并不完全清楚还需要支持哪些场景，过多的考虑反而会出现过度设计的问题。

但是，随着业务场景复杂化，需求也会多样化，而且接入服务及调用量逐年增长，Kite 已经不足以支持后续的迭代，在线上服役三年多后，2019 年我们开启了新的项目 Kitex，2020 年初发布了正式版本，在 2020 年底字节内部已经有 1w+ 服务接入 Kitex。

从 2014 年到 2020 年，Golang 已经是字节跳动内部主要的业务开发语言，应该是业界 Golang 应用最多的公司。我们的服务框架支持着数万个 Golang 微服务的可靠通信，经过数量众多的微服务和海量流量的验证，我们已经有了较为成熟的微服务最佳实践，于是考虑将内部的实践开源出去丰富云原生社区的 Golang 产品体系。在 2021年，我们以 CloudWeGo 品牌正式开源了第一个服务框架 Kitex。截至今年 8 月，Kitex 已经为字节跳动内部 6w+ 的服务提供支持，峰值 QPS 达到上亿级别。

大家或许还有疑问，完整的微服务体系离不开基础的云生态，无论在公有云、私有云，都需要搭建额外的服务以很好地支持微服务的治理，比如治理平台、注册中心、配置中心、监控、链路跟踪、服务网格等，而且还存在一些定制的规范。字节跳动自然也有完善的内部服务支持微服务体系，但这些服务短期还无法开源，那 CloudWeGo 如何内外维护一套代码，统一迭代呢？

关于这个问题，我们看一下 Kitex 的模块划分。Kitex 的模块分为三个部分：中间是 Kitex 主干部分 Kitex Core，它定义了框架的层次结构、接口核心逻辑的实现以及接口的默认实现；左边的 Kitex Tool 则是与生成代码相关的实现，我们的生成代码工具就是编译这个包得到的，其中包括 IDL 的解析、校验、代码生成、插件支持等。不过为了便于用户使用同时提供更友好的扩展，主要能力也做了拆分作为基础库独立开源，如 Thriftgo、Thrift-validator 插件、Fastpb；右边的 Kitex Byted 是对字节内部基础能力集成的扩展实现，我们在开始就将内部的能力作为扩展收敛到一个 package 下。

如此，我们就可以将 Kitex Core 和 Tool 部分开源出去。我们将代码做了拆分，Kitex 的核心代码和工具部分迁移到开源库，集成内部扩展的模块作为 Kitex 的扩展保留在内部库，同时内部库封装一层壳保证内部用户可以无感知地升级。

那么 Kitex 的开源就只是代码拆分这么简单吗？显然不是。2021 年 2 月，我们开始筹备 Kitex 的开源，虽然基于 Kitex 的扩展性，我们可以与内部基础设施集成的能力解耦，但是 Kitex 仍然依赖内部的一些基础库，如果要开源必须先开源基础库的能力。所以我们首先做了依赖库的梳理，与相关的同学合作首先开源了 bytedance/gopkg 库。这个库由 CloudWeGo 与字节跳动的语言团队合作维护，里面包含也了对 Golang 标准库能力的增强，感兴趣的同学可以关注使用。

bytedance/gopkg: https://github.com/bytedance/gopkg

在 gopkg 库开源后，我们调整代码进行开源适配。2021 年 7 月，Kitex 正式开源，在内部发布中版本使用开源库。但 Kitex 毕竟支持了内部几万的微服务，我们必须要确保内部服务在这个变更后可以平滑过渡，所以在开源初我们没有对外官宣，在确认稳定性后，2021 年 9 月，Kitex 正式对外官宣开源。

介绍了Kitex诞生、开源的历程，希望能够解除外部同学关于“Kitex 会不会是一个 KPI 项目？”的顾虑。

开源的价值

第一部分的最后，简单讲一下开源能为我们带来的价值。Kitex 不是为了开源而实现的，但它的实现是面向开源的。Kitex 本身是一个经过内部大规模实现的项目，我们希望 Kitex 开源后能帮助更多用户在内部快速搭建微服务，同时开源能让我们收集更多社区和企业的反馈，也能吸引外部开发者共建，促进 Kitex 面向多场景支持的演进，丰富产品能力，然后能在更多场景和企业得到落地，这是一个正向循环，互利共赢的过程。

开源一年变更回顾

框架的衡量指标

在介绍 Kitex 开源一年变更前，先分享一下框架的衡量指标，这是大家在选择一个框架时要考虑的。

扩展性

如果一个框架与内部能力强耦合，就无法移植到其他平台，或框架的支持场景单一也无法进行扩展，这样的框架很难得到外部的使用。

易用性

框架的易用性体现在两个方面。第一是面向业务开发者，如果一个框架在使用过程中需要让用户关注很多框架的细节，那么对研发效率要求很高的团队可能无法接受。第二是面向框架的二次开发者，他们需要对框架做一些定制支持，如果框架提供的扩展能力过于宽泛，扩展成本很高，或者可扩展的能力不够多，那么这个框架也是存在局限性的。

功能的丰富度

虽然基于扩展性可以对框架进行定制，但不是所有开发者都有足够的精力做定制开发，如果框架本身对各种扩展能力提供了不同选择的支持，对于开发者来说只需要根据自己的基础设施进行组合就能在自己的环境中运行。

高性能

前面三点是初期选择框架需要重点关注的指标，但随着服务规模和资源消耗变大，性能就成了不容忽视的问题。从长期的角度来说，选择框架的时候一定要关注性能，否则后续只能面临框架替换的问题，或者被迫对这个框架做定制维护。

关于以上四点框架的衡量指标，虽然 Kitex 目前还没做到最好，但是这四个要素都是 Kitex 设计和实现中一直在兼顾的，我们不会顾此失彼。

功能特性

下面就几个开源一年来重要的功能特性进行介绍。

Proxyless Proxyless

是 Kitex 面向开源场景提供的支持。在 Kitex 开源初期，我们内部讨论过是否要支持 xDS 对接 Istio，对于外部用户来说，使用 Istio 可以快速搭建一套基本的微服务架构，解决服务发现、流量路由、配置下发等问题，但是如果使用完整的 Istio 的解决方案，就要引入 Envoy，这会增加运维成本，而且直接使用官方的 Envoy 方案对性能有损，会引入额外的 CPU 开销且增加延迟。如果 Kitex 能直接对接 Istio，既能让用户享受到部分 Istio 的能力，又可以避免 Envoy 带来的性能损失和部署运维成本。但是在开源初期，我们没有看到很明确的用户诉求，因此没有对此做高优的支持。

后来 gRPC 官方也发布了 Proxyless 的支持，同时 Istio 的官方也将 Proxyless 作为使用 Istio 的一种方式。Kitex 现在也已完成支持，目前主要是对接服务发现，xDS 支持的扩展单独开源到了 kitex-contrib/xds 库中，后续还会完善。大家可以根据 README 了解如何使用 Kitex 对接 Istio。

xDS Support: https://github.com/kitex-contrib/xds

JSON 和 Protobuf 泛化调用支持

之前，Kitex 支持了应用在网关场景的 HTTP 泛化，以及支持了应用在一些通用服务场景的 Map 和二进制泛化。开源后，根据用户的需求反馈又新增了 JSON 和 Protobuf 的泛化。

Protobuf 的泛化也是应用在 API 网关的场景。原来的 HTTP 泛化传输的数据格式是 JSON，但是 JSON 的序列化体积大、效率低，对性能有影响，所以很多移动端的接口选择使用 Protobuf 传输数据，因此增加了 Protobuf 泛化的支持。

目前 Kitex 的泛化主要针对后端的 Thrift 服务，无论是 Protobuf、Map 还是 JSON，Kitex 都会在调用端结合 IDL 解析，将这些数据映射编码为 Thrift 包发给后端服务。

那么为什么把泛化放在调用端而不是服务端呢？大家广泛了解的泛化都是服务端对泛化请求做了解析处理，当然调用端也要相应地提供泛化的 Client。但是泛化面向的是通用服务，泛化使用成本其实是比较高的，它并不适用于普通的 RPC 场景，而通用服务面向的是所有后端的服务，有 Golang/Java/C++/Python/Rust，如果每一种语言框架都支持泛化，成本是非常高的。就算各个语言都对泛化做了支持，框架版本收敛又是一个漫长的过程，对于通用服务来说，对接所有的服务就显得不太现实。综合以上原因，泛化放在调用端支持。

重试能力增强

去年开源时，Kitex 已经支持了重试功能。之前支持的重试有两类，一个是超时重试，一个是 Backup Request。

对于超时来重试来说，我们只会对超时这一种异常进行重试，但为了进一步提高请求成功率，用户希望对其他的异常也进行重试，或者用户可能会定义一些用户请求的状态码，结合用户状态码进行重试，在这种情况下，显然我们只支持超时重试是不满足用户需求的。基于这个背景，Kitex 新增了指定结果重试，用户可以指定其他异常或指定某一类 Response，框架会结合用户指定的结果进行重试。

其次，用户在配置重试时，如果通过代码配置的方式设置重试，它会对整个 Client 的所有 RPC 方法生效，但是用户希望针对不同的 RPC 方法应用不同的重试策略，甚至同一个方法也希望可以采用不同的重试策略，因为不同链路上发起的同一个方法的请求对指标要求也会不同。比如有些想使用 Backup Request 减少延迟，有些想做异常重试提高成功率，对于这种情况，Kitex 新的版本支持了请求粒度配置重试。

下图是使用示例。以请求粒度重试配置为例，比如 RPC 方法是，那么我们在发起 RPC 调用的时候，在后面可以配置一个指定重试策略，此次请求就会使用这个重试策略。

Thrift Validator

Thrift-gen-validator 是 Thriftgo 的一个工具插件，它可以根据 Thrift IDL 中定义的注解描述约束给对应的生成方法，校验值的合法性。通常做 RPC 调用的时候，用户可能会对一些字段校验合法性，用户如果直接写这些校验代码，投入的成本会很高。所以我们就提供了注解支持，只要用户在 IDL 中根据规范定义注解，Kitex 就可以帮助用户生成校验代码。

下图是代码生成的命令和一个 IDL 注解定义示例，在生成代码的时候指定 Thrift Validator 的插件，我们的插件工具就会解析注解，为用户生成这一套合法性校验的代码。目前我们也将 Thrift Validator 的功能贡献给了 Apache Thrift。

性能优化

介绍完几个重要的功能特性，再介绍几个在性能上的优化特性。

Thrift 高性能编解码

Frugal 是一个无需生成编解码代码、基于 JIT 的高性能动态 Thrift 编解码器。虽然我们针对官方 Thrift 编解码已经做了优化，支持了 FastThrift，这个在我们开源前发布的优化实践里也有介绍，但我们希望能有进一步的性能提升，参考我们开源的高性能 JSON 库 Sonic 的设计，实现了 Thrift JIT 编解码器。下图中的表格是 Frugal 结合 Kitex 与 FastThrift 的性能对比。

可以看到在大部分场景 RPC 性能表现都较优。除了性能上的优势，Frugal 还有另一个优势是无需生成编解码生成代码。Thrift 的生成代码比 Protobuf 繁重，一个复杂的 IDL 代码生成文件可以达到几万行，而这些代码本来对用户来说无需关注，却需要由用户来维护。Frugal 只需要生成结构体代码，不需生成编解码代码，就大大解决了这个问题。

关于如何在 Kitex 中使用 Frugal，可以参考仓库的 Readme。当然用户也可以单独使用 Frugal 作为 Thrift 高性能编解码器，Kitex 后续也会考虑默认使用 Frugal。

Frugal: https://github.com/cloudwego/frugal#readme

Protobuf 高性能编解码

虽然我们内部主要支持 Thrift，但开源之后我们发现外部用户对于 Protobuf 或 gRPC 的关注会更多，所以参考 Kitex FastThrift 的优化思路，重新实现了 Protobuf 的生成代码。在 v0.4.0 版本，如果用户使用 Kitex 的工具生成 Protobuf 的代码，就会默认生成 Fastpb 的编解码代码，在发起 RPC 调用的时候，Kitex 也会默认使用 Fastpb。

下图是 Fastpb 与官方 Protobuf 序列化的性能对比，可以看到无论是编码还是解码，在效率和内存分配上，Fastpb 都远远优于官方 Protobuf 序列化库。

gRPC 性能优化

开源初期，我们对 gRPC 整体稳定性和性能的关注是比较少的。因为内部使用的场景不是很多。开源后收到了很多外部同学的反馈，所以我们针对 gRPC 做了一个专项的问题治理以及性能优化。今年中旬我们已经把相关的优化正式提交到开源库，在 v0.4.0 版本发布。

Kitex v0.4.0: https://sigusoft.com/s/ezifbQkHcZQP6MygmJABYA

下图中左侧是优化前 Kitex-gRPC 和官方 gRPC 框架对 Unary 请求的压测吞吐对比，在并发比较低的情况下，Kitex 的吞吐并不具有优势，使用 Fastpb 的时候，Kitex 的吞吐表现会好一些，但低并发的吞吐依然低于官方 gRPC。在优化之后，吞吐对比如右图所示。相比优化前吞吐提升 46% – 70%，相比官方 gRPC 框架，吞吐高 51% – 70%。

下图中右侧是优化后 Unary 请求的延迟对比，在吞吐比官方 gRPC 高出很多的情况下，Kitex 的延迟也显著低于官方的 gRPC。同时就 Kitex 自身而言，在优化后延迟表现也好了很多。

我们再看下 Streaming 请求的压测性能对比，优化前 Streaming 请求的表现同样在低并发的情况下，相对 gRPC 框架没有优势。经过优化后，Kitex 吞吐显著高于官方 gRPC，如下图，同时低并发下吞吐高但延迟持平，增加并发后能看到延迟出现分叉。所以在性能上， Kitex 支持的 gRPC 协议相对官方有明显的优势。

虽然在部分功能上，Kitex 还没有完全对齐，但是目前已经可以满足大部分的场景需求，我们后续也会继续进行功能对齐。

社区共建完善生态及企业落地

社区共建的 Kitex 扩展生态

开源后，我们很欣慰得到了很多开发者的关注，坦白说内部团队精力有限，无法快速建立起面向外部用户的 Kitex 扩展生态。但是一年以来借助社区的力量，Kitex 在服务注册/发现、可观测性、服务治理几部分的扩展得到了很多补充，尤其是服务注册/发现相关的扩展，目前开源的主流注册中心都已完成对接，虽然在功能丰富度上我们还有待加强，但结合已有的支持，对于外部用户已经具备了搭建微服务架构的能力。

衷心感谢积极参与 CloudWeGo 社区建设的同学们！关于 Kitex 相关的生态支持，大家可以进入 Kitex-contrib 了解更多的开源仓库。

Kitex-contrib: https://github.com/kitex-contrib

对接外部企业，协助落地

我们开源的初衷是为了助力其他外部企业快速地搭建企业级的云原生架构。开源后，森马、华兴证券、贪玩游戏、禾多科技先后主动与我们联系，反馈使用问题、提出需求，的确让我们发现了一些和内部场景不一样的问题，需要我们去关注、支持和优化，我们很开心 Kitex 能在这些企业内部得到应用。在今年 6 月 25 日的 CloudWeGo Meetup 中，森马和华兴证券的研发同学也分享了他们使用 Kitex 的内部实践。

森马：https://sigusoft.com/s/JAurW4P2E3NIduFaVY6jew

华兴证券：https://sigusoft.com/s/QqGdzp-7rTdlxedy6bsXiw

除了以上企业，还有一些公司也私下向我们咨询过使用问题，我们非常感谢这些企业用户的支持，以及向我们提出的反馈信息。如第一部分所讲，收集社区和企业的反馈可以促进 Kitex 面向多场景支持的演进，企业用户如果有相关需求，欢迎联系我们。

如何使用 Kitex 与内部基础设施集成

这里再简单介绍下如何使用 Kitex 与大家的内部基础设施集成。以字节内部为例，内部仓库里有开源库中的扩展实现，集成内部的能力，在 bytedSuite 中，我们针对不同场景对 Kitex 进行初始化。如下面的代码示例，用户只需要在构造 Client 和 Server 时增加一个 option 配置就可以完成集成，不过为了让用户完全不需关注内部能力的集成，我们将该配置放在了生成的脚手架代码中，关于配置如何内嵌在生成代码中，后续我们也会开放出来，方便外部的框架二次开发者能以同样的方式为业务开发同学提供集成能力。

总结和展望

总结

本次分享主要介绍了以下内容：

Kitex 如何保持内外统一地从内部应用较广的框架转为开源框架；

开源一年以来发布了哪些重要的功能特性，做了哪些性能优化；

借助社区的力量现在 Kitex 的周边生态如何、企业落地情况以及如何使用 Kitex 优雅地集成内部能力。

展望

与社区同学共建，持续丰富社区生态；

结合工程实践，为微服务开发者提供更多便利；

完善好 BDThrift 生态，持续优化 Protobuf/gRPC；

更多特性支持或开源，ShmIPC、QUIC、Protobuf 泛化…

以上内容整理自第七期字节跳动技术沙龙《字节高性能开源微服务框架：CloudWeGo》，获取讲师 PPT 和回放视频，请关注 CloudWeGo 公众号，并在后台回复关键词 “一周年”。

项目地址

GitHub：https://github.com/cloudwego

官网：www.cloudwego.io

CodeGeeX是一个具有130亿参数的多编程语言代码生成预训练模型。CodeGeeX采用华为MindSpore框架实现，在鹏城实验室“鹏城云脑II”中的192个节点（共1536个国产昇腾910 AI处理器）上训练而成。

截至2022年6月22日，CodeGeeX 在20多种编程语言的代码语料库（>8500亿Token）上预训练得到。

CodeGeeX有以下特点：

高精度代码生成：支持生成Python、C++、Java、JavaScript和Go等多种主流编程语言的代码，在HumanEval-X代码生成任务上取得47%~60%求解率，较其他开源基线模型有更佳的平均性能。代码生成示例
跨语言代码翻译：支持代码片段在不同编程语言间进行自动翻译转换，翻译结果正确率高，在HumanEval-X代码翻译任务上超越了其它基线模型。代码翻译示例
自动编程插件：CodeGeeX插件现已上架VSCode插件市场（完全免费），用户可以通过其强大的少样本生成能力，自定义代码生成风格和能力，更好辅助代码编写。插件下载
模型跨平台开源: 所有代码和模型权重开源开放，用作研究用途。CodeGeeX同时支持昇腾和英伟达平台，可在单张昇腾910或英伟达V100/A100上实现推理。申请模型权重

全新多编程语言评测基准HumanEval-X：HumanEval-X是第一个支持功能正确性评测的多语言、多任务的基准，包含820个人工编写的高质量代码生成题目、测试用例与参考答案，覆盖5种编程语言（Python、C++、Java、JavaScript、Go），支持代码生成与代码翻译能力的评测。如何使用

在HumanEval-X代码生成任务上，与其它开源基线模型相比，CodeGeeX取得了最佳的平均性能。

使用指南

CodeGeeX最初使用Mindspore框架实现，并在昇腾910AI芯片上进行训练。为适配更多平台，官方将其转换到Megatron-LM框架，支持Pytorch+GPU环境。

安装

需要Python 3.7+ / CUDA 11+ / PyTorch 1.10+ / DeepSpeed 0.6+，通过以下命令安装 :

git clone git@github.com:THUDM/CodeGeeX.git cd CodeGeeX pip install -e .

模型权重

通过该链接申请权重，您将收到一个包含临时下载链接文件的邮件。推荐使用aria2通过以下命令快速下载（请保证有足够的硬盘空间存放权重（～26GB））：

aria2c -x 16 -s 16 -j 4 --continue=true -i urls.txt

使用以下命令合并得到完整的权重：

cat codegeex_13b.tar.gz.part.* > codegeex_13b.tar tar xvf codegeex_13b.tar.gz

用GPU进行推理

尝试使用CodeGeeX模型生成第一个程序吧！首先，在配置文件中写明存放权重的路径。其次，将提示（可以是任意描述或代码片段）写入文件，运行以下脚本即可开始推理（需指定GPU序号）：

bash https://www.xujun.org/scripts/test_inference.sh <GPU_ID> https://www.xujun.org/tests/test_prompt.txt

VS Code插件使用指南

基于CodeGeeX 开发了一款免费的VS Code插件，在应用市场搜索“codegeex”或通过该链接安装。详细的使用指南在CodeGeeX插件使用指南.

左侧：CodeGeeX训练数据中各编程语言占比。 右侧：CodeGeeX训练损失函数随训练步数下降曲线。

全球最大的汽车制造商丰田近日承认，他们意外地将能够访问近 30 万用户资料的访问密钥公开在了 GitHub 上，并且长达 5 年时间，用户的部分个人信息可能已经发生了泄漏。

丰田在发布的道歉声明中表示，一个负责构建 T-Connect 的外包开发商于 2017 年 12 月将 T-Connect 网站的部分源代码错误地发布在了 GitHub 上，其中还包含了存储客户电子邮件地址和管理号码的数据服务器的访问密钥。

这个问题直到今年 9 月份才被丰田注意到，也就是说在这近 5 年时间里，未经授权的第三方可以毫无障碍地访问客户信息。

注：丰田 T-Connect 是该汽车制造商的官方项目，允许丰田汽车的车主将他们的智能手机与车辆的信息娱乐系统连接起来，以获得电话、音乐、导航、通知集成、驾驶数据、发动机状态、油耗等功能和信息的控制与访问。

发现问题后，丰田第一时间将该仓库设为私有，并及时修改了数据库的密钥，目前已经解决了潜在的问题。

此次事件中涉及的数据库仅存储了用户的电子邮件地址和客户管理号码，由于客户姓名、信用卡数据和电话号码等数据是存储在另一个数据库中的，因此这些数据并没有泄漏。

虽然那些敏感信息没有发生泄漏，但用户也需要留意近期收到的电子邮件，不要随意未知发件人的邮件，以防黑客伪装成丰田官方人员向用户发送钓鱼邮件。

丰田表示：

我们将单独向任何可能泄露电子邮件地址或客户管理号码的客户发送致歉信息和通知。此外，我们在网站上准备了一个特殊的表格，可以让用户检查你的电子邮件地址是否受此活动的影响，我们还设立了专门的呼叫中心来回答客户的问题和疑虑。

这一事件是由开发承包公司对源代码的不当处理造成的，我们将与承包公司合作，确保对客户个人信息的处理进行彻底管理，并加强安全。丰田公司重申，妥善处理客户的个人信息是一项重要的企业社会责任，并将进一步努力确保客户个人信息的保护和管理，以实现客户可信赖的服务。

继呼吁停用 C/C++ 开发新项目并使用 Rust 之后，Microsoft Azure CTO、Sysinternals 的主要开发者 Mark Russinovich 的一条吐槽 Git 的新社交动态又引起了广泛讨论。他表示：

Git 又一次让我想拔掉我的头发。这是我使用过的所有软件中最不直观、最笨重的界面之一。

事实上，Mark Russinovich 并不是第一个也不是唯一一个有此感想的人，很多人在评论表达了自己的共鸣。有人指出，“据我所知，连 Linus 都讨厌它”。其中一条高赞评论还指向了一个吐槽 Git 的网页（ohshitgit.com），这个吐槽页面甚至被不同国家的几十名开发者自发翻译成了不同的语言版本。

“用好 Git 很难: 很容易就犯错了，然后想自己弥补犯下的错，简直太难了。查阅 Git 文档简直就像是个先有鸡还是先有蛋的问题，你得知道你要的是啥，但如果我知道的话，我还他妈查个毛文档啊！”

网页作者还详细分享了自己在使用 Git 时所遇到的一些抓狂瞬间，并提供了所采用的解决办法：

Oh shit，我刚才好像犯了个大错，能不能给我台时光机啊!?!
Oh shit，我刚提交 commit 就发现还有一个小改动需要添加！
Oh shit，我要修改我刚刚 commit 提交的信息！
Oh shit，我不小心把本应在新分支上提交的东西提交到了 master!
Oh shit，我把这个 commit 提交错分支了！
Oh shit，我想用 diff 命令看下改动内容，但啥都没看到?!
Oh shit，我想撤回一个很早以前的 commit！
Oh shit，我想撤回某一个文件的改动！
Fuck this noise, I give up（指那些 untracked 的文件）

针对 Mark Russinovich 的发言，也有人激动地表示自己已经因为 Git 烦扰多时，现在则终于有权威人士出来发声了。

根据维基百科，Mark Eugene Russinovich（生于 1966 年 12 月 22 日）是西班牙裔美国软件工程师，现任 Microsoft Azure CTO。在 2006 年被微软收购之前，他是软件生产商 Winternals 的联合创始人。

Mark Russinovich 首次接触电脑是在 20 世纪 70 年代，源于他朋友的父亲得到了一台 Apple II。彼时，他就能够对其 ROM 进行逆向工程以及为其编写程序。15 岁时，他给自己买了第一台电脑 —— 德州仪器的 TI99/4A。他还是小说 Rogue Code、Zero Day and Trojan Horse、Windows Internals、Sysinternals tools 的作者。2005 年，在业界引起巨大反响的索尼 DRM 反拷贝程序事件也是他发现的。

据 SerenityOS 博客介绍：自 2018 年 10 月 10 日 SerenityOS 存储库迎来第一次提交，距今已满四周年。

SerenityOS 是一个类似 Unix 的操作系统，但是带有图形化界面，适合 x86 计算机。SerenityOS 结合了类 Unix 内核和 1990 年代生产力软件的外观和体验，其界面类似 90 年代的Win98/NT。SerenityOS 的作者是来自瑞典的程序员 Andreas Kling ，在 2018 年完成了为期 3 个月的毒瘾康复计划后，Andreas 发现“自己有很多时间，没有什么可以做的“，接着就用了将近三年的时间全职创建 SerenityOS 。

SerenityOS 项目最初只是想做一个操作系统内核，但随着社区的壮大和贡献者的增加，现在已经诞生了属于 SerenityOS 的内存安全的编程语言 jakt ，以及跨平台 Web 浏览器 Ladybird。

SerenityOS 项目最初使用 C++ 语言开发，但随着系统本身的壮大和普及，内存安全成为了一个大问题。社区最初尝试了 Rust 等用多种语言进行了原型设计，却发现它们都不适合这个项目，只好创建了属于自己的 jakt 编程语言。最初的 Jakt 原型使用 Rust 编写，如今 jakt 已实现自举：Jakt 编译器本身也用 Jakt 编写。

目前 SerenityOS 已可以满足基本的办公需求（虽然内核还不太稳定），还移植了一些经典的 PC 游戏。游戏运行在 LibGL （SerenityOS 社区对 OpenGL API 的实现）之上。游戏的渲染由 LibSoftGPU 完成，这也是 SerenityOS 社区自研的一款使用 SIMD 的软件光栅化器。

如今 SerenityOS 已有 750+ 贡献者，社区在持续壮大中。作者称最新的目标是在 SerenityOS 内部构建所有组件和工具，不依赖任何第三方库，我愿称之为轮子王。

Hadoop是Apache基金会旗下最知名的基础架构开源项目之一。自2006年诞生以来，逐步发展成为海量数据存储、处理最为重要的基础组件，形成了非常丰富的技术生态。

作为国内顶尖的 Hadoop 开源生态技术峰会，第四届 China Apache Hadoop Meetup于 2022年9月24日在上海成功举办。

围绕“云数智聚砥柱笃行”的主题，来自华为、阿里、网易、字节跳动、bilibili、平安银行、袋鼠云、英特尔、Kyligence、Ampere等多所企业单位，以及来自Spark、Fluid、ChunJun、Kyuubi、Ozone、IoTDB、Linkis、Kylin、Uniffle等开源社区的多位嘉宾均参与了分享讨论。

作为此次Meetup参与社区之一，也是大数据领域的项目，ChunJun也带来了一些新的声音：

ChunJun框架在实时数据采集和还原上的实现和原理是怎样的？这段时间以来，ChunJun有哪些新发展，对于未来发展又有着怎样的新想法？

作为袋鼠云资深大数据引擎开发专家，徐超带来了他的分享，将从一个独特的角度来介绍ChunJun数据集成在数据还原上的探索和实践。

一、ChunJun框架介绍

第一个问题：ChunJun这个框架是什么？能干啥？

ChunJun(原FlinkX) 是袋鼠云基于Flink 基座自研的数据集成框架,经过4年多的迭代，已经成为一个稳定，高效，易用的批流一体的数据集成工具，可实现多种异构数据源高效的数据同步，目前已有3.2K+Star。

开源项目地址：

https://github.com/DTStack/chunjun

https://gitee.com/dtstack_dev_0/chunjun

01 ChunJun框架结构

ChunJun 框架基于Flink 进行开发，提供了丰富的插件，同时添加了断点续传、脏数据管理、数据还原等特性。

02 ChunJun批量同步

• 支持增量同步

• 支持断点续传

• 支持多通道&并发

• 支持脏数据（记录和控制）

• 支持限流

• 支持transformer

03 ChunJun离线

二、实时数据采集上的实现和原理

01 一个样例

02 ChunJun插件装载逻辑

03 ChunJun插件定义

04 ChunJun数据流转

05 ChunJun动态执行

面对监听多个表的情况，包括新添加表的数据，我们如何执行下游的写入：

• 支持Update 转换 before,after

• 添加扩展参数，DB,Schema,Table, ColumnInfo

• 支持动态构建PreparedStatement

06 ChunJun间隔轮询

什么是间隔轮询？我们是如何做的？

• 校验轮询字段类型，如果不是数值类型且source并行度大于1，报错不支持

• 创建三个数据分片，startlocation为null或者配置的值，mod分别为0，1，2

• 构造SQL：不同SQL的取余函数不同，各自插件实现

select id,name,age from table where (id > ? and ) mod(id, 3) = 0 order by id;

select id,name,age from table where (id > ? and ) mod(id, 3) = 1 order by id;

select id,name,age from table where (id > ? and ) mod(id, 3) = 2 order by id;

• 执行SQL，查询并更新lastRow

• 第一次result查询完后，若脚本中没有配置startlocation，则之前的查询SQL为：

select id,name,age from table where mod(id, 3) = 1 order by id;

将其更新为：

select id,name,age from table where id > ? and mod(id, 3) = 1 order by id;

• CP时获取lastRow中的id值，保存到state中

三、实时数据还原上的实现和原理

01 数据还原介绍

数据还原基于对应的数据库的CDC采集功能,比如上面提到的Oracle Logminer,MySQL binglog，支持将捕获到的数据完整的还原到下游，所以不仅仅包括DML，而且也需要对DDL进行监听，将上游数据源的所有变更行为发送到下游数据库的还原。

难点

· DDL，DML 如何有序的发送到下游

· DDL 语句如何根据下游数据源的特性进行对应的操作（异构数据源间DML 的转换）

· DML 语句中的insert update, delete 如何进行处理

02 一个样例

03 整体流程

数据从上游的数据源获取之后经过一些列的算子的处理之后按数据在原始表中的顺序准确的还原到目标数据源，完成数据的实时获取链路。

04 DDL解析

数据还原- DDL转换

· 基于Calcite解析数据源DdlSql转为SqlNode

· SqlNode转为中间数据DdlData

· ddlData转为sql：不同语法之间互相转换；不同数据源字段类型互相转换

05 名字映射

在实时还原中，当前上下游表字段对应关系必须是相同的，即上游的database schema table 对应的表只能写入下游database schema table相同的表，同时字段名称也必须是相同的。本次迭代将针对表路径可以进行一个自定义映射以及字段类型进行自定义映射。

• db or schema 转换

• 表名称转换

• 字段名(提供大小写转换)，类型隐式转换

06 中间数据缓存

数据（不论ddl还是dml数据）下发到对应表名下的unblock队列中，worker在轮询过程中，处理unblock数据队列中的数据，在遇到ddl数据之后，将数据队列置为block状态，并将队列引用交给store处理。

store在拿到队列引用之后，将队列头部的ddl数据下发到外部存储中，并监听外部存储对ddl的反馈情况（监听工作由store中额外的线程来执行），此时，队列仍然处于block状态。

在收到外部存储的反馈之后，将数据队列头部的ddl数据移除，同时将队列状态回归为unblock状态，队列引用还给worker。

07 目标端接收数据

• 获取到DdlOperator 对象

• 根据目标数据源对应的DDLConvertImpl解析器转换为目标数据源sql

• 执行对应的sql,比如删除表

• 触发调整DDLChange 表，修改对应的DDL 状态

• 中间存储Restore算子，监听状态变更，执行后续数据下发操作

四、ChunJun未来规划

• 提供对Session 进行管理

• 提供restful 服务，ChunJun 本身作为一个服务，便于外围系统进行集成

• 对实时数据还原进行加强，包括扩展支持更多的数据源的DDL 解析

此外，本次分享的全文视频内容也可以随时观看，如果您有兴趣，欢迎前往袋鼠云B站平台观看。

Apache Hadoop Meetup 2022

ChunJun视频回顾：

https://www.bilibili.com/video/BV1sN4y1P7qk/?spm_id_from=333.337.search-card.all.click

袋鼠云开源框架钉钉技术交流群（），欢迎对大数据开源项目有兴趣的同学加入交流最新技术信息，开源项目库地址：https://github.com/DTStack/Taier

不同行业之间，都会存在一些业务属性上的差距。对于金融领域的应用软件来说，因其涉及到钱等因素，所以在业务上会有以下独特属性：

稳定性。 金融领域跟钱强相关，这对于业务稳定性就有着非常严格的要求，稳定性一旦出现问题，它将影响整个交易系统的成败。
强监管。 强监管一般是针对生物医药领域、医疗领域和金融领域，因为它们所呈现的内容都与人的生命相关。所以，更高层面的强监管要求势必会影响一些业务层面的选型和架构呈现。
准确性和有效性。 由于跟钱强相关，所以在数字层面的呈现更是要求零偏差。就像股票价格一样，它的数字呈现都是精确到了每分每秒和固定数位的。

基于以上这些特点，金融行业软件系统在进行系统设计、机房拓扑以及中间件选型时，就会出现一些与其他通用行业不太一样的地方。

对 Java 的那些爱与恨

金融系统为何独爱 Java

Java 自诞生以来就深受开发者的喜爱。在中国有将近 50% 的开发者在使用 Java 作为开发语言。这不单单是因为其语言的优势，也因为 Java 相关的生态非常庞大，尤其是国内的金融系统很多都是基于 Java 的，这导致有段时间大家都误以为所有的系统都是用 Java 做的。

近 15～20 年以来，大部分金融系统基本都选择了 Java 技术栈，深究其原因，我们认为主要是因为 Java 技术栈有以下几点优势。

正是如此，Java 逐渐得到了金融类软件系统的青睐。

云原生时代下的 Java 现状

随着技术行业的快速发展，单体架构逐渐被淘汰，微服务和云原生时代正在风靡四海。然而在近几年的技术大环境下，作为面向对象的高级语言，Java 也在一些业务场景中开始略显疲惫：

首先，Java 性能较低，这点对比一下 C 语言相关技术栈就会明白。Java 是基于虚拟机，它的内存管理是交给虚拟机来解决的，所以当面对一些高性能或动态变化的业务场景时，Java 语言在处理上没有那么强势。

其次，Java 语言需要更多的资源。一个架构的打造如果不考虑成本，很多问题都很好解决，但在云原生时代下，所有的资源计算变得越来越细、越来越颗粒化。Java 在运作时需要消耗大量的资源，由于 Java 分量重和需要重启的基础特性，因此在高 QPS 或者业务连续性要求较高的场景下，该语言会更容易出现问题。

最后就是指针变量的问题。习惯于写 C/C++ 语言的同学都知道，指针是一个非常好的资源。但 Java 是基于虚拟机，它把内存管理交给了 GC（Garbage Collection），而不是由手动程序进行管理，所以对于一些特定情况或者高并发、高访问量和高性能的场景下，Java 的实际性能可能就略显不足了。

还呗为何选择 APISIX？

数禾科技是一家提供智能化金融的服务平台，旗下主要产品有还呗、还享花等。还呗 APP 是一款基于消费多场景的分期服务平台，通过与持牌金融机构合作，为大众提供个人消费信贷服务，并为小微企业主提供贷款资金支持。在业务架构层面，还呗的产品实现一直是依赖 Java 技术栈的。

Spring Cloud Gateway 是 Spring Cloud 生态下为更好管理微服务而诞生的网关项目，对于公司业务以 Java 为主要开发语言的情况下，Spring Cloud Gateway 通常是个不错的 API 网关选择。但在近期的 API 网关迭代过程中，还呗放弃了使用已久的 Spring Cloud Gateway，而是选择了 Apache APISIX。

架构的前后变化

在架构层面，还呗在使用 APISIX 前后呈现了如下图所示的变化。

在左侧的使用前架构中，还呗一共使用了三套网关系统，并把网关分为入口网关和出口网关两大类。其中在运营系统网关和出口系统网关中，都使用了 Spring Cloud Gateway 作为网关，而在业务系统网关中则使用了 OpenRestry 作为业务系统网关。

对于一开始使用 Spring Cloud Gateway 作为运营和出口系统网关，主要是看中了 Spring Cloud 庞大的生态系统，以及简单易部署和易维护的分布式系统开发框架，所以在早期进行业务架构部署时，为了更快搭建起业务而选择使用 Spring Cloud 全家桶。

但随着业务慢慢发展，原先架构中的网关开始出现一些稳定性的问题，比如内存溢出、CPU 使用率过高等情况。为了升级网关性能及统一多个网关，还呗将架构中的网关全部统一替换为了 Apache APISIX。

在新网关架构中，业务系统网关会优先把请求流量通过服务发现的方式直接转发到业务系统。如果后端应用在 Consul 中没有健康 Pod 或者后端应用不支持服务发现等，就会把流量转发到以前的内网 K8s Ingress，作为兜底的上游来使用。

新架构同时也统一了出口网关的两个应用，新出口网关部署在 K8s 集群外的外联区。同时也在出口网关集群前新增一个 SLB，可以统一出口网关的入口，方便没有服务发现能力的应用或者其他 VPC 内的系统调用。

基于 APISIX 的应用实践

实际业务情况下，由于内部已存在多种网关架构，没办法直接使用 Apache APISIX，于是还呗基于 APISIX 进行了一些改造和构建。

APISIX 构建部署

在内部进行开发时，将 APISIX 网关的代码和定制代码存放在不同路径下，两者协同工作，各自可独立迭代。在部署时则采用 Docker 镜像方式部署，构建一个 APISIX 指定版本的基础镜像，然后再把自定义代码打包形成新镜像。

自定义代码打包时没有使用来指定代码目录，而是直接覆盖基础镜像源码目录，如果有同名文件则覆盖源码文件。Dockerfile 如下所示：

APISIX 的日志默认存储在本地（也可以通过 Syslog 等插件收集），通过调整配置模板和判断启用的 Profile 来决定日志存储在本地还是通过 Syslog 存储到 FLUENTD 中。同时在构建镜像时替换模板中变量。如下所示：

在配置模板中，还呗不光修改了日志存储，还调整了循环添加 ENV 环境变量、循环添加 lua_shared_dicts 配置及写死一些 NGINX 其他调优参数。

因为公司是按照业务流量划分为多种网关，这些网关的基本功能都差不多，因此还呗内部采取了「一套代码部署多个网关应用」方案。通过 Profile 功能配置各个网关的 config-xxx.yaml 文件，然后通过公司 DEVOPS 平台构建镜像时，根据应用名构建不同网关的 Docker 镜像即可。

公司级定制插件

在内部访问运营系统页面时，会调用很多后端的 API 获取数据，这些 API 都需要在 API 网关中配置对应的白名单。在页面中根据登录运营系统用户的角色不同，能够访问的 API 范围也不一样，因此权限系统也需要维护相关 API 列表。每当在页面上新增后端 API 调用时，都需要开发人员在网关页面及权限系统页面配置两次，工作冗余且重复。

为此，还呗把网关配置与权限系统配置打通，只保留权限配置系统的配置入口，网关配置管理系统则定时拉取权限 API，之后转换成网关 API 白名单配置。这样做不仅能减少用户一次配置操作，同时也协助权限系统进行了权限管控。可以保证在运营页面调用的后端 API，一定是在权限系统配置了相关权限。

在公司的实际业务中，经常会遇到原生插件不能满足实际需求的情况，就需要定制开发。好在 APISIX 提供了很多工具类，参照原生插件就可以轻松实现，开发过程也非常简单。以下列举了还呗内部基于 APISIX 进行的其他定制插件：

网关流量灰度

之前还呗使用的 K8s 容器是 OpenShift（现已升级为 ACK 集群），其中 Ingress 是 Haproxy 搭建。由于公网 K8s Ingress 的 Haproxy 不能把一个域名的流量转发到两个 Namespace 的路由中，因此考虑把新网关部署在和老网关相同的 Namespace 下。即域名的路由下挂载多个服务，之后便可以通过路由调整流量比例，控制流量走新网关还是老网关。

具体实施流程如下图所示，在老网关的 Namespace 下新增 c、d 组用于部署新网关，通过路由控制新老网关的流量比例。

Java 层面网关的考虑因素

很多 Java 工程师在微服务架构中都会选择 Spring Cloud，主要是语言绑定，并用类库的方式放在代码里。但是在实践过程中可能会出现升级困难的情况，如果团队是多语言就需要维护多个类库，假设有 10 个版本与 10 种语言，就需要维护 100 个类库。

此时就可以通过代理的方式（即 API 网关）把多版本和多语言的问题轻松解决。那 Java 技术栈公司选择 APISIX 作为 API 网关后都有哪些收益？我们根据还呗的实践经历，从以下两个角度进行了总结。

公司角度

功能与性能兼具

还呗在内部使用 4 核虚拟机无插件空跑压测 APISIX 的 QPS 可以达到 80K，很好地解决了 Spring Cloud Gateway 在承接 C 端流量时出现的性能问题，而且在生产环境中发现 APISIX 相较于之前网关性能提升了 30% 以上。

其次，得益于云原生属性，APISIX 在实际的测试中完全可以满足公司的需求，比如认证鉴权、可观测性、服务发现、限流限速以及四层和七层流量转发。而在功能扩展方面，APISIX 也支持了 70 余款插件，大部分的业务可以使用其原生插件，很大程度上减少了开发工作。

业务支出成本下降

在使用 APISIX 之前，如果性能出现了瓶颈，公司只能通过不断的增加服务器来解决这个问题，因此相应的硬件成本也会非常的高。

还呗在进行成本计算时发现，使用 APISIX 后，服务器的数量大概减少了 60% 左右。统一技术栈后，业务上也可以很轻松地基于 APISIX 原生框架实现功能的扩展，节省了开发成本，加快了项目上线时间速度。

开发者角度

满足业务需求

业务中所使用的软件或技术都应该是为需求而服务。从实际测试结果及调研数据来看，APISIX 的稳定性、可观测性、可扩展性会更好。

软件最终服务于业务。如果业务需要，可以为公司节约资源，那么无论公司的技术栈是什么，都会使用最符合公司业务的组件。

降低维护成本

相比之前使用的 OpenResty，APISIX 的学习成本相对较低，维护起来也比较省心。同时，APISIX 丰富的插件简化了一些通用功能的实现与部署，大大节约了项目上线的时间。

同时利用 APISIX 强大的日志和动态调试功能，业务可以很轻松地排查出故障点，从而快速定位、节约时间。

总结：金融业务发展趋势

在过去的十年里，互联网金融从「野蛮生长」开始逐渐向「精耕细作」模式转变，这个转变主要涉及到的就是系统的变革。

在野蛮生长阶段，业务讲究的是效率。为了业务更快速地建设，在基础架构选择的时候，负责人更多是选择自己熟悉的语言架构进行搭建。不同的负责人便会选择使用不同的技术栈，因此留下了很多技术债务。从 2017 年开始，依旧活跃的金融企业或服务公司大多都会面临同样的技术现状，那就是存在多套技术组件。这时就需要进行基础设施的统一。

来到精耕细作阶段，企业就需要对系统进行垂直拆分，由以前的烟囱式拆分成前台、中台及后台等模式。系统到达一个稳定阶段时，就需要把一些东西夯实下来。

而系统建设的根本目的其实就是为了共用。重复性使用越强，系统的运维成本就越低。所以很多公司到了精耕细作阶段，要么是进行系统的垂直拆分，要么就是进行基础组件的下沉，进而控制运维成本。

作为企业来说，成本优先依旧是需要考虑的原则。野蛮生长阶段可能只需要尽快实现业务，而在目前大环境下，预算范围之内肯定是成本优先。这样的话，效率和成本永远只能保住一项。因此在成本有限的情况下，企业就会少谈技术的先进性。技术人员在选型的过程中，就不会考虑当下选择的这个技术对团队有多大冲击、对现有的运维和架构带来多少收益等等，更多是从成本角度考虑。

项目背景

MAUI的出现，赋予了广大Net开发者开发多平台应用的能力，MAUI 是Xamarin.Forms演变而来，但是相比Xamarin性能更好，可扩展性更强，结构更简单。但是MAUI对于平台相关的实现并不完整。所以MASA团队开展了一个实验性项目，意在对微软MAUI的补充和扩展，

项目地址：https://github.com/BlazorComponent/MASA.Blazor/tree/main/src/Masa.Blazor.Maui.Plugin

每个功能都有单独的demo演示项目，考虑到app安装文件体积（虽然MAUI已经集成裁剪功能，但是该功能对于代码本身有影响），届时每一个功能都会以单独的nuget包的形式提供，方便测试，现在项目才刚刚开始，但是相信很快就会有可以交付的内容啦。

前言

本系列文章面向移动开发小白，从零开始进行平台相关功能开发，演示如何参考平台的官方文档使用MAUI技术来开发相应功能。

介绍

之前两篇文章我们实现了安卓蓝牙BLE的相关功能，本文我们将IOS的BLE功能实现一下。，考虑到Swift语法对于c#开发人员更友好，本文示例代码参考Swift，相关代码来自苹果开发者官网

https://developer.apple.com/documentation

开发步骤

修改项目

在Masa.Blazor.Maui.Plugin.Bluetooth项目中的Platforms->iOS文件夹下，添加一个部分类MasaMauiBluetoothService，在安卓中有BluetoothManager，在ios中对应的是CBCentralManager，但是不同有安卓还有个适配器Adapter的概念，在ios中关于设备扫描、连接和管理外围设备的对象，都是通过CBCentralManager直接管理的，我们看一下他的初始化方法

delegate：接收中心事件的委托。相当于我们在安装中实现的DevicesCallback

queue：用于调度中心角色事件的调度队列。如果该值为 nil，则中央管理器将使用主队列分派中心角色事件。这个我们可以简单的理解为和安卓的UI线程或者后台线程对应，更详尽的说明请参考 https://developer.apple.com/documentation/dispatch/dispatchqueue

options：配置信息，我们这里只用到了ShowPowerAlert，代表蓝牙设备如果不可用，给用户提示信息。就好比你用了不符合标准的数据线，iphone会给你提示是一个意思。

我们将MasaMauiBluetoothService修改为静态类，我们自定义的BluetoothDelegate 继承自CBCentralManagerDelegate，篇幅问题我们这里先只重写DiscoveredPeripheral和 UpdatedState，我们这次的演示不需要实现UpdatedState，但是这里的重写必须先放上去，否则调试过程会出现下面的报错

ObjCRuntime.ObjCException: ‘Objective-C exception thrown. Name: NSInvalidArgumentException Reason: -[Masa_Blazor_Maui_Plugin_Bluetooth_MasaMauiBluetoothService_BluetoothDelegate centralManagerDidUpdateState:]: unrecognized selector sent to instance 0x284bfe200

另外有一点需要特别注意，这个UpdatedState方法我没有实现的代码，那么我就需要添加一个[Preserve]，这样是为了防止链接器 在生成nuget包的时候把这个方法帮我优化掉。

实现发现附近设备功能，_eventWaitHandle和安卓一样，我这里只是实现了一个异步转同步方便直接通过Devices拿到结果，如果小伙伴不喜欢后期我会添加不阻塞的方式。这里之所以可以Devices.Contains和Devices.Add是因为我们在BluetoothDevice类中实现了隐式转换如下是iOS目录下BluetoothDevice.ios.cs的部分代码

ios扫描外围设备是通过scanForPeripherals 我们继续在MasaMauiBluetoothService添加一个扫描附件设备的方法，我们看一下Swift的文档

serviceUUIDs：代表需要过滤的服务UUID，类似安卓的scanFilter对象。 option：提供扫描的选项，我们这里用到了AllowDuplicatesKey，该值指定扫描是否应在不重复筛选的情况下运行我们参照实现以下我们的PlatformScanForDevices方法

通过 _cbCentralManager.IsScanning来判断是否处于扫描状态，如果没有，那就就通过ScanForPeripherals扫描外围设备，扫描5秒之后（BluetoothDelegate 内部控制）通过StopScan停止扫描，并通过 _discoveredDevices 保存结果。我们还需实现PlatformIsEnabledIsEnabled和PlatformCheckAndRequestBluetoothPermission方法，用来在扫描之前检查蓝牙是否可用并且已经经过用户授权

在PlatformIsEnabledIsEnabled方法中通过 _cbCentralManager.State == CBManagerState.PoweredOn 来判断蓝牙是否可用。该状态一共有如下枚举，从字面意思很好理解 Unknown, //手机没有识别到蓝牙 Resetting, //手机蓝牙已断开连接 Unsupported, //手机蓝牙功能没有权限 Unauthorized, //手机蓝牙功能没有权限 PoweredOff,//手机蓝牙功能关闭 PoweredOn //蓝牙开启且可用

权限检查这里和安卓有一些区别，在重写的RequiredInfoPlistKeys方法中指定了需要检查的蓝牙权限，BasePlatformPermission的EnsureDeclared方法用来检查是否在Info.plist文件添加了需要的权限，GetBleStatus方法通过 _cbCentralManager 的状态，来检查授权情况。

我们在Masa.Blazor.Maui.Plugin.Bluetooth的根目录添加部分类MasaMauiBluetoothService.cs，向使用者提供ScanForDevicesAsync等方法，方法内部通过PlatformScanForDevices来调用具体平台的实现。

使用

右键Masa.Blazor.Maui.Plugin.Bluetooth项目，打包，生成一个nuget包，在Masa.Blazor.Maui.Plugin.BlueToothSample项目中离线安装即可，代码的使用与安卓完全一样，只是权限配置方式不同在Masa.Blazor.Maui.Plugin.BlueToothSample项目的Platforms->iOS->Info.plist中添加蓝牙相关权限

NSBluetoothAlwaysUsageDescription对应iOS 13以上版本，对于iOS 13之前的版本，需要将NSBluetoothAlwaysUsageDescription和NSBluetoothPeripheralUsageDescription同时添加。

蓝牙扫描的效果和安卓机是完全一样的，这里就不展示了。[前文详情]

iOS调试及错误排查

目前在windows的vs环境调试MAUI的ios程序，是不需要mac电脑支持的，数据线连上后会显示一个本地设备，但是你仍然需要一个开发者账号，vs会调用apple开发者api自动帮你配置好需要的证书。

1、如果没有显示检查Xamarin->iOS设置，热重启是否开启

2、调试过程如果提示类似 Could not find executable for C:UsersxxxAppDataLocalTemphbjayi2h.ydn 找不到文件的情况，右键选择清理项目即可，如果无法解决手动删除bin和obj目录重试

3、调试过程如果app无故退出，排查一下考虑APP的启动和调试断点时间，iOS要求所有方法必须在17秒之内返回，否则iOS系统将停止该应用

4、调试过程出现Deploy Error: An Lockdown error occurred. The error code was “MuxError”的错误，请检查你的数据线，重新插拔或者更换原装线。

本文到此结束。

如果你对我们MASA感兴趣，无论是代码贡献、使用、提 Issue，欢迎联系我们

WeChat：MasaStackTechOps
：

一、引言

Presto是开源分布式SQL查询引擎，可以对从GB到PB级大小的数据源进行交互式分析查询。Presto支持Hive、Cassandra、关系型数据库甚至专有数据存储等多种数据源，允许跨源查询。（详见参考[1] ）

WebStorm激活2022.2.3(WebStorm 2022.2.3 发布)

图1 Presto层次架构图（图源Presto官网）

无处不在的Presto

当今大规模的互联网公司都在使用Presto。

Uber将Presto用于SQL数据湖，每周有超过7000名活跃用户，每天在超过50PB 的HDFS（Hadoop Distributed File System）数据上运行50万次查询。

字节跳动对Presto 进行了广泛的应用，例如数据仓库、BI 工具、广告等。字节跳动的 Presto 集群拥有上万个计算核心，每天处理约 100 万次查询，涵盖 90% 以上的交互式查询。这极大地减少了查询延迟并节省了大量计算资源。

Meta公司（Facebook）使用 Presto 对多个内部数据存储进行交互式查询，包括300PB 数据湖。每天有超过 1,000 名 Facebook 员工使用 Presto 运行 30,000 多个查询，平均每个查询扫描超过 1 PB。

腾讯将Presto 应用于内部的不同业务场景，包括微信支付、、游戏等关键业务。日均处理数据量 PB 级，P90 查询耗时为 50s，全面提升各业务数据实时分析性能，有效助力业务增长。

阿里数据湖分析集成了Presto的联合查询引擎能力，不仅让阿里云众多用户体验了大规模的 Serverless 云服务，也积累了许多成功的业务用例，比如日志数据分析和基因数据分析等，这些案例表明了Presto应用广泛，分析能力强大。

图2 各大互联网公司Presto性能展示数据部分来源Presto官网

Presto系统架构

Presto 集群由一个Coordinator和一个或多个Worker组成。Coordinator负责接纳、解析、规划和优化查询以及查询编排，Worker负责查询处理。Presto通过Connector适应底层不同类型的数据源，以便访问各种数据源中的数据。如图3显示了 Presto 架构的简化视图（详见参考[2] ）。

图3 Presto 架构图

传统方式部署Presto存在的问题

作为一个分布式架构的系统，Presto为数据查询和处理提供了高效便捷的方法。随着数据量增大，为了保证数据查询处理的效率，Presto集群规模也要扩大。例如上文提到的Uber、字节跳动和Meta等公司每天查询的数据量是PB级别，一个Presto集群的节点数量已经上千。当数据量远超单机处理能力时，分布式架构相比于集中式架构的优势就体现出来了，但是对于一个规模庞大的分布式集群，持续高效地处理数据，将会面临一系列的问题：

对于一个规模庞大、节点数量上千的Presto集群，如果没有自动化部署工具，采用传统方式一个一个部署Presto节点，耗费的时间是难以想象的。此外对于部署好的Presto集群根据业务进行调优，需要不断修改Presto节点的配置信息，按照传统方式逐个修改配置信息，耗费的人力和时间成本也是难以忍受的。

2. 传统部署Presto集群，当其中某个节点发生故障时，无法做到自动重启或者动态加入新的节点以维持集群数量，此时如果正好发生故障的是Coordinator节点，则整个集群将陷入瘫痪，导致服务不可用。

3. Presto主要应用场景是即席查询，比如Uber和滴滴等网约车公司，查询业务高峰时段主要在白天，晚上基本没有查询。如果晚上闲置的资源不能加以回收利用，将会产生很大的资源浪费。此外，当业务高峰期的查询负载超过当前集群的承载能力时，如果不对集群立刻按需扩容，也会对业务产生很大的影响。

使用Kubernetes部署Presto集群，将云原生与Presto相结合，借助Kubernetes便捷部署、自动化运维和弹性伸缩等优点，解决上述提到的一系列问题。

二、使用Kubernetes部署Presto

Kubernetes，也被称为K8s，是一个用于自动化部署、扩展和管理容器化应用程序的开源系统，目前已被业界广泛接受并得到了大规模的应用。Kubernetes集群由控制平面和node组成。其中node上运行由Kubernetes所管理的容器化应用，也就是Pod。控制平面管理集群中的node和Pod，为集群提供故障转移和高可用性，而集群也会跨多个主机运行（详见参考[3] ）。

图4 Kubernetes部署Presto集群方案

如图4所示为本次测试所部署方案，Deployment负责创建、更新、维护其所管理的所有Pods。Presto Coordinator和Worker进程分别运行在Pod中，针对Presto集群内Coordinator和Worker分别配置不同类型的Deployment来进行管理。Deployment可以保证集群内可用Pod的数量，实现弹性伸缩，维持集群可用性和稳定性。

Configmap用来存储配置文件，Coordinator和Worker的配置信息分别通过Configmap进行存储，每次进行配置更改，只需要修改Configmap里面的配置信息，Coordinator和Worker就会更新相应的配置信息。

Service会对同一个服务的多个Pod进行聚合，向集群提供一个统一的入口地址，通过访问Service的入口地址就能访问到后面的Pod服务，实现负载均衡和服务发现。在Kubernetes部署的Presto集群中，Coordinator将自己的地址注册到Service，Worker通过Service中的域名地址与Coordinator连接，从而实现Presto集群的服务注册与发现。

在Kubernetes部署Presto方案中，Deployment负责创建和管理Pods，Configmap负责存储配置信息，Service负责服务注册与发现。Deployment、Configmap和Service三类资源相互配合，保证了Presto集群持续高效工作。

Kubernetes部署方案的优点

通过合理设置Deployment、Configmap和Service等资源对象，使用Kubernetes部署Presto集群，将Kubernetes的运营优势与Presto技术优势相结合：

便捷部署：在Deployment中设置Coordinator和Worker的副本数量，Configmap设置配置信息，Service设置Presto集群提供服务的入口地址。将上述三类资源对象提交到Kubernetes中即可完成Presto集群配置，比如设置Worker副本数量为1000，提交之后即可创建1000个Worker Pod，每一个节点的配置信息从Configmap文件中读取。只需要编写好资源对象文件，提交到Kubernetes，即可创建Presto集群，后续可以通过修改Configmap文件更新各个节点的配置信息。通过Kubernetes部署Presto集群减轻了配置、部署、管理和监控容器化Presto应用程序的负担和复杂性。

自动化运维：可以更方便地和Prometheus结合，通过Prometheus可以实现对整个集群的监控数据采集、存储、分析以及可视化。有效监控Presto集群，当发生故障时可以针对性修复，从而维持集群稳定，保证高可用性。

弹性伸缩：当业务量激增，自动扩容Presto Worker节点，满足业务需求；当业务量处于低谷，自动缩容Presto Worker节点，节省运行成本。

Kubernetes部署方案的问题

传统方式部署Presto集群是以物理机的方式运行，相比之下，在Kubernetes上部署Presto集群是以容器的方式运行。尽管Kubernetes部署方式带来了很多优点，但是容器方式和物理机方式的性能差异仍然未知，下面的测试将重点对比分析两种不同部署方式的性能差异。

三、对比测试评估

测试介绍

基准测试的目的是比较物理机的 Presto 集群和部署在 Kubernetes 的 Presto 集群的性能差异。因此，测试方案分为物理机方案和Kubernetes方案。Presto 物理机集群的结构是1个Coordinator和5个Worker；Kubernetes集群是在6个node之间分配了1个Coordinator和5个Worker。在物理机集群中，用户直接通过Presto客户端向Coordinator发起查询请求，Coordinator将任务分配给Worker；如图5所示，在Kubernetes集群中，首先利用6个node部署Presto集群，Presto客户端向Kubernetes中的Coordinator发起SQL查询，Coordinator将任务分配给Worker。

图5 基准测试系统架构图

TPC-DS

沿用目前业内的普遍测评方法，本次测试采用TPC-DS 作为benchmark，它在多个普遍适用的商业场景基础上进行了建模，包括查询和数据维护等场景（详见参考[4] ），同时提供了一系列能够代表系统性能的评估指标。简单来说，TPC-DS使用了一个真实的商品零售业务场景来测试系统性能。它构建了一个大型跨国零售公司的业务模型，模型里不仅包含了多家专卖店，同时还包含了线上销售业务，以及库存管理系统和促销系统（详见参考[5] ）。由于TPC-DS是以真实场景为原型，在业内能够起到比较好的测评效果，从而成为了当前SQL引擎测试最常用的benchmark（详见参考[6] ）。

集群配置

Linux系统版本 Ubuntu20.04 Kubernetes版本 1.22.3 Docker版本 20.10 Kubernetes集群 6 node，56vCPU，224G内存 Presto集群 1 Coordinator/5 Worker，48vCPU，192G内存

四、测试结果

为了保证本次测试的结果具有更加广泛的意义，分别选取了TPC-DS不同的查询类型进行测试，包括即席查询、报告查询和迭代OLAP查询三种类型：

即席查询：这类查询主要的应用场景是通过查询来回答即时和特定的业务问题。即席查询和报告查询之间的主要区别在于系统管理员在规划即席查询时可用的预知程度有限。图表中为q19, q42, q52, q55, q63, q68, q73, q98。

报告查询：定期执行的查询，这类查询主要是定期获取到有关企业财务和运营状况。图表中为q3, q7, q27, q43, q53, q89。

迭代OLAP查询：OLAP 查询通常用于探索和分析业务数据以发现新的和有意义的关联关系和趋势。图表中为q34, q46, q59, q79, q96, q48。

图6 Kubernetes VS 物理机查询时间对比图

如图6所示，纵坐标为查询时间，单位是毫秒；横坐标为查询任务分类，图表中所显示的每个查询任务的时间实际为4次查询时间的平均值。可以看出，在不同的查询分类中，Kubernetes部署的Presto集群的平均查询时间稍微短于物理机部署，两者时间差基本保持在几秒之间，考虑到本次测试环境部署在云服务器上，不同时段使用云服务器，性能会有不同程度的偏差，几秒之间的性能波动是可以容忍的。排除本次测试使用的云服务器产生的波动，可以说明Kubernetes部署与物理机部署在性能和效率上几乎相差无几。所以针对不同类型的查询，Kubernetes部署的Presto集群相比物理机部署在查询速度上并没有损耗，性能与效率几乎没有损失。

五、结论

Kubernetes部署Presto集群的方案减轻了配置、部署、管理和监控容器化Presto应用程序的负担和复杂性。实现了Presto集群的自动配置以及工作节点自动扩展，保证了Presto Coordinator的高可用，通过与Prometheus集成可以更好地实现集群监控。在Kubernetes上部署Presto集群将这两种技术的架构优势和运维优势结合在一起，相比于传统方案，在没有性能损耗的情况下，实现了对Presto集群的动态扩展、便捷部署管理和稳定维护。

六、问题排查

在性能对比测试的过程中，并非一帆风顺，前期测试中出现了一些问题，导致Kubernetes部署的Presto集群性能无法完全释放，与物理机部署的Presto集群性能相差很多。现将测试过程中遇到的一系列问题以及相应的解决方法单开一节进行总结，方便读者在实际部署过程中遇到类似问题时可以得到借鉴与参考。

节点分配不均

Kubernetes 部署 Presto Pod（Master 或 Worker）时，如果使用了Deployment而非DaemonSet进行部署，会集中在几台物理机上（多个 Presto Pod 会同时运行在一台物理机上），有些物理机没有 Pod 运行。

图7 Presto Pod 分布情况

解决方法：出现这种现象的原因是 Presto Pod 所需的 CPU 和内存远远小于主机的上限，因此可以在一台物理机上运行多个 Presto Pod。造成的影响包括同一主机中的Pod互相抢占资源，导致效率下降，以及部分主机（没有Presto Pod）闲置，造成资源浪费。解决方案是可以通过resources requests 和 limits 合理设置 Presto Pod 运行所需的资源，使其均匀分布到各个主机上。

资源利用率过低

与物理机相比，Kubernetes 部署的 Presto 无法使用所有 CPU，只使用一个 CPU 核，每个节点的吞吐量有限，导致查询时间明显变慢。

图8 Kubernetes vs 物理机资源利用情况

解决方法：出现这种现象的原因是没有设置Presto Pod调用主机资源的最大限制。最大限制可能是默认值，无法达到主机的理想资源配额。影响是 Presto Pod 使用的资源严重受限，导致查询任务执行效率低下。解决的办法是合理设置 Presto Pod 可以调用的宿主机的最大资源限制。

针对上述两个问题，在Kubernetes中采用requests和limits两种限制类型来对资源进行容器粒度的分配。这 2 个参数是通过每个容器 containerSpec 的 resources 字段进行设置的。requests定义了对应容器需要的最小资源量。limits定义了这个容器最大可以消耗的资源上限，防止过量消耗资源导致资源短缺甚至宕机。设置为 0 表示对使用的资源不做限制。如下图所示，设置request的cpu为3，memory为6Gi，这样保证一个pod运行在一个节点上，解决了Pod在节点上分配不均的问题；设置limit的cpu为8，memory为8Gi，为节点的最大资源配置，解决了性能受限的问题，同时也避免了使用资源超过节点最大资源引起的Pod崩溃重启问题。

图9 资源配置

Presto性能如何调优

解决方法：对于Kubernetes部署集群，需要设置CpuCoreRequests、CpuCoreLimits、MemoryRequests和MemoryLimits。CpuCoreLimits 和 MemoryLimits 需要设置为宿主机配置的最大值，这样在执行任务时就不会受到限制。在此基础上，在Presto应用层面还需要设置一个合理的 query.max-memory-per-node。query.max-memory-per-node：查询可以在任何一台机器上使用的最大用户内存量，如果不进行设置，默认值为jvm * 0.1。在本次测试中，如果单个查询在节点上的使用内存最大值过小，会导致查询无法完成，建议将内存值设置足够大，以避免查询失败的情况。

七、参考

[1]
https://prestodb.io/

[2] R. Sethi et al., “Presto: SQL on Everything,” 2019 IEEE 35th International Conference on Data Engineering (ICDE), 2019, pp. 1802-1813, doi: 10.1109/ICDE.2019.00196.
[3]
https://kubernetes.io/

[4]
https://www.tpc.org/tpcds/

[5]
https://zhuanlan.zhihu.com/p/46

[6]
https://bbs.huaweicloud.com/blogs/

想要获取更多有趣有料的【活动信息】【技术文章】【大咖观点】，请关注[Alluxio智库]：

现如今，手机录屏是必不可少的能力之一。对于游戏领域作者来说，在平时直播玩游戏、制作攻略、操作集锦时，不方便切屏，这时在游戏内如果有一个录制按钮就可以随时开启，记录下每个精彩瞬间，减少后期剪辑工作量；在直播App中开启一键录屏，不光方便主播后续的账号运营与复盘，用户也能随时截取有意思的片段传播在社交媒体上；在会议App里，通常因为要点太多而来不及记录，此时录屏按钮，后续再进行会议的回顾、总结与摘要就十分便利；在上网课时，用户可以直接在课程页面录屏，方便及时学习和批注；和亲朋好友视频聊天，也可在社交App里直接录制，记录下每个相见的时光。

那么，如何在App里集成录屏能力呢？HMS Core视频编辑服务屏幕录制SDK提供全屏录制手机桌面、实时录音、后台录制等能力，集成简单，支持自定义录屏通知、多分辨率选择、多存储路径选择等，无需切屏，助力游戏、直播等App快速、轻松实现录屏功能。

功能特点

30行代码就可以简单集成；

支持自定义通知栏样式；

支持横竖屏切换；

支持多分辨率选择；

录屏结束后，支持自定义存储位置。

Demo

开发步骤

1.开发准备

详细准备步骤可参考华为开发者联盟官网。

2. 集成屏幕录制

创建屏幕录制事件监听器HVERecordListener实例，重写监听器的方法。

使用应用上下文和HVERecordListener实例，初始化HVERecord。

3.（可选）创建HVERecordConfiguration.Builder实例，设置录屏配置。

自定义录屏通知。在自定义录屏通知前，先创建用来指定通知布局的XML文件。XML文件需包含按钮等通知组件的ID。以下为指定录屏通知布局的XML文件使用示例。将自定义录屏通知的按钮对应ID命名为“btn_1”。可根据实际需要决定通知中的按钮数量。

a. 将自定义通知布局传入HVENotificationConfig的初始化方法。

b. 使用XML文件中定义的按钮、textView等组件的ID及事件。调用addClickEvent可新建事件。

c. 调用setDurationViewId设置textView ID，用来指定录屏时长显示位置。

d. 调用setCallingIntent设置录屏通知时返回的intent。在示例中，intent用来打开一个Activity，这是intent的常见用法。

e. 在HVERecord中设置通知配置。

开始录屏。

停止录屏。

了解更多详情>>

访问华为开发者联盟官网
获取开发指导文档
华为移动服务开源仓库地址：GitHub、Gitee

关注我们，第一时间了解 HMS Core 最新技术资讯~

作者：伝迹谦言夕陌临在

在人工智能广泛应用的今天，深度学习技术已经在各行各业起到了重要的作用。在计算机视觉领域，深度学习技术在大多数场景已经替代了传统视觉方法。如果说深度学习是一项重要的生产工具，那么数据就是不可或缺的生产资料，巧妇难为无米之炊，数据对于视觉模型生产起到了至关重要的作用。

EasyCV是阿里云机器学习平台团队开源的基于Pytorch的all-in-one视觉算法建模工具，搭建了丰富完善的自监督算法体系，提供了效果SOTA的视觉Transformer预训练模型，modelzoo覆盖图像自监督训练、图像分类、度量学习、物体检测、实例分割、语义分割、关键点检测等领域。

EasyCV提供了不同数据源(data_source)的抽象，支持直接读取多种开源数据集格式例如Cifar、ImageNet、CoCo等，同时也支持PAI智能标注平台Itag标注格式和Tfrecord格式数据。 TFrecord格式数据支持使用DALI进行数据处理加速，Itag标注格式图片支持通过缓存机制加速数据读取。

为了方便EasyCV的用户进行模型指标复现、在实际场景训练使用模型，EasyCV汇总了不同领域的常用数据集的介绍和下载地址，当前涵盖图像分类、目标检测、图像分割、姿态估计等方向，并针对较大且常用的数据集例如imagenet在原许可证允许的情况下提供了国内网盘地址，方便用户快速下载数据集进行论文指标对齐、模型效果对比、以及实际场景下的模型训练。

主要数据集介绍

下面按领域介绍一下EasyCV当前整理提供的数据集，其中加粗部分的数据集可以通过网盘链接下载。

datahub的使用细节可参考：https://github.com/alibaba/EasyCV/blob/master/docs/source/data_hub.md

图像分类

数据集汇总： ImageNet1K、ImageNet21K、Cifar10、Cifar100、MNIST、Fashion-MNIST、Flower102、Caltech101、Caltech256

ImageNet

官网链接：https://image-net.org/download.php

网盘链接：

ImageNet1k https://sigusoft.com/s/13pKw0bJbr-jbymQMd_YXzA 提取码：0zas

ImageNet1k TFrecord https://sigusoft.com/s/153SY2dp02vEY9K6-O5U1UA 提取码：5zdc

ImageNet21k https://sigusoft.com/s/1eJVPCfS814cDCt3-lVHgmA 提取码:kaeg

ImageNet是市场上最大、最受欢迎的开源数据集之一。ImageNet拥有超过1400万张已手动标注的图像。数据库按WordNet层次结构予以组织，对象级标注通过边界框完成。

目标检测

数据集汇总：COCO2017、VOC2007、VOC2012、LVIS、Cityscapes、Object365、CrowdHuman、OpenImages、WIDER FACE、DeepFashion、Fruit Images、Oxford-IIIT Pet、Arthropod Taxonomy Orders、African Wildlife、AI-TOD航空图、TinyPerson、WiderPerson、Caltech Pedestrian Dataset、DOTA

COCO2017

官网链接：https://cocodataset.org/#home

网盘链接：https://sigusoft.com/s/14rO11v1VAgdswRDqPVJjMA 提取码:bcmm

COCO 是一个大型图像数据集，其被用于机器视觉领域的对象检测与分割、人物关键点检测、填充分割与字幕生成。该数据集以场景理解为主，图像中的目标则通过精确的分割进行位置标定。

该数据集具有目标分割、情景感知和超像素分割三个特征，其包含 33 万张图像、150 万目标实例、80 个目标类、91 个物品类以及 25 万关键点人物。

LVIS

官网链接：https://www.lvisdataset.org/dataset

网盘链接：https://sigusoft.com/s/1UntujlgDMuVBIjhoAc_lSA 提取码:8ief

大规模的词汇实例分割数据集(Large Vocabulary Instance Segmentation,LVIS )，包含了164k图像，并针对超过1000类物体进行了约200万个高质量的实例分割标注。由于数据集中包含自然图像中的物体分布天然具有长尾属性。

Objects365

官网链接：https://www.objects365.org/overview.html

该数据集总共包含63万张图像，覆盖365个类别，高达1000万框数，具有规模大、质量高、泛化能力强的特点，远超Pascal VOC、COCO等传统数据集。

分割

数据集汇总：VOC2007、VOC2012、Pascal Context、COCO-Stuff 10K、Cityscapes、ADE20K

Cityscapes

官网链接：https://www.cityscapes-dataset.com/

该数据集拍摄了国外多个城市街道场景图片，构建数据集，其分为三个部分，包括训练集，验证集和测试集，一共 19 个类别。

ADE20K

官网链接：http://groups.csail.mit.edu/vision/datasets/ADE20K/

网盘链接：https://sigusoft.com/s/1ZuAuZheHHSDNRRdaI4wQrQ 提取码:dqim

ADE20K涵盖了场景、对象、对象部分的各种注释，在某些情况下甚至是部分的部分。有25k张复杂日常场景的图像，其中包含自然空间环境中的各种对象。每个图像平均有19.5个实例和10.5个对象类。

姿态估计

数据集汇总： COCO2017、MPII、CrowdPose、OCHuman

MPII

官网链接：http://human-pose.mpi-inf.mpg.de/

网盘链接：https://sigusoft.com/s/1uscGGPlUBirulSSgb10Pfw 提取码:w6af

MPII人体姿态数据集是评价关节人体姿态估计的最先进的基准。该数据集包括大约25K张图片，其中包括超过40K名带有标注身体关节的人。这些图像是根据人类日常活动的既定分类系统收集的。总体而言，数据集涵盖410项人类活动，每张图像都有活动标签。每张图片都是从YouTube视频中提取的，并提供了前后未注释的帧。

EasyCV数据集接口使用示例

设计思路

EasyCV抽象了data_source来封装不同格式的数据集，data_source输出图像相关的信息，然后通过指定dataset_type来创建不同任务类型的数据集对象进行训练。其中data_source类型包括ClsSourceImageList、DetSourceCoco、DetSourceVOC、PoseTopDownSourceCoco和SegSourceRaw等等，dataset_type类型包括RawDataset、ClsDataset、DetDataset和SegDataset等等。

以ImageNet数据集为例：

其他和Imagenet格式相似的数据集，都可以通过替换data_train_list、data_train_root、data_test_list和data_test_root进行配置使用，详细的config配置方式可参考https://github.com/alibaba/EasyCV/blob/master/configs/classification/imagenet/resnet/resnet50_b32x8_100e_jpg.py。

项目开源地址：https://github.com/alibaba/EasyCV

EasyCV往期分享

EasyCV带你复现更好更快的自监督算法-FastConvMAE
YOLOX-PAI:加速YOLOX,比YOLOV6更快更强
基于EasyCV复现DETR和DAB-DETR，Object Query的正确打开方式
基于EasyCV复现ViTDet：单层特征超越FPN
MAE自监督算法介绍和基于EasyCV的复现
EasyCV开源｜开箱即用的视觉自监督+Transformer算法库

本文介绍了几个常见的匹配算法，通过算法过程和算法分析介绍了各个算法的优缺点和使用场景，并为后续的搜索文章做个铺垫；读者可以通过比较几种算法的差异，进一步了解匹配算法演进过程以及解决问题的场景；KMP算法和Double-Array TireTree是其中算法思想的集大成者，希望读者重点关注。

1 前言

上文探究了数据结构和算法的一些基础和部分线性数据结构和部分简单非线性数据结构，本文我们来一起探究图论，以及一些字符串模式匹配的高级数据结构和算法。【搜索中常见数据结构与算法探究（一）】（https://developer.jdcloud.com/article/2153）

搜索作为企业级系统的重要组成部分，越来越发挥着重要的作用，ES已经成为每个互联网企业必备的工具集。而作为搜索的基础部分，文本匹配的重要性不言而喻。文本匹配不仅为精确搜索提供了方法，而且为模糊匹配提供了算法依据。比如相似度算法，最大搜索长度算法都是在匹配算法的基础上进行了变种和改良。

2 图论基础

2.1 图的基本概念

以我们物流的抽象模型为例：每个配送中心是一个顶点，由两个顶点表示的配送中心间如果存在一条干线运输线，那么这两个顶点就用一条边连接。边可以由一个权，表示时间、距离和运输的成本。我们愿意迅速确定任何两个配送中心的最佳线路。这里的“最佳”可以是指最少边数的路径，也即经过的配送中心最少；也可以是对一种或所有权总量度所算出的最佳者。

2.2 图的表示方法

我们考虑实用情况，以有向图为例：
我们假设可以以省会城市开始对顶点编号。如下图

1）邻接矩阵
表示图的一种简单的方法是使用一个二维数据，称为邻接矩阵表示法。有一个二维数组A，对于每条边（u，v），置A[u][v]等于true；否则数组素就是false。如果边有一个权，那么可以置A[u][v]等于该权，而使用很大或者很小的权作为标记表示不存在的边。虽然这种表示方法的优点是简单，但是，它的空间复杂度为θ（|V|^2）,如果图的边不是很多（稀疏的），那么这种表示的代价就太大了。代码如下：

2）邻接表
如果图是稀疏的，那么更好的解决办法是使用邻接表。

2.3 图的搜索算法

从图的某个订单出发，访问途中的所有顶点，并且一个顶点只能被访问一次。图的搜索（遍历）算法常见的有两种，如下：

深度优先搜索算法（DFS）
广度优先搜索算法（BFS）

3 数据结构与算法

3.1 BF（Brute Force）算法

3.1.1 算法介绍

BF（Brute Force）算法也可以叫暴力匹配算法或者朴素匹配算法。

3.1.2 算法过程

在讲解算法之前，我们先定义两个概念，方便后面讲解。他们分别是主串（S）和模式串（P）。比如说要在字符串A中查找字符串B，那么A就是主串，B就是模式串。我们把主串的长度记作n，模式串的长度记作m，并且n>m。算法过程如下图：

3.1.3 算法分析

BF算法从很“暴力”，当然也就比较简单，好懂，但是响应的性能也不高极端情况下时间复杂度函数为O(m*n)。
尽管理论上BF算法的时间复杂度很高，但在实际的开发中，它却是一个比较常用的字符串匹配算法，主要原因有以下两点：

朴素字符串匹配算法思想简单，代码实现也非常简单，不容易出错，容易调试和修改。
在实际的软件开发中，模式串和主串的长度都不会太长，大部分情况下，算法执行的效率都不会太低。

3.2 RK（Rabin-Karp）算法

3.2.1 算法介绍

RK算法全程叫Rabin-Karp算法，是有它的两位发明者Rabin和Karp的名字来命名，这个算法理解并不难，他其实是BF算法的升级版。

3.2.2 算法过程

3.2.3 算法分析

在BF算法中当字符串不匹配时，需要比对每一个字符，如果不能匹配则重新调整I，J的值重新比对每一个字符，RK的思路是将模式串进行哈希算法得到s=hash(P)，然后将主串分割成n-m+1个子串，分别对其进行hash算法，然后逐个和s进行比对，减少逐个字符串比对的次数。其中hash函数的具体实现可自行选择。
整个RK算法包含两部分：

计算模式串哈希和子串的哈希；
模式串哈希和子串哈希的比较；

第一部分的只需要扫描一遍主串就能计算出所有子串的哈希值，这部分的时间复杂度是O(n)。模式串哈希值与每个子串哈希之间的比较的时间复杂度是O(1)，总共需要比对n-m+1次，所以这部分的时间复杂度为O(n)。所以RK算法的整体时间复杂度为O(n)。

3.3 KMP算法

3.3.1 算法介绍

KMP算法是一种线性时间复杂度的字符串匹配算法，它是对BF(Brute-Force)算法的改进。KMP算法是由D.E.Knuth与V.R.Partt和J.H.Morris一起发现的，因此人们称它为Knuth-Morris-Pratt算法，简称KMP算法。

前面介绍了BF算法，缺点就是时间消耗很大，KMP算法的主要思想就是：在匹配过程中发生匹配失败时，并不是简单的将模式串P的下标J重新置为0，而是根据一些匹配过程中得到的信息跳过不必要的匹配，从而达到一个较高的匹配效率。

3.3.2 算法过程

在介绍KMP算法之前，首先介绍几个字符串的概念：

前缀：不包含最后一个字符的所有以第一个字符开头的连续子串；
后缀：不包含第一个字符的所有以最后一个字符结尾的连续子串；
最大公共前后缀：前缀集合与后缀集合中长度最大的子串；

例如字符串abcabc
前缀集合是a，ab，abc，abca，abcab
后缀集合为bcabc，cabc，abc，bc，c
最大公共前后缀为abc

KMP算法的过程如下图：

那么为什么KMP算法会知道在匹配失败时下标J回溯的那个位置呢？其实KMP算法在匹配的过程中将维护一些信息来帮助跳过不必要的匹配，这个信息就是KMP算法的重点，next数组也叫做fail数据或者前缀数据。下面我们来分析next数组的由来

对于模式串P的每个素P[j]，都存在一个实数k，使得模式串P开头的k个字符(P[0]P[1]…P[k-1])依次于P[j]前面的k(P[j-k]P[j-k+1]…P[j-1])个字符相同。如果这样的k有多个，则取最大的一个。模式串P中的每个位置j的字符都存在这样的信息，采用next数组表示，即next[j]=MAX{k}。

从上述定义中可看到next(j)的逻辑意义就是求P[0]P[1]…P[j-1]的最大公共前后缀长度。代码如下：

下面分析next的求解过程：

1）特殊情况
当j的值为0或者1的时候，它们的k值都为0，即next(0) = 0 、next(1) = 0。为了后面k值计算的方便，我们将next(0)的值设置为-1。
2）当P[j]==P[k]的情况
当P[j]==P[k]时，必然有P[0]…P[k-1]==P[j-k]…P[j-1]，因此有P[0]…P[k]==P[j-k]…P[j]，这样就有next(j+1)=k+1。
3）当P[j]!=P[k]的情况
当P[j]!=P[k]时，必然后next(j)=k，并且next(j+1)<k；也就是说P[0]…P[k-1]=P[j-k]…P[j-1]，因此此时k值需要向左移动重新进行匹配，next数组的作用就是在匹配失败时进行下标左移，所以k=next(k)进行下一轮循环。
4）算法优化
上述算法有一个小问题就是当P[k]匹配失败后会跳转到next(k)继续进行匹配，但是此时有可能P[k]=P[next(k)]，此时匹配肯定是失败的所以对上述代码进行改进如下：

3.3.3 算法分析

KMP算法通过消除主串指针的回溯提高匹配的效率，整个算法分为两部分，next数据的求解，以及字符串匹配，从上一节的分析可知求解next数组的时间复杂度为O(m)，匹配算法的时间复杂度为O(n)，整体的时间复杂度为O(m+n)。KMP算法不是最快匹配算法，却是名气最大的，使用的范围也非常广。

3.4 BM算法

3.4.1 算法介绍

Boyer-Moore字符串搜索算法是一种非常高效的字符串搜索算法。它由Bob Boyer和J Strother Moore发明，有实验统计它的性能是KMP算法的3-4倍。

3.4.2 算法过程

前面介绍的BF，KMP的算法的匹配过程虽然模式串的回溯过程不同，但是相同点都是从左往右逐个字符进行匹配，而BM算法则是采用的从右向左进行匹配，借助坏字符规则（SKip(j)）和好后缀（Shift(j)）规则，能够进行快速匹配。其中坏字符和好后缀示意如下图

1）坏字符规则：在BM算法从右向左扫描的过程中，若发现某个字符S[i]不匹配时，则按照如下两种情况进行处理：

如果字符S[i]在模式串P中没有出现，那么从字符S[i]开始的m个文本显然是不可能和P匹配成功，直接全部跳过该区域。
如果字符S[i]在模式串P中出现，则以该字符进行对齐。

2）好后缀规则：在BM算法中，若发现某个字符不匹配的同时，已有部分字符匹配成功，则按照如下两种情况进行处理：

如果已经匹配的子串在模式串P中出现过，且子串的前一个字符和P[j]不相同，则将模式串移动到首次出现子串的前一个位置。
如果已经匹配的子串在模式串P中没有出现过，则找到已经匹配的子串最大前缀，并移动模式串P到最大前缀的前一个字符。

BM算法过程如下：

3.4.3 算法分析

在BM算法中，如果匹配失败则取SKip(j)与Shift(j)中的较大者作为跳跃的距离。BM算法预处理阶段的复杂度为O(m+n)，搜索阶段的最好的时间复杂度为O(n/m)，最坏的时间复杂为为O(n*m)。由于BM算法采用的是后缀匹配算法，并且通过坏字符和好后缀共同作用下，可以跳过不必要的一些字符，具体Shift(j)的求解过程可参看KMP算法的next()函数过程。

3.5 TireTree

3.5.1 算法介绍

在《搜索中常见的数据结构与算法探究（一）》中，我们介绍过一种树状的数据结构叫做HashTree，本章介绍的TireTree就是HashTree的一个变种。TireTree又叫做字典树或者前缀树，典型的应用是用于统计和排序大量的字符串，所以经常被搜索系统用于文本的统计或搜索。

TireTree的核心思想是空间换时间。TrieTree是一种高效的索引方法，它实际上是一种确定有限自动机(DFA)，利用字符串的公共前缀来降低查询时间的开销以达到提高查询效率的目的，非常适合多模式匹配。TireTree有以下基本性质：

根节点不包含字符，除根节点外每个节点都包含一个字符。
从根节点到某一个节点，路径上经过的字符连接起来，为该节点对应的字符串。
每个节点对应的所有子节点包含的字符都不相同。

3.5.2 算法过程

TireTree构建与查询
我们以《搜索中常见的数据结构与算法探究（一）》案例二中提到的字谜单词为例，共包含this、two、fat和that四个单词，我们来探究一下TireTree的构建过程如下图：

上述过程描述了that，two，fat，that四个单词的插入TireTree的过程，其中黄色的节点代表有单词存在。由于TireTree的构建的过程是树的遍历，所以查询过程和创建过程可以视为一个过程。

3.5.3 算法分析

TireTree由于本身的特性非常适合前缀查找个普通查找，并且查询的时间复杂度为O(log(n))，和hash比较在一些场景下性能要优于甚至取代hash，例如说前缀查询（hash不支持前缀查询）。

虽然TireTree的查询速度会有一定的提升但是缺不支持后缀查询，并且TireTree对空间利用率不高，且对中文的支持有限。

3.6 AC自动机

3.6.1 算法介绍

AC自动机（Aho-Corasick automation）该算法在1975年产生于贝尔实验室，是著名的多模匹配算法之一。要搞懂AC自动机，先得有TireTree和KMP模式匹配算法的基础知识，上述章节有TireTree和KMP算法的详细介绍。

3.6.2 算法过程

AC自动机的构建过程需要如下步骤：

TireTree的构建，请参看TireTree章节
fail指针的构建 – 使当前字符失配时跳转到具有最长公共前后缀的字符继续匹配。如同 KMP算法一样， AC自动机在匹配时如果当前字符匹配失败，那么利用fail指针进行跳转。由此可知如果跳转，跳转后的串的前缀，必为跳转前的模式串的后缀并且跳转的新位置的深度一定小于跳之前的节点。fail指针的求解过程可是完全参照KMP算法的next指针求解过程，此处不再赘述。
AC自动机查找 – 查找过程和TireTree相同，只是在查找失败的时候感觉fail指针跳转到指定的位置继续进行匹配。

3.6.3 算法分析

AC自动机利用fail指针阻止了模式串匹配阶段的回溯，将时间复杂度优化到了O(n)。

3.7 Double-Array-TireTree

3.7.1 算法介绍

前面提到过TireTree虽然很完美，但是空间利用率很低，虽然可以通过动态分配数组来解决这个问题。为了解决这个问题我们引入Double-Array-TireTree，顾名思义Double-Array-TireTree就是TireTree压缩到两个一维数组BASE和CHECK来表示整个树。Double-Array-TireTree拥有TireTree的所有优点，而且刻服了TireTree浪费空间的不足，使其应用范围更加广泛，例如词法分析器，图书搜索，拼写检查，常用单词过滤器，自然语言处理中的字典构建等等。

3.7.2 算法过程

在介绍算法之前，我们提前简单介绍一个概念DFA（下一篇详细介绍）。DFA（Deterministic Finite State）有限自动机，通俗来讲DFA是指给定一个状态和一个输入变量，它能转到的下一个状态也就确定下来，同时状态是有限的。

Double-Array-TireTree构建
Double-Array-TireTree终究是一个树结构，树结构的两个重要的要素便是前驱和后继，把树压缩在双数组中，只需要保持能查到每个节点的前驱和后继。首先要介绍几个重要的概念：

STATE：状态，实际是在数组中的下标
CODE：状态转移值，实际为转移字符的值
BASE：标识后继节点的基地址数组
CHECK：标识前驱节点的地址

从上面的概念的可以理解如下规则，假设一个输入的字符为c，状态从s转移到t

state[t] = base[state[s]] + code[c]
check[state[t]] = state[s]

构建的过程大概也分为两种：

动态输入词语，动态构建双数组
已知所有词语，静态构建双数组

我们以静态构建过为核心，我们以《搜索中常见的数据结构与算法探究（一）》案例二中提到的字谜单词为例，共包含this、two、fat和that四个单词为例，其中涉及都的字符集{a,f,h,i,o,s,t,w}共8个字符，为了后续描述方便，我们对这个八个字符进行编码，分别是a-1,f-2,h-3,i-4,o-5,s-6,t-7,w-8

构建this，如下图

构建two，如下图

构建fat，如下图

构建that，如下图

Double-Array-TireTree查询
验证this是否在范围内如下过程
1）state[t] = base[state[null]]+code[t]= 0 + 7=7
check[7]=state[null]=0通过
2）state[th] = base[state[t]]+code[h]=base[7]+3 =2+3=5
check[5]= state[t] = 7通过
3）state[tha] = base[state[th]]+ code[a]=base[5]+1=5+1=6
check[6]=state[th]=5通过
4）state[that] = base[state[tha]]+t = base[6]+7=11
check[11]=state[tha]=6通过

3.7.3 算法分析

通过两个数据base和check将TireTree的数据压缩到两个数组中，既保留了TireTree的搜索的高效，又充分利用了存储空间。

3.8 其他数据结构

鉴于篇幅有限，DFA，FSA以及FST将在下一篇文章中再来一起讨论，敬请期待！

4 参考资料

参考书籍
《数据结构与算法分析：java语言描述》
《自动机理论、语言和计算导论》

本篇文章对本系列的上一篇文章的常见数据结构做了补充，介绍了非线性数据结构的最后一种，图数据结构作为基本数据结构最复杂的一种，在多种企业级应用中都有使用，如网络拓扑，流程引擎，流程编排；另外本文重点介绍了几种常见的匹配算法，以及算法的演进过程和使用场景，为下一篇的主题，也是本系列的重点探究的目标，“搜索”做一个铺垫，敬请期待！

作者：潘坤郑冰曹东杰

嵌入式分析是使任何应用程序或用户更容易获得数据分析和商业智能的技术。商业智能是通过分析业务数据辅助决策获取数据背后的 0信息。商业智能软件和技术包含了报表查询，OLAP，数据挖掘及高级数据分析，最终用户自助分析及仪表板监控舱等功能。嵌入式商业智能是一种技术能力，囊括了商业智能的功能和特征，并且成为了业务系统的一个重要的构成。

嵌入式商业智能发展背景

“商业智能”一词最早出现是在Richard Millar Devens，1865的Cyclopaedia of Commercial and Business Anecdotes一书中，用它来描述“银行家亨利·弗兰西斯爵士的成功方式”。

起源

1958年IBM的计算机科学家Hans Peter Luhn 撰写的一片文章《A Business Intelligence System》中，开始描述BI的价值和潜力，今天他被公认为“商业智能之父”。

演变：20世纪80年代末 1956年，IBM发明的硬盘彻底改变了数据存储，越来越多的数据被创建和存储。也就在这个阶段产生了第一个数据库管理系统，统称为决策支持系统（DSS）。 20世纪70年代，出现了几家BI厂商。 1988年，在罗马举办的数据分析联盟会议是一个商业智能的里程碑。

转折点：20世纪80年代-90年代 1988年会议后，商业智能就开始向现代化演进。1989年，分析师Howard Dresner再次将“商业智能”带入大家的视野，他将商业智能作为涵盖数据存储和数据分析的统称，避免了繁琐的名称，如DSS或EIS等。数据仓库技术的发展大大推动了商业智能的发展，传统存储在各个地方的业务数据开始集中在一起。应运而生的技术还包括ETL（数据抽取、转换、加载）和OLAP（联机分析处理），该阶段被称为-商业智能1.0。

商业智能1.0 20世纪90年代末和2000年初，数十家BI厂商进入市场，在此期间，BI包含两个基本功能：生成数据和报告，并以可视化的方式展示。商业智能1.0面临的两大问题：复杂性和时效性。当时存在两个主要难点： 1、大多数人无法自助使用，强依赖IT 2、由于数据沉默，制定和提交报告给决策者需要更多的时间

商业智能2.0 二十一世纪是一个明显的转折点，随着技术的发展，解决了复杂性和时效性的问题。 BI2.0的实时处理技术允许企业依据最新的信息作出决策。互联网社交的发展，也让商业智能广泛的传播，越来越多的人知道并理解商业智能。 BI 已经不再是一个锦上添花的软件，它代表的是一种企业竞争力，只是这种竞争力还没有被更多企业感知。

现代商业智能3.0

实现自助式和增强数据可视化，结合数字孪生，3D建模，GIS 地图实现数据可视化，并结合当下最新发展的AI技术进行AI交互挖掘很深层次信息。是BI的发展领域和现代化特征。随着云计算、SaaS（软件即服务）、大数据的发展和成熟，商业智能开始被更多的企业使用，高度易用的设计让业务人员也可以使用，无需IT的支持。

2022 年及以后的嵌入式商业智能 (BI) 采用趋势

所有公司都在努力建立一种数据驱动的文化，预计到 2025 年大多数企业的数据量将达到 175 泽字节。如此大量的数据，意味着我们需要更加强有力的手段去组织管理。为了挖掘这些数据的价值，公司必须收集、组织、分析、整合和分发这些数据。这就是业务分析的用武之地，也是为什么越来越多的公司采用它并利用 BI 来发挥自己的优势。让我们看一下 2022 及未来几年的嵌入式BI 发展趋势

BI 市场规模统计 BI 市场由其他相互交织的行业发展推动，特别是在分析、大数据和人工智能市场。美国仍然是最赚钱的市场，但中国的增长率最高。

2021 年，BI 软件市场规模在全球范围内的收入为 228 亿美。预计 2027 年将增长 44%，收入预计将达到 328 亿美。到 2027 年，中国的增长率最高达到 119.8%，其次是美国（37%），紧随其后的是德国和日36.7%，然后是英国（31.5%）。

BI 投资 BI 是组织技术堆栈中较为成熟的业务系统之一。越来越多的员工正在使用 BI，与此同时，越来越多的公司正计划雇用全职 IT 人员来管理商业智能计划。2021 年，BI 在 B2B 技术买家 (38%) 的支出中排名第四。网络和视频会议以 64% 位居榜首，其次是在线协作和项目管理以及营销，分别占 53% 和 41%。这些数字可以在很大程度上归因于疫情居家办公影响的。尽管目前的员工可以访问和使用 BI，但到 2021 年，73% 的 CIO 正在考虑为分析平台招聘全职 IT 员工，这在 CIO 全职技术职位计划中排名第二。

虽然统计数据显示公司计划雇用 IT 员工来管理 BI，但自助式 BI 解决方案对用户非常友好。授权员工使用 BI 可以带来更快的洞察力、增强的团队协作、员工的整体满意度等。即将到来的趋势确实表明，未来几年每位员工的 BI 支出预计将增加 30%：

2022 年 6.96 美
2023 年 7.35 美
2024 年 7.76 美
2025 年 8.17 美
2026 年 8.57 美
2027 年 8.96 美

BI 软件的成本差异很大。使用嵌入式商业智能，可节省采购成本及维护成本，可扩展许可模式为您的业务提供了增长空间，而无需增加许可费用。

BI 感知到的重要性

许多行业（即商业、金融和保险）多年来一直在使用 BI，并且已经部署了成熟的 BI 集成。不过，展望未来，更多利基行业开始看到实施 BI 软件的必要性和好处。由于行业需求和流程千差万别，因此在搜索 BI 系统时，必须找到能够支持所有业务类型的嵌入式 BI 解决方案。嵌入式商业智能需包括仪表板和报告，满足各行各业的特定需求。尽管在过去三年中感知到的重要性有所下降，但对于采用 BI 解决方案而言仍然很重要。

行业BI BI 被认为是满足许多行业业务目标的必备条件。但是，某些行业比其他行业更重视 BI。按行业划分，云 BI 作为一个关键且非常重要的系统，在以下方面最为明显：

技术 (77%)
教育 (76%)
医疗保健 (61%)
商业服务 (50%)
金融服务 (50%)
零售 (38%)

另一方面，政府（42%）和制造业（28%）在采用率方面得分最低。这些数字可能是由于各种原因造成的，但政府的一个明显原因是数据的敏感性。在搜索 BI 系统时，找到具有可扩展安全性的系统至关重要，这样IT 团队就可以轻松管理角色、权限、许可证、用户和安全性。

移动BI变成企业产品选型的加分点，随时随地的洞察数据变得重要。新一代的商业智能产品涌现，传统商业智能被迫淘汰或者转型“敏捷BI”。

总结

本文从嵌入式BI的发展历程讲起，为大家详细介绍了嵌入式BI出现的背景、发展现状、市场应用与不同行业中BI的重要性，大家如果想了解针对不同行业的BI在线demo体验一下：

https://www.grapecity.com.cn/solutions/wyn/demo

带上您的潜水服、调节器、潜水电脑表和水下摄像机，跟随我们在 NGINX Sprint China 2022 年度线上会议期间，一起深潜到 NGINX 的斑斓世界吧！

NGINX Sprint China 2022 是一年一度 NGINX Sprint 全球线上大会的本地分支版本，也是 F5 NGINX 中国区全年最盛大的线上旗舰会议。

本次会议预计将于 2022 年 12 月初举办，我们将分享最热门的行业趋势以及 NGINX 的最新动态，并且探讨与 NGINX 以及更多热门开源项目相关的行业案例和最佳实践。NGINX 官方团队也会借此机会与社区进行深入交流，期待听到您的声音和反馈。

我们非常希望有更多的 NGINX 用户参与到会议中来——您可以在 20 分钟的演讲时间内分享任何与 NGINX 相关的内容，并与社区中的开发者和技术爱好者共同探讨交流。

议题方向包括但不限于：

使用经验及用户案例
技术干货及深入解析
实践分享及运维调优
行业趋势及周边生态

参与到本次活动，意味着您将参与到一个观看量将过万的线上会议。2022 年 10 月 30 日前提交您的议题，一旦内容入选，您还将获得 NGINX 独家定制的精美大礼一份！

立即通过扫描下方二维码提交议题

有任何问题或是建议，请在本文下方回复评论，或通过 contactme_nginxapac@f5.com 与我们取得联系。

我们期待着与您相约 NGINX Sprint China 2022 线上大会，一同畅游 NGINX 的斑斓世界！

原文作者：Amir Rawdat of F5

原文链接：更新：为NGINX配置免费的Let’s Encrypt SSL/TLS 证书

转载来源：NGINX 官方网站

众所周知，网站的 SSL/TLS 加密会为您的用户带来更靠前的搜索排名和更出色的安全性。但目前有许多障碍阻碍了网站所有者采用 SSL。

其中两个最大障碍是证书获取成本高昂和所涉人工流程繁琐。而现在，有了 Let’s Encrypt，这些都不再是问题。Let’s Encrypt 支持所有人免费使用 SSL/TLS 加密。

Let’s Encrypt 是一家免费、开放、自动化的证书颁发机构 (CA)。是的，没错Let’s Encrypt颁发的 SSL/TLS 证书是免费的。现今的大多数浏览器都信任 Let’s Encrypt 颁发的证书，包括旧版浏览器，例如 Windows XP SP3 上的 Internet Explorer。此外，Let’s Encrypt 实现了证书颁发和更新的全自动化。

NGINX 对于成为 Let’s Encrypt 的赞助者之一感到非常骄傲。

本文介绍了如何使用 Let’s Encrypt 客户端生成证书，以及如何自动配置 NGINX 开源版和 NGINX Plus 以使用这些证书。

Let’s Encrypt 的工作原理

在颁发证书之前，Let’s Encrypt 会验证域名的所有权。在您的主机上运行的 Let’s Encrypt 客户端将创建一个临时文件（一个令牌），其中包含所需的信息。然后，Let’s Encrypt 验证服务器会发出 HTTP 请求以检索文件并验证令牌，从而验证您域名的 DNS 记录是否解析到运行 Let’s Encrypt 客户端的服务器。

准备工作

在开始使用 Let’s Encrypt 之前，您需要：

安装NGINX开源版或NGINX Plus。
如果没有注册域名，可以在域名注册商处申请。
创建一条DNS记录，将您的域名和服务器的IP地址关联。

_现在可以使用NGINX版本或NGINX_开源设置设置（为了便于阅读NGINX Plus，您可以方便地使用密码统称为）。

注：我们在 Ubuntu 16.04 (Xenial) 上测试了本文所述的程序。

1、下载 Let’s Encrypt 客户端

首先，下载 Let’s Encrypt 客户端。

1. 上面那个，我们在 Ubuntu6.04 测试相关指令，下面是在平台上运行的相应命令：

使用 Ubuntu 18.04 和更高版本，替代 Python 3 版本：

2、设置NGINX

可以自动完成 NGINX 的 SSL/TLS 配置修改。它会在您的 N 配置中查找并包含指令（包含您的委托请求的域名）在我们的示例中，域名为www.example.com。

您在全新的 NGINX 安装上进行设置，请使用文本编辑器在/etc/nginx/conf.d目录中创建一个名为域名的.conf文件（在我们的示例中为www.example。 com.conf）。
使用指令指定您的域名（如果域名有变体的话请指定）：
保存文件，然后运行以下命令来验证配置的语法并重新启动 NGINX：

3、获取 SSL/TLS 证书

certbot 的 NGINX 插件负责重新配置 NGINX，并在必要时重新加载其配置。

运行以下命令，使用 NGINX 插件生成证书：
根据 certbot 的提示配置 HTTPS 设置，包括输入您的电子邮件地址并同意 Let’s Encrypt 服务条款。

证书生成后，NGINX 重新加载新设置。certbot 生成一条消息，显示证书成功生成，并指示证书在服务器上的位置。
注： Encrypt 90 节后让在证书中（在本例中，自动时间为 2017 年 12 月 12 日）。让更新证书的信息，请参阅“更新加密证书”。

如果查看域名.conf，您会发现已经进行了修改：

4、自动更新 Let’s Encrypt 证书

Let’s Encrypt 证书 90 天后将执行更新操作文件。我们建议您自动在此处，我们将一个添加到现有的cron中，以这一点。

打开crontab文件。
添加示例，命令设置为每天运行中，我们每天运行该命令。该命令检查服务器上的证书未来 30 是否正常使用本协议，如果是，则不要更新指示建议生成输出。
保存并文件。所有已安装的证书将自动更新并重新加载。

总结

那么，我们用SSL/来加密SSL/来注册域名证书，然后配置加密证书，更新更新更新。借助GINX和NGINX Encrypt Encrypt’s’s，您可以在加密证书中轻松安装Nx一个安全的网站。

业务场景

案例一

张小明同学希望在自己的运营平台上接入BI的可视化分析能力，能够在运营平台上通过、拖拽等页面交互方式便可以快速生成可视化图形，获取数据洞见。

经过调研后决定集成Datawind平台，将自己的数据源通过数据准备导入到Datawind中作为数据集，并在运营平台上嵌入该数据集的可视化查询页面。之后可以直接在运营平台上直接做数据拖拽分析，极大地提高了数据分析效率。

案例二

王小红同学想要建立运营数据看板并分享给不同的地区经理，希望不同的地区经理只看到本地区数据。并且这些数据看板可以集成到地区经理最常用的CRM系统之中。

小红发现Datawind能够满足制作数据看板的诉求，并且Datawind的行权限、自定义筛选器也能满足平台对数据权限控制的需要，也可以快速集成到自己的CRM系统中，最后决定使用嵌入Datawind仪表盘的方式搭建运营数据看板。

案例三

李小华同学需要对海量的商品交易记录进行查询。他希望使用这样一款查询工具：具备对海量明细数据的查询能力、支持丰富的筛选操作、能够配置表格和单格样式、必要时可以对表格列的字段公式进行改写。确认Datawind满足需要后，李小华在Datawind上建立了明细数据报表并将其嵌入到商品交易管理系统中，让每个相关运营同学都能快速查询获得想要的数据结果。

Iframe集成方案

为了最方便快捷实现集成，可以通过Iframe的方式对接，操作方式如下。

概述

该操作需要开发人员完成，主要操作步骤如下所示：

Step 1. 获得目标仪表盘/图表的URL链接

Step 2. 链接修改

Step 3. 生成代码

该开发人员建议在需要操作的项目中赋予项目管理员权限，完成后再根据实际情况赋予权限。

Step 1.获得目标仪表盘/图表的URL链接

如下两种方式均可获得目标仪表盘/图表/大屏的链接，得到的结果是一致的
仪表盘移动端则只能按照第二种方式获得

1. 直接在产品中获得

（1）仪表盘/图表

图表

进入到仪表盘预览状态

需嵌入图表右侧，选择「嵌出图表」

显示「复制成功」，之后可以鼠标右键复制，或者键盘crtl+V即可

仪表盘

进入到仪表盘预览状态

需嵌入图表右侧，选择「嵌出仪表盘」

显示「复制成功」，之后可以鼠标右键复制，或者键盘crtl+V即可。

（2）大屏

如图在列表页选择查看，打开之后复制浏览器URL即可

2. 自行拼接

选择自行拼接，则按照如下方式进行，划下划线内容是变量，在如下参数详解要解释的，其他为固定内容

仪表盘

$HOST/#/external/dashboard/$DASHBOARD_ID?appId=$APP_ID&inline=true

比如：

移动端仪表盘

比如：

注意：移动端链接只能移动端设备访问，如果该链接在PC端打开，则默认跳转为PC端链接。

图表

$HOST/#/external/dashboard/$DASHBOARD_ID/$REPORT_ID?appId=$APP_ID&inline=true

比如：

可视化查询

$HOST/#/dataQuery?appId=$APP_ID&inline=true

比如：

大屏

$HOST/vScreen/preview?appId=$APP_ID&id=$VSCREEN_ID&resizeMode=auto

比如：

参数详解

$HOST

SaaS环境设置为https://console.volcengine.com/bi
私有化部署环境替换为产品部署的域名

$HOST-h5

移动端的域名

SaaS环境设置为https://console.volcengine.com/bi-h5
私有化部署环境替换为产品移动端部署的域名

$APP_ID

项目id。在项目下任意打开地址均可获得，如图所示，任意打开一个项目下的链接，URL如下所示，app_Id值为

$DASHBOARD_ID

在列表页面打开需要外嵌的仪表盘，获得浏览器的URL链接如下，则dashboardId值为47610

$REPORT_ID
图表id，标识唯一的图表。可视化查询页面URL的 rid 表示图表id。在如下可视化查询链接中，reportId值为

$VSCREEN_ID
大屏id。在如下仪表盘链接中，vscreenId值为4750

Step2.加入特性，修改链接

在iframe的url中传入参数来配置通用特性，以下是该特性的解释说明，可以根据实际情况选择需要的特性。

特性说明

Step3.生成代码

根据上述获得的信息来拼接代码，比如以获得的仪表盘链接举例：

1. 生成HTML代码

比如如下代码指的是隐藏仪表盘header

2. 使用实例

如果在使用 React 框架，参考如下实例
在iframe的url中传入参数来配置通用特性。的类型为后的特性配置对象。可以参考如下的iframe 嵌入代码隐藏仪表盘header

立即跳转
火山引擎
智能数据洞察
DataWind
官网了解详情，并参与30天免费试用！

关注公众号

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

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

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

a.out 是一种文件格式，在旧版本的类 Unix 计算机操作系统中用于可执行文件、目标代码，以及在后来的系统中用于共享库，a.out 是 “assembler output” 的缩写。

Linux 其实只使用 a.out 到 1.2 版本（1995 年），而对 ELF 的支持则是最早于 1.1.52 内核中加入（实验性支持）。

目前大多数类 Unix 系统都已改用 ELF 格式，不再采用 a.out 格式，在 2019 年的时候，Linux 内核弃用了对 a.out 支持。不过需要注意的是，当用户没有指定输出名称时，”a.out” 仍然是某些编译器和链接器创建的可执行文件的默认输出文件名，但这个文件仅有文件名为 “a.out”，实际创建的文件并不是 a.out 格式（约定俗成的命名习惯）。

在弃用这么久之后，从今年年初开始，Linux 内核开发者就开始着手删除 a.out 相关的代码，现在，随着 Linux 6.1 的到来，之前没有完全清楚的 a.out 代码则是彻底被删除了（删除了大约 500 行相关的 a.out 代码）。

这次代码清理也实现此前承诺的在 2022 年从 Linux 内核中删除所有 a.out 相关内容的目标。

JetBrains 宣布首次公共预览 Fleet，所有人都可以使用。Fleet 是由 JetBrains 打造的下一代 IDE，于 2021 年首次正式推出。它是一个新的分布式多语言编辑器和 IDE，基于 JetBrains 在后端的 IntelliJ 平台，采用了全新的用户界面和分布式架构从头开始构建。

下载 Fleet：https://www.jetbrains.com.cn/fleet/download/

公告表示，自从最初宣布 Fleet 以来，有超过 137,000 人报名参加私人预览；官方最初之所以决定从封闭式预览开始，是为了能够以渐进的方式处理反馈。现如今，JetBrains Fleet 仍处于起步阶段，还有大量的工作要做。其向公众开放预览的原因有两个方面：“首先，我们认为让所有注册者再等下去是不对的，但单独邀请这么多人对我们来说也缺乏意义。面向公众开放预览对我们来说更容易。第二，也是最重要的，我们一直是一家以开放态度打造产品的公司。我们不希望 Fleet 在这方面有任何不同。”

JetBrains 方面提供了一个图表，以显示 Fleet 目前提供支持的语言和技术，以及每个技术的状态。但值得注意的是，Fleet 仍处于早期阶段，有些事情可能无法按预期工作；所以即使有些东西被列为受支持的，也有可能存在问题。

同时 JetBrains 也强调称，他们并不打算取代其现有的 IDE。

因此，请不要期望在 Fleet 中看到与我们的 IDE（如 IntelliJ IDEA）完全相同的功能。尽管我们会继续开发 Fleet，我们 IDE 的所有功能也不会出现在其中。Fleet 是我们为开发者提供不同用户体验的一个机会。话虽如此，我们确实希望听到你认为 Fleet 还缺少什么功能的反馈，例如特定的重构选项、工具集成等。我们现有的 IDE 将继续发展。我们对其有很多计划，包括性能改进、新的用户界面、远程开发等等。最后，Fleet 还在底层采用了我们现有工具的智慧，所以这些工具都不会消失。

JetBrains透露，在未来几个月他们将致力于稳定 Fleet，并尽可能地解决得到的反馈。同时，将在以下领域开展工作：

为插件作者提供 API 支持和 SDK–鉴于 Fleet 有一个分布式架构，我们需要努力为插件作者简化工作。虽然我们保证会为扩展 Fleet 提供一个平台，但也请求大家在这方面多一点耐心。
性能 – 我们希望 Fleet 不仅在内存占用方面，而且在响应时间方面都能表现出色。有很多地方我们仍然可以提高性能，我们将在这些方面努力。
主题和键盘地图 – 我们知道许多开发者已经习惯了他们现有的编辑器和 IDE，当他们转移到新的 IDE 时，往往会想念他们以前的键盘绑定和主题。我们将致力于增加对更多主题和键盘映射的支持。我们当然也会致力于 Vim 的模拟。

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

开源 3D 图形设计软件 Blender 最新每日构建版本在 Linux 上已经原生支持 Wayland。官方称如果一切顺利，即将发布的 Blender 3.4 将引入此功能。

Blender 是一款跨平台的 3D 图形设计软件，可以在 Linux、macOS 以及 Windows 系统下运行。与其他 3D 建模工具相比，Blender 对内存和驱动的需求更低。其界面使用 OpenGL，在所有支持的硬件与平台都能提供一致的用户体验。

近年来，越来越多的 Linux 发行版开始默认提供 Wayland 桌面，开发者也一直在积极为 Blender 提供原生 Wayland 支持。目前 Blender 的 Wayland 支持依赖于库。

Blender 团队认为，Wayland 从 2008 年开始就已成为 X11 替代方案，近年不少 Linux 发行版都已默认提供 Wayland 桌面。因此从长远来看，Blender 原生支持 Wayland 能带来更好的用户体验，让 Blender 支持 Wayland 的开放功能，不受 X11 兼容层的限制。

Blender 团队称他们早在 2020 年就已实现了对 Wayland 的初步支持，此后一直在解决各种问题，让 Wayland 得到更好的支持——以便在正式版本中默认启用。不过目前的版本仍存在问题，列举部分如下：

不支持平板电脑
不支持 NDOF（3D 鼠标）
不支持 cursor warping
不支持窗口帧
不支持高 DPI
……

现在 Wayland 支持已在官方每日构建版本中启用，团队希望在即将发布的版本中对其进行验证。因此，除非出现无法解决的问题，否则它将在 Blender 3.4x 及以后的版本中得到正式支持。

Blender 3.4 计划在 12 月初发布。Blender 3.4 还将为 Linux 带来 Headless 渲染、集成 OpenPGL、改进 Sculpt 性能，以及许多其他的改进。

作者：Vishal Ghariwala，SUSE 亚太及大中华区 CTO

如今，在边缘环境部署成百上千互联设备已经不再新奇。在工厂和工程设施中，自从微芯片问世以来，PLC 就接管了工业设备的监控任务，并且一直在简化相应的工作流程。而今的不同在于，网络节点的构成以及其中容纳的互联设备数量一直在快速变化。

无论您是否愿意接受，宇宙和 Web 3.0 将在未来数年内走进我们的生活。在 Web 2.0 时代，用户可以通过键盘/触控板、耳机和网络/手机摄像头彼此交互，而 Web 3.0 将为我们呈现全新的交互维度，比如提供一些去中心化的虚拟 3D 世界和体验。一些新的设备也将应运而生，比如能在宇宙世界里获得物体真实触感的触觉手套。依托边缘设备和应用程序，这些都将成为可能。

按照如今的发展趋势，配置成千上万设备的边缘环境将变得无处不在。随之而来的新问题是，如何安全、稳定、连续地管理和运行这些设备？毕竟谁也不愿看到触觉手套在宇宙出现错乱，或者自动驾驶汽车传感器被恶意软件攻陷。

边缘运行系统

随着联网设备数量的增加，相关的管理和安全防护将成为管理人员的重中之重。对于具备不可变特性的 Linux 操作系统——甚至是一些消费电子产品，很多人赞成将系统和应用程序的部署空间彼此隔离。而对于小规模边缘设备，类似的部署策略则需借助容器化架构来实现。操作系统需要在速度、安全性和不可变性方面进行优化，并为可互操作且部署平台彼此独立的边缘设备和应用程序提供良好的基础环境。

SUSE Linux Enterprise Micro (SLE Micro) 正是这样一款为边缘环境中的容器化工作负载量身打造的轻量级操作系统。它安全可靠、无需维护，能够使更新、回滚和复原等简单而重要的边缘设备管理任务实现自动化运行；它占用的资源很少，可以确保设备电池续航更长时间。开发人员也能够基于 SLE Micro 快速完成测试和编程，构建涵盖可穿戴设备、智慧城市、交通运输等众多领域的各类应用程序。

边缘计算

边缘设备和应用程序将生成大量需要实时处理和分析的数据，以便为最终用户提供理想的体验。例如，现场工程师可以借助数字孪生虚拟化技术实现远程监控，可以通过增强现实眼镜采集传感器数据，并以数据流的形式传回总部，获取实时的远程指示。

对于这类情况，我们需要将边缘计算资源部署在更靠近现场的位置（例如去中心化的 3D 世界），以满足降低延迟的需求。边缘基础设施也需要具备灵活性、可靠性和容错能力。Kubernetes 是一项非常实用的技术，它拥有出色的可扩展性和自我修复能力。作为一款安全可靠的轻量级 Kubernetes 解决方案，经过多项标准认证的 SUSE Edge 堪称边缘位置的理想选择。

边缘代码安全防护

对于有意进军宇宙的软件，其开发人员的一项要务就是确保代码能在边缘设备和计算基础设施上安全运行。为此，必须持续扫描代码中的漏洞，监控实时流量中的可疑行为，保护敏感数据，并建立自动化的安全防护策略。SUSE NeuVector 正是一款具备上述所有功能的网络安全平台，可在从开发到质量保证 (QA)、再到投入生产环境运行的各个阶段为边缘应用程序提供全方位的保护。

边缘计算与宇宙相辅相成。它们彼此成就、相互支持，共同为我们呈现无数令人叹为观止的全新可能。低延迟、自动化维护、无间断运行和安全性等关键层面的用户体验可为用户业务成功和全面推广提供可靠的支持。我们需要采取新策略来部署数据中心，对软件进行维护、管理和安全防护。以 SUSE 为代表的技术合作伙伴提供的创新开源解决方案能够充分满足这些方面的边缘计算需求。深入了解 SUSE 边缘计算解决方案，请下载《SUSE云原生边缘计算指南》。

前言

在linux系统中，root账户是有全部管理权限的，一旦root账户密码外泄，对于服务器而言将是致命的威胁；出于安全考虑，通常会限制root账户的登陆，改为配置普通用户登陆服务器后su切换到root账户使用，这种方式较为安全，限制root账户登陆的方式有多种，本文主要介绍如何通过linux-PAM限制账户登陆；

PAM模块简介

Linux-PAM (Pluggable Authentication Modules for Linux)可插拔认证模块。Linux-PAM是一套适用于Linux的身份验证共享库系统，它为系统中的应用程序或服务提供动态身份验证模块支持。它提供了对所有服务进行认证的中央机制，在Linux中，PAM是可动态配置的，本地系统管理员可以自由选择应用程序如何对用户进行身份验证。

由此可知PAM可以对linux系统的账户做验证，我们通过PAM模块可以对linux系统内的账户进行登陆限制；PAM下的功能模块较多，此次主要讲述通过pam_listfile.so模块限制账户登陆的方法

pam_listfile.so模块可以实现基于”用户/组，主机名/IP，终端”的访问控制。访问控制依靠PAM配置文件中的控制选项和一个自定义的配置文件来实现的。而且除了针对上述访问源的控制之外，还能够控制到ruser，rhost，所属用户组和登录shell。

访问控制的配置方法

下面说下基于用户的访问控制的配置方法：

/etc/pam.d/目录下是PAM配置文件所在路径，/etc/pam.d/sshd和/etc/pam.d/login 两个文件是本次要修改的文件；/etc/pam.d/sshd对应的是sshd登陆的配置文件，/etc/pam.d/login对应的是管理终端登陆的配置文件；

我们先在/etc/pam.d/sshd文件中增加一行如下信息：

auth required pam_listfile.so item=user sense=deny file=/etc/pam.d/denyuser onerr=succeed

此行表示用户通过管理终端登陆主机的时候，会调用pam_listfile.so模块来验证用户是否可以登录；pam_listfile.so中配置的item=user表示基于用户；sense=deny表示拒绝；file=/etc/pam.d/denyuser则是定义了一个denyuser的文件；此行的含义是denyuser文件中的用户拒绝通过ssh系统；

此处对pam_listfile.so模块配置做下说明:

格式分为五个部分：分别是item、sense、file、onerr以及apply。

其中：

onerr=succeed|fail_：定义了当出现错误（比如无法打开配置文件）时的缺省返回值。_

sense=allow|deny_：定义了当在配置文件中找到符合条件的项目时的控制方式。如果没有找到符合条件的项目，则一般验证都会通过。_

file=filename_：用于指定配置文件的全路径名称。_

apply=user|@group__：定义规则适用的用户类型（用户或者组）。

测试效果

我们在云主机中添加此配置测试下效果；

编辑下/etc/pam.d/sshd文件添加上述信息：(信息需要添加到auth的第一行之前，否则不会生效)

在/etc/pam.d目录下创建denyuser文件，并写入root；

之后测试下使用root账户ssh登录云主机，提示密码被拒绝；

在服务器内查看/var/log/secure文件，日志中显示的登陆错误为：

根据日志可以看出root登陆不上是被pam_listfile限制了；

如果想限制其他用户，可以在denyuser文件中将要限制的用户名添加下，添加后对应用户的登陆也会被限制；

下面在通过在/etc/pam.d/login配置文件添加限制，login文件控制的是终端登陆，云主机通过控制台的远程连接功能登陆属于终端登陆；

调整后通过远程终端vnc连接后，使用root账户登陆无法正常；说明配置已经生效。

以上是通过linux-PAM的pam_listfile.so模块限制账户登陆的方法，我们可以灵活运用此模块限制主机内的账户登陆情况，加强主机的安全性。

作者：马寅初

在这个充满无限可能的多计算时代，

如何加速开发周期，

释放开发潜能，降低开发风险，

持续创新，

推动计算领域的新突破？

面向云、AI、智能边缘和5G、

游戏开发、内容创作等应用，

和加速计算、信息安全、神经形态、

量子计算等技术的飞速发展，

软硬件开发者和创新者们，

如何利用先进产品、技术和工具，

打造面向未来的解决方案，

实现下一代计算愿景？

2022年10月18日-19日，

英特尔On技术创新峰会中文版即将上线！

两场主题演讲、

五个技术洞察、六大技术论坛，

一场oneAPI DevSummit，

专注赋能开发者，

涵盖当前开发者关注的各项热门主题，

分享前沿创新产品、工具、技术方案与实例，

助力开发者在全栈提升各项技能。

在激动人心的主题演讲环节，

英特尔公司首席执行官帕特·基辛格

联合合作伙伴分享技术发展成果，

揭示创新的未来科技，

并面向庞大的软硬件开发者生态系统，

发布和公布全新产品与技术方案的重大进展。

期待值拉满，

亮点剧透，先睹为快！

亮点1：创新方案和开放平台，助力开发者加速开发周期

如何应对开发者所面临的一系列挑战，诸如新型硬件的采用、上市成本和安全等问题？英特尔将在本次主题演讲带来扩展的英特尔开发者云平台支持开发者在产品发布前进行开发和测试，以及全新的英特尔® Geti™ 计算机视觉平台只需运行小型训练工作负载就能完成AI模型构建等，揭示这些解决方案如何帮助开发者加速开发周期，从容应对挑战。

亮点2：更丰富产品及软硬件技术组合，提供更多选择释放开发潜能

英特尔持续推动硬件和软件产品创新，以求为当今世界和未来商业应用带来更佳的计算体验。此次峰会的主题演讲，将深入探索全新发布的第13代英特尔® 酷睿™ 处理器家族在游戏开发领域的出色表现。同时，英特尔在面向数据中心、高性能计算、游戏等不同领域的GPU新品进展，Habana Gaudi2 深度学习加速器帮助内容创作者提升速度增强创意，英特尔® 至强® 可扩展处理器中的内置人工智能加速和安全技术，让包括 iOS和 Android 的设备都可以与 Windows PC 协同运行的英特尔多设备协同技术等一系列软硬件技术创新，都将在主题演讲环节逐一揭晓和演示。

亮点3：系统级代工开创芯片制造新时代

为了用芯粒打造新的客户和合作伙伴解决方案，英特尔将开创系统级代工的时代，发展结合卓越的晶圆制造、基于2D、2.5D 和 3D 堆叠技术的封装、稳定的软件接口和oneAPI 解决方案和包括PCIe、以太网和 Wi-Fi 等标准的通用芯粒高速互连开放规范（UCIe）联盟-芯粒生态系统的系统级代工业务，并预先展示可插拨式光电共封装解决方案的创新突破，为未来新的系统和芯片封装架构开启了全新可能。这些创新举措与进展，您可以通过主题演讲进一步深入了解。

10月18日上午10点

英特尔On技术创新峰会

帕特·基辛格主题演讲中文版直播，

开放、可选择、可信任，

在多计算时代加速开发，

一起探索推动计算领域的新突破！

当然，

这仅仅是英特尔On技术创新峰会的开始，

10月18日-19日，

为期两天的峰会还将带来

● 10月18日-英特尔公司首席技术官、高级副总裁、软件和先进技术事业部总经理Greg Lavender主题演讲：

分享英特尔在推进开放生态上的努力与投入，探讨英特尔如何助力开发者加速创新。

● 10月18日-五个技术洞察和六场专题论坛：

涵盖当前开发者关心的热门话题，深度解码英特尔在网络和边缘计算、终端、数据中心/云、开放加速计算、人工智能/机器学习方面的创新技术与工具，解决方案和实例。

● 10月19日-oneAPI DevSummit 2022中国站：

聆听英特尔及来自阿里云、联想、国泰君安、海信医疗、北大微软和中科院计算所等产学合作伙伴的分享，深入学习各种经典案例及创新实践。

链接，即刻注册参会，

解锁更多精彩！

作者 | 17哥

导读：在视频处理中，我们经常会用到不同的色彩空间：非线性RGB，线性 RGB，YUV，XYZ……为什么需要这么多的色彩空间呢？为什么在 FFMpeg 中会有 color_space，color_transfer，color_primaries 等一系列的颜色属性呢？这些术语之间究竟隐藏着什么秘密 ?

全文5840字，预计阅读时间15分钟。

01 视频采集

如上图所示，在相机系统中，外部世界的光信息（光子，photons）通过透镜或其他光学器件聚焦之后达到相机的图像传感器（‍CCD‍ 或者 CMOS）。[1]

图像传感器可以将一个入射光子（photon）转换为对应的一个电子（electron）。
在曝光时间内，图像传感器对转换的电子进行电荷积累。
然后，图像传感器会将积累的电荷信号转换成对应的电压信号。
最后，利用 ADC 把电信号转换成数字信号，而转换后的数字信号则为某个范围内的整数值。

ADC 数字信号的取值范围：

ADC 转换之后的数字信号的取值范围受限于 ADC 设备。对于 8-bits 的 ADC 而言，数字信号的取值范围为 [0, 2^8-1]，因此，对于每一个像素而言，会用 [0, 255] 之间的整数来进行编码。

ADC 转换的数字信号的数值是一个线性编码的过程，这意味着如果将图像传感器上的光量增加 1 倍，则 ADC 转换之后对应的数值也会增加 1 倍。这是一个非常有用的特性：无论是增加物理世界的光量，还是增加 ADC 转换之后的数值，对图片而言，都会带来相同的效果。线性编码意味着我们所处理的数据和光发射的强度成正比关系。[2]

由数码相机中的 CMOS 传感器产生并写入原始文件（Raw File）的数据是线性的。与普通照片相比，线性数据通常看起来非常暗且对比度较低。[3]

在 iPhone 手机中，可以通过设置相机来拍摄 Apple ProRAW 格式的照片。

02 探索视频伽马校正

实际上，研究表明，人类视觉系统是以对数函数的方式来感知光亮度。这意味着，人眼会提高暗部的敏感度，降低高光部分的敏感度。[4]

从数学角度看，感知光强度和测量光强度之间存在一个近似的平方关系，具体如下式所示。

由于人类视觉感知系统不是以线性方式工作的，因此必须使用非线性曲线来对 ADC 生成的的线性数据进行变换，从而使得拍摄的图像色调与我们的视觉系统的工作方式相匹配。这个过程也就是我们所说的伽马校正。

因此，在从线性 RGB 空间转换到非线性 RGB 空间时，需要 γ 作为转换参数。相机中的 ISP 模块负责对图像传感器的线性 RGB 进行伽马校正进而产生对应的符合人眼感知的非线性 RGB 数据。

RGB 的设备依赖性：

不同显示设备支持的色域空间不同，因此对于不同的显示设备而言，伽马校正之后的 RGB 数值也不同。从这个角度讲，RGB 是设备依赖型的色彩空间。

03 视频压缩

根据如上的信息，我们知道：相机系统经过 ISP 处理之后，最终会得到非线性的 RGB 信息。对于视频而言，如果以 RGB 存储每帧的信息，则需要消耗大量的存储空间。

人类视觉系统对颜色信息的敏感度要弱于亮度信息，利用这一特点，通常相机会将捕获的 RGB 信息转换为 YUV 格式，然后对 YUV 格式进行色度信息采样（例如，YUV420）以便压缩图像空间。

RGB->YUV，不同标准有不同要求，一般常用的标准有：

BT. 601(SD: Standard-Definition)
BT. 709(HD: High-Definition)
BT. 2020(UHD: Ultra-High-Definition)

注意：

标准中，不但会规定 RGB->YUV 的转换系数，同时还会规定从线性 RGB 到非线性 RGB 转换的 gamma 系数。

将 RGB颜色模型，转换成 YUV 模型后，接下来会采用某种视频编解码算法（例如，H265, VP9）对获取的数据进行视频编码，最终得到视频文件（此处忽略了音频的采集编码以及合流的操作）。

04 视频转码

出于各种原因，例如：

终端用户的带宽受限
终端用户支持的视频编解码算法和相机压缩视频的编解码算法不一致
……

一般不会直接把相机产出的视频文件分发给用户去消费。媒体服务商会对相机生成的视频文件进行转码，然后选择合适的转码后的视频分发给终端消费用户。[5]

在视频转码阶段，如果我们希望对原视频进行色域的变换，例如从 BT. 601 转码为 BT. 709，则需要在不同色域的 RGB 数值之间进行转换。[6]

在不同的色域空间进行 RGB 数据的转换，这也就是我们所说的色彩管理。色彩管理会对图像进行色彩管理以适配当前环境下的颜色效果，从而保证同一张图片在不同输入、输出上都呈现出最好的颜色。[7]

色彩转换需要在某个线性空间下进行操作，并且操作过程需要保持设备的独立性。因此，不同的 RGB 色域空间是不能直接进行转换的，需要一个设备无关、线性的颜色模型作为中转才能实现其转换。

而 XYZ(CIE 1931 XYZ color space) 具备设备无关、线性操作的特性。

在 FFMpeg 中，主要使用 colorspace 滤镜来完成不同色域空间的转换。[6:1]根据 colorspace 的实现可知，在 FFMpeg 中，BT. 601->BT. 709 的转换过程如下所示：

在如上的变换中，涉及到 3 个颜色空间的转换，分别是：

YUV 和 RGB 之间的转换
线性 RGB 和非线性 RGB 之间的转换
线性 RGB 和 XYZ 之间的转换

在 FFMpeg 中，所有的这些转换参数都保存在 AVFrame 结构中[8]：

AVFrame->colorspace 中保存了 YUV/RGB 的转换矩阵
AVFrame->color_trc 中保存了线性 RGB 和非线性 RGB 之间的转换函数（transformation characteristics）。
AVFrame->color_primaries 中保存了 RGB/XYZ 的转换矩阵

如果用 ffprobe 命令解析视频文件，则：

color_space 字段对应 YUV/RGB 的转换矩阵
color_transfer 字段对应线性 RGB 和非线性 RGB 之间的转换函数
color_primaries 字段对应 RGB/XYZ 的转换矩阵

在如上的例子中，arib-std-b67 也就是我们所熟悉的 HLG。

在 MediaInfo 中，

Matrix coefficients 字段对应 YUV/RGB 的转换矩阵
Transfer characteristic 字段对应线性 RGB 和非线性 RGB 之间的转换函数
Color primaries 字段对应 RGB/XYZ 的转换矩阵

除了如上的参数外，AVFrame->range 还用来存储视频中对应像素的每个分量的取值范围。在 vf_setparams.c 中也作了相关的定义说明：

05 视频解码&播放

转码之后的视频，可以通过各种渠道分发到终端用户进行消费。对于大部分显示设备，例如CRT显示器、LCD、OLED，屏幕上的每个像素都是通过驱动三个非常靠近但仍然分开的小型 RGB 光源而构建的。[9] 因此，显示屏（监视器，电视机，屏幕等等）仅使用 RGB 模型，并以不同的方式来组织，并显示最终的图像。[10]

如前所述，不同的显示设备采用的 RGB 的色域并不一定相同，因此，RGB 是一种设备依赖型的颜色模型。[11]在 Mac 电脑上，可以通过显示器配置来选择显示器支持不同的 RGB 色域。

5.1 显示设备和相机的色域一致

如果编码视频和播放视频的显示器采用的 RGB 色域是一致的，比如都是 sRGB，此时的播放过程相对比较简单。视频解码之后，得到 YUV 数据，然后根据标准将 YUV 数据转换成非线性的 sRGB 数据，然后显示器根据 sRGB 数据显示图像即可。

5.2 显示设备和相机的色域不一致

当显示设备支持的色域从 sRGB 变为 Rec. 2020 时，如果直接显示 sRGB 色域下的数据，则会导致比较严重的颜色失真。

和转码阶段的色域转换类似，此时，也需要在不同的色域空间进行 RGB 数据的转换（色彩管理）以保证相同的视频在不同输入、输出、显示设备上都呈现出最好的颜色。

对于显示设备而言，sRGB->RGB(Rec. 2020)的转换过程如下所示：

因此，对于拍摄设备和显示设备的色域不同时，视频的播放增加了颜色管理的过程。

06 视频观看

虽然视频信息的采集和最终终端播放采用的都是 RGB 的颜色模型，但是对人眼而言，RGB 其实并不直观，比如我们很难马上反应出天青色的 RGB 色值？

为了能够更直观的表示颜色，又引入了 HSL 色彩模型。HSL 比 RGB 更加直观，比如：想从黄色过度到红色，只需要调整色相即可，饱和度和亮度保持不变。因此，HSL 一般更适合人的色彩感知，而 RGB 更适合显示领域。

为了让作品可以呈现出期望的效果，提升用户的视觉体验，在摄影后期，使用 HSL 对作品进行调整是最方便的一种方式。利用 HSL 对作品进行调整，简单几步就可以让灰暗的「马路随拍」秒变「街头大片」。[12]

FFMpeg 的 signalstats 滤镜可以分析获取视频的色调、饱和度、亮度信息。但是该滤镜获取的色调、饱和度和 HSL 中的计算是不一致的。

signalstats 计算色调、饱和度的算法如下所示：

如果需要得到视频的标准 HSL 信息，可以使用作者开发的 vf_hsl 滤镜。

07 结语

虽然颜色还是那个颜色，但是不同的颜色空间的适用范围并不相同：

RGB：面向采集和显示设备
YUV：面向存储
HSL：面向人类视觉感知
XYZ：RGB之间的转换桥梁

从视频采集到视频消费的整个过程，涉及到不同的设备和标准，而不同的设备和标准所支持的色域空间又不相同。正是通过不同的颜色模型转换和不同的色域转换，才得以让我们实现：在不同输入、输出、显示设备上都呈现出最好的颜色，才得以让我们实现以近似相同的观看体验来消费视频。

——END——

参考文献：

CMOS Image Sensor原理简述：https://zhuanlan.zhihu.com/p/
What does linear RGB mean：https://discuss.pixls.us/t/what-does-linear-rgb-mean/16584
How Digital Cameras Work：https://www.astropix.com/html/astrophotography/how.html
Linear vs. Logarithmic Dimming—A White Paper：https://www.pathwaylighting.com/products/downloads/brochure/technical_materials__Linear+vs+Logarithmic+Dimming+White+Paper.pdf
What is Video Transcoding and Why Do You Do It：https://medium.com/videocoin/what-is-video-transcoding-and-why-do-you-do-it-348a2610cefc
Talking About Colorspaces and FFmpeg：https://medium.com/invideo-io/talking-about-colorspaces-and-ffmpeg-f6d0b037cc2f
【颜色科学】RGB和XYZ颜色空间的转换：https://blog.csdn.net/weixin_/article/details/‍‍‍‍‍‍‍‍
Colorspace support in FFmpeg：https://trac.ffmpeg.org/wiki/colorspace
RGB color model：https://en.wikipedia.org/wiki/RGB_color_model
数字视频导论：https://wangwei1237.github.io/2020/02/28/Introduction-to-digital-video-technology/
Computational Color Technology：https://www.spiedigitallibrary.org/ebooks/PM/Computational-Color-Technology/eISBN-85/10.1117/3.
用HSL调色=简单、快速、超出片：https://zhuanlan.zhihu.com/p/

在云原生社区近日主办的 Service Mesh Summit 2022 服务网格峰会上，网易数帆云原生技术专家方志恒分享了轻舟服务网格无侵入增强 Istio 的经验，本文据此次分享整理，介绍了对无侵入和实现的思考，轻舟服务网格演进过程中的扩展增强，以及这些扩展增强和无侵入的关系。这里“无侵入”强调的是对服务网格基础设施本身的无侵入，而不是只有对业务的无侵入，后者是服务网格本身的定位所要考虑的内容。

服务网格维护中的无侵入

关于无侵入，我们从各自的实践经验也知道，做无侵入的增强是非常困难的。原因有很多，比如说我们可能要做业务的适配，快速落地，定制的一些需求等，业务以及项目周期的压力，迫使我们不得不做出一些有侵入的选择。但是我们为什么还要去强调无侵入呢？因为对于我们维护团队，或者说对于我们自己这个技术方案的维护方来说，每一分侵入都会有每一分的成本，它会在后续会体现出来，比如说在做长期维护，做版本演进，去做社区的一些功能和新版本的对齐，我们都需要去解决我们的改动和社区的主干分支之间的冲突。

因此，我们需要在我们的研发流程里面去贯彻这样一个目标或者理念：这个方案是不是做到无侵入了，如果没有做到的话，那做到的程度是怎么样的？这样可能才得到一个“求上得中”的效果，就是坚持无侵入，我们才可能做到比较低的侵入。

在使用社区的方案去做定制开发、去演进的过程中，我们认为，有一些比较合适的用来去做维护的思路，最合适的方式，是直接使用社区原生的 API 提供的扩展点去做一些无侵入的扩展，这是最理想的情况。当然，社区的一些扩展的 API 可能无法完全满足我们的需求，这个时候我们可以在上层去做一个封装，业界的一些落地的实践案例也体现出这样的理念。这里引用一句名言：计算机科学领域的任何问题，都可以通过增加一个中间层来解决。

即使是这样，我们出于性能的考虑，或者出于特性的考虑，很多时候还是会面临一些不得不去做修改的情况。我们有第二个原则，就是把扩展增强的内容去做一些封装在一个单独的库里面，这样可以做到最小的修改和替换。这也是一个比较朴素的工程经验。

第三点，如果我们确实要做比较大的一个修改，这个时候我们可以尽量去贯彻一个理念，就是要对社区原生的一些设计思路和特性做一致性的对齐。这里我分享一个“撸猫原则”：如果我们非要去撸一只猫的话，最好顺着它的毛去撸，否则我们可能会把它的毛搞得很乱，甚至它还会反过来咬我们一口。

服务和配置的扩展

首先介绍我们对 Istio 的服务和配置的扩展。

配置

Istio 社区已经提供支持多 configSource，并给出了一个协议叫 MCP-over-xds，通过这种方式我们可以从不同的数据源去拿到所需的配置。

这里给出一个配置样例，是通过 xDS 协议去向某一个服务去获取它的配置，同时也可以去 Kubernetes 去获取那些标准的 CR，这是它的一个扩展的方式。

我们的 URL 跟官方的稍微有点不一样，是在这基础上稍微做了一点改进，实现了一个叫做 Istio-MCP 的库平替社区原生的 adsc，这就是前面说的第二个原则。在这个库里面，我们实现了 xDS 的增量推送，更增强了一个 revision 的机制，Istio 支持按照 revision 去获取自己感兴趣的配置，我们对此做了增强。我们还做了一个更灵活的分派，允许在 configSource 里面去指定一个类型，相当于从不同的 configSource 去获取不同类型的配置，这个很多时候都是实践的需要。

服务

服务这部分，在网易数帆的场景里面，比较广泛地应用到了。Istio 对 Kubernetes 服务的支持很好，大部分情况下无需做额外的扩展，但是因为它的定位，Istio 把对非 Kubernetes 服务的支持几乎都留给了它的一个扩展点，就是这个API，以及前面所说的配置扩展的方式。通过这种方式，Istio 允许第三方来作为配置和服务的提供员，来提供其他的服务模型。当然在这个过程中，第三方需要自己去完成服务模型的转换，因为几乎就是 Istio 内部服务模型的 API 版本，你可以认为它是 Istio Service 模型。

我们也有一个单独的组件，叫做 mesh-registry，实现了 MCP-over-xds 的协议，作为一个MCP server。在这个组件内部，我们支持了不同的服务模型的转换，包括将 Dubbo/ZK、Eureka、Nacos 去转换成标准的 ServiceEntry，然后下发。

这是在服务这一块的扩展。从目前来说，以上两部分的扩展方式都可以说是无侵入的，是基于社区原生接口和协议的扩展。

插件的扩展

第二部分是插件的扩展。Istio 的功能确实很丰富，这导致它在市场上成为主流，使用的人很多。但很多人使用同时也意味着，即使 Istio 的能力再丰富，它也无法覆盖所有用户的场景，就会需要这种扩展机制。

EnvoyFilter

Istio 社区的扩展方式是一个比较典型的 EnvoyFilter 的方式。这种方式，configPatches 进去的内容是 Envoy 的一个一个 filter 的配置，Envoy 具体的内容我们可以先忽略，先看一下 applyTo、context、match、routeConfiguration、vhost 这一堆东西。

举个例子，我们要做一个限流的功能，因为它是一个业务功能，作为使用者，我们要知道限流 API 的业务语义，首先需要去看 Envoy 的限流插件它的 API 是怎么样的，跟上层对限流的业务需求是不是对得上，再确定我应该怎么样去写一个限流的插件的配置。到这一步还只是完成了要 Patch 进去的内容，要写出这个 EnvoyFilter 的时候，我们还需要去了解更多的东西，比如这里的 applyTo、HTTP_ROUTE 以及 vhost 等。如果是其他的类型的 Patch，可能还有其他的概念。

这里面有一个本质的问题，filter 是 Istio 提供的一个几乎是纯数据结构级别的 Patch 机制，它直接操作 Istio 下发给 Envoy 的 xDS 配置，它的数据结构的描述、定义和类型都是 Envoy 侧的一些概念，比如 vhost，这就意味着 Istio 的使用者需要深入了解 Envoy 侧的概念。同时还有一些的灰色地带，举个例子，如果我们要给一个 vhost 去 Patch 一些东西，就要知道 vhost name，而 vhost name 是 Istio 自己的一个实现，纯粹实现层面的东西，相当于说上层的使用者还要知道某一个版本的 Istio，它的 vhost name 是通过什么规则拼起来的。我们会认为对使用者来说负担会比较多，一个比较理想的做法是，他既然是 Istio 的使用者，那么他接触到的应该尽量是 Istio 层面的一些语义。我们对它做增强的思路就是这样的。

下面是轻舟服务网格做的一个比较浅的封装，但是在我们内部用得很多，所以我们认为它解决了一些实际问题。这个字段描述我们这个插件要去作用于网关，作用于某一个 host，作用于某一条路由，也就是说我们会尽量用 Istio 层面的语义来做这种类似的封装，帮用户转成下层的 Envoy 语义。

基于同样的思路，我们还做了一个限流的模块。但这里不是为了讲限流，而是说我们怎么去做上层的业务语义描述。限流这个功能有点特别，可以做得很复杂，所以 Envoy 提供了一个非常灵活的 API，这带的一个问题是，别说 Istio 的用户，就是 Istio 的维护者自己要把 Envoy 限流 API 看明白，都需要付出较多的时间和精力。所以，我们希望把它做得简化一点，更接近业务语义描述，这也是一个复杂度的消化——Envoy 做得非常灵活，它什么都可以做，但复杂度不会凭空消失，中间需要肯定有一层实现业务语义到底层的灵活能力的映射。

Rider 插件扩展

插件扩展的第二大类是我们的 Rider 的插件，Rider 比较像 Envoy 版本的 OpenResty，Envoy 本身有支持 Lua 的插件，但是它的支持比较简单，里面的 API 比较少，熟悉 OpenResty 的同学应该知道，我们写 Lua 和 OpenResty 是完全不一样的，因为 OpenResty 提供了很丰富的，跟网络操作、跟 Nginx 内部 API 做交互的 API，让我们很容易去做实际业务功能的开发，你无法想象我们纯粹用 Lua 去开发一个 HTTP_SERVER。基于这个背景，我们对 Lua 做了一个增强，在 Rider 插件提供了比较丰富的 Lua 交互的 API，让用户可以相对容易地在里面去实现一个上层的业务和治理的功能。另外，我们也对原生的 Lua 插件实现做了一些性能优化，相比来说 Rider 是有一定的性能优势的。

Rider 和原生的 Envoy Lua 插件的对比，是我们可以支持插件的配置。这里的配置是指类似于 Envoy 的 WASM 或者 Lua 插件，都是分成两部分，一部分是下发一个可执行的内容，无论是 Lua 脚本还是 WASM 二进制，都是一个插件实际执行的逻辑，我们还可以给它一份配置，这个配置跟执行内容两相结合，形成最终的业务行为。

社区的 Lua 不支持如路由级别的插件配置，这导致它的行为比较死，比较 hardcode，我们支持它的插件配置，支持更多的 API，性能也会更好一点。

现在 WASM 是一个很火的概念，我们也跟 WASM 做了一个对比，第一点是 Lua 跟 WASM 的对比，作为脚本语言，Lua 更加可见即可得，虽然 WASM 也可以从脚本编译而得，但如果用脚本转成 WASM 再做下发，WASM 编译语言性能损耗更小的优势就没有了。第二点是便于分发，因为没有编译的过程。第三点也是支持更多的API，原生的 Envoy WASM API 确实会少一些。最后一点是更好的性能，我们原以为即使考虑上 LuaJIT，Rider 的性能也不会更好，但实际上 Envoy WASM API 的实现导致 Envoy WASM 跟 Envoy 内部交互的成本略高，所以测出来它的性能反而比 Rider 要更差一点。

扩展方案是否支持插件配置是否支持动态扩展性能支持语言开发复杂度原生 C++ 是否最优 C++ 复杂社区 Lua 否是较差 Lua 简单社区 WASM 是是差 C++/Rust/Go等中等

这是我们实际上测出来的一个对比，我们分别模拟三种场景下，一个很简单的，一个中等复杂度的，还有一个稍微高一点复杂度的，不同方案的性能差别，从图中可以都可以看到，三种场景下 Rider 插件的性能都是好于 WASM C++ 的，尤其是在复杂场景，大概有10%左右的提升，当然这三者相比于原生插件都有不小的差别。

这里给出了一个我们提供的 API 的列表，可以看到风格还是非常的 Resty 的。

我们做的 RiderPlugin，这个东西比较有意思，下面是一个 WASM 的样例，大家可以看到它的 API 的数据结构，完全是一个 WASM 的 API，但实际上做的事情，是通过镜像的方式把我们的 Rider 插件给下发了，再分发到数据面，效果是将 HTTP 请求的那个 response 的 body 改成了。所以说，使用上不能说差不多，简直是一模一样。

我当时看到 Istio 的 WasmPlugin 这个 API 的时候，是有点惊讶的，第一是不知道它为什么要做一个 WasmPlugin，而不是做一个通用的插件分发机制，有点过于耦合了；第二是我发现它字段的设计就是一个通用的插件分发，但是它的名字就叫做 WasmPlugin，当然它在实现的时候也是这样的。所以，我们完全可以用这个 API 来实现我们的 Rider 插件的分发，这个是我们目前已有的一个特性。当然我们还另外设计了一个 RiderPlugin CRD，主要是考虑到后续 Rider 可能提供更丰富的功能，会有更多的字段。我们在实现这个支持的时候，不能说没有侵入，但真的是只改了一点点——它的那些插件分发，包括 Pilot agent 里面，怎么从镜像里面去提取 WASM 文件，我们几乎按同样的规范去定义 Rider 的镜像，去在里面放我们的 Rider 的插件的配置，Lua 的文件，几乎是完全一样的。这就是前面提到的另一个原则，如果我们非要去做一些新的功能，可以做得跟原生的比较像，这样的话无论是我们自己还是用户，都很容易上手。

我们最终下发给 Envoy 的一个数据结构，和 WASM 是有一些差异的，这个差异是在实现里面去做了一个屏蔽，本质上说，我们只是在最后生成下发给 Envoy 的数据的时候对内容做了一些修改，让它是一个 Rider 的格式。

基于此我们还做了前面提到的一个 EnvoyPlugin 的插件，对插件分发做了一个比较浅的上层封装，也加入了对 WASM、Rider 的支持，将会在近期 release。

Dubbo 协议扩展

接下来介绍协议的扩展。我们第一个做的是 Dubbo 协议扩展，因为 Dubbo 在国内确实使用很广泛，同时我们还有一些特殊的考量，稍后再详解。

数据面

首先看数据面的部分。第一，我们做了比较丰富的七层的 dubbo filters，Istio + Envoy 这套体系的大部分治理功能都是通过七层插件来实现的，HTTP 的比较丰富的治理功能有很多七层插件，所以我们也实现了很多 Dubbo 的插件。

第二，我们实现了一个 DRDS，也就是 Dubbo RDS，因为 Envoy RDS 几乎等同于 HTTP RDS，只定义了 HTTP 协议相关的路由的数据结构，我们要实现一个比较灵活的路由，以及性能比较好的路由分发，就需要定义一个单独的 xDS 资源类型。

第三，我们还做了一个 Dubbo 协议嗅探，这是有一些特殊的场景，Istio 社区对协议嗅探有一部分的的支持，它的本意不是为了实现一个很丰富的基于协议嗅探的治理，而是为了解决一部分场景需求，相当于我们引入一个代理之后，会有一些场景需要通过特殊的技术手段去解决，而我们在实际生产中会面临 HTTP 的、TCP 的、Dubbo 的协议，也需要用同样的机制去解决它，所以我们也支持 Dubbo 的协议嗅探。其中技术细节非常多，这里就不展开。

控制面

控制面的改动更多，用户会更可感知。我们的支持比较特殊，因为我们实现了跟 HTTP 几乎完全同等语义的 Istio API，体现为 VS/DR，就是基本的治理。还有比较丰富的治理，是那些七层的 filter，还有 Istio 这一层所抽象出来的认证鉴权的策略是只作用于 HTTP 的，我们也是对它做了 Dubbo 的支持。还有一个比较特殊的就是 Sidecar，Istio 有一个资源是用来描述应用或者服务之间的依赖关系的，这样就可以实现按需下发，像配置瘦身、推送范围的影响，都可以得到一个比较好的优化，我们对此也做了 Dubbo 的支持，相当于用标准的 API 去支持 Dubbo 的类似于服务依赖描述和按需下发。还有一个是 EnvoyFilter，我们也支持了用 EnvoyFilter 的标准的 API 去做 Dubbo 插件的分发。

通用七层扩展框架

我们也做了通用的七层扩展框架的支持，我们在 Envoy 社区的 Maintainer 也和国内同行沟通过，共同努力推进，目前已经合入 Envoy 社区版本，也就是说在数据面是有通用七层扩展框架的支持的，后续 Istio 社区相关的支持，我觉得也是可以期待的。

这里简要展开一下我个人对通用七层扩展框架的理解。我们服务网格多协议适配以及长期维护的成本很高，每接入一个新的协议，都需要去做一个额外的适配。在 Envoy 视角来说，支持一个新的协议需要做的事情，首先是对协议基本的编解码和协议流程的支持，这是协议内部的东西，肯定要做的；除此之外，还涉及到它要跟 Envoy 原有流程的对接，比如 Cluster 是不是可以用，路由是怎么生效的，流量的分派从 listener 进来怎么走到协议解析器或者是四层的 filter，也就是说，一个新的协议的支持要做很多重复性的事情，比如跟原有的机制相结合，这部分重复的工作量我们是可以省去的。

从服务代理和服务治理的视角来说，很多时候我们不关心它是什么协议，服务治理可以理解为一个基于特征的流量分配或者是流量处理，也就是说通常我们关心的是它的特征能否用一种比较通用的方式去描述，就好比我们在做协议设计的时候，可能都会塞进去一个字段，叫做 metadata，HTTP 的协议里面的 header 其实就是一种 metadata，如果能用一个比较简单的通用模型去描述我们所有协议的特征，我们就可以基于这个模型去做服务治理，剩下的事情就是把已有的协议来转化成这个通用模型。当然，所有的这种加一个简单的中间层去做一个复杂度的屏蔽，都会有一个问题，就是无法感知我们抽象出来的共性以外的东西。

举个例子，如果我们要支持 HTTP2，想做一些相对下层的治理，可能会比较困难，因为感知不到 stream、frame 等等，能感知到的就只有它这个抽象。这就是我觉得所有类似的技术方案都有同样的问题。但是一个技术方案的价值，肯定是在它带来的收益减去副作用之后的，如果我们觉得还不错，就可以继续去使用它。

我们目前在用这个通用框架去实现 Dubbo。以前 Dubbo 之所以没有进 Istio 社区，是因为 Istio 社区并不想维护一个特定的协议，即使该协议国内用户比较多，而且因为年代的原因，Dubbo 是不那么云原生的。但是如果我们这里引入的不是 Dubbo，而是一个通用的七层框架，那应该比较乐观一些。所以我们后续会替换原有的 Dubbo Proxy，就是数据面这一块，同时也会尝试跟相关方去推动控制面的接入，看能不能进入 Istio 社区。

Slime 开源项目的集成

上述的很多扩展增强，都已经沉淀在我们开源的 Slime 项目（github.com/slime-io/slime ）里面了。这个项目已经进入 Istio 生态，我们对 Istio 的增强，或者是说魔改也好，或者是说生态丰富也好，都会放进 Slime 项目里面，它是一个 group，里面包含比较多的子项目。这里简单介绍 Slime 最近的一些进展。首先在架构层面，我们做了比较彻底的模块化设计，可以快速地去对 Slime 做上层功能的扩充。

我们定义了一个比较明确的框架层来管理上层的模块，同时也提供一些基础能力给上层，包含定义的一些 metric 框架，让上层可以用很少的代码去获取到一些像 Kubernetes 乃至更多类型的 metric 信息，并且对它做一些处理。同时我们也做了多集群的支持——很多时候我们之所以做一些东西，是因为 Istio 的多个增强功能都需要去做相关的支持，我们就会把它放到框架层——在这个框架层我们直接做了与 Istio 原生比较一致的多集群感知，社区叫做 multi cluster discovery。

我们还支持了一个统一的服务模型数据，支持了 Kubernetes Services 和 ServiceEntry，两个消化完以后处理为内部的一个数据类型。我们之前有了解到，一些同行的朋友在调研技术方案的时候，发现我们只支持 Kubernetes 就没有继续了。比如懒加载的方案，我们现在已经做了一个比较彻底的支持。

还有一个模块聚合和管理的能力，最终的形态大概是这样，只要手动写几行代码，把每一个模块直接放进来就可以了。

我们在最近一年多做了很多的模块，比如前面提到的 meshregistry、pilotadmin、sidecarmgr、tracetio，其中里面有一部分已经开源出去了，还有一部分因为耦合了一些业务逻辑，可能会晚一点开源。

稍微重点说一下，我们有一个子项目叫做 i9s（github.com/slime-io/i9s ），是从另一个开源项目 K9s fork 过来的。熟悉 Kubernetes 的同学可能会用过 K9s ，它提供一种交互式的方式，我们觉得它很好用。同时我们也想到，对于 Istio 的运维管理，有很多地方也可以用这种方式来实现，使用起来会更方便一些。i9s 本质上是用 K9s 这种交互式的视图去展示 Istio 的各种内部信息，比如可以去查看 Istio 上面连接哪些 Sidecar，每个 Sidecar 的运行状态，下发的配置，它的配置是否和应有的配置一致，我们可以去 watch 推送的频率，以及推送的时延，等等。

Slime 项目后续会开放更多服务网格管理的能力，期待大家共建社区。谢谢！

延伸阅读

视频回放：https://www.bilibili.com/video/BV1HD4y117rD/
IstioCon 回顾 | 网易数帆的 Istio 推送性能优化经验
Slime 项目：https://github.com/slime-io/slime
i9s 子项目：https://github.com/slime-io/i9s
Rider 插件框架：https://github.com/hango-io/rider

作者简介： 方志恒，网易数帆云原生技术专家，负责轻舟 Service Mesh，先后参与多家科技公司 Service Mesh 建设及相关产品演进。从事多年基础架构、中间件研发，有较丰富的 Istio 管理维护、功能拓展和性能优化经验。

对Excel进行解析生成查询计算等处理是Java下较常见的任务，但Excel的文件格式很复杂，自行编码读写太困难，有了POIEasyExcelJExcel等类库就方便多了，其中POI最为出色。

POI具有全面而细致的xls读写能力

POI可读写多种Excel文件格式，既支持古老的二进制格式（xls），也支持现代的OOXML格式（xlsx），既支持全内存一次性读写，也支持小内存流式读写。POI为大量Excel素设计了相应的JAVA类，包括workbook、printer、sheet、row、cell，其中，与cell相关的类包括单格样式、字体、颜色、日期、对齐、边框等。仅单格样式类，方法就超过了四十个，可进行最全面最细致的读写操作。

POI的读写功能很底层

POI的读写功能全面而细致，但细致也意味着过于底层，开发者必须从头写起，自己处理每一处细节，即使简单的操作也要编写大量代码。比如，读入首行为列名的行式xls：

行式xls是最常见的格式，但POI并没有为此提供方便的处理方法，只能按照workbook->sheet->line->cell的顺序进行循环解析，造成了如此繁琐的代码。

这还只是将数据简单读出来，如果下一步想再处理数据，还要事先转为结构化数据对象，比如ArrayList<实体类>或HashMap，代码就更繁琐了。

POI查询计算困难

解析Excel并不是目标，我们通常还要对这些文件进查询计算，但POI作为Excel的解析类，没有也不合适再提供相关的方法，只能用JAVA手工硬写。比如基础的分组汇总运算，JAVA代码大概这样：

Java编码实现计算不仅繁琐，而且存在架构性缺陷。代码很难复用，数据结构和计算代码通常会耦合在一起，如果数据结构发生变化，代码就要重写。查询计算的要求灵活多变，而Java作为编译型语言，每次修改代码都要重启应用，维护工作量大，系统稳定性差。

POI成熟稳定，但读写能力过于底层，且未提供查询计算能力，直接基于POI完成Excel文件的处理（特别是查询计算）的开发效率很低。如果针对POI进行封装，形成简单易用的高级读写函数，并额外提供查询计算能力，就能大幅度提高开发效率了。

esProc SPL就是其中的佼佼者。

SPL内置高级读写函数

SPL是JVM下开源的计算引擎，它对POI也进行了封装，内置简单易用的高级函数，可解析生成各类格式规则或不规则的xls，并自动生成结构化数据对象。

解析格式规则的行式Excel，SPL提供了T函数。比如解析前面的xls文件，用封装前的POI要几十行，封装后只要一句：

=T(“d:Orders.xls”)

解析行式Excel是很常见的任务，SPL用T函数封装了POI的功能，接口简单易用。无论xls还是xlsx，T函数都可以统一解析。可自动进行类型转换，开发者无须在细节浪费时间。T函数可自动区分首行的列名和其他行的数据，并根据列名创建序表（SPL的结构化数据对象）并填入数据：

读入并解析成序表后，就可以使用SPL提供的丰富的结构化数据处理方法了：

取第3条记录：A1(3)

取后3条记录:A1.m([-1,-2,-3])

取记录的字段值：A1(3).Amount*0.05

修改记录的字段值：A1(3).Amount = A1(3). Amount*1.05

取一列，返回集合：A1.(Amount)

取几列，返回集合的集合：A1.([CLIENT,AMOUNT])

追加记录：A1.insert(200,”APPL”,10,2400.4,date(“2010-10-10”))

先按字段取再按记录序号取：A1.(AMOUNT)(2)；等价于先按记录序号取再按字段取：A1(2).AMOUNT

解析格式较不规则的行式xls，SPL提供了xlsimport函数，内置丰富而简洁的读取功能：

没有列名，首行直接是数据：file(“D:Orders.xlsx”).xlsimport()

跳过前2行的标题区：file(“D:/Orders.xlsx”).xlsimport@t(;,3)

从第3行读到第10行：file(“D:/Orders.xlsx”).xlsimport@t(;,3:10)

只读取其中3个列：file(“D:/Orders.xlsx”).xlsimport@t(OrderID,Amount,OrderDate)

读取名为”sales”的特定sheet：file(“D:/Orders.xlsx”).xlsimport@t(;”sales”)

函数xlsimport还具有读取倒数N行、密码打开文件、读大文件等功能，这里不再详述。

解析格式很不规则的xls，SPL提供了xlscell函数，可以读写指定sheet里指定片区的数据，比如读取第1个sheet里的A2格：

=file(“d:/Orders.xlsx”).xlsopen().xlscell(“C2”)

配合SPL灵活的语法，就可以解析自由格式的xls，比如将下面的文件读为规范的二维表（序表）：

这个文件格式很不规则，直接基于POI写Java代码是个浩大的工程，而SPL代码就简短得多：

生成规则的行式xls，SPL提供了xlsexport函数，用法也很简单。比如，上面例子的解析结果是个序表，存在SPL的A1格中，下面将A1写入新xls的第一个sheet，首行为列名，只要一句代码：=file(“e:/result.xlsx”).xlsexport@t(A1)

xlsexport函数的功能丰富多样，可以将序表写入指定sheet，或只写入序表的部分行，或只写入指定的列：=file(“e:/scores.xlsx”).xlsexport@t(A1,No,Name,Class,Maths)

xlsexport函数还可以方便地追加数据，比如对于已经存在且有数据的xls，将序表A1追加到该文件末尾，外观风格与原文件末行保持一致：=file(“e:/scores.xlsx”).xlsexport@a(A1)

不规则片区写入数据，可以使用前面的xlscell函数。比如，xls中蓝色单格是不规则的表头，需要在相应的白色单格中填入数据，如下图：

直接用POI要大段冗长的代码，而SPL代码就简短许多：

注意，第6、9、11行有连续单格，SPL可以简化代码一起填入，POI只能依次填入。

SPL提供足够的查询计算能力

查询计算是Excel处理任务的重点，SPL提供了丰富的计算函数、字符串函数、日期函数，以及标准SQL语法，不仅支持日常的xls计算，也能计算内容不规则的xls和逻辑复杂的xls。

SPL提供了丰富的计算函数，可直接完成基础计算。比如前面的分组汇总，只要一句：

A1.groups(SellerId;sum(Amount))

更多计算：

条件查询：A1.select(Amount>1000 && Amount<=3000 && like(Client,”S“))

排序：A1.sort(Client,-Amount)”

去重：A1.id(Client)”

关联两个xlsx：join(T(“D:/Orders.xlsx”):O,SellerId; T(“D:/Employees.xls”):E,EId).new(O.OrderID,O.Client,O.SellerId,O.Amount,O.OrderDate, E.Name,E.Gender,E.Dept)”

TopN：T(“D:/Orders.xls”).top(-3;Amount)

组内TopN （开窗函数）：T(“D:/Orders.xls”).groups(Client;top(3,Amount))

SPL支持大量日期函数和字符串函数，代码量更短，开发效率更高。比如：

时间类函数，日期增减：elapse(“2020-02-27”,5) //返回2020-03-03

星期几：day@w(“2020-02-27”) //返回5，即星期4

N个工作日之后的日期：workday(date(“2022-01-01”),25) //返回2022-02-04

字符串类函数，判断是否全为数字：isdigit(“12345”) //返回true

取子串前面的字符串：substr@l(“abCDcdef”,”cd”) //返回abCD

按竖线拆成字符串数组：”aa|bb|cc”.split(“|”) //返回[“aa”,”bb”,”cc”]

SPL还支持年份增减、求年中第几天、求季度、按正则表达式拆分字符串、拆出SQL的where或select部分、拆出单词、按标记拆HTML等功能。

SPL提供了标准SQL语法，可以像对数据库表一样直接对xls文件进行查询，极大地降低了数据库程序员的学习门槛：

filter：$select * from d:/sOrder.xlsx where Client like ‘%S%’ or (Amount>1000 and Amount<=2000)sort：$select * from sales.xls order by Client,Amont descdistinct：$ select distinct(sellerid) from sales.xls group by…having：$select year(orderdate) y,sum(amount) s from sales.xls group by year(orderdate) having sum(amount)>=join：$select e.name, s.orderdate, s.amount from sales.xls s left join employee.xlsx e on s.sellerid= e.eid

SPL支持SQL-92标准中大部分语法，包括集合计算、case when、with、嵌套子查询等，详见<a href=”http://c.raqsoft.com.cn/article/33″ rel=”nofollow”>《没有 RDB 也敢揽 SQL 活的开源金刚钻 SPL》</a>

内容不规则的xls，一般的类库都无能为力，SPL语法灵活函数丰富，可轻松解决处理。比如Excel单格里有很多”key=value”形式的字符串，需要整理成规范的二维表，以进行后续计算：

逻辑复杂的计算，SQL和存储过程都难以实现，SPL的计算能力更强，可轻松解决此类问题。比如，计算某支股票最长的连续上涨天数：

SPL支持更优的应用架构

SPL是解释型语言，提供JDBC接口，可以用SQL或存储过程的形式被JAVA集成，不仅降低了架构的耦合性，还能支持热切换。SPL还支持多种数据源，并支持跨数据源计算。

SPL提供了JDBC接口，可被JAVA轻松调用。简单的SPL代码可以像SQL一样，直接嵌入JAVA，比如条件查询：

SPL支持计算外置，可降低计算代码和前端应用的耦合性。复杂的SPL代码可以先存为脚本文件，再以存储过程的形式被JAVA调用：

SPL是解释型语言，通过外置代码可实现热切换。解释型语言无须编译，修改后可立即执行，无须重启JAVA应用，可降低维护工作量，提高系统稳定性。

SPL支持多种文件数据源，除了xls外，SPL还能读写csv xtXMLJson等文件，比如对txt进行条件查询：

T(“sOrders.txt”).groups(SellerId;sum(Amount))

$select * from d:/sOrders.txt where Client like ‘%S%’ or (Amount>1000 and Amount<=2000)

SPL支持跨数据源计算，比如xls和txt的关联计算：

=join(T(“D:/Orders.xlsx”):O,SellerId; T(“D:/Employees.txt”):E,EId).new(O.OrderID,O.Client,O.SellerId,O.Amount,O.OrderDate, E.Name,E.Gender,E.Dept)”

SPL还能访问各类关系型数据库，WebService、Restful等网络服务， Hadoop、redis、Kafka、Cassandra等NoSQL。

POI只适合简单的xls解析生成任务，且未提供查询计算能力。SPL对POI进行了封装，内置高级读写函数，不仅可以大幅简化代码，还能进行较不规则甚至很不规则的xls解析生成任务。SPL额外提供了强大的计算能力，不仅支持日常的Excel查询计算，还可计算内容不规则的xls和逻辑复杂的xls。SPL支持更优的应用架构，可实现代码低耦合和热切换，支持多种数据源和跨数据源计算。

SPL资料

SPL官网
SPL下载
SPL源代码

欢迎对SPL有兴趣的加小助手（VX号：SPL-helper），进SPL技术交流群欢迎关注我的公告号：字母哥杂谈，回复003赠送作者专栏《docker修炼之道》的PDF版本，30余篇精品docker文章。字母哥博客：zimug.com

版本名称说明地址 RXThinkCMF_TP3.2 专业版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_TP3.2 RXThinkCMF_TP3.2 旗舰版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_TP3.2_PRO RXThinkCMF_TP5.1 专业版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_TP5.1 RXThinkCMF_TP5.1 旗舰版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_TP5.1_PRO RXThinkCMF_TP6.x 专业版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_TP6 RXThinkCMF_TP6.x 旗舰版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_TP6_PRO RXThinkCMF_LV5.8 专业版最新开源版本，master 分支 https://gitee.com/laravel520/RXThinkCMF_LV5.8 RXThinkCMF_LV5.8 旗舰版最新开源版本，master 分支 https://gitee.com/laravel520/RXThinkCMF_LV5.8_PRO ThinkPhp3.2+Vue+ElementUI 旗舰版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_EVTP3.2_PRO ThinkPhp3.2+Vue+AntDesign 旗舰版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_AVTP3.2_PRO ThinkPhp5.1+Vue+ElementUI 旗舰版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_EVTP5.1_PRO ThinkPhp5.1+Vue+AntDesign 旗舰版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_AVTP5.1_PRO ThinkPhp6.x+Vue+ElementUI 旗舰版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_EVTP6_PRO ThinkPhp6.x+Vue+AntDesign 旗舰版最新开源版本，master 分支 https://gitee.com/ruoxi520_admin/RXThinkCMF_AVTP6_PRO Laravel8.x+Vue+ElementUI 旗舰版最新开源版本，master 分支 https://gitee.com/laravel520/RXThinkCMF_EVL8_PRO Laravel8.x+Vue+AntDesign 旗舰版最新开源版本，master 分支 https://gitee.com/laravel520/RXThinkCMF_AVL8_PRO

领课教育系统（roncoo-education）是基于领课网络多年的在线教育平台开发和运营经验打造出来的产品，致力于打造一个各行业都适用的分布式在线教育系统。系统采用前后端分离模式，前台采用vue.js为核心框架，后台采用Spring Cloud为核心框架。系统目前主要功能有课程点播功能，支持多家视频云的接入，课程附件管理功能，支持多家存储云的接入，可以帮助个人或者企业快速搭建一个轻量级的在线教育平台。

11.0.0 版本更新内容

 1. 业务流程重新设计，优化现在的业务流程(课程由管理员维护，不再依赖讲师)，并对UI进行了升级优化。 2. 优化支付流程，直接对接官方支付渠道(包括支付宝和微信)，解耦龙果支付 3. 定时任务功能升级，改用xxl-job，解决分布式调度问题 4. 重构后端工程项目，进行升级和优化（特别提醒：不兼容之前的版本，建议直接使用最新版本：11.0.0） 5. 重构Admin工程，进行架构升级和页面重构优化(由vue2.0升级为vue3.0) 6. 重构Web工程，进行代码重构和页面优化

关注公众号

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

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

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

Spring Framework 6.0 发布了首个 RC 版本。

发布公告写道，Spring Framework 6.0 作为重大更新，目前 RC1 要求使用 Java 17 或更高版本，并且已迁移到 Jakarta EE 9+（在命名空间中取代了以前基于的 EE API），以及对其他基础设施的修改。基于这些变化，Spring Framework 6.0 支持最新 Web 容器，如 Tomcat 10 / Jetty 11，以及最新的持久性框架 Hibernate ORM 6.1。这些特性仅可用于 Servlet API 和 JPA 的 jakarta 命名空间变体。

此版本的一项重要变化是完成对 Spring 应用上下文的 AOT 转换和相应的 AOT 处理支持的基础。该变化有助于优化部署安排，从微调的 JVM 部署到对 GraalVM 原生镜像的“一等公民”支持（阅读相关的 Spring Boot 3 文章）。

值得一提的是，开发者可通过此版本在基于 Spring 的应用中体验“虚拟线程”（JDK 19 中的预览版“Project Loom”），查看此文章了解更多细节。现在提供了自定义选项来插入基于虚拟线程的实现，目标是在 Project Loom 正式可用时提供“一等公民”的配置选项。

除了上述的变化，Spring Framework 6.0 还包含许多其他改进和特性，例如：

提供基于服务接口的 HTTP 接口客户端
对 RFC 7807 问题详细信息的支持
Spring HTTP 客户端提供基于 Micrometer 的可观察性
……

此外，团队称将在下周发布 Spring Boot 3.0 首个 RC 版本，以及 Spring Framework 6.0 的第二个 RC，然后在 11 月正式 GA。

下载地址 | 新特性介绍

前言

solon是一款小而美的应用开发框架。拥有轻量、高性能、内存占用低、打包文件小、启动速度快等优势，Mybatis Plus也是早早的支持了solon。希望国产开源软件越来越好是整个开源社区的共同愿望，所以easy-trans本次也发布了solon的版本。

因为是第一个版本，所以功能比sp版本稍微弱一点点点点，ORM框架目前只支持MP，不支持微服务翻译。其他的和sp版本功能相同。

功能

1 我有一个id，但是我需要给客户展示他的title/name 但是我又不想自己手动做表关联查询
2 我有一个字典码 sex 和一个字典值0 我希望能翻译成男给客户展示。
3 我有一组user id 比如 1，2,3 我希望能展示成张三,李四,王五给客户
4 我有一个枚举，枚举里有一个title字段，我想给前端展示title的值给客户
5 我有一个唯一键(比如手机号，身份证号码，但是非其他表id字段)，但是我需要给客户展示他的title/name 但是我又不想自己手动做表关联查询

食用步骤

maven引入

因为阿里云仓库软件更新，所以如果依赖下载不了请切到中央仓库。

初始化字典缓存(没有字典表的项目请无视本步骤)

定义vo，使用@Trans 注解标记哪些字段需要翻译

在controller调用翻译服务，对数据进行翻译。

访问controller查看结果，返回的student对象中已经包含了学校名称，性别等中文的翻译结果

源码地址

solon版本源码地址：https://gitee.com/fhs-opensource/easy_trans_solon

springboot版本源码地址：https://gitee.com/fhs-opensource/easy_trans

文档地址：https://gitee.com/fhs-opensource/easy_trans/wikis

技术支持

我在solon的官网微信群中，或者查看git仓库的readme添加easy trans官网群获取技术支持。

漏洞描述

protocol-buffers 是一种与语言无关、与平台无关的可扩展机制，用于序列化结构化数据。

protobuf-java core 和 lite 的的受影响版本中存在输入验证不当漏洞，导致在解析二进制和文本格式数据存在拒绝服务问题。攻击者可利用此漏洞制造包含多个具有重复或未知字段的非重复嵌入消息实例的输入流，从而会导致对象在可变和不可变形式之间来回转换，进而导致潜在的长时间垃圾收集暂停，造成拒绝服务。

漏洞名称 protobuf-java 存在输入验证不当漏洞漏洞类型输入验证不恰当发现时间 2022-10-13 漏洞影响广度小 MPS编号 MPS-2022-56472 CVE编号 CVE-2022-3171 CNVD编号 –

影响范围

com.google.protobuf:protobuf-javalite@[3.17.0-rc-1, 3.19.6)

com.google.protobuf:protobuf-javalite@(-∞, 3.16.3)

com.google.protobuf:protobuf-javalite@[3.21.0-rc-1, 3.21.7)

com.google.protobuf:protobuf-javalite@[3.20.0-rc-1, 3.20.3)

protobuf@影响所有版本

com.google.protobuf:protobuf-java@[3.16.0, 3.16.3)

com.google.protobuf:protobuf-java@[3.19.0, 3.19.6)

com.google.protobuf:protobuf-java@[3.20.0, 3.20.3)

com.google.protobuf:protobuf-java@[3.21.0, 3.21.7)

com.google.protobuf:protobuf-javalite@[3.16.0, 3.16.3)

com.google.protobuf:protobuf-javalite@[3.21.0, 3.21.7)

com.google.protobuf:protobuf-javalite@[3.20.0, 3.20.3)

com.google.protobuf:protobuf-javalite@[3.19.0, 3.19.6)

com.google.protobuf:protobuf-kotlin@[3.19.0, 3.19.6)

com.google.protobuf:protobuf-kotlin@[3.20.0, 3.20.3)

com.google.protobuf:protobuf-kotlin@[3.21.0, 3.21.7)

com.google.protobuf:protobuf-kotlin-lite@[3.16.0, 3.16.3)

google-protobuf@[3.16.0, 3.16.3)

google-protobuf@[3.20.0, 3.20.3)

google-protobuf@[3.21.0, 3.21.7)

com.google.protobuf:protobuf-kotlin-lite@[3.20.0, 3.20.3)

com.google.protobuf:protobuf-kotlin@[3.16.0, 3.16.3)

google-protobuf@[3.19.0, 3.19.6)

com.google.protobuf:protobuf-kotlin-lite@[3.19.0, 3.19.6)

com.google.protobuf:protobuf-kotlin-lite@[3.21.0, 3.21.7)

修复方案

将组件 com.google.protobuf:protobuf-javalite 升级至 3.20.3 及以上版本

升级 com.google.protobuf:protobuf-kotlin到 3.21.7 或 3.20.3 或 3.19.6 或 3.16.3 或更高版本

升级com.google.protobuf:protobuf-kotlin-lite到 3.21.7 或 3.20.3 或 3.19.6 或 3.16.3 或更高版本

升级google-protobuf到 3.21.7 或 3.20.3 或 3.19.6 或 3.16.3 或更高版本

将组件 com.google.protobuf:protobuf-javalite 升级至 3.19.6 及以上版本

将组件 com.google.protobuf:protobuf-javalite 升级至 3.16.3 及以上版本

将组件 com.google.protobuf:protobuf-javalite 升级至 3.21.7 及以上版本

升级 com.google.protobuf:protobuf-java到 3.21.7 或 3.20.3 或 3.19.6 或 3.16.3 或更高版本

升级com.google.protobuf:protobuf-javalite到 3.21.7 或 3.20.3 或 3.19.6 或 3.16.3 或更高版本

将组件 google-protobuf 升级至 3.16.3 及以上版本

参考链接

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

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

https://github.com/protocolbuffers/protobuf/security/advisories/GHSA-h4h5-3hr4-j3g2

https://github.com/protocolbuffers/protobuf

情报订阅

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

具体订阅方式详见：

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

漏洞描述

loader-utils 是一款用于 webpack 加载器的实用程序的工具类。

loader-utils 中的 parseQuery.js 中的 parseQuery 方法中由于未对手动传入的参数进行过滤，从而存在原型污染漏洞。攻击者可用过此漏洞通过传入恶意的参数修改JavaScript对象属性的默认值，从而导致拒绝服或远程代码执行。

漏洞名称 loader-utils v2.0.0 原型污染漏洞漏洞类型动态确定对象属性修改的控制不恰当发现时间 2022-10-13 漏洞影响广度一般 MPS编号 MPS-2022-53514 CVE编号 CVE-2022-37601 CNVD编号 –

影响范围

修复方案

参考链接

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

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

https://github.com/webpack/loader-utils/issues/212

情报订阅

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

具体订阅方式详见：

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

漏洞描述

Dolibarr ERP & CRM 是一个专为中小型企业、基金会和自由职业者设计的现代软件包，用于管理公司或基金会的活动。

Dolibarr ERP & CRM 在15.0.3 及之前版本中存在任意添加管理员和后端远程代码执行漏洞。由于Dolibarr 安装后不会自动添加install.lock，攻击者可以在安装页面手动添加任意管理员，添加成功后可以通过使用菜单的编辑功能将恶意数据添加到数据库中，进而通过 eval 函数恶意执行。

漏洞名称 dolibarr<=15.0.3 存在任意添加管理员和后端远程代码执行漏洞漏洞类型代码注入发现时间 2022-10-13 漏洞影响广度小 MPS编号 MPS-2022-57212 CVE编号 CVE-2022-40871 CNVD编号 –

影响范围

Dolibarr/dolibarr@(-∞, 16.0.0)

修复方案

将组件 Dolibarr/dolibarr 升级至 16.0.0 及以上版本

参考链接

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

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

https://github.com/Dolibarr/dolibarr

https://github.com/youncyb/dolibarr-rce

情报订阅

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

具体订阅方式详见：

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

都什么年代了，还在用传统密码？10月12日，谷歌宣布在 Android 和 Chrome 中正式推行密钥登录“PassKey”，以逐步替代长期使用的密码登录“PassWord”。

推出的密钥登录可以认为是“生物密码”和“授权登录”的结合。用户可以在 Android 手机上创建一个基于公钥加密的密钥凭据，创建密钥的时候需要对本人进行生物特征识别，比如“指纹”或者“面部识别”等。

创建完毕后，这个密钥凭据可用于解锁所有在线帐户 —— 既可以解锁 Android 手机上的帐户，也可以解锁附近所有设备的帐户。是的，这个 FIDO 密匙登录功能由微软 / 苹果 / 谷歌联合出品，属于行业标准。因此它是跨平台的，包括 Windows、macOS 和 iOS 以及 ChromeOS。换而言之，你可以用 Android 手机的密钥凭据解锁上述所有系统的帐户和网站。

在谷歌的眼中，密码登录这种老旧的身份验证方法很容易被钓鱼或者盗号等方法影响，安全性不高。而密钥登录则大为不同，它不能重复使用，也不会泄露服务器漏洞，还能保护用户免受网络钓鱼的攻击以及忘记密码的困扰，即使丢失了手机， FIDO 密钥也可以从云备份安全地同步到新手机。

不过，现在这个密钥登录功能还不完善，只是一个重要的里程碑，实现了两个关键功能：

用户可以在 Android 设备上创建和使用密钥，密钥通过 Google 密码管理器进行同步。
开发人员可以通过 WebAuthn API、Android 和其他支持的平台，使用 Chrome 在网站上为用户构建密钥支持。

如果要在网站上添加密钥登录功能，开发者需要注册 Google Play Services 测试版，并使用 Chrome Canary 版本。

密钥登录功能的下一个里程碑是原生的 Android 应用 API，原生 API 将为应用程序提供多种登录方式，用户可以选择密钥登录，或是使用已保存的密码登录。

近日，深圳市亿道数码技术有限公司（以下简称“亿道数码”）签署了openKylin社区 CLA(Contributor License Agreement 贡献者许可协议)，正式加入openKylin开源社区。

亿道数码成立于2010年，为亿道信息旗下子公司之一，是一家专注于消费类移动终端、行业终端及人工智能终端解决方案的国家级高新技术企业，国内及全球领先的平板电脑和笔记本电脑解决方案提供商。

亿道数码专注于笔记本电脑、平板电脑、智能商显、人脸&语音交互显示终端及国产化产品的研发与生产，产品主要应用在家庭、办公、娱乐、教育、商业、交通、健康等领域，亿道数码坚持一切以客户价值为依归，通过与合作伙伴的紧密联接，构建共赢的产业生态。

在加入openKylin社区后，亿道数码将开放合作，发挥平台的能动性，将上游技术和自身的供应链优势相结合，助力openKylin社区快速发展，成为引领桌面操作系统发展的根社区。

社区会员持续招募中

目前，openKylin社区会员招募正在火热进行中，欢迎更多企业伙伴加入，携手共建，打造桌面操作系统顶级社区，推动国产操作系统产业生态健康发展。详情可查看：【开源聚力，共创未来 | openKylin（开放麒麟）社区会员招募火热进行中！】

数据库开发运维作为研发流程上的刚需场景，目前在行业内还尚未形成标准或者主流方案。 Zadig 作为链接开发者的云原生持续交付平台，对该领域抱有持续的关注度。今天我们介绍的主角是开源数据库版本管理工具 Flyway，本文将介绍 Flyway 如何结合 Zadig，实现数据和业务同步变更的软件交付实践。

Flyway 是什么？

Flyway (https://flywaydb.org)是一款开源的数据库版本管理工具，Flyway 可以独立于应用实现管理并跟踪数据库变更，支持数据库版本自动升级，并且有一套默认的规约，无需复杂的配置，Migrations 可以写成 SQL 脚本，也可以写在 Java 代码中，不仅支持 Command Line 和 Java API，还支持 Build 构建工具和 Spring Boot 等，同时在分布式环境下能够安全可靠地升级数据库。

研发流程中如何做数据变更？

下面以 Flyway 中支持的 SQL 脚本为例，简单阐述研发过程中如何顺滑地执行数据变更。

SQL 脚本存放在 Git 代码库中，建议和业务代码放一起管理，这样业务代码的变更和数据的变更可以完全匹配。
开发人员以 Pull Request 的方式提交业务代码和数据库变更 SQL 到 Git 代码库。
代码审核人员对开发提交的 Pull Request 内容进行审核，通过后合并。自动触发 Zadig 工作流的执行，包含任务：Flyway 数据变更、服务构建、部署 dev 环境、测试。
测试人员触发 Zadig 工作流，包含任务：Flyway 数据变更、服务构建、部署 qa 环境、测试。
运维人员触发 Zadig 工作流针对预发/生产环境进行数据变更和业务发布。

结合 Zadig 实践

准备工作

搭建项目 microservice-demo，参考教程如何使用 GitLab + Zadig 实现产品级持续交付。
准备数据变更相关文件，文件保存在 microservice-demo 项目代码库中。

根据实际的情况修改 Flyway config 文件中数据库相关配置。

初始化 MySQL 数据库，创建不同环境使用的数据库 dev、qa、prod。

对于新创建的数据库无需做额外的初始化操作，对于已有的数据库需要使用 flyway baseline 命令对数据库进行初始化

下面主要介绍研发流程中涉及的工作流、、的配置和使用。

第一步：配置工作流

包括：新建工作流 -> 配置数据变更任务 -> 配置构建任务 -> 配置部署任务。

新建自定义工作流

「新建工作流」-> 选择「自定义工作流」-> 输入工作流名称。

配置数据变更任务

添加阶段。「+ 阶段」-> 填写阶段名称数据变更。
添加通用任务。「+ 任务」->选择「通用任务」。
配置通用任务，执行 flyway migration。

a. 新建 flyway 软件包。从 Flyway 官网下载安装包，添加到 Zadig 的软件包管理。具体添加方式参考：软件包管理 | Zadig 文档 b. 选择 flyway 软件包、配置代码库信息和 shell 脚本执行。具体脚本参考如下：

至此，Flyway 数据变更任务配置完成，更多 Flyway 的工作原理和 CLI 使用方式详见 Flyway 官方文档。

配置构建任务

添加构建阶段 -> 「+ 任务」-> 选择「构建」。
配置任务名称 -> 选择镜像仓库 -> 选择服务组件及构建，「确定」。

配置部署任务

添加阶段 -> 「+ 任务」-> 选择「部署」。
配置任务名称 -> 选择 dev 环境 -> 选择服务来源：其他任务输出，选择构建任务，「确定」。

工作流任务配置完成后，「保存」。至此已完成工作流任务的配置，其他工作流的具体配置类似，不再赘述。

第二步：执行工作流

「执行」，确认执行变量，选择对应需要更新的服务组件和代码信息，「启动任务」。在任务详情页面任务，查看 Flyway 数据变更执行过程的详细日志。

第三步：配置 Git 触发器

在工作流配置页面「触发器」
「+ 添加」
配置触发器。配置代码库信息、触发事件和工作流执行变量等。

第四步：SQL 变更触发工作流

添加 SQL 脚本，提交到代码库。
自动触发工作流执行。

更多 Zadig 的使用姿势可参考官网文档。

扩展阅读

关于数据库/SQL 版本管理工具的更多介绍可参考以下内容。

数据库/SQL 版本管理工具选型指北
Zadig + Liquibase，数据变更、业务变更、数据回滚，一键搞定
Zadig + Mysql 代码、数据变更一站式编排，可靠丝滑交付

Zadig，让工程师更专注创造。欢迎加入开源吐槽群🔥

Zadig on Github
Zadig on Gitee

摘要：高性能、大容量、低成本、强稳定性，广告业务需要的Ta都有

本文分享自华为云社区《广告业务存储神器：华为云GaussDB for Redis》，作者： GaussDB 数据库。

一、从需求场景说起，什么是RTA广告业务？

在互联网时代，媒体平台逐渐成为广告业务的主体，而作为广告主的企业往往每年需花费数亿甚至数十亿广告费，却依然难以准确触达目标用户，这就造成大量资金浪费。在这样的需求场景下，RTA广告业务模式逐渐流行起来。

RTA 即Realtime API的简称，是一套接口服务，用于满足广告主实时个性化的投放需求，在竞价中减少资金浪费。简单来说，RTA大体流程如下：

媒体在将广告曝光给用户前，先通过RTA接口询问广告主是否参与本次竞价；
广告主结合自己的画像数据（一般是百GB~数TB的key-value数据）进行决策，快速响应媒体侧，表明是否要参与本次曝光竞价，以及具体的曝光策略；
媒体平台根据价高者得原则，进行精准目标广告投放。

RTA广告业务流程图

RTA让广告投放变得更精准，更省钱，还可以满足许多不同的投放需求，例如获取新用户、召回流失用户等。

二、聊聊RTA中的数据存储选型

对广告主来说，RTA业务价值明显，但媒体侧可是设置了不小的技术门槛，一般要求RTA系统高峰承载20w+ QPS，50到100ms快速响应。当不达标时，媒体侧会有降级和清退机制，例如暂时关闭广告主的RTA接入通道。
因此，RTA业务的首要需求是使用靠谱的画像数据库：

1. 毫秒级响应，支持数十万级QPS
2. 稳定性高，关键时刻不能掉链子
3. 支持百GB~数TB的画像存储，且成本可控

根据经验，很多公司会使用开源Redis集群来做这件事，但其实开源Redis并不太适合这类大数据场景：

一方面，虽然开源Redis并发性能和响应都很优秀，但终究只是缓存，无法提供数据库级的稳定性保障，丢数据、fork抖动、分片不均OOM、扩容耗时久等等，都是很常见的问题。

另一方面，由于开源Redis中存放的数据无法突破内存限制，上百GB的数据存储价格非常昂贵，例如512GB规格的开源Redis接近5w/月。

在这类大数据业务场景下，我们推荐使用华为云数据库GaussDB for Redis做画像数据存储。

三、大数据业务存储神器：华为云数据库GaussDB for Redis

GaussDB for Redis是华为云企业级存算分离Redis数据库，使用上与开源Redis别无二致，并且能够兼顾缓存与存储两类典型场景：

1. 内存+分布式存储池

提供毫秒级响应，同时实现大幅降本

2. 命令兼容度>98%

支持业务零改造平迁

3. 容量最大支持36TB

保障数据库级别可靠存储，压缩比高

4. 算力按需原配

用多少买多少，最大支持千万级QPS

5. 无感热扩容

128GB到512GB也只需一秒

6. 增强版ACL

支持多DB访问权限隔离

RTA广告业务对画像存储的核心需求是：响应快、稳定性高、大容量且不贵，GaussDB for Redis充分满足这类大数据业务需求。

超低时延，性能满足媒体侧要求

根据现网的案例经验，在数十万QPS流量下，GaussDB for Redis可稳定保持平均时延1ms，p99时延2ms。
媒体侧一般对广告主端到端响应要求在50~100ms，这其中包括了业务及网络链路的耗时，GaussDB for Redis可以很好地满足响应要求，并给业务链路留有充足的余量。

为什么GaussDB for Redis在存算分离的架构下还能提供低时延访问？

1. 自动冷热分离，计算层的内存资源会被用来充分加速热数据
2. 存储池是基于高性能Nvme SSD和RDMA网络所构建，响应速度其实也很快
  实际上，响应快速并非内存的专利，Nvme SSD同样有优秀的时延表现，下图是市面上某款Nvme SSD的性能指标：

作为存算分离的数据库，稳定性远超缓存Redis

开源Redis的稳定性问题存在已久，单线程、fork机制、Gossip协议……这些都是让开源Redis稳定性不够好的原因。在小数据量缓存场景问题不一定经常出现，但在百GB的大数据存储场景下很容易成为打破系统稳定的隐患。
GaussDB for Redis存算分离架构对稳定性的提升是巨大的。在扩容场景，只需调整存储池配合，即可1秒完成扩容，业务0感知。由于数据全部存储在分布式存储池中，当计算节点发生故障，数据依然可见，业务只感知秒级抖动。同时，也不会发生分片数据不均OOM问题。

存储百GB画像数据，比缓存Redis成本节省 50%以上

GaussDB for Redis在这类场景下能够帮助企业实现有效降本，原因是：

1、内存+分布式存储池（Nvme SSD）

开源Redis技术上无法突破内存限制，因此成本会随着每涨1GB而线性增长，大数据业务中很容易带来成本痛点。

GaussDB for Redis分布式存储池采用的高性能Nvme SSD硬件成本虽然比普通SSD高，但是跟内存相比还是比较高性价比的。另外还支持根据实际所需QPS购买计算节点，避免不必要的算力成本浪费。

2、高压缩比

很多画像类业务使用protobuf格式，GaussDB for Redis采用了逻辑数据+块数据双重压缩机制，对于protobuf的压缩比效果很好。根据现网案例经验，500GB的protobuf数据写入GaussDB for Redis后，实际占用的存储空间可压缩到160G，压缩率30%。

四、总结

RTA广告竞价业务近年来发展潜力巨大，一方面要满足媒体侧的性能指标要求，另一方面又要承担企业降本重任。在这类典型大数据业务中，往往需要一款能够兼顾性能与存储降本需求的KV数据库来做画像存储，华为云数据库GaussDB for Redis无论从性能、稳定性，还是大容量、低成本，都充分满足这类场景的需求，是其最佳存储选型。

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

摘要：JDK 1.5开始提供Scheduled Thread PoolExecutor类，Scheduled Thread Pool Executor类继承Thread Pool Executor类重用线程池实现了任务的周期性调度功能。

本文分享自华为云社区《【高并发】ScheduledThreadPoolExecutor与Timer的区别和简单示例》，作者：冰河。

JDK 1.5开始提供ScheduledThreadPoolExecutor类，ScheduledThreadPoolExecutor类继承ThreadPoolExecutor类重用线程池实现了任务的周期性调度功能。在JDK 1.5之前，实现任务的周期性调度主要使用的是Timer类和TimerTask类。本文，就简单介绍下ScheduledThreadPoolExecutor类与Timer类的区别，ScheduledThreadPoolExecutor类相比于Timer类来说，究竟有哪些优势，以及二者分别实现任务调度的简单示例。

二者的区别

线程角度

Timer是单线程模式，如果某个TimerTask任务的执行时间比较久，会影响到其他任务的调度执行。
ScheduledThreadPoolExecutor是多线程模式，并且重用线程池，某个ScheduledFutureTask任务执行的时间比较久，不会影响到其他任务的调度执行。

系统时间敏感度

Timer调度是基于操作系统的绝对时间的，对操作系统的时间敏感，一旦操作系统的时间改变，则Timer的调度不再精确。
ScheduledThreadPoolExecutor调度是基于相对时间的，不受操作系统时间改变的影响。

是否捕获异常

Timer不会捕获TimerTask抛出的异常，加上Timer又是单线程的。一旦某个调度任务出现异常，则整个线程就会终止，其他需要调度的任务也不再执行。
ScheduledThreadPoolExecutor基于线程池来实现调度功能，某个任务抛出异常后，其他任务仍能正常执行。

任务是否具备优先级

Timer中执行的TimerTask任务整体上没有优先级的概念，只是按照系统的绝对时间来执行任务。
ScheduledThreadPoolExecutor中执行的ScheduledFutureTask类实现了java.lang.Comparable接口和java.util.concurrent.Delayed接口，这也就说明了ScheduledFutureTask类中实现了两个非常重要的方法，一个是java.lang.Comparable接口的compareTo方法，一个是java.util.concurrent.Delayed接口的getDelay方法。在ScheduledFutureTask类中compareTo方法方法实现了任务的比较，距离下次执行的时间间隔短的任务会排在前面，也就是说，距离下次执行的时间间隔短的任务的优先级比较高。而getDelay方法则能够返回距离下次任务执行的时间间隔。

是否支持对任务排序

Timer不支持对任务的排序。
ScheduledThreadPoolExecutor类中定义了一个静态内部类DelayedWorkQueue，DelayedWorkQueue类本质上是一个有序队列，为需要调度的每个任务按照距离下次执行时间间隔的大小来排序

能否获取返回的结果

Timer中执行的TimerTask类只是实现了java.lang.Runnable接口，无法从TimerTask中获取返回的结果。
ScheduledThreadPoolExecutor中执行的ScheduledFutureTask类继承了FutureTask类，能够通过Future来获取返回的结果。

通过以上对ScheduledThreadPoolExecutor类和Timer类的分析对比，相信在JDK 1.5之后，就没有使用Timer来实现定时任务调度的必要了。

二者简单的示例

这里，给出使用Timer和ScheduledThreadPoolExecutor实现定时调度的简单示例，为了简便，我这里就直接使用匿名内部类的形式来提交任务。

Timer类简单示例

源代码示例如下所示。

运行结果如下所示。

ScheduledThreadPoolExecutor类简单示例

源代码示例如下所示。

运行结果如下所示。

注意：关于Timer和ScheduledThreadPoolExecutor还有其他的使用方法，这里，我就简单列出以上两个使用示例，更多的使用方法大家可以自行实现。

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

本篇是「标签画像系列」的第四篇，此前我们已经介绍过了标签画像体系建设方法论、标签体系设计与加工、标签加工与落库，这次我们来介绍一下「标签评分」。

标签评分是标签治理的一个重要措施，通过给标签打分，可清晰直观的从各个维度评估标签，掌握标签真实使用情况，进行标签持续优化，助力业务运营。同时，也能帮助数据团队判断哪些标签更应该投入计算与存储资源，合理规划集群资源。

一、为何要使用标签评分？

经过前期标签体系设计、标签加工，标签终于可以上线，让业务人员使用，发挥价值了！

随着标签上线一段时间后，我们开始关心每天占用计算资源与存储空间，跑出来的上百个标签，业务同学真的用到了多少，业务收益是否能覆盖数据成本呢？标签上线后，其质量怎么样，是否存在老规则不适用、需要持续优化的情况？

带着这一问题，我们需要用一种方法来评估标签上线后的使用情况，标识各个标签的价值。参考电影评分、花呗评分等形式，我们决定也给标签打个分、排个序，简单明了。

二、标签评分模型

标签评分模型，经过考虑我们选取了5个维度作为评分入参：

标签总评分= a * 标签使用度评分 + b * 标签关注度评分 + c * 标签质量评分 + d * 标签持续优化读评分 + e * 标签安全度评分

其中标签使用度、标签关注度、标签质量、标签持续优化度作为核心维度，标签安全度可根据实际情况考虑是否纳入。a、b、c、d、e是权重，总和为100%。

01 标签使用度评分

标签使用度，用以评估标签被分析、外部系统的使用情况。

在袋鼠云标签产品中，标签有这几种使用场景：

• 标签引用：如原子标签被衍生标签应用、衍生标签被组合标签引用等，基于该场景，计算“标签引用次数”指标。

• 标签分析：标签在标签圈群、群组画像、群组对比、显著性分析等画像分析功能中被分析的情况，计算“标签分析次数”指标。

• 标签调用：标签通过数据API被外部应用查询的次数，计算“标签调用次数”指标。

基于以上3个指标，我们首先采用Sigmoid函数将指标转化为评分，再将各个指标的评分加权汇总成标签使用度评分。

02 标签关注度评分

标签关注度，用以评估被搜索、查看、收藏的情况。

袋鼠云标签产品中，标签关注度与以下场景有关：

• 标签搜索：标签在标签市场被用户搜索的情况，计算“标签搜素次数”指标。

• 标签查看：标签被查看基础信息、分析页面等的次数，计算“标签查看次数”指标

• 标签收藏：收藏该标签的用户数，计算“收藏用户数”指标

以上3个指标可反映标签的关注热度，我们依然采用Sigmoid函数将指标转化为评分，再将各个指标的评分加权汇总成标签关注度评分。

03 标签质量评分

标签质量，用以评估用户被打标情况，反映标签规则的合理性。

当我们定义了标签和标签值，经过计算之后，标签值打在用户身上的很少，那说明我们的规则执行不合理。比如我们定义了“活跃度”这个标签，分为“高活跃、中活跃、低活跃度”等，但真实被打上的这个标签的用户，低于70%，还有很大一部分比例是空值，未打上该标签，说明我们制定的标签值规则有漏洞，需要完善。

系统将计算每个标签的“标签覆盖度”，将覆盖度归一化为分数，转化成评分。

04 持续优化度评分

持续优化度，用以评估标签上线后，是否后续再去优化该标签。

在客户的生命周期中，不断有新用户流入、沉默用户流失。公司战略调整、产品发布等都会影响客户行为，这些变化我们需要以数据的方式呈现，所以我们需要不断根据业务调整、客户变化调整我们的标签策略，以追求可通过标签直接地、迅速地反映客户情况，指导业务运营。

持续优化度，我们通过“标签优化次数”指标来评估，指标签上线后标签被编辑再次发布的的次数。我们同样采用Sigmoid函数将指标转化为评分。

05 安全度评分

标签安全度，不能反映标签的热度，但也将其作为了标签评分的一个维度，可根据企业情况考虑是否纳入。

在袋鼠云标签产品中，标签安全相关的策略有：

• 标签的可见度：标签可编辑、可查看的用户范围

• 标签使用是否需要申请授权：标签发布后，其他人使用该标签，是否需要申请审批

• 标签是否进行行级权限控制：上面我们控制了标签的列权限，行级权限反映该标签是否设置了行级权限

• 标签是否脱敏：标签是否进行脱敏

根据标签的安全度策略配置情况，我们也采用评分的方式来评估。

基于以上5个维度的评分，我们根据前面提的公式加权汇总，得到总评分。

三、标签评分的应用

基于标签评分，为了更加直观的让标签管理员、业务人员查看热门标签、沉默标签等，通过排行榜的方式呈现：

01 热门标签排行榜

基于标签的使用度、关注度、持续优化度3个角度来计算标签的热门评分，展示TOP N的热门标签。

02 沉默标签排行榜

热门的标签的反向排序便是沉默标签，沉默标签说明这些标签使用率很低，可考虑定期下线，节省集群资源。

03 综合排行榜

综合排行榜便根据标签的综合评分进行排序，从标签使用度、关注度、持续优化度、质量、安全等几个维度评估，全面评估标签。

04 标签使用度、关注度、持续有优化度、质量、安全分榜单排行

用户可根据自己更加关注的维度，查看标签使用度、关注度、持续优化度、质量、安全各个子维度的排行榜。同时，可查看各个标签的具体指标，如使用度维度，可查看各个标签的当前引用次数、分析次数、调用次数，针对具体指标具体分析，满足不同的标签分析场景。

标签评分模型上线后，我们需要根据实际情况调整不同维度的权重，符合自身实际情况。当经过一段时间的应用，大家认可这套评估逻辑之后，便可以将静态化的评分展示转化为动态化的告警、自动化治理等，可设置标签质量告警、评分告警，自动通知标签管理员、责任人等。

以上便是在产品中应用的评分逻辑，希望对大家有所帮助，也可提出不同思路优化评分模型，达到更好的标签治理效果。

袋鼠云开源框架钉钉技术交流群（），欢迎对大数据开源项目有兴趣的同学加入交流最新技术信息，开源项目库地址：https://github.com/DTStack/Taier

版面分析

版面分析指的是对图片形式的文档进行区域划分，定位其中的关键区域，如文字、标题、表格、图片等。

在上图中，最上面有图片区域，中间是标题和表格区域，下面是文字区域。

命令行使用

Python代码使用

 import os import cv2 from paddleocr import PPStructure,save_structure_res if __name__ == '__main__': table_engine = PPStructure(table=False, ocr=False, show_log=True) save_folder = 'https://www.xujun.org/output'  img_path = 'ppstructure/docs/table/1.png'  img = cv2.imread(img_path) result = table_engine(img) save_structure_res(result, save_folder, os.path.basename(img_path).split('.')[0]) for line in result: img = line.pop('img') print(line) while True: cv2.imshow('img', img) key = cv2.waitKey() if key & 0xFF == ord('q'): break  cv2.destroyAllWindows()

运行结果

‘text’, ‘bbox’: [11, 729, 407, 847]

‘text’, ‘bbox’: [442, 754, 837, 847]

‘title’, ‘bbox’: [443, 705, 559, 719]

‘figure’, ‘bbox’: [10, 1, 841, 294]

‘figure_caption’, ‘bbox’: [70, 317, 707, 357]

‘figure_caption’, ‘bbox’: [160, 317, 797, 335]

‘table’, ‘bbox’: [453, 359, 822, 664]

‘table’, ‘bbox’: [12, 360, 410, 716]

‘table_caption’, ‘bbox’: [494, 343, 785, 356]

‘table_caption’, ‘bbox’: [69, 318, 706, 357]

从运行的结果来看，它是将原始图像拆成了图像、图像标题、表格、表格标题、文字和文字标题六个分类。

模型训练

下载PaddleDection框架代码

PaddleDetection: PaddleDetection的目的是为工业界和学术界提供丰富、易用的目标检测模型 (gitee.com)

下载，解压，进入PaddleDection主目录，安装需要的Python库

cocotools安装错误的话可以使用如下命令安装

1 插件概述

问题：什么是Mybatis插件？有什么作用？

一般开源框架都会提供扩展点，让开发者自行扩展，从而完成逻辑的增强。

基于插件机制可以实现了很多有用的功能，比如说分页，字段加密，监控等功能，这种通用的功能，就如同AOP一样，横切在数据操作上

而通过Mybatis插件可以实现对框架的扩展，来实现自定义功能，并且对于用户是无感知的。

2 Mybatis插件介绍

Mybatis插件本质上来说就是一个拦截器，它体现了

Mybatis中针对四大组件提供了扩展机制，这四个组件分别是：

Mybatis中所允许拦截的方法如下：

Executor 【SQL执行器】【update,query,commit,rollback】
StatementHandler 【Sql语法构建器对象】【prepare,parameterize,batch,update,query等】
ParameterHandler 【参数处理器】【getParameterObject,setParameters等】
ResultSetHandler 【结果集处理器】【handleResultSets,handleOuputParameters等】

能干什么？

分页功能：mybatis的分页默认是基于内存分页的（查出所有，再截取），数据量大的情况下效率较低，不过使用mybatis插件可以改变该行为，只需要拦截StatementHandler类的prepare方法，改变要执行的SQL语句为分页语句即可
性能监控：对于SQL语句执行的性能监控，可以通过拦截Executor类的update, query等方法，用日志记录每个方法执行的时间

如何自定义插件？

在使用之前，我们先来看看Mybatis提供的插件相关的类，过一遍它们分别提供了哪些功能，最后我们自己定义一个插件

用于定义插件的类

前面已经知道Mybatis插件是可以对Mybatis中四大组件对象的方法进行拦截，那拦截器拦截哪个类的哪个方法如何知道，就由下面这个注解提供拦截信息

由于一个拦截器可以同时拦截多个对象的多个方法，所以就使用了数组，该注解定义了拦截的完整信息

已经知道了该拦截哪些对象的哪些方法，拦截后要干什么就需要实现方法，在这个方法里面实现拦截后的处理逻辑

3 自定义插件

需求：把Mybatis所有执行的sql都记录下来

步骤：① 创建Interceptor的实现类，重写方法

② 使用@Intercepts注解完成插件签名说明插件的拦截四大对象之一的哪一个对象的哪一个方法

③ 将写好的插件注册到全局配置文件中

①.创建Interceptor的实现类

② 使用@Intercepts注解完成插件签名说明插件的拦截四大对象之一的哪一个对象的哪一个方法

③ 将写好的插件注册到全局配置文件中

核心思想：

就是使用JDK动态代理的方式，对这四个对象进行包装增强。具体的做法是，创建一个类实现Mybatis的拦截器接口，并且加入到拦截器链中，在创建核心对象的时候，不直接返回，而是遍历拦截器链，把每一个拦截器都作用于核心对象中。这么一来，Mybatis创建的核心对象其实都是代理对象，都是被包装过的。

4 源码分析-插件

插件的初始化：插件对象是如何实例化的？插件的实例对象如何添加到拦截器链中的？组件对象的代理对象是如何产生的？
拦截逻辑的执行

插件配置信息的加载

我们定义好了一个拦截器，那我们怎么告诉Mybatis呢？Mybatis所有的配置都定义在XXx.xml配置文件中

对应的解析代码如下（XMLConfigBuilder#pluginElement）：

主要做了以下工作：

遍历解析plugins标签下每个plugin标签
根据解析的类信息创建Interceptor对象
调用setProperties方法设置属性
将拦截器添加到Configuration类的IntercrptorChain拦截器链中

对应时序图如下：

代理对象的生成

Executor代理对象（Configuration#newExecutor）

ParameterHandler代理对象（Configuration#newParameterHandler）

ResultSetHandler代理对象（Configuration#newResultSetHandler）

StatementHandler代理对象（Configuration#newStatementHandler）

通过查看源码会发现，所有代理对象的生成都是通过方法来创建的，进一步查看pluginAll方法

InterceptorChain#pluginAll内部通过遍历Interceptor#plugin方法来创建代理对象，并将生成的代理对象又赋值给target,如果存在多个拦截器的话，生成的代理对象会被另一个代理对象所代理，从而形成一个代理链，执行的时候，依次执行所有拦截器的拦截逻辑代码，我们再跟进去

方法最终将目标对象和当前的拦截器交给方法来创建代理对象。该方法是默认方法，是Mybatis框架提供的一个典型plugin方法的实现。让我们看看在方法中是如何实现代理对象的

最终我们看到其实是通过JDK提供的Proxy.newProxyInstance方法来生成代理对象

以上代理对象生成过程的时序图如下:

拦截逻辑的执行

通过上面的分析，我们知道Mybatis框架中执行Executor、ParameterHandler、ResultSetHandler和StatementHandler中的方法时真正执行的是代理对象对应的方法。而且该代理对象是通过JDK动态代理生成的，所以执行方法时实际上是调用InvocationHandler#invoke方法（Plugin类实现InvocationHandler接口）,下面是Plugin#invoke方法

注：一个对象被代理很多次

问题：同一个组件对象的同一个方法是否可以被多个拦截器进行拦截？

答案是肯定的，所以我们配置在最前面的拦截器最先被代理，但是执行的时候却是最外层的先执行。

具体点：

假如依次定义了三个插件：，。

那么List中就会按顺序存储：，和。

而解析的时候是遍历list，所以解析的时候也是按照：,,的顺序。

但是执行的时候就要反过来了，执行的时候是按照：，和的顺序进行执行。

当 Executor 的某个方法被调用的时候，插件逻辑会先行执行。执行顺序由外而内，比如上图的执行顺序为。

本文由教研团队发布。

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

转载请注明出处！

摘要：2022年9月29日，KubeEdge发布1.12版本。新版本新增多个增强功能，在扩展性、稳定性、安全性上均有大幅提升。

本文分享自华为云社区《KubeEdge 1.12版本发布，稳定性、安全性、可扩展性均带来大幅提升》，作者：云容器大未来。

北京时间2022年9月29日，KubeEdge发布1.12版本。新版本新增多个增强功能，在扩展性、稳定性、安全性上均有大幅提升。

KubeEdge v1.12 新增特性：

▪ 全新的边缘设备管理接口DMI
▪ 全新的Edged实现
▪ EdgeMesh支持高可用（HA）模式
▪ 支持批量远程升级边缘节点
▪ 边缘原生接口支持认证鉴权
▪ CloudHub可靠性增强
▪ 新增摄像头接口标准GigE的 Mapper实现

新特性概览

全新的云原生边缘设备管理接口DMI

1.12版本中，对全新的云原生边缘设备管理标准Device Management Interface（DMI），提供了Alpha版本支持。DMI让设备管理者可以用云原生的方式对边缘设备进行管理，它的设计覆盖了设备生命周期管理、设备数据管理，且解耦了管理面与数据面数据，使KubeEdge的边缘设备管理更稳定、易插拔、更具扩展性。目前本版本支持了边缘设备生命周期管理能力，边缘设备数据管理能力正在实现中。

设备生命周期管理(管理面)

北向依旧通过CRD使用Kubernetes扩展API来管理边缘设备生命周期；南向提供了统一的边缘设备生命周期管理相关的gRPC接口，包括设备注册、设备更新、设备删除、设备状态更新等。边缘设备开发者可以以更统一、更灵活、更标准化的方式来开发Device Mapper。

设备数据管理(数据面)

解耦了设备管理面与数据面，数据面信息可以通过配置灵活地选择在边端被处理或通过数据面通道在云端处理，管理面的云边通道仅传输少量的管控信息，大幅降低了云边通道拥塞的风险，提高了KubeEdge系统的稳定性。

DMI支持用户通过多种形式对边缘设备数据进行访问，包括：

1、Device as a Service（DaaS），通过Service的方式访问、拉取边缘设备数据；
2、通过配置规则的方式，将采集到的设备数据推送到指定接收者

数据消费者包括：云端设备数据消费者应用、边缘端设备数据消费者应用、第三方数据消费者应用、数据流转平台broker、云端或边缘端数据持久化数据库等。

通过DMI接口，开发者只需按照DMI接口标准实现对应协议的Mapper，并在云上执行相应的API操作，就能够将设备接入到KubeEdge中来，享受KubeEdge边缘计算平台带来的云原生设备管理体验。

更多信息可参考： https://github.com/kubeedge/kubeedge/pull/4013

全新的Edged实现

Edged模块是边缘侧的轻量化容器应用引擎，用于实现边缘Pod应用的生命周期管理，以及Node状态收集与上报等能力。新版的Edged为了保证边缘的轻量化，在原生Kubelet中做了优化与裁剪，并保留了裁剪历史记录(Commit History)，最终直接调用Kubelet入口的Run函数启动以集成在EdgeCore中。

新版的Edged，由于保留了对Kubelet的裁剪历史记录(Commit History)，用户和开发者可以根据历史记录了解裁剪点。直接调用Kubelet入口的Run函数启动，减少了对Kubelet的侵入修改，将大大简化后续K8s版本依赖升级，也可将上游K8s漏洞修复及时全量同步到KubeEdge版本。

新版Edged的配置参数也与Kubelet保持一致。为了保持KubeEdge可靠的云边消息传输和边缘自治能力，在新版Edged中，我们仍然通过通过云边可靠通道传输应用、节点相关消息，并将数据存入边缘数据库。

对Kubelet的优化与裁剪，在KubeEdge组织下的Kubernetes仓库维护了裁剪后的版本，开发者可以通过commit提交记录查看裁剪记录，后续也可以根据需求自主调整裁剪内容。v1.12版本主要裁剪了Kubelet中在边缘不会使用到的特性、第三方内置存储、Cloud Provider等，更多裁剪详情可以参考：https://github.com/kubeedge/kubernetes/commits/v1.22.6-kubeedge1。

EdgeMesh支持高可用（HA）模式

EdgeMesh作为KubeEdge集群的数据面组件，为应用程序提供了服务发现与流量代理功能，稳定与高效的流量转发是用户对EdgeMesh的核心诉求。1.12版本的EdgeMesh新增了HA模式的部署方式，以支持EdgeMesh中继节点的高可用性。

HA部署模式下的EdgeMesh可以避免中继节点的单点故障问题，同时将中继转发与协助网络穿透的能力从edgemesh-server移入到edgemesh-agent中，使得具备中继能力的edgemesh-agent能够自动承担起中继节点的角色。因此用户可以在合适的位置设置具备中继能力的edgemesh-agent以分担云端中继节点的负载，同时也能解决过远的中继节点带来的长时延问题。在多中继节点下，EdgeMesh系统运行时能够自动选择一个最优的中继节点运行转发流量或协助网络穿透的功能。

用户在升级到v1.12.0版本的EdgeMesh时，默认无需再部署edgemesh-server，升级时需要配置中继节点表relayNodes中的nodeName和advertiseAddress参数以指定中继节点和其公网IP地址，通过Helm安装命令示例如下：

中继节点表relayNodes支持指定多个中继节点，每个中继节点支持配置多个公网IP地址。如果后续有新的中继节点加入，可以通过执行kubectl -n kubeedge edit configmap edgemesh-agent-cfg编辑中继节点表relayNodes添加新的中继节点，EdgeMesh能够自动热加载此配置。

更多信息可参考proposal： https://github.com/kubeedge/edgemesh/pull/372

支持批量远程升级边缘节点

KubeEdge集群常常管理数以万计分散的远程边缘节点，如何对这些节点实现方便快捷的升级更新是一个不小的挑战。1.12版本中新增了NodeUpgradeJob API及其Controller来实现云上批量远程升级边缘节点。

用户可以通过在云上创建NodeUpgradeJob来创建升级任务，用户可以指定升级的节点范围以及升级版本号等内容。例如以下配置表示升级edge-node1及edge-node2两个边缘节点到版本v1.12.0，升级结果将会显示在status字段中，用户可以通过执行kubectl get nodeupgradejob upgrade-example -oyaml命令来查看升级结果。

该特性处于alpha版本，用户需要手动启用该功能。如下所示在cloudcore.yaml配置文件中将nodeUpgradeJobController模块置为true以启用该功能。

更多信息可参考proposal：https://github.com/kubeedge/kubeedge/pull/3822

边缘原生接口支持认证鉴权

在边缘侧，EdgeCore组件通过MetaServer模块对外提供边缘原生接口能力。为了巩固和加强边缘侧的安全，在用户使用边缘原生接口访问原生K8s API时，需要对用户请求进行认证和鉴权。

新版本MetaServer可通过HTTPS方式启动并提供服务，用户的请求需要经过Token方式鉴权，未经过认证或鉴权的请求将无法访问。出于安全性考虑，Token鉴权方式在当前版本中要求边缘节点保持在线状态，离线场景下的鉴权请求将默认被拒绝。

新增的认证鉴权特性当前处于Alpha阶段，通过特性开关（featuregate）requireAuthorization来控制，默认是关闭状态，即用户默认仍然可通过监听在localhost的HTTP接口进行无鉴权访问。用户可以在CloudCore、EdgeCore的配置文件中配置开启该特性。

细节可参考 https://github.com/kubeedge/kubeedge/issues/4108

CloubHub可靠性增强

在大量KubeEdge使用场景中，边缘设备物理位置高度分散，并处于不稳定的物理环境中，因此云边通信网络质量较差，面临着高时延、网络中断、闪断闪连等问题。在KubeEdge中，CloudHub是云边之间通信的桥梁，负责边缘设备的连接管理和分发上下行的云边消息。在1.12版本中，我们重构了CloudHub模块，增强了在上述极端场景下CloudHub的稳定性和鲁棒性。

更多信息可参考：https://github.com/kubeedge/kubeedge/pull/4087

新增摄像头接口标准GigE的 Mapper实现

KubeEdge支持多种协议的边缘设备接入。GigE Vision是一种摄像头接口标准，在工业机器视觉产品中有广泛的应用。在这个版本中，我们提供了基于GigE协议开发的Mapper，GigE Mapper可以支持GigE视觉协议摄像机、工业相机设备接入KubeEdge。它使用第三方开源摄像机SDK库rc_genam_api，通过GeniCam协议访问不同厂商的摄像机。

每个GigE Mapper可以支持多个摄像头同时连接，通过设备SN来区分不同的摄像头设备，还可以通过KubeEdge北向接口，以CRD的形式来对摄像头参数进行配置。通过GigE Mapper管理摄像头，还支持摄像头捕获功能，支持导出PNG和PNM图像格式。目前测试了两种型号的摄像机，Basler acA640和HIKROBOT MV-CA050-12GC。

GigE Mapper是基于KubeEdge社区提供的Mapper开发框架Mapper-SDK-GO来开发实现的。使用Mapper-SDK-GO框架可以一键生成Mapper程序的主体内容，开发者只需要完成几个关键接口的对应协议的实现，即可开发出对应协议接入的Mapper，非常方便。

版本升级注意事项

EdgeCore的配置参数已经升级到v1alpha2版本，如果需要升级节点到v1.12，为了适配新版Edged，您需要手动修改EdgeCore中Edged模块的配置参数。
如果使MetaServer提供的边缘原生接口进行认证鉴权，您需要在CloudCore和EdgeCore的配置文件中将RequireAuthorization 特性开关打开，一旦开启，MetaServer只能以HTTPS访问。
如果要将EdgeMesh升级到v1.12，不需要部署现有的EdgeMesh-Server，且需要配置relayNodes。
如果要在 KubeEdge v1.12 上运行 EdgeMesh v1.12，并使用 https 请求与 KubeEdge 通信，则必须对EdgeMesh设置 kubeAPIConfig.metaServer.security.enable=true。

致谢

感谢KubeEdge社区技术指导委员会(TSC)、各SIG成员对v1.12版本开发的支持与贡献，未来KubeEdge将持续在新场景探索与支持、稳定性、安全性、可扩展性等方面持续发展与演进！

关于 KubeEdge

KubeEdge是业界首个云原生边缘计算框架、云原生计算基金会内部唯一孵化级边缘计算开源项目,社区已完成业界最大规模云原生边云协同高速公路项目（统一管理10万边缘节点/50万边缘应用）、业界首个云原生星地协同卫星、业界首个云原生车云协同汽车、业界首个云原生油田项目，开源业界首个分布式协同AI框架Sedna及业界首个边云协同终身学习范式，并在持续开拓创新中。

KubeEdge网站 : https://kubeedge.io

GitHub地址 : https://github.com/kubeedge/kubeedge

Slack地址 : https://kubeedge.slack.com

邮件列表 : https://groups.google.com/forum/#!forum/kubeedge

每周社区例会 : https://zoom.us/j/

Twitter : https://twitter.com/KubeEdge

文档地址 : https://docs.kubeedge.io/en/latest/

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

自从最初宣布 Fleet 以来，我们得到了来自大家的极大兴趣，有超过 137,000 人报名参加私人预览。我们之所以从封闭式预览开始，是为了能够以渐进的方式处理反馈。我们要感谢每一个参加这次私人预览的人，我们也想向没有收到邀请的人致以歉意。幸运的是，您不再需要等待了。

Fleet 仍处于起步阶段，还有大量的工作要做。然而，今天我们宣布首次公共预览 Fleet，所有人都可以使用。我们向公众开放预览的原因有两个方面。首先，我们认为让所有注册者再等下去是不对的，但单独邀请这么多人对我们来说也缺乏意义。面向公众开放预览对我们来说更容易。第二，也是最重要的，我们一直是一家以开放态度打造产品的公司。我们不希望 Fleet 在这方面有任何不同。

不过，在您下载它之前，请继续阅读完这篇文章，因为有一些重要的事情您应该知道。

Fleet 是什么

对于那些之前可能没有听说过它的人来说，Fleet 是我们新的分布式多语言编辑器和 IDE。它是基于我们在后端的 IntelliJ 平台，采用了全新的用户界面和分布式架构，从头开始构建的。要了解更多详情，请查看 Fleet 产品页面。

Fleet 公共预览版开箱演示

现在可以期待什么

由于我们计划支持的技术清单很长，我们准备了一个图表，显示 Fleet 目前提供支持的语言和技术，以及每个技术的状态。这应该能让您更好地了解接下来可以期待什么。

然而，我们想提醒您，Fleet 仍处于早期阶段，有些事情可能无法按预期工作，即使它们被列为受支持的。如果您确实遇到了问题，如果您能把它们记录下来，我们将非常感激。最简单的方法是通过 Fleet 的 Help 菜单中的 Send Feedback 选项。

还需要强调的是，我们并不打算取代我们现有的 IDE。因此，请不要期望在 Fleet 中看到与我们的 IDE（如 IntelliJ IDEA）完全相同的功能。尽管我们会继续开发 Fleet，我们 IDE 的所有功能也不会出现在其中。Fleet 是我们为开发者提供不同用户体验的一个机会。话虽如此，我们确实希望听到您认为 Fleet 还缺少什么功能的反馈，例如特定的重构选项、工具集成等。我们现有的 IDE 将继续发展。我们对其有很多计划，包括性能改进、新的用户界面、远程开发等等。最后，Fleet 还在底层采用了我们现有工具的智慧，所以这些工具都不会消失。

即将推出的内容

在未来几个月，我们将致力于稳定 Fleet，并尽可能地解决我们得到的反馈。同时，我们将在以下领域开展工作：

为插件作者提供 API 支持和 SDK–鉴于 Fleet 有一个分布式架构，我们需要努力为插件作者简化工作。虽然我们保证会为扩展 Fleet 提供一个平台，但也请求大家在这方面多一点耐心。
性能 – 我们希望 Fleet 不仅在内存占用方面，而且在响应时间方面都能表现出色。有很多地方我们仍然可以提高性能，我们将在这些方面努力。
主题和键盘映射 – 我们知道许多开发者已经习惯了他们现有的编辑器和 IDE，当他们转移到新的 IDE 时，往往会想念他们以前的键盘绑定和主题。我们将致力于增加对更多主题和键盘映射的支持。我们当然也会致力于 Vim 的模拟。

开始使用 Fleet

要下载 Fleet，您需要使用 JetBrains Toolbox App。

我们也正在准备一系列短视频以帮助您开始使用，请记得订阅我们的频道（Bilibili/YouTube）。无论您使用哪种技术，体验都是近似的，但我们还是根据语言将教程分成了不同的视频。另外，如果您遇到任何问题，请务必查看 Fleet 的文档。

我们仍处于与 Fleet 漫长旅程的开始阶段。我们希望您能加入我们，这将会是一场伟大的冒险！

摘要：RNN可以用于描述时间上连续状态的输出，有记忆功能，能处理时间序列的能力，让我惊叹。

本文分享自华为云社区《用RNN进行图像分类——CNN之后的探索》，作者： Yin-Manny。

一、写前的思考：

当看完RNN的PPT，我惊叹于RNN可以用于描述时间上连续状态的输出，有记忆功能，能处理时间序列的能力。

当拿到思考题，在CNN框架下加入RNN程序，这是可以实现的吗，如果可以，它的理论依据是什么，它的实现方法是什么，它的效果是怎样的。加入这个有必要吗。

我寻找了CNN combine with RNN的资料，看了CLDNN论文，我知道了：

CNN和RNN直接的不同点：

CNN进行空间扩展，神经与特征卷积；RNN进行时间扩展，神经与多个时间输出计算；

RNN可以用于描述时间上连续状态的输出，有记忆功能；CNN则用于静态输出；

CNN高级结构可以达到100+深度；RNN的深度有限。

CNN和RNN组合的意义：

大量信息同时具有时间空间特性：视频，图文结合，真实的场景对话；

带有图像的对话，文本表达更具体；

视频相对图片描述的内容更完整。

但是这对思考题没有什么帮助。

于是我又从RNN分类图像下手，试图弄明白RNN能用于图像分类的原理，首先需要将图片数据转化为一个序列数据，例如MINST手写数字图片的大小是28×28，那么可以将每张图片看作是长为28的序列，序列中的每个素的特征维度是28，这样就将图片变成了一个序列。同时考虑循环神经网络的记忆性，所以图片从左往右输入网络的时候，网络可以记忆住前面观察东西，然后与后面部分结合得到最后预测数字的输出结果，理论上是行得通的。但是对于图像分类，CNN才是主流，RNN图像分类的理论，对于CNN能有什么帮助呢？

甚至我们知道，循环神经网络还是不适合处理图片类型的数据:

第一个原因是图片并没有很强的序列关系，图片中的信息可以从左往右看，也可以从右往左看，甚至可以跳着随机看，不管是什么样的方式都能够完整地理解图片信息;

第二个原因是循环神经网络传递的时候，必须前面一个数据计算结束才能进行后面一个数据的计算，这对于大图片而言是很慢的，但是卷积神经网络并不需要这样，因为它能够并行，在每一层卷积中，并不需要等待第一个卷积做完才能做第二个卷积，整体是可以同时进行的。

那么我要怎么在CNN中加入RNN程序呢？

初步设想：

把CNN比较深层次的网络提取到的特征序列化，再喂给RNN进行分类，因为我认为这时候CNN提取到的特征比原始图像有更强的序列关系（如下图，越深层得到的特征序列关系越强，比如跳着看可能就难以进行分类了）

二、如何将图像数据改成序列数据？如何加入RNN系列程序，以改进图片分类的性能？

设image.shape为（h,w）

则令time_steps=h, input_size=w即可将图像数据改成序列数据

令X=[batch_size,h,w]

outputs, states = tf.nn.dynamic_rnn(rnn_cell, X, dtype=tf.float32)即可将X应用于RNN程序

如果是三通道图片，如RGB，则利用图像处理知识将三通道图像转为单通道灰度图像。

例如：

效果如下：

正如初步设想所说，把CNN比较深层次的网络提取到的特征序列化，再喂给RNN进行分类，因为我认为这时候CNN提取到的特征比原始图像有更强的序列关系，也许能够改进图片分类的性能？

例如我们将第一层的特征图喂到RNN中

迭代10次准确率高达98%，因此分类效果还是不错的。

三、不同的RNN细胞结构、不同的RNN整体结构，对分类性能有什么影响？

不同的细胞结构具有不同的门结构，对长短期记忆有不同的权重

不同的RNN整体结构有不同的层数与架构，对长短期记忆有不同的遗忘属性

常见RNN细胞总结：

BasicRNNCell–一个普通的RNN单。

GRUCell–一个门控递归单细胞。

BasicLSTMCell–一个基于递归神经网络正则化的LSTM单，没有窥视孔连接或单剪裁。

LSTMCell–一个更复杂的LSTM单，允许可选的窥视孔连接和单剪切。

MultiRNNCell–一个包装器，将多个单组合成一个多层单。

DropoutWrapper – -一个为单的输入和/或输出连接添加dropout的包装器。

常见RNN整体结构:

LSTM和GRU，其它的还有向GridLSTM、AttentionCell等

这些在tf.keras.layers.*中都可以直接调用API

因此只需修改下面一行代码的API即可实现不同的RNN细胞结构、不同的RNN整体结构对分类性能的影响的实验。

由于时间问题我没有运行完代码，直接附上相关资料的实验结果：

一般来说，多层结构的复杂度更高，分类性能会更好，但是产生的时间成本也会更多。

四、 nn.dynamic_rnn输出的final_state.h和output[:,-1,:]是否是相同的？

RNN 是这样一个单：y_t, s_t = f(x_t, s_{t-1}) ，画成图的话，就是这样：

考虑 Vanilla RNN/GRU Cell（vanilla RNN 就是最普通的 RNN，对应于 TensorFlow 里的 BasicRNNCell），工作过程如下：

这时，s_t = y_t = h_t

对于 LSTM，它的循环部件其实有两部分，一个是内部 cell 的值，另一个是根据 cell 和 output gate 计算出的 hidden state，输出层只利用 hidden state 的信息，而不直接利用 cell。这样一来，LSTM 的工作过程就是：

其中真正用于循环的状态 s_t 其实是 (c_t, h_t) 组成的 tuple（就是 TensorFlow 里的 LSTMStateTuple），而输出 y_t 仅仅是 h_t（例如网络后面再接一个全连接层然后用 softmax 做分类，这个全连接层的输入仅仅是 h_t，而没有 c_t），这时就可以看到区分 RNN 的输出和状态的意义了。

如果是一个多层的 Vanilla RNN/GRU Cell，那么一种简单的抽象办法就是，把多层 Cell 当成一个整体，当成一层大的 Cell，然后原先各层之间的关系都当成这个大的 Cell 的内部计算过程/数据流动过程，这样对外而言，多层的 RNN 和单层的 RNN 接口就是一模一样的：在外部看来，多层 RNN 只是一个内部计算更复杂的单层 RNN。图示如下：

大方框表示把多层 RNN 整体视为一层大的 Cell，而里面的小方框则对应于原先的每一层 RNN。这时，如果把大方框视为一个整体，那么这个整体进行循环所需要的状态就是各层的状态组成的集合，或者说把各层的状态放在一起组成一个 tuple：st=(st(l),st(2),…, st(l))而这个大的 RNN 单的输出则只有原先的最上层 RNN 的输出，即整体的yt= yt(l)=ht(l)。

最后对于多层 LSTM：

和之前的例子类似，把多层 LSTM 看成一个整体，这个整体的输出就是最上层 LSTM 的输出：yt=ht(l)；而这个整体进行循环所依赖的状态则是每一层状态组合成的 tuple，而每一层状态本身又是一个 (c, h) tuple，所以最后结果就是一个 tuple 的 tuple

这样一来，便可以回答问题：final_state.h和output[:,-1,:]是否是相同的

output是RNN Cell的output组成的列表，假设一共有T个时间步，那么 outputs = [y_1, y_2, …, y_T]，因此 outputs[:,-1,:] = y_T；而 final_state.h 则是最后一步的隐层状态的输出，即 h_T。

那么，到底 output[:,-1,:]等不等于final_state.h 呢？或者说 y_T 等不等于 h_T 呢？看一下上面四个图就可以知道，当且仅当使用单层 Vanilla RNN/GRU 的时候，他们才相等。

代码运行结果具体见附件代码第三问。

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

https://www.atzlinux.com/News/2022/20220920.htm

《铜豌豆 Linux》11.5.1 版本发布

2022-09-20

2022-09-10, Debian 官方发布 11.5 版本：
https://www.debian.org/News/2022/

铜豌豆 Linux 跟进发布 11.5.1。该版本是铜豌豆 x86_64 amd64 架构，首次基于 Debian 11 发布的版本。

铜豌豆软件源同时发布匹配 Debian 11 的软件源。

安装文件 iso 下载

安装文件大小约 3.5 G

http://www.yxgang.top:1080/atzlinux-cd/11.5.1/amd64/iso-dvd/atzlinux-11.5.1-amd64-DVD-1.iso

https://mike.atzlinux.com:58888/atzlinux-cd/11.5.1/amd64/iso-dvd/atzlinux-11.5.1-amd64-DVD-1.iso

https://motion.atzlinux.com:18761/atzlinux-cd/11.5.1/amd64/iso-dvd/atzlinux-11.5.1-amd64-DVD-1.iso

山东电信家用线路下载
广东电信家用线路下载 1
广东电信家用线路下载 2

下载完成后，可进行完整性验证，支持校验和、公钥签名验证。验证所需相关文件可以访问这里获取。

该 iso 安装文件，支持目前国内市场上常用的 Intel/amd 64 位 CPU。

默认用户名 wo root

系统默认创建两个用户，一个是名字为 wo 的普通用户；一个是具有最高系统权限的管理员用户 root 。

默认普通用户名为： wo ，默认密码为：
debian168;
最后一个字符是英文的分号
- root 用户可以直接登录系统， 默认密码为：
- debian-cn;168
  中间为英文的连接符，英文的分号
安全更新
- Debian 官方软件包安全更新同步到 2022-09-19 日。
主要系统软件包版本
- 内核
- Linux atzlinux 5.10.0-18-rt-amd64 #1 SMP PREEMPT_RT Debian 5.10.140-1 (2022-09-02) x86_64 GNU/Linux
- glibc 2.31-13+deb11u4
- Xfce 桌面环境 4.16
- Mate 桌面环境 1.24.0+4
- KDE 桌面环境 5.20.5
- Gnome 桌面环境 3.38
- 小企鹅输入法 fcitx 4.2.9.8-3
- 火狐浏览器 firefox 91.13.0
- 雷鸟邮件客户端 thunderbird 91.13.0-1
- chromium 浏览器 105.0.5195.125
主要应用软件包版本
- 搜狗拼音输入法 sogoupinyin 4.0.1.2800
- 霞鹜文楷开源字体 fonts-lxgw-wenkai 1.235.2+repack-1
- 铅笔字形楷体，该软件包也已经提交 Debian 官方，目前在审核中。
- WPS 办公 wps-office 11.1.0.11664
- 钉钉 com.alibabainc.dingtalk 1.4.0.20425
- Google Chrome 浏览器 google-chrome-stable 105.0.5195.125-1
- opengnb 1.2.9.0-2~bpo11+1
- 方便快捷搭建 VPN 网络，内网穿透，国人自己开发，特别适合国内网络环境，速度极快。
- 火焰截图 flameshot 12.1.0-1
- 解压缩命令 unzip 6.0-27atzlinux1~bpo10+1
- 百度网盘 baidunetdisk 4.12.5
- liblunar-calendar-gtk3-module 农历 3.0.1-2
- 可以在 Xfce、MATE 等桌面环境的默认日历程序中，直接显示农历和中国节假日信息
主要铜豌豆软件包版本：
- 铜豌豆补丁包
- 11.5.1 版
  /etc/atzlinux_version 文件, 版本号设置为 11.5.1
- 铜豌豆 11 版本软件源 atzlinux-v11-archive-keyring 2022.03.02
- 铜豌豆商店 11 版本 atzlinux-store-a11 11.3.2.5
- 铜豌豆桌面定制基础包 desktop-base-atzlinux 1.0.3
- 定制启动背景图，登录背景图等。
- 铜豌豆 Xfce 桌面定制包
- xfce-atzlinux-v11 11.5.3
- 铜豌豆网络小脚本 netscripts-atzlinux 1.0.7
- 铜豌豆 CA 证书 ca-certificates-atzlinux 1.0.0
- 铜豌豆自签名的 Grub EFI 安全启动包 grub-efi-amd64-signed 1+2.06+3.atzlinux2
- 支持在 Grub 阶段的安全启动
iso 文件相关
- 支持安全启动 Secure Boot
- 首次实现了对安全启动功能支持。
  1. 在安装阶段，继续使用 Debian 的安全启动支持
  2. 在系统启动的 grub 阶段，使用铜豌豆 CA 证书签名的 grubx64.efi 启动
  3. 在机器第一次启动时，会提示导入 CA 证书
  4. 这时需要将铜豌豆 CA 证书导入机器的 MOK，证书在 EFI 分区里面有存放，路径为：
    /boot/efi/atzlinux-uefi-ca.der
  注：机器启用安全启动后，休眠、混合睡眠功能默认无法使用。相关信息请查阅：
  
  apt install manpages
  man kernel_lockdown
- 将 5.18.x 系列最新版本内核软件包集成到 iso 文件
- 路径为： pool/main/l/linux/linux-image-5.18.0-0.deb11.4-rt-amd64_5.18.16-1~bpo11+1_amd64.deb
  对部分比较新的硬件，在安装过程及系统安装完成后均无法驱动的情况，可以在操作系统安装完成后，再安装这个新版内核并重启机器。
  
  登录系统后，重新拔插下 U 盘，让 U 盘自动挂载，在命令行进入挂载目录，用 root 账号安装该内核软件包：
  dpkg -i linux-image-5.18.0-0.deb11.4-rt-amd64_5.18.16-1~bpo11+1_amd64.deb
NVIDIA 显卡驱动

铜豌豆默认安装NVIDIA 显卡开源驱动 nouveau，软件包名为：xserver-xorg-video-nouveau。

如需要安装 NVIDIA 闭源驱动，请参阅：安装 NVIDIA 显卡厂家闭源驱动及相关软件

《铜豌豆 Linux 11 版本》维护期

该版本维护期至 2026 年 8 月。

在 Debian 11 版于 2021 年 8 月正式发布后，Debian 官方将维护三年至 2024 年 8 月，随后 Debian 的 LTS 团队将再继续维护两年。 LTS 维护相关情况，请参阅： https://wiki.debian.org/LTS

铜豌豆 Linux 11 版本系列，将跟随 Debian 官方和 Debian LTS 的版本继续进行维护和更新发布。

无缝升级

在后续使用中，请用 root 用户运行下列命令，一键更新所有软件包到最新版本：

apt update
apt upgrade

iso 文件信息：
- jidgo 文件：
- https://www.atzlinux.com/atzlinux-cd/11.5.1/amd64/jigdo-dvd/
  指引： 使用 jigdo 下载制作铜豌豆 iso 镜像文件
- iso 文件软件包完整列表：
- https://gitee.com/atzlinux/debian-cn/blob/apt-install/isodvd/11.5/atzlinux-11.5.1-amd64-DVD-1.list
已知问题
- 首次蓝牙图标，会有是否自动启动蓝牙的提示
- 有蓝牙的机器，请选择自动启动蓝牙。
问题&需求反馈

铜豌豆 Linux 项目是一个开源项目，采用开源社区模式开发，非常欢迎大家反馈在使用过程中遇到的任何问题。各类建议和需求也非常欢迎反馈。

https://gitee.com/atzlinux/debian-cn/issues

感谢
- 感谢星际译王、农历库、opengnb、霞鹜文楷字体、apvlv 等项目上游作者对开源社区的积极贡献
- 丰富了 Linux 中文应用，并和铜豌豆社区积极配合，解决定位了不少问题。这些软件包也由铜豌豆 Linux 项目维护，其中的新软件包提交到 Debian 官方上游，贡献成为 Debian 官方软件包。
- 感谢铜豌豆 iso 测试群的各位爱好者对新版本的测试工作
- 帮忙积极发现和定位问题。该版本的测试时间是以往所有版本中最长的一次。
- 感谢网友“幻念”提供下载机器和带宽
- 捐赠的 www.yxgang.top 机器也是家用路由器带宽，下载带宽约 30Mb。此次版本同时使用三台家用器带宽对外提供下载服务，极大的缓解了下载带宽不足的情况，并大量节省了项目运维成本。
- 感谢各位捐赠人对《铜豌豆 Linux》项目的积极捐赠
- 捐赠列表： https://www.atzlinux.com/juanzeng.htm#liebiao
  大家的捐赠既是对铜豌豆 Linux 的认可，也是对铜豌豆 Linux 支持，是铜豌豆 Linux 开源项目持续前进的动力。
其它事项

root 账号登录系统
1. 象棋、围棋程序，会报错
2. 默认声音图标显示为静音
3. 无法打开声音，不能够播放声音
4. 程序菜单，设置–》用户和组
5. 账号操作，无法成功，请用户普通用户登录系统后使用该程序，届时会出现 root 密码输入提示框。
以上为正常现象。这是由于 Debian 的安全机制，不建议 root 用户直接使用图形应用程序。请用普通账号登录系统使用相关功能。

漏洞描述

Mockery 是一个使用 Node.js 简化模拟的使用的工具组件。

Mockery 在2.1.0及之前版本中由于 mockery.js 中的方法未对参数 opts 进行过滤处理从而存在原型污染漏洞。攻击者可用过此漏洞通过传入恶意的 opts 参数修改JavaScript对象属性的默认值，从而导致拒绝服或远程代码执行。

漏洞名称 Mockery <=2.1.0 存在原型污染漏洞漏洞类型动态确定对象属性修改的控制不恰当发现时间 2022-10-13 漏洞影响广度极小 MPS编号 MPS-2022-53527 CVE编号 CVE-2022-37614 CNVD编号 –

影响范围

mockery@[1.0.0, 2.1.0]

修复方案

参考链接

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

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

https://github.com/mfncooper/mockery

情报订阅

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

具体订阅方式详见：

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

漏洞描述

powerline-gitstatus 是一个用于显示 Git 工作副本状态的powerline。

powerline-gitstatu 在1.3.2之前的版本中存在任意代码执行漏洞，由于 powerline-gitstatus 切换到目录中会自动运行 git 命令，当powerline-gitstatus在 shell 上启用并在系统上克隆恶意存储库时，攻击者可利用此漏洞引导用户将其当前目录更改为由攻击者控制的目录，进而运行任意恶意命令。

漏洞名称 powerline-gitstatus <1.3.2 存在任意代码执行漏洞漏洞类型代码注入发现时间 2022-10-13 漏洞影响广度极小 MPS编号 MPS-2022-59750 CVE编号 CVE-2022-42906 CNVD编号 –

影响范围

powerline-gitstatus@[1.0.0, 1.3.2)

修复方案

将组件 powerline-gitstatus 升级至 1.3.2 及以上版本

参考链接

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

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

https://github.com/jaspernbrouwer/powerline-gitstatus/issues/45

https://github.com/jaspernbrouwer/powerline-gitstatus

情报订阅

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

具体订阅方式详见：

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

漏洞描述

LAVA 是 Linaro 自动化和验证架构，用于测试基于 Linux 内核在 ARM 设备上的系统部署，主要是 ARMv7 及更高版本。

LAVA 在 022.10之前的版本中由于输入清理不当从而存在远程代码执行漏洞。其原因为 lava_server/lavatable.py 中的参数用于为表搜索创建查询参数，由于未对其进行过滤，攻击者可利用此漏洞传入恶意的参数从而远程执行恶意代码。

漏洞名称 Linaro/lava <2022.10 存在远程代码执行漏洞漏洞类型代码注入发现时间 2022-10-13 漏洞影响广度极小 MPS编号 MPS-2022-59746 CVE编号 CVE-2022-42902 CNVD编号 –

影响范围

Linaro/lava@(-∞, 2022.10)

修复方案

升级Linaro/lava到 2022.10 或更高版本

参考链接

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

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

https://git.lavasoftware.org/lava/lava/-/commit/e66b74cd6c175ff8826b8fbe228b52?merge_request_iid=1834

https://github.com/Linaro/lava

情报订阅

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

具体订阅方式详见：

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

2022年10月13日，北京 —— 微软年度技术大会 Ignite 2022 及 Ignite China 中国技术峰会同步开启线上直播。微软智能云矩阵发布超过100项新服务和新功能，并面向全球和中国市场，推出一系列线上主题演讲、技术论坛、专家讲座、案例分享，启发和助力来自世界各地、各行各业的客户、合作伙伴、开发者，在新形势下提升效率、降低成本、把握机遇，“事半功倍”地加速数字化转型与数字化创新。面对中国市场不断增长的客户需求，微软宣布多项Azure、Dynamics 365、Power Platform服务落地中国北部三数据中心区域，提升中国市场服务能力；由世纪互联运营的Office 365上的Teams服务，以及由世纪互联运营的Microsoft 365服务，将于2023年上半年正式推出，为中国市场带来更加全面、更加优质的本土化服务体验和技术保障。

微软全球资深副总裁、微软大中华区董事长兼首席执行官侯阳博士

微软全球资深副总裁、微软大中华区董事长兼首席执行官侯阳博士表示：“全球各地、各行各业都在面对不确定性带来的巨大挑战。越来越多的企业发现，由科技创新驱动的数字化转型和数字化创新，正成为助力企业增强业务韧性和竞争优势的关键要素。我们在微软技术大会上所说的‘事半功倍’，就是要充分发挥微软智能云的潜力和优势，通过发掘数据智能、强化协作能力、自动化商业流程，尽可能地在控制成本投入的同时，提升企业生产、运营、创新的效率，帮助更多的企业和合作伙伴在日趋激烈的市场竞争中斩获先机，赢得未来。”

全面释放人工智能的最大潜力，让数字化转型“事半功倍”

微软智能云加速实现“事半功倍”的关键诀窍，在于将一系列智能化、自动化技术潜移默化地融入微软智能云矩阵各项主要云服务的方方面面：从Microsoft 365到低代码开发平台和工具，从Azure数据服务平台到全方位确保身份安全和权限管理，让人工智能真正成为触手可及的现实体验。

作为Azure人工智能平台的组成部分，Azure OpenAI服务推出Dall·E 2的受邀预览，该模型可根据用户输入的文本或者图片生成定制化的图像。借助该服务，用户可以在Azure安全合规、负责任的AI框架下，进一步拓展OpenAI服务的使用场景，将脑中一闪而过的灵感，转化为栩栩如生的图像、内容或程序代码。

Power Automate进一步降低了低代码开发的门槛，现在用户只要用日常的自然语言说出需求，就可以自动创建云端的工作流程，将“低代码”进一步简化到了让更多人以完全“无代码”的方式来快速构建不同的自动化流程。

全新推出的Microsoft Syntex打通了从Microsoft 365、Azure到Power Platform及Purview的微软智能云矩阵，能够对海量内容自动进行读取、标记、索引并对相关内容建立背景关联，以便将其用于搜索、应用程序或者是可被调用的知识。它能从用户的需求出发，将所有相关内容都整合到协作及eSignature这样的工作流程中去。

由AI Builder和Power Automate支持的Microsoft 智能文档处理服务无需代码即可实现端到端的文档处理，将繁重的文档处理工作自动化，让人们能够将精力集中到更有价值的工作上去。为了更好地满足销售人员对于移动办公和会议日益增长的需求，微软免费为Dynamics 365 Sales Enterprise和新发布的Viva Sales加入了对话智能服务。这项服务能够通过智能分析和数据洞察，为销售人员提供更多有价值的业务线索，指导与客户的对话，并帮助他们节省下大量用在行政工作上的时间，从而更好地服务客户，促进成交。

面对中国市场不断增长的客户需求，Azure机器学习服务、Azure认知服务也即将落地中国北部三数据中心区域，服务能力和规模将得到显著提升。

云端数据平台和开发服务持续升级，助力客户降本增效

今年微软推出了微软智能数据平台，用以统一微软旗下的数据库、数据分析和管理服务，帮助客户将分散割裂的数据负载融会贯通，从而更加快速、高效地获取业务洞察。该平台现在又得到了进一步的拓展，目前已经有12家合作伙伴加入这一生态系统。

微软推出的支持超大规模拓展的企业级无服务器分布式数据库Azure Cosmos DB，已经被全球各地的客户广泛用于支持各种不同规模的关键业务应用，其地理高可用性、高扩展性和分布式部署，得到了客户的广泛认可。Azure Cosmos DB增加对开源分布式数据引擎PostgreSQL的支持，以便开源开发者借助Azure Cosmos DB在速度、规模化和性能上的优势，用同一个数据库服务访问结构化和非结构化数据。

在多云开发部署方面，微软为了给客户提供最大的灵活性，推出了支持本地部署和通过Azure Arc在边缘部署的Azure Kubernetes服务。此外还有最新推出的Azure公共多路访问边缘计算服务，已经被AT&T等运营商用于5G网络的建设。现已面向开发者提供预览的Microsoft Dev Box云端编程工作站推出了Visual Studio镜像，开发者只要登入服务就能直接进入Visual Studio开发环境，更有利于节约时间和集中精力。

在中国市场，Azure SQL、Cosmos DB、Power BI、MySQL、PGSQL 等微软及开源数据平台已经落地中国北三数据中心区域，Azure Databricks、Azure Synapse分析服务也将于本季度落地北三。中国北三区域带来了Availability Zone高可用能力, 可为企业关键业务应用提供99.99%的高可用保障，并提供更完善的灾备和恢复能力；支持超大规模SAP系统云端运营的Mv2系列虚拟机也已落地中国市场，加速企业ERP及核心业务系统上云, 实现真正的降本增效。

创新工作方式，让混合工作更加灵活高效

微软最新发布的“工作趋势指数”报告显示，超过80%的雇员选择回到办公室，是为了彼此见面。在Ignite技术大会上，微软发布全新的Microsoft Places应用，用来优化物理办公场所的使用。Places能够提供关于同事们该在何时进入办公室的洞察，并能提供哪些会议更适合在线下召开的建议。此外还有智能会议总结功能，就像是为每个会议安排了一个智能助手，它可以借助AI自动按照会议记录分配工作任务，给会议划分段落，并且从会议记录中提取出与每个人关系最紧密的内容，让人更好地抓住重点信息。智能会议总结和其它一些新功能将作为Teams Premium版的附加组件供单独选购。

Microsoft Edge Workspaces是Edge浏览器上的共享标签页，用来在群组成员之间同步分享网站和线上工作文件的地址。比如有新成员加入某个项目时，就可以分享一个Edge Workspaces的标签，通过浏览器就能找到所有相关文件和链接，而无需再通过邮件转发大量文档。在小组成员共享工作期间，标签也会自动实时更新，确保每个人的工作进度随时同步。

在混合办公新常态下，包括Teams和Office组件的Microsoft 365现代办公平台，正越来越多地扮演着“组织数字中枢”的角色。微软和世纪互联计划将于2023年上半年，在中国发布由世纪互联运营的Office 365上的Teams服务。与此同时，我们将结合Office 365 和企业移动性+安全性（EMS），正式推出由世纪互联运营的Microsoft 365服务。此外，由世纪互联运营的Dynamics 365和Power Platform，即将落地中国北部三数据中心区域；Wrap App for Power App、Power Pages等创新功能也已上线，持续助力企业加速推进业务创新。

从开发平台到身份管理，构建完善的安全保护体系

微软致力于为数字化转型，构建最无微不至的安全防护体系。在今年的Ignite大会上，微软特别针对常常被忽视的开发环节，推出了一系列安全措施。全新推出的Defender for DevOps用来在开发运维过程中，为各类新老代码自动添加完善的保护措施，以防其中的漏洞被攻击者所利用。企业在打造应用程序的过程中，就能直接为程序加入安全保护，杜绝安全漏洞，让程序员安心地调用来自外部的代码，或者是在大规模的开发团队中相互协作。Power Platform 可以将现有环境变成托管环境。托管环境提供了数据管控、权限管理和自动发送报告等功能，从而更轻松的管理低代码资产，简化 Power Platform 的 IT 管理工作。

微软致力于帮助企业打造面向未来的身份管理体系，对人、组织、应用、智能设备的访问权限控制加以实时管理。新发布的Microsoft Entra身份和访问管理方案能对多云平台的安全访问权限进行管理。Microsoft Entra Identity Governance服务能确保正确的人拥有正确的权限，在正确的时间访问正确的资源。Workload Identities服务则用来控制应用、服务之类的数字工作负载和云资源的访问权限，基于证书的认证体系能够更好防范钓鱼式网络攻击。

欲了解Ignite 2022微软技术大会上的更多精彩内容和最新发布的技术细节，请访问官方网站（ignite.microsoft.com）。

Grafana 9.2 正式发布，主要更新内容如下：

面板帮助菜单

仪表板面板出现问题的原因多种多样，从处理数据的问题到渲染或配置的问题。通过检索面板的查询响应数据和面板设置，缩短你在报告问题和请求 Grafana Labs 帮助时的沟通时间。这将帮助支持团队尽快重现、诊断和修复问题。

Canvas 面板

引入了 Canvas 面板，这是一个结合了 Grafana 的强大功能和自定义素的灵活性的新面板。Canvas 可视化是可扩展的表单构建面板，允许您在静态和动态布局中明确放置素。这使你能够以标准 Grafana 面板无法实现的方式设计自定义可视化和覆盖数据。如果你使用过一些知名的 UI 和网页设计工具，那么设计 Canvas 面板会感觉非常熟悉。

支持 Google Analytics 4 属性

现在可以使用 Google Analytics 4 (GA4) 来跟踪 Grafana 的使用情况。要使用 GA4 启用跟踪，需在 Grafana 的配置文件中指定你的属性的测量 ID。

Google Analytics 4 取代了 Universal Analytics，后者将在 2023 年停止服务（免费帐户为 7 月 1 日，Google Analytics 360 用户为 10 月 1 日）。

Alertmanager 更新为基于 Prometheus Alertmanager v0.24

用于 Grafana 管理的警报规则的 Alertmanager 现在基于最新版本的 Prometheus Alertmanager v0.24。

将外部警报管理器配置为数据源

从版本 9.2 开始，不推荐使用警报页面上管理选项卡中的外部警报管理器的 URL 配置。它将在未来的版本中删除。

现在应该使用 Grafana 主导航菜单中的 Grafana 配置将外部警报管理器配置为数据源。

表达式支持

为公共仪表板添加了使用表达式的功能。

更多详情可查看：https://grafana.com/docs/grafana/latest/whatsnew/whats-new-in-v9-2/

CKEditor 5 v35.2.0 已发布。此版本最重要的变化是正式添加“从 Word 导入文档”服务，以及改进用户界面。

从 Word 导入文档服务

CKEditor 云服务推出了一项快速且高度可扩展的服务，使用户能够从 Microsoft 的 Word 文档 ( ) 以及 Word 模板文件 ( ) 中导入内容。该服务允许用户上传 Word 文件并将其转换为 HTML，使其可供浏览器访问。

该功能作为服务提供，可以将此类文件直接发送到云服务的服务器，也可以直接与集成了该功能的 CKEditor 5 WYSIWYG 编辑器插件搭配使用。

调整工具栏

支持展开和折叠工具栏，如下图所示：

添加新的特殊字符类别

最后要注意的是，当官方发布 CKEditor 5 v35.2.0 和从 Word 导入服务时，生产环境出现了意外问题：存在一个持续错误导致从 Word 导入的建议未与其余内容一起写入。他们迅速进行了修复并发布补丁更新。因此，最新的 CKEditor 5 版本实际上是 v35.2.1。

详细更新内容查看发布公告。

关注公众号

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

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

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

OpenProject 是一个基于网络的项目管理系统，用于不受地点限制的团队协作，分为免费开源的社区版和收费的企业版。该项目的开发工作主要由 OpenProject GmbH 完成。

这个版本极大地改善了工作包的调度，因此将节省大量的时间，使调度更加准确。

全局工作周的引入

OpenProject 12.3 为管理员提供了在整体实例级别上指定工作日和非工作日的功能，从而定义一个全局工作周。

这有助于创建更准确的项目时间表，避免工作的开始或结束日期被设定在周末。非工作日在日历中显示为灰色，工作不能被安排在这些天开始或结束。非工作日的默认值被设置为星期六和星期日，但你可以根据需要设置。

期限

OpenProject 12.3 引入了工作的期限。通过使用新的期限字段，可以更快地安排你的工作。

你可以为一个工作定义一个开始日期，输入以工作日为单位的持续时间，完成日期将被自动设置。另外，你可以输入持续时间和结束日期，开始日期将被设置。在所有情况下，工期与开始和结束日期是一致的。更新日期将更新持续时间，而更新持续时间将更新你的完成日期。

日期选择器的升级

随着持续时间的增加和全局工作周的引入，日期选择器得到了更新以反映这些变化。你现在会发现一个持续时间字段和一个 “仅工作日” 的开关。

持续时间字段显然是用来指示工作的持续时间，并协助设置开始或结束日期。通过 “仅工作日” 开关，你可以决定是坚持既定的工作周还是包括周末。

更多详情可查看：https://www.openproject.org/docs/release-notes/12-3-0/

PostgreSQL 15 已发布，此版本在本地管理和分布式部署中的工作负载方面有明显的优化，包括改进的排序性能。此版本还添加了流行的 MERGE 命令、启用 Zstd 和 LZ4 压缩支持，以及更多用于观察/调整数据库状态的功能。

改进的排序性能和压缩

在最新版本中，PostgreSQL 改进了其内存和磁盘上的排序算法。测试基准显示：根据不同的数据类型，此次排序优化大概可加速 25% – 400%。
在 PostgreSQL 15 中，使用 row_number()、rank()、dense_rank()和count()as 窗口函数也具有性能优势。
使用 SELECT DISTINCT 的查询可以并行执行。
PostgreSQL 15 添加了对 LZ4 和 Zstandard (zstd) 压缩到预写日志 (WAL) 文件的支持，对于某些工作负载可以同时具有空间和性能优势。
在某些操作系统上，PostgreSQL 15 增加了对 WAL 中引用的预取页面的支持。
PostgreSQL 的内置备份命令 pg_basebackup 现在支持备份文件的服务器端压缩，可选择 gzip、LZ4 和 zstd 等压缩方法。
PostgreSQL 15 拥有使用自定义模块进行归档的能力，消除了使用 shell 命令的开销。

新的开发者功能

PostgreSQL 15 包含 SQL 标准 MERGE 命令。MERGE 允许编写条件 SQL 语句，这些语句可以在单个语句中包含 INSERT、UPDATE 和 DELETE 操作。
PostgreSQL 15 还增加了使用正则表达式检查字符串的新函数：regexp_count()、regexp_instr()、regexp_like() 和 regexp_substr()。
PostgreSQL 15 还扩展了 range_agg 函数，可聚合多范围数据类型。
PostgreSQL 15 允许用户使用调用者（view caller）来创建查询数据的视图，而不是视图创建者的权限。这个选项称为 security_invoker，它增加了一个额外的保护层，以确保视图调用者拥有处理底层数据的正确权限。

日志和配置增强

PostgreSQL 15 引入了一种新的日志格式：jsonlog。这种新格式使用定义的 JSON 结构输出日志数据，允许在结构化日志系统中处理 PostgreSQL 日志。
在用户管理 PostgreSQL 配置方面，PostgreSQL 15 版本为数据库管理员提供了更大的灵活性，增加了向用户授予更改服务器级配置参数的权限的能力。
此外，用户现在可以使用 psql 命令行工具中的 dconfig 命令搜索有关配置的信息。

其他变化

PostgreSQL 15 使 ICU 排序规则成为集群或单个数据库的默认排序规则成为一种可能。
该版本添加了一个新的内置扩展 pg_walinspect，它允许用户直接从 SQL 接口检查预写日志文件的内容。
PostgreSQL 15 还从公共(或默认)模式的所有用户（数据库所有者之外）撤销 CREATE 权限。
PostgreSQL 15 从 PL/Python 包中删除了长期被弃用的“独占备份”模式和对 Python 2 的支持。

更新公告：https://www.postgresql.org/about/news/postgresql-15-released-2526/

Python 3.10.8 现已发布。与此同时，3.7-3.9 中也进行了一些修复，因此同一时间共发布了 Python 3.10.8、3.9.15、3.8.15 和 3.7.15 四个版本。

此次的安全更新内容包括：

CVE-2022-40674：捆绑的 libexpat 从 2.4.7 升级到 2.4.9，修复了 function doContent 中的 heap use-after-free 漏洞
gh-97616：修复了中可能出现的缓冲区溢出
gh-97612：修复了示例脚本中可能的 shell 注入（这个问题最初分配了一个 CVE，其作者撤回了它）
gh-96577：修复了中潜在的缓冲区溢出

作为一个在计划外安全版本发布仅一个月后发布的错误修复版本，与一年前发布周期的同一阶段发布的 3.9.8 相比，3.10.8 要稍微小一些。3.10.8 有 151 个 commit，而 3.9 则有 204 个。不过它仍然是一个比 3.10.7（113 个 commit）更大的版本。

更多详情可查看 change log。

下载

LibreOffice 7.4.1 发布大约一个月后，LibreOffice 7.4.2 版本进一步解决了 LibreOffice 7.4 办公套件系列中发现的各种问题和错误。根据 RC1 和 RC2 的更新日志，LibreOffice 7.4.2 版本中正好包含 80 个错误修复。

LibreOffice 7.4.2 版本的修复进一步提高了与专有办公套件（微软 office）文档格式的兼容性，以及对 LibreOffice 的本机文档格式 ODF（OpenDocument 格式）的支持。此外，还解决了社区报告的崩溃、错误和其他错误。

LibreOffice 7.4.2 社区版本可从该下载地址获得，它对专有操作系统的最低要求是 Microsoft Windows 7 SP1 和 Apple macOS 10.12。

LibreOffice 7.4 系列将支持到 2023 年 6 月 12 日，总共有六次维护更新。下一个版本 LibreOffice 7.4.3 计划于 2022 年 11 月末发布。

漏洞描述

Apache Commons Text 项目实现了一系列关于文本字符串的算法，专注于处理字符串和文本块。

Apache Commons Text 在1.10.0之前的版本中由于插值默认值验证不当从而存在远程代码执行漏洞。其原因是因为Apache Commons Text 插值格式“${prefix:name}”中的“prefix”用于定位执行插值的 org.apache.commons.text.lookup.StringLookup 的实例，如果 Lookup 实例中包含了不受信任的配置值，则在受影响版本中使用插值默认值的应用程序容易受到远程代码执行或与远程服务器的错误联络。

漏洞名称 Apache Commons Text <1.10.0 远程代码执行漏洞漏洞类型反序列化发现时间 2022-10-13 漏洞影响广度一般 MPS编号 MPS-2022-59712 CVE编号 CVE-2022-42889 CNVD编号 –

影响范围

org.apache.commons:commons-text@[1.0, 1.10.0)

修复方案

升级org.apache.commons:commons-text到 1.10.0 或更高版本

参考链接

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

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

https://seclists.org/oss-sec/2022/q4/22

https://github.com/apache/commons-text/commit/b9b40b903e2d1fc80ea

情报订阅

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

具体订阅方式详见：

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

vivo 互联网产品团队 – Wang xiao

随着广告和内容等推荐场景的扩展，算法模型也在不断演进迭代中。业务的不断增长，模型的训练、产出迫切需要进行平台化管理。vivo互联网机器学习平台主要业务场景包括游戏分发、商店、商城、内容分发等。本文将从业务场景、平台功能实现两个方面介绍vivo内部的机器学习平台在建设与实践中的思考和优化思路。

一、写在前面

随着互联网领域的快速发展，数据体量的成倍增长以及算力的持续提升，行业内都在大力研发AI技术，实现业务赋能。算法业务往往专注于模型和调参，而工程领域是相对薄弱的一个环节。建设一个强大的分布式平台，整合各个资源池，提供统一的机器学习框架，将能大大加快训练速度，提升效率，带来更多的可能性，此外还有助于提升资源利用率。希望通过此文章，初学者能对机器学习平台，以及生产环境的复杂性有一定的认识。

二、业务背景

截止2022年8月份，vivo在网用户2.8亿，应用商店日活跃用户数7000万+。AI应用场景丰富，从语音识别、图像算法优化、以及互联网常见场景，围绕着应用商店、浏览器、游戏中心等业务场景的广告和推荐诉求持续上升。

如何让推荐系统的模型迭代更高效，用户体验更好，让业务场景的效果更佳，是机器学习平台的一大挑战，如何在成本、效率和体验上达到平衡。

从下图可以了解到，整个模型加工运用的场景是串行可闭环的，对于用户的反馈需要及时进行特征更新，不断提升模型的效果，基于这个链路关系的基础去做效率的优化，建设一个通用高效的平台是关键。

三、vivo机器学习平台的设计思路

3.1 功能模块

基于上图业务场景的链路关系，我们可以对业务场景进行归类，根据功能不同，通用的算法平台可划分为三步骤：数据处理「对应通用的特征平台，提供特征和样本的数据支撑」、模型训练「对应通用的机器学习平台，用于提供模型的训练产出」、模型服务「对应通用的模型服务部署，用于提供在线模型预估」，三个步骤都可自成体系，成为一个独立的平台。

本文将重点阐述模型训练部分，在建设vivo机器学习平台过程中遇到的挑战以及优化思路。

1.数据处理，围绕数据相关的工作，包括采集、加工、标记和存储。

其中，采集、加工、存储与大数据平台的场景相吻合，标记场景是算法平台所独有的。

数据采集，即从外部系统获得数据，使用Bees{vivo数据采集平台}来采集数据。
数据加工，即将数据在不同的数据源间导入导出，并对数据进行聚合、清洗等操作。
数据标记，是将人类的知识附加到数据上，产生样本数据，以便训练出模型能对新数据推理预测。
数据存储，根据存取的特点找到合适的存储方式。

2. 模型训练，即创建模型的过程，包括特征工程、试验、训练及评估模型。

特征工程，即通过算法工程师的知识来挖掘出数据更多的特征，将数据进行相应的转换后，作为模型的输入。
试验，即尝试各种算法、网络结构及超参，来找到能够解决当前问题的最好的模型。
模型训练，主要是平台的计算过程，平台能够有效利用计算资源，提高生产力并节省成本。

3.模型部署，是将模型部署到生产环境中进行推理应用，真正发挥模型的价值。

通过不断迭代演进，解决遇到的各种新问题，从而保持在较高的服务水平。

4. 对平台的通用要求，如扩展能力，运维支持，易用性，安全性等方面。

由于机器学习从研究到生产应用处于快速发展变化的阶段，所以框架、硬件、业务上灵活的扩展能力显得非常重要。任何团队都需要或多或少的运维工作，出色的运维能力能帮助团队有效的管理服务质量，提升生产效率。

易用性对于小团队上手、大团队中新人学习都非常有价值，良好的用户界面也有利于深入理解数据的意义。

安全性则是任何软件产品的重中之重，需要在开发过程中尽可能规避。

3.2 模型训练相关

模型训练包括了两个主要部分，一是算法工程师进行试验，找到对应场景的最佳模型及参数，称之为“模型试验”，二是计算机训练模型的过程，主要侧重平台支持的能力，称之为“训练模型”。

建模是算法工程师的核心工作之一。建模过程涉及到很多数据工作，称为特征工程，主要是调整、转换数据。主要任务是要让数据发挥出最大的价值，满足业务诉求。

3.2.1 模型试验

特征工作和超参调整是建模过程中的核心工作。特征工作主要对数据进行预处理，便于这部分输入模型的数据更好的表达信息，从而提升模型输出结果的质量。

数据和特征工程决定模型质量的上限，而算法和超参是无限逼近这个上限。

超参调整包括选择算法、确认网络结构、初始参数，这些依赖于算法工程师丰富的经验，同时需要平台支持试验来测试效果。

特征工程和超参调整是相辅相成的过程。加工完特征后，需要通过超参的组合来验证效果。效果不理想时，需要从特征工程、超参两个方面进行思索、改进，反复迭代后，才能达到理想的效果。

3.2.2 训练模型

可通过标准化数据接口来提高快速试验的速度，也能进行试验效果的比较。底层支持docker操作系统级的虚拟化方案，部署速度快，同时能将模型直接部署上线。用户无需对训练模型进行更多定制化的操作，批量提交任务能节约使用者的时间，平台可以将一组参数组合的试验进行比较，提供更友好的使用界面。

其次，由于训练的方向较多，需要算力管理自动规划任务和节点的分配，甚至可以根据负载情况，合理利用空闲资源。

四、vivo机器学习平台实践

前面我们介绍了机器学习平台的背景和发展方向，现在我们来介绍下，平台在解决用户问题部分的困扰和解决思路。

4.1 平台能力矩阵

机器学习平台主要目标是围绕模型训练进行深耕，并辅助用户进行模型决策，更快的进行模型部署。

以此为目标分为两个方向，训练框架的优化能够支撑大规模模型的分布式计算，调度能力优化能够支持批次模型的执行。

在调度能力上，平台由原生k8s调度，单个训练调度的效率较低，升级为kube-batch批量调度，到以混合云精细化编排为目标，当前主要处于灵活性调度策略的形式。

在训练框架上，从原生Tensorflow模型，随着特征和样本规模的扩大，自研了超大规模的训练框架vlps，当前处于TensorFlow+vlps结合的新框架状态。

4.2 平台能力介绍

平台能力建设主要围绕模型试验和训练模型的运用，运用过程中遇到的痛点和难点如何解决，是我们在实践中的关键。同时，训练框架也是平台关键能力的体验，基于业务的复杂度，持续对框架进行优化。

已覆盖公司内部算法工程师模型调试的工作，已达到亿级样本，百亿特征的规模。

4.2.1 资源管理

痛点：

机器学习平台属于计算密集型的平台。

业务场景不同，是否完全按照业务分组进行资源划分；
资源池划分过小，会导致资源利用率低且没办法满足业务激增的资源诉求；
资源不足以满足业务诉求时，会存在排队情况导致模型更新不及时；
如何管理好算力，提效与降本的平衡，是平台资源管理的一个核心问题。

解决思路：

资源管理的基本思路是将所有计算资源集中起来，按需分配，让资源使用率尽量接近100%。任何规模的资源都是有价值的。

比如，一个用户，只有一个计算节点，有多条计算任务时，资源管理通过队列可减少任务轮换间的空闲时间，比手工启动每条计算任务要高效很多。多计算节点的情况，资源管理能自动规划任务和节点的分配，让计算节点尽量都在使用中，而不需要人为规划资源，并启动任务。多用户的情况下，资源管理可以根据负载情况，合理利用其它用户或组的空闲资源。随着节点数量的增加，基于有限算力提供更多业务支持是必经之路。

1.以配额限资源滥用：

新增配额组和个人配额，减少业务之间的相互干扰，尽可能满足各组的资源需要，并且配额组支持临时扩容和共享，解决偶发性激增的资源诉求；限额后用户仅支持在有限资源下使用，让用户自我调节高优先级训练。

2.以调度促资源优化：

新增生产环境，确认模型已经正常迭代，在合理利用率的情况下切换至高优环境，提供更高性能的资源池；同时提供调度打分机制，围绕资源颗粒度、配置合理性等维度，让合理的训练资源更快的拉起，减少调度卡住情况；

上线多维度调度打分机制后，平台不合理训练任务有大幅度下降，资源效率提升。

围绕并不限于以下维度：最大运行时长、排队时长、cpu&内存&gpu颗粒度和总需求量等。

4.2.2 框架自研

痛点：

随着样本和特征规模增加后，框架的性能瓶颈凸显，需要提升推理计算的效率。

发展路径：

每一次的发展路径主要基于业务量的发展，寻求最佳的训练框架，框架的每一次版本升级都打包为镜像，支持更多模型训练。

当前效果：

4.2.3 训练管理

痛点：

如何支持多种分布式训练框架，满足算法工程师的业务诉求，让用户无需关心底层机器调度和运维；如何让算法工程师快速新建训练，执行训练，可查看训练状态，是训练管理的关键。

解决思路：

上传代码至平台的文件服务器和git都可以进行读取，同时在平台填写适量的参数即可快速发起分布式训练任务。同时还支持通过OpenAPI，便于开发者在脱离控制台的情况下也能完成机器学习业务。

围绕训练模型相关的配置信息，分为基础信息设置、资源信息设置、调度依赖设置、告警信息设置和高级设置。在试验超参的过程中，经常需要对一组参数组合进行试验。

批量提交任务能节约使用者时间。平台也可以将这组结果直接进行比较，提供更友好的界面。训练读取文件服务器或git的脚本，即可快速执行训练。

1.可视化高效创建训练

2. 准确化快速修改脚本

3. 实时化监控训练变动

4.2.4 交互式开发

痛点：

算法工程师调试脚本成本较高，算法工程师和大数据工程师有在线调试脚本的诉求，可直接通过浏览器运行代码，同时在代码块下方展示运行结果。

解决思路：

在交互式工具中进行试验、开发，如：jupyter notebook，提供所见即所得的交互式体验，对调试代码的过程非常方便。

在交互试验的场景下，需要独占计算资源。机器学习平台需要提供能为用户保留计算资源的功能。如果计算资源有限，可对每个用户申请的计算资源总量进行限制，并设定超时时间。

例如，若一周内用户没有进行资源使用后，就收回保留资源。在收回资源后，可继续保留用户的数据。重新申请资源后，能够还原上次的工作内容。在小团队中，虽然每人保留一台机器自己决定如何使用更方便，但是用机器学习平台来统一管理，资源的利用率可以更高。团队可以聚焦于解决业务问题，不必处理计算机的操作系统、硬件等出现的与业务无关的问题。

五、总结

目前vivo机器学习平台支撑了互联网领域的算法离线训练，使算法工程师更关注于模型策略的迭代优化，从而实现为业务赋能。未来我们会在以下方面继续探索：

1.实现平台能力的贯通

当前特征、样本还是模型的读取都是通过hdfs实现的，在平台上的告警、日志信息都未关联上，后续可以进行平台能力贯通；
平台的数据和模型还有标准化的空间，降低学习成本，提升模型开发的效率。

2. 加强框架层面的预研

研究不同分布式训练框架对模型效果的影响，适配不同的业务场景；
提供预置的参数，实现算法、工程、平台的解耦，降低用户的使用门槛。

关注公众号

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

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

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

RISC-V 在即将到来的 Linux 6.1 默认内核配置中将会添加对 CD-ROM 文件系统的支持。

此举并不是为了要在 RISC-V 中使用 CD/DVD 驱动器，毕竟 2022 年 CD-ROM 基本已被淘汰。这是因为部分安装介质仍然可以作为这些文件系统的镜像来分发，部分用例还可能涉及到以这种格式存档的镜像。而且 RISC-V 默认内核配置已经为 ISO9660、Joliet 和 ZISOFS 文件系统提供支持。

目前此文件系统驱动程序已经在 RISC-V 上构建良好，此项变更只为了启用 ISO960 / Joliet / ZISOFS 的默认配置 “defconfig”。

对于使用 Linux 6.1 的 RISC-V 来说，这项变化还为 RISC-V 64 位系统启用了透明巨大页面交换 (TH_SWAP, transparent huge-pages swap)，默认 NR_CPUS 容量已经增加到 512，并且对 RISC-V 的 CPU 拓扑子系统进行了优化。后者现在支持 RISC-V 在更多的配置中报告正确的 CPU 拓扑信息。

详情查看 Pull Request。

AMD 于今年 8 月发布了 Zen 4 架构的 Ryzen 7000 系列的处理器，其中包括 Ryzen 9 7950X、Ryzen 9 7900X、Ryzen 7 7700X 和 Ryzen 5 7600X 这四款产品，该系列的产品在上个月也已经正式发售了。

既然产品已经上市，那么拿来测试一下不同系统在该系列 CPU 上的性能差异也是不能少的一个环节。日前外媒 Phoronix 拿到了 AMD 此次最强的处理器 —— Ryzen 9 7950X，他们将测试微软 Windows 11 22H2、Ubuntu 22.04.1 LTS 和即将推出的 Ubuntu 22.10 在该处理器下的性能基准测试。

此次测试的系统如下：

Windows 11 Pro 22H2
Ubuntu 22.04.1 LTS
Ubuntu 22.10 “Kinetic Kudu” + Linux 5.19
Ubuntu 22.10 “Kinetic Kudu” + Linux 6.0
同样是上述 Ubuntu 22.10 + Linux 6.0 的组合，但切换到 amd-pstate performance。默认情况下，Ubuntu 22.10 在 Zen 架构的处理器上使用 amd-pstate schedutil 驱动，而这次则选择更激进的 CPU 频率来最大化性能。

其他配置如下：

华硕 ROG CROSSHAIR X670E HERO 主板
2 x 16GB DDR5-6000 EXPO 内存
Radeon RX 6800 XT 显卡
1TB Sabrent Rocket 4.0 Plus NVMe SSD

因为此次测试主要是关注 CPU 和系统的性能，而游戏的性能高低更依赖于显卡，因此此次测试不包括游戏。

这次基准测试一共进行的 109 项不同的项目，上图是所有 109 项测试结果汇总之后的几何平均数。从图中也能看出，Windows 11 Pro 22H2 与开箱即用的 Ubuntu Linux 在性能上基本保持一致，可以说几乎没有差距（最下面的四项），无论是目前的稳定版 Ubuntu 22.04.1，还是接近最终发布的 Ubuntu 22.10，甚至是将内核升级到 Linux 6.0 也没有产生任何太大的性能差异。Ubuntu 仅仅是在用户手动将 amd-pstate schedutil 默认配置切换到更为激进的 performance 后，才让这个处理器的性能总体上提高了大约 6%。

以下我们节选出部分成绩差异较大的基准测试以供参考：

ParaView 基准：一个开源的数据分析和可视化应用程序。ParaView 用户可以快速建立可视化，使用定性和定量技术分析他们的数据（分数越高越高）。

BLAKE2 是 MD5 和 SHA-2/3 的一个高性能加密替代方案（分数越低越好）。

该测试运行用 Java 编写的 DaCapo 基准测试，旨在测试系统/CPU 性能（分数越低越好）。

测量了使用 Zstd 压缩技术压缩/解压一个样本文件所需的时间，并有不同的压缩级别/设置选项（分数越低越好）。

Kvazaar 是一个基于 CPU 的 H.265/HEVC 视频编码器，用 C 编程语言编写，用汇编优化（分数越高越好）。

虽然上述几项测试成绩在不同的操作系统中存在较大差异，但这仅仅是所有 109 项测试中的少数。此次测试的大部分成绩基本都像下图这样，基本没有差异。

此次测试也能看出，Windows 11 与 Ubuntu Linux 的基准测试比我们过去所看到的各种操作系统比较中看到的要接近得多。随着 AMD 处理器的大量铺货，以及开发者后续的优化，我们在未来应该能看到两个操作系统的变化，但就目前的情况来看，两个操作系统的表现出奇的一致。

此次测试的完整数据可查看：链接

InfoWorld 梳理了一份致使开发人员喜欢或讨厌使用 Rust 编程的原因清单，分别列出了 7 条内容。具体如下：

1、喜欢：Rust 解决了规模和并发问题

随着开发人员解决规模和并发性问题（即需要同时处理来自多个不同来源的输入），软件变得越来越复杂。许多人认为 Rust 是构建适合当今架构的工具的最佳语言。

Web 浏览器是需要大规模可扩展性的应用程序的一个很好的例子，因此 Rust 是由开发 Firefox 的非盈利公司 Mozilla 创建的也就不足为奇。Mozilla 的开发人员研究了他们在代码中遇到的问题并寻求更好的解决方案。最后，他们想出了 Rust。

讨厌：Rust 的并发模型太复杂了

虽然多线程系统越来越流行，但对于很多开发人员来说这并不是真正需要的；Scientific programmers 倾向于编写单线程函数。Web 开发人员可以编写 PHP 代码，它提供了一种简单的声明式方法来创建网站。Serverless programmers 只需编写一个函数，然后将繁重的工作留给其他人。需要创建更复杂的 Web 应用程序的开发人员则可以转向 Node.js，它提供了另一种处理多线程应用的策略。Node 的事件驱动模型与基于 Promise 的代码相结合，也可以产生简单而优雅的结果。

所有这一切都意味着 Rust 的多线程编程模型提供了比许多程序员所需的更复杂的功能。一些人可以不计较这些额外的东西并对 Rust 保持热爱，但有些程序员宁愿不去处理这些复杂的东西。“他们只是不需要它”。

2、喜欢：Rust 是一门现代语言

现如今许多编程语言的设计都专注于在创建功能性语言，以引导开发人员编写更容易分析的软件，Rust 也是如此。许多开发人员喜欢 Rust 的 logical、functional syntax，它鼓励将代码结构化为一系列嵌套函数调用。

与此同时，Rust 的创造者想要构建一些东西来处理保持物联网正常运行所需的 bit-banging、low-level 编程。Rust 为希望用现代风格解决这些非常现实的挑战的程序员提供了正确的组合。

讨厌：它有一个陡峭的学习曲线

在某些方面，学习 Rust 是一个忘掉你从编程生涯开始就可能遵循的概念和技术的过程。例如，学习 Rust 需要忘掉 JavaScript 和 Java 等旧语言所要求的 scope 和 ownership 的概念。

如果你想利用 Rust 的优势，则必须愿意放弃一些可能导致错误的已熟悉的功能。还有些人认为，Rust 的语言语法也很复杂。除了大括号和圆括号，还有方括号、竖线和大于号；有时候甚至还有双冒号。

构建复杂的多线程工具的 Rust 开发者可能会认为 Rust 的语法复杂性是一种值得的折衷，熟悉功能流的真正爱好者甚至可能会喜欢它。但其他人的感受却不尽相同，学习 Rust 的所有语义规则并不适合 casual user。

3、喜欢：你可以告诉 Rust 编译器该做什么

一些开发人员将 Rust 所需的所有额外细节和模板视为优势。它让他们可以 inject hints，使编译器更容易找出正在发生的事情并捕获任何潜在的错误。华丽的代码为开发人员提供了更好的机会来完全指定应该发生的事情，此举有助于避免编译器错误。Rust 通过注入有关代码应该如何工作的提示来邀请开发人员编写更好、更快的代码。

讨厌：谁想告诉编译器该做什么啊？

有些开发者只是想要一种语言，他们可以用它来完成运行时不会崩溃的循环、可以处理后台工作。因此如果编译器有时生成的代码比较慢，或者可能有点错误，无伤大雅。许多工作并没有那么复杂，而且调试起来也不难。相较 Rust 编译器的使用，配置更多的硬件反而要更轻松一点。

4、喜欢：Rust 具有很好的向后兼容性

Rust 的开发团队致力于确保即使语言不断发展，代码也能继续运行。该团队致力于确保旧的代码能够继续编译和运行新版本的语言，这一点是其他语言有时会忽视的。Rust 爱好者经常指出，他们能够维护他们的代码库而不需要无休止的重写。这是因为 Rust 是一种尊重其自身历史的语言。

讨厌：Rust 不是严格面向对象的语言

Rust 不遵守面向对象的编程原则，这会给一些程序员造成问题。

5、喜欢：Rust 的异步处理模型更安全

Rust 的异步编程模型允许开发人员创建独立运行的 separate functions，然后将结果连接起来。许多开发人员表示，这种结构有助于他们构建更快的代码，同时遇到更少的错误。

讨厌：异步编程很难

Rust 所做的任何事情都无法使我们不必仔细考量我们的代码。Rust 无法保护代码免受死锁或延迟；它只能提供更好的建议和更少错误的结构。开发人员仍然要对良好的应用设计和编写干净的代码负责。Rust 只是将问题最小化，并减少一些更明显的危险。

6、喜欢：没有抽象的编程

Rust 旨在支持编写 low-level、byte-tweaking 代码的 system-level 程序员；它提供对 raw bits 的访问，并期望程序员能够使用它。该语言设计是为了与许多旧的 C 语言或汇编语言代码共存。

讨厌：Byte-level access 是有风险的

许多语言在发展过程中都避免了 byte-level access。这是有充分理由的：此举很容易导致程序员陷入困境。隐藏访问可以避免风险。一些程序员最好让语言的 hidden back 来处理分配内存和表示数据的细节。

7、喜欢：一种更好的垃圾回收机制

Rust 语言有自己的内存管理方法，它不像传统的 GC 那样全面，但可以更强大。优秀的开发人员可以使用 Rust 的内存模型提供出色的性能，但他们必须掌握类型系统和原子引用计数。

对于 Rust 的死忠粉来说，亲手操作内存管理是他们喜欢的功能。即使这项工作意味着要处理大量线程并确保代码具有响应性，他们也宁愿自己动手。无论好坏，Rust 都让你自己掌握主动权。

讨厌：内存管理很痛苦

许多流行的编程语言（如 Java）已经实现了内部内存管理，因为它可以防止内存泄漏和其他错误。大多数程序不需要担心由垃圾回收引起的偶尔的小插曲。作为程序员，你可能不希望需要担心内存问题。

此外，Rust 并不是唯一提供传统垃圾回收替代方案的语言。例如，Node.js 简化了多线程编码并让你依赖 JavaScript 的运行时内存管理，这是一个很好的折衷方案。

结论：Rust 仍然是新的和不断发展的

InfoWorld 总结称，我们可以争论 Rust 是否为异步编程提供了最好的模型，摆脱垃圾收集是否真的有助于开发人员等等；但归根结底，Rust 仍然是一门非常新的语言。开发人员正在积极学习其细节并发现使用 Rust 的最佳实践。创建 Rust 程序的正确方法有待商榷，开发人员在该领域不断学习和试验。

Rust 可能是也可能不是最适合你或你的项目的语言。一般来说，它可能是也可能不是创建软件的最佳解决方案。但这是一个令人兴奋的选择，有很多探索机会。作为一门语言，Rust 很新颖，学习它可以使人的大脑得到延伸。作为程序员，它让我们有理由重新思考我们的挑战，重新制定我们的目标，并着手寻找编写现代软件的最佳方式。还有什么能比这更好呢？

据外媒 windows centra 报道，微软在 Ignite 2022 上”意外地“展示了 Windows 的下一代 UI 设计原型。新 UI 和 Windows 11 区别不大，任务栏依然在底部浮动，但系统图标被移到了右上角，顶部中间有一个浮动搜索框，左上角则显示天气。

有一说一，这个布局有 GNOME 的味道，包括顶部居中的搜索，左上角天气和右上角的系统图标。下面是 GNOME 的 UI 布局：

有人分析 Windows下一代 UI 看起来是更好地优化触摸屏，同时力求不影响鼠标和键盘用户体验。微软希望能够这一代 UI 能在台式机、笔记本电脑和平板电脑之间通用。

此前微软一直在努力在 Windows 的触摸和鼠标用户之间找到平衡。Windows 8 倾向以触控为中心，而 Windows 10 则以鼠标为中心。Windows 11 试图找到一个平衡点，但它仍更倾向于鼠标输入。

事实上，微软 Ignite 2022 大会并没有设置新 UI 原型地介绍环节，它更像是“意外地暴露了”（这么机密的 UI 原型竟然会莫名出现在微软大会的主题演讲中）。尚不清楚这一 UI 原型是否会应用在 Windows 12 上，一些用户觉得这也可能是 “Windows 11 Plus”、“Windows 11 Ultra”。

1. 介绍

Serverless并不仅仅是一个概念，很多地方都已经有了它的影子和思想，本文将给大家介绍最近比较火的Serverless。

首先放出官方对Serverless的解释：

Serverless的全称是Serverless computing无服务器运算，又被称为函数即服务（Function-as-a-Service，缩写为 FaaS），是云计算的一种模型。以平台即服务（PaaS）为基础，无服务器运算提供一个微型的架构，终端客户不需要部署、配置或管理服务器服务，代码运行所需要的服务器服务皆由云端平台来提供。国内外比较出名的产品有阿里云Function Compute、AWS Lambda、Microsoft Azure Functions 等。

有人说它是云计算的未来，代表了一种技术趋势、理念和发展方向，因为不是官方科普，说说个人的理解。

首先Serverless代表了一种思想或者服务理念，使用者无需再关心除了业务逻辑之外的机器资源容量、配置管理等事项，不需要关注运营维护，是一种去DevOps的理念；
然后他又是一种全新的架构模式，通过一系列技术手段使得各项资源都到最充分的利用；
同时也是一种云服务产品的形态，现在已经陆续开始有云产品(比如阿里云的数据仓库PostgreSQL、阿里云多模数据库Lindorm、阿里云MongoDB)开始提供Serverless版本支持，这个可以理解为服务的plus的版本，比如我们常见的MySQL、Redis、ES、分布式ID、MQ等一系列的服务，如果提供了Serverless版本的支持，那我们不再需要关心这些服务的申请机器、资源部署、资源碎片、弹性扩缩容问题，不再需要日夜值守关心各个依赖组件各项指标出现的问题，我们只需要聚焦在自己的上层业务逻辑上进行实现和优化，并且再也不会有闲置资源或者碎片资源问题(按需使用)，这个就是Serverless想要构建的架构体系。

2.架构演进

早期的软件部署模式是通过采购物理机的形式，有多大规模采购多少台机器，采购多了或者配置差了都会存在比较大的资源浪费。

虚拟化技术出来后缓和了这个问题，允许将物理机切分成一个一个VM实例，一台机器上可以运行多个实例，采购多了那就运行其他服务，配置差的机器多运行一些实例，配置好的少运行一些，但是虚拟化本身还是挺重的，每个VM需要维护自己的OS内核，切的越多浪费越大，并且不利于维护统一基线，安装插件配置agent上传脚本很容易造成应用内一批机器不一致，并且销毁重建也不是那么容易的事情，这个阶段运维的事务性工作还是不少。

接下来云的浪潮铺开，传统的服务器厂商开始转型拥抱云，将自己的服务器搬到云上通过虚拟化技术进行线上售卖提供基础IaaS服务，到这个阶段仅仅是转变了商业模式，上面的问题依然还是存在。

再到后面docker容器技术产生，docker本身还是一种虚拟化技术，但是他是依托于宿主机操作系统之上的虚拟化，仅仅只是一个独立进程共享OS内核，资源碎片和内存占用浪费问题会少很多，并且重建销毁比较容易，非常利于维护应用统一基线，通过一套标准镜像自定义dockerfile进行统一交付，一次构建到处运行，运维可以脱离繁琐重复的工作去做更多工具类的产品。

DevOps概念在这个阶段变得火热，大厂内甚至要求消灭运维，强制运维转型开发，想起来也不无道理，在docker技术出来之前，一次建站往往需要运维们准备一堆脚本和安装顺序手册，搭建操作系统环境，安装网关、DB、软负载等一系列中间件，编译配置安装然后使得服务可用，中间一旦有一个步骤出错还得从头再来，但是运维往往是不了解应用的，启动不起来配置错误报错信息等问题还是需要开发介入，而让开发来负责上线部署，很多服务软件不知道如何部署，两者中间有一道很明显的鸿沟，所以一次建站或者新平台的搭建，需要拉上运维和开发通宵好几个晚上一起攻坚，效率低下，这个时候急需一个了解开发的人把运维的事情干了，而容器技术出现之后，就如上面介绍，docker镜像统一基线使得建站部署变得更加标准化和简单，开发运维一体化这个事情就会变得水到渠成，通过dockerfile、swarm集群编排或者k8s可以很容易的让开发把运维的事情干了，这个时候运维自然会显得多余，当然完全消灭运维也是不可能的，变革是渐进式的，需要有一些人去负责历史包袱的资产系统，同时与开发有更好的协同具备提升系统稳定性和做自动化工具化系统研发能力的SRE出现也代表了运维转型的决心。

到目前为止，还是停留在开发需要关心运维的阶段，但是随着docker技术的普及，很多运维相关的工作已经变得非常容易了，这个时候云厂商开始考虑是否可以把运维这个事情从开发手中收走，让运维自动化，变得对开发更加透明，开发人员只需关注核心业务逻辑的开发，进而精益整个产品开发流程，快速适应市场变化，这个时候Serverless的概念开始产生，所以从这个角度来看，在整个it架构演进中，docker的普及无疑是进一步推动了Serverless的快速发展。

从整个演进过程中来看，一直都在朝着资源切分粒度越来越细(物理机->操作系统->进程->function)，资源利用率越来越高，运维工作逐渐减少，开发更聚焦业务的方向发展的，Serverless的产生也是符合历史发展的一般规律。

3. 应用场景

一个比较典型的应用场景是云上的巡检产品，业务很简单类似于360安全卫士，定期巡检云用户的三方依赖组件，产出包括安全、性能、稳定、成本的巡检报告并且给出建议，由于需要和一些微服务治理高可用等产品做捆绑售卖，本身也是免费产品，以前的ECS部署模式成本较高也不是很灵活，所以需要做改造来适应现在的云原生环境，准备将其托管到云上Function Compute Serverless平台，部署架构如下图：

这是一个比较典型的依托于Serverless平台的SaaS应用交付，即我们提供了一套通用的代码模板，提交给了Serverless平台进行运行，服务开发商也就是我们无需关注承载服务的系统架构和资源运维，不会因为服务的客户越来越多而导致运维负担或者设计重构问题，只需要关心服务业务的实现，然后消费方开箱即用，这套模板可以无限复制给更多的使用方，只要模板是固定的，不管未来新增多少个三方依赖组件要加入巡检，我们都只是新增模板实现然后提交任务给Serverless平台而已，而由采集端负责触发任务执行，对于应用或者业务的创新成本都是极低的。整个Serverless平台就是FaaS和BaaS的组合服务，FaaS是函数即服务，负责运行任务实例，BaaS是后端即服务，是任务依赖的三方依赖组件通过API的形式提供数据，你可以在Serverless平台编写代码(FaaS能力)，然后调用一些第三方依赖组件的API进行数据交互(BaaS)。

4. Serverless如何影响微服务

微服务和Serverless并不冲突，一个微服务应用可以是基于Serverless架构搭建部署的，也可以是传统的先申请资源再进行部署的方式，Serverless本身是技术架构，而微服务是业务架构，经济基础决定上层建筑，底层的技术架构形式会影响上层的业务，当Serverless以function为粒度提供服务的时候，对于上层微服务的架构组织带来了新的契机。

以前的微服务更多是以应用的形式来组织的，一个应用关注一个特定的业务功能集合，很多服务可能都会使用到相同的功能，而这个功能并没有达到分解为一个微服务的程度，这个时候，可能各个服务都会开发这一功能，从而导致代码重复。尽管可以使用共享库来解决这个问题(例如可以将这个功能封装成公共组件，需要该功能的微服务引用该组件)，但共享库在多语言环境下就不一定行得通了，而在Serverless架构中以function为最小粒度组织的模式下，你的业务分隔粒度可以无限的小，任何一个模块功能甚至方法都可以独立存在，不再需要通过共享组件代码复用强耦合的方式来组织应用，在Serverless架构中，微服务组件的相互隔离和模块松耦合可以做的更好，应用甚至可以以独立函数的形式存在，当然这不代表你的微服务拆的越细越好，也需要考虑到你的业务边界定义是否有利于不同团队组织之间独立工作，这里不展开讨论，事实上云厂商们已经开始进行了这方面探索，将Serverless和微服务打包做成组合拳产品提供解决方案。

5. Serverless和云原生的关系

Serverless就是为云而生的东西，天生具有云的基因(免运维弹性伸缩按量计费)，用户将服务托管给了云厂商，只需要聚焦业务逻辑不需要去关心和管理资源问题，是对容器技术的封装，代表了云原生的高级阶段。

6. Serverless要解决的问题

在我们公司内部其实也有类似和Serverless相似的产品，比如算法推荐平台，他本身提供的是FaaS服务，希望能够让使用者更快更好的实践自己的算法而不用关心机器部署配置的一些细节，但他还不是一个Serverless模式，实现Serverless需要有对应几个能力的建设，首先先介绍下Serverless要解决的几个问题。

机器资源分配不均

一个大型系统因为需要支撑各种业务，往往会拆分集群来进行业务隔离，不同集群由于业务的特性，会出现差距较大的资源利用率，这显然是对资源的一种浪费，当然通过人肉运维调整集群机器配比可以解决这个问题，但是这种重复劳动本身也是对人效的浪费。

错峰问题

每个流量本身就有一定的规律，比如白天流量高晚上流量低，大促流量高常态流量低，如果就为了一天1个小时的高峰流量来准备全天的机器，那剩下来的那23小时也是一种资源的浪费。

碎片化问题

微服务之间的数据交互主要是RPC和MQ，常见的RPC框架本身就有比较完善的探活和负载均衡机制能够保证流量在不同机器的的均衡性，而MQ受限于顺序消费、失败重发、消息分区等特性没有办法很好的保证消费端负载均衡，比如我们常用的RocketMQ默认使用了一种分页的算法，即在客户端将消费者和分区分别按照字典序排好，再按照平均分配的原则每个消费者分”一页”的分区，所以这里就会引申出碎片的问题，当一个集群中消费的Metaq消息都是小分区的消息，所有的消息都会被流入集群中的前几个机器中，造成集群整体流量不均，带来集群资源碎片。

资源问题

对于新接入的用户和业务，我们常见的做法是评估峰值业务量然后为其开启新集群预先分配一批机器，这里就有两个问题，一个是对于资源的预先评估是否能够准确而不造成浪费，另一个是成本结算方式，如果使用机器数来给用户或者业务方结算成本，对于有明显波峰波谷的使用者来说也是一种很大的成本资源浪费。

运维问题

在每次大促或者压测之前都需要提前扩缩容准备资源、修改集群配置，随着各种大促小促和压测次数越来越密集，这种运维开销成本也变得越来越大。

7. Serverless特性

Serverless的产生就是为了解决上面这些问题，它应该具有的特性有：

FaaS化

FaaS化的目的是为了做任务的抽象标准化和对业务的更细粒度拆分，以函数的方式进行组织，这和我们常说的流程化编排组件化建设其实初衷是一样的，如果有了这一层抽象，任何业务形式都可以在这个标准化平台上像搭积木一样进行构建，并且对于业务组件化和资源拆分的粒度是Function，这个对于上层微服务的架构组织带来了新的契机，上面篇幅已经介绍过这里不再累述。

无维护

这里不是真正的没有维护，而是机器帮助人去实现自动化运维进行弹性扩缩容，管理员不必关心应用运行的状态，是否在工作，是否有资源碎片等等，任务不再是固定的跑在某个集群里，而是可以在任意机器里进行迁移。

按需使用

有了Serverless，应用水位会维持在一个固定的范围，什么时候该扩容什么时候该缩容都由平台按照当前的负载情况来决定。

按量收费

根据执行次数执行时间来计算费用，只为实际使用的计算资源付费，是一种资源粒度精细化的管理模式。云计算归根结底是一种 IT 服务提供模式，不论是公共云还是专有云（以IT设备的归属不同分类），其本质都是帮助 IT 的最终使用者随时随地，并且简便快速地获取 IT 服务，目前的IaaS、PaaS都已经做到了按需付费，PaaS 甚至做到了按请求付费，如DB、CACHE、MQ等，但是 IaaS 的付费粒度仍然是时间维度，最快按照小时付费，以分钟来交付。因此，当下的云计算场景，应用的开发维护方式相比传统 IDC 时代的开发维护，差别还不是很大，本质上都是做预算然后购买交付，但Serverless平台提供了一种全新的开发维护方式，用户只需要写好业务代码，提交到云上，所有和机器容量、可用性、机器为单位的运维工作可以全部交给云平台，这种模式极大的释放了云的弹性价值，真正做到了按需付费。

事件监听

Serverless中的function通过事件监控的方式被触发执行，这里的事件监听可以是HTTP API触发、消息监听、定时触发、控制台触发。

8. 如何实现Serverless平台

结合上面说到的Serverless特性，我们的任务都以函数的方式进行组织，任务可以在任意机器里进行迁移和启动，并且支持自动弹性扩缩容，为了实现这些特性，大前提是我们需要保证函数的无状态。

无状态

在Serverless平台中由于执行函数的容器是不确定的、执行顺序也不确定，一个容器可能会被并发的执行多次，也不存在执行顺序，函数运行时根据业务弹性，可能伸缩到 0，所以无法在运行环境中保存状态数据，这就要求我们的函数是无状态的，以便于随时进行水平伸缩，否则可能会出现一些意料之外的结果，比如:

如果连续两次执行handler(3)，会得到不一样的结果，因为这里存储了状态变量sum，两次执行间共享了这个状态变量，影响了最终执行的结果，所以无状态也是要求函数开发者在编码过程中保证尽量少的使用外部变量，但是也不代表完全不使用外部变量，对于一些有限资源比如数据库连接，这部分资源是可以被复用的，我们可以提前在函数外进行提前初始化，这样当容器预热之后就可以直接使用；还有一些状态信息比如登录状态，我们可以利用外部服务、产品，例如数据库或缓存，实现状态数据的保存，以便可以用来获取登录信息。

快上快下

因为按需使用的特性，对于长时间不使用的函数会主动退出以节省内存，当函数调用请求传入时，我们会检查是否已有一个空闲的容器可以使用，如果没有那就需要重新拉起一个容器启动，这个就是”冷启动”问题，一个容器的拉起和函数初始化加载工作需要一定的时间，冷启动会拖慢函数的响应速度。对此业界最常见的做法是准备buffer池，提前申请一部分资源，拉取镜像创建容器加载资源包，这样当有突发流量进入、运行中容器无法承载的时候，会自动进行快上快下，将buffer池中预热好的容器拿出来直接灌入流量，而流量下降后，运行中容器负载下降则会自动进行快下操作，将一部分容器摘流放回buffer池中，那这里有同学可能会问如果提前准备buffer机器那不是违背了Serverless降低成本的初衷了吗，注意buffer池中的资源并不是一个高优先级的绝对资源占用，他实质上并不属于任何一个应用的，预先加载多少buffer资源也是由Serverless平台的算法策略决定，所以在资源紧缺的情况下完全可以挪出去供其他业务使用，一般不超过Serverless平台总机器数的10%，是一种在进程复制技术还不成熟的情况下的折中方案。

统一集群

引入集群的目的是做分治管理，来提高机器集中运维效率，而在Serverless平台中，所有机器均被统一的部署和管理(同一物理区域内)，集群管理的方式已经失去了意义，Serverless平台的机器全部跑在一个大集群中被无差异的执行，机器实际使用量根据实时水位自动进行调整。

混合部署

标准的Serverless平台应该是一容器一函数的部署方式然后通过容器的资源隔离能力做到完全的隔离，但是实操过程中由于管理的需要，往往是一容器多函数的部署方式，当然也有性能方面的考虑，因为频繁的创建销毁容器做资源隔离也会带来资源消耗(容器资源隔离通过内核cgroup机制实现)，过多的cgroup组会对内核造成额外的开销。之前在实践中曾经遇到过一个线上问题，当时发现只要和Serverless平台混部的应用sys CPU都会莫名的高出一截，因为做了线程级别的CPU隔离(通过创建cgroup组进行线程pid绑定的方式)，但是在函数退出时没有做cgroup的清理，导致宿主机因为绑定过多cgroup组(上万)进行了内核态空转引起sys CPU飚高，所以控制宿主机上容器的数量以及使用一容器多函数的部署方式还是很有必要的。

混合部署的方式彻底解决了之前说到的碎片化问题，函数可以自由调度，各个机器都得到了充分的利用。虽然是一容器多函数的部署方式，但是也不是意味着就可以随意的混部，混合部署会尽量做到各机器的水位均衡，也就说到下面的自动调度的话题。

任务分类

我们在第一版测试中，为每台机器都设置了相同的线程池线程数，最后的结果是机器负载非常不均衡，因为不同的函数执行耗时不同，以前可以通过集群来隔离这些不同的业务为每个集群预设不同的线程池配置，而现在Serverless平台统一了集群，不同的函数可以在机器间任意迁移，当机器中存在耗时较高的任务，线程池立马被占满来不及消费，但是机器水位很低，这种情况下再给他分配任务反而会加剧这个问题，当机器中都是耗时较低的任务时，水位会保持的较高。

所以为了规避这个问题，我们将函数进行了分类，分为IO密集型任务和CPU密集型任务，事先分配好两个线程池，IO密集型任务跑在IO线程池中，CPU密集型任务跑在CPU线程池中，由于CPU密集型任务可以近似认为是纯CPU计算型，所以CPU线程池线程数近似等于核数大小，IO密集型任务由于不同的任务耗时也大不相同，所以采用累加的形式，每个IO函数都要设置使用的IO线程数，该容器上IO线程池的线程数等于所有IO函数设置的线程数之和，这是一个动态的数，会随着任务调度而变化。

自动调度

之前说到buffer池的方案中需要提前预热一批资源，如何设置合理的buffer池资源数量以保证成本和效率的最优解是比较重要的问题。

在第一版的尝试中我们引入过多个指标的数据通过综合判定来进行调度，这里的指标包括系统指标CPU、load和业务SLA指标、队列堆积量、执行RT，但是最后会发现，通过这些指标并不能很好的均衡各机器的水位，因为不同函数的瓶颈并不完全一致，有IO密集型的，有CPU密集型的，一个场景可能在CPU不超过30%的情况下，就已经出现了容量不足的问题，有的场景高水位CPU运行的很好，但是有的场景相对较低的CPU可能就出问题了，或者机器本身的问题导致的load突然飙高，队列堆积增加的问题，其实并不是容量不足导致的。所以通过系统指标和业务指标并不能很好的衡量机器当前的水位。

通过对第一版的分析，我们发现这中间最主要的问题是我们一直在通过外部表象数据来判断机器水位，而这些数据在不同业务场景下表现又不尽相同，还容易受到外部环境的干扰造成数据抖动。所以在第二版中，我们增加了负载率的概念，在讲负载率之前先看一下并行度的概念，并行度(线程数)理论值为:

但是由于混合部署，每个函数脚本都不相同，导致整个机器上总的线程等待时间与线程CPU时间之比是一个不确定值，所以并行度是一个经验值设置，CPU密集型规则可以尽可能靠近核数以提高CPU的资源利用率，IO密集型可以调大，但是不是一味的调大,过多的线程数会导致频繁的上下文切换等损失，反而降低了性能，毕竟CPU时间片有限，太多并行度也执行不过来，并行度和资源利用率近似如下图的关系(正相关的折线，到达最佳并行度后资源利用率开始缓慢下降)。

所以为了达到最佳并行度，每台机器上的线程数都是一个动态变化的值，和这台机器上跑了哪些任务有关系。

负载率是用来衡量线程池利用率的指标，这个指标只和单机的线程池配置和流入的任务量有关，和这台机器的外部表象指标(CPU load 任务堆积量等等)都没有关系，定义为:

负载率是在并行度基础上的概念，当并行度不变时，耗时总和越大负载率越大，但是不会超过1，达到1说明机器的线程资源已经全部使用了，要么提高并行度要么扩机器。负载率还有一个意义在于可以精确的获取每个任务消耗线程资源的比重以便于进行比较精确的任务调度，因为IO密集型和CPU密集型任务已经用不同线程池进行了分隔，可以把这个消耗线程资源的比重，近似认为是消耗机器资源的比重。

自动化调度是第一步，再往下就是基于基线和时间相关性做一些算法智能化调度的探索，因为没有实践过这里不展开讨论。

调度预热的处理

当容器启动后到灌入第一批流量期间，存在一段时间执行能力较差，负载率偏高的问题，因为对于Java来说当一个新加容器在到达100%服务能力之前需要充分的代码预热(python ruby这类脚本语言可能会好些)，为了防止在预热期间负载率偏高造成错误的调度，增加了对于预热期的判定，只要有一台机器正在启动，调度就停止，直到启动完成后一段时间再恢复调度。

最大消费者数

消息消费的负载均衡取决于上游消息中间件，比如对于RocketMQ来说订阅者数必须小于消费组队列数，才能保证每个订阅者都有消息可消费，否则会出现部分订阅者无消息消费的问题，如果调度策略不考虑RocketMQ每个topic的队列数情况，无限制的增加订阅者，最后又会出现上面提到的碎片化问题。所以必须保证每个订阅者都有消息消费，每次调度都是有效的调度。

为了解决这个问题，我们增加了一个最大消费者数的概念，对于单个任务来说能够分配的消费机器数必须小于等于这个任务对应的topic的最大消费者数，防止出现无效的调度。对于RocketMQ来说最大消费者数等于该topic队列(分区)数，对于DRC来说，不支持负载均衡所以最大消费者数等于1，其他消息中间件依此类推。

调度策略

我们的调度策略是把负载率控制在一个稳态区间，然后结合最大消费者数进行调度。比如单机的CPU密集型任务负载率范围设置为5%-30%，大于这个值则给CPU密集型任务中负载率最高的前5个任务扩容器，如果所有在线容器都已经在消费该任务则从buffer池快上容器来给任务扩容，如果已经扩充至最大消费者数，则进行任务迁移，将这台机器上的任务迁移至低负载率的机器上；小于这个值则将该机器快下放进buffer池。IO密集型任务的调度也是类似，最终的目标是将所有在线机器收敛至稳态区间，同时为了避免在任务扩缩容和机器快上快下上出现”扩过了头”或者”缩过了头”的情况，限制了单次扩缩容的机器数和单台机器调度的最小时间间隔，也是防止一台机器刚刚任务扩容又立马任务缩容或者快下。

我们来考虑几种典型场景在这种调度策略下的应用:

某个消息topic任务的TPS高，队列数(最大消费者数)小，只要消费该任务的机器负载率都偏高，因为负载率超出了设定的稳态区间，调度策略对其进行任务扩容，但是已经达到了最大消费者数，只能进行任务迁移。最后这个任务会一直处于一个动态平衡中，即任务不断的在不同的机器里迁移，达到了一种超出队列数负载均衡消费的效果。
某个topic队列数很大，突然流量猛增，造成消费该topic的机器负载率都偏高，此时进行任务扩容，直到扩充到所有的在线容器，如果负载率还是偏高，则进行buffer池快上容器，直到buffer池的机器全部被快上或者负载率进入稳态区间范围。流量恢复正常后，因为很多的机器都在负载均衡消费该topic，造成机器负载率降低(尤其是之前快上的机器只消费该任务)，一部分负载率较低的容器会被快下进buffer池，此时恢复至最初的状态。
很多topic一起流量猛增，造成消费这些topic的机器负载率都偏高，此时对这些topic进行任务扩容，直到扩充到所有的在线机器或者达到最大消费者数，如果负载率还是偏高，则进行buffer池快上机器，为了防止出现”扩过了头”的问题，一次只将负载率最高的前5个任务的topic扩充至快上的机器中，随着负载率最高的前5个任务不断的增加机器，它们的负载率会下降，之后负载率最高的任务排名发生了变化，换成了另外5个任务，对它在进行扩容或者快上，慢慢地所有流量猛增的topic都会被扩容，最终就会达到稳定区间状态。
第一次任务分配的容器不均，导致大部分任务都分配给了相同的一组容器，这部分容器会出现负载率偏高的现象，对这些容器中的任务进行扩容，直至扩容到最大消费者数，如果之前的那组容器因为分配的任务过多，导致负载率仍然偏高，继续进行任务扩容，但是已经达到最大消费者数，此时会进行任务迁移，将负载率最高的容器中的负载率排名前5的任务进行任务迁移，迁移至负载率较低的容器中，之前的那组机器分配的任务数会被逐渐迁移开来，达到和其他机器平均分配任务的效果。

9. 遇到的问题以及建议改进

混部策略

混合部署中仅仅以水位为依据进行随机混部对于比较核心的任务不是很友好容易被资源抢占，需要设置不同的任务等级标签和混部策略，保证资源不足的情况下高等级任务被优先执行保证SLA。

自动降级机制

如何防止某些实现有问题的任务，消耗大量的资源，不断触发扩容，从而掏空整个集群，影响正常规则的执行，引发不公平，我们可能需要增加一种自动降级机制，针对某些不重要的任务或者问题任务在资源不够的情况下或者在预热的时间段触发降级。

扩缩容速度

虽然现在针对单次任务调度或者buffer池机器快上可以做到秒级，但是为了避免扩过了头或者缩过了头的问题，我们限制了单次任务扩缩容和快上快下的机器数，所以目前扩缩容对于相对较小的流量猛增可以做到秒级，但是对于几百倍甚至几千倍的流量猛增需要一定次数的扩容迭代周期来达到最终平衡，目前的策略虽然能很好的支持常态期间的秒级调度，但是对于大促场景还需要进行一定的改进。

自动压测机制

目前问题函数的发现依赖于线上真实流量，这是一种亡羊补牢的方式，而且任务的线程数配置和CPU密集型IO密集型的划分也是依赖于人工判断，存在预判的误差，如果有一套自动压测机制，针对每一个新上线的规则进行自动压测，获取它的性能数据，自动判断是否存在问题并且划分任务类型设置线程数，对于调度和buffer池容量评估也能提供更加科学准确的依据。

10. 总结

本文介绍了在接触实践Serverless中遇到的一些实际问题和做法，当应用规模扩展到一定程度的时候，势必会要求做更精细化的资源管理，比如上面说到的资源分配不均、碎片化、错峰资源、混合部署、运维等等问题，通过Serverless的架构模式来实现自动化运维调度以及更加灵活的弹性，能让系统资源做到更加合理充分的利用，也让云的红利离我们越来越近。

*文 /Gao

关注得物技术，每周一三五晚18:30更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～

过去，App里各种弹窗和贴片广告不仅令用户心烦，广告主们也头疼。一方面，广撒网的广告成本较高；另一方面，这些广告不能精准触达需要的用户。直到个性化广告的出现，才解决了这一痛点。

如今媒体广告主们为了更精准地投放广告，通常会收集用户个人数据来判断他们的特征定位、兴趣爱好或近期需求等，然后在App里进行定向的广告推送。基于有些用户不愿意共享隐私数据来接收个性化广告，所以App出于实现个性化广告的目的需要收集、使用和共享用户的个人数据，须先获得用户的有效同意。

HUAWEI Ads提供了征求用户意见能力，在一些隐私比较严格的地区，建议发布商通过HUAWEI Ads SDK接入个性化广告服务，将收集和使用用户的个人数据与HUAWEI Ads共享，HUAWEI Ads有权对媒体广告主们的隐私和数据合规性进行监督。默认情况下，向HUAWEI Ads平台发出的广告请求会投放个性化广告，并根据以前收集的用户数据筛选广告。HUAWEI Ads平台也支持通过配置广告请求来投放非个性化广告。详情请参见《HUAWEI Ads隐私与数据安全相关政策》“个性化广告和非个性化广告”。

为了征求用户意见，可以使用HUAWEI Ads平台提供的Consent SDK，也可以使用符合IAB TCF v2.0规范的CMP，详情请参见IAB TCF v2.0用户同意信息传递。

接下来我们就看一下如何使用Consent SDK征求用户意见，以及在征得用户意见后如何根据用户意见获取广告。

开发步骤

在开发前需要集成HMS Core SDK和HUAWEI Ads SDK，具体步骤可参考开发文档。

Consent SDK使用

集成Consent SDK。

a. 配置Maven仓地址。

Android Studio的代码库配置在Gradle 插件7.0以下版本、7.0版本和7.1及以上版本有所不同。请根据您当前的Gradle 插件版本，选择对应的配置过程。

b. 在应用级的“build.gradle”文件中添加编译依赖。

将{version}替换为实际的版本号，版本号索引请参见版本更新说明，修改如下：

c. 在完成以上的配置后，工具栏中的gradle同步图标，完成“build.gradle”文件的同步，将相关依赖下载到本地。

更新用户意见状态。

使用Consent SDK时，应确保Consent SDK获得的是HUAWEI Ads平台广告技术提供商的最新信息。如果在征求用户意见后，广告技术提供商的列表发生改变，则Consent SDK会自动将用户意见置为未知状态。因此在每次启动应用时都必须通过调用requestConsentUpdate()方法确定用户意见状态。示例代码如下所示：

如果成功更新用户意见信息，那么会通过ConsentUpdateListener的onSuccess()方法提供更新后的用户意见状态参数ConsentStatus、isNeedConsent参数（是否需要consent）和广告技术提供商的adProviders列表。

征求用户意见。

您需要通过弹框等方式向用户征求意见，并展示广告技术提供商的完整列表。以下是通过弹框征求用户意见的样例：

a. 弹框征求用户意见。

示例代码如下所示：

对话框效果图如下：

注：该页面仅为简单示例，具体实现需要开发者结合隐私界面自行设计UI。

“here”跳转至更多信息：

注：该页面仅为简单示例，具体实现需要开发者结合隐私界面自行设计UI。

b. 展示广告技术提供商列表。

您需要将广告技术提供商的名称展示给用户，并提供访问广告技术提供商隐私政策的入口。

通过上述更多信息页面中的here链接弹出广告技术提供商列表对话框，效果如下：

注：该页面仅为简单示例，具体实现需要开发者结合隐私界面自行设计UI。

c. 设置用户意见。

征得用户意见后，请使用setConsentStatus()方法设置用户的选择。示例代码如下所示：

d. 设置“未达到法定承诺年龄用户”的标记。

如果您需要针对未达到法定承诺年龄的用户请求对应的广告，则在调用requestConsentUpdate()前必须通过调用setUnderAgeOfPromise设置“未达到法定承诺年龄用户”的标记。示例代码如下所示：

一旦将此设置为“true”，则每次requestConsentUpdate()请求均会回调onFail(String errorDescription)方法，并提供给用户错误描述参数errorDescription，此时不需要再展示征求用户意见弹框。设置为“false”表明用户已达到法定承诺年龄。

根据用户意见获取广告。

请求广告时，默认不设置setNonPersonalizedAd方法，请求个性化广告与非个性化广告。如果用户在Consent阶段没有做出选择，则只能请求非个性化广告。

setNonPersonalizedAd方法的值可以设置为：

• ALLOW_ALL：个性化广告与非个性化广告

• ALLOW_NON_PERSONALIZED：非个性化广告

示例代码如下所示：

Consent SDK测试

为了让您能轻松地测试应用，Consent SDK提供了可设置的调试选项。

调用getTestDeviceId()获取设备ID。

示例代码如下所示：

使用获取的设备ID将您的设备作为调试设备列入允许清单。

示例代码如下所示：

调用setDebugNeedConsent设置是否需要Consent。

示例代码如下所示：

完成这些步骤后，调用更新用户意见状态时会根据您的调试状态返回isNeedConsent的值。

如果您需要了解更多Consent SDK相关信息，请查看此示例代码。

了解更多详情>>

访问华为开发者联盟官网
获取开发指导文档
华为移动服务开源仓库地址：GitHub、Gitee

关注我们，第一时间了解 HMS Core 最新技术资讯~

1 什么是流程引擎

流程引擎是一个底层支撑平台，是为提供流程处理而开发设计的。流程引擎和流程应用，以及应用程序的关系如下图所示。

常见的支撑场景有：Workflow、BPM、流程编排等。本次分享，主要从BPM流程引擎切入，介绍流程引擎的架构设计方法。

1.1 什么是流程

简单来说，流程就是一系列活动的组合。比如，用于企业办公的OA系统中，就存在大量的申请审批类的流程。在生产制造业，有大量的从销售端的订单，到生产制造，再到签收回款的生产销售流程。在机器学习领域，有亚马逊AWS Sagemaker的大数据处理、机器学习的应用。综上，流程是一个概念，在和具体实现结合时，就产生了不同的流程产品，如DevOps、Spring Data Stream等。
在流程实现方面，主要可以分为2种实现方式，一种是用代码实现，比如：用代码实现一个加班申请，那么就要自己对接SSO进行单点登录，通过接口拿到发起人和审批人的信息，同时保存表单数据。另一种方式是使用流程引擎来实现，流程引擎对接应用场景所需数据，如加班申请，流程引擎对接SSO、OU、审批人配置、权限等，实现这样一个流程，只需要关心流程配置、流程节点和流程表单即可，流程流转以及流程的数据处理，都通过流程引擎来完成。
流程引擎可以快速落地流程实现，这也是流程引擎存在的价值。

1.2 什么是引擎

一般而言，引擎是一个程序或一套系统的支持部分。常见的程序引擎有游戏引擎、搜索引擎、杀毒引擎等。引擎是脱离具体业务场景的某一类业务场景的高度抽象和封装。
比如，某OA公司，封装了一套审批用的workflow，实施人员只需要配置流程和表单即可交付项目。再比如，美国某公司做了一个AI引擎做NBA（Next Best Action）推荐，封装了推荐领域的常用算法，在不同的场景自动选择和组合多种算法，进行智能推荐。

1.3 流程设计器

流程设计器是流程和引擎的连接方，用户通过流程设计器，将某种layout和rule固化成某种流程，然后通过数据和数据上下文，使用流程引擎自动按照某种固化的流程进行执行。
我将目前见到的流程设计器的理论基础，分为以下三类：1，自定义系；2，UML中的活动图系；3，BPMN系。

1.3.1 自定义系

用于Sagemaker等场景的AWS Step Function（自定义流程节点）

1.3.2 UML Activity Diagram

Flowportal BPM的流程设计器

1.3.3 BPMN系

activiti的流程设计器

炎黄盈动的流程设计器

题外话：炎黄盈动的流程设计器，和processon中的流程设计器界面几乎一样，因为本质上是一家的。

2 流程引擎的应用

2.1 Workflow

工作流管理联盟(Workflow Management Coalition，WfMC)作为工作流管理的标准化组织而成立。
WfMC对工作流给出定义为：工作流是指一类能够完全自动执行的经营过程，根据一系列过程规则，将文档、信息或任务在不同的执行者之间进行传递与执行。

在workflow中，流程引擎主要用于支撑流程审批和数据流转，应用场景非常广泛。
国外产品（开源或商用）通常需求和操作比较简单，不会有国内的需求那么复杂。国内的产品，经历了众多客户的锤炼，功能目前都比较强大。
一般而言，workflow使用场景最多的是OA产品。在OA办公中，包含了企业办公中的大量素，这些素足够形成特定的产品，比如门户系统、移动办公。在OA的项目落地过程中，结合行业、业务侧重点又可以形成行业解决方案和专题方案。
以下是某OA公司产品和解决方案。

2.2 BPM（Business Process Management）

Workflow主要是解决审批和数据流转，而BPM主要是解决端到端、信息孤岛等问题而存在的。大多数用BPM产品的客户，都是在BPM基础上进行系统搭建，比如在BPM上面搭建OA、CRM、HR等系统。
BPM的使用场景，比Workflow更广泛，BPM产品中包含大量的和第三方系统交互的组件和自定义SQL、代码组件。比如，BPM系统中的文件触发器，可以在海关等交互场景下，通过监控FTP服务器中的文件，自动触发流程实例；可以通过定时器Timer，自动每日执行数据同步，并通过Mail节点将同步结果通知到相关运营成员等。

BPM的应用，可以按照执行前、执行中和执行后来划分。

2.3 流程编排

流程编排是脱离流程业务领域的更高一层抽象，使用方可以通过流程编排系统，结合自己的业务场景进行业务定制。比如，可以将相关业务代码，封装成function，然后通过云厂商平台的FAAS平台，将不同业务的function进行关联和调度，从而完成某项任务。

3 流程引擎的架构设计

鉴于一些朋友可能没有使用和接触过流程引擎，先介绍流程引擎的组成单，再介绍基于某个BPM产品的项目是如何进行开发的。我们通过BPM项目开发，对流程引擎的作用有个初步的认识。

3.1 BPM流程引擎的组成单

组织、角色、用户、成员的组织架构托管；
流程资源文件的配置、校验、存储和执行，对不同的流程节点，流程引擎自动结合配置、数据处理其对应的业务逻辑，流程数据自动处理；
表单配置、数据绑定，表单数据的根据流程配置自动处理；
通用的数据接口；

3.1.1 组织架构的设计

3.1.2 流程设计器

流程设计器包含左侧的分组节点列表，和右侧的画布。左侧的节点可以如下进行设计。

问题：对于一个XML或JSON格式的流程图，如何进行解析？
不同的节点，按照不同的业务场景，配置不同的配置项。比如，对于Human Node需要配置审批人，配置审批环节的展示表单，审批环节能够修改哪些字段，哪些字段的修改要进行留痕等。

3.1.3 表单设计器

这种是按照表单相关数据表，生成出一个表单，然后对表单字段进行配置和数据绑定。

这种是Drag&Drop控件，然后配置控件的属性，如绑定字段等。

这种是Drag&Drop控件，无需关联数据库表字段的表单

数据表生成表单的概要流程如下图所示。

拖拽控件绑定数据表字段的概要流程如下。

拖拽控件无需绑定数据表字段的概要流程。使用NoSQL的Document记录或使用RDS提供的JSON类型进行保存会比较方便。

3.1.4 接口设计

结合Activity的接口设计，如下图所示

一些系统在创建一个流程任务的时候，要先按照流程模板先创建一个应用示例，再关联发起人和备注，调用RuntimeService，执行到StartNode，这类设计因人而异，这么做略显繁琐。

3.2 基于流程引擎的项目开发实践

3.2.1 流程项目实践流程

确定组织架构
确定流程，包括流程布局、审批人设置、权限
确定表单信息（字段、类型、数据源、校验规则）和表单样式
确定页面布局、样式、数据字段、搜索、导入、导出
报表

3.2.2 组织架构

组织架构实现，有两种方法，一种是按照维度进行数据管理，另一种是在同一棵组织架构树下进行管理。
按照集团、公司、部门、用户等不同维度，进行数据管理，比较常见，这里不做讨论。下图为按维度维护数据的示例。

按照同一棵组织架构树进行数据维护，界面一般显示为左树右表。大多数商业化产品，都会将此组织架构树进行内存缓存，以方便审批人查找、开窗选择OrgUnit、Role、User、Member等场景。Member的引入是为了解决一人多职等场景。一般发起流程的时候，需要带出发起人拥有的Member列表，从而后续节点取合适的审批人。

对于组织架构而言，需要考虑，系统本身要具备OU存储的能力，对于没有组织架构的用户，可以直接在系统的组织架构中新建组织架构。同时，对于已有系统的客户，可以通过组织架构数据同步来进行数据自动维护。对于用AD域内部管控的客户来说，需要具备AD域身份认证的能力。对于复杂场景，比如用户是SaaS化等复杂场景，组织架构也需要在系统内部，支持使用API的方式来获取组织信息。
所以在组织架构设计的时候，要使用插件的方式来做，具体使用哪种插件，可以在配置文件中进行配置。以下为一个商业产品的组织架构操作界面示例。

常见的组织架构操作还有组织架构同步，比如流程系统同步微信企业号、钉钉等，这里不再展开。

3.2.3 流程设计

我们想象的流程，可能是向下面的这种简单流程。

而实际项目，碰到的流程，一般是如下图所示的情景。

初步看几个流程的模型文件是什么样的，先有个印象。

一个屏幕截图都截不完的流程，如果用代码去实现整个流程，其工作量和效率，可想而知。而实际做项目，使用基于流程引擎的产品来做项目的时候，只需要确定节点、节点配置、数据配置和权限即可。
问题：一般流程，都带有邮件通知的节点，如何实现邮件通知节点？请考虑以下情景。
流程流转和执行的时候，会遇到各种情况的错误，比如找不到审批人等，此时流程引擎要对数据做rollback，而邮件通知节点的业务逻辑已经执行过了。

权限方面，对于流程资源，哪些部门可以申请，哪些角色不可申请，都应该做流程控制。而在流程执行过程中，流程数据、不是路程的相关人也都不应该看到流程，处理过流程的审批人，不可以再对流程进行处理等，都是权限方面要考虑的问题。

3.2.4 表单设计

如下图所示的表单，可以分析以下，一个流程表单有多个主表信息和多个子表信息。一般而言，如果是通过流程引擎做非流程的数据处理，子表通过主表ID来做关联，如果通过流程引擎做流程的数据处理，子表和主表通过TaskId来做关联。以下为示例。

流程系统需要表单设计器，一个流程的不同节点可以挂接不同的表单，以方便不同角色的人关注不同维度的流程信息

3.2.5 页面设计

一般而言，对于流程的发起、审批、历史记录等，都是通用的系统界面。而一些业务场景，需要单独做列表界面，以方便使用。对于已有门户系统的客户，需要融合其界面样式。以下为曾经做过的项目示例。

3.2.6 报表

由于不是所有客户都有报表系统，所以流程系统需要具备一个基本的报表功能。下图为示例。

有报表系统的客户，可以使用其商业版报表系统，获取（直接取、数仓）数据进行展示。常见的报表系统有FineReport、Tableau、PowerBI等。

3.3 BPM流程引擎架构设计

3.3.1 流程引擎的架构设计

3.3.2 发起流程

流程引擎处理过程

执行节点处理过程

问题：在流程引擎处理过程中，如果一个节点有多条连线，如何寻找FromNodeId是某个Node的连线？
人工处理时，指定连线text

3.4 流程引擎架构设计

3.4.1 业务识别

识别业务场景中的配置项，使用集合或分组的方式，让业务可配置
支撑业务流程过程的可配置化
支撑业务场景中的数据，自动处理

3.4.2 流程引擎的实现

资源相关服务，资源加载，资源保存，资源加密等
配置项相关服务
PVM虚拟机的实现，即通过某个节点（发起时为开始节点）作为初始节点，按照某个连线的action进行节点的自动执行的虚拟机
数据配置、数据权限
流程数据和业务数据的自动处理

4 商业机会

Business Process Analysis (BPA) 流程分析，帮助企业进行流程调整和优化
Process Assets Library（PAL）流程资产库，对企业流程进行知识化沉淀，将制度和流程落地做绑定，让审批人知晓流程中对应的职责
Process Simulate 流程模拟，自动化测试
Process Forecast 流程预测
低代码平台
更广泛的机会，在于业务领域+流程引擎，比如：DevOps、RPA、应用与服务编排、数据编排、FaaS编排等。

作者：马瑞

摘要：从 OpenJDK8 起有了一个很 nice 的虚拟机内部功能： Native Memory Tracking (NMT)。

本文分享自华为云社区《Native Memory Tracking 详解（1）:基础介绍》，作者：毕昇小助手。

0.引言

我们经常会好奇，我启动了一个 JVM，他到底会占据多大的内存？他的内存都消耗在哪里？为什么 JVM 使用的内存比我设置的 -Xmx 大这么多？我的内存设置参数是否合理？为什么我的 JVM 内存一直缓慢增长？为什么我的 JVM 会被 OOMKiller 等等，这都涉及到 JAVA 虚拟机对内存的一个使用情况，不如让我们来一探其中究竟。

1.简介

除去大家都熟悉的可以使用 -Xms、-Xmx 等参数设置的堆（Java Heap），JVM 还有所谓的非堆内存（Non-Heap Memory）。

可以通过一张图来简单看一下 Java 进程所使用的内存情况（简略情况）：

非堆内存包括方法区和Java虚拟机内部做处理或优化所需的内存。

方法区：在所有线程之间共享，存储每个类的结构，如运行时常量池、字段和方法数据，以及方法和构造函数的代码。方法区在逻辑上（虚拟机规范）是堆的一部分，但规范并不限定实现方法区的内存位置和编译代码的管理策略，所以不同的 Java 虚拟机可能有不同的实现方式，此处我们仅讨论 HotSpot。
除了方法区域外，Java 虚拟机实现可能需要内存用于内部的处理或优化。例如，JIT编译器需要内存来存储从Java虚拟机代码转换的本机代码（储存在CodeCache中），以获得高性能。

从 OpenJDK8 起有了一个很 nice 的虚拟机内部功能： Native Memory Tracking (NMT) 。我们可以使用 NMT 来追踪了解 JVM 的内存使用详情（即上图中的 JVM Memory 部分），帮助我们排查内存增长与内存泄漏相关的问题。

2.如何使用

2.1 开启 NMT

默认情况下，NMT是处于关闭状态的，我们可以通过设置 JVM 启动参数来开启：-XX:NativeMemoryTracking=[off | summary | detail]。

注意：启用NMT会导致5% -10%的性能开销。

NMT 使用选项如下表所示：

我们注意到，如果想使用 NMT 观察 JVM 的内存使用情况，我们必须重启 JVM 来设置XX:NativeMemoryTracking 的相关选项，但是重启会使得我们丢失想要查看的现场，只能等到问题复现时才能继续观察。

笔者试图通过一种不用重启 JVM 的方式来开启 NMT ，但是很遗憾目前没有这样的功能。

JVM 启动后只有被标记为 manageable 的参数才可以动态修改或者说赋值，我们可以通过 JDK management interface (com.sun.management.HotSpotDiagnosticMXBean API) 或者 jinfo -flag 命令来进行动态修改的操作，让我们看下所有可以被修改的参数值（JDK8）：

很显然，其中不包含 NativeMemoryTracking 。

2.2 使用 jcmd 访问 NMT 数据

我们可以通过 jcmd 命令来很方便的查看 NMT 相关的数据：

jcmd 操作 NMT 选项如下表所示：

NMT 默认打印的报告是 KB 来进行呈现的，为了满足我们不同的需求，我们可以使用scale=MB | GB来更加直观的打印数据。
创建 baseline 之后使用 diff 功能可以很直观地对比出两次 NMT 数据之间的差距。

看到 shutdown 选项，笔者本能的一激灵，既然我们可以通过 shutdown 来关闭 NMT ，那为什么不能通过逆向 shutdown 功能来动态的开启 NMT 呢？笔者找到 shutdown 相关源码（以下都是基于 OpenJDK 8）：

遗憾的是通过源码我们发现，shutdown 操作只是将 NMT 的追踪等级 tracking_level 变成了 NMT_minimal 状态（而并不是直接变成了 off 状态），注意注释：We can only shutdown NMT to minimal tracking level if it is ever on（即我们只能将NMT关闭到最低跟踪级别，如果它曾经打开）。

这就导致了如果我们没有开启过 NMT ，那就没办法通过魔改 shutdown 操作逆向打开 NMT ，因为 NMT 追踪的部分内存只在 JVM 启动初始化的阶段进行记录（如在初始化堆内存分配的过程中通过 NMT_TrackingLevel level = MemTracker::tracking_level(); 来获取 NMT 的追踪等级，视等级来记录内存使用情况），JVM 启动之后再开启 NMT 这部分内存的使用情况就无法记录，所以目前来看，还是只能在重启 JVM 后开启 NMT。

至于提供 shutdown 功能的原因，应该就是让用户在开启 NMT 功能之后如果想要关闭，不用再次重启 JVM 进程。shutdown 会清理虚拟内存用来追踪的数据结构，并停止一些追踪的操作（如记录 malloc 内存的分配）来降低开启 NMT 带来的性能耗损，并且通过源码可以发现 tracking_level 变成 NMT_minimal 状态后也不会再执行 jcmd VM.native_memory 命令相关的操作。

2.3 虚拟机退出时获取 NMT 数据

除了在虚拟机运行时获取 NMT 数据，我们还可以通过两个参数：-XX:+UnlockDiagnosticVMOptions和-XX:+PrintNMTStatistics ，来获取虚拟机退出时内存使用情况的数据（输出数据的详细程度取决于你设定的跟踪级别，如 summary/detail 等）。

-XX:+UnlockDiagnosticVMOptions：解锁用于诊断 JVM 的选项，默认关闭。

-XX:+PrintNMTStatistics：当启用 NMT 时，在虚拟机退出时打印内存使用情况，默认关闭，需要开启前置参数 -XX:+UnlockDiagnosticVMOptions 才能正常使用。

3.NMT 内存 & OS 内存概念差异性

我们可以做一个简单的测试，使用如下参数启动 JVM ：

然后使用 NMT 查看内存使用情况（因各环境资源参数不一样，部分未明确设置数据可能由虚拟机根据资源自行计算得出，以下数据仅供参考）：

NMT 会输出如下日志：

大家可能会发现 NMT 所追踪的内存（即 JVM 中的 Reserved、Committed）与操作系统 OS （此处指Linux）的内存概念存在一定的差异性。

首先按我们理解的操作系统的概念：

操作系统对内存的分配管理典型地分为两个阶段：保留（reserve）和提交（commit）。保留阶段告知系统从某一地址开始到后面的dwSize大小的连续虚拟内存需要供程序使用，进程其他分配内存的操作不得使用这段内存；提交阶段将虚拟地址映射到对应的真实物理内存中，这样这块内存就可以正常使用 [1]。

如果使用 top 或者 smem 等命令查看刚才启动的 JVM 进程会发现：

此时疑问就产生了，为什么 NMT 中的 committed ，即日志详情中 Total: reserved=KB, committed=KB 中的 KB 与 top 中 RES 的大小54200KB 存在如此大的差异？

使用 man 查看 top 中 RES 的概念（不同版本 Linux 可能不同）：

RES 表示任务当前使用的非交换物理内存（此时未发生swap），那按对操作系统 commit 提交内存的理解，这两者貌似应该对上，为何现在差距那么大呢？

笔者一开始猜测是 JVM 的 uncommit 机制（如 JEP 346[2]，支持 G1 在空闲时自动将 Java 堆内存返回给操作系统，BiSheng JDK 对此做了增强与改进[3]）造成的，JVM 在 uncommit 将内存返还给 OS 之后，NMT 没有除去返还的内存导致统计错误。

但是在翻阅了源码之后发现，G1 在 shrink 缩容的时候，通常调用链路如下：

G1CollectedHeap::shrink ->

G1CollectedHeap::shrink_helper ->

HeapRegionManager::shrink_by ->

HeapRegionManager::uncommit_regions ->

G1PageBasedVirtualSpace::uncommit ->

G1PageBasedVirtualSpace::uncommit_internal ->

os::uncommit_memory

忽略细节，uncommit 会在最后调用 os::uncommit_memory ，查看 os::uncommit_memory 源码：

可以发现在返还 OS 内存之后，MemTracker 是进行了统计的，所以此处的误差不是由 uncommit 机制造成的。

既然如此，那又是由什么原因造成的呢？笔者在追踪 JVM 的内存分配逻辑时发现了一些端倪，此处以Code Cache（存放 JVM 生成的 native code、JIT编译、JNI 等都会编译代码到 native code，其中 JIT 生成的 native code 占用了 Code Cache 的绝大部分空间）的初始化分配为例，其大致调用链路为下：

InitializeJVM ->

Thread::vreate_vm ->

init_globals ->

codeCache_init ->

CodeCache::initialize ->

CodeHeap::reserve ->

VirtualSpace::initialize ->

VirtualSpace::initialize_with_granularity ->

VirtualSpace::expand_by ->

os::commit_memory

查看 os::commit_memory 相关源码：

我们发现 MemTracker 在此记录了 commit 的内存供 NMT 用以统计计算，继续查看 os::pd_commit_memory 源码，可以发现其调用了 os::Linux::commit_memory_impl 函数。

查看 os::Linux::commit_memory_impl 源码：

问题的原因就在 uintptr_t res = (uintptr_t) ::mmap(addr, size, prot, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0); 这段代码上。

我们发现，此时申请内存执行的是 mmap 函数，并且传递的 port 参数是 PROT_READ|PROT_WRITE|PROT_EXEC 或 PROT_READ|PROT_WRITE ，使用 man 查看 mmap ，其中相关描述为：

由此我们可以看出，JVM 中所谓的 commit 内存，只是将内存 mmaped 映射为可读可写可执行的状态！而在 Linux 中，在分配内存时又是 lazy allocation 的机制，只有在进程真正访问时才分配真实的物理内存。所以 NMT 中所统计的 committed 并不是对应的真实的物理内存，自然与 RES 等统计方式无法对应起来。

所以 JVM 为我们提供了一个参数 -XX:+AlwaysPreTouch，使我们可以在启动之初就按照内存页粒度都访问一遍 Heap，强制为其分配物理内存以减少运行时再分配内存造成的延迟（但是相应的会影响 JVM 进程初始化启动的时间），查看相关代码：

让我们来验证下，开启 -XX:+AlwaysPreTouch 前后的效果。

NMT 的 heap 地址范围：

对应该地址的/proc/{pid}/smaps：

对应的/proc/{pid}/status：

开启参数后的 top：

观察对比我们可以发现，开启 AlwaysPreTouch 参数后，NMT 统计的 commited 已经与 top 中的 RES 差不多了，之所以不完全相同是因为该参数只能 Pre-touch 分配 Java heap 的物理内存，至于其他的非 heap 的内存，还是受到 lazy allocation 机制的影响。

同理我们可以简单看下 JVM 的 reserve 机制：

reserve 通过 mmap(requested_addr, bytes, PROT_NONE, flags, -1, 0); 来将内存映射为 PROT_NONE，这样其他的 mmap/malloc 等就不能调用使用，从而达到了 guard memory 或者说 guard pages 的目的。

OpenJDK 社区其实也注意到了 NMT 内存与 OS 内存差异性的问题，所以社区也提出了相应的 Enhancement 来增强功能：

1.JDK-[4] ：

- 目前 NMT 将分配的内存显示为 Reserved 或 Committed。而在 top 或 pmap 的输出中，首次使用（即 touch）之前 Reserved 和 Committed 的内存都将显示为 Virtual memory。只有在内存页（通常是4k）首次写入后，它才会消耗物理内存，并出现在 top/pmap 输出的 “常驻内存”（即 RSS）中。
- 当前NMT输出的主要问题是，它无法区分已 touch 和未 touch 的 Committed 内存。
- 该 Enhancement 提出可以使用 mincore() [5]来查找 NMT 的 Committed 中 RSS 的部分，mincore() 系统调用让一个进程能够确定一块虚拟内存区域中的分页是否驻留在物理内存中。mincore()已在JDK- NMT：增强线程堆栈跟踪中实现，需要将其扩展到所有其他类型的内存中（如 Java 堆）。
- 遗憾的是该 Enhancement 至今仍是 Unresolved 状态。

2.JDK-[6] ：

- 1 中提到的 NMT：增强线程堆栈跟踪。使用 mincore() 来追踪驻留在物理内存中的线程堆栈的大小，用以解决线程堆栈追踪时有时会夸大内存使用情况的痛点。
- 该 Enhancement 已经在 JDK11 中实现。

参考

https://weread..com/web/reader/fk37632cd0cfc7149
http://openjdk.java.net/jeps/346
https://gitee.com/openeuler/bishengjdk-8/wikis/G1GCååä¼¸ç¼©ç¹æ§ä»ç»?sort_id=
https://bugs.openjdk.org/browse/JDK-
https://man7.org/linux/man-pages/man2/mincore.2.html
https://bugs.openjdk.org/browse/JDK-

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

作者｜Jeff Dean

翻译｜沈佳丽、胡燕君、贾川

为什么芯片设计需要很长时间？能不能加速芯片设计周期？能否在几天或几周之内完成芯片的设计？这是一个非常有野心的目标。过去十年，机器学习的发展离不开系统和硬件的进步，现在机器学习正在促使系统和硬件发生变革。

Google在这个领域已率先出发。在第58届DAC大会上，Google AI负责人Jeff Dean分享了《机器学习在硬件设计中的潜力》，他介绍了神经网络发展的黄金十年，机器学习如何影响计算机硬件设计以及如何通过机器学习解决硬件设计中的难题，并展望了硬件设计的发展方向。

他的演讲重点在于Google如何使用机器学习优化芯片设计流程，这主要包括架构搜索和RTL综合、验证、布局与布线（Placement and routing）三大阶段。在架构搜索阶段，Google提出了FAST架构自动优化硬件加速器的设计，而在验证阶段，他们认为使用深度表示学习可提升验证效率，在布局与布线阶段，则主要采用了强化学习技术进行优化。

以下是他的演讲内容，由OneFlow社区编译。

神经网络的黄金十年

制造出像人一样智能的计算机一直是人工智能研究人员的梦想。而机器学习是人工智能研究的一个子集，它正在取得很多进步。现在大家普遍认为，通过编程让计算机变得“聪明”到能观察世界并理解其含义，比直接将大量知识手动编码到人工智能系统中更容易。

神经网络技术是一种非常重要的机器学习技术。神经网络一词出现于1980年代左右，是计算机科学术语中一个相当古老的概念。虽然它当时并没有真正产生巨大的影响，但有些人坚信这是正确的抽象。

本科时，我写了一篇关于神经网络并行训练的论文，我认为如果可以使用64个处理器而不是一个处理器来训练神经网络，那就太棒了。然而事实证明，我们需要大约100万倍的算力才能让它真正做好工作。

2009年前后，神经网络技术逐渐火热起来，因为我们开始有了足够的算力让它变得有效，以解决现实世界的问题以及我们不知道如何解决的其他问题。2010年代至今是机器学习取得显著进步的十年。

是什么导致了神经网络技术的变革？我们现在正在做的很多工作与1980年代的通用算法差不多，但我们拥有越来越多的新模型、新优化方法等，因此可以更好地工作，并且我们有更多的算力，可以在更多数据上训练这些模型，支撑我们使用更大型的模型来更好地解决问题。

在探讨设计自动化方面之前，我们先来看看一些真实世界的例子。首先是语音识别。在使用深度学习方法之前，语音识别很难得到实际应用。但随后，使用机器学习和神经网络技术，大幅降低了词语的识别错误率。

几年后，我们将错误率降低到5%左右，让语音识别更加实用，而现在，在不联网的设备里，我们都可以做到仅仅4%左右的错误率。这样的模型被部署在人们的手机里面，随时随地帮助人们识别自己的语音。

计算机视觉方面也取得了巨大的进步。2012年左右，Alex Krizhevsky、Ilya Sutskever和Geoffrey Hinton在ImageNet比赛中首次使用了AlexNet，错误率得到显著降低，并在当年夺得桂冠。

后一年的ImageNet比赛中，几乎所有参赛者都使用深度学习方法，研究人员则进一步放弃了传统的方法。其中，2015年，由何恺明等微软研究人员提出ResNet更进一步降低了错误率。

当时的斯坦福大学研究生Andrej Karpathy正在帮助运营ImageNet比赛，他想知道如果人工识别这项艰难的任务，错误率会是多少。在上千个类别中有40种狗，你必须能够看着一张照片说：“哦，那是一只罗威纳犬，不是一只大力金刚犬，或者其他品种的狗。” 经过一百个小时的训练，他将错误率降到了5%。

这是一项非常艰难的任务，将计算机识别错误率从2011年的26%降低到2017年的2%是一件很了不起的事，过去计算机无法识别的东西，现在已经可以识别。自然语言处理、机器翻译和语言理解中也经历了类似的故事。

此外，开源框架确实使世界各地的许多人能够应用机器学习技术，TensorFlow就是其中之一。

大约在2015年11月，我们开源了TensorFlow以及供Google内部使用的工具。TensorFlow对世界产生了相当大的影响，它已经被下载了大约5000万次，当然也出现了很多其他框架，比如JAX、PyTorch等等。

世界各地的人们能够将机器学习用于各种了不起的用途，例如医疗保健、机器人技术、自动驾驶等等，这些领域都是通过机器学习方法来理解周围的世界，进而推动领域的发展。

机器学习改变计算机设计方式

ML研究社区中的许多成功源自使用更多算力和更大的模型，更多的算力促进了机器学习研究领域中重要成果的产生。深度学习的发展正在深刻改变计算机的结构。现在，我们想围绕机器学习计算类型构建专门的计算机。

近年来，我们已经在Google做了很多类似的工作，其中TPU（张量处理单）是我们构建定制处理器的一种方法，这些处理器专为神经网络和机器学习模型而设计。

TPU v1是我们第一个针对推理的产品，当你拥有经过训练的模型，并且只想获得已投入生产使用的模型的预测结果，那它就很适合，它已经被用于神经机器翻译的搜索查询、AlphaGo比赛等应用中。

后来我们还构建了一系列处理器。TPU v2旨在连接在一起形成称为Pod的强大配置，因此其中的256个加速器芯片通过高速互联紧紧连接在一起。TPU v3则增加了水冷装置。

TPU v4 Pod不仅可以达到ExaFLOP级的算力，它还让我们能够在更大的模型训练中达到SOTA效果，并尝试做更多的事情。

以ResNet-50模型为例，在8块P100 GPU上训练完ResNet-50需要29小时，而在2021年6月的MLPerf竞赛中，TPU v4 pod仅耗时14秒就完成了训练。但我们的目的不仅仅是在14秒内训练完ResNet，而是想把这种强大的算力用于训练其他更先进的模型。

可以看到，从一开始的29小时到后来的14秒，模型的训练速度提高了7500倍。我认为实现快速迭代对于机器学习非常重要，这样才能方便研究者试验不同想法。

基于机器学习的计算方式越来越重要，计算机也正在往更适应机器学习计算方式的方向上演进。但深度学习有可能影响计算机的设计方式吗？我认为，答案是肯定的。

机器学习缩短芯片设计周期

目前，芯片的设计周期非常长，需要几十甚至几百人的专业团队花费数年的努力。从构思到完成设计，再到成功生产，中间的时间间隔十分漫长。但如果将来设计芯片只需要几个人花费几周时间呢？这是一个非常理想的愿景，也是研发人员当前的目标。

如上图所示，芯片设计包含四个阶段：架构探索→RTL综合→验证→布局和布线。完成设计之后，在制作生产环节需要进行布局和布线（Placement & Routing），有没有更快、更高质量的布局和布线方法？验证是非常耗时的一步，能不能用更少的测试次数涵盖更多的测试项目？有没有自动进行架构探索和RTL综合的方法？目前，我们的芯片架构探索只针对几种重要的应用，但我们终将要把目光扩大。

布局与布线

首先，关于布局和布线，Google在2020年4月发表过一篇论文Chip Placement with Deep Reinforcement Learning，2021年6月又在Nature上发表了A graph placement methodology for fast chip design。

我们知道强化学习的大致原理：机器执行某些决定，然后接收奖励（reward）信号，了解这些决定带来什么结果，再据此调整下一步决定。

因此，强化学习非常适合棋类游戏，比如国际象棋和围棋。棋类游戏有明确的输赢结果，机器下一盘棋，总共有50到100次走棋，机器可以根据最终的输赢结果评定自己和对手的整套走棋方法的有效性，从而不断调整自己的走棋，提高下棋水平。

那么ASIC芯片布局这项任务能不能也由强化学习智能体来完成呢？

这个问题有三个难点。第一，芯片布局比围棋复杂得多，围棋有10^{360}种可能情况，芯片布局却有10^{9000}种。

第二，围棋只有“赢”这一个目标，但芯片布局有多个目标，需要权衡芯片面积、时序、拥塞、设计规则等问题，以找到最佳方案。

第三，使用真实奖励函数（true reward function）来评估效果的成本非常高。当智能体执行了某种芯片布局方案后，就需要判断这个方案好不好。如果使用EDA工具，每次迭代都要花上很多个小时，我们希望将每次迭代所需时间缩减为50微秒或50毫秒。

利用强化学习进行芯片布局的步骤如下：首先从空白底座开始，运用分布式PPO算法（强化学习的常用算法）进行设计，然后完成每个节点的布局放置，最后进行评估。

评估步骤使用的是代理奖励函数（proxy reward function），效果和真实奖励函数相近，但成本低得多。在一秒或半秒内就可以完成对本次布局方案的评估，然后指出可优化之处。

构建奖励函数需要结合多个不同的目标函数，例如线长、拥塞和密度，并分别为这些目标函数设定权重。

如上图所示，布局优化采取的是混合方式。强化学习智能体每次放置宏（macro），然后通过力导向方法（force-directed method）放置标准单。

上图来自前面提到的Nature论文，展示了更多芯片架构的细节。

上图展示了一个TPU设计块的布局与布线结果。白色区域是宏，绿色区域是标准单群（standard cell clusters）。

图中左边是人类专家完成的设计，从中可以看出一些规律。人类专家倾向于把宏沿边缘放置，把标准单放在中间。一名人类专家需要6~8周完成这个布局，线长为57.07米。图中右边是由智能体（ML placer）完成的布局，耗时24小时，线长55.42米，违反设计规则的地方比人类专家略多，但几乎可以忽略。

可以看出，智能体并不像人类专家一样追求直线布局。为了优化布局，智能体更倾向于弧形布局。我们也希望能训练智能体高效地创造一些前所未有的布局方式。

为了实现这个目标，首先，我们运用强化学习算法优化某个芯片设计块的布局，期间需要经历上万次迭代；然后，重复前一步骤，在多个不同的设计块上预训练出一套布局规则，最终让算法在面对前所未见的新设计块时也能给出布局方案。

预训练好的策略有助于在推理时做更少的迭代，进行“零次（zero-shot）布局”。我们实际上还没有新算法来优化这个特定的设计，当然我们可以做数百次迭代以得到更好的结果。

上图展示了使用不同方法时的布局成本。蓝线表示不经过预训练的从头训练策略的布局成本，绿线表示用已预训练的算法优化新设计块的布局，X轴表示训练时间，可以看到，蓝线在经过20多小时的训练后方可大幅降低布局成本，此后仍需经过一段时间才能达到收敛。而绿线只用了极少的训练时间就达到了更低的布局成本并很快收敛。

最令我感到兴奋的是圈红部分。调优预训练策略在短时间内就可实现相当不错的布局，这种实现就是我所说的，在一两秒内完成芯片设计的布局。

上图展示了更详细的不同设计的情况。Y轴表示线长成本（越低越好）。绿色表示使用商业工具的线长成本，可以看到，从浅蓝色（零次布局）→蓝色（2小时微调）→深蓝色（12小时微调），线长成本越来越低。深蓝色一直比黄色的线长成本要低，因为通过12小时的微调能从其他设计中学到最佳布局。

上图中，左边和右边分别展示了从头训练的策略和经过微调预训练策略的芯片布局过程。每个小方块表示一个宏的中心，空白部分表示为标准单预留的位置。可以看到，右边从一开始就将宏放在边缘，将大片中间区域留空。而左边则要经过很多次迭代才能形成这样的格局。

我们利用强化学习工具针对TPU v5芯片的37个设计块进行了布局与布线。其中，26个设计块的布局与布线质量优于人类专家，7个设计块的质量与人类专家相近，4个设计块的质量不如人类专家。目前我们已经把这个强化学习工具投入到芯片设计流程中了。

总的来说，用机器学习进行芯片布局与布线的好处包括：可以快速生成多种布局方案；即使上游设计有重大改动也可以迅速重新布局；大幅减少开发新ASIC芯片所需的时间和精力。

验证

接下来是芯片设计的验证阶段。我们希望用较少的测试次数覆盖多个测试项目。验证是阻碍芯片设计提速的主要瓶颈。据估计，芯片设计过程中，80%的工作量在于验证，而设计本身仅占20%。因此，验证技术的任何一点进步都会产生重大作用。

Google在2021年NeurIPS（神经信息处理系统大会）上发表了论文《Learning Semantic Representations to Verify Hardware Designs》，我们能不能运用机器学习生成在更短时间内覆盖更广状态空间的测试用例？

验证阶段的基本问题是可达性（reachability）。目前的芯片设计能否让系统达成需要的状态？我们的想法是，根据当前的芯片设计生成一个连续的表示，从而预测对系统的不同状态的可达性。

我们可以通过RTL将芯片设计抽象为一张图，然后运用基于图的神经网络去了解该图的特性，从而了解其对应芯片设计的特性，继而决定测试覆盖率和测试用例，这给了我们一个很好的设计的抽象表示。

当然，如何将这种方法应用到实际芯片设计中将是另外一个重要话题。用RTL生成图表示之后，我们在图神经网络中运用一种叫Design2Vec的技术进行深度表示学习，从而帮助我们作出预测。

目前，芯片的验证环节需要大量人力，例如，找bug、查找测试覆盖率漏洞、分析和解决bug等，还需要经历多次如上图所示的流程循环。我们希望上述步骤可以实现自动化，自动生成新的测试用例以解决重要的问题。

后来我们发现，可以把这个问题转化为一个监督学习问题。如果之前进行了一系列测试，并知道这些测试覆盖哪些测试点，就可以将这些数据用作监督学习中的训练数据。

然后，当出现新的测试点时，假设进行一个新的测试，我们需要预测这个测试能否覆盖新的测试点。我们希望能结合之前的训练数据以及芯片设计本身，来实现这种预测。

我们有两个Baseline，其中一个能够看到测试点（test points）和覆盖点（cover points）的数据，这是一个黑盒测试。

而Design2Vec除了能够处理上述数据外，还能处理实际设计、设计的图结构等等。如果你使用一半的测试点作为训练数据，并且设置多个大小不同的训练集，然后对其它测试点进行预测，那么将会得到非常出色的结果，即使是对于相对较少的覆盖点，也能泛化得非常好。相比之下，Baseline这种方法就不能对此进行很好地泛化。

但使用图神经网络来学习设计、覆盖率和测试属性的方法，实际上比NeurIPS论文中的其他所有Baseline都要好。

例如，我们常会遇到很多难以生成测试的覆盖点。工程师们发现使用RISC-V Design和TPU Design这两种不同的设计也很难为这些特定的覆盖点生成测试，于是我们又转向使用贝叶斯优化器来尝试生成测试。

上图右边这一列是贝叶斯优化器覆盖的不同测试点、覆盖点所需的模拟器调用数（simulator calls），中间一列是使用Design2Vec所需的模拟器调用数。从中可以看到，为覆盖这些有挑战性的覆盖点，Design2Vec生成的测试要少于贝叶斯优化器。所以Design2Vec非常好，相比之下它更快，能聚焦覆盖范围，还能节省在运行计算模拟器（本身很昂贵）上的开销。

验证是芯片设计在理论和实践上长期面临的一个挑战。我们认为，深度表示学习能够显著提高验证效率和质量，并且在设计中实现泛化。

即使设计发生了一些改变，这个新设计的版本也能运用之前在众多设计上训练出来的系统，提高验证效率。正如在布局与布线阶段，经过训练后的算法即使面对新设计也能够预测不同测试的覆盖点，以带来好的结果。

架构探索和RTL综合

在芯片设计中，另一个比较耗时的方面是要清楚你究竟想要构建何种设计。此时你需要做一些架构探索（architectural exploration），然后做RTL综合。目前计算机架构师和其他芯片设计师等具有不同专业知识的人花费大量时间来构建他们真正想要的设计，然后验证、布局和布线，那么我们可以学习自动做架构探索和综合吗？

现在我们正在研究的就是如何为已知的问题实行架构探索。如果我们有一个机器学习模型，并且想要设计一个定制芯片来运行这个模型，这个过程能否实现自动化，并提出真正擅长运行该特定模型的优秀设计。

关于这项工作，我们在arXiv发表了论文《A Full-stack Accelerator Search Technique for Vision Applications》，它着眼于很多不同的计算机视觉模型。另外一个进阶版本的论文被ASPLOS大会接收了《A Full-stack Search Technique for Domain Optimized Deep Learning Accelerators》。

这里要解决的问题是：当你设计一个机器学习加速器时，需要考虑你想在哪个加速器上运行什么样的机器学习模型，而且这个领域的变化非常之快。

上图中的红线是指引入的不同计算机视觉模型，以及通过这些新模型实现的ImageNet识别准确率提升。

但问题是，如果你在2016年想要尝试设计一个机器学习加速器，那么你需要两年时间来设计芯片，而设计出来的芯片三年后就会被淘汰。你在2016年做的决定将会影响计算，要保证在2018年-2021年高效运行，这真的很难。比如在2016年推出了Inception-v3模型，但此后计算机视觉模型又有四方面的大改进。

因此，如果我们能使设计周期变得更短，那么也许单个工作负载加速器能变得可用。如果我们能在诸多流程中实现自动化，那么我们或许能够得到正反馈循环，即：缩短机器学习加速器的上市时间，使其能更适合我们当下想要运行的模型，而不用等到五年后。

用机器学习探索设计空间

实际上，我们可以使用机器学习来探索设计空间。有两个因素影响加速器性能，一是设计中内置的硬件数据通道，二是工作负载如何通过编译器而不是更高级别的软件映射到该数据通道。通常，设计空间探索实际上只考虑当前编译器优化的数据通道，而不是协同设计的编译器优化和优化数据通道时可能会做的事。

因此，我们能否同时优化数据通道、调度（schedule）和一些编译器决策，并创建一个搜索空间，探索出你希望做出的共同设计的决策。这是一种覆盖计算和内存瓶颈的自动搜索技术，探索不同操作之间的数据通道映射和融合。通常，你希望能够将事物融合在一起，避免内存传输的每次内存负载中执行更多操作。

根本上说，我们在机器学习加速器中可能做出的设计决策创建了一种更高级别的搜索空间，因此，可以探索乘法的脉冲列阵（systolic array）在一维或二维情况下的大小，以及不同的缓存大小等等。

如前所述，考虑编译器优化与硬件设计的协同设计也很重要，因为如果默认编译器不会更改，就无法真正利用处理器中底层设计单的变化。实际上，不一定要考虑特定设计的所有效果和影响。

接下来看看这种方式产生的一系列结果，将这些结果与TPUv3芯片的baseline（上图蓝条）进行比较。实际上这是假定型TPUv3芯片，其中模拟器已停止了运行。我们已经将其缩小到了sub-10纳米工艺。我们还将研究TPUv3的软件效用，以及共同探索在设计空间中的编译器优化。

红条和蓝条表示的内容是一致的，但一些探索过的编译器优化不一定在蓝条中得以体现，而这里的绿条则表示的是为单一计算机视觉模型定制的假定型设计。EfficientNet-B0…B7表示相关但规模不同的计算机视觉模型。与蓝条baseline相比，（绿条的）Perf/TDP的改进大约在3到6倍之间。

那么除EfficientNet-B0…B7外，其他模型的情况如何？在此前所述的ASPLOS论文中提出更广泛的模型集，尤其是那些计算机视觉以外的BERT-seq 128和BERT-seq 1024等NLP模型。

实际上，定制化芯片不只是适用于单个机器学习模型，而是使其适用于一组机器学习模型。你可能不想使你的加速器芯片设计仅针对某一项任务，而是想涵盖你所关注的那一类任务。

上图的黄条代表为五种不同模型设计的定制化芯片，而我们想要一个能同时运行这五种模型（红色箭头所指）的芯片，然后就能看出其性能能达到何种程度。可喜的是，从中可以看到，黄条（单一负载）并不比绿条（多负载）的性能低多少。所以你实际上可以得到一个非常适合这五种模型的加速器设计，这就好比你对其中任何一个模型都进行了优化。它的效果可能不是最好的，但已经很不错了。

而且，如果你关注的点是性能而非Perf/TDP，得到的结果实际上会更好。所以结果如何取决于你关注的是什么，是绝对性能还是每瓦性能？在Perf//TDP指标中，性能结果甚至提升了2.6到8.8倍，而非Perf/TDP指标下的1.8到6.4倍。

因此，我们能够针对特定工作负载进行定制和优化，而不用构建更多通用设备。我认为这将会带来显著改进。如果能缩短设计周期，那么我们将能以一种更自动化的方式用定制化芯片解决更多问题。

当前的一大挑战是，如果了解下为新问题构建新设计的固定成本，就会发现固定成本还很高，因此不能广泛用于解决更多问题。但如果我们能大幅降低这些固定成本，那么它的应用面将会越来越广。

总结

我认为，在计算机芯片的设计过程中，机器学习将大有作为。

如果机器学习在合适的地方得以正确应用，那么在学习方法（learning approaches）和机器学习计算的加持下，芯片设计周期能不能缩短，只需要几个人花费几周甚至几天完成呢？我们可以用强化学习使得与设计周期有关的流程实现自动化，我认为这是一个很好的发展方向。

目前人们正通过一组或多组实验来进行测验，并基于其结果来决定后续研发方向。如果这个实验过程能实现自动化，并且能获取满足该实验正常运行的各项指标，那么我们完全有能力实现设计周期自动化，这也是缩短芯片设计周期的一个重要方面。

这是本次演讲的部分参考文献以及相关论文，主要涉及机器学习在芯片设计和计算机系统优化中的应用。

机器学习正在很大程度上改变人们对计算的看法。我们想要的是一个可以从数据和现实世界中学习的系统，其计算方法与传统的手工编码系统完全不同，这意味着我们要采取新方式，才能创建出我们想要的那种计算设备和芯片。同时，机器学习也对芯片种类和芯片设计的方法论产生了影响。

我认为，加速定制化芯片设计过程中应该将机器学习视为一个非常重要的工具。那么，到底能否将芯片设计周期缩短到几天或者几周呢？这是可能的，我们都应该为之奋斗。

（原视频：https://www.youtube.com/watch?v=FraDFZ2t__A）

其他人都在看

OneFlow v0.8.0正式发布
深度学习硬件的过去、现在和未来
Groq：从头设计一个张量流式处理器架构
AI加速器与机器学习算法：协同设计与进化
Hinton等谈DL十年；PyTorch落地Linux基金会
OneEmbedding:单卡训练TB级推荐模型不是梦
大模型训练难？效率超群、易用的“李白”模型库来了

欢迎下载体验 OneFlow v0.8.0 最新版本：
https://github.com/Oneflow-Inc/oneflow/

一个涛思数据的 Fun Fact：TDengine 工程师平均年龄刚好 35 岁。

从创始人陶建辉的故事开始，大龄程序员的标签就和涛思数据紧紧地扣在一起。一个 53 岁的程序员，为 TDengine 写下了第一行代码，开启了他人生的第三次创业之旅。

他本人常说，“写程序是一辈子的事，而代码是你最好的简历，代码是你实力的最好证明。当你看了我贡献的近5万行 TDengine 代码，你一定不会怀疑我的编码能力。如果你为某个较为流行的开源项目贡献了哪怕仅仅几千行代码，我想所有人都不会再问你年龄、学历、工作背景，因为那些都是多余。”

这也是他对于工程师唯一的要求，年龄这件事在 TDengine，从来都不是一件评判你技术好坏的标准。

公司简介：TDengine 是一款开源、云原生的时序数据库，专为物联网、工业互联网、金融、IT 运维监控等场景设计并优化。它能让大量设备、数据采集器每天产生的高达 TB 甚至 PB 级的数据得到高效实时的处理，对业务的运行状态进行实时的监测、预警，从大数据中挖掘出商业价值。

本文来源于开源集《开源观止》第 4 期，更多精彩内容，请下载：

https://oscimg.oschina.net/public_shard/opensource-guanzhi-.pdf

Rainbond创始人刘凡在公司成立前，可谓是不折不扣的技术男，一面是对技术的痴迷和钻研，一面是对社交的排斥和恐慌。

在公司的成立之初，刘凡以为招聘销售人员来做自己不擅长的事情，自己主要专注产品和技术就好。但半年下来，销售团队一单都没签下来，公司账面的现金已经花光。刘凡这才发现，原来要想公司发展壮大，光有好的产品还不够，还要有好的销售。而且Rainbond作为底层技术产品，销售必须要懂技术，才能推动商业落地。

面对企业的困境，刘凡不得不从后台走到前台直接面对客户。

最开始，刘凡宅公司，只跟客户远程干聊技术，虽聊得很嗨，但叫好不叫座。慢慢地，刘凡天天在外跑，把产品演示、价值传达、写解决方案、商务谈判这些售前和销售能力都逐渐补足，终于拿下多个大客户并成功交付。随着客户成功案例的积累，刘凡也对公司的发展有了新的认识——只有真正面对客户，才能了解客户的需求，才能做出更好的产品。

2017年底，“如何让更多人知道Rainbond”成为好雨科技的发展瓶颈。公司虽然知道开源是一条路，却总是担心开源和商业的冲突。不过，公司最终还是做出了一个重要决定，将产品完全开源。最开始，Rainbond 默默无闻，半年后，很多知名企业主动联系。随着落地的客户越来越多，产品营收也成倍增加，最初的顾虑完全消除，开源也成为驱动公司发展的主要动力。

公司及产品简介：

北京好雨科技有限公司成立于2015年，自成立以来始终致力于云原生应用转型改造和行业生态搭建，借助云原生，赋能ToB企业IT资产积累复用和业务持续交付，伟业数字化能力升级、ToB领域应用交付、搭建行业生态提供团建产品和技术服务。

好雨核心产品Rainbond于2017年开源，使用简单，不需要懂容器和Kubernetes，支持管理多个Kubernetes集群，提供企业级应用的全生命周期管理，功能包括应用开发环境、应用市场、微服务架构、应用持续交付、应用运维、应用级多云管理等。

本文来源于开源集《开源观止》第 4 期，更多精彩内容，请下载：

https://oscimg.oschina.net/public_shard/opensource-guanzhi-.pdf

Thief 是一款 AI 智能创新摸鱼神器，基于 Electron 框架开发，可以在 Win、Mac 双平台运行使用。这是为上班族打造的必备神器，释放工作中的压力，上班倍感轻松，远离 ICU。

推荐官：Thief 作者，神秘的摸鱼人，使用 N 年摸鱼神器的打工人。

推荐理由：使用了 Thief 后，即使在背后有许多人的注视的情况下，也可以极其隐蔽地进行摸鱼。比如说，Thief 的小说窗口以小型文本框的形式放在在屏幕不起眼的隐秘角落，因此你可以光明正大地阅读小说，不怕被人发现。甚至能用任务栏和 Touch Bar 来显示小说，工作和阅读两不误。

等背后没人的时候，你还可以愉快的玩单机游戏&网络游戏，实现带薪打游戏。又或者上班炒股(基金)，利用小窗口显示在屏幕预定位置，工作中随时观看行情走势，增加一份赚钱的副业。

Thief 还有超方便的 AI 识别技术，可设定摄像头识别功能，识别到身后角度有人出现就自动隐藏摸鱼窗口，再也不用担心被领导抓住了。更重要的是，通过 Thief 可以认识一群高学历的摸鱼小伙伴，微信群里个个都是人才，每天开开心心释放压力，快乐摸鱼。

项目介绍：https://www.oschina.net/p/thief

pache Kvrocks(incubating) 是一款高性能的分布式 KV 数据库，使用 RocksDB 作为底层存储引擎并兼容 Redis 协议，能够解决 Redis 内存成本高以及容量有限的问题，亦可作为PB级海量数据存储的解决方案。

推荐官：王源(ShooterIT): Apache Kvrocks PMC & Redis Group Member

推荐理由：

Apache Kvrocks(incubating) 兼容 Redis 协议，支持 String、List、Set、ZSet、Hash、BitMap、Geo、Stream等数据类型并实现了大多数命令，支持持久化 Lua 脚本、事务、PubSub 等高级特性，以方便业务开发；实现了基于 RSID(Replication Sequence ID) 的主从复制并支持 Redis Sentinel 的管理方案，轻松实现服务高可用；支持集群模式，最高可实现 PB 级别数据存储，采用中心化管理方案并完成兼容 Redis Cluster 访问协议，并提供了扩缩容功能，方便用户横向扩展。

Kvrocks 在百度、美图、携程、雪球等公司都大规模的应用实践，可应用于推荐系统、特征工程、物联网、游戏、电商、短视频等多个领域。

在成本方面，Kvrocks兼容 Redis 协议，但成本较纯内存版本的 Redis 可降低 80% 以上；其次，它使用 SSD 作为存储介质，相较内存，既保证了数据的持久化，也提升了系统的存储容量，可作为海量 KV 存储方案；最后，Kvrocks支持丰富的数据类型和命令，很好地实现业务表达和数据模型的映射，方便业务开发，也可满足其他 NoSQL 的需求。

未来，Kvrocks 会支持 JSON 数据类型以提升数据存储的灵活性，其次也会适配云基础设施满足大家云上部署的需求。社区正在开发管控服务来更好地管理 Kvrocks 集群，方便用户使用。

项目介绍：https://www.oschina.net/p/kvrocks

ShareX 是一款将截图、录屏、文件共享和 OCR 功能汇聚于一身的老牌 Windows 生产力工具，目前已有超过 14 年积极开发的历史。

推荐官：OSC 编辑部

推荐理由：

作为一款优秀的生产力工具，普通的全屏截图、区域截图、滚动截图、屏幕录制、屏幕录制 GIF 等功能自然是不用多说，截取时用户还可以根据需求设置窗口透明度、延迟时间、光标是否显示、定时自动重复截图等自定义选项。

正如软件名字 ShareX 所写，它的一大特点就是分享，ShareX 可以将截图内容自动上传到 Google Drive、OneDrive、Flickr和Google Photos 等 80 多种不同的图床或云存储平台；还可以立即在各大社交媒体上分享，分享后 ShareX 还能自动返回一个短链方便你使用。

对于 ShareX 来说，有两个功能是不能不提的，其中一个是自带的 OCR 工具，该工具支持中文识别，并且在近期更新中还对中文、日文、韩文语言进行了专门优化。

ShareX 的另一个功能则是有一套先进的快捷键 + 工作流程系统。在这套系统中，用户可以根据自己日常的工作流程单独定制一些快捷键，每一套快捷键都对应使用怎样的截图方式、截图后执行怎样的上传任务、截取的内容最终存储在什么目的地等。

用户可以从 ShareX 官网、项目 GitHub 页面和 Windows 系统中的 Microsoft Store 免费下载该软件。

项目介绍：https://www.oschina.net/p/sharex

Astro 是一款现代化的轻量级静态站点生成器，具有出众的开发者体验 (Developer Experience)。

推荐官：OSC编辑部

推荐理由：

虽然 Astro 从诞生到今天只有 16 个月，但其仓库的 star 数已超过 13000，并且在全球拥有超过 30000 名用户。目前，Astro 文档已被翻译成 6 种不同的语言 —— 包括中文。

Astro 其他特性：

自带组件框架：Astro 为 React、Vue、Svelte 和 Tailwind CSS 等前端工具提供一级支持。通过 astro add 命令即可添加使用。
支持静态页面生成 (SSG) 和服务器端渲染 (SSR)，可以按需渲染内容。
开发者体验出众：Astro 支持所有喜爱的开发者工具和功能，如 TypeScript、NPM 包、Scoped CSS、CSS Modules、Sass、Tailwind、Markdown、MDX。
按需组件：Astro 支持通过水化组件按需加载 JavaScript。因此，如果该特定组件不可见，它不会加载相关的 JavaScript。
100% 静态 HTML，无 JavaScript 运行时环境：当构建 Astro 时，它将删除所有 JavaScript，并将整个页面渲染为静态 HTML 页面。
SEO 友好：使用 Astro，可以启用自动网站地图、RSS 订阅、分页和收藏。
基于文件的路由：就像 Next.js 一样，Astro 有一个基于文件的路由机制，所有在 /pages 中的东西 Astro 都会将目录转化为路由。

Astro 采用了独特的 Island 组件架构，团队称这是一种用于构建更快网站的新型 Web 架构。

与单页应用程序不同，Astro 的组件不会被捆绑到一个 JavaScript 包中。相反，每个组件都被视为一个独立的小型应用程序，与所有其他组件隔离存在。

Astro 从首次推出到最近发布 1.0 正式版，已经发生了许多变化。它不仅仅只是静态站点生成器，开发者可以在任何流行的托管平台上将 Astro 构建为动态的、支持 SSR 的服务器。

项目介绍：https://www.oschina.net/p/astro-build

开发人员与运维人员是 IT 领域很重要的两大人群，他们都会参与到各种业务系统的建设过程中去。DevOps 是近年间火爆起来的一种新理念，这种理念被很多人错误的解读为“由开发人员（Dev）学习一大堆新的技能，从而掌握运维人员（Ops）该处理的事情”。然而能力越大，责任越大，当维持生产环境稳定为要位的运维责任落到开发人员的肩头时，多数程序员发出了扯淡的DevOps，我们开发者根本不想做运维! 的呼喊。那么在云原生时代，到底应该怎样达成 DevOps 的体验呢？我的观点是由平台工程来衔接这两大人群，各自做好各自领域的事情。

令人“厌恶”的DevOps

首先，我非常希望你能先看一看引言中提到的扯淡的DevOps，我们开发者根本不想做运维! 这篇文章。这篇文章从亚马逊云科技社区参与负责人 Emily Freeman 的一条推特入手，观察了很多留言后，得出了文章标题这种类似咆哮一般的结论。从绝大多数回复这条推特的 IT 从业者的口中，我听到了对于将运维职责强加给开发人员这种 DevOps 体验深恶痛绝。

开发人员对于 “谁构建，谁运行” 这种大义凛然的话表示无感，对于学习运维领域的新技能，亦或是将自己加入轮班支持人员的行列都感觉力不从心；运维人员的本职工作被剥离之后，则对本专业的前景惶惶不安，会害怕运维团队的重新洗牌。

开发与运维，的的确确是两个不同的工种，有着类似“车床工与管道工”的区别。

开发人员运维人员专业技能开发语言、开发框架、中间件、数据库硬件、操作系统、网络、存储、虚拟化日常工作理解需求、开发文档写作、开发代码安装部署、监控、日志、问题排查、变更文化标签自由、创造保守、责任

一些公司认为从表格中把大量的运维人员管辖的工作，一股脑的“左移”给开发人员就是 DevOps。在专业技能和日常工作领域带来的缺口，可以通过开发人员的勤劳学习加以补足，然而在文化标签领域的冲突，将会是导致开发人员厌恶这种 DevOps 体验的根本原因。

DevOps 的真意与平台工程

在我看来，DevOps 的真意是利用软件工程思维，解决复杂且繁重的运维问题。真正适合做 DevOps 工作的人，是具备一定软件工程能力的运维专家，在这里，对运维能力的要求更重要。

DevOps 工程师，可以通过设计或选择一款平台产品，来将复杂的运维工作抽象为产品化的运维特征。从这个角度上讲，开发人员将会是这个平台产品的用户，他们能够在不了解复杂基础设施的情况下，操作并维护应用程序。DevOps 工程师，应该是更懂开发人员需求的运维工程师。

在追根溯源，找到了这条推特之后，我了解到了更多 IT 业内人士对 DevOps 的看法，从中找到了很多和我有共鸣的声音。

To me that’s a sign we haven’t made ops intuitive/easy enough for most devs to be able to handle it.

对我来说，这表明我们还没有让运维变得足够直观/简单，以至于大多数开发人员都无法处理它。

—— @Liz Fong-Jones (方禮真)

The “platform” should do the heavy lifting ops, lacking a real platform the ops team (DevOps/are/platform team) is the platform. Devs can then focus on the application level operations of their apps using the knobs and levers provided by the platform.

“平台”应该做繁重的运维，缺乏真正的平台时运维团队就是平台（DevOps/are/platform team）。然后，开发人员可以使用平台提供的旋钮和杠杆专注于其应用程序的应用程序级操作。

—— @pczarkowski

IT 行业近年来的发展趋势，一直是不断以平台能力的提升，来解决复杂基础设施的使用问题的。最开始，程序开发人员需要面对的是一台物理服务器，在缺乏运维能力的情况下，会由运维人员处理有关服务器的一切，包括操作系统、网络配置等等。而到现在，程序开发人员已经很少需要跟服务器打交道，甚至我见过的很多程序员并不掌握任何有关命令行的知识，就可以面向服务器开发应用系统。这种转变让程序开发人员更加专注于业务代码本身，不必分神去做一些繁重且琐碎的运维事务。带来这种转变的，是处于发展过程中的平台工程，在让基础设施不断变得简单易用。

最原始的裸机时代，并没有开发运维之分。从底层基础设施，一直到最顶层的业务系统都是同一批人在处理，这一批老程序员可以被称为真正的全栈工程师。但毫无疑问，每一个开发人员，都希望能够抛却运维工作，更专注于自己开发的代码。

云计算时代的兴起以虚拟化技术为基础，软件定义基础设施变得炙手可热起来。运维人员通过建设并维护一套 IaaS 云平台，将计算资源进行池化。开发人员按需申请自己需要的虚拟机，从而得到一个操作系统界面来进行交互。与操作系统打交道，对开发人员依然是个巨大的挑战，在 IT 领域，操作系统就像一座漂浮在海上的冰山，看似只露出冰山一角，然而其庞大的知识领域“身躯”都隐藏在海平面以下。和裸机时代相比较，开发人员和运维人员已经是两个完全不同的群体，开发人员已经可以将自己的大部分精力放在业务系统上了。值得一提的是，对操作系统的掌控是不折不扣的运维领域技能。

容器技术以及 Kuberentes 的横空出世，成为了云计算时代的分水岭。软件定义基础设施的技术手段已经被发挥到了极致，并且成为了现阶段运维人员的标配技能。运维人员通过建设并维护一套 PaaS 云平台，终于将操作系统这一座最后的“大山”从开发人员的身上搬开。开发人员可以将更多的精力放在业务系统上了，除了他们依然需要学习容器技术和 Kubernetes ，至少他们要学会如何面向 Kubernetes 编写业务系统所需的声明式配置文件。运维人员也通过 PaaS 云平台得到了自己想要的能力，容器技术和 Kubernetes 为他们带来了弹性、便捷性的巨大提升。

跟随时代的变迁，我得出了一个结论：从开发人员与运维人员的关系上来看，IT 领域的演变，就是运维人员通过不断向上接手开发人员眼中“跟开发无关的杂活”，来不断为开发人员减负。开发人员在得到了解放后，可以将视角更多的聚焦在自己开发的业务系统上，释放出自己的创造力。

那么跟随结论中的趋势，解放开发人员负担的脚步绝对不会停止。DevOps 的工作，就是以开发人员为用户群体，打造一套可以让开发人员毫无障碍的使用基础设施的“云原生平台“。

云原生是一种面向云设计应用的思想理念，充分发挥云效能，组织内 IT 人员相互协作构建弹性可靠、松耦合、易管理、可观测的云应用系统，最终目标是提升软件交付效率，降低运维复杂度。相比上文中提到的 PaaS 平台，起码要能够避免开发人员去编写复杂的 Kubernetes 声明式配置文件。

现有开源产品情况

在云原生平台领域，已经有不少项目在深耕。在这里我列举了三个各具特色的云原生领域的平台级产品：Rancher、KubeSphere、Rainbond ，后续的具体设计思路中，也会关注已有产品的实现。

这三款开源产品中，Rancher 是祖级容器管理平台，加入 SUSE 后，能够明显感觉在云原生生态领域不断发力，Rancher 在各个层次可以集成的云原生领域工具集已经非常丰富。Rancher 专注于帮助 DevOps 团队面对多集群情况下的运维和安全挑战，从这一点来说，Rancher 更偏向于运维人员的使用体验，而非面向开发人员提供更高的易用性。

KubeSphere 是来自青云的 “面向云原生应用的容器混合云”。除了对 Kubernetes 集群内的各种资源的管理能力之外，Kubesphere 主打即插即用的插件式生态扩展能力。

Rainbond 由北京好雨科技出品，从其介绍来看，它是一款主打易用性的云原生多云管理平台。

降低业务部署难度

诚实地讲，为现代开发语言开发而来的业务系统制作容器镜像并不是什么难以掌握的技能。但是不可否认的是，绝大多数 IT 从业人员依然会将制作镜像这件事情归为运维人员管理，而不是开发人员要关心的事情。

那么 DevOps 工程师就有必要考虑，如何在开发人员对容器技术一无所知的情况下，使之可以直接从代码开始部署业务系统。

在这个方面，Heroku 是无可争议的先行者。Heroku 是一个支持多种编程语言的云平台即服务产品。在2010年被 Salesforce.com 收购。 Heroku 作为最祖的云平台之一，从2007年6月起开发，当时它仅支持 Ruby，但后来增加了对 Java、Node.js、Scala、Clojure、Python 以及 PHP 和 Perl 的支持。

开发人员在使用云原生平台时，只需要在界面中填写代码仓库的地址，对应的用户名密码等基础信息，就可以等待代码构建成为镜像，并自由的运行在 Kubernetes 云环境中去。

现有开源产品也在这方面给予了一定的支持：

Rancher KubeSphere Rainbond 实现方式通过集成 Epinio 项目，继而深入集成了Paketo Buildpacks 来实现源码构建提供定制化的基础镜像来结合用户代码构建项目基于 Heroku buildpack 定制的源码构建能力支持语言类型 Java、GraalVM、Golang、.NetCore、Nodejs、PHP、Ruby、Python Java、Nodejs、Python Java、Golang、.NetCore、Nodejs、PHP、Python、Html静态使用体验全部命令行操作，使用复杂图形化操作，直接提供代码地址，构建产出镜像，进而部署业务图形化操作，提供代码地址即可完成构建与部署，构建参数可配置，自由度高

更进一步的设计，是将代码的提交、检测、部署等流程都集成到 CI/CD 流水线中去，开发人员只需要进行代码的提交，后续的流程会自动触发完成，生成检测报告，并完成代码的上线部署。而与之相关的第三方工具集，由 DevOps 团队负责进行维护，开发人员可以充分的发扬拿来主义——拿来用就好。

在这方面 KubeSphere 做的更加全面，通过集成 Jenkins 实现了基于图形化的流水线配置，这种方式对于以前就在使用 Jenkins 的团队很友好。并且这种实现继承了 Jenkins 生态原有的高自由度，可以更好的将其他第三方CI工具纳入流程之中。

Rainbond 通过在构建流程中加入自制的自动触发能力，也可以完成部分流水线工作。这种配置相对编写 Jenkinsfile 来说更简单一些，能够满足一些基本场景。然而其扩展性和自由度不足，能够接纳的第三方CI工具不够丰富。

Rancher 并没有在产品中集成 CI 方面的能力，在 CD 方面通过集成 fleet 项目来实现 GitOps ，使用的门槛较高。

这样的使用体验还有一个优点，从始至终都不需要开发人员去编写格式严苛的 Kubernetes 声明式配置文件。这对开发人员而言无疑是一个极大的利好，Kubernetes 虽好，但学习曲线非常陡峭。Kubernetes 默认通过 yaml 格式的声明式配置文件来部署业务系统，其中绝大多数的字段定义都是运维特征的体现，换句话说，绝大多数的字段定义，都不应该是开发人员关注的事情。

DevOps 工程师应该抓住开发人员使用 Kubernetes 的痛点，避免其接触复杂运维事务。云原生平台理应提供这种使用体验，让开发人员对 Kubernetes 完全无感知的情况下，完成业务系统的部署工作。换句话说，让 Kubernetes 变得对开发人员“透明”。

从这个方面来说，通过对三款开源云原生平台的体验，发现 Rancher 和 KubeSphere 虽说均可以基于图形化界面来部署自己的业务组件，然而这些图形化配置只是 yaml 声明式配置文件的 “翻译”，对于 Kubernetes 不够熟悉的用户想要顺利使用，还是有一定的门槛。Rainbond 这一点则做的非常不错，部署业务时完全感受不到 Kubernetes 的存在，对于不熟悉 Kubernetes 的用户而言非常友好。然而产品化定制的程度越高，跟随 Kubernetes 前进的脚步就越难，上游 Kubernetes 不断在推出新的功能特性，如何将新特性抽象成为用户易于理解的功能将会是个挑战。最新版本的 Rainbond 推出了 Kubernetes 属性这一功能特性，允许用户以 yaml 形式编辑 workload ，也是为打破自设的“天花板”。

降低操作基础设施的难度

既然要设计一款平台级的软件产品，那么就需要将复杂且不易被掌握的技术，抽象成为用户易于理解的功能。DevOps 工程师设计的云原生平台产品，首要任务之一，是能够降低开发人员使用基础设施的门槛。这个章节主要讨论的，是开发人员自行管理自己业务系统的运维特征。

就拿存储这件事来说，开发人员到底关注什么呢？

围绕存储这个概念，我们可以说出一堆名词，块设备、文件系统、对象存储、本地磁盘、磁盘阵列、NFS、Ceph等等。这些名词毋庸置疑都与存储相关，也的确会被各种业务系统所使用，但我相信，绝大多数的开发人员对这些名词并不关心。

作为用户，开发人员只关心一件事情，我所负责的业务系统，指定目录中的数据需要被持久化的保存下来。

大多数情况下，业务系统涉及到的存储场景都应该是简单的。在云原生时代，我们甚至呼吁开发人员在开发业务系统的时候，应该尽量做到“无状态化”，即在业务系统中，不存在限制实例横向扩容的状态数据，至少做到不同实例之间，数据可以共享。根据这一点，DevOps 工程师们完全可以为开发人员提供一个能够适应大多数场景的默认存储类型，各个云厂商提供的 NAS 类型存储是个很好的选择。

使用复杂存储的场景更多见于业务系统所调用的各种中间件中，比如数据库需要高速稳定的块设备类型存储，再比如大数据领域的“存算分离”场景下对接对象存储等等。然而在大多数场景下，这些复杂中间件的维护并不是开发人员应该关心的事情。它们由专门的运维人员进行维护，开发人员只需要得到访问它们的地址即可。

所以在这种简单存储场景下，开发人员最好可以仅仅填写一下自己需要被持久化的目录地址，由云原生平台来实现底层存储的配置。对存储基础设施的操作，开发人员并不需要关心。

从使用体验上来说，Rancher 和 KubeSphere 可选择的存储类型很多，这是因为它们的产品生态优于 Rainbond ，比如 Rancher Lab 直接推出了轻量级的存储解决方案 Longhorn，对于各大公有云厂商提供的存储产品驱动也都有集成。 Rainbond 依然在易用性方面做的够好，实现了上文中仅关注业务系统持久化目录的使用体验。然而仅对 NFS 类型的存储支持比较完善，对于其他类型的存储支持，需要在底层基础设施中自建驱动，安装起来不如前二者方便。

易于理解的应用模型

从工作负载层面上讲，Kubernetes 只通过 Deployment、Statefulset 等抽象描述单个组件的特征，然而多数情况下，开发人员开发出的业务系统会包含若干微服务组件。那么如何对整个业务系统进行统一的管理就变成了一个问题。解决方案之一，就是通过云原生应用平台，在单个组件之上，抽象出应用这个概念。应用应该是由人为规定的一组服务组件（workload）组成，服务组件之间具有显式或隐式的关联调用关系，彼此之间有机组合成为一个整体，作为一套完整的业务系统对外提供服务。

开发人员可以将所有的服务组件视作一个整体来进行管理，而非机械的单独管理每一个服务组件，这种操作体验无疑会更简单，也便于开发人员理解。对应用的管理可以包括统一的生命周期管理、统一的安装升级卸载，灵活拼装服务组件之间的调用关系，更合理的处理业务系统的交付流程。

目前 Kubernetes 领域内较为成熟的交付工具 Helm ，其设计也暗合此类模型，一条简单的命令，即可安装起一大堆组件以及围绕这些组件的配置。

Rancher 并没有实现自己的应用模型，其应用的安装方式集成了 Helm ，并没有体现出应用管理能力。

KubeSphere 则更进一步，在项目下的应用负载中提出了应用的概念。在应用中可以通过 Helm 或自建的形式部署服务，集成了微服务治理、单个组件的版本控制、路由管理、灰度发布等能力。其对 Helm 模板的支持，使得其从理论上可以支持任何市面上已有的 Helm Chart 包的安装部署。

Rainbond 的应用概念是最完善的，除了常规的生命周期操作、整个应用级的版本控制这样的常规能力之外，还有些非常易用的自研功能，能够简化开发人员对自己应用的管理。比如基于泛解析域名机制实现的对外服务域名，开启对外服务，就会生成一个公网可用的域名访问自己的应用，这比一层一层的配置 Ingress 规则容易太多。又比如应用复制能力，可以批量的将整套应用复制到另一个工作空间，而不必重新手动搭一套。

应用模板是 KubeSphere 和 Rainbond 均提出的一个概念，应用模板存在的意义是可以将开发好的应用复制到不同的环境中去，是一种制备新一代制品并交付分发的技术。应用模板的基础使用体验，是可以快速方便的安装整套应用系统，最好是一键化的体验，KubeSphere 和 Rainbond 都提供了应用商店，供用户快速安装一些已经制作好的应用模板。应用模板更高层次的使用体验，则是开发人员可以无任何技术负担的开发出自己的应用模板，而不仅仅是从应用商店拉取别人制作好的应用模板。

易于掌控的微服务架构

微服务架构也是云原生平台不可缺少的一个素。微服务架构旨在帮助开发人员建设高类聚、低耦合的现代应用系统，将以往烟囱式的业务系统架构，拆散成为一大堆彼此间更为独立，包含自身功能特点的微服务模块。容器与相关编排技术的成熟，为微服务架构的落地打下了基础。云原生应用平台，则为开发人员更简单的入手微服务框架提供了可能。

云原生平台首选的微服务框架，应该是以 Istio、Linkerd 为代表的 Service Mesh 微服务框架，也被称为“服务网格”。相对于 Spring Cloud 、 Dubbo ，这种微服务框架提供了更高的自由度和适应性，开发人员不需要被某种开发语言或产品绑定，只需要回归网络编程即可将自己的业务系统连接成为一个整体。这里要重点提出的是微服务架构对业务代码无侵入，只有无侵入的实现，才能最大限度降低开发人员花费精力学习其他领域知识的可能性。

DevOps 工程师可以通过设计云原生平台功能来进一步优化配置微服务的使用体验，大胆设想一下，开发人员只需要在两个服务组件之间拖动一条表征微服务调用关系的线，就可以生成对应的微服务配置。这样的操作体验完全可以使注册中心、控制平面这种微服务领域中复杂的概念对开发人员屏蔽。本质上讲，维护注册中心或者控制平面也是运维人员需要关心的工作。

Rancher 由于其自身的定位，产品中没有集成任何微服务相关的能力，用户需要手动安装 Istio 等微服务框架，通过复杂的 yaml 配置，来引用微服务能力。

KubeSphere 和 Rainbond 都在应用层面默认集成了 Service Mesh 微服务框架，不同之处是前者集成了 Istio 方案，而后者的 Service Mesh 微服务框架是自研的。从使用体验上来说， KubeSphere 产品化的包装了 Istio，大幅度降低了 Istio 的使用体验，但这不意味着用户可以完全抛却 Istio 这一层的概念，应用内部的拓扑依靠事先的配置来体现。Rainbond 自研的微服务框架易用性更高一些，已经实现了拖拉拽式的微服务拼装模式，这一点还是很惊艳的。然而自己造的轮子过多，外部的其他方案有好的特性时想要快速集成接纳，就需要在微服务规范的对接层次更上层楼，毕竟 Istio、Linkerd 这些 Service Mesh 微服务框架一统江湖的情况下，其他生态的结合都会以它们为标准，而非自研框架。目前 Rainbond 也提供集成方式接纳了 Istio 治理模式，但还没有得到大量用户的使用验证。

对运维人员友好

之前的探讨，都是以开发人员为受众去考量的，但我们不应该忘记维护着底层基础设施正常工作的运维人员。任何软件的稳定运行都只是暂时的，出问题只是一个时间问题。云原生平台本身作为开发人员的基础设施，也需要被持续的维护。如何优化运维人员的管理体验，也是在云原生平台设计过程中的重点。

当今时代，Kubernetes 的使用与维护、容器化技术都已经成为了运维人员的标志性技能，对操作系统的掌控以及命令行工具的使用则是运维人员的看家本领。所以云原生平台在面向运维人员的设计中，不必要在易用性或图形化上考虑过多，更多要考虑的是可靠性、安全性、底层基础设施生态的兼容性。

Rancher 在运维层面的表现非常出众。得益于其丰富的周边生态，Rancher 在各个领域都得到了自家其他产品的原生支持。首当其冲的就是 RKE/RKE2/K3S 这几个 kubernetes 发行版，降低了不同场景下 Kubernetes 的安装难度。容器安全方面有 NeuVector 容器安全平台负责全生命周期的管理。基础设施方面有轻量级分布式块设备存储系统 Longhorn。除了丰富的生态之外，Rancher 产品界面的设计尤其符合运维人员的喜好。个人体验过程中认为 Kubectl Shell 非常惊艳，这是一个分屏式的命令行操作界面，运维人员可以一边在下半分屏 Shell 交互分页中敲命令，上半分屏中实时观察操作结果。

KubeSphere 也比较适合运维人员维护和管理。尤其是在监控报警层面，KubeSphere 制作了大量符合自身产品理念的可观测性图表，体验很不错。对于集群或节点的控制也做了图形化的设计，便于运维人员掌控。生态方面，KubeSphere 背靠青云，也在不断发展围绕自身的云原生项目，可以利用自家的驱动对接青云的云平台、云存储，以及负载均衡等基础设施。其内置的可插拔式的组件管理系统，可以快速扩展出平台级的其他能力。

Rainbond 对运维人员不太友好，甚至是一种“遗忘”了运维人员的设计理念。体验之后发现所有的运维操作依然离不开登录服务器这个前提。没有提供图形化亦或者命令行交互界面来操作集群和节点。对接多集群时，提供了图形化安装 Kubernetes 集群继而安装 Rainbond 的能力，体验还算不错。产品生态相较 Rancher 不够丰富，好在官方提供了很多文档支撑，来对接很多其他的云原生生态产品。比如提供文档对接阿里云ACK、华为云CCE、腾讯云TKE等云基础设施的安装方式。

在用户权限管理方面，Rancher 、KubeSphere 沿用了 Kubernetes RBAC 这一套体系，Rainbond 依然有些特立独行，权限管理体系并没有完全对照原生 Kubernetes RBAC 设计，甚至在使用 Rainbond 的时候，完全没有感觉到有 RBAC 体系的存在。对接外部的身份管理系统时，KubeSphere 主推 LDAP 协议，而 Rainbond 使用了 Oauth2.0 协议的实现。

其他方面，诸如稳定性、行为审计、监控报警方面三款产品各自有实现，没什么太大的区别。

写在最后

相对于招聘文武全才的“全栈式”开发人员搞定所有的 IT 事务，我更倾向于找到不同领域的专家来搞定各自领域的问题。在运维事务的领域里，构建并维护一套功能齐备的云原生平台，能够更好的解决 IT 业务系统从底层基础设施到开发过程，最终到达生产上线的运维支持问题。这是对 DevOps 理念比较合理的一种落地方式。

文中重点提到了 Rancher 、KubeSphere、Rainbond 这三款云原生平台级产品各自不同的实现。

归纳起来，Rancher 更偏向运维人员使用，来管理企业内部的各类 Kubernetes 基础设施。开发人员想要很好的使用 Rancher ，必须具备 Kubernetes 操作能力以及容器化技术。从这个角度来说，Rancher 的定位应该位于 PaaS 与云原生平台之间。

KubeSphere 和 Rainbond 都属于以应用为中心的云原生平台产品，二者的设计思路不同之处见仁见智。 KubeSphere 以可插拔式框架纳入了云原生领域的其他项目为己所用，将这些项目的能力串联起来为最终用户提供一站式的使用体验，然而这样的使用体验必然是有门槛的，每纳入一个项目，最终用户难免需要同时学习该项目和 KubeSphere 自身。Rainbond 的设计思路则更加的内聚，多数功能都自研。这样做的好处是功能体系高度自我契合，最终用户的使用体验非常好，功能之间衔接关联更符合人类思维，却容易自我限定，提高了纳入其他云原生生态的门槛。

DevOps 团队可以直接选择既有的云原生平台级产品使用，也可以基于开源项目二次开发。更落地的方式是选择其中多款进行混合部署，各取所长，以提到的三款产品为例，DevOps 团队完全可以选择 Rancher + KubeSphere 或 Rancher + Rainbond 的组合，它们之间并没有冲突，向下对接基础设施，管理集群的安全性与合规性是 Rancher 最擅长的事情，向上为最终开发人员提高易用的云原生平台的使用体验则交给 KubeSphere 或 Rainbond，最终的目标，是开发人员通过云原生平台的支持，从以往的运维工作之中解放出来，将精力更多的放在所开发的业务之上。

最近因为工作需要，需要找一个功能完善的云原生应用平台，经过自己筛选和朋友推荐，剩下 KubeSphere和Rainbond ，这两个产品都是基于 Kubernetes 之上构建的云原生应用平台，功能都非常强大，但产品定位和功能侧重不同，本文将介绍我在选型过程中从各维度对比两款产品的过程记录。

产品定位对比

KubeSphere 是在 Kubernetes 之上构建的面向云原生应用的分布式操作系统，完全开源，支持多云与多集群管理，提供全栈的 IT 自动化运维能力，简化企业的 DevOps 工作流。作为全栈的多租户容器平台，KubeSphere 提供了运维友好的向导式操作界面，帮助企业快速构建一个强大和功能丰富的容器云平台。KubeSphere 为用户提供构建企业级 Kubernetes 环境所需的多项功能，例如多云与多集群管理、Kubernetes 资源管理、DevOps、应用生命周期管理、微服务治理（服务网格）、日志查询与收集、服务与网络、多租户管理、监控告警、事件与审计查询、存储管理、访问权限控制、GPU 支持、网络策略、镜像仓库管理以及安全管理等。

Rainbond 是一个云原生应用管理平台，使用简单，不需要懂容器、Kubernetes和底层复杂技术，支持管理多个Kubernetes集群，和管理企业应用全生命周期。主要功能包括应用开发环境、应用市场、微服务架构、应用交付、应用运维、应用级多云管理等。Rainbond 遵循以应用为中心的设计理念，统一封装容器、Kubernetes和底层基础设施相关技术，让使用者专注于业务本身, 避免在业务以外技术上花费大量学习和管理精力。

KubeSphere Rainbond Slogan 面向云原生应用的混合云平台云原生多云应用管理平台抽象容器和K8s概念和抽象为主，应用级抽象为辅应用级抽象定位面向懂K8s相关技术的运维和开发面向所有运维和开发，平台管理需要懂K8s

由于产品抽象不同，表现出来的概念和流程也有很大差异，KubeSphere主要是Kubernetes相关概念和抽象，使用和管理都需要懂Kubernetes相关体系知识，懂Kubernetes的人能快速上手，Rainbond应用级抽象，使用门槛很低，面向不懂Kubernetes的普通开发人员，平台管理跟KubeSphere一样都需要懂Kubernetes。

开源社区活跃度对比

KubeSphere Rainbond 社区活跃度论坛、微信群都活跃微信钉钉活跃 Stars 11003 3451 文档成熟度很全面很全面版本迭代近一年迭代了4个版本近一年迭代了8个版本开源 100% 开源 100% 开源

KubeSphere 社区更加活跃些，毕竟是万星开源项目，用户遍布国内外。Rainbond 社区用户基本都是国内用户，Star上差了些不过Github、社区群也蛮活跃的。

安装体验对比

KubeSphere

支持通过一条命令在 Linux 上快速安装 KubeSphere。

Rainbond

支持通过一条命令在 Mac、Win、Linux 上快速安装 Rainbond。

KubeSphere Rainbond Docker Desktop and ARM 不支持支持 Linux 支持支持 Kubernetes 支持支持公有云、托管Kubernetes 支持支持安装后组件数量启动所有可拔插组件后 Pod 大概 55 个左右大概 15 个 Pod

KubeSphere和Rainbond安装都很简单。 KubeSphere 自研的 KubeKey 安装工具，在服务上安装 K8s 和 KubeSphere 很方便。KubeSphere 的可拔插组件这个设计还蛮好的，Allinone安装之后有 5 个 Pod 左右，能满足基本运行需求，需要其他功能就通过可拔插开启，开启所有组件后 Pod 大概 60 个左右。Rainbond 能支持在 Mac M1 Docker Desktop 上安装，这个安装体验还蛮好的可以在本地开发，Rainbond 启动后 Pod 大概15个左右，内存占用1G 左右。

应用部署功能对比

KubeSphere

KubeSphere对接git仓库部署源码，支持 Source-to-Image (S2I) 标准工作流将源码打包成镜像，并部署在 Kubernetes 集群中。支持 Java、Python、Node，其他语言可通过自定义 S2I 实现源码构建。

KubeSphere采用 Binary-to-Image (B2I) 标准工作流将二进制打包成镜像，并部署在 Kubernetes 集群中。支持通过 Jar、War、二进制

KubeSphere 支持自定义持续构建的流水线

Rainbond

Rainbond支持对接和整合 Gitlab、Github、Gitee、SVN，实现统一入口

Rainbond 的构建支持自动识别源代码类型，支持自动识别 Java Maven、Java Gradle、Java Jar、Java War、Python、PHP、.NetCore、Golang、NodeJS、Static HTML。

每种识别的开发语言支持设置环境相关信息，并自动构建成容器镜像。

KubeSphere Rainbond 源码部署支持 Java、Python、Node 支持自动识别 Java Maven、Java Gradle、Java Jar、Java War、Python、PHP、.NetCore、Golang、NodeJS、Static HTML 二进制部署 Jar、War Jar、War 容器镜像支持容器镜像部署支持容器镜像、docker run、docker compose部署 Kubernetes 应用 Yaml、Helm Yaml、Helm 持续交付支持GitOps和自定义流水线步骤支持GitOps

KubeSphere 兼容Kubernetes体系，应用部署使用S2I和B2I，KubeSphere自定义流水线功能非常强大，配置灵活。Rainbond 应用部署不需要懂容器和Kubernetes，支持常见的源代码，并自动识别和构建，使用非常简单。

微服务架构功能对比

KubeSphere

KubeSphere的微服务架构基于 Istio 实现，支持微服务的流量可视化管理。

基于Jaeger的调用链分析

Rainbond

Rainbond的微服务架构拓扑和服务编排，通过图形化的编排，添加组件之间的依赖关系，添加后也会注入服务之间的连接信息等。拓扑图可以展示服务之间的关系，用颜色区分服务的状态等。

微服务实时性能分析

KubeSphere Rainbond 服务网格支持 Istio 内置、Istio、Linkerd 服务拓扑图流量拓扑图微服务依赖关系和服务状态展示服务治理熔断、限流插件实现熔断断路器和限流微服务可观测性调用链分析通过插件扩展非常多可观测性：性能分析、pinpoint、skywalking、Jaeger等微服务编排代码编排 “拖拉拽”的形式编排微服务依赖关系

KubeSphere 完全依赖 Istio 实现微服务架构，对Istio的功能支持非常完整，KubeSphere弥补了Istio没有图形化的控制面板的不足，简化了 Istio 的上手难度，服务之间的拓扑图是根据流量走向自动生成的，可以直观的看到服务间流量。

Rainbond 的服务网格、服务治理、可观测性都是通过插件体系支持的，传统应用开启服务网格插件，马上就能支持微服务架构，服务治理和可观测性也只需要开启相应插件，Rainbond内置了很多插件，有需要还可以自行扩展，可以将自己趁手的工具添加进来，另外，图形化手动编排服务是个特色，不用改代码就可以动态调整依赖关系。

应用市场功能对比

KubeSphere

内置应用商店有 30 个应用可直接安装。

基于 Helm Chart 创建应用模板。

发布 Helm Chart 应用模板。

Rainbond

内置应用商店有 90+ 应用可直接安装。

支持用户将已经部署好的应用一键发布至应用市场，无需编写复杂的YAML。可以一键发布应用模型内所有数据，例如依赖关系、配置文件、存储信息等。

支持应用离线导出导入，支持导出 Rainbond App 应用包、Docker Compose 应用包、非容器环境应用包。

支持基于 Rainbond 应用市场一键安装和一键升级，升级会包含应用模型内所有数据，包括依赖关系等。

KubeSphere Rainbond 应用模板 Helm Rainbond 应用模版、Helm 应用发布上传 Helm Chart 一键发布到应用市场应用安装一键安装一键安装应用升级整体升级部分升级或整体升级离线导入导出不支持离线导出多种格式包内置应用 30 可用应用 90+ 可用应用

在应用市场这块Rainbond的功能比KubeSphere强大很多，易用性也好很多。KubeSphere 在应用市场这块是基于标准的 Helm 实现的，在应用发布、安装、升级这套流程里是按照标准的 Helm 应用规范实现，制作 Helm Chart 门槛比较高，功能也受限于Helm。Rainbond 的应用市场定义了自己的应用模型规范，也支持Helm Chart转成Rainbond的应用模型，应用发布支持一键发布由几十个服务组成的应用，无需编写复杂的YAML，离线导出是在企业软件交付场景非常实用的功能。

Kubenetes 多集群管理功能对比

KubeSphere

KubeSphere支持对接多个 K8s 集群，支持各种云厂商托管 K8s 集群以及私有云、混合云等。借助 KubeSphere的图形化 Web 控制台，用户可以管理底层的基础架构，例如添加或删除集群。可以使用相同的方式管理部署在任何基础架构上的异构集群。支持跨集群应用分发，资源整合等。支持通过图形化界面管理节点，监控集群状态、应用资源监控、集群告警和通知等。

集群监控

Rainbond

支持对接多个 K8s 集群，支持各种云厂商托管 K8s 集群以及私有云、混合云等。支持用户通过控制台添加或删除集群，支持跨集群应用分发。

通过grafana扩展的集群和节点监控

KubeSphere Rainbond 多集群管理支持对接多个 K8s 集群支持对接多个 K8s 集群集群管理存储管理、节点管理命令行管理集群监控和可视化丰富的监控通过grafana扩展的监控多租户从平台角色、企业空间角色、项目角色三个维度定义多租户<br />支持企业空间、项目进行资源限额，支持多租户的逻辑隔离、网络隔离从企业角色、团队角色两个维度定义多租户<br />支持对团队的资源限额，支持多租户的逻辑隔离

KubeSphere 在多集群管理这块比Rainbond体验好，有丰富的监控和可观测性，管理存储和节点在控制台全部完成，Rainbond在集群管理这块需要在命令行下管理，监控功能也弱一些。

应用运维功能对比

基本管理

KubeSphere

支持对工作负载、容器组级别的管理，支持工作负载的YAML编辑、版本回滚、删除、重新创建等。

支持对容器级别的日志查询过滤，支持全局的日志查询过滤。

KubeSphere 采用 Kubernetes 原生模式进行应用访问，可通过 NodePort、LoadBalancer、Ingress实现外部访问。支持扩展第三方负载均衡控制器以及 Ingress 控制器

Rainbond

支持对应用、组件级别的管理，支持应用批量启动、重启、更新、关闭、删除以及组件的操作，支持应用和组件级别的环境变量、版本回滚等。

组件日志实时查看和筛选

Rainbond采用统一的应用网关，支持配置HTTP路由规则和HTTPS证书

由 Rainbond Gateway 统一封装访问，支持http、tcp、udp、grpc访问组件。

KubeSphere Rainbond 基本管理支持对工作负载级别的管理支持对应用、组件级别的管理日志支持容器组日志查询过滤和全局日志查询过滤支持组件日志查询过滤监控支持工作负载级别的告警以及自定义监控图支持组件级别的监控以及图表，告警可扩展伸缩支持手工和自动支持手工和自动网关支持 NodePort、LoadBalancer 和 Nginx Ingress 由 Rainbond Gateway 统一封装访问，支持http、tcp、udp、grpc

对于基本管理来说 KubeSphere 是原生 K8s 的一些管理，比如删除Pod、编辑YAML、配置环境、自定伸缩等，同样 Rainbond 展现的是应用级概念，比如：在K8s里没有关闭的概念，而在Rainbond里应用不用了直接关闭，想用了再启动，Rainbond做了很多应用级的概念转化，对于不动K8s的开发人员更加容易接受。

KubeSphere 在网关这块同样也是遵循了 K8s 原生的模式，通过 NodePort、LoadBalancer、Ingress实现外部访问，并通过图形化操作简化了 YAML 的操作，优点是可以扩展更多第三方 Ingress 控制器，例如 Traefik 等。Rainbond 网关则是通过 Rainbond Gateway 统一封装实现外部访问，简化了用户的操作，一键开启外部访问，同时也能配置 HTTP 的路由规则等，使用的体验非常好。

总结

总体来说，KubeSphere和Rainbond都很成熟，也都有大量开源使用用户，只是定位不同，所以适用场景也会不同。

KubeSphere 在兼容Kubernetes生态方面做的非常好，包装和整合了很多云原生的工具，并扩展了对Kubernetes和开源工具的管理能力，对于想要管理Kubernetes集群的系统管理员是个好的工具，熟悉Kubernetes的工程师也可以自行扩展KubeSphere的能力。但对开发人员来开发和管理应用来说，门槛比较高，需要学习和理解的概念非常多。

Rainbond 屏蔽了底层复杂的技术，基于应用级抽象，在Rainbond的产品闭环里，体验非常好。这适用普通的开发人员开发和管理应用，对于不熟悉 Kubernetes用户快速起步也是一个不错的选择，在企业软件交付上Rainbond非常擅长。但在对Kubernetes 的系统管理上功能有欠缺。

由于个人知识和经验有限，如有理解不对的地方，还请见谅。

凹语言™（凹读音“Wa”）是针对 WASM 平台设计的的通用编程语言，支持 Linux、macOS 和 Windows 等主流操作系统和 Chrome 等浏览器环境，同时也支持作为独立Shell脚本和被嵌入脚本模式执行。主页 : https://wa-lang.org

克隆 vim-wa 仓库到本地(假设目录路径为 `$VIM_WA_ROOT`)，然后在 `$HOME/.vimrc` 文件添加以下配置信息：

“`

set rtp+=$VIM_WA_ROOT/misc/vim

filetype plugin indent on

syntax on

“`

打开 hello.wa 文件，效果如下图：

更多信息请参考 https://github.com/wa-lang/vim-wa 。

Dante Cloud 是一款企业级微服务架构和服务能力开发平台。首个全面拥抱 Spring Authorization Server 的版本，基于Spring Boot 2.7.4、Spring Cloud 2021.0.4、Spring Cloud Alibaba 2021.0.4.0、 Spring Authorization Server 0.3.1、Nacos 2.1.1 等最新版本开发的多租户系统，遵循SpringBoot编程思想，高度模块化和可配置化。具备服务发现、配置、熔断、限流、降级、监控、多级缓存、分布式事务、工作流等功能

平台定位

构建成熟的、完善的、全面的，基于 OAuth2.1 的、前后端分离的微服务架构解决方案。
面向企业级应用和互联网应用设计开发，既兼顾传统项目的微服务化，又满足互联网应用开发建设、快速迭代的使用需求。
平台架构使用微服务领域及周边相关的各类新兴技术或主流技术进行建设，是帮助快速跨越架构技术选型、研究探索阶段的利器。
代码简洁规范、结构合理清晰，是新技术开发应用的典型的、综合性案例，助力开发人员对新兴技术的学习和掌握。

[1]、为什么更名为 Dante Cloud

Dante Cloud (但丁)，原项目名称 Eurynome Cloud，很多朋友都反映名字太长、读起来拗口、不容易记等问题。因此在加入 Dromara 开源社区之际，将名字进行了变更。

Dante，即但丁·阿利基耶里(公1265年-公1321年)，13世纪末意大利诗人，现代意大利语的奠基者，欧洲文艺复兴时代的开拓人物之一，以长诗《神曲》(原名《喜剧》)而闻名，后来一位作家叫薄伽丘将其命名为神圣的喜剧。

他被认为是中古时期意大利文艺复兴中最伟大的诗人，也是西方最杰出的诗人之一，最伟大的作家之一。恩格斯评价说：“封建的中世纪的终结和现代资本主义纪的开端，是以一位大人物为标志的，这位人物就是意大利人但丁，他是中世纪的最后一位诗人，同时又是新时代的最初一位诗人”

更名为 Dante Cloud，寓意本项目会像恩格斯对但丁的评价一样，在行业变革的时期，可以成为一款承上启下，助力企业信息化建设变革的产品。

[2]、本次更新内容

主要更新
- [新增] 新增 Opaque Token (不透明令牌) 支持，并将其设置为默认 Token 格式，降低 JWT Token 被捕获解析的风险。仍旧保留 JWT Token 格式支持，可通过修改配置参数进行切换。
- [重构] 使用 Spring Authorization Server 标准的 Token 废弃机制，重构同一账号在同类型终端异处登录自动踢出(Kick Out)前一个登录用户功能。
- [修复] 结合 Opaque Token 修复 Kick Out 不生效问题。(注：Kick Out 仅在 Opaque Token 格式下有效。因 JWT Token 自身机制以及 Spring Authorization Server Token 验证实现方式与 Spring Security OAuth 的不同，使用 JWT Token 仅能实现 Token 过期验证，是无法实现 Kick Out 功能 )
- [新增] Monorepo 版前端工程新增 Dante Cloud 授权码登录预览功能
其它更新
- [重构] 重构部分枚举类，新增 Target 枚举，统一所有涉及本地及远程判断的枚举。
- [重构] 由于 Okhttps 大版本升级，包名进行了变更，因此涉及一部分代码修改重构。
- [删除] 删除无用的、自定义的 OAuth2ClientAuthorizationToken 类。
- [删除] 删除 AuthorizationServerConfiguration 中，冗余的 Authorization Server 配置
- [修复] 修复单体版参数配置错误，导致启动抛错问题。
- [优化] 结合 Opaque Token 机制，优化前端工程应用管理功能。
依赖更新
- [升级] mapstruct-processor 版本至 1.5.3.Final
- [升级] bcprov-jdk15to18 版本至 1.72
- [升级] okhttps 版本至 4.0.0
- [升级] dysmsapi 版本至 2.0.22
- [升级] alipay-sdk-java 版本至 4.34.8.ALL

【升级指南

本次更新涉及系统核心逻辑变化，升级新版代码涉及核心参数和数据的变更。如果是全新部署，可以跳过以下内容；如果是在系统，可以参考以下内容进行最小化修改。

修改 dante-cloud-platform.yaml 配置，增加 opaque 相关配置，具体修改内容参见工程中对应的配置文件。
手动修改数据和参数
- 修改数据表 oauth2_registered_client 中 token_settings 字段 JSON 数据，将其中 OAuth2TokenFormat 的值 “self-contained” 修改为 “reference”。
- 修改数据表 oauth2_application 中 access_token_format 字段的值，将其值从“0”改“1”
- 修改完成之后，需要清理 Redis 缓存，并重新启动服务。

[3]、Dante Cloud 2.7.X 主要变化

基于深度定制:
- 基于，重新构建基础数据存储代码，替代原有 JDBC 数据访问方式，破除原有数据存储局限，扩展为更符合实际应用的方式和设计。
- 基于，在 OAuth 2.1 规范基础之上，增加自定义“密码”认证模式，以兼容现有基于 OAuth 2 规范的、前后端分离的应用。
- 基于，在 OAuth 2.1 规范基础之上，增加自定义Social Credentials 认证模式，支持手机短信验证码、微信小程序、第三方应用登录。
- 遵照以及的代码规范，进行 OAuth2 认证服务器核心代码的开发，遵照其使用 Jackson 反序列化的方式，增加大量自定义 Jackson Module。
- 支持的标准的Token加密校验方式外，还了增加支持自定义证书的 Token 加密方式，可通过配置动态修改
- 支持 OAuth2 OIDC 认证模式，补充前端 OIDC 认证相关配置操作，以及对应的 /userinfo 接口调用支持和客户端注册支持
- 支持 OAuth2 Authorization Code PKCE 认证模式
- 扩展默认的模式，实现 Refresh Token 的创建。
- 扩展默认的模式，实现真正的使用 Scope 权限对接口进行验证。增加客户端 Scope 的权限配置功能，并与已有的用户权限体系解耦
- 自定义授权码模式登录认证页面和授权确认页面，授权码模式登录采用数据加密传输。支持多种验证码类型，暂不支持行为验证码。
- 基于和 JPA 构建支持 Database 和 Schema 模式的多租户架构。
代码结构的大规模调整和优化：
- 对原有代码进行了深度的“庖丁解牛”，严格遵照“单一职责”原则，根据各个组件的职责以及用途，将整个工程拆解细化为多个各自独立组件模块，在最大程度上降低代码间的耦合，也更容易聚焦和定位问题。
- 将通用化组件提取为独立工程，独立编译、按需选用，极大的降低系统主工程代码量。相关组件也已上传至 Maven 中央仓库，降低系统主工程工程代码编译耗时，改进和提升 CICD 效率，
- 原有主工程代码结构也进行了深化调整，代码分包更加合理，代码逻辑也更加清晰。

[4]、界面预览

[5]、额外说明

本项目以后将主要维护 `Spring Authorization Server` 版本，原有基于 `Spring Security OAuth2` 的版本已经移至 spring-security-oauth2 分支，可以从该分支或发行版页面获取历史版本继续使用。后期会根据 ISSUE 以及使用用户反馈情况，再行决定是否继续维护 `Spring Security OAuth2` 版本。
基于 Vue3、Vite3、Quasar2、Pinia 等新版前端已发布，原有基于 Vue2、Vuetify2、Typescript 开发的前端代码已移至 vue2+vuetify2+typescript 分支
自 2.7.2.3 版本起，Dante Cloud 所有核心代码全部开源。新开放内容包括：
- 接口权限鉴权：全面整合 `@PreAuthorize` 注解权限与 `URL` 权限，通过后端动态配置，无须在代码中配置 `Spring Security` 权限注解以及权限方法，即可实现接口鉴权以及权限的动态修改。采用分布式鉴权方案，规避 Gateway 统一鉴权的压力以及重复鉴权问题
- 动态权限数据分发：采用分布式服务独立鉴权方案，`Spring Security` `@PreAuthorize` 的权限注解、权限方法以及 `URL` 权限，通过后端动态配置后，实时动态分发至对应服务。
- User 数据策略访问：`OAuth2` `UserDetails` 核心数据支持直连数据库获取和 `Feign` 远程调用两种模式。`OAuth2` 直连数据库模式性能更优，`Feign` 访问远程调用可扩展性更强。可通过配置动态修改采用策略方式。
- 手机短信验证码注册认证：采用自定义 `OAuth2` 授权模式，使用统一 `Token` 接口，实现手机验证码登录认证，与平台为统一体系，统一返回`OAuth2` Token，支持服务接口鉴权
- 第三方系统社交注册认证：集成 `JustAuth`，采用自定义 `OAuth2` 授权模式，使用统一 `Token` 接口，实现基于 `JustAuth` 实现第三方系统社交登录认证，与平台为统一体系，统一返回 `OAuth2` Token，支持服务接口鉴权。所有 `JustAuth` 支持的第三方系统均支持。
- 微信小程序注册认证：采用自定义 `OAuth2` 授权模式，使用统一 `Token` 接口，实现支持微信小程序登录认证，与平台为统一体系，统一返回 `OAuth2` Token，支持服务接口鉴权。
- 其它方式注册认证：采用策略模式对外部系登录认证和用户注册进行接入支持，采用 `OAuth2` 默认认证接口。目前未集成的外部系统，可参考标准，适当增减参数，即可支持接入。
- 多通道 SMS 集成：集成阿里，百度，中国移动，华为，京东，极光，网易，七牛，腾讯，又拍，云片等平台短信发送通道。可通过配置动态选择具体使用通道。支持多模版定义以及模版参数顺序控制
- 微信小程序订阅消息：支持微信小程序订阅消息发送。提供订阅消息模版工厂，可根据自身业务需求，编写少量代码既可以拓展支持新订阅消息模版。

Dromara 开源社区

一、社区愿景

让每一位开源爱好者，体会到开源的快乐。

二、社区官网

https://dromara.org 是 Dromara 开源社区官方网站。

三、成员项目

此版本在5.5版本的基础上重构消息队列支持，使得在远程事件处理机制上更加广泛，您可以利用各类第三方消息队列实现分布式事件处理服务并可获得事件处理结果，亦可利用自定义协议亦或mqtt实现远端事件处理服务。
1、可根据应用场景限定远端事件处理是否为广播模式或不重复处理模式，此功能可完全由第三方消息队列限定。
2、获取事件处理结果在广播模式下仅以最先收到的处理结果为准。
3、可基于消息队列、MQTT或其它自定义用户协议实现分布式事件处理服务，如全服事件仅处理一次请优先考虑使用第三方消息队列。

以下是基于消息队列的范例代码：

关注公众号

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

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

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

关注公众号

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

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

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

漏洞描述

Apache Kylin 是一个开源的分布式分析引擎。

在 Apache Kylin 受影响版本的“重写配置”菜单中，当攻击者使用功能覆盖系统参数时存在命令注入漏洞，攻击者可通过传递恶意参数闭合“– conf=” 参数周围的单引号，从而注入恶意系统命令。攻击者可利用此漏洞进行远程恶意代码执行。

漏洞名称 Apache Kylin 存在命令注入漏洞漏洞类型代码注入发现时间 2022-10-14 漏洞影响广度极小 MPS编号 MPS-2022-3633 CVE编号 CVE-2022-24697 CNVD编号 –

影响范围

org.apache.kylin:kylin-core-common@(-∞, 4.0.2)

org.apache.kylin:kylin-server-base@(-∞, 4.0.2)

修复方案

升级org.apache.kylin:kylin-core-common到 4.0.2 或更高版本

升级org.apache.kylin:kylin-server-base到 4.0.2 或更高版本

参考链接

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

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

https://github.com/apache/kylin/pull/1811/commits/bd1b6028b8374d38e6968b7ee8b7cbf0

https://github.com/apache/kylin/pull/1811

情报订阅

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

具体订阅方式详见：

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

漏洞描述

JFinal CMS 是采用Jfinal框架开发的后台管理系统。

JFinal CMS 5.1.0版本中的 sql 接口由于没有使用相同的组件，并且没有对接口中传入的数据进行有效过滤，从而存在SQL注入漏洞。攻击者可利用该漏洞获取隐私数据，恶意操作数据库，甚至接管数据库所在服务器。

漏洞名称 JFinal CMS v5.1.0 存在SQL注入漏洞漏洞类型 SQL注入发现时间 2022-10-14 漏洞影响广度极小 MPS编号 MPS-2022-52970 CVE编号 CVE-2022-37208 CNVD编号 –

影响范围

JFinal CMS@[5.1.0, 5.1.0]

修复方案

参考链接

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

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

https://github.com/AgainstTheLight/someEXP_of_jfinal_cms/blob/main/jfinal_cms/sql5.md

情报订阅

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

具体订阅方式详见：

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

漏洞描述

swftools 是一个用于编辑和生成 Adobe Flash (SWF) 文件的实用程序。

swftools 在中的 png_read_header 函数中存在堆缓冲区溢出漏洞，攻击者可利用此漏洞执行恶意代码或造成拒绝服务。

漏洞名称 swftools 缓冲区溢出漏洞漏洞类型堆缓冲区溢出发现时间 2022-10-14 漏洞影响广度极小 MPS编号 MPS-2022-44728 CVE编号 CVE-2022-35081 CNVD编号 –

影响范围

matthiaskramm/swftools@[0.0.1, 0.9.2]

修复方案

参考链接

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

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

https://github.com/matthiaskramm/swftools/issues/183

情报订阅

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

具体订阅方式详见：

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

一年一度黑客们的狂欢——TiDB Hackathon 2022 报名已开启，万奖金等你来拿，还有技术专家、顶级投资人全程坐镇，你的实力将被更多人看到。

TiBD Hackathon 2022 ·「Possibility at Scale」，邀请你一起打破传统技术边界，突破固有思维局限，用 TiDB 释放创新的更多可能性。（悄悄说：今年真的不卷，值得一试！）

两大赛道任选

应用组（推荐，因为特别奖项更多！）

以体现 TiDB 产品价值为主，使用 TiDB 构建代码开源的产品、工具、应用等均可。部署方式上，更推荐基于 Cloud 构建 TiDB 相关应用。常见应用领域：游戏、电商、金融科技、公益等。

TiDB 产品组（延续传统，保持初心）

为 TiDB 内核产品以及 TiCDC、TiDB Lightning、TiUP 等周边工具的性能、稳定性、易用性或功能等各方面做出提升。

扫描下方二维码立即报名参与！

听说你想参加 TiDB Hackathon，却没有 idea？

别担心，脑洞达人东旭和他的架构师朋友们在创意脑暴会上分享的项目 idea 都整理好啦，快来看看有没有你感兴趣的~

创意贡献嘉宾

黄东旭 PingCAP 联合创始人兼 CTO
姚维 PingCAP 全球社区生态负责人
张兴晔 多点系统架构师
Cheng Chen PingCAP Product Manager

应用组

今年应用组的决赛参赛项目仅要求是 demo 级别的，例如以下项目示例：

OSS Insight：https://ossinsight.io/（复制链接至浏览器即可查看，下同）

这是一个基于 TiDB 实现的，数十亿 GitHub events 数据构建的洞察工具。只要你会写 SQL，就可以基于 Docusaurus、Apache ECharts 构建一个强大、酷炫的数据洞察工具。

TiDB & Snowflake Demo：https://tidb-snowflake-e-commerce-demo.vercel.app/

这是一个基于 TiDB 和 Snowflake 构建的电子商务系统，该系统使用了 TiDB 强大的实时 HTAP 能力和 Snowflake 的离线分析能力，来处理系统中大量的数据。

Ti-Click：http://ide.ti-click.com/

这是 TiDB Hackathon 2021 的 20 强项目之一，项目通过在线 IDE 的方式，快速搭建基于 TiDB 的 Example App 的开发和在线编译的实验室，可帮助开发者快速学习 TiDB。

Bookshop

这是一个基于 TiDB 搭建的在线书店应用，你可以通过它来学习如何导入表结构和数据，以及如何基于这些数据来编写 SQL。
这篇文章也以 Bookshop 应用的数据表结构和数据为基础来编写示例 SQL，为你介绍如何导入该应用的表结构和数据，以及其数据表结构的定义。https://docs.pingcap.com/zh/tidb/stable/dev-guide-bookshop-schema-design

Gitpod

对于 TiDB 初学者，我们基于 Gitpod，提供了一个云原生开发环境的使用帮助，你可以直接从你的浏览器或桌面 IDE 启动一个远程的 TiDB 开发环境，快速体验 TiDB 的能力。我们编写了全新的 TiDB 开发者文档，这份文档可以帮助应用开发者，在最短时间内上手 TiDB。
TiDB 开发者文档：https://docs.pingcap.com/zh/tidb/stable/dev-guide-overview

TiDB 产品组

彩蛋组

彩蛋组不可更改 TiDB/TiKV 源码，仅可使用插件方式进行 Hack。

更多项目 idea 也可以来 Hackathon 2022 创意库（扫描下方二维码获取灵感）

看到这么多 idea，你是否跃跃欲试了呢？热爱编程，勇于探索，就能参赛，你离万大奖只有一个报名的距离~

近日，中国长城科技集团股份有限公司（以下简称“中国长城”）签署了openKylin社区 CLA(Contributor License Agreement 贡献者许可协议)，正式加入openKylin开源社区。

中国长城是中国电子信息产业集团有限公司旗下“安全、先进、绿色自主计算产业专业子集团”，是网信科技自主创新生力军和中国“PKS”自主计算体系建设主力军。

中国长城坚持“芯端一体，双核驱动”的发展战略，致力于构建以“芯-端”为核心的自主计算产品链，全面带动“网-云-数-智”自主计算产业生态发展。自重组以来成功突破高端通用芯片（CPU）、固件等关键核心技术，依托“PKS”自主计算体系，构建了从芯片、台式机、笔记本、服务器、网络交换设备到应用系统等具有完整自主知识产权的产品谱系，成功赋能党政办公及金融、能源、电信、交通等重点信息化领域的数字化转型

在加入openKylin社区后，中国长城将依托自身优势，凝聚技术先锋力量，积极参与社区合作，完善生态适配体系，助力拓展行业生态圈，推动产业链深度融合及网信产业纵深发展，扩大网信产品影响力。

社区会员持续招募中

审核：openKylin

摘要：在本案例中，我们将展示如何对基础的Mask R-CNN进行扩展，完成人体关键节点标注的任务。

本文分享自华为云社区《使用Mask R-CNN模型实现人体关键节点标注》，作者：运气男孩。

前言

ModelArts 是面向开发者的一站式 AI 开发平台，为机器学习与深度学习提供海量数据预处理及交互式智能标注、大规模分布式训练、自动化模型生成，及端-边-云模型按需部署能力，帮助用户快速创建和部署模型，管理全周期 AI 工作流。

背景

Mask R-CNN是一个灵活开放的框架，可以在这个基础框架的基础上进行扩展，以完成更多的人工智能任务。在本案例中，我们将展示如何对基础的Mask R-CNN进行扩展，完成人体关键节点标注的任务。

Mask R-CNN整体架构，它的3个主要网络：

backbone网络，用于生成特征图
RPN网络，用于生成实例的位置、分类、分割(mask)信息
head网络，对位置、分类和分割(mask)信息进行训练

在head网络中，有分类、位置框和分割(mask)信息的3个分支，我们可以对head网络进行扩展，加入一个人体关键节点keypoint分支。并对其进行训练，使得我们的模型具备关键节点分析的能力。那么我们的模型结构将如下图所示：

head网络中，红色的keypionts分支为新加入的人体关键节点分支

MaskRCNN模型的解析可以参考此文章。

本案例的运行环境是 TensorFlow 1.8.0 。

keypoints分支

在RPN中，我们生成Proposal后，当检测到Proposal的分类为”Person”时，对每个部位的关键点生成一个one-hot掩码，训练的目标最终是得到一个56*56的二值掩码，当中只有一个像素被标记为关键点，其余像素均为背景。对于每一个关键点的位置，进行最小化平均交叉熵损失检测，K个关键点是被独立处理的。

人体姿态检测中，人本身可以作为一个目标实例进行分类检测。但是，采取了one-hot编码以后，就可以扩展到coco数据集中被标注的17个人体关键点（例如：左眼、右耳），同时也能够处理非连续型数值特征。

COCO数据集中，对人体中17个关键点进行了标注，包括：鼻子,左眼,右眼,左耳,右耳,左肩,右肩,左肘,右肘,左手腕,右手腕,左膝盖,右膝盖,左脚踝,右脚踝,左小腿,右小腿，如下图所示：

基础环境准备

在使用 ModelArts 进行 AI 开发前，需先完成以下基础操作哦（如有已完成部分，请忽略），主要分为4步（注册–>实名认证–>服务授权–>领代金券）：

1、使用手机号注册华为云账号：注册

2、点此去完成实名认证，账号类型选”个人”，个人认证类型推荐使用”扫码认证”。

3、进入 ModelArts 控制台数据管理页面，上方会提示访问授权，【服务授权】按钮，按下图顺序操作：

4、进入 ModelArts 控制台首页，如下图，页面上的”彩蛋”，领取新手福利代金券！后续步骤可能会产生资源消耗费用，请务必领取。

以上操作，也提供了详细的视频教程，点此查看：ModelArts环境配置

在ModelArts中训练Mask R-CNN keypoints模型

准备数据和源代码

第一步：准备数据集和预训练模型

下载完成后，显示如下压缩包

解压后，得到data目录，其结构如下：

其中data/mask_rcnn_coco_humanpose.h5为预训练模型，annotations、train2014和val2014为我们提前准备好的最小数据集，包含了500张图片的标注信息。

第二步：准备源代码

第三步：安装依赖pycocotools

我们使用COCO数据集，需要安装工具库pycocotools

程序初始化

第一步：导入相关的库，定义全局变量

第二步：生成配置项

我们定义Config类的子类MyTrainConfig，指定相关的参数，较为关键的参数有：

__NAME__： Config的唯一名称
__NUM_CLASSIS__：分类的数量，我们只生成圆形，正方形和三角形，再加上背景，因此一共是4个分类
__IMAGE_MIN_DIM和IMAGE_MAX_DIM__：图片的最大和最小尺寸，我们生成固定的128×128的图片，因此都设置为128
__TRAIN_ROIS_PER_IMAGE__：每张图片上训练的RoI个数
__STEPS_PER_EPOCH和VALIDATION_STEPS__：训练和验证时，每轮的step数量，减少step的数量可以加速训练，但是检测精度降低

第三步：创建数据集对象

我们使用封装好的CocoDataset类，生成训练集和验证集。

创建模型

用”training”模式创建模型对象，并加载预训练模型

运行完成后输出下面

训练模型

Keras中的模型可以按照制定的层进行构建，在模型的train方法中，我们可以通过layers参数来指定特定的层进行训练。layers参数有以下几种预设值：

heads:只训练head网络中的分类、mask和bbox回归
all: 所有的layer
3+: 训练ResNet Stage3和后续Stage
4+: 训练ResNet Stage4和后续Stage
5+: 训练ResNet Stage5和后续Stage

此外，layers参数还支持正则表达式，按照匹配规则指定layer，可以调用model.keras_model.summary()查看各个层的名称，然后按照需要指定要训练的层。

我们针对不同的layer进行训练，首先，训练head网络中的4个分支：

输出结果：

然后训练ResNet Stage4和后续Stage

最后，对所有layer进行优化，并将训练的模型保存到本地

输出结果：

使用模型检测图片物体

第一步：创建”Inference”模式的模型对象，并加载我们训练好的模型文件

第二步：从验证数据集中随机选出一张图片，显式Ground Truth信息

输出结果，识别图片如下：

第三步：使用模型对图片进行预测，并显示结果

最终识别结果：

总结

使用Mask R-CNN模型实现人体关键节点标注，在head网络中，有分类、位置框和分割(mask)信息的3个分支，我们可以对head网络进行扩展，加入一个人体关键节点keypoint分支。并对其进行训练，使得我们的模型具备关键节点分析的能力。对人体中17个关键点进行了标注，包括：鼻子,左眼,右眼,左耳,右耳,左肩,右肩,左肘,右肘,左手腕,右手腕,左膝盖,右膝盖,左脚踝,右脚踝,左小腿,右小腿，并且取得了不错的效果。

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

缓存就是内存中的数据，常常来自对数据库查询结果的保存。使用缓存，我们可以避免频繁的与数据库进行交互，进而提高响应速度MyBatis也提供了对缓存的支持，分为一级缓存和二级缓存，可以通过下图来理解：

①、一级缓存是SqlSession级别的缓存。在操作数据库时需要构造sqlSession对象，在对象中有一个数据结构（HashMap）用于存储缓存数据。不同的sqlSession之间的缓存数据区域（HashMap）是互相不影响的。

②、二级缓存是mapper级别的缓存，多个SqlSession去操作同一个Mapper的sql语句，多个SqlSession可以共用二级缓存，二级缓存是跨SqlSession的

一级缓存

默认是开启的

①、我们使用同一个sqlSession，对User表根据相同id进行两次查询，查看他们发出sql语句的情况

查看控制台打印情况：

② 同样是对user表进行两次查询，只不过两次查询之间进行了一次update操作。

查看控制台打印情况：

③、总结

1、第一次发起查询用户id为1的用户信息，先去找缓存中是否有id为1的用户信息，如果没有，从数据库查询用户信息。得到用户信息，将用户信息存储到一级缓存中。

2、如果中间sqlSession去执行commit操作（执行插入、更新、删除），则会清空SqlSession中的一级缓存，这样做的目的为了让缓存中存储的是最新的信息，避免脏读。

3、第二次发起查询用户id为1的用户信息，先去找缓存中是否有id为1的用户信息，缓存中有，直接从缓存中获取用户信息

一级缓存原理探究与源码分析

问题1：一级缓存底层数据结构到底是什么？

问题2：一级缓存的工作流程是怎样的？

一级缓存底层数据结构到底是什么？

之前说,所以我从SqlSession这个类入手

可以看到，中有一个和缓存有关的方法——刷新缓存的方法，点进去，找到它的实现类

再次点进去,再次点进去并找到其实现类，

进入方法。进入到了类中

我们看到了类中有一个属性，很明显它是一个HashMap，我们所调用的方法，实际上就是调用的Map的clear方法

得出结论：

一级缓存的数据结构确实是HashMap

一级缓存的执行流程

我们进入到中看到一个方法，见名思意是一个创建CacheKey的方法找到它的实现类和方法

我们分析一下创建CacheKey的这块代码：

我们再点进去方法看一看

我们知道了那些数据是在CacheKey对象中如何存储的了。下面我们返回方法。

我们进入，可以看到一个方法：

这里我们很清楚的看到，在执行方法前，方法被创建了

我们可以看到，创建CacheKey后调用了query()方法，我们再次点进去：

在执行SQL前如何在一级缓存中找不到Key，那么将会执行sql，我们来看一下执行sql前后会做些什么，进入

分析一下：

一级缓存源码分析结论：

一级缓存的数据结构是一个，它的value就是查询结果，它的key是，中有一个list属性，等参数都存入到了这个list中
先创建，会首先根据查询缓存中有没有，如果有，就处理缓存中的参数，如果没有，就执行sql，执行sql后执行sql后把结果存入缓存

二级缓存

注意：Mybatis的二级缓存不是默认开启的，是需要经过配置才能使用的

启用二级缓存

分为三步走：

1）开启映射器配置文件中的缓存配置：

在需要使用二级缓存的Mapper配置文件中配置<cache>标签

3）在具体CURD标签上配置 useCache=true

注意：实体类要实现Serializable接口，因为二级缓存会将对象写进硬盘，就必须序列化，以及兼容对象在网络中的传输

具体实现

二级缓存源码分析

问题：

① cache标签如何被解析的（二级缓存的底层数据结构是什么？）？

② 同时开启一级缓存二级缓存，优先级？

③ 为什么只有执行sqlSession.commit或者sqlSession.close二级缓存才会生效

④ 更新方法为什么不会清空二级缓存？

标签 < cache/> 的解析

二级缓存和具体的命名空间绑定，一个Mapper中有一个Cache, 相同Mapper中的MappedStatement共用同一个Cache

根据之前的mybatis源码剖析，xml的解析工作主要交给XMLConfigBuilder.parse()方法来实现

我们来看看解析Mapper.xml

先来看看是如何构建Cache对象的

MapperBuilderAssistant.useNewCache()

我们看到一个Mapper.xml只会解析一次<cache/>标签，也就是只创建一次Cache对象，放进configuration中，并将cache赋值给MapperBuilderAssistant.currentCache

buildStatementFromContext(context.evalNodes(“select|insert|update|delete”));将Cache包装到MappedStatement

我们看到将Mapper中创建的Cache对象，加入到了每个MappedStatement对象中，也就是同一个Mapper中所有的MappedStatement中的cache属性引用的是同一个

有关于<cache/>标签的解析就到这了。

查询源码分析

CachingExecutor

如果设置了flushCache=”true”，则每次查询都会刷新缓存

如上，注意二级缓存是从 MappedStatement 中获取的。由于 MappedStatement 存在于全局配置中，可以多个 CachingExecutor 获取到，这样就会出现线程安全问题。除此之外，若不加以控制，多个事务共用一个缓存实例，会导致脏读问题。至于脏读问题，需要借助其他类来处理，也就是上面代码中 tcm 变量对应的类型。下面分析一下。

TransactionalCacheManager

TransactionalCacheManager 内部维护了 Cache 实例与 TransactionalCache 实例间的映射关系，该类也仅负责维护两者的映射关系，真正做事的还是 TransactionalCache。TransactionalCache 是一种缓存装饰器，可以为 Cache 实例增加事务功能。下面分析一下该类的逻辑。

TransactionalCache

存储二级缓存对象的时候是放到了TransactionalCache.entriesToAddOnCommit这个map中，但是每次查询的时候是直接从TransactionalCache.delegate中去查询的，所以这个二级缓存查询数据库后，设置缓存值是没有立刻生效的，主要是因为直接存到 delegate 会导致脏数据问题

为何只有SqlSession提交或关闭之后？

那我们来看下SqlSession.commit()方法做了什么

SqlSession

二级缓存的刷新

我们来看看SqlSession的更新操作

MyBatis二级缓存只适用于不常进行增、删、改的数据，比如国家行政区省市区街道数据。一但数据变更，MyBatis会清空缓存。因此二级缓存不适用于经常进行更新的数据。

总结：

在二级缓存的设计上，MyBatis大量地运用了装饰者模式，如CachingExecutor, 以及各种Cache接口的装饰器。

二级缓存实现了Sqlsession之间的缓存数据共享，属于namespace级别
二级缓存具有丰富的缓存策略。
二级缓存可由多个装饰器，与基础缓存组合而成
二级缓存工作由一个缓存装饰执行器CachingExecutor和一个事务型预缓存TransactionalCache 完成

本文由教研团队发布。

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

转载请注明出处！

作者：板栗，前阿里、京东运营，6年资深互联网运营，成功从C端转B端，擅长用户运营、内容营销和个人IP打造，人人都是产品经理/鸟哥笔记等平台专栏作者

有很多小伙伴习惯了追求速度，一有问题，常常依靠下意识去处理，以为这就是职场上所强调的执行力。其实不是，执行力是指带来结果。

思与行的关系，我认为沈鹏在《详谈》中提到的尤为准确：真正的执行力应该是想得足够清楚的时候，你拼了，这才是执行力。不是说你什么都没想就瞎搞，那不是执行力。

说回开源社区运营，本质仍是社区运营与用户运营。前者是后者的子集，是一种相对小众的特殊情况，但仍旧逃不开用户运营的共性，即围绕人这一核心，梳理用户画像，理解用户需求，通过各种资源配置，让用户来到你的地盘，留下来，玩得爽，自觉维护你，还要对外说你的好话。

成也规模，败也规模。

社区运营因为用户规模小、重人力、琐碎的事情多，常常被人看做是鄙视链最末端。是的，你没看错，尽管运营已经在互联网鄙视链的底端，但不妨碍内部仍有更精细的鄙视链划分。

但也是因为规模不算大，社区运营才有可能对这群人进行更加人性化甚至是人格化的运营。尤其是在一对一的用户运营中，往往能够挖掘出社区关键人物，撬动更大贡献。

毕竟一个社区真正能够产出、有话语权的人物，也只有20%不到。而社区运营本身也可以作为更大范围内的用户运营或者功能产品化的前期测试，给其他团队以一些新的思路和支持。

做完了社区运营的心理建设，接下来讲讲如何从0到1运营开源社区。

板栗

01 了解用户，梳理开源社区用户画像

运营开源社区的第一步就是了解你的用户。

只有知道了他们是谁，多大年纪，做什么工作，内容消费习惯是什么样的，喜欢什么时候摸鱼，有什么需求，你才知道要如何满足对方的需求，从而让他们也能为你所用。

除了梳理出典型用户画像（物理属性+社会属性）之外，还要了解用户结构和了解用户的分级、分类、分阶段情况，具体来说包括各类典型用户的数量、占比、每日增长规模大概是多少、不同生命周期的用户占比是否健康、成长速度是否会导致青黄不接（新用户不够，老用户流失，无人活跃）……

一般C端业务的社区用户画像到这里就够了，但对开源社区这种和B端业务强相关的社区来说（因为B端业务决策是集体决策，更多是取决于角色决策，详细差异可以查看我的B端运营三部曲，放在文末），还需要在用户画像时加上行业（行业现状、市场规模、发展趋势）、企业（如企业规模、收入规模、活跃用户、公司评价）、职位（CTO、技术总监、专家还是一线人员）等标签，以此来做用户分级，方便评估后续运营成本的投入。

就真的还蛮现实的。用户进入社区之初，就已经分出了三六九等，应用广泛、需求强的行业比试水行业优先级高，大公司职员比小公司职员待遇好，技术大咖比小白用户得到更多青睐……

如果说C端社区运营像自由恋爱，讲感情，看感觉，那么B端社区运营更多就是相亲，各种条件摆得清清楚楚，评估过后再来看以什么姿态、用几分力。

那要如何了解用户呢？

我自己常用的调研手段主要有以下三种：

1）用户访谈：一对一访谈和群访都有，但规模都比较小。一对一可以聊的更深度，用户也会有比较好的体验，感觉被尊重和独家对待。群访可以撬动一些相对不愿意透露信息的企业人员，给人以更强的安全感。

很多人以为访谈很容易，不就是聊天嘛，但其实访谈是需要提前设计问题的，而且在访谈时要尽量客观记录和分析，记录时不要加入自己的理解，以防信息变形，导致后续分析离用户的真实想法越来越远。同时也要学会追问，挖掘用户深层次的真实需求，在初次交锋时，用户可能会讲一些很表象的想法和需求。追问可以验证用户是不是真的有这样的需求，真的这样想。

2）问卷调研：比较适合更大规模的用户研究，但问卷的设计很考验人，这里有需要的话，以后单独开一篇来讲。

3）看行业报告：结合报告数据与自己的一线经验，对照分析自己的目标用户有哪些共性特点，有哪些是报告所未能涉及到、属于你的小洞察的。

这里还要着重讲一下心态问题，因为社区运营工作多且琐碎，反复遇到一些问题以后，不免会有些烦躁和抱怨，比如用户这么笨，这么简单都不会操作？他怎么这么懒，文档不是都有吗？怎么又问重复的问题？

做社区运营，尤其是不断滚动的成长型社区，就像生育孩子一样，大孩长大了，二胎又来了……然后还有三胎、四胎。

对你来说重复的问题，对他们来说可能是第一次。他们也不是笨，最多只是懒，习惯了伸手问妈要。放下不耐烦，打破“知识的诅咒”，多看用户的留言和评价，针对性解决问题，才能把你的“孩子”带起来。

02 定位先行，一切运营动作围绕定位展开

完成“了解用户，梳理用户画像”这个步骤以后，基本掌握了我要运营的社区的目标用户情况，概括起来就是企业侧以技术人员为主，还有少量的商务、市场以及高管；校园侧会有一些相关专业的学生及教授，需求方面依次有技术需求、交流需求和商业合作需求。而社区只是作为一个满足用户需求的载体，也是实现企业目的的工具。

因此需要给社区一个定位，一来是设定核心目标以及边界，夯实这个定位的，我们可以做，其余不做；二来也是为了让每个第一眼看到社区、第一次进入到社区的用户就知道“这个社区是做什么的，能够提供什么价值，都有谁在里面，我能够在其中做什么”。

问题来了，定位要怎么去做呢？尤其是那种看起来高大上的slogan要怎么写呢？

首先是要站在用户视角，看用户最需要什么，而不是你有什么。我相信每个人不论是对自己运营的社区还是运营的产品，都能够说出来一大堆的优点，但问题是你写的那一点，用户真的care吗？同样是写“全球首个XXX社区”“全国最大XXX社区”，B端用户会考量技术积淀、开发者支持力度、生态丰富度，但如果是小众社区呢？这些用户会希望被冠以“大众化”的title吗？未见得。不管你是从行业价值角度、自身优势角度、还是诸如建立时间这样的客观描述角度，只有当你的定位话术刚好戳中用户最关心的那个点，才是有效定位。

其次是明确开源社区的内部定位。截至目前，开源技术本身也没有找到很好的商业模式，开源不是出发点，也不是终点，而依托开源技术而生的开源社区既然动用了人力物力财力，必然也承载着自己的企业使命。

如在《开源社区运营经验分享（一）：我们为什么要做社区？》中所言，我自己所运营的开源社区对于企业的作用在于反哺产品迭代、为品牌传播建立种子用户群以及孵化商机，本质还是为商业化做产品和流量准备。

可能会有小伙伴说“不就是一个小小的社区运营，至于搞得这么复杂嘛”。越是难以量化、不被重视、承载误解的工作，越需要自己去厘清眉目，才能避免做着做着失去了工作的热情，陷入机械的重复中。

而有了定位，知道自己所做的事情到底能给公司业务带来什么价值以后，面对该做的事情，你会有自己的标准去判断优先级；面对一些突然而来的dirtywork，你才知道如何巧妙的拒绝。

有了定位以后，不管是按照KPI还是OKR拆解和制定一版运营规划，和上级对齐自己的工作内容。这样既可以体现你的工作态度和能力，也便于你去争取工作所需的资源。

03 开源社区运营：分级、分类、分阶段

1.用户分级运营

资源永远是有限的，而我们的工作就是要在将有限的资源利用最大化。除去显性的金钱与物料，你的时间也是极其宝贵的资源。

即使是小规模的社区运营，可能也有小几千人，如果对每个人投入都一样多，最后大概率只会累死自己，还照顾不好用户。海王或许有，但即使是最优秀的时间管理大师，也绝对不会同时应付超过150个人（邓巴数，即150定律：人类智力将允许人类拥有稳定社交网络的人数是148人，四舍五入大约是150人）。

同时，你会发现这个世界遵循着帕累托原理（又名28定律，即最重要的只占其中一小部分），80% 的人消费着20% 的人生产出来的内容，20%的人占据着这个世界上超过80% 的财富（这一趋势只会越来越极端，比如 5% 的人占据着世界财富的95%）。

80% 是多数，但却是次要的。开源社区不过是世界的一个缩影，20% 的用户创造80% 的价值，20% 的客户创造了80% 的利润。作为一个运营，也需要花费80% 的精力去服务20% 的优质用户。

用户分层是按照重要程度、贡献价值等标准来划分，有比较鲜明的等级差异（没有到不尊重，只是指投入程度和运营优先级的差异）。用户分层的判断核心在于用户对产品或者业务的ROI，以便后续根据预期收益投入相应的成本。

一般来说，我们会把用户按照贡献价值从高到低分为以下五种：

以上数字只是示意，并非不同级别用户的实际贡献

名人用户：行业大佬、学术权威等，平时不怎么发言，但可以为社区权威性背书，必要时也能为合作牵线搭桥
贡献用户：资深开发、技术大牛等，可以贡献代码方案
活跃用户：一般的技术开发者，氛围担当的同时可以解决一些基础问题和提建议
普通用户：反馈产品问题，参加社群的有奖活动
入门用户：一般是学生，处于研究阶段，最常干的事情就是提问和薅羊毛

2.用户分类运营

有时候也会被称为“分层运营”，但我还是认为分类一词更加清晰，因为分类运营没有明确的等级差异，不存在谁高谁低。而“分层”本身就有高低之分。

用户分类的判断核心源自于用户本身的差异，如行为习惯、需求场景、技术水平、企业背景不一样，分类的目的是方便运营以特定手段和内容来触达和满足不同类型的用户。

比如，同样处于普通用户层级的两人，可能一个来自金融行业，另一个是零售行业的，他们的核心需求就不太一样。

用户分类的标准相对比较灵活，除去行业属性、职业属性、企业属性之外，城市、甚至是设备类型都可以分类。由于用户价值也是分类的标准之一，所以有些人会把用户的分类与分级搞混。

完成用户分类以后，抽象出共性，再进行针对性运营即可。

3.用户分阶段运营

而不管用户分级还是用户分层，都需要分阶段运营用户，这里的判断依据在于用户与产品的交互和认可程度：是只听过没用过，还是刚安装不会用，又或者是已经非常熟练到可以去教别人？这个部分相对复杂一些，涉及到用户生命周期管理、用户成长体系以及用户激励体系的搭建。

04 搭建用户体系之前的5个问题

随着用户不断深入了解、使用和感受产品，加深与产品的关联度，用户身份也是在不断变化的，比如导入期对应新用户，成长对应普通用户。

之所以这么划分，是为了更加清楚用户在不同阶段的核心需求。在这个基础上，运营利用已有的资源，引导用户进入或者更持久的停留在“运营期望的阶段和状态”，进一步提高LT和Value，完成产品从用户价值到商业价值的统一。

为了达成这一目标，我们可用的手段包括但不限于“用户成长体系”和“用户激励体系”。

而不管是成长体系还是激励体系，都要先思考下面几个问题：

问题1：哪些用户行为是我们希望看到的？

问题2：判断用户行为是否值得被激励的标准是什么？

问题3：如何判断这些行为之间的权重？

问题4：用户为何会按照我们的预期行动？我们能提供什么价值？

问题5：这个价值要怎么给，给多少，多久给一次，给的形式……整个玩法要如何设计，才能更好地刺激用户完成既定行为？

1、哪些用户行为是我们希望看到的？

对于一个开源技术社区来说，我认为可以从技术使用深度以及社区交互深度两个角度去思考。用户来到社区的初衷是技术互动，和同行交流并解决技术问题。一个人只要他提出的问题能够得到及时有效的回复，他就能留下来。如果他还能解决别人的问题，得到来自其他用户甚至是社区官方的认可，他就会更有动力在社区活跃。但如果只停留在技术交流，那么就低估了社区尤其是开源社区的价值空间。

PingCAP 联合创始人&CTO黄东旭在采访中说到，对于社区运营者来说，最关键的任务不是让沉默者更多或更深度地使用，而是让他们和网络中的其他用户建立更多的连接。将网络效应从使用者的网络效应转移到基于信仰的网络效应，将社区中心从开源公司内部转移到外部以获得更大的势能。

翻译过来就是，技术层面的交流，只能算是物理反应。当用户之间的连接程度超越技术转向共同信仰或者价值观的时候，社区才开始有了化学反应。这个时候社区的势能呈指数级增长，社区成员不仅可以自治，还能以共同体的身份对外发声与合作。

1）技术使用深度具体来说，包括但不限于使用技术产品、提bug、提issue、提PR等；

2）社区交互深度具体来说，包括但不限于参与官方内容转赞评，帮助社区其他用户解决技术问题，参与社区活动，在社区进行主题分享等。

2、判断用户行为是否值得被激励的标准是什么？

一个用户行为是否值得被激励的标准，一是用户行动以后会给社区好评吗，也就是说用户自己觉得舒服吗，有没有被满足；二是用户行动以后对社区有没有正外部性，也就是其他用户有没有因此受益。因为符合这两个标准的才能让用户玩得爽，以及社区健康可持续地发展。不能说，这个用户爽了，其他用户都跑了。虽然我们经常说运营用户就是伺候上帝，但问题是社区不只一个“上帝”，更何况上帝之间的行为是会相互影响的。

3、如何判断这些行为之间的权重？

还是上面两条标准，优先考虑社区整体的健康发展。

其余行为，要结合投入成本来看。一般来说，用户投入越重的行为，我们越鼓励。我们也很希望每个用户都能成为contributor，但很可惜达不到。对此大家也可以通过“官方投入”去观察产品和社区到底鼓励用户做什么。从某种程度来说，这也是一次交易。

4、用户为何会按照我们的预期行动？我们能提供什么价值？

用户愿意听你的、按照你说的做，是因为他愿意这么做来交换你手中的资源，并不是因为你牛逼。

而我们能够提供的资源或者说价值一般包括以下四种：

1）物质：现金激励，购物卡，周边，苹果产品等硬通货；

2）内容：技术文档，经典QA，行业资讯，白皮书等；

3）服务：一对一技术专家答疑，与权威专家交流机会，企业参观；

4）荣誉：社区认证讲师、技术布道者等荣誉；

这里提醒一下，还是要学会通过荣誉激励用户去完成预期行为。

大多数时候，钱都是不够的，我还没有听过谁的预算是花不完的。同时，人为了物质激励去做事是会疲乏且滥竽充数来薅羊毛的，只有内在动机才会让一个人真正优质高量输出（比如我现在一毛钱都没有，但心甘情愿在这里写内容）。

5、这个价值要怎么给，给多少，多久给一次，给的形式……整个玩法要如何设计，才能更好地刺激用户完成既定行为？

这个比较复杂，需要具体情况具体分析。由于工作内容暂时不便公开，所以细节也没法说。但是有些原则可以和大家分享。

首先是有多大金刚钻，揽多少瓷器活儿。

一定要结合现有资源去设计整个体系，不要空头支票。钱不够的时候，一定一定要取舍，做好重点，而不是均摊费用！

其次是设计用户行为时，要时刻考虑降低用户行动成本，不改变用户本来的行为路径，除非真的有必要。

比如说一个技术用户进来，在部署安装的过程中大概率会遇到问题，在他解决完以后，你引导他写一个注意事项文档，这是OK的。但你不要妄想一点点诱惑可以让用户专门为你创造一个东西。再比如，用户习惯了在GitHub上面提issue，用Markdown写作，你就不要非得要求别人和你一样用飞书文档交流。

最后要注意结合用户自然行为的特征（行动极限，行动频率等）去设计你的目标。

比如说，一般情况下一个用户每天也就是下午摸鱼的时候能够来给你当志愿者维护社区秩序，答上那么七八个问题，你就不要设计成每日答疑数量满50个可以获得XXX。人又不傻，放在面前的胡萝卜才去够，放太远了就直接放弃掉了。你设置奖励的目的是让用户完成从现状到理想的跃迁，不是“我不玩了”或者干脆“跳他个粉身碎骨”。

微信公众号：南有板栗

终身学习，定期分享运营经验和个人成长经验

本文来源于开源集《开源观止》第 4 期，更多精彩内容，请下载：

https://oscimg.oschina.net/public_shard/opensource-guanzhi-.pdf

美图崇尚的故障文化是“拥抱故障，卓越运维”，倡导的基准是No-Blame，即「不指责，重改进」。今年9月TakinTalks社区曾经分享过美图的三段式故障治理方法（美图SRE：一次线上大事故，我悟出了故障治理的3步9招），这次重点讲讲故障治理中的最后一个重要环节——故障后的复盘，在这个过程里可以总结吸取经验教训并改进，这样才能让整个系统的稳定性得到实质性提升。

作者介绍：美图SRE负责人-石鹏

TakinTalks社区专家团特聘讲师。2016年加入美图，运维技术专家，美图产品SRE负责人。目前在美图负责社区、商业化、创新等全线产品的运维保障工作，同时参与公司日志、监控等基础设施的建设。参与或主导过多次公司基础设施的调整、改造，在监控、灾备、故障管理、稳定性运营等方面有一定的经验和积累。

温馨提醒：本文约2900字，预计花费4分钟阅读。后台回复“8201”获取文件资料；回复 “交流” 进入读者交流群；

一、故障后的复盘该怎么进行？

1.1 故障复盘的黄金3问

故障复盘过程怎么去有效提问，这里有个准则可以参考，就是黄金三问：

我们应该怎么做，才能更快地去恢复业务？

我们应该怎么做，才能避免再次出现类似的问题？

我们有哪些好的经验可以总结、提炼并固化？

这是我们在复盘中需要去发问的，自我发问还有相互之间的挑战审视都是需要的。

除了前面这些东西，我们还有没有一些更高维度视角可以去帮助提升整体的稳定性，也就是 “我们还能做什么” ？这个也可以去进行自我发问。

1.2 故障定级、定性与定责

1.2.1 故障定级

故障定级的方法标准在不同公司是不同的，比如对故障级别的定义和命名都会有差异：有的公司是用P0、P1、P2、P3这样的分级标准，在美图则是按一二三四级去定义级别的，当然定级的逻辑肯定都是一致的，那就是影响越大则级别越高。

美图的具体做法是参考故障对服务功能的影响、故障的影响时长、故障发生所处时段、对客户的影响范围这些维度，对不同维度赋以不同的权重，最终累计得出加权分数，然后再根据预设的标准去判定故障到底属于什么级别。

下图是我们服务端的故障定级标准，客户端有另一套标准，但整体的逻辑是类似的。

上面是我们的通用标准，不过有部分业务会有个性化的定级需求，比如商业化部门会更关注故障有没有影响收入、造成资损；或者有些业务会更关注有没有影响口碑、造成PR事件等；针对这样的需求场景我们有单独梳理业务个性化定级标准。然后跟这些业务部门进行沟通协商，将相关个性化的标准映射到我们的通用定级标准中，将大家的定级标准拉齐，如此这个故障定级标准就可以方便地在公司内部做推广应用，进而对故障实现体系化的管理。

1.2.2 故障定性

故障定性其实就是根据故障发生的原因进行有效分类，包含代码质量、测试质量、流程规范、变更操作、容量规划、产品逻辑、硬件设备、预案失效、云厂故障等等。

1.2.3 故障定责

前面有讲美图的故障文化叫No-Blame不指责，那为什么还要去做定责呢？

这里的定责并不等于惩罚、更不等于扣绩效或工资。这里的定责更多的是指要你承担改进的责任，跟大家分享几个判定原则：

高压线原则：各个企业都会有内部的红线，比如说数据安全，凡事触碰到红线责任就会更大一些，也有一些对应的措施。
健壮性原则：每一个服务模块自身要有比较强的自愈能力，比如要做好主备、集群，要做好限流、降级等容灾手段等。其中对依赖的管理需要重点关注，原则上核心应用对非核心应用的依赖必须要有降级和限制的手段，以此保证自身的健壮性。
第三方默认无责：定责是对内的，即使我们上云，引用了很多第三方应用，也是默认第三方是没有责任的。这是为了避免内部定责时各种问题都甩锅给第三方，久而久之SRE会失去应有的责任心。当然，故障是第三方引起的，我们理应去追责、索赔，这没有问题，但你在架构设计上、整个稳定性保障上有没有哪些工作是可以完善来规避故障的，这是我们需要思考的内容。
分段判定原则：部分故障的的链路比较长，原因可能也不止一个，因此需要去做一些分段的分析，有利于更全面地审视故障问题，相关分析也会更聚焦，最终推导出来的改进措施也会更具针对性。
自由裁量原则：虽然我们有相关标准，但是实操时还是要case by case，具体事情具体分析，不能完全一刀切，要保证灵活性。

1.3 输出报告与定期回顾

接下来就是故障报告的产出了，也是整个故障处理过程中比较重要的一环，下图是美图做故障报告的一个固定模板，在报告中陈述影响功能、故障级别、责任部门/责任人、处理过程、改进措施等，把这些故障报告定期进行归纳梳理，一般会按照故障级别、发生时间、故障类型、责任部门…甚至更细的分类去做梳理。

有一点可能会被很多人忽视，就是针对故障总结去做周期性的回顾。像我们美图会有一个年度目标，制定故障预算，通过故障计分来进行回顾，每发生一个故障会扣你特定的故障分，在周期结束之后，你要去看故障分/故障预算的目标是不是达成了。

另外，应该周期性地去分析这些故障的发生是否有规律，是否集中在某些业务部门，是否有集中出现的时间段，是否频繁出现跟某些基础设施或组件的关联，以及有没有什么其他的规律性？通过分析推导出来的改进措施到底有没有落地，整改措施是不是有效？有没有发生过重复的/类似的故障？这些都是需要进行周期性回顾的。

二、故障管理的2个要点分享

GoogleSRE里有这样一个数据，大概75%的故障都是因为人为操作、人为变更引起的，因此人的因素也需要重点关注。在故障管理这块美图有自己的一套体系，流程体系上将故障分与OKR结合来进行。

2.1 通过故障预算管控系统故障

简单说一下故障预算，这个概念来自于Google SRE，美图在这块有一套自己的体系规则，具体的实践叫故障分，包括故障定级规则(见前文)、计分标准。每个周期之初我们年度或者半年度会有一个故障分的预算，每个部门会被分配一定的故障分配额，当发生了故障就要计分并抵扣配额，最后根据故障分的余额进行周期考核。如果业务线、产品的故障分(错误预算)扣完了，那产品发布迭代的节奏、稳定性建设相关的投入就需要有一些干预措施了。

2.2 管理需要组织来支撑

组织支撑是比较重要的，企业庞大部门繁多，如果部门之间的目标不能达成一致，那故障管理将很难推行。美图是有故障管理委员会的，每个BU也有接口人，当故障发生了就根据故障判定的准则去做故障定级、定责接着将故障分拆分到对应的部门。故障的预算制定和考核会与部门的OKR绑定，用这样行政手段来保障我们整个故障体系的正常运行。

写在最后的话

“稳定是偶然，异常才是常态”，只要你身处在IT行业，不管你是研发、测试、运维，或是其他什么岗位，故障始终都是一个你“避之唯恐不及”却怎也无法彻底摆脱的梦魇。故障本质上是系统稳定性被挑战和持续迭代优化的过程，只有理解故障发生的规律、掌握故障管理的方法，做好复盘和改进，持续归纳总结和反思，才能做好对故障的管理，才能更好地建设和保障系统的稳定性——既然无法彻底摆脱它，那就理解它、掌控它。

回复【8201】关键词获取讲师PPT

回复【交流】进入读者交流群

【查看原文】直达精彩演讲回放

声明：本文由公众号「TakinTalks稳定性社区」联合社区专家共同原创撰写，如需转载，请后台回复“转载”获得授权。

关注公众号

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

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

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

漏洞描述

PHPCMS是一套基于PHP和Mysql架构的网站内容管理系统。该系统包括新闻、图片、下载、信息、产品等模块。

phpcms 上述版本中存在信息泄露漏洞http：//sebug.net/exploit/5716/，成功攻击可读取任意文件内容。

漏洞名称 NPM 组件包 @sdh100shaun/iptracker 存在获取主机敏感信息危害漏洞类型内嵌恶意代码发现时间 2022-10-11 漏洞影响广度小 MPS编号 MPS-2022-59700 CVE编号 – CNVD编号 –

影响范围

@sdh100shaun/iptracker@[0.0.2, 0.0.2]

修复方案

避免使用受影响的组件包。

参考链接

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

情报订阅

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

具体订阅方式详见：

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

漏洞描述

October 是一个基于 Laravel PHP 框架的自托管内容管理系统（CMS）平台。

October 的受影响版本中存在远程代码执行漏洞。此漏洞仅影响依赖于安全模式限制的安装，安全模式限制通常用于向公众提供对管理面板的访问。可以访问管理面板，并且有权打开“ Editor”的攻击者可以可以绕过安全模(cms.safe_mode)，构造特殊的请求在 CMS 模板中引入恶意 PHP 代码，从而造成远程代码执行。

漏洞名称 October 存在远程代码执行漏洞漏洞类型代码注入发现时间 2022-10-14 漏洞影响广度广 MPS编号 MPS-2022-51458 CVE编号 CVE-2022-35944 CNVD编号 –

影响范围

october/system@(-∞, 2.2.34)

october/system@[3.0.0, 3.0.66)

修复方案

将组件 october/system 升级至 2.2.34 及以上版本

将组件 october/system 升级至 3.0.66 及以上版本

参考链接

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

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

https://github.com/advisories/GHSA-x4q7-m6fp-4v9v

情报订阅

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

具体订阅方式详见：

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

漏洞描述

Linux kernel 是一个免费开源的类Unix系统的内核。

Linux kernel 的受影响版本在解析 multi-BSSID 素时存在释放后使用漏洞，攻击者可利用此漏洞通过注入恶意 WLAN 帧造成拒绝服务或远程代码执行。

漏洞名称 Linux kernel 释放后使用漏洞漏洞类型 UAF 发现时间 2022-10-14 漏洞影响广度一般 MPS编号 MPS-2022-59480 CVE编号 CVE-2022-42719 CNVD编号 –

影响范围

Linux kernel@[5.2, 5.19.15)

修复方案

升级Linux kernel到 5.19.15 或更高版本

参考链接

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

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

https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=ff05d4b45dd89bdac497dcabf57cf771c6

情报订阅

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

具体订阅方式详见：

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

漏洞描述

Linux kernel 是一个免费开源的类Unix系统的内核。

Linux kernel 5.1 到 5.19.14 版本中存在远程代码执行漏洞，原因为在 mac80211 堆栈中的 BSS 处理列表管理时会被本地攻击者通过注入 WLAN 帧来破坏链表，进而执行恶意代码。

漏洞名称 Linux kernel 远程代码执行漏洞漏洞类型代码注入发现时间 2022-10-14 漏洞影响广度一般 MPS编号 MPS-2022-59482 CVE编号 CVE-2022-42721 CNVD编号 –

影响范围

Linux kernel@[5.1, 5.19.15)

修复方案

将组件 Linux kernel 升级至 5.19.15 及以上版本

参考链接

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

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

https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=bccae5878aec911aecc88d6fff7f

情报订阅

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

具体订阅方式详见：

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

以开源软件为基础构建信息系统成为主流趋势，开源软件迭代快、安全开发机制欠缺、维护人员不足等现状，导致全球开源安全事件频发，威胁着使用者信息安全，也带来了隐私信息泄露的风险。因此，开源安全风险已成为全球化挑战，是开源项目首要关注的风险点。

而要降低开源风险，保障开源安全，就要求开源社区必须做好开源的安全机制。为此，openKylin社区推出了“可控开源”体系，为开源安全保驾护航。

什么是“可控开源”？

“可控开源”是指在确保开源代码安全的基础上，使用户和开发者能够安全、持续、稳定的使用开源社区软件及开源软件涉及的支持性服务。

“可控开源”的特性

“可控开源”体系从代码的来源、设计、使用、创新和发展五个重要环节，围绕代码流通的全链路进行安全管理。

1. 来源可控

对于引入的开源组件，通过合规检查、安全漏洞扫描、静态代码分析、动态代码分析等技术手段，确保引入openKylin社区的开源组件代码来源清晰、透明、安全。

2. 设计可控

成立安全委员会，通过建立安全基线、规范开源组件选型、对系统架构可信威胁建模分析等技术手段，保证openKylin社区开源软件可信受保护、安全可隔离。

3. 使用可控

提供协议一致性检查工具、漏洞检测修复和软件更新等机制，避免openKylin开源软件使用过程中出现法律和知识产权风险，保障开源软件运行环境、升级维护的安全。

4. 创新可控

提供降低贡献者门槛的措施，吸引贡献者参与，并不断优化贡献者参与机制和激励措施。孵化出UKUI、RISC-V、Virtualization等明星SIG组，已具备软件核心模块自主研发、核心模块替换、定制优化、持续对上游社区的代码维护贡献的能力。openKylin开源社区创新能力已达到可控要求。

5. 发展可控

提供自主研发的基础设施平台和以技术委员会+SIG组主导版本、关键技术路线的机制，有效保障openKylin开源软件发展演进的安全。

“可控开源”当前进展

目前openKylin“可控开源”安全体系正在积极推进针对开源合规、漏洞应急响应和漏洞管理平台的建设，面向多场景为社区的安全保驾护航，及时规避可能存在的安全隐患，具体情况如下：

开放麒麟门禁系统：是由Infrastructure SIG组建设的开源合规检测平台。平台涵盖了开源选型可靠性、稳定性、安全性及开源协议风险性检测，致力于保障引入的开源组件来源清晰、安全透明。

开放麒麟安全应急响应中心：由SecurityCommittee SIG组建设、广大社区成员共同贡献的开源操作系统安全漏洞发布、响应、处理、发布的平台。平台涵盖了上报漏洞的全生命周期管理，致力于拓宽漏洞发现渠道，增强面对未知信息安全风险的能力。

开放麒麟漏洞管理平台：是SecurityCommittee SIG组为切实履行自身职能，提高漏洞监控与响应修复能力而自主研发的一款漏洞全生命周期监控与管理的服务型平台。

面对日益严峻的开源安全挑战，openKylin作为国内首个桌面操作系统根社区，积极构建开源安全机制和平台，让开发者能安全高效地在openKylin社区平台上开展研发工作。接下来openKylin将持续聚焦“可控开源”体系建设，助推国内开源领域迈向安全创新新阶段。

审核：openKylin

关注公众号

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

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

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

关注公众号

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

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

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

Spring Batch 5.0.0-M8 已发布。

Spring Batch 是一个轻量级且功能全面的批处理框架，使用 Spring 和 Java 编写离线和批处理应用程序，旨在为开发对企业系统日常运行至关重要的批处理应用程序提供支持。

此版本包含两个主要变化：

引入新的默认执行环境序列化格式

在这个里程碑版本中，已升级至支持对 Base64 上下文进行序列化/反序列化。

此外，由或配置的默认已经从更改为。Jackson 依赖项被设置为可选状态。为了使用, 会被添加到 classpath。

增强 SystemCommandTasklet 功能

此版本增强了 SystemCommandTasklet 功能，并做了以下改变：

引入名为的新策略接口，用于从 tasklet 执行中解耦命令执行。该接口的默认实现是，它使用 API 来运行系统命令。该接口还可以被实现为使用任何其他 API 来运行系统命令
运行命令的方法现在支持接受代表命令及其参数的字符串数组，开发者不需要再对命令进行标记或做任何预处理。此项变化使 API 更加直观，而且不容易出错

详情查看 release note。

Bitwarden 是一款开源的密码管理服务，使用者可在加密的保管库中储存敏感信息。Bitwarden 平台提供有多种客户端应用程式，包括 Web 版本、桌面应用，浏览器扩展、移动端应用和 CLI 版本等。

日前 Bitwarden 更新了 Desktop、Browser Extension、CLI 和 Web 版本，带来了以下多项更新内容：

浏览器

添加 DuckDuckGo 到转发的电子邮件提供商列表中
修正条目名称过长时不显示共享图标的问题
修正了解锁 Chrome 浏览器扩展时键盘输入滞后的问题
让所有项目字段（除了链接字段）都可以拖动
不要阻止链接/按钮中的空白包装，拓宽桌面页面
让所有项目字段（除了链接字段）都可以拖动
不要阻止链接/按钮中的空白 wrapping，拓宽桌面页面
修正错别字：”salted hashtag” 改为 “salted hashing”。

CLI

修复CLI Snap权限

桌面

DuckDuckGo 浏览器集成
添加 DuckDuckGo 到转发的电子邮件供应商列表中
更新了丢失主密码的错误信息
启用阿拉伯语支持
让所有项目字段（除了链接字段）都可以拖动
不要阻止链接/按钮中的空白 wrapping，拓宽桌面页面
修正错别字：将 “salted hashtag “改为 “salted hashing

Web

添加 DuckDuckGo 到转发的电子邮件供应商列表中
不要阻止链接/按钮中的空白 wrapping，拓宽桌面页面
将模态标题改为，编辑样式以匹配桌面

更多详情可查看：https://github.com/bitwarden/clients/releases

Apache Tomcat 10.1.1 现已发布，此版本实现了作为 Jakarta EE 9 平台一部分的规范。

在 Tomcat 9 和更早版本上运行的应用程序，如果不做修改，将无法在 Tomcat 10 上运行。为 Tomcat 9 和更早版本设计的基于 Java EE 的应用程序可以放在目录下，Tomcat 会自动将其转换为 Jakarta EE 并复制到 webapps 目录。此转换是通过 Apache Tomcat 的 Jakarta EE 迁移工具进行的，此工具也可以单独下载，以供离线使用。

此版本中一些值得关注的变化有：

修复 bug 66277，一个重构回归，破坏了 JSP 包括其他功能
修复使用 HTTP/2 和 NIO2 时可能显示为 client disconnections 的意外超时
强制执行 RFC 7230 的要求，即始终应以 400 响应拒绝具有格式错误的 content-length header 的请求。

完整详细信息可查看 Tomcat 10.1 changelog。

下载

SQLAlchemy 2.0.0 首个 Beta 版本已发布。SQLAlchemy 是一个 Python 的 SQL 工具包以及数据库对象映射 (ORM) 框架。它包含整套企业级持久化模式，专门用于高效和高性能的数据库访问。

发布公告写道，2.0 旨在适应现代化 Python 的实际使用，开发团队花费了三年多的时间来升级 SQLAlchemy 用例模型和架构。他们表示，自 2006 年 SQLAlchemy 发布第一个版本以来出现了三个主要的 Python 范式：Python 3、pep-484 类型支持和 asyncio。此次 SQLAlchemy 的 2.0 更新正是为了适应 Python 社区的不断变化。而且与 16 年前相比，Python 社区的规模变得更大，拥有更多新的开发者，他们对严格性、易用性，以及在文档方面有更高的标准。

SQLAlchemy 1.4 系列就已对内部架构进行了变更，包括在 ORM 中集成核心 SQL 结构、完整的 SQL 缓存支持和异步支持，SQLAlchemy 2.0 系列则在许多方面利用了这种架构，主要包括：

完整的 pep-484 类型支持，以及与 mypy、pylance 等类型工具的原生兼容性，包括基于注释的声明模型和完全类型化的 SQL 语句（确保卸载所有 sqlalchemy-stubs、 sqlalchemy2-stubs 包）
在 ORM 中提供性能更高的 INSERT
提供性能更高的表反射架构
集成 SELECT、INSERT、UPDATE、DELETE 语句，包括对象的返回、常规 ORM 使用中的 upsert

SQLAlchemy 2.0 还完成了 1.4 中首次引入的大量 API 变更。尽管 SQLAlchemy 1.4 提供了一个非常全面的升级路径，但预计在本系列的初始版本会有很多问题，尤其是声明式的注释支持。开发团队计划在 Beta 阶段完成大量测试，预计几个月后发布 2.0 正式版。

详情查看新功能介绍。

更新日志 | 下载地址

VS Code 1.72.1 、1.72.2 已发布，这是 1.72 版本的修复更新，解决了该版本的一些安全问题和 bug 。

1.72.1 解决了一些安全和漏洞：

检查根目录时，规范化 webview 资源 #

VS Code 1.71 及更早版本中存在信息泄露漏洞。如果攻击者能够在 webview 中运行任意脚本（由扩展程序或核心 VS Code 创建），则攻击者可以绕过本地资源根检查来读取用户系统上的任意文件

在 notebooks 中禁止命令 uris #

VS Code 1.71 及更早版本中存在一个针对恶意 notebooks 的远程执行代码漏洞，这些 notebooks 可以使用命令 uris 来执行任意命令，包括潜在危险的命令。

以 [‘ui’,’workspace’, ‘web’] 类型的格式，在 web 和远程安装的扩展程序显示重新加载按钮 #
提供 vscode 使用的所有依赖项的传递闭包 #

1.72.1 milestone

1.72.2 解决了以下问题：

不在 web 中缓存活动栏图标（url） #
扩展同步功能在 vscode 服务器 web 中不起作用 #
合并编辑器时，使用错误的换行符保存文件 #
解决合并冲突后，禁用提交按钮 #

1.72.2 milestone

关注公众号

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

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

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

Filament 是 Google 开发的轻量级跨平台实时渲染引擎，支持 PBR 材质，可用于开发游戏渲染引擎或构建音视频编辑工程。当开发者需要处理 3D 渲染效果，又不想引入庞大的游戏引擎时，可以考虑使用它（尤其是 Android 平台），因为它特别针对 Android 平台进行了优化。

目前，Filament 发布了 1.28 版本，带来如下变更：

引擎：LiSPSM 成为用户可设置的选项
引擎：获取给定原语的变形目标缓冲区
Java：修复 TransformManager.getChildren()
金属：较新的设备不再限于每种材料 16 个采样器。
gltfio：修复遮挡强度的解释
引擎：minsdk 升级为 21 ，允许使用 OpenGL ES 3.1
Vulkan：修复黑屏问题

更新公告：https://github.com/google/filament/releases/tag/v1.28.0

关注公众号

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

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

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

引言

富媒体是指在即时通信过程中传输的图片、语音、视频、文件等媒体介质的展示方式。

一、背景

客服一站式平台旨在为得物生态内的客服域服务人员提供一站式的服务办公平台。我们有多条业务线，客服在和用户聊天的过程中，有很多场景需要发送富媒体。跟普通的文本传输相比，富媒体可以直观地用户了解到消息内容，但是在传输过程中也面临着文件大、内存消耗大、传输过程漫长等问题。

二、面临的挑战

客服发送大文件(视频、图片)等消息给用户的大致流程如下：

首先通过文件上传服务上传到CDN，同时返回对应的CDN地址链接；
其次是获取到CDN地址链接，通过IM网关将链接返回给用户界面渲染。

在整个传输过程中，前端必须等文件上传成功拿到链接之后，才能渲染，如果传输的文件很大，客服需要会等待很长时间，这对于客服的接线效率有非常大的影响。比较理想的方式是当客服发送文件的时候，文件立马在聊天窗口渲染，此时渲染的不是完整的文件，而是文件的画像，比如文件的名字、封面图片，通过消息的状态进行上传状态的控制。

以视频传输为例，如果直接把视频放在缓存中展示在客服聊天内容区域，庞大的缓存会让用户的浏览器分分钟崩溃。比如大于70M的视频，在网络，电脑硬件等环境都较好的情况下，从读取文件到获取到首帧图片传输的过程大概需要2~3s，如果在网络一般，同一环境下有多人在发送视频文件，或者硬件设备一般的情况下时间会更长。

如何在不影响客服接线效率的情况下，还能让大文件的传输做到如丝般顺滑呢？

三、解决方案与成效

1、将fileReader.target.result作为视频的url在页面渲染

最初使用的方式是在视频上传CDN时，同时截取视频首帧，然后将截取的视频首帧也上传到CDN，再通过长链（wss）发送给客户端，因为截取首帧是一个同步的过程，需要拿到screenshot的url之后才能渲染到页面，导致客服在发送的第一时间在聊天界面看不到发送出去的视频，如上图视频所示，客服无法感知到视频发送的进度。

通过FileReader读取文件信息：

通过返回的文件信息进行属性设置：

如上代码 video.setAttribute(‘src’, target)，如果用target作为视频的url在页面渲染，页面会分分钟崩溃。可以看一下1M的视频文件，通过readAsDataURL(file)读取文件内容得到是一个data:url的base64字符串，用这个字符串进行渲染，等于在页面加了一个1.4M的字符串内容，如下图所示，这样做的后果不可想象，在文件稍微大一些的话会有更加明显的卡顿。

所以这个方案在开发之初就被否定了。

2、采用的URL.createObjectURL(file) 获取到URL

在第一种方案被否定之后，又调研了URL.createObjectURL的实现。采用的URL.createObjectURL(file) 获取到URL(这个URL对象表示指定的 File 对象或 Blob 对象)，然后放到聊天数据的缓存中，便于快速发送到客服聊天窗口页面。其主要实现代码如下：

经过这个改造很明显的看到视频发出之后，可以很快的展示在页面上，让客服感知到视频发送的状态和进度，相对于方案一，视频发送的过程有明显的提升。渲染出来的代码效果如下图所示：

但是！

在给客户端发送视频信息时，要携带首帧和视频时长，作为展示封面，历史的做法是：

首先前端获取文件信息后通过canvas转换成图片再上传到CDN；
在获取到首帧和文件信息之后，先上传到CDN，返回URL后再通过长链发送给用户，同时更新页面的URL地址为CDN返回的真实地址。

取首帧时要读取文件，既然是读取文件，还是存在一定的耗时，如下代码片段所示，这段耗时任务也会影响到客服的使用体验。

上传视频的时候，文件服务器提供了获取首帧的方式拿到首帧图片，在链接地址上拼接对应的参数即可，如下所示：

但在实际的使用场景中，只获取视频首帧信息是不够的，还要获取视频的宽高、播放时长等信息，并且通过网络请求发送给网关，最终在客户端展示。读取文件这个过程无法避免，耗时问题还需要解决。

3、Web Worker异步读取文件信息

通过方案二虽然实现了文件的快速渲染，但读取文件信息如果在浏览器的主线程去做，耗时长的话，还是会阻碍客服的操作。如果这个过程能通过异步去实现，那就很完美了。JS虽然是单线程，但是浏览器提供了Web Worker的能力，让JS也能通过异步的方式和主线程进行通信。首先对比下浏览器主线程执行和主子线程执行的区别，如下图所示：

浏览器主线程在执行发送文件的时候，如果发送文件任务没有结束，则会阻塞其他的任务，相当于发送期间，客服什么事情也做不了；
浏览器主子线程在执行发送文件的时候，通过子线程读取文件，在读取文件期间，主线程可以继续执行其他的任务，等到子线程读取完文件通过postMessage发送相关的信息告知主线程文件读取完毕，主线程再开始渲染。整个过程对于客服没有任何阻塞。

Web Worker主子线程实现的流程如下：

首先在线程订阅中心创建子线程任务，如下：

然后在线程订阅中心初始化Worker，如下：

最后在主线程里面调用Worker获取文件信息，如下：

通过上面的三个步骤，基本就可以在不影响客服操作的情况下获取到文件信息。获取到视频信息对象之后，再通过URL.createObjectURL(file)即可获取到视频相关的属性信息，如下：

如上所述，在获取文件对象信息之后，再通过blob的方式直接获取视频的宽高作为第一帧图片的宽高，二者结合即达到了在不影响客服操作的情况下，让视频发送做到了如丝般顺滑。

通过Web Worker+URL.createObjectURL(file)的方式，解决了富媒体文件发送时，不管有没有发送成功，都可以实现秒发的效果，即让视频信息先展示到聊天框，再通过发送状态来标识当前的发送进度。

四、总结

富媒体发送在很多IM场景中均会涉及到，用什么样的技术实现能够让客服和用户之间沟通和交流更便捷是本文阐述的重点。通过在实际客服业务场景中的实践，本文的技术方案已经很好的解决了业务中的问题并且实际线上也一直比较稳定的在运行。从业务中发现问题，用技术手段解决问题，提升客服的解决效率，给用户带来好的体验是我们不断追求的目标，如果看了本文之后，你有更好的建议可以给我们留言。此外客服领域的技术点远不止这些，脚踏实地，一步一个脚印，相信即时通讯在客服领域的沉淀会越来越好。

五、知识扩展

1、文件读取的实现差异

URL.createObjectURL() 和FileReader.readAsDataURL(file)都可以取到文件的信息，为什么我们选择使用前者而非后者?

两者的主要区别在于：

通过FileReader.readAsDataURL(file)获取到的是一段data:base64的字符串，base64位的字符串较大
通过URL.createObjectURL(blob)获会创建一个DOMString，其中有包含了文件信息的URL(指定的 File 对象或 Blob 对象)

执行的时机的不同：

createObjectURL是立即的执行
FileReader.readAsDataURL是（过一段时间）异步执行

内存的使用不同：

createObjectURL返回一段带hash的url，并且一直存储在内存中，当document被触发了unload或者执行revokeObjectURL进行内存释放；

FileReader.readAsDataURL返回的是base64的字符串，比blob url消耗更多的内存，不过这个数据会通过垃圾回收机制自动清除。

使用选择：

用createObjectURL能够节省性能，获取的速度也更快；
如果设备性能足够好，而且想要获取图片的base64，可以用FileReader.readAsDataURL。

2、流媒体、富媒体、多媒体的概念

流媒体、富媒体、多媒体到底有什么区别?

流媒体：一边使用，后台一边下载后面可能要使用到的东西。

富媒体：文字、图片、视频、音频混排的页面内容。
多媒体：图片、文字、音频、视频等资料。

其中流媒体是一种传输方式，富媒体是不同于纯文本的一种展示方式，多媒体是展示内容的一种手段。

*文/Jun

关注得物技术，每周一三五晚18:30更新技术干货
要是觉得文章对你有帮助的话，欢迎评论转发点赞～

关注公众号

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

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

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

Rainbond创始人刘凡在公司成立前，可谓是不折不扣的技术男，一面是对技术的痴迷和钻研，一面是对社交的排斥和恐慌。

面对企业的困境，刘凡不得不从后台走到前台直接面对客户。

公司及产品简介：

本文来源于开源集《开源观止》第 4 期，更多精彩内容，请下载：

https://oscimg.oschina.net/public_shard/opensource-guanzhi-.pdf

虽然早在 Linux 5.19 就已合并龙芯 LoongArch CPU 架构，但初步支持阶段的功能非常有限，甚至缺少一些关键的设备驱动程序 —— 所以当时 Linux 5.19 暂未支持在搭载 LoongArch CPU 的设备上启动。正式从这时开始，龙芯团队也一直在积极为 Linux 内核能够合并他们的代码到主线而继续努力。

在不久前发布的 Linux 6 中，龙芯团队为内核添加了 LoongArch PCI 支持和其它变化。现在，尚处于合并窗口开启阶段的 Linux 6.1 继续为 LoongArch 架构提供更多支持，比如此前合并的 LoongArch EFI Boot，该特性能够为将来使用 EFI 代码提供机密计算支持做准备。

近日合并的代码则涉及到了 LongArch CPU 的移植更新，带来了更多的 CPU 特性。

此次开发周期还包括重构 TLB/缓存操作、支持 qspinlock、支持 perf 事件、处理 Kexec 和 Kdump、面向架构实现的通用 BUG() 处理实现、支持 eBPF JIT、基于 ACPI 的笔记本电脑驱动程序，以及对默认内核配置 (defconfig) 的更新。点此查看完整内容。

上周，我们报道了 Ubuntu 向个人及小型企业用户推出了免费的 Ubuntu Pro，并允许用户在最多 5 台设备上安装，此举可以为 Ubuntu 用户提供更好的安全性，最长可达 10 年。

但近日有用户发现，Canonical 似乎在不遗余力地推广 Ubuntu Pro。现在当你在命令行用 apt 命令更新时，你会在命令行中发现下图这样的信息，其中就包含 Ubuntu Pro 的广告，而这引起了用户的反感。

通过 Ubuntu Pro 接收额外的未来安全更新。了解更多关于 Ubuntu Pro 的信息，请访问 https://ubuntu.com/pro

在最多 5 台设备上免费订阅 Ubuntu Pro 测试版。了解更多信息，请访问 https://ubuntu.com/pro

目前在 Reddit、Mastodon 以及 AskUbuntu 等网站和论坛上都有针对这一问题的投诉，开发者一致认为这些信息干扰了他们正常的工作流程，并准备考虑更换其他操作系统。不过这也不是 Ubuntu 第一次在系统中内置广告了。

此前，在 Ubunu 20.04 LTS 的软件和更新应用程序中，就有用户发现了 Ubuntu Pro 的推广信息（当时还没有免费计划）。

当时没有引发太多不满情绪的原因在于，首先这个广告展示的层级比较深，用户必须打开软件和更新应用并 Livepatch 标签才能看到它；其次对用户来说，这个窗口也不会经常打开，看到的频次也比较低。

而此次展示广告的位置就让开发者非常难受了，终端可以说是开发者无时无刻不在使用的工具，在里面展示广告就意味着每天都会看到这样的信息，对开发者而言，他们更了解系统，知道自己的需求，展示这样的信息也并不一定能让他们切换到 Ubuntu Pro。

其实这里面还有一个问题，那就是 Ubuntu 22.04 LTS 系统目前可以获得更新直到 2027 年，虽然 Ubuntu Pro 具有更长的更新周期，但在 22.04 LTS 距离生命周期结束还很久远的时候就展示扩展支持似乎也有点为时过早（在 EOL 即将来临时再显示，似乎是一个更加合理的选择）。

如果你是一位使用 Ubuntu 足够久的开发者，那你可能记得 Ubuntu 还有过曾将亚马逊的购物建议放进系统搜索结果中的 “黑历史”。那么你又是如何看待 Ubuntu 在终端中展示推广信息一事的呢？

Debian 开发者团队在邮件列表宣布 Debian 12 “Bookworm” 即将到达第一个里程碑：工具链冻结期，开发者需为此做好准备，避免上传大型破坏性变化。

除了提醒开发者为即将到来的 Debian 12 做好测试和修复 Bug 的准备外，邮件列表的通知还公布了已确认的 Debian 14 代号“Forky”，跟以往一样，Debian 系统代号通常来自《玩具总动员》的角色名，这次是这根叉子：

另外，Debian 13 使用名为 “Trixie” 的代号，它是蓝色的塑料玩具恐龙，最早出现在《玩具总动员 3》。

Debian 12 “Bookworm” 预计在 2023 年发布，Debian 13 将在 2025 年左右发布，Debian 14 Forky 则预计在 2027 年发布。

在 LLVM Clang 被越来越多地开发人员和组织用于构建主线 Linux 内核的同时，大家似乎忘记了，作为对长期以来占主导地位的 GCC 编译器目标的补充支持，英特尔的 ICC 编译器也能够用于构建 Linux 内核（尽管没有被广泛使用）。鉴于此，内核开发人员现在正在考虑删除对 ICC 编译器的支持。

Linux 开发人员 Masahiro Yamada 提出了放弃英特尔 ICC 编译器支持的想法。他在邮件中指出：

include/linux/compiler-intel.h 在过去 3 年没有更新。

我们经常忘记构建内核的第三个 C 编译器。

例如，commit a0a12c3ed057 (“asm goto: eradicate CC_HAS_ASM_GOTO”) 只提到了 GCC 和 Clang。

init/Kconfig 定义了 CC_IS_GCC 和 CC_IS_CLANG 但没有定义 CC_IS_ICC，却没有人报告任何问题。

我猜对英特尔编译器的支持已经 broken，而且没有人关心它。

对此，Linus Torvalds 做出了回应并支持称：

Ack，我认为没有人真正使用过 icc。

我不记得曾听到过关于 icc 问题的任何消息，我不认为这是因为它在 emulating gcc 方面“特别”好，所以没有人遇到过任何问题。

此外，其他内核开发人员也表达了对这一提议的支持。Phoronix 指出，这个拟议的补丁将致使放弃对主线内核的 ICC 支持，并释放目前用于 ICC 支持的大约 300 行代码。值得一提的是，随着英特尔的 ICC 编译器从原来的专有代码库转向基于 LLVM 的模式，新的 ICC 编译器最终可能会使用 Clang 路径构建内核。

更多详情可查看邮件列表。

版本名称说明地址 JavaWeb 混编专业版采用 SpringBoot2+Thymeleaf+layui https://gitee.com/javaweb520/JavaWeb JavaWeb_Pro 混编旗舰版采用 SpringBoot2+Thymeleaf+layui https://gitee.com/javaweb520/JavaWeb_Pro JavaWeb_Vue 专业版前后端分离版，采用 SpringBoot2+Vue+ElementUI https://gitee.com/javaweb520/JavaWeb_Vue JavaWeb_Vue_Pro 旗舰版采用 SpringBoot2+Vue+ElementUI https://gitee.com/javaweb520/JavaWeb_Vue_Pro JavaWeb_Ant_Pro 旗舰版采用 SpringBoot2+Vue+AntDesign https://gitee.com/javaweb520/JavaWeb_Ant_Pro JavaWeb_Cloud 微服务专业版采用 SpringCloud+Vue+ElementUI https://gitee.com/javaweb520/JavaWeb_Cloud JavaWeb_Cloud_Pro 微服务旗舰版采用 SpringCloud+Vue+ElementUI https://gitee.com/javaweb520/JavaWeb_Cloud_Pro JavaWeb_Cloud_Ant 微服务旗舰版采用 SpringCloud+Vue+AntDesign https://gitee.com/javaweb520/JavaWeb_Cloud_Ant

更新内容：

[新增] datePicker 组件 type 属性为 date 与 datetime 时, 支持时间戳传入。
[新增] menu 组件 ident 属性, 用于开启目录缩进与缩进尺寸。
[新增] table 组件 column 配置 total-row-method 属性, 用于自定义列统计逻辑。
[修复] upload 组件 drag 为 false 时的 removeEventListener 警告。
[修复] upload 组件销毁 drap drapenter dragover 事件未注销。
[修复] menu 组件 ident 属性带来的 typescript 警告。
[修复] tansfer 组件 data-source 属性缺少响应式的特性。
[修复] upload 组件 drag 属性开启后, 拖拽上传无效的问题。
[修复] table 组件 column 配置 fixed 属性, 特殊情况下的列空白问题。
[修复] talle 组件 table-row 行 algin 等属性, 不跟随 column 列配置的问题。
[修复] table 组件 table-row 行 fixed 属性不生效的问题。
[修复] datePicker 组件 type 属性为 dateTime 时同时选择日期与时间不生效问题。
[修复] datepicker 组件 type 属性为 mouth 时, v-model 为 number 类型时, 月份选择显示NaN。
[修复] tree 组件 checkedKeys 属性赋值默认子集全部选中的问题。
[修复] layer 组件在高版本 google 中的 event.path 警告信息。
[修复] select-option 组件 default 插槽不可用的问题。
[优化] switch 组件 on-switch-text 和 un-switch-text 属性, 为描述提供适当边距。
[优化] config-provider 组件 dark-partial 属性默认值, 降低整体饱和度。

更多详情：http://www.layui-vue.com

漏洞描述

grunt-karma 是一款 karma 测试运行器的 grunt 插件。

grunt-karma 的受影响版本中的 grunt-karma.js 中存在原型污染漏洞，攻击者可利用此漏洞更改JavaScript原型Dom属性，从而造成拒绝服务或远程代码执行。

漏洞名称 grunt-karma v4.0.1 原型污染漏洞漏洞类型原型污染发现时间 2022-10-15 漏洞影响广度极小 MPS编号 MPS-2022-53515 CVE编号 CVE-2022-37602 CNVD编号 –

影响范围

grunt-karma@[4.0.1, 4.0.2)

修复方案

将组件 grunt-karma 升级至 4.0.2 及以上版本

参考链接

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

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

https://github.com/karma-runner/grunt-karma/issues/311

情报订阅

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

具体订阅方式详见：

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

漏洞描述

rdiffweb 是一个提供 Web 界面的备份管理软件。

rdiffweb 在2.5.0之前的版本中存在无限制的资源分配漏洞，由于对未经身份验证的连接没有适当的限制，攻击者可利用此漏洞通过发送大量恶意请求造成rdiffweb服务的资源过度分配，甚至造成拒绝服务。

漏洞名称 rdiffweb <2.5.0 无限制的资源分配漏洞漏洞类型不加限制或调节的资源分配发现时间 2022-10-15 漏洞影响广度极小 MPS编号 MPS-2022-59501 CVE编号 CVE-2022-3439 CNVD编号 –

影响范围

rdiffweb@(-∞, 2.5.0)

修复方案

将组件 rdiffweb 升级至 2.5.0 及以上版本

参考链接

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

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

https://github.com/ikus060/rdiffweb/commit/b78ec09f4582e363f6f449df6fe126c311

情报订阅

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

具体订阅方式详见：

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

漏洞描述

Vim 是老式 UNIX 编辑器 Vi的一个改进的版本。

Vim 在9.0.0404之前的版本中 “vim/src/regexp.c” 中的vim_regcomp()函数存在NULL 指针取消引用漏洞。攻击者可利用此漏洞造成拒绝服务或恶意代码执行。

漏洞名称 vim/vim <9.0.0404 NULL指针取消引用漏洞漏洞类型空指针解引用发现时间 2022-10-15 漏洞影响广度一般 MPS编号 MPS-2022-56902 CVE编号 CVE-2022-3153 CNVD编号 –

影响范围

vim-doc@(-∞, 2:9.0.0626-1)

vim-runtime@(-∞, 2:9.0.0626-1)

vim-tiny@(-∞, 2:9.0.0626-1)

vim-motif@(-∞, 2:9.0.0626-1)

vim@(-∞, 2:9.0.0626-1)

vim-gtk3@(-∞, 2:9.0.0626-1)

vim-common@(-∞, 2:9.0.0626-1)

vim-gui-common@(-∞, 2:9.0.0626-1)

vim-athena@(-∞, 2:9.0.0626-1)

vim-nox@(-∞, 2:9.0.0626-1)

xxd@(-∞, 2:9.0.0626-1)

vim-common@(-∞, 2:9.0.0626-1)

vim-gui-common@(-∞, 2:9.0.0626-1)

xxd@(-∞, 2:9.0.0626-1)

vim-gtk3@(-∞, 2:9.0.0626-1)

vim-nox@(-∞, 2:9.0.0626-1)

vim-doc@(-∞, 2:9.0.0626-1)

vim@(-∞, 2:9.0.0626-1)

vim-tiny@(-∞, 2:9.0.0626-1)

vim-athena@(-∞, 2:9.0.0626-1)

vim-motif@(-∞, 2:9.0.0626-1)

vim-runtime@(-∞, 2:9.0.0626-1)

vim-doc@(-∞, 9.0.0626-1)

vim@(-∞, 9.0.0626-1)

vim-nox@(-∞, 9.0.0626-1)

vim-athena@(-∞, 9.0.0626-1)

vim-tiny@(-∞, 9.0.0626-1)

xxd@(-∞, 9.0.0626-1)

vim-common@(-∞, 9.0.0626-1)

vim-gui-common@(-∞, 9.0.0626-1)

vim-runtime@(-∞, 9.0.0626-1)

vim-motif@(-∞, 9.0.0626-1)

vim-gtk3@(-∞, 9.0.0626-1)

vim/vim@(-∞, 9.0.0404)

修复方案

将组件 vim/vim 升级至 9.0.0404 及以上版本

将组件 vim-doc 升级至 2:9.0.0626-1 及以上版本

将组件 vim 升级至 2:9.0.0626-1 及以上版本

将组件 vim-gui-common 升级至 2:9.0.0626-1 及以上版本

将组件 vim-gtk3 升级至 2:9.0.0626-1 及以上版本

将组件 vim-common 升级至 2:9.0.0626-1 及以上版本

将组件 vim-athena 升级至 2:9.0.0626-1 及以上版本

将组件 vim-nox 升级至 2:9.0.0626-1 及以上版本

将组件 xxd 升级至 2:9.0.0626-1 及以上版本

将组件 vim-runtime 升级至 2:9.0.0626-1 及以上版本

将组件 vim-tiny 升级至 2:9.0.0626-1 及以上版本

将组件 vim-motif 升级至 2:9.0.0626-1 及以上版本

参考链接

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

https://huntr.dev/bounties/-620d-48bc-a8fa-cd947b26270a

https://github.com/vim/vim/commit/1540d334a04d874c2aa9d26b82dbbcd4bc5a78de

情报订阅

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

具体订阅方式详见：

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

漏洞描述

pdfkit 是一个使用wkhtmltopdf将HTML转化为PDF的工具。

pdfkit 在0.8.7之前的版本中由于对 URL 未正确清理从而存在命令注入漏洞。攻击者可利用此漏洞通过构造恶意url参数进行命令注入，从而进行任意代码执行。

漏洞名称 pdfkit <0.8.7 存在命令注入漏洞漏洞类型命令注入发现时间 2022-09-09 漏洞影响广度极小 MPS编号 MPS-2022-5124 CVE编号 CVE-2022-25765 CNVD编号 –

影响范围

pdfkit@[0.0.0, +∞)

修复方案

参考链接

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

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

https://github.com/pdfkit/pdfkit/blob/46cdf53ec540da1a1a2e4da979e3e5fe2f92a257/lib/pdfkit/pdfkit.rb%23L55-L58

情报订阅

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

具体订阅方式详见：

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

漏洞描述

rdiffweb 是一个提供 Web 界面的备份管理软件。

Rdiffweb 2.4.1之前的版本由于对渲染 UI 层限制不当从而存在劫持漏洞。攻击者可利用此漏洞将易受攻击的站点嵌入到自己网站的透明 iframe 中，通过诱导用户看似正常的网站页面从而造成劫持攻击，导致用户在恶意网站上执行各种意外操作。

漏洞名称 rdiffweb <2.4.1 存在劫持漏洞漏洞类型渲染 UI 层或帧的不当限制发现时间 2022-10-15 漏洞影响广度极小 MPS编号 MPS-2022-56448 CVE编号 CVE-2022-3167 CNVD编号 –

影响范围

rdiffweb@(-∞, 2.4.1)

修复方案

升级rdiffweb到 2.4.1 或更高版本

参考链接

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

https://huntr.dev/bounties/e5c2625b-34cc-4805-8223-80f2689e4e5c

https://github.com/ikus060/rdiffweb/commit/7294bbc93dec1b428

情报订阅

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

具体订阅方式详见：

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

openKylin社区将于北京时间10月14日晚21:00至10月17日早8:00进行服务器升级维护，届时社区官网、论坛、系统源等均暂停访问，

期间，如需下载openKylin开源操作系统请访问以下网址：

https://mirror.lzu.edu.cn/openkylin-cdimage
https://mirrors.nju.edu.cn/openkylin-cdimage
https://sigusoft.com/s/1KLS1E2wkIHHj5lxrYoVXZg?pwd=c7ph

如需反馈社区相关问题，欢迎您前往openKylin仓库提交反馈：

https://gitee.com/openkylin/qa/issues

维护期间给大家带来的不便深感抱歉，感谢大家的支持和配合。

HummerRisk v0.4.0 已经发布，云原生安全检测平台

此版本更新内容包括：

快速开始

仅需两步快速安装 HummerRisk：

准备一台不小于 4 核 8 G 内存的 64位 Linux 主机；
以 root 用户执行如下命令一键安装 HummerRisk。

如果您已经部署旧版本，可通过如下命令一键升级至最新版本:

产品文档

完整文档查看完整的安装和使用文档

更新内容

” 新功能 Features”

feat（云资源态势）：新增云资源态势功能，根据云账号同步云资源，进行资源汇总。
feat（云资源态势）：新增云资源拓扑图功能，根据同步云资源汇总信息，形成拓扑图。
feat（云检测规则组）：新增阿里云最佳实践规则组，新增规则组直接快速检测功能。
feat（云检测规则）：新增 UCloud 、 Aliyun 云检测规则。
feat（云检测结果）：新增云资源检测优化建议功能，根据检测规则跳转优化建议页面。
feat（操作审计）：新增操作审计概览、云事件聚合功能。
feat（源码检测）：新增源码概览、源码检测历史记录、历史检测数据对比、下载检测报告功能。
feat（部署检测）：新增部署概览、部署检测历史记录、历史检测数据对比、下载检测报告功能。
feat（镜像检测）：新增镜像概览、镜像检测历史记录、历史检测数据对比、下载检测报告功能。
feat（主机检测）：新增主机概览、主机检测历史记录、历史检测数据对比功能。
feat（K8s 检测）：新增 K8s 概览、K8s 检测历史记录、历史检测数据对比、下载检测报告功能。
feat（K8s 资源态势）：新增 K8s 资源拓扑图功能，根据同步 K8s 资源汇总信息，形成拓扑图。
feat（HummerRisk 安装）：新增 K8s 安装部署 HummerRisk。

” 性能优化 Optimization”

refactor（多云检测）：优化云账号一键检测，提升检测效率与检测速度。
refactor（版本升级）：升级 pom 依赖包版本，升级 spring-boot 和 jdk 等版本。
refactor（检测规则组）：优化规则组展示顺序与样式。
refactor（主机检测）：优化主机检测规则，维护有状态检测结果。
refactor（站内消息）：站内消息通知，添加k8s、镜像、源码检测等类型。
refactor（树结构）：优化所有页面树结构展示样式与数据结构。
refactor（i18n）：优化前后端数据翻译展示。

” Bug修复 Bug Fixes”

fix（主机检测）：修复主机检测只有密码时报错不了的问题。
fix（主机检测）：解决 server 主机凭证数据没有及时刷新，选择不到的问题。
fix（源码检测）：解决源码检测，连接 github 仓库时，无法自己修改分支名称。
fix（sbom分析）：解决 sbom 分析里，镜像检测结果详情显示字段不正确的问题。
fix（sbom 分析）：修复 sbom 列表字段展示问题。
fix（云资源检测）：解决分组检测重复检测的问题。
fix（漏洞检测）：修改国家信息安全漏洞库网址(旧址换新址)。
fix（漏洞检测）：修复漏洞检测概览数据显示不正确的问题，解决漏洞检测报错的问题。

离线安装包

百度网盘下载链接: https://sigusoft.com/s/1LeDx5hF_RkkpO8HcsYUDAQ 提取码: 4ljt 网站资源下载链接: https://docs.hummerrisk.com/about/download/

详情查看：https://gitee.com/hummercloud/HummerRisk/releases/v0.4.0

凹语言第一时间支持JetBrains Fleet 语法高亮！

JetBrains 宣布首次公共预览 Fleet，所有人都可以使用。Fleet 是由 JetBrains 打造的下一代 IDE，于 2021 年首次正式推出。它是一个新的分布式多语言编辑器和 IDE，基于 JetBrains 在后端的 IntelliJ 平台，采用了全新的用户界面和分布式架构从头开始构建。具体可以参考 https://www.oschina.net/news//jetbrains-fleet-public-preview

凹语言™（凹读音 “Wa”）是针对 WASM 平台设计的的通用编程语言，支持 Linux、macOS 和 Windows 等主流操作系统和 Chrome 等浏览器环境，同时也支持作为独立 Shell 脚本和被嵌入脚本模式执行。主页 : https://wa-lang.org

先克隆 fleet-wa
本仓库到本地，然后将
子目录复制到
目录下（具体细节可以参考 TextMate bundles
文档）。然后重启 Fleet，打开 hello.wa
文件，效果如下图：

更多
信息请参考 https://github.com/wa-lang/fleet-wa
。

关注公众号

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

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

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

本周发布了 5 个围绕 Linux WiFi 堆栈的安全漏洞的 CVE，这些漏洞可以利用无线网络通过恶意数据包来作恶。

Linux 内核已发布针对 WiFi 堆栈漏洞的最新修复版本，分别是 Linux 6.0.2 , Linux 5.19.16 , Linux 5.15.74 , Linux 5.10.148，和 Linux 5.4.218，这些版本带有最新的 WiFi 安全修复程序。

5 个围绕 Linux WiFi 堆栈的安全漏洞分别是：

CVE-2022-41674：修复 cfg80211_update_notlisted_nontrans 中的 u8 溢出
CVE-2022-42719：wifi：mac80211：修复 MBSSID 解析 use-after-free
CVE-2022-42720：wifi：cfg80211：修复 BSS 引用计数错误
CVE-2022-42721：wifi：cfg80211：避免未传输的 BSS 列表损坏，列表损坏只会使其无限循环（DOS）
CVE-2022-42722：wifi：mac80211：修复 P2P 设备信标保护中的崩溃，NULL ptr 取消引用崩溃 (DOS)

通过 oss-sec list 可进一步了解 WIFI 安全问题，Linux 6.1 也合并了该系列漏洞的修复补丁。

Wine（Wine Is Not an Emulator）是一个能够在多种兼容 POSIX 接口的操作系统（诸如 Linux、macOS 与 BSD 等）上运行 Windows 应用的兼容层。它不是像虚拟机或者模拟器一样模仿内部的 Windows 逻辑，而是将 Windows API 调用翻译成为动态的 POSIX 调用，免除了性能和其它一些行为的内存占用，让你能够干净地整合 Windows 应用到桌面。

Wine 7.19 已经正式发布，该版本中值得关注的更新内容包括：

支持在磁盘上存储 DOS 属性。
捆绑的 vkd3d 升级到 1.5 版本。
支持 MPEG-4 音频格式。
各种错误修复。
- 多个微软开发工具在线/网络安装程序未能跳过 “$shtdwn$.req” with FILE_ATTRIBUTE_HIDDEN（Visual Studio Express Editions，.NET Framework 3.0）。
- OpenMPT UI 不能正确呈现所有文本框
- AIMP 3 导致内存泄漏
- x64dbg 在打开可执行文件时崩溃了
- 当InfoValue为NULL时，SQLGetInfo(W)不会填充StringLength。
- winetricks dotnet35安装失败

更多详情可查看：https://www.winehq.org/announce/7.19

关注公众号

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

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

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

IntelliJ IDEA 2022.3 EAP 3 现已推出！新的 EAP 版本引入了重新设计的 Settings Sync 解决方案，可无缝同步个人 IDE 设置、一系列新的 Java 检查和其他改进，以及利用新 IntelliJ IDEA Workspace Model API 的实验性 Maven 导入功能。

新的同步设置解决方案

引入了一个重新设计的解决方案来同步自定义用户设置。新的 Settings Sync 插件能够同步来自平台、捆绑插件和第三方插件的所有可共享设置。

默认情况下， Settings Sync 插件本身也将被同步并静默安装。至于第三方插件设置是否可同步，则取决于第三方供应商。

如何启用

一直在使用IDE Settings Sync，则你的数据将自动迁移到新插件，因此您无需执行任何操作。
如果你是Settings Repository用户，建议继续使用当前设置，因为相关的功能迁移仍在进行中。功能准备就绪后，你将在 IDE 中收到通知。
如果你之前没有使用过设置同步解决方案，想尝试新的解决方案，可以通过设置/首选项 | 设置同步 | 启用设置同步。

改进的复制剪切粘贴行为

通过重新设计粘贴操作 ( ⌘V / Ctrl+V ) 行为改进了 IDE 中的编辑体验。

在未选择任何代码的情况下复制（⌘C / Ctrl+C）或剪切（⌘X / Ctrl+X）行时，粘贴操作会将剪贴板的内容添加到当前行的上方，而不是插入符号处。

新的 Java 检查和其他改进

有一个新的检查，可以在每个分支中检测带有公共子表达式的 switch 表达式。快速修复建议将开关移到内部并缩短代码。

另一项新的检查则报告冗余数组长度检查。当唯一的后续语句是遍历数组的 for 循环时，可以删除 if 子句，因为无论如何都会在 for 循环中执行长度检查。

另外，还引入了一项检查，该检查报告字符串文字中 s 的使用情况（文本块位于行尾的情况除外）。此检查附带一个快速修复，建议将 s 替换为空格。

新的检查会报告 Javadoc 和代码之间的不匹配，当用英语编写的方法规范的部分和方法声明不对应时，会产生通知。

在仅使用一个素或字符时，有一项新检查，可检测不必要的数组、列表或字符串创建。快速修复会建议简化内联重构后可能出现的过度构造。

Java 调试器中的增强型数据流分析辅助

改进了Java 调试器中的数据流分析功能。此前，DFA 助手会预测某些表达式的未来值。现在，当分析器可以预测代码的特定分支将不会被执行时，它将使该部分代码变灰。

使用新的 IntelliJ IDEA 工作区模型 API 导入 Maven（实验性）

IntelliJ IDEA 2022.3 EAP 使用新的 IntelliJ Workspace Model API引入实验性 Maven 导入功能，在导入 Maven 项目时将速度提高 10%。

更多详细内容可查看更新公告：https://blog.jetbrains.com/idea/2022/10/intellij-idea-2022-3-eap-3/

在 Ardour 6.9 发布一年多之后，跨平台音频编辑器 Ardour 7.0 现已发布。新版本具有许多新功能，比如首次将“剪辑启动”功能带入 Ardour，以及 MIDI 编辑的许多增强，此版本还增加了 Apple Silicon 系统的官方构建（之前只能通过 nightly build 获得）。

Ardour 开源音频处理套件不仅是 Linux 用户的最佳选择之一，还适用于 macOS 和 Windows。

新的剪辑启动功能

Ardour 剪辑启动功能类似于 Ableton Live、Bitwig、Digital Performer 和其他数字音频软件解决方案提供的工作流程，剪辑启动允许尝试各种循环和单次样本的组合，所有声音适当（但可选）时间拉伸以适合会话的速度图，并开始/停止量化到凹槽。

纹波模式

Ardor 现在有 3 种“波纹编辑”模式。波纹编辑描述了当您从轨道中剪切/删除材料时会发生什么，后来的材料可更早地移动以“填补空白”。

已选纹波：在此模式下，删除片段或时间范围后，所有选定的曲目都会出现波纹。
所有涟漪：在此模式下，所有轨道都会响应范围删除而波动
面试模式：在此模式下，只有选择多个轨道时才会发生波纹。否则 Ardor 将假设你只是从一首曲目中删除诸如“uhm”和“ah”之类的附带噪音。选择将编辑应用于两个/所有轨道时，只需向下移动鼠标即可。该模式在编辑一对一采访/讨论音频时特别有用

此外，该版本还有改进的 MIDI 编辑、恢复 Freesound 集成以及新的主题和翻译更新等大量改进。

通过 Ardour.org 可以了解到更多内容。

全球开源技术峰会（Global Open-source Technology Conference），简称 GOTC，是由 Linux 基金会亚太区、开源中国和开源社区联合发起的，面向全球开发者的一场盛大开源技术盛宴。2021 年首届 GOTC 圆满举办，获得热烈反响。

原定于 2022 年 11 月举办的 GOTC 2022 时间更新为 2023 年 2 月 25、26 日，现在重新出发，诚邀参与共建。

https://gotc2023.oschina.net

GOTC 2023，为期 2 天的开源行业盛会，将通过行业展览、主题发言、特别论坛、圆桌讨论、快闪演讲、大咖会客厅、HR 面对面、开源时空隧道等形式来诠释此次大会主题——“Open Source, Into the Future”。会议聚焦宇宙、3D 与游戏、eBPF、Web3.0、开源治理、开源教育培训、云原生、前端、基础软件、AI、IoT 等热门话题，探讨开源未来，助力开源发展。

大会在线下举办的同时，还将在线上同步直播。

本次大会将邀请 Linux 基金会执行董事 Jim Zemlin、开源中国 CEO 马越、OpenSSF 总经理 Brian Behlendorf、Open 3D 基金会执行董事 Royal O’Brien、LF AI & Data 基金会执行董事 Ibrahim Haddad、Apache 软件基金会董事 Craig Russell、Eclipse 基金会执行董事 Mike Milinkovich、红帽 CTO Chris Wright、VMware 副总裁兼首席开源官 Chip Childers、《大教堂与集市》作者 Eric Steve Raymond、CNCF 总经理 Priyanka Sharma、OpenJS 基金会执行董事 Robin Ginn、Hyperledger 基金会执行董事 Daniela Barbosa 等数百位来自全球的开源重磅嘉宾出席，为开发者、为行业分享开源的观点、经验借鉴与未来探索。

关注到开源生态中近年来最新的发展趋势，GOTC 2023 特别策划了 3D 与游戏世界技术峰会、eBPF、AI is Everywhere、聚焦开源安全，这四大“特别论坛”：

3D 与游戏世界技术峰会

自 2021 年起 Web 3.0 和宇宙逐步成为全球科技界的热门概念，科技巨头如 Meta、谷歌、苹果、华为、腾讯、OPPO 等均已在积极布局相关产业，其中一个关键技术就是 3D 引擎，无论是智慧城市、构建虚拟空间、工业设计还是高度真实的沉浸式用户体验都离不开强大的 3D 引擎技术。本论坛从开源技术出发，将带领观众通过畅游 3D 宇宙世界。除此之外，本论坛将带领观众畅玩 3D 与游戏世界，领略 3D 与游戏技术，并探讨商业在该领域的探索与落地。

eBPF

eBPF (extended Berkeley Packet Filter) 是 Linux 内核中一个非常灵活且高效的类虚拟机组件，能够直接运行在 Linux 内核态，第一时间能够完成对数据包、系统调用等处理，避免了内核态和用户态之间的切换和数据拷贝开销。由于eBPF 具有很强的安全性和稳定性，已经有越来越多的基于 eBPF 的项目如雨后春笋般蓬勃涌现。目前，很多内核子系统都已经使用了 eBPF，例如常见的网络、负载均衡、跟踪与安全等领域。此外，一些应用广泛的开源项目，如 Cilium、Falco、Bcc、Katran、Bpftrace、Kubectl-trace 等均采用了该技术。此论坛将一览无余地展现 eBPF 技术，并分享如何将其结合到实际工作中。

AI is Everywhere

AI赋能万物的时代已经到来。预计到2025年，AI赋能设备的数量将增长到7500万台，并会影响到每个行业和工作。每个种类的AI应用都可能会有一套自己的开发生态和架构。对于企业来说这种模式意味着高维护成本和高安全风险，并限制了企业AI新技术的应用和创新的步伐。LF AI & DATA开源社区一直致力于打造一个全球化的AI技术和开发者生态，我们诚邀所有的开源AI用户、贡献者和社区成员参加这次聚会，共同探讨开源AI的未来。

聚焦开源安全

开源软件在数据中心、消费者设备和应用程序中无处不在。使用开源代码已经成为软件开发的新常态，统计显示，一个软件平均有 90% 的代码源自开源，保证开源供应链安全已经远超出了一般开发者的能力。开源安全需要业界共同联手，为行业打造自动化工具、总结最佳实践、推动安全教育和鼓励开源安全协作。您将会在这个特别论坛听到来自全球的开源安全专家和用户的分享。我们诚邀所有开源用户、贡献者和社区成员参加这次聚会。

此外，大会还设置了众多分论坛。届时，围绕“基础设施与软件架构”“大前端新趋势”“云原生技术”“开源教育”“编程语言”“嵌入式”“开源治理”“数据与数据库技术”“DevOps”“Web3.0”等开源热门主题，开源大牛们将轮番上阵，激荡思想火花。

Cloud Native Summit：Cloud Native Summit 是 CNCF 的旗舰会议，峰会聚集了全球领先开源社区和云原生社区的使用者和技术大咖。相约 2023 年 GOTC 上的 Cloud Native Summit China，共同探讨云原生计算的未来和技术方向。
Linux 基金会开源教育及人才培养峰会：在最近的 Linux 基金会的开源工作岗位报告中，鉴于各行业持续采用云计算和进行数字化转型，对开源人才的需求非常强烈。邀请各界的开源大咖在到 GOTC，一起探讨国内开源教育和人才培养源教育的挑战，把握最热门的开源技术，帮助开发者会了解进入开源圈的途径，开启开源事业。
基础设施与软件架构：操作系统、数据库、编程语言、RISC-V……这些都是软件体系中最为基础和重要，也最为复杂的部分。在这些领域，其最前沿技术发展得如何？任何一个软件都需要合适的架构，怎样让架构更加理想，当前有哪些架构新花样，也是本论坛想要探讨的内容。
Web 3.0：Web 3.0 在今年被推上风口，但其实 2014 年已被提出。然而，当我们在谈 Web 3.0，我们到底在谈什么？此论坛将带领观众扫清迷雾，全面了解 Web 3.0 的形态与技术栈，以及探索可付诸应用实践的方向。
大前端新趋势：低代码、WebAssembly、小程序、跨端、PWA、Flutter、Dart、RN、Vue、Angular……这些技术越来越火，本论坛聚焦大前端前沿开源相关技术及实践经验，让技术更好地为业界服务。
开源乱秀：本论坛主要用于分享并演示炫酷的开源技术，展现一个“赛博朋克的机械感世界”，主要与硬件、嵌入式以及 IoT 相关，并提供现场互动。
编程语言：在开源的世界里，编程语言必不可少，每种语言也有各自的能力和性情，本论坛会为大家分享近两年大势的编程语言在实际使用中的技巧，以及语言相关生态的发展情况等内容。
OSPOCon：“我们本土的企业，每家的实力都很强，不仅有大量的贡献，也开源出很多项目，但是有一项尚不足，那就是企业之间在开源方面的合作还有很大的上升空间。”CNCF 大中华区总监 Keith Chan 在一次直播活动中如此总结道。数字世界的协作和竞争的逻辑是完全不同于我们过去的工业时代的，对于大型的软件工程，或者是依赖链条更长的生产项目，其工程消耗、维护成本、创新推进都不是某一家商业公司能够去独立完成的，而是要汇聚更多企业合力打造。这也就意味着和信息技术相关的企业需要学会合作，很多情况可能是业务上竞争，但是需要在基础设施上合作，毫无疑问这对于企业提出了更高的要求。借 GOTC 2023 的大势，我们想邀请本土企业的 OSPO 相关从业人员，一起商讨这个巨大的难题。旨在为接下来的本土开源推进重要的一步。我们会围绕一下主题进行：
- OSPO 在开源项目上的企业合作有何作用？
- 企业之间的OSPO应该如何互动？
- 利益该如何计算？
- OSPO 如何在内部说服决策层、业务部门
- 企业对于中立组织和机构的要求和期望
DevOps 前线：最前沿的 DevOps 理论、技术与实践。
数据与数据库技术：互联网与物联网不断发展，针对海量数据的处理技术层出不穷并不断成熟。在这个过程中，大数据、流式数据、数据库变得越来越紧密，本论坛将围绕数据技术，带领观众走向当前的技术前沿。

除了传统的内容分享与活动展区之外，本次大会还别出心裁地策划了“快闪演讲”“大咖会客厅”“HR 面对面”“开源时空隧道”等新玩法。如“开源时空隧道”，大会现场将围绕开源打造一个 3D 赛博朋克的未来世界。对于开源实践中面临的社区发展和生存挑战等现实问题，大会将邀请主流社区、大厂开源大拿、草根开源项目作者举行闭门会议，共寻解决之道。

相约 GOTC 2023，招商与议题征集等合作积极开展中，诚邀全球各技术领域开源爱好者共襄盛举。

了解更多信息，请访问官网：https://gotc2023.oschina.net

1 什么是流程引擎

流程引擎是一个底层支撑平台，是为提供流程处理而开发设计的。流程引擎和流程应用，以及应用程序的关系如下图所示。

常见的支撑场景有：Workflow、BPM、流程编排等。本次分享，主要从BPM流程引擎切入，介绍流程引擎的架构设计方法。

1.1 什么是流程

1.2 什么是引擎

1.3 流程设计器

1.3.1 自定义系

用于Sagemaker等场景的AWS Step Function（自定义流程节点）

1.3.2 UML Activity Diagram

Flowportal BPM的流程设计器

1.3.3 BPMN系

activiti的流程设计器

炎黄盈动的流程设计器

题外话：炎黄盈动的流程设计器，和processon中的流程设计器界面几乎一样，因为本质上是一家的。

2 流程引擎的应用

2.1 Workflow

2.2 BPM（Business Process Management）

BPM的应用，可以按照执行前、执行中和执行后来划分。

2.3 流程编排

3 流程引擎的架构设计

3.1 BPM流程引擎的组成单

组织、角色、用户、成员的组织架构托管；
流程资源文件的配置、校验、存储和执行，对不同的流程节点，流程引擎自动结合配置、数据处理其对应的业务逻辑，流程数据自动处理；
表单配置、数据绑定，表单数据的根据流程配置自动处理；
通用的数据接口；

3.1.1 组织架构的设计

3.1.2 流程设计器

流程设计器包含左侧的分组节点列表，和右侧的画布。左侧的节点可以如下进行设计。

3.1.3 表单设计器

这种是按照表单相关数据表，生成出一个表单，然后对表单字段进行配置和数据绑定。

这种是Drag&Drop控件，然后配置控件的属性，如绑定字段等。

这种是Drag&Drop控件，无需关联数据库表字段的表单

数据表生成表单的概要流程如下图所示。

拖拽控件绑定数据表字段的概要流程如下。

拖拽控件无需绑定数据表字段的概要流程。使用NoSQL的Document记录或使用RDS提供的JSON类型进行保存会比较方便。

3.1.4 接口设计

结合Activity的接口设计，如下图所示

3.2 基于流程引擎的项目开发实践

3.2.1 流程项目实践流程

确定组织架构
确定流程，包括流程布局、审批人设置、权限
确定表单信息（字段、类型、数据源、校验规则）和表单样式
确定页面布局、样式、数据字段、搜索、导入、导出
报表

3.2.2 组织架构

常见的组织架构操作还有组织架构同步，比如流程系统同步微信企业号、钉钉等，这里不再展开。

3.2.3 流程设计

我们想象的流程，可能是向下面的这种简单流程。

而实际项目，碰到的流程，一般是如下图所示的情景。

初步看几个流程的模型文件是什么样的，先有个印象。

3.2.4 表单设计

流程系统需要表单设计器，一个流程的不同节点可以挂接不同的表单，以方便不同角色的人关注不同维度的流程信息

3.2.5 页面设计

3.2.6 报表

由于不是所有客户都有报表系统，所以流程系统需要具备一个基本的报表功能。下图为示例。

有报表系统的客户，可以使用其商业版报表系统，获取（直接取、数仓）数据进行展示。常见的报表系统有FineReport、Tableau、PowerBI等。

3.3 BPM流程引擎架构设计

3.3.1 流程引擎的架构设计

3.3.2 发起流程

流程引擎处理过程

执行节点处理过程

问题：在流程引擎处理过程中，如果一个节点有多条连线，如何寻找FromNodeId是某个Node的连线？
人工处理时，指定连线text

3.4 流程引擎架构设计

3.4.1 业务识别

识别业务场景中的配置项，使用集合或分组的方式，让业务可配置
支撑业务流程过程的可配置化
支撑业务场景中的数据，自动处理

3.4.2 流程引擎的实现

资源相关服务，资源加载，资源保存，资源加密等
配置项相关服务
PVM虚拟机的实现，即通过某个节点（发起时为开始节点）作为初始节点，按照某个连线的action进行节点的自动执行的虚拟机
数据配置、数据权限
流程数据和业务数据的自动处理

4 商业机会

Business Process Analysis (BPA) 流程分析，帮助企业进行流程调整和优化
Process Assets Library（PAL）流程资产库，对企业流程进行知识化沉淀，将制度和流程落地做绑定，让审批人知晓流程中对应的职责
Process Simulate 流程模拟，自动化测试
Process Forecast 流程预测
低代码平台
更广泛的机会，在于业务领域+流程引擎，比如：DevOps、RPA、应用与服务编排、数据编排、FaaS编排等。

作者：马瑞

AITemplate（AIT）是一个 Python 框架，它将深度神经网络转化为 CUDA（NVIDIA GPU）/ HIP（AMD GPU）C++ 代码，以实现快速的推理服务。AITemplate 的亮点包括：

高性能：在主要模型上接近 roofline fp16 TensorCore（NVIDIA GPU）/MatrixCore（AMD GPU）性能，包括 ResNet、MaskRCNN、BERT、VisionTransformer、Stable Diffusion 等。
统一、开放、灵活：用于 NVIDIA GPU 或 AMD GPU 的 Seamless fp16 深度神经网络模型。完全开放源代码，乐高式的易扩展高性能基，支持新的模型。

安装

硬件要求：

NVIDIA ：AIT 仅在 SM80+ GPU 上进行测试，并非所有内核都适用于旧的 SM75/SM70 (T4/V100) GPU。
AMD ：AIT 仅在 CDNA2 (MI-210/250) GPU 上进行测试，旧的 CDNA1 (MI-100) GPU 可能存在编译器问题。

克隆代码

克隆代码时，请使用以下命令同时克隆子模块：

Docker 镜像

我们强烈建议将 AITemplate 与 Docker 一起使用，以避免意外使用错误版本的 NVCC 或 HIPCC。

CUDA:
ROCM:

这将构建一个带有标签的 docker 镜像

作者：板栗，前阿里、京东运营，6年资深互联网运营，成功从C端转B端，擅长用户运营、内容营销和个人IP打造，人人都是产品经理/鸟哥笔记等平台专栏作者

有很多小伙伴习惯了追求速度，一有问题，常常依靠下意识去处理，以为这就是职场上所强调的执行力。其实不是，执行力是指带来结果。

成也规模，败也规模。

做完了社区运营的心理建设，接下来讲讲如何从0到1运营开源社区。

板栗

01 了解用户，梳理开源社区用户画像

运营开源社区的第一步就是了解你的用户。

如果说C端社区运营像自由恋爱，讲感情，看感觉，那么B端社区运营更多就是相亲，各种条件摆得清清楚楚，评估过后再来看以什么姿态、用几分力。

那要如何了解用户呢？

我自己常用的调研手段主要有以下三种：

2）问卷调研：比较适合更大规模的用户研究，但问卷的设计很考验人，这里有需要的话，以后单独开一篇来讲。

3）看行业报告：结合报告数据与自己的一线经验，对照分析自己的目标用户有哪些共性特点，有哪些是报告所未能涉及到、属于你的小洞察的。

做社区运营，尤其是不断滚动的成长型社区，就像生育孩子一样，大孩长大了，二胎又来了……然后还有三胎、四胎。

02 定位先行，一切运营动作围绕定位展开

问题来了，定位要怎么去做呢？尤其是那种看起来高大上的slogan要怎么写呢？

03 开源社区运营：分级、分类、分阶段

1.用户分级运营

资源永远是有限的，而我们的工作就是要在将有限的资源利用最大化。除去显性的金钱与物料，你的时间也是极其宝贵的资源。

一般来说，我们会把用户按照贡献价值从高到低分为以下五种：

以上数字只是示意，并非不同级别用户的实际贡献

名人用户：行业大佬、学术权威等，平时不怎么发言，但可以为社区权威性背书，必要时也能为合作牵线搭桥
贡献用户：资深开发、技术大牛等，可以贡献代码方案
活跃用户：一般的技术开发者，氛围担当的同时可以解决一些基础问题和提建议
普通用户：反馈产品问题，参加社群的有奖活动
入门用户：一般是学生，处于研究阶段，最常干的事情就是提问和薅羊毛

2.用户分类运营

比如，同样处于普通用户层级的两人，可能一个来自金融行业，另一个是零售行业的，他们的核心需求就不太一样。

完成用户分类以后，抽象出共性，再进行针对性运营即可。

3.用户分阶段运营

04 搭建用户体系之前的5个问题

随着用户不断深入了解、使用和感受产品，加深与产品的关联度，用户身份也是在不断变化的，比如导入期对应新用户，成长对应普通用户。

为了达成这一目标，我们可用的手段包括但不限于“用户成长体系”和“用户激励体系”。

而不管是成长体系还是激励体系，都要先思考下面几个问题：

问题1：哪些用户行为是我们希望看到的？

问题2：判断用户行为是否值得被激励的标准是什么？

问题3：如何判断这些行为之间的权重？

问题4：用户为何会按照我们的预期行动？我们能提供什么价值？

问题5：这个价值要怎么给，给多少，多久给一次，给的形式……整个玩法要如何设计，才能更好地刺激用户完成既定行为？

1、哪些用户行为是我们希望看到的？

1）技术使用深度具体来说，包括但不限于使用技术产品、提bug、提issue、提PR等；

2）社区交互深度具体来说，包括但不限于参与官方内容转赞评，帮助社区其他用户解决技术问题，参与社区活动，在社区进行主题分享等。

2、判断用户行为是否值得被激励的标准是什么？

3、如何判断这些行为之间的权重？

还是上面两条标准，优先考虑社区整体的健康发展。

4、用户为何会按照我们的预期行动？我们能提供什么价值？

用户愿意听你的、按照你说的做，是因为他愿意这么做来交换你手中的资源，并不是因为你牛逼。

而我们能够提供的资源或者说价值一般包括以下四种：

1）物质：现金激励，购物卡，周边，苹果产品等硬通货；

2）内容：技术文档，经典QA，行业资讯，白皮书等；

3）服务：一对一技术专家答疑，与权威专家交流机会，企业参观；

4）荣誉：社区认证讲师、技术布道者等荣誉；

这里提醒一下，还是要学会通过荣誉激励用户去完成预期行为。

5、这个价值要怎么给，给多少，多久给一次，给的形式……整个玩法要如何设计，才能更好地刺激用户完成既定行为？

这个比较复杂，需要具体情况具体分析。由于工作内容暂时不便公开，所以细节也没法说。但是有些原则可以和大家分享。

首先是有多大金刚钻，揽多少瓷器活儿。

一定要结合现有资源去设计整个体系，不要空头支票。钱不够的时候，一定一定要取舍，做好重点，而不是均摊费用！

其次是设计用户行为时，要时刻考虑降低用户行动成本，不改变用户本来的行为路径，除非真的有必要。

最后要注意结合用户自然行为的特征（行动极限，行动频率等）去设计你的目标。

微信公众号：南有板栗

终身学习，定期分享运营经验和个人成长经验

本文来源于开源集《开源观止》第 4 期，更多精彩内容，请下载：

https://oscimg.oschina.net/public_shard/opensource-guanzhi-.pdf

开发者 Wesley Smits 以自身经验为例罗列了 11 个他认为已经没用的扩展。“由于扩展可能会导致性能问题、增加 CPU 使用率，并且可能与其他扩展或本地功能发生冲突，因此最好将扩展限制为你所需要的扩展”。

Wesley Smits 指出，有些扩展的下载页面顶部有甚至有明确的弃用通知，但在 Medium、dev.to、Reddit 等一些平台上却仍有推荐贴。值得一提的是，这些扩展中有许多是原生存在于 Visual Studio Code 中，所以可以通过设置菜单启用/禁用或进行控制。

这些设置可以通过 UI 或 JSON 配置来控制。Wesley Smits 在文中以 JSON 版本为例建议：可以通过命令面板（⇧ ⌘P）打开全局 Visual Studio 代码设置的 settings.json。输入 settings，然后选择”Preferences: Open User Settings (JSON)”。

这 11 个扩展具体包括：

1、Auto Rename Tag — 1050 万次下载

截至文章撰写时（10 月 14 日），这个扩展的下载量已超过 1050 万次。Smits 称，这个扩展频繁地出现在每个推荐扩展的文章中。然而事实上，VS Code 已经通过内部设置提供了同样的功能。通过启用以下设置，你的 tags 将自动重命名，而无需第三方扩展。

 "editor.linkedEditing": true

2、Auto Close Tag — 800 万次下载

这个非常受欢迎的扩展，与前一个扩展的作者是同一个人。目前，这个扩展的功能也已被添加到了 VS Code 中。

 "html.autoClosingTags": true, "javascript.autoClosingTags": true, "typescript.autoClosingTags": true

3、Auto Import — 250 万次下载

此扩展可自动查找、解析并为 Typescript 和 TSX 中的所有可用导入提供 code actions 和 code completion。

但实际上 VS Code 中有很多设置可以帮助动安排导入。可以为 JavaScript/TypeScript 使用 auto-import suggestions，在文件移动时更新导入，并在 top 使用绝对路径组织导入。

 "javascript.suggest.autoImports": true, "typescript.suggest.autoImports": true, "javascript.updateImportsOnFileMove.enabled": "always", "typescript.updateImportsOnFileMove.enabled": "always", "source.organizeImports": true

4、Settings Sync — 340 万次下载

这个扩展可以让 VS Code 设置在不同的设备之间保持同步。不过 VS Code 官方已经在大约两年前原生地添加了这个特性。有关如何设置的更多信息，可阅读官方 VS Code 文档。

5、Trailing Spaces— 110 万次下载

此扩展 highlights training spaces ，并允许你使用命令将它们全部删除。VS Code 有一个设置，启用后会在你保存文件时删除所有 trailing spaces。启用设置：

 "files.trimTrailingWhitespace": true,

6、Path Intellisense — 800 万次下载

此扩展自动完成路径和文件名，下载量超过 800 万次。同一开发人员针对 NPM 模块自动补全提供了此扩展的对应版本，下载量接近 500 万次。然而，与许多特性一样，VS Code 不久前添加了对这些特性的原生支持。这些功能默认开启，无需启用任何设置。

7、NPM — 560 万次下载

此扩展允许你用一个命令运行 NPM 脚本。但是 VS Code 也已经提供了提供了一种原生的处理方式。VS Code 有一个称为 Task Auto Detection 的功能，任务可以被自动检测到，也可以自定义为自动运行。

8、HTML Snippets — 840 万次下载

此扩展允许你使用 shorthand 的方式快速放置 HTML snippets。以下两个扩展的概念也是如此：

CSS Snippets
HTML Boilerplate

这些扩展都提供 shorthand 版本，VS Code 已经原生支持这些版本。VS Code 内置了 Emmet，一个可以用 easy-to-remember shorthands 快速写出 HTML 和 CSS 的工具。此外，Emmet 提供了一个开箱即用的 HTML 模板，并允许你定义自己的自定义片段。

9、HTMLTagWrap— 415K 次下载

此扩展程序和其他类似扩展程序允许你选择一些 HTML 代码并将其 wrap 在 tag中。

VVS Code 通过 Emmet 的一个命令也提供了这个功能。只要用 CTRL/CMD + Shift + P 打开命令面板，并查找。然后你可以输入任何你想要的 emmet 缩写，这可以是单个 tag、多个嵌套 tag、带有类或 ID 的 tag。

10、Lorem Ipsum — 473K 次下载

此扩展可让你快速将 Lorem Ipsum 文本块插入到你的 markup 中。Emmet 同样也支持此功能。你可以键入并按 Tab 键以生成 30 字的段落。或者，如果你需要多个块，可以编写类似的内容以满足需求：

 ul>li*3>p>lorem

11、Bracket Pair Colorizer (1 & 2) — 520 万次下载

Bracket Pair Colorizer 及其继任者的安装量已超过 1100 万。鉴于此需求量，开发团队已在 VS Code core 中实现了 bracket pair colorizer，并声称这使其速度提高了 10.000 倍。可以通过启用以下设置来启用 Bracket pair coloring：

 "editor.bracketPairColorization.enabled": true

以下是上述设置的完整清单：

 { "editor.linkedEditing": true, "html.autoClosingTags": true, "javascript.autoClosingTags": true, "typescript.autoClosingTags": true, "javascript.suggest.autoImports": true, "typescript.suggest.autoImports": true, "javascript.updateImportsOnFileMove.enabled": "always", "typescript.updateImportsOnFileMove.enabled": "always", "source.organizeImports": true, "files.trimTrailingWhitespace": true, "editor.bracketPairColorization.enabled": true }

Wesley Smits 最后作出结论称，Visual Studio Code 有一个广泛的扩展市场，可以增加你的便利度。但在安装其中一个之前，最好先看看它是否还没有原生支持。随着时间的推移，包含改进和功能的每月发布更新，越来越多的 Visual Studio Code 扩展将不再需要。更多详情可查看全文。

对此，Reddit 上也有网友分享称，“有一堆扩展是 bulitin 的，你可以禁用所有你不需要的。进入扩展面板，搜索 @builtin”。

Linux 6.1在本周合并了 VirtIO 更改，Linux 6.1 在 VirtIO 方面值得注意的是块驱动程序“virtio_blk”引入了“SECURE ERASE”支持。

现在安全擦除功能已添加到 VirtIO 规范中，新引进的 VIRTIO_BLK_F_SECURE_ERASE 要求除了常规的 SSD“丢弃”功能之外，所有可能通过垃圾收集创建的丢弃块（discarded blocks）也必须被擦除，底层块/存储驱动程序必须反过来支持这种安全擦除功能才能公开。通过 VirtIO 实现，安全擦除请求可从客户机传递到实际后端，以执行请求。

Linux 6.1 的 VirtIO 更新的另一个主要功能是支持 vDPA 功能配置：尝试允许通过 netlink 配置设备功能，实现Virtio 功能在设备和驱动程序之间协商，允许像 vDPA 这样的中介层对驱动程序隐藏一些功能，以促进跨供应商实时迁移。比如说：

源上的 vDPA 支持功能集 X
目标上的 vDPA 支持功能集 Y

支持 vDPA 功能配置后，管理可以简单地为 vDPA 实例同时配置两者上的功能（X + Y），使 vDPA 可以在具有不同功能支持的两个 vDPA 设备之间迁移。

在 VirtIO 网络方面，Linux 6.1 引入了 9P 网络协议，允许主机和来宾之间更快的文件共享。

有关 Linux 6.1 的完整 VirtIO 更改，可查看该 PR 。

关注公众号

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

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

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

漏洞描述

lighttpd 是德国Jan Kneschke个人开发者的一款开源的Web服务器。

lighttpd 1.4.65 版本中如果启用了 mod_wstunnel 并且服务器接收到无效的 HTTP Websocket 握手请求，则会出现一个空指针取消引用错误，该错误会导致整个服务器崩溃。远程攻击者会滥用此漏洞来导致拒绝服务条件。

漏洞名称 lighttpd v1.4.65 NULL针取消引用漏洞漏洞类型空指针解引用发现时间 2022-09-12 漏洞影响广度小 MPS编号 MPS-2022-53710 CVE编号 CVE-2022-37797 CNVD编号 –

影响范围

lighttpd-mod-deflate@(-∞, 1.4.59-1+deb11u2)

lighttpd@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-vhostdb-dbi@(-∞, 1.4.59-1+deb11u2)

lighttpd-modules-lua@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-openssl@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-maxminddb@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-magnet@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-authn-sasl@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-cml@(-∞, 1.4.59-1+deb11u2)

lighttpd-doc@(-∞, 1.4.59-1+deb11u2)

lighttpd-modules-ldap@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-nss@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-authn-gssapi@(-∞, 1.4.59-1+deb11u2)

lighttpd-modules-dbi@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-mbedtls@(-∞, 1.4.59-1+deb11u2)

lighttpd-modules-mysql@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-wolfssl@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-authn-pam@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-webdav@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-trigger-b4-dl@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-geoip@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-openssl@(-∞, 1.4.66-1)

lighttpd-modules-lua@(-∞, 1.4.66-1)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.66-1)

lighttpd-mod-wolfssl@(-∞, 1.4.66-1)

lighttpd-doc@(-∞, 1.4.66-1)

lighttpd-modules-ldap@(-∞, 1.4.66-1)

lighttpd-mod-deflate@(-∞, 1.4.66-1)

lighttpd-mod-authn-sasl@(-∞, 1.4.66-1)

lighttpd-modules-mysql@(-∞, 1.4.66-1)

lighttpd-mod-nss@(-∞, 1.4.66-1)

lighttpd-mod-webdav@(-∞, 1.4.66-1)

lighttpd-modules-dbi@(-∞, 1.4.66-1)

lighttpd-mod-authn-gssapi@(-∞, 1.4.66-1)

lighttpd-mod-authn-pam@(-∞, 1.4.66-1)

lighttpd-mod-maxminddb@(-∞, 1.4.66-1)

lighttpd-mod-mbedtls@(-∞, 1.4.66-1)

lighttpd-mod-gnutls@(-∞, 1.4.66-1)

lighttpd-mod-vhostdb-dbi@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-ldap@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-wolfssl@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-webdav@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-pam@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-nss@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-maxminddb@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-ldap@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-cml@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-dbi@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-lua@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-openssl@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-gssapi@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-mbedtls@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-sasl@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-mysql-vhost@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-mysql@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-deflate@(-∞, 1.4.53-4+deb10u3)

lighttpd-doc@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-geoip@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-trigger-b4-dl@(-∞, 1.4.53-4+deb10u3)

lighttpd@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-magnet@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-mysql@(-∞, 1.4.53-4+deb10u3)

lighttpd-doc@(-∞, 1.4.66-1)

lighttpd-mod-webdav@(-∞, 1.4.66-1)

lighttpd-modules-ldap@(-∞, 1.4.66-1)

lighttpd-modules-lua@(-∞, 1.4.66-1)

lighttpd-modules-dbi@(-∞, 1.4.66-1)

lighttpd-mod-authn-sasl@(-∞, 1.4.66-1)

lighttpd-mod-authn-gssapi@(-∞, 1.4.66-1)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.66-1)

lighttpd-mod-mbedtls@(-∞, 1.4.66-1)

lighttpd-mod-openssl@(-∞, 1.4.66-1)

lighttpd-modules-mysql@(-∞, 1.4.66-1)

lighttpd-mod-authn-pam@(-∞, 1.4.66-1)

lighttpd-mod-deflate@(-∞, 1.4.66-1)

lighttpd-mod-nss@(-∞, 1.4.66-1)

lighttpd-mod-maxminddb@(-∞, 1.4.66-1)

lighttpd-mod-wolfssl@(-∞, 1.4.66-1)

lighttpd-mod-gnutls@(-∞, 1.4.66-1)

lighttpd-mod-authn-gssapi@(-∞, 1.4.66-1)

lighttpd-modules-ldap@(-∞, 1.4.66-1)

lighttpd-mod-mbedtls@(-∞, 1.4.66-1)

lighttpd-mod-authn-pam@(-∞, 1.4.66-1)

lighttpd-mod-openssl@(-∞, 1.4.66-1)

lighttpd@(-∞, 1.4.66-1)

lighttpd-mod-deflate@(-∞, 1.4.66-1)

lighttpd-modules-lua@(-∞, 1.4.66-1)

lighttpd-modules-dbi@(-∞, 1.4.66-1)

lighttpd-mod-webdav@(-∞, 1.4.66-1)

lighttpd-mod-authn-sasl@(-∞, 1.4.66-1)

lighttpd-doc@(-∞, 1.4.66-1)

lighttpd-mod-wolfssl@(-∞, 1.4.66-1)

lighttpd-modules-mysql@(-∞, 1.4.66-1)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.66-1)

lighttpd-mod-nss@(-∞, 1.4.66-1)

lighttpd-mod-maxminddb@(-∞, 1.4.66-1)

lighttpd-modules-lua@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-openssl@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-maxminddb@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-wolfssl@(-∞, 1.4.59-1+deb11u2)

lighttpd-modules-mysql@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-magnet@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.59-1+deb11u2)

lighttpd-doc@(-∞, 1.4.59-1+deb11u2)

lighttpd@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-vhostdb-dbi@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-webdav@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-authn-pam@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-deflate@(-∞, 1.4.59-1+deb11u2)

lighttpd-modules-ldap@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-nss@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-authn-sasl@(-∞, 1.4.59-1+deb11u2)

lighttpd-modules-dbi@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-mbedtls@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-geoip@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-cml@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-trigger-b4-dl@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-authn-gssapi@(-∞, 1.4.59-1+deb11u2)

lighttpd@(-∞, 1.4.66-1)

lighttpd-doc@(-∞, 1.4.66-1)

lighttpd-modules-lua@(-∞, 1.4.66-1)

lighttpd-mod-authn-pam@(-∞, 1.4.66-1)

lighttpd-mod-deflate@(-∞, 1.4.66-1)

lighttpd-modules-mysql@(-∞, 1.4.66-1)

lighttpd-mod-webdav@(-∞, 1.4.66-1)

lighttpd-modules-ldap@(-∞, 1.4.66-1)

lighttpd-mod-wolfssl@(-∞, 1.4.66-1)

lighttpd-mod-maxminddb@(-∞, 1.4.66-1)

lighttpd-mod-authn-gssapi@(-∞, 1.4.66-1)

lighttpd-modules-dbi@(-∞, 1.4.66-1)

lighttpd-mod-openssl@(-∞, 1.4.66-1)

lighttpd-mod-gnutls@(-∞, 1.4.66-1)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.66-1)

lighttpd-mod-authn-sasl@(-∞, 1.4.66-1)

lighttpd-mod-mbedtls@(-∞, 1.4.66-1)

lighttpd-mod-nss@(-∞, 1.4.66-1)

lighttpd-mod-vhostdb-dbi@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-mbedtls@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-mysql@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-geoip@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-magnet@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-maxminddb@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-deflate@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-mysql@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-wolfssl@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-webdav@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-ldap@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-openssl@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-gssapi@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-sasl@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-ldap@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-dbi@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-lua@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.53-4+deb10u3)

lighttpd@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-pam@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-nss@(-∞, 1.4.53-4+deb10u3)

lighttpd-doc@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-mysql-vhost@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-cml@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-trigger-b4-dl@(-∞, 1.4.53-4+deb10u3)

lighttpd-doc@(-∞, 1.4.66-1)

lighttpd-modules-dbi@(-∞, 1.4.66-1)

lighttpd-modules-mysql@(-∞, 1.4.66-1)

lighttpd-mod-gnutls@(-∞, 1.4.66-1)

lighttpd-mod-deflate@(-∞, 1.4.66-1)

lighttpd-mod-mbedtls@(-∞, 1.4.66-1)

lighttpd@(-∞, 1.4.66-1)

lighttpd-mod-openssl@(-∞, 1.4.66-1)

lighttpd-modules-ldap@(-∞, 1.4.66-1)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.66-1)

lighttpd-mod-maxminddb@(-∞, 1.4.66-1)

lighttpd-mod-authn-sasl@(-∞, 1.4.66-1)

lighttpd-mod-nss@(-∞, 1.4.66-1)

lighttpd-modules-lua@(-∞, 1.4.66-1)

lighttpd-mod-webdav@(-∞, 1.4.66-1)

lighttpd-mod-authn-gssapi@(-∞, 1.4.66-1)

lighttpd-mod-authn-pam@(-∞, 1.4.66-1)

lighttpd-mod-wolfssl@(-∞, 1.4.66-1)

lighttpd@(-∞, 1.4.59-1+deb11u2)

lighttpd-doc@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-trigger-b4-dl@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-geoip@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-mbedtls@(-∞, 1.4.59-1+deb11u2)

lighttpd-modules-dbi@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-nss@(-∞, 1.4.59-1+deb11u2)

lighttpd-modules-ldap@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-vhostdb-dbi@(-∞, 1.4.59-1+deb11u2)

lighttpd-modules-lua@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-openssl@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-webdav@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-authn-gssapi@(-∞, 1.4.59-1+deb11u2)

lighttpd-modules-mysql@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-wolfssl@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-authn-sasl@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-deflate@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-magnet@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-authn-pam@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-cml@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-maxminddb@(-∞, 1.4.59-1+deb11u2)

lighttpd-mod-authn-gssapi@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-sasl@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-nss@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-mysql@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-geoip@(-∞, 1.4.53-4+deb10u3)

lighttpd@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-mysql-vhost@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-pam@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-dbi@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-lua@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-mbedtls@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-wolfssl@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-webdav@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-maxminddb@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-cml@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-vhostdb-dbi@(-∞, 1.4.53-4+deb10u3)

lighttpd-modules-ldap@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-ldap@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-openssl@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-magnet@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-trigger-b4-dl@(-∞, 1.4.53-4+deb10u3)

lighttpd-doc@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-deflate@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-authn-mysql@(-∞, 1.4.53-4+deb10u3)

lighttpd-mod-deflate@(-∞, 1.4.66-1)

lighttpd-mod-vhostdb-pgsql@(-∞, 1.4.66-1)

lighttpd-mod-gnutls@(-∞, 1.4.66-1)

lighttpd-mod-nss@(-∞, 1.4.66-1)

lighttpd-doc@(-∞, 1.4.66-1)

lighttpd-mod-wolfssl@(-∞, 1.4.66-1)

lighttpd-mod-maxminddb@(-∞, 1.4.66-1)

lighttpd-mod-mbedtls@(-∞, 1.4.66-1)

lighttpd-modules-mysql@(-∞, 1.4.66-1)

lighttpd-mod-webdav@(-∞, 1.4.66-1)

lighttpd-modules-ldap@(-∞, 1.4.66-1)

lighttpd-mod-authn-gssapi@(-∞, 1.4.66-1)

lighttpd-mod-authn-sasl@(-∞, 1.4.66-1)

lighttpd@(-∞, 1.4.66-1)

lighttpd-mod-openssl@(-∞, 1.4.66-1)

lighttpd-modules-dbi@(-∞, 1.4.66-1)

lighttpd-modules-lua@(-∞, 1.4.66-1)

lighttpd-mod-authn-pam@(-∞, 1.4.66-1)

lighttpd@(-∞, 1.4.66)

修复方案

将组件 lighttpd-mod-openssl 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-wolfssl 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-authn-pam 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-maxminddb 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-authn-mysql 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-modules-mysql 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-cml 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-doc 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-mbedtls 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-deflate 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-doc 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-openssl 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-authn-gssapi 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-cml 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-vhostdb-pgsql 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-authn-pam 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-webdav 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-geoip 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-modules-dbi 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-openssl 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-doc 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-authn-sasl 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-webdav 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-mbedtls 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-gnutls 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-wolfssl 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-modules-lua 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-authn-sasl 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-webdav 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-trigger-b4-dl 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-modules-lua 升级至 1.4.66-1 及以上版本

将组件 lighttpd-modules-dbi 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-vhostdb-dbi 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd 升级至 1.4.66-1 及以上版本

升级lighttpd到 1.4.66 或更高版本

将组件 lighttpd-mod-vhostdb-pgsql 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-magnet 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-maxminddb 升级至 1.4.66-1 及以上版本

将组件 lighttpd 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-mbedtls 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-modules-mysql 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-nss 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-wolfssl 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-modules-ldap 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-modules-lua 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-geoip 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-deflate 升级至 1.4.66-1 及以上版本

将组件 lighttpd-modules-dbi 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-authn-sasl 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-nss 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-authn-gssapi 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-authn-pam 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-authn-ldap 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-deflate 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-modules-ldap 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-modules-ldap 升级至 1.4.66-1 及以上版本

将组件 lighttpd-mod-authn-gssapi 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-maxminddb 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-modules-mysql 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-nss 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-vhostdb-pgsql 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-vhostdb-dbi 升级至 1.4.59-1+deb11u2 及以上版本

将组件 lighttpd-mod-trigger-b4-dl 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-magnet 升级至 1.4.53-4+deb10u3 及以上版本

将组件 lighttpd-mod-mysql-vhost 升级至 1.4.53-4+deb10u3 及以上版本

参考链接

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

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

https://redmine.lighttpd.net/issues/3165

情报订阅

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

具体订阅方式详见：

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

漏洞描述

Django 是Django基金会的一套基于Python语言的开源Web应用框架。

Django 的受影响版本中的 MultiPartParser 中存在解析文件时无限循环漏洞，攻击者可利用此漏洞在解析文件时将恶意输入传递给multipart forms，从而导致敏感信息泄露、数据添加或修改或拒绝服务 (拒绝服务）。

漏洞名称 Django 无限循环漏洞漏洞类型不可达退出条件的循环（无限循环）发现时间 2022-10-16 漏洞影响广度广 MPS编号 MPS-2022-2266 CVE编号 CVE-2022-23833 CNVD编号 CNVD-2022-31854

影响范围

django@[4.0, 4.0.2)

python-django@(-∞, 1.10.7-2+deb9u15)

python-django-common@(-∞, 1.10.7-2+deb9u15)

python-django-doc@(-∞, 1.10.7-2+deb9u15)

python-django-doc@(-∞, 3.2.12-1)

python-django-doc@(-∞, 1.10.7-2+deb9u15)

python-django@(-∞, 1.10.7-2+deb9u15)

python-django-common@(-∞, 1.10.7-2+deb9u15)

python3-django@(-∞, 3.2.12-1)

python-django-common@(-∞, 1.10.7-2+deb9u15)

python-django-doc@(-∞, 1.10.7-2+deb9u15)

python3-django@(-∞, 1.10.7-2+deb9u15)

python-django@(-∞, 1.10.7-2+deb9u15)

python-django-doc@(-∞, 3.2.12-1)

python3-django@(-∞, 1:1.10.7-2+deb9u15)

python-django-doc@(-∞, 1:1.10.7-2+deb9u15)

python-django@(-∞, 1:1.10.7-2+deb9u15)

python-django-common@(-∞, 1:1.10.7-2+deb9u15)

python-django-doc@影响所有版本

python3-django@影响所有版本

python-django-common@影响所有版本

python-django-doc@影响所有版本

python-django-doc@(-∞, 2:3.2.12-1)

python3-django@影响所有版本

python-django@影响所有版本

python3-django@(-∞, 2:3.2.12-1)

python-django-common@(-∞, 1:1.10.7-2+deb9u15)

python-django@(-∞, 1:1.10.7-2+deb9u15)

python3-django@(-∞, 1:1.10.7-2+deb9u15)

python-django-doc@(-∞, 1:1.10.7-2+deb9u15)

python3-django@(-∞, 2:3.2.12-1)

python-django-doc@影响所有版本

python-django@影响所有版本

python-django-doc@影响所有版本

python-django-common@影响所有版本

python3-django@影响所有版本

python-django-doc@(-∞, 2:3.2.12-1)

python-django-doc@(-∞, 1.10.7-2+deb9u15)

python-django-common@(-∞, 1.10.7-2+deb9u15)

python3-django@(-∞, 1.10.7-2+deb9u15)

python-django@(-∞, 1.10.7-2+deb9u15)

python3-django@影响所有版本

python-django-doc@影响所有版本

python3-django@(-∞, 3.2.12-1)

python3-django@影响所有版本

python-django@影响所有版本

python-django-doc@影响所有版本

python-django-doc@(-∞, 3.2.12-1)

python-django-common@影响所有版本

python-django@(-∞, 3.2.12-1)

python-django@影响所有版本

django@[3.0, 3.2.12)

django@[2.2, 2.2.27)

修复方案

将组件 python-django 升级至 1.10.7-2+deb9u15 及以上版本

将组件 python3-django 升级至 3.2.12-1 及以上版本

将组件 python3-django 升级至 1:1.10.7-2+deb9u15 及以上版本

将组件 python-django 升级至 1:1.10.7-2+deb9u15 及以上版本

将组件 python-django 升级至 3.2.12-1 及以上版本

将组件 django 升级至 4.0.2 及以上版本

将组件 python-django-common 升级至 1.10.7-2+deb9u15 及以上版本

将组件 python-django-doc 升级至 1:1.10.7-2+deb9u15 及以上版本

将组件 python-django-common 升级至 1:1.10.7-2+deb9u15 及以上版本

将组件 python-django-doc 升级至 2:3.2.12-1 及以上版本

将组件 django 升级至 2.2.27 及以上版本

将组件 python-django-doc 升级至 3.2.12-1 及以上版本

将组件 python3-django 升级至 1.10.7-2+deb9u15 及以上版本

将组件 django 升级至 3.2.12 及以上版本

将组件 python-django-doc 升级至 1.10.7-2+deb9u15 及以上版本

将组件 python3-django 升级至 2:3.2.12-1 及以上版本

参考链接

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

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

https://www.djangoproject.com/weblog/2022/feb/01/security-releases/

情报订阅

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

具体订阅方式详见：

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

漏洞描述

Django 是Django基金会的一套基于Python语言的开源Web应用框架。

Django 的受影响版本中 {% debug %} 模板标签存在XSS漏洞，其原因是{% debug %}模版标签不能正确的编码上下文数据。攻击者可通过该漏洞获取系统敏感信息泄露、执行任意JavaScript代码或造成拒绝服务 (DoS)。

漏洞名称 Django 存在XSS漏洞漏洞类型 XSS 发现时间 2022-10-16 漏洞影响广度广 MPS编号 MPS-2022-0820 CVE编号 CVE-2022-22818 CNVD编号 CNVD-2022-31853

影响范围

django@[4.0, 4.0.2)

python-django-common@(-∞, 1.10.7-2+deb9u15)

python-django@(-∞, 1.10.7-2+deb9u15)

python-django-doc@(-∞, 1.10.7-2+deb9u15)

python-django-doc@(-∞, 3.2.12-1)

python-django-common@(-∞, 1.10.7-2+deb9u15)

python-django-doc@(-∞, 1.10.7-2+deb9u15)

python-django@(-∞, 1.10.7-2+deb9u15)

python-django-doc@(-∞, 3.2.12-1)

python3-django@(-∞, 3.2.12-1)

python3-django@(-∞, 1.10.7-2+deb9u15)

python-django-common@(-∞, 1.10.7-2+deb9u15)

python-django@(-∞, 1.10.7-2+deb9u15)

python-django-doc@(-∞, 1.10.7-2+deb9u15)

python-django-common@(-∞, 1:1.10.7-2+deb9u15)

python3-django@(-∞, 1:1.10.7-2+deb9u15)

python-django-doc@(-∞, 1:1.10.7-2+deb9u15)

python-django@(-∞, 1:1.10.7-2+deb9u15)

python-django@影响所有版本

python-django-common@影响所有版本

python3-django@影响所有版本

python3-django@(-∞, 2:3.2.12-1)

python-django-doc@(-∞, 2:3.2.12-1)

python-django-doc@影响所有版本

python3-django@影响所有版本

python-django-doc@影响所有版本

python-django-doc@(-∞, 1:1.10.7-2+deb9u15)

python3-django@(-∞, 1:1.10.7-2+deb9u15)

python-django@(-∞, 1:1.10.7-2+deb9u15)

python-django-common@(-∞, 1:1.10.7-2+deb9u15)

python3-django@影响所有版本

python-django-doc@影响所有版本

python-django-common@影响所有版本

python3-django@(-∞, 2:3.2.12-1)

python-django-doc@(-∞, 2:3.2.12-1)

python-django-doc@影响所有版本

python-django@影响所有版本

python-django-doc@(-∞, 1.10.7-2+deb9u15)

python-django-common@(-∞, 1.10.7-2+deb9u15)

python3-django@(-∞, 1.10.7-2+deb9u15)

python3-django@影响所有版本

python3-django@(-∞, 3.2.12-1)

python-django-doc@(-∞, 3.2.12-1)

python-django-doc@影响所有版本

python-django-common@影响所有版本

python3-django@影响所有版本

python-django@影响所有版本

python-django@(-∞, 1.10.7-2+deb9u15)

python-django@(-∞, 3.2.12-1)

python-django@影响所有版本

django@[3.0, 3.2.12)

django@[2.2, 2.2.27)

修复方案

将组件 python-django-common 升级至 1.10.7-2+deb9u15 及以上版本

将组件 python-django-doc 升级至 1.10.7-2+deb9u15 及以上版本

将组件 python-django-doc 升级至 1:1.10.7-2+deb9u15 及以上版本

将组件 django 升级至 4.0.2 及以上版本

将组件 python3-django 升级至 1.10.7-2+deb9u15 及以上版本

将组件 python-django 升级至 1:1.10.7-2+deb9u15 及以上版本

将组件 python-django 升级至 3.2.12-1 及以上版本

将组件 python-django-doc 升级至 3.2.12-1 及以上版本

将组件 python-django-common 升级至 1:1.10.7-2+deb9u15 及以上版本

将组件 python3-django 升级至 1:1.10.7-2+deb9u15 及以上版本

将组件 django 升级至 3.2.12 及以上版本

将组件 django 升级至 2.2.27 及以上版本

将组件 python-django 升级至 1.10.7-2+deb9u15 及以上版本

将组件 python3-django 升级至 3.2.12-1 及以上版本

将组件 python3-django 升级至 2:3.2.12-1 及以上版本

将组件 python-django-doc 升级至 2:3.2.12-1 及以上版本

参考链接

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

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

https://docs.djangoproject.com/en/4.0/releases/security/

情报订阅

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

具体订阅方式详见：

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

漏洞描述

Django 是Django基金会的一套基于Python语言的开源Web应用框架。

Django 的受影响版本中 QuerySet.explain() 中发现了 SQL 注入漏洞，攻击者可利用此漏洞将精心制作的字典作为 options 参数进行XSS攻击，从而获取系统敏感信息，窃取受害者的会话令牌或登录凭据等内容。

漏洞名称 Django SQL注入漏洞漏洞类型 SQL注入发现时间 2022-10-16 漏洞影响广度广 MPS编号 MPS-2022-7491 CVE编号 CVE-2022-28347 CNVD编号 CNVD-2022-31837

影响范围

django@[3.0, 3.2.13)

python-django-doc@(-∞, 3.2.13-1)

python3-django@(-∞, 3.2.13-1)

python3-django@(-∞, 2:3.2.13-1)

python-django-doc@(-∞, 2:3.2.13-1)

python-django-doc@(-∞, 3.2.13-1)

python3-django@(-∞, 2:3.2.13-1)

python-django-doc@(-∞, 2:3.2.13-1)

python-django-doc@(-∞, 3.2.13-1)

python3-django@(-∞, 3.2.13-1)

python-django@(-∞, 3.2.13-1)

django@[4.0, 4.0.4)

django@[2.2, 2.2.28)

修复方案

将组件 python3-django 升级至 2:3.2.13-1 及以上版本

将组件 python-django-doc 升级至 2:3.2.13-1 及以上版本

将组件 python-django 升级至 3.2.13-1 及以上版本

将组件 django 升级至 4.0.4 及以上版本

将组件 django 升级至 2.2.28 及以上版本

将组件 django 升级至 3.2.13 及以上版本

将组件 python-django-doc 升级至 3.2.13-1 及以上版本

将组件 python3-django 升级至 3.2.13-1 及以上版本

参考链接

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

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

https://www.djangoproject.com/weblog/2022/apr/11/security-releases/

情报订阅

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

具体订阅方式详见：

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

关注公众号

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

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

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

漏洞描述

Linux kernel 是一个免费开源的类Unix系统的内核。

Linux kernel 5.8 到 5.19.14 版本存在拒绝服务漏洞，本地攻击者可通过将恶意 WLAN 帧注入 mac80211 堆栈，从而导致 P2P 设备的信标保护的 NULL 指针取消引用，进而造成拒绝服务。

漏洞名称 Linux kernel 拒绝服务漏洞漏洞类型拒绝服务发现时间 2022-10-14 漏洞影响广度一般 MPS编号 MPS-2022-59483 CVE编号 CVE-2022-42722 CNVD编号 –

影响范围

Linux kernel@[5.8, 5.19.15)

修复方案

将组件 Linux kernel 升级至 5.19.15 及以上版本

参考链接

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

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

https://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless.git/commit/?id=b2d03cabe2b2e150ff5aea0be09f

情报订阅

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

具体订阅方式详见：

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

四、直播福利

福袋抽奖：直播中将有多轮抽奖，10 + 个中奖名额，参与就有机会获得 OSC T 恤、笔记本、小米保温杯、前沿技术书籍等。

关于 Apache ShenYu

Apache ShenYu 是一款使用 Java Reactor 开发的响应式 API 网关。以其高性能，动态灵活的流量管控，热插拔，易部署等特性，开箱即用的为用户提供整套全生命周期的 API 管理，包含 API 注册、服务代理、协议转换与 API 治理等功能。

关于 Dromara 开源社区

Dromara 是由国内顶尖的开源项目作者共同组成的开源社区。提供包括分布式事务，流行工具，企业级认证，微服务 RPC，运维监控，Agent 监控，分布式日志，调度编排等一系列开源产品，以及解决方案与咨询、技术支持与培训认证服务。

Dromara 开源社区目前拥有 10+GVP 项目，总 star 数量超过十万，构建了上万人的开源社区，有成千上万的个人及团队在使用 Dromara 社区的开源项目。

关于中国开源社区 Landscape 社区

COSCLC：中国开源社区 Landscape 社区，是以国内开源社区为单位的社区，旨在通过凝聚社区力量，推动国内开源生态发展。（COSCLC 具体章程等规划正在筹备中，近期公布。）

十月中旬，我们推出了 Gitea 1.17.3 版本。与此同时，1.18版本的新特性也几乎确定，追踪 Gitea 的代码仓库可以发现最新的 feature 大部分已进入冻结状态，相信不久之后会放出预览版，心急的小伙伴已经使用 Docker 快速切换到 Dev 分支尝鲜啦图片。

还在使用1.17.2以及更早版本的用户请尽快升级到1.17.3以获得最新的软件补丁。

从1.17.2到1.17.3版本完成了 29 次代码合并。其中包含了 3 项安全补丁、 3 项优化补丁、20 项 Bug 修复、补充1项单测试以及将 Go 版本从 1.17 升级到 1.19。

Security Thanks!

非常感谢 STAR Labs 旗下的 Ngo Wei Lin 报告了问题 #21465 和 #21464，并感谢 techknowlogick, wxiaoguang 和 6543 发送补丁来解决这些问题。

下载安装

您可以从下载页面下载预编译的二进制文件，请注意选择正确的操作系统。我们前面的文章介绍了在 Docker、Windows 和 Kubernetes上安装 Gitea 的方法，请随时翻阅。

• Gitea 中文文档：

支持我们

在此，我们感谢所有在 Open Collective 给予我们资金支持的贡献者。

您可以在官方商店 shop.gitea.io 购买周边来支持我们。

Changelog

1.17.3 – 2022-10-14

• SECURITY
- • Bump (#21412) (#21413)
- • Update bluemonday (#21281) (#21287)
- • Sanitize and Escape refs in git backend (#21464) (#21463)
• ENHANCEMENTS
- • Fix empty container layer history and UI (#21251) (#21278)
- • Use en-US as fallback when using other default language (#21200) (#21256)
- • Make the vscode clone link respect transport protocol (#20557) (#21128)
• BUGFIXES
- • Do DB update after merge in hammer context (#21401) (#21416)
- • Add Num{Issues,Pulls} stats checks (#21404) (#21414)
- • Stop logging CheckPath returns error: context canceled (#21064) (#21405)
- • Parse OAuth Authorization header when request omits client secret (#21351) (#21374)
- • Ignore port for loopback redirect URIs (#21293) (#21373)
- • Set SemverCompatible to false for Conan packages (#21275) (#21366)
- • Tag list should include draft releases with existing tags (#21263) (#21365)
- • Fix linked account translation (#21331) (#21334)
- • Make NuGet service index publicly accessible (#21242) (#21277)
- • Foreign ID conflicts if ID is 0 for each item (#21271) (#21272)
- • Use absolute links in feeds (#21229) (#21265)
- • Prevent invalid behavior for file reviewing when loading more files (#21230) (#21234)
- • Respect for packages (#20873) (#21232)
- • Treat git object mode 40755 as directory (#21195) (#21218)
- • Allow uppercase ASCII alphabet in PyPI package names (#21095) (#21217)
- • Fix limited user cannot view himself’s profile (#21212)
- • Fix template bug of admin monitor (#21209)
- • Fix reaction of issues (#21185) (#21196)
- • Fix CSV diff for added/deleted files (#21189) (#21193)
- • Fix pagination limit parameter problem (#21111)
• TESTING
- • Fix missing m.Run() in TestMain (#21341)
• BUILD
- • Use Go 1.19 fmt for Gitea 1.17, sync emoji data (#21239)

关注公众号

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

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

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

关注公众号

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

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

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

关注公众号

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

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

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

.NET 7 RC2 已作为 .NET 7 的最新候选版本（RC）发布，该版本已通过 Visual Studio 17.4 Preview 3测试，并在生产环境中得到支持。

适用于 Windows、macOS 和 Linux 的 .NET 7 RC2。如需在 Visual Studio 系列产品中试用 .NET 7，建议使用预览通道构建。如果使用 macOS，则建议使用最新的 Visual Studio 2022 for Mac 预览版。

.NET 7 RC 2 中的新增功能

为 System.Text.Json 源生成重新启用反射回退

.NET 7 引入了一项重大更改，该更改删除了 System.Text.Json 源生成器中基于反射的序列化的静默回退。但似乎有不少用户还在依赖回退行为。因此，从 .NET 7 RC 2 开始，用户可以使用 AppContext 兼容性开关，在全局范围内重新启用反射回退。

将以下条目添加到应用程序的项目文件中，可重新启用应用程序中所有源构建上下文的反射回退：

 <ItemGroup> <RuntimeHostConfigurationOption Include="System.Text.Json.Serialization.EnableSourceGenReflectionFallback" Value="true" /> </ItemGroup>

有关如何使用 AppContext 开关的详细介绍，请参阅 .NET 运行时配置设置。

正确实现通用数学接口（dotnet/runtime #69775）

确保使用奇异递归模板模式 (CRTP) 的 .NET 通用数学接口在用户代码中正确实现。如果实现 .NET 通用数学接口（实现 CRTP 架构）的类型未使用类型本身来填充泛型类型参数，它将发出警告。例如：

 public readonly struct DateOnly : IParsable<DateOnly> // correct implementation of IParsable<TSelf> interface { ... } public readonly struct MyDate : IParsable<DateOnly> // Warns: "The 'IParsable<TSelf>' requires the 'TSelf' type parameter to be filled with the derived type 'MyDate' " the type parameter TSelf { ... }

防止内置运算符中的行为更改 IntPtr 和 UIntPtr（dotnet/runtime #74022）

.NET 7 RC 2 相关链接：

安装程序和二进制文件
容器图像
Linux 软件包
发行说明
已知的问题
GitHub 问题跟踪器

其他内容可查看微软更新博客。

SQLAlchemy 是 Python SQL 工具箱和对象关系映射器，它为应用程序开发人员提供了 SQL 的全部功能和灵活性。它提供了一整套知名的企业级持久性模式，旨在高效、高性能地访问数据库，并被适配为一种简单的 Pythonic 域语言。

SQLAlchemy 1.4.42 现已发布。此版本包含了各种错误修复，主要是在 ORM 相关用例领域。还添加了两个新的与 ORM 相关的配置警告，指出在某些情况下使用不正确的 mappings 时可能会导致混淆行为的情况。公告指出，虽然某些现有设置可能具有这些模式中的任何一种并且会看到新的警告，但这些错误配置模式已经存在多年，并不表示现有应用程序有任何新问题。

此外，新版本还修复了在尝试连接到各种形式的 Azure 云数据库时有关 MSSQL 方言的持续回归；其中修复了一种类型的 Azure 数据库，然后引入了连接到另一种类型的新问题。开发团队表示，SQLAlchemy 项目没有针对这些数据库的直接测试资源，因此只能依靠用户反馈的来判断，但是很可能这些问题最终会在此版本中得到解决。

1.4.42 的完整变更日志可查看 Changelog。

下载页面

Linux 6.1-rc1 已发布。尽管合并期间 Linus 电脑内存损坏，但在紧急修复后，RC 版本还是如期发布了。

根据 Linus Torvalds 的说法， Linux 6.1-rc1 大约有 60% 的版本代码是新驱动程序，以提供更好的硬件支持，此外也包含架构更新、文件系统和工具改进，还有其他提高性能的改动。

这实际上并不是一个特别大的版本：在此合并窗口期间，我们“仅”有 11.5k 非合并提交，而上次为 13.5k。

所以 Linux 6.1 不算很小，但比最近几个版本小，至少在提交次数上如此。

我们有一些已经酝酿了很长时间的核心内容，最值得注意的是多代 LRU VM 系列，以及最初的 Rust 脚手架（内核中还没有真正的真正的 Rust 代码，但基础设施是那里）。

多代 LRU 是 Linux 6.1 最新合并的页面回收策略，可有效缓解低内存设备的高内存压力。Linux 6.1 最大的新特性是 Rust 基础架构代码的合并，包含对 Rust 编程语言的支持的基础设施，目前还不能用于现实用例。

Linux 内核 6.1 的稳定版本将在 12 月发布，根据内核开发人员 Greg Kroah-Hartman 的说法，由于 Linux 6.1 是今年最后一个主要的 Linux 内核版本，它应该会是下一个 LTS 系列。

Apache Wicket 是一个开源的面向 Java 组件的 Web 应用框架，为政府、商店、大学、城市、银行、电子邮件提供商等成千上万的 Web 应用和网站提供支持。Wicket 的开发中使用了语义版本，因此与 9.0.0 相比，9.12 版本没有出现 API 中断。

Apache Wicket 9.12.0 是一个次要版本，具体更新内容包括：

Bug

[WICKET-6955] – Wicket 使用不稳定的 slf4j 版本
[WICKET-6996] – KeyInSessionSunJceCryptFactory 附近的 NotSerializableException
[WICKET-6999] – 缺少名称中带有“internal”的软件包的 Export-Package
[WICKET-7007] – CSRF 文档修复的 Code snippets

Improvement

[WICKET-6958] – 允许在 OSGi 运行时使用 Slf4j 1.7.x
[WICKET-6982] – ListenerRequestHandler 中的 stateful pages 的不必要初始化
[WICKET-6998] – 将 slf4j-api 升级到 2.0.0
[WICKET-7000] – ParseException (“Malformed tag”) if
[WICKET-7002] – 应用程序数据访问不需要同步
[WICKET-7003] – http RequestLogger 非常 expensive #524
[WICKET-7004] – Jetty 配置示例包含安全隐患
[WICKET-7008] – LoadableDetachableModel.toString() 应该反映实际的变量名称

更多详情可查看：https://wicket.apache.org/news/2022/10/15/wicket-9.12.0-released.html

关注公众号

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

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

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

Snowy 是国内首个采用国密技术为核心的前后分离后台权限管理系统，同时也是面向中小企业快速开发平台框架。框架采用主流技术开发设计，支持国产中间件、麒麟操作系统、Windows、Linux 部署使用，框架使用 SM2、SM3、SM4 等国密算法进行签名、数据完整性保护，软件层面完全符合等保、密评要求。

此次发布 2.0.3 主要更新请看以下：

【修复】修复C端用户接口解密失败的bug
【更新】更新用户界面编辑后，因任职机构传输null字符串，导致回显错误问题
【修复】删除角色时应该级联删除角色与权限关系
【更新】升级satoken为1.31.0
【更新】升级springboot为2.5.12，与satoken依赖boot版本一致，防止log4j漏洞风险
【更新】升级spring-boot-maven-plugin为2.5.12
【更新】文件、短信、邮件、站内信的重要接口仅超管可访问，非重要接口登陆后即可访问
【更新】更新mp配置，新增oracle.nls.orai18n编码包
【更新】更新 issues 中 #I5V6OD:菜单管理选中新创建的模块，菜单列表不为空:菜单管理选中新创建的模块，菜单列表不为空菜单管理选中新创建的模块，菜单列表不为空问题
【更新】更新 issues 中 #I5TY0J:文件上传异常:文件上传异常文件配置中修改了上传路径，但是缓存中没有更新问题，去掉前端上传成功后的提醒为刷新列表

> 可以直接覆盖更新，无需更新sql文件

平台定位

构建成熟的、完善的、全面的，基于 OAuth2.1 的、前后端分离的微服务架构解决方案。
面向企业级应用和互联网应用设计开发，既兼顾传统项目的微服务化，又满足互联网应用开发建设、快速迭代的使用需求。
平台架构使用微服务领域及周边相关的各类新兴技术或主流技术进行建设，是帮助快速跨越架构技术选型、研究探索阶段的利器。
代码简洁规范、结构合理清晰，是新技术开发应用的典型的、综合性案例，助力开发人员对新兴技术的学习和掌握。

[1]、为什么更名为 Dante Cloud

更名为 Dante Cloud，寓意本项目会像恩格斯对但丁的评价一样，在行业变革的时期，可以成为一款承上启下，助力企业信息化建设变革的产品。

[2]、本次更新内容

【重要更新】
- [新增] 扩展 Spring Authorization Server 授权码模式(AuthorizationCode), 在授权码模式返回 Token 中增加系统用户信息，减少二次请求获取用户信息
- [新增] 在原有 ResourceOwnershipPassword、SocialCredentials 认证模式基础上，补充增加 OIDC IdToken 支持。
- [新增] 扩展 OIDC IdToken 及 OIDC /userinfo 端点信息内容，与现有用户权限体系融合，支持使用 Opaque Token 读取并解析用户信息。
- [优化] 整体优化 AuthorizationCode、ClientCredentials、ResourceOwnershipPassword、SocialCredentials 四种认证模式，除保留原有 JWT Token 的所有支持内容外，对 OIDC IdToken、Opaque Token 与现有权限体系进行了全面融合与支持
- [安全] 修复 jackson-databind 拒绝服务漏洞 (CVE-2022-42003)
【其它更新】
- [重构] 重构自定义 AuthorizationCode、ClientCredentials、ResourceOwnershipPassword、SocialCredentials 四种认证模式代码，抽象创建 AccessToken、RefreshToken、IdToken 等操作公共代码，代码逻辑更清晰易懂，同时减少重复冗余代码。
- [重构] 重构 oauth2ResourceServer 配置代码，统一资源服务器 Opaque Token 和 JWT Token 切换策略化配置逻辑。
- [修复] 在 OAuth2 OIDC 认证方式下，/userinfo 接口调用始终为 401 问题
- [修复] 修复开启 Session 共享功能后，Gateway Session 相关内容注入重复冲突问题。
- [修复] 在 AuthorizationCode、SocialCredentials 认证模式下，前端菜单加载异常问题。
- [新增] 前端新增 Spring Authorization Server 授权码模式(AuthorizationCode) 登录方式。
- [新增] 优化前端 OAuth2 认证所有接口代码，新增 OIDC IdToken 开关配置，在前端即可根据使用需求决定使用 OIDC (OpenID Connect) 模式还是传统 OAuth2 模式。
- [优化] 优化前后端用户基本信息提供和使用机制。后端会根据前端 IdToken 开启与否状态，策略化提供 IdToken 或自定义 Token 补充用户信息(注：两种方式均无需通过二次请求后端获取用户信息)。
- [优化] 前端 echarts 使用方式，变更为按需加载，解决前端工程调试过程中，Dashboard 页面加载缓慢问题。
- [优化] 优化单体版 application.yml 配置
【依赖更新】
- [升级] commons-text 版本至 1.10.0
- [升级] tencentcloud-sdk-java-sms 版本至 3.1.608
- [升级] alipay-sdk-java 版本至 4.34.14.ALL

[3]、Dante Cloud 2.7.X 特点

一、前端

未使用任何流行开源模版，使用全新技术栈，完全纯”手写”全新前端工程。
借鉴参考流行开源版本的使用和设计，新版前端界面风格和操作习惯尽量与当前流行方式统一。
充份使用 Typescript 语言特性，解决大量类型校验问题，尽可能规避 “any” 式的 Typescript 编程语言使用方式。
充份使用 Composition Api 和 Hooks 等 Vue3 框架新版特性进行代码编写。
充份利用 Component、Hooks 以及 Typescript 面向对象等特性，抽取通用组件和代码，尽可能降低工程重复代码。
对较多 Quasar 基础组件和应用功能组件进行封装，以方便代码的统一修改维护和开发使用。
对生产模式下，对基于 Vite3 的工程打包进行深度性能优化。
提供以 docker-compose 方式，对工程生产代码进行容器化打包和部署。
支持密码模式、授权码模式、手机短信模式、第三方社会化等多种登录模式。

二、后端

基于深度定制和扩展:

基于和实现多租户系统架构，支持 Database 和 Schema 两种模式。
基于，重新构建基础数据存储代码，替代原有 JDBC 数据访问方式，破除原有数据存储局限，扩展为更符合实际应用的方式和设计。
基于，在 OAuth 2.1 规范基础之上，增加自定义 (密码)认证模式，以兼容现有基于 OAuth 2 规范的、前后端分离的应用，支持 Refresh Token 的使用。
基于，在 OAuth 2.1 规范基础之上，增加自定义 (社会化登录)认证模式，支持手机短信验证码、微信小程序、基于JustAuth的第三方应用登录，支持 Refresh Token 的使用。
扩展默认的模式，实现模式支持 Refresh Token 的使用。
扩展默认的模式，实现真正的使用 Scope 权限对接口进行验证。增加客户端 Scope 的权限配置功能，并与已有的用户权限体系解耦
支持认证模式
支持的标准的 JWT Token 加密校验方式外，新增基于自定义证书的 JWT Token 加密校验方式，可通过配置动态修改。
支持 Opaque Token (不透明令牌) 格式及校验方式，将低 JWT Token 被捕获解析的风险。可通过修改配置参数，设置默认Token 格式是采用 Opaque Token 格式还是 JWT Token 格式。
全面支持 OpenID Connect (OIDC) 协议, 系统使用时可根据使用需求，通过前端开关配置，快速切换 OIDC 模式和传统 OAuth2 模式
深度扩展、、几种模式，全面融合 IdToken、Opaque Token、JWT Token 与现有权限体系，同时提供 IdToken 和自定义Token 扩展两种无须二次请求的用户信息传递方式，减少用户信息的频繁请求。
自定义授权码模式登录认证页面和授权确认页面，授权码模式登录采用数据加密传输。支持多种验证码类型，暂不支持行为验证码。
基于 JetCache 的多级缓存支持，实现自定义二级缓存，有效解决 Spring Cache 查询缓存更新问题。
全面整合注解权限与权限，通过后端动态配置，无须在代码中配置权限注解以及权限方法，即可实现接口鉴权以及权限的动态修改。采用分布式鉴权方案，规避 Gateway 统一鉴权的压力以及重复鉴权问题
采用分布式服务独立鉴权方案，的权限注解、权限方法以及权限，通过后端动态配置后，实时动态分发至对应服务。
核心数据支持直连数据库获取和远程调用两种模式。直连数据库模式性能更优，访问远程调用可扩展性更强。可通过配置动态修改采用策略方式。
基于自定义 Session，混合国密 SM2(非对称) 和 SM4(对称加密) 算法，实现秘钥动态生成加密传输。利用“一人一码机制”，实现密码模式登录数据进行动态加密传输。配合验证，保护接口调用和前后端数据传输的合理性及安全性。

[4]、界面预览

Dromara 开源社区

一、社区愿景

让每一位开源爱好者，体会到开源的快乐。

二、社区官网

https://dromara.org 是 Dromara 开源社区官方网站。

三、成员项目

一、为何要使用标签评分？

经过前期标签体系设计、标签加工，标签终于可以上线，让业务人员使用，发挥价值了！

二、标签评分模型

标签评分模型，经过考虑我们选取了5个维度作为评分入参：

标签总评分= a * 标签使用度评分 + b * 标签关注度评分 + c * 标签质量评分 + d * 标签持续优化读评分 + e * 标签安全度评分

01 标签使用度评分

标签使用度，用以评估标签被分析、外部系统的使用情况。

在袋鼠云标签产品中，标签有这几种使用场景：

• 标签引用：如原子标签被衍生标签应用、衍生标签被组合标签引用等，基于该场景，计算“标签引用次数”指标。

• 标签分析：标签在标签圈群、群组画像、群组对比、显著性分析等画像分析功能中被分析的情况，计算“标签分析次数”指标。

• 标签调用：标签通过数据API被外部应用查询的次数，计算“标签调用次数”指标。

基于以上3个指标，我们首先采用Sigmoid函数将指标转化为评分，再将各个指标的评分加权汇总成标签使用度评分。

02 标签关注度评分

标签关注度，用以评估被搜索、查看、收藏的情况。

袋鼠云标签产品中，标签关注度与以下场景有关：

• 标签搜索：标签在标签市场被用户搜索的情况，计算“标签搜素次数”指标。

• 标签查看：标签被查看基础信息、分析页面等的次数，计算“标签查看次数”指标

• 标签收藏：收藏该标签的用户数，计算“收藏用户数”指标

以上3个指标可反映标签的关注热度，我们依然采用Sigmoid函数将指标转化为评分，再将各个指标的评分加权汇总成标签关注度评分。

03 标签质量评分

标签质量，用以评估用户被打标情况，反映标签规则的合理性。

系统将计算每个标签的“标签覆盖度”，将覆盖度归一化为分数，转化成评分。

04 持续优化度评分

持续优化度，用以评估标签上线后，是否后续再去优化该标签。

持续优化度，我们通过“标签优化次数”指标来评估，指标签上线后标签被编辑再次发布的的次数。我们同样采用Sigmoid函数将指标转化为评分。

05 安全度评分

标签安全度，不能反映标签的热度，但也将其作为了标签评分的一个维度，可根据企业情况考虑是否纳入。

在袋鼠云标签产品中，标签安全相关的策略有：

• 标签的可见度：标签可编辑、可查看的用户范围

• 标签使用是否需要申请授权：标签发布后，其他人使用该标签，是否需要申请审批

• 标签是否进行行级权限控制：上面我们控制了标签的列权限，行级权限反映该标签是否设置了行级权限

• 标签是否脱敏：标签是否进行脱敏

根据标签的安全度策略配置情况，我们也采用评分的方式来评估。

基于以上5个维度的评分，我们根据前面提的公式加权汇总，得到总评分。

三、标签评分的应用

基于标签评分，为了更加直观的让标签管理员、业务人员查看热门标签、沉默标签等，通过排行榜的方式呈现：

01 热门标签排行榜

基于标签的使用度、关注度、持续优化度3个角度来计算标签的热门评分，展示TOP N的热门标签。

02 沉默标签排行榜

热门的标签的反向排序便是沉默标签，沉默标签说明这些标签使用率很低，可考虑定期下线，节省集群资源。

03 综合排行榜

综合排行榜便根据标签的综合评分进行排序，从标签使用度、关注度、持续优化度、质量、安全等几个维度评估，全面评估标签。

04 标签使用度、关注度、持续有优化度、质量、安全分榜单排行

以上便是在产品中应用的评分逻辑，希望对大家有所帮助，也可提出不同思路优化评分模型，达到更好的标签治理效果。

袋鼠云开源框架钉钉技术交流群（），欢迎对大数据开源项目有兴趣的同学加入交流最新技术信息，开源项目库地址：https://github.com/DTStack/Taier

108 是一个在浏览器中运行的的最小节拍机，具有 5 个经典音效样本，这些音效可以安排在一个运行 108 bpm 的 16 步循环圈子，应用会自动按顺序播放你写出来的旋律。

可以使用键盘上的 C V B N M 五个键来在圈内新增音效， Z 删除之前添加的音效，X 清除整个音效序列，空格开始/停止播放， SHIFT 切换节拍器。

一个涛思数据的 Fun Fact：TDengine 工程师平均年龄刚好 35 岁。

这也是他对于工程师唯一的要求，年龄这件事在 TDengine，从来都不是一件评判你技术好坏的标准。

本文来源于开源集《开源观止》第 4 期，更多精彩内容，请下载：

https://oscimg.oschina.net/public_shard/opensource-guanzhi-.pdf

谷歌宣布推出安全操作系统 KataOS，作为他们最新专注于运行环境侧重于机器学习工作负载的嵌入式设备的操作系统。出于将安全性放在首位的宗旨，KataOS 专门使用 Rust 语言开发，并基于 seL4 微内核进行了构建。

通过 seL4 CAmkES 框架，我们还能够提供静态定义和可分析的系统组件。KataOS 提供了一个可验证安全的平台来保护用户的隐私，因为应用程序在逻辑上不可能违反内核的硬件安全保护，并且系统组件是可验证安全的。KataOS 也几乎完全用 Rust 实现，它为软件安全性提供了一个强有力的起点，因为它消除了 entire classes 错误，如 off-by-one errors 和缓冲区溢出。

目前，谷歌已经在 GitHub 开源了大部分 KataOS 核心部分。具体包括用于 Rust 的框架（例如 sel4-sys crate，它提供了 seL4 系统调用 API），一个用 Rust 编写的备用 rootserver（用于动态系统范围的内存管理），以及对 seL4 的内核修改，可以回收 rootserver 使用的内存。

谷歌方面透露，在内部，KataOS 还能够动态加载和运行在 CAmkES 框架之外构建的第三方应用程序。但运行这些应用程序所需的组件暂时还未开源，他们计划或将在不久的未来发布这些功能。

为了完整地证明一个安全的环境系统，谷歌还为 KataOS 构建了一个名为 Sparrow 的参考实现，它将 KataOS 与一个安全的硬件平台相结合。因此，除了逻辑安全的操作系统内核之外；Sparrow 还包括一个逻辑安全的信任根，该信任根是使用 OpenTitan 在 RISC-V 架构上构建的。但是就初始版本而言，其目标是使用 QEMU 在模拟中运行更标准的 64 位 ARM 平台。

公告称，谷歌的目标是开源所有 Sparrow，包括所有硬件和软件设计；现下发布的 KataOS 早期版本只是一个开始。

导读：欢迎来到 StarRocks 技术内幕系列文章，我们将为你全方位揭晓 StarRocks 背后的技术原理和实践细节，助你从 0 开始快速上手这款明星开源数据库产品。本期 StarRocks 技术内幕将主要介绍 StarRocks Pipeline 执行框架的基本概念、原理及代码逻辑。

#01

背景介绍

—

Pipeline 调度与 MPP 调度之间存在着明显的差异，前者是单机多核调度，后者是分布式集群的多机调度。总结下来，Pipeline 调度的目的包括三点：

1. 降低计算节点的任务调度代价；

2. 提升 CPU 利用率；

3. 充分利用多核计算能力，提升查询性能、自动设置并行度、消除人为设置并行度的不准确性。

本文将主要介绍 Pipeline 执行框架的基本概念、原理以及代码逻辑，帮助读者快速入门 StarRocks 的 Pipeline 执行框架，通过阅读本文，你将掌握：

1. 如何在 Pipeline 执行框架中添加算子；

2. Source 算子和 Sink 算子如何异步化；

3. 怎么将单机执行计划拆分成 Pipeline；

4. 添加新的表达式或者函数需要主要的方面。

#02

基本概念

—

在深入 Pipeline 执行框架的细节之前，我们先来了解一下整体所需的基本概念。这些基本概念，共同构成了 Pipeline 执行框架的底层，建议大家掌握清楚。

1、MPP 调度基本概念

物理执行计划(ExecPlan)

物理执行计划是 FE 生成的，由物理算子构成的执行树；SQL 经过 parse、anlyze、rewrite、optimize 等阶段处理，最终生成物理执行计划。

计划碎片(PlanFragment)

PlanFragment 是物理执行计划的部分。只有当执行计划被 FE 拆分成若干个 PlanFragment 后，才能多机并行执行。PlanFragment 同样由物理算子构成，另外还包含 DataSink，上游的 PlanFragment 通过 DataSink 向下游 PlanFragment的 Exchange 算子发送数据。

碎片实例(Fragment Instance)

Fragment Instance 是 PlanFragment 的一个执行实例，StarRocks 的 table 经过分区分桶被拆分成若干 tablet，每个 tablet 以多副本的形式存储在计算节点上，可以将 PlanFragment 的实例化成多个 Fragment Instance 处理分布在不同机器上的 tablet，从而实现数据并行计算。FE 确定 Fragment Instance 的数量和执行 Fragment Instance 的目标 BE，然后 FE 向 BE投递 Fragment Instance。在 Pipeline 执行引擎中，BE 上的 PipelineBuilder 会把 PlanFragment 进一步拆分成若干 Pipeline，每个 Pipeline 会根据 Pipeline 并行度参数而被实例化成一组 PipelineDriver， PipelineDriver 是 Pipeline 实例，也是 Pipeline 执行引擎所能调度的基本任务。

物理算子(ExecNode)

物理算子是构成物理执行计划 PlanFragment 的基本素，例如 OlapScanNode，HashJoinNode 等等。

2、FE 负责 MPP 调度

我们以下面的简单 SQL 为例，进一步说明上述概念：

第一步：FE 产生物理计划并且拆分 PlanFragment，如下图所示，物理计划被拆分成三个 PlanFragment，其中 Fragment 1 包含 HashJoinNode，Fragment 0 为 HashJoinNode 的右孩子。

第二步：FE 确定 PlanFragment 的实例数量，创建 Fragment Instance。如果一个 Fragment Instance 把另外一个 Fragment Instance 的输出结果作为输入，则产生数据的一方为上游，输入数据的一方为下游，上游插入 DataStreamSink 用来发送数据，下游插入 ExchangeNode 算子用来接收数据。如下图所示，其中 PlanFragment 1 有 3 个 Fragment Instance。

第三步：FE 将所有 Fragment Instance，一次性(all-at-once)投递给 BE，BE 执行 Fragment Instance。

3、Pipeline 调度基本概念

Pipeline

Pipeline 是一组算子构成的链，开始算子为 SourceOperator，末尾算子为 SinkOperator。Pipeline 中间的算子只有一个输入端和输出端。

SourceOperator 作为 Pipeline 的起始算子，为 Pipeline 后续算子产生数据，SourceOperator 获取数据的途经有：

1. 读本地文件或者外部数据源，比如 ScanOperator；

2. 获得上游 Fragment Instance 的输出数据，比如 ExchangeSourceOperator；

3. 获得上游 Pipeline 的 SinkOperator 的计算结果，比如 LocalExchangeSourceOperator。

SinkOperator 作为 Pipeline 的末尾算子，吸收 Pipeline 的计算结果，并输出数据，输出途经有：

1. 把计算结果输出到磁盘或者外部数据源，”比如OlapTableSinkOperator, ResultSinkOperator”；

2. 把结果发给下游 Fragment Instance，比如 ExchangeSinkOperator；

3. 把结果发给下游 Pipeline 的 SourceOperator，比如 LocalExchangeSinkOperator；

Pipeline 的中间算子，既可获得前驱算子的输入，又可以输出数据给后继算子。

Pipeline 计算时，从前向后，先从 SourceOperator 获得 chunk，输出给下一个算子，该算子处理 chunk，产生输出 chunk，然后输出给再下一个算子，这样不断地向前处理，最终结果会输出到 SinkOperator。对于每对相邻的算子， Pipeline 执行线程调用前一个算子 pull_chunk 函数获得 chunk，调用后一个算子的 push_chunk 函数将 chunk 推给它。Pipeline 的 SinkOperator 可能需要全量物化，而其他算子，则采用 chunk-at-a-time 的方式工作。

以 TPCH-Q5 为例，执行计划，可以划分成若干条 Pipeline，Pipeline 之间也存在上下游数据依赖。如下图所示：

P2 依赖 P1
P3 依赖 P2
P6 依赖 P3，P4，P5
P7 依赖 P6
P8 依赖 P7

PlanFragment 为树状结构，需要进一步转换为 Pipeline。转换工作由 BE 上的 PipelineBuilder 完成，FE 本身对 Pipeline 无感知。一个 PlanFragment 可以拆分成若干条 Pipeline，相应地，PlanFragment 中的物理算子也需要转换为 Pipeline 算子，比如物理算子 HashJoinNode 需要转换为 HashJoinBuildOperator 和 HashJoinProbeOperator。

Pipeline 算子

Pipeline 算子是组成 Pipeline 的素，BE 的 PipelineBuilder 拆分 PlanFragment 为 Pipeline 时，物理算子需要转换为成 Pipeline 算子。

Pipeline 实例 (PipelineDriver)

PipelineDriver 是 Pipeline 实例，一条 Pipeline 可以产生多个 PipelineDriver。在代码实现中，Pipeline 由一组 OperatorFactory 构成， Pipeline 可以调用 OperatorFactory 的 create 方法，生成一组 Operator，这组 Operator 即构成 PipelineDriver。如下图所示，根据 dop=3(degree-of-parallelism)，Pipeline 实例化 3 条 PipelineDriver，输入数据也被拆分成三部分，每个 PipelineDriver 各自处理一部分。

PipelineDriver 也是 Pipeline 执行引擎的基本调度单位，其本质上是一个协程，具有三种状态：Ready、Running 和 Blocked。

1. Pipeline 执行线程从就绪队列获得处于 Ready 状态的 PipelineDriver，设置状态为 Running，并执行；

2. PipelineDriver 自身不会阻塞并挂起执行线程，因为它的阻塞操作(比如网络收发，获取 Tablet 数据，读外表由其他的线程异步化处理。PipelineDriver 发起阻塞操作后，状态会被执行线程标记为 Blocked，并且主动让出 (yield)CPU，放回阻塞队列，执行线程从就绪队列选择其他的 PipelineDriver 执行。

3. 当 PipelineDriver 执行时间超过规定的时间片(如20ms)，则 PipelineDriver 也会 yield，此时 PipelineDriver 会被标记为 Ready 状态访问就绪队列，切换其他 Ready 状态的 PipelineDriver 执行。如下图所示：

Running：PipelineDriver 在当前执行线程中执行，执行线程反复调用相邻算子的 pull_chunk/push_chunk 函数移动 chunk。
Blocked：PipelineDriver 处于阻塞状态，等待就绪事件，此时 PipelineDriver 不占用执行线程，被放置在阻塞队列中，由专门的 Poller 线程持续检查 PipelineDriver 的状态，当 PipelineDriver 等待的事件就绪后，状态设置为 Ready，放回就绪队列。
Ready：PipelineDriver 执行时间超过时间片，会被放回就绪队列；阻塞解除的 PipelineDriver 也会放回就绪队列。执行线程从就绪队列中获得 PipelineDriver 并执行。执行线程的数量为计算节点 BE 的物理核数，而同时 BE 需要调度的 PipelineDriver 可能成千上万，因此执行线程是全局资源，跨所有查询，被所有的 PipelineDriver 所复用(multiplexing)。

Pipeline 引擎中协程调度模型和传统的线程调度模型的主要区别是，前者实现了用户态的 yield 语义，而后者依赖 OS 的线程调度，在高并发场景下的频繁的上下文切换增加了调度成本，降低了 CPU 的有效利用率。如下图所示:

阻塞操作异步化

实现 Pipeline 执行引擎的协程调度，最为关键处理是阻塞操作异步化，如果没有实现异步化，PipelineDriver 的阻塞操作会导致执行线程陷入内核挂起，退化为 OS 线程调度。为了避免执行线程的上下文切换，需要控制执行线程的数量不超过物理核数，并且执行线程为跨查询的全局资源，这种阻塞挂起会显著影响 CPU 利用率和其他 PipelineDriver 的调度。因此，涉及阻塞的操作，需要异步化处理，例如：

1. ScanOperator 读 Tablet 数据，访问磁盘。

2. ExchangeSinkOperator 发送数据，ExchangeSourceOperator 接收数据。

3. HashJoinProbeOperator 所在 PipelineDriver 等待 HashJoinBuildOperator 完成 HashTable 的构建和 RuntimeFilter 的生成。

4. 需要全量物化的物理算子拆分成一对 SinkOperator 和 SourceOperator，其中 SinkOperator 位于上游的 Pipeline，而 SourceOperator 位于下游的 Pipeline，SourceOperator 需要等待 SinkOperator 算子完成。比如物理算子 AggregateBlockingNode 转换为 Pipeline 引擎的 AggregateBlockingSinkOperator 和 AggregateBlockingSourceOperator，后者需要等待前者完成。

4、BE 负责 Pipeline 调度

BE 执行 PipelineDriver 使用两种类型的线程和两种队列，分别为 Pipeline 执行引擎的工作线程 PipelineDriverExecutor、阻塞态 PipelineDriver 的轮询线程 PipelineDriverPoller。队列分别为就绪 Driver 队列(Ready Driver queue)和阻塞 Driver 队列(Blocked Driver queue)，如下图所示：

执行线程 PipelineDriverExecutor：不断地从就绪 Driver 队列中获得就绪态的 PipelineDriver 并执行，把主动让出 CPU 的PipelineDriver 再次放回就绪 Driver 队列，把处于阻塞态 PipelineDriver 放入阻塞 Driver 队列。
轮询线程 PipelineDriverPoller：不断地遍历阻塞 Driver 队列，跳过仍然处于阻塞态的 PipelineDriver，将解除阻塞态的 PipelineDriver，设置为 Ready 状态，放回就绪 Driver 队列。

本文主要讲解了 Pipeline 执行引擎想解决的问题及一般性原理。

关于 Pipeline 执行引擎的实现， BE 端拆分 Pipeline 的逻辑，以及 Pipeline 实例 PipelineDriver 的调度执行逻辑， StarRocks Pipeline 执行框架（下）见！

读到这里，好学的你是不是又产生了一些新思考与启发？扫描下方用户群二维码加入 StarRocks 社区一起自由交流！

关于 StarRocks

面世两年多来，StarRocks 一直专注打造世界顶级的新一代极速全场景 MPP 数据库，帮助企业建立“极速统一”的数据分析新范式，助力企业全面数字化经营。

当前已经帮助腾讯、携程、顺丰、Airbnb 、滴滴、京东、众安保险等超过 170 家大型用户构建了全新的数据分析能力，生产环境中稳定运行的 StarRocks 服务器数目达数千台。

2021 年 9 月，StarRocks 源代码开放，在 GitHub 上的星数已超过 3200 个。StarRocks 的全球社区飞速成长，至今已有超百位贡献者，社群用户突破 7000 人，吸引几十家国内外行业头部企业参与共建。

近年来，随着银行业务场景的不断丰富、业务规模的不断扩张，用户线上线下交易大幅上升，数据量与数据种类愈加丰富，大量创新型数据分析和应用场景出现，对分析型数据库的存储与计算能力提出了更复杂的需求，尤其在对实时数据价值的深入挖掘、数据库查询与分析性能的提高上提出了更高要求。为满足以上需求，银行纷纷开始重塑数据库体系，对已有分析型数据库进行改造，在支撑业务需求的同时简化架构。

近日，专注于数字化市场的研究咨询机构爱分析深入调研了行业中一批国内领先的银行数字化转型实践案例，围绕实践领先型、案例创新性、应用成熟度、价值创造四个维度对多个实践案例进行评选，经过多轮评选与角逐，由StarRocks提供技术支持的“中原银行OLAP全场景架构解决方案”案例凭借其完整且个性化的实施方案、卓越的项目效果当选优秀创新实践案例。该案例中，中原银行借助StarRocks对数据分析架构进行改造升级，构建了全新的数据分析平台，从而提高用数效率，赋能银行经营管理与业务发展。

#01

数据量激增，业务场景多化，中原银行数据平台需升级

—

中原银行成立于2014年，是河南省唯一一家省级法人银行，今年经改革重组后，该银行总资产规模已突破1.2万亿，下辖18家分行，有400余家营业网点，2万余名员工以及17家附属机构，目前已成为河南省首家资产超万亿的城商行。

随着业务不断扩张、数据量的高速增长以及业务逻辑复杂程度的不断提升，银行需要更加快速地响应客户，为其提供更加精准的服务，即使用实时数据进行客户洞察，以帮助银行经理与业务人员做出业务决策，提高管理水平。为此，中原银行搭建了一站式商业智能BI平台，该平台分为客户行为分析系统知秋、一站式报表平台鲁班、一站式大屏平台鸿图和自助分析平台云间四大应用系统，总用户超一万人，月活用户在3000以上，月均次数为20万以上，用户规模大且使用频率高。

为支持BI平台的快速高效工作，中原银行还搭建了完整的数据平台。该数据平台分为数据源、数据传输、数据存储计算、数据服务与数据应用五大部分。数据源是通过Oracle数据库对核心数据、信贷数据、绩效数据等进行存储。数据传输主要依赖中原银行自主研发的百川离线同步平台与实时传输AR平台。存储计算层主要分为数据湖、离线数仓与实时数仓三部分。其中，数据湖对半结构化数据、非结构化数据和部分系统日志与历史数据进行存储；离线数仓是基于Gauss DB完成跑批作业，对数据进行层层加工传输到读集群中以供报表查询；实时数仓则是对实时数据进行处理辅助进行实时决策。数据服务主要为对存储的报表、分析计算的数据进行查询。数据应用层面向银行客户经理，包括商业智能BI平台与业绩分析等应用系统。

（中原银行改造前的OLAP平台架构）

虽然已有商业智能BI平台与大数据平台已经能够解决中原银行大部分业务问题，但随着数字化转型逐步步入深水区，各业务场景对用数效率提出了更高要求。具体体现在：

查询效率亟需提高。中原银行原有的基于MPP和Hadoop构建的数据平台查询效率较低，尤其是多表关联查询效率，BI平台的平均耗时超10秒，知秋系统平均耗时长达20秒以上，严重影响了对客户的深入洞察分析与对银行经营状况的管理。因此，该银行需要提高对业务、经营管理等数据的查询能力，尤其是对复杂的关联数据的查询能力，为其良好的分析性能提供保障。
需要升级数据平台架构，深入挖掘实时数据的价值。基于原有的数据平台架构，仅能支持T+1小时级别的准实时报表，需要等待最新的小时任务跑批完成，才可以查询最新时间的数据，难以满足银行在客户分析、风控管理等场景下的实时查询与分析需求。并且，原有架构中需要经过Oracle-AR数据传输平台-Kafka-Flink-Kafka的长链路才能实现对实时数据的查询与分析。因此，银行需要全面升级数据平台架构，尤其是数据分析层的架构，从而满足业务增长带来的实时需求。
需要统一数据架构，降低运维成本。原有数据平台流批链路复杂，运维成本高，且实时数据与离线数据的存储并不统一，存在冗余，造成存算资源的浪费。因此，中原银行需要简化数据平台架构，对离线数据与实时数据进行统一高效管理。

#02

多维度综合考察，最终选择StarRocks升级OLAP架构

—

基于以上需求，中原银行决定对原有数据平台中数据分析架构进行全面升级与改造，以保证数据的统一管理与高效应用，提升实时响应能力。

经过调研了市面上的主流的两款OLAP数据库产品发现，ClickHouse在单表查询和大宽表查询表现优秀，查询延迟也比较低，但是Join性能较差，且不易维护；StarRocks在固化查询和灵活分析性能表现不错，多表查询性能也比较优秀，而且同时支持实时与离线导入分析场景。与此同时，StarRocks分析型数据库具有流批一体、能够向量化执行、运维简单、查询效率高、兼容性好且能够满足高并发查询要求六大优势，恰好满足了中原银行构建极速统一的数据分析架构的业务需求。

具体而言，该数据库支持实时和批量两种数据导入方式，以实现极速统一分析；全面采用向量化技术，适配CPU的SIMD指令集等手段，充分发挥其并行计算能力；安装部署容易，高可用易拓展，且扩缩容期间无需停服；能够智能物化视图，通过智能CBO优化器提供亚秒级的多维分析能力；能兼容MySQL协议语法与MySQL生态，使用者可快速上手；同时，还能为客户提供高性能高并发的交互式分析体验，查询QPS高于平均水平。六大优势相辅相成，恰好满足了中原银行构建极速统一的数据分析架构的业务需求。

（中原银行OLAP查询引擎选型对比表）

通过POC测试StarRocks分析型数据库的数据导入性能、查询响应速度、与知秋客户洞察系统匹配程度发现，该数据库能够满足极端业务的数据导入性能要求，大幅度提高知秋系统转化分析、客群分群查询、活跃用户查询等应用查询效率，且与银行原有MPP数据库相比，平均性能可以提高3.87倍。

StarRocks 以“打造新一代极速全场景 MPP 数据库，面向复杂查询、高并发、实时分析等各类场景以达成数据价值的最大化”为原则，不断打磨产品，即将面世的 StarRocks 3.0 致力于支持用户同时进行极速分析与极速数据湖分析。StarRocks还坚持发展生态，多方合作以壮大社区，阿里云计算平台事业部产品解决方案总经理陈立就曾表示“StarRocks 是阿里云在数据湖 3.0 云原生化、弹性化、实时化的重要产品之一”。截至目前，StarRocks已帮助超过170家大型企业构建了全新的数据分析能力，生产环境中运行的StarRocks服务器数目达数千台，其社区用户也已超7000人，吸引几十家国内外行业头部企业参与共建。

综合以上结果，中原银行最终选择了产品成熟度高、技术栈与银行主流技术相符、功能完善、安全性高、查询效率高、社区活跃度高的StarRocks分析型数据库。

#03

StarRocks助力中原银行分阶段升级OLAP架构

—

完成选型后，中原银行开始进行OLAP架构改造。此项目分为三个阶段：集群搭建、离线业务实践与实时业务实践。

（数据分析架构改造路径）

集群搭建

集群搭建是改造前的准备工作，包括与离线传输平台百川、流计算平台的对接，StarRocks集群的规划与搭建，机器资源的申请与分配，此阶段为数据分析架构升级的有序进行奠定了基础。

离线业务实践

为解决对离线数据查询效率低与分析性能差的问题，中原银行将固定离线报表迁移至StarRocks，并对知秋客户行为分析系统进行改造。

该银行的固定报表分为灵活分析、透视分析、电子表格、可视化报表四种形式，共计2800多张，广泛应用于对公、零售、绩效、风险、系统指标监控多个场景下。通过更新建表语句、将原有函数转化为StarRocks内部函数，中原银行实现了固定离线报表的自动化迁移。

（固定离线报表迁移方案）

迁移后的报表具有三大特性。首先，排序列前引入了前缀索引，能够快速过滤数据，减少数据扫描量，从而快速找到起始的目标行；其次，选择了高基数的列（如唯一的ID）作为分桶键，保证了数据在各个分桶内尽可能均衡；最后，默认三副本，不同副本存储在不同BE上，保证某一机器或副本的损坏并不会影响业务查询。这三大特性既避免了数据缺失的问题，又保证了查询效率的提高。

知秋客户行为分析系统有获客分析、增长分析、留存分析、传播分析和特征分析五大分析场景，但由于其分析所需的报表多为上亿级别的大宽表，且需要多表关联查询，查询效率低，分析性能也较差。因此，中原银行将各分析场景也全部转移至StarRocks中，提高其查询响应速度；其次，对留存分析场景进行了Bitmap改造，如针对中原银行驻马店分行所应用的留存分析功能，将原有只能进行单一条件查询或全部查询的方式升级为了Bitmap取交集与并集计算的模式，大大提高了客户数据查询与分析的灵活性与时效性，也丰富了客户行为分析的种类。

实时业务实践

实时数据读写效率低下严重影响了对客户的深入洞察与经营管理查询效率，因此，中原银行在原有数据平台架构上对数据存算层与数据服务层进行改造，搭建了实时数仓。

（中原银行改造后的数据平台架构）

搭建实时数仓后，数据传输不再是统一抽取到Kafka后再进行推送，离线数据将采用broker load的方式将T+1数据直接导入StarRocks中，通过相关SQL命令进行快速分析处理；实时数据则通过Flink connector的方式导入，实现Oracle- Kafka- Flink- StarRocks的实时链路，极大地提高了实时查询与计算的效率。同时，原有的ES实时维表转变成了StarRocks 中主键模型的数据表，它支持自定义主键、指标列与秒级的导入与查询，在查询时能够返回相同组件的最新数据，也促进了实时数据使用效率的提高。

此实时数仓架构将中原银行的离线数据和实时数据进行了统一，极大程度上减少了数据的冗余，同时支持秒级的导入与查询，提高了业务的时效性和多样性。

#04

升级平台架构，优化查询效率，实现实时响应，提升用数效率

—

目前，中原银行使用StarRocks完成了固定报表迁移、知秋系统改造与实时数仓建设，极大提高了银行的数据导入、查询与分析效率。整体改造后的具体效果如下：

固定报表迁移效率与查询效率大幅提升。70%的报表可以通过自动化迁移来完成。迁移完成后，固定报表查询效率提升为原来的 2.7 倍，所需时间下降到 3 秒以内。尤其是原耗时排行 top 10 的报表，查询效率提优化了10倍以上，提升效果明显。

实现自助客户行为分析，查询效率显著提高。目前，知秋系统内13个业务场景已全部迁移，其中，针对留存分析进行了bitmap 改造，查询效率提升了10 倍以上；其他模块查询效率平均提升3倍以上，平均查询时效为5.8秒。

实时架构升级，实现秒级响应。通过搭建实时数仓，能够实现秒级响应最新贷款等业务数据的实时查询，管理决策用数效率从T+1小时转换为秒级。在实时存贷款报表应用中，业务人员能够查询到精准到秒级的最新数据，核对存款入账时间从平均半小时缩减至5秒钟，提升了360倍。

通过实时大屏，实时监控银行经营与管理情况。基于实时数仓，中原银行极大程度的丰富了实时大屏的应用场景。目前，智能运营增长平台可以实时监控触达转化数据；鸿图大屏能实时查看对公时点存款、对公时点贷款的余额、对公总客户数与对公的排名情况，辅助业务人员进行实时的分析决策；还能够实时查看当天各项目组DevOps研发效能流水线发版情况、发版成功率、失败率和以及排名情况。

#05

中原银行为城商行OLAP架构升级提供创新实践典范

—

中原银行作为目前我国排名第八的城商行，此次与StarRocks合作的升级OLAP项目为其他规模相同、已有数据平台建设较完善的城商行提供了标杆。

首先，银行在改造前需深入分析业务需求，基于此进行选型。目前市面上的分析型数据库厂商众多，各产品优势不同；银行不能盲目跟风采购，需要拆解业务需求，并结合技术适配度、安全性、社区活跃度等多维度进行考察与POC测试，选择符合业务需求、适配技术框架的分析型数据库。该项目中，中原银行基于用数效率提高的核心需求，从九大维度中进行考察，最终选择了在查询效率、技术架构与兼容性有明显优势的StarRocks。

其次，项目实施过程应分阶段分场景进行改造。对于中原银行为代表的数字平台建设已经比较完善的银行来说，OLAP的升级比较复杂。因此，应该按照业务场景等逻辑进行任务拆分，有规划的分阶段进行改造，提高项目执行效率。此项目中，中原银行按照业务需求将具体执行阶段划分成离线业务改造与实时业务改造，在9个月内完成了部分系统的升级改造。

未来，中原银行还会携手StarRocks继续深入改造与优化包括数据分析平台在内的数据平台架构，挖掘更多业务场景下的实时报表，进一步探索优化OLAP性能，解决数据湖分析过程中存在IO延迟高、数据格式无法最优化等问题，从而在StarRocks上实现极速分析与极速数据湖分析以提高用数效率并赋能业务增长与银行管理，迈向极速统一3.0时代。

关于 StarRocks

2021 年 9 月，StarRocks 源代码开放，在 GitHub 上的星数已超过 3400 个。StarRocks 的全球社区飞速成长，至今已有超百位贡献者，社群用户突破 7000 人，吸引几十家国内外行业头部企业参与共建。

作者：小傅哥
博客：https://bugstack.cn

> 沉淀、分享、成长，让自己和他人都能有所收获！😄

一、前言：为啥不要你？

从刚面试的问题回答中，能看得出你用了不少拙力背了不少题。直接拿这些技术点问，你可以回答。但同样是这些技术点，我换个场景来问用到了什么技术，你就像从没有听说过一样。当然不可否认你能通过背把这些内容记住也是一种能力，但作为招聘从事软件编程的码农来说，其实更希望是招聘那些通过实际场景积累下来技术经验研发人员，对各个技术点有张有弛，举一反三。这也是一个理科生该具备的学习编程的基本素质，也更具有培养价值。

你肯定想，那为啥明明大部分时候都是CRUD开发，怎么还那么多要求呢？招进个人能干活就行呗？

但其实能干活的人多的是，你看；同类公司间为了市场有竞争吧、公司内同部门为了业绩有竞争吧、部门内各小组为了绩效有竞争吧。那么同样一个事有的公司能做起来有的公司就不行，因为各个公司所具备的基因不同，而这个基因主要是来自公司选择的市场面和相关人才积累。那么放到各个公司部门内的小组也一样，为啥有的组就那么高绩效、那么多晋升指标、那么多加薪包。那都是这个组内除了完成基础项目一样，还有很多具有超高素质的人才，所拼出来的。再拿这些拼出来的成绩兑换成绩效分配给组员。

现在缕清了，如果招聘一个组内平均能力以下只能完成 CRUD 开发的，那么就是招聘进来分配资源包的。放到组内没有竞争力、放到部门内垫底，所以领导根本没有那么多经历培养一个社招的还需要大量时间培养的。—— 这样的培养机会只会给到应届生。

所以在你度过编程阶段的新手村阶段以后，就不要把时间只是放到背八股文，堆CRUD代码上。这些东西搞多了，会让人厌烦，吸收的不多，收获的不大。而以大部分连八股文都能背的下来的人来说，把这样的时间精力放到吸收有深度的技术项目上，同样时间下成长的会更快。

这些东西本就没有多难，难的是你不知道，从哪知道！—— 你不是学不会，你只是没有人带你开开眼界！

二、深耕：科技与狠活！

但！有这样的深耕技术的小傅哥在，我会帮你知道你不知道的，也会帮你知道你知道但没法深知的。—— 这也是我的初心，成为粉丝最受信赖和尊重的技术号主。沉淀、分享、成长，让自己和他人都能有所收获！

接下来小傅哥就给大家举一些场景案例，这也是当你缺少这些深度后，倒置你的简历那么空洞，你的回答那么苍白的主要原因。以下这些内容来自于粉丝读者的提问后小傅哥给予的回答

1. 场景设计

问题：目前在做一个微商城系统，中间有一个类似购物车结账，支持改价和使用优惠券等。目前遇到一个问题，就是优惠分为2种，一种是商品直减优惠，这种优惠我使用策略加责任链模式进行了重构优化能快速扩展。但是另一种是类似满减优惠，需要根据各个商品在总价的比例均摊给不同的商品优惠金额，这里我们使用的均摊算法是最后一个商品优惠金额等于总优惠金额-商品a-商品b的优惠金额，这样能解决1/3这种小数问题。

回答：

背景（这类分摊计算的逻辑还是蛮复杂的，虽然复杂，但这类业务还是蛮有意思的）

1.1 优惠类型可能包括：直减、满减、N购、折扣、优惠限定SKU
1.2 支付方式优惠券，免息、分期百分比优惠、红包
1.3 合作分摊，包括优惠费用的承担方，各自出资占比，有了出资后运营才能配置优惠券
1.4 多种商品SKU组合购买 X 多种优惠组合支付 X 支付方式优惠(可选)
1.5 部分商品退货，根据优惠分摊金额扣除后，退款其余部分。PS：但有时候也有业务需求是退款时候，分摊调整，所推商品金额如果能覆盖优惠券，则退回优惠券和剩余金额。如：用户支付了80，买了5件商品，用了100-20的满减优惠券，那么1件商品退款的时候，退款了10+20满减券。但也有时候是支持用户选择的，比如你同意退款15还是退款10+20优惠券。具体要根据合规、风控、业务三方协调确定产品方案，有时候不同年度市场规则调整，可能也会随之处理分摊方式。

设计

2.1 结构上使用模板模式，因为分摊是一套标准的流程，具体分摊由不同的优惠券策略进行处理。
2.2 在模板模式中抽象类可以继承数据支撑类和配置类，也可以结合策略模式、责任链模式等，便于组合使用。

流程

3.1 接口中需要的核心参数包括：父单号、下单商品SKU列表、商品价格、实际支付、优惠券金额、优惠券信息。当然可能这些信息需要通过单号拆分后自己查询组合，这个时候模板模式的数据支撑类就发挥作用了。
3.2 模板模式的数据处理中，为商品列表提供分摊占比计算，A/(A+B+…N) 保持占比记录。
3.3 模板模式分摊方法中for循环优惠列表，在循环方法中调用抽象分摊方法。
3.4 在子类实现的抽象分摊方法中，调用优惠类型分摊计算策略方式。100-20 20按照商品分摊比例，循环计算，并填充到抽象模板中的Map<string, list<分摊对象>>中，key 是优惠ID。由于计算会有余数，这部分分摊给最后一个商品。最终形成一组各个优惠分摊到每个商品SKU的分摊结果。

数据

4.1 在数据库中要记录每一条的分摊记录，商品父单、子单、金额、实付、优惠类型、占比、分摊金额等，这些方便后续进行退款以及结算给商户使用。
4.2 同时要有一张总表来记录一个商品分摊后的完整信息，是哪个商品父单、使用的优惠组合，这个表有点和订单表类似，不过会填充一些分摊信息与4.1表1vn的结构。

扩展

5.1 新提供的分摊优惠券了类型策略，采用数据库配置的方式处理，并在程序启动的时候，加载到分摊模板的Config中，这样就可以处理新增的分摊计算方式了。
5.2 不过可能有时候实际的业务订单要比分摊系统快，那么这个时候出现的订单，不能分摊则要做归档处理，写入归档表，后续开发了新的分摊策略和配置，再开启任务扫描处理分摊。

2. 技术问题

技术问题的解决能力，需要来自于编程上的日积月累，参与更多的场景，碰到更多的问题。这样才能积累经验，为此小傅哥专门收集实际开发中所遇到的异常并进行模拟复现。让大家更好的吸收这些实战经验。

2.1 rollback-only

问题：rollback-only
异常：线程执行某个定时任务，在事务提交时抛出了异常。看到rollback-only字样，这个是什么原因引起的。写代码要注意什么能避免产生这一种情况。
测试：用数据库表防重做插入测试，触发异常；
- 1. 两个方法都加了事务注解，两个方法都会受到到事务管理的拦截器增强，并且事务传播的方式都是 REQUIRED，当已经存在事务的时候就加入事务，没有就创建事务。这里A和B都受事务控制，并且是处于同一个事务的。
- 1. A调用B，A中抓了B的异常，当B发生异常的时候，B的操作应该回滚，但是A吃了异常，A方法中没有产生异常，所以A的操作又应该提交，二者是相互矛盾的。
- 1. Spring的事务关联拦截器在抓到B的异常后就会标记rollback-only为true，当A执行完准备提交后，发现rollback-only为true，也会回滚，并抛出异常告诉调用者。
复现：https://gitcode.net/KnowledgePlanet/CodeTutorial/Bug-Code/-/blob/master/src/test/java/cn/bugstack/guide/test/RollbackOnlyTest.java

2.2 Deadlock

问题：死锁
异常：Deadlock found when trying to get lock; try restarting transaction
测试：多线程模拟并发下，一个事务未提交完成，又来一个事务。
复现：https://gitcode.net/KnowledgePlanet/CodeTutorial/Bug-Code/-/blob/master/src/test/java/cn/bugstack/guide/test/DeadlockTest.java

2.3 主从同步

问题：在高可用场景中，数据库会做主备，那么当主数据还没来的急同步到备数据库，主数据库挂掉了。这种场景如果是对数据一致性要求比较高的情况下，架构又该如果考虑，业务又该如何补偿呢。

binlog 说明；用于记录数据库执行的写入性操作，以二进制保存在磁盘。binlog 是 mysql 的逻辑日志，由 Server 层进行记录，使用任何存储引擎的 mysql 数据库都会记录 binlog 日志。实际应用中，binlog 用于主从复制、数据备份。
binlog 分类；STATMENT、ROW、MIXED，mysql 5.7.7 之前默认格式为 STATMENT，5.7.7 之后默认为 ROW；可以通过命令查看 mysqlbinglog mysql-bin.00001 | more
- 1 STATMENT：基于 SQL 语句复制，每一条修改SQL语句都会记录到binlog
- 2 ROW：基于行复制
- 3 MIXED：基于 STATMENT、ROW 的混合模式
主从复制：Mysql 主从复制需要三个线程：master（binlog dump thread）、slave（I/O thread 、SQL thread）
- 1 binlog dump线程：主库中有数据更新时，根据设置的binlog格式，将更新的事件类型写入到主库的binlog文件中，并创建log dump线程通知slave有数据更新。当I/O线程请求日志内容时，将此时的binlog名称和当前更新的位置同时传给slave的I/O线程。
- 2 I/O线程：该线程会连接到master，向log dump线程请求一份指定binlog文件位置的副本，并将请求回来的binlog存到本地的relay log中。
- 3 SQL线程：该线程检测到relay log有更新后，会读取并在本地做redo操作，将发生在主库的事件在本地重新执行一遍，来保证主从数据同步。
复制过程：
- 1 主库写入数据并且生成binlog文件。该过程中MySQL将事务串行的写入二进制日志，即使事务中的语句都是交叉执行的。
- 2 在事件写入二进制日志完成后，master通知存储引擎提交事务。
- 3 从库服务器上的IO线程连接Master服务器，请求从执行binlog日志文件中的指定位置开始读取binlog至从库。
- 4 主库接收到从库的IO线程请求后，其上复制的IO线程会根据Slave的请求信息分批读取binlog文件然后返回给从库的IO线程。
- 5 Slave服务器的IO线程获取到Master服务器上IO线程发送的日志内容、日志文件及位置点后，会将binlog日志内容依次写到Slave端自身的Relay Log（即中继日志）文件的最末端，并将新的binlog文件名和位置记录到master-info文件中，以便下一次读取master端新binlog日志时能告诉Master服务器从新binlog日志的指定文件及位置开始读取新的binlog日志内容。
- 6 从库服务器的SQL线程会实时监测到本地Relay Log中新增了日志内容，然后把RelayLog中的日志翻译成SQL并且按照顺序执行SQL来更新从库的数据。
- 7 从库在relay-log.info中记录当前应用中继日志的文件名和位置点以便下一次数据复制。
降低延迟：
- 从库上的执行，即sql_thread更新逻辑，在5.6版本之前，是只支持单线程，那么在主库并发高、TPS高时，就会出现较大的主从延迟。因此，MySQL自5.7版本后就已经支持并行复制了。可以在从服务上设置 slave_parallel_workers为一个大于0的数，然后把slave_parallel_type参数设置为LOGICAL_CLOCK
- 降低多线程大事务并发的概率，优化业务流程
- 优化SQL，避免慢查询，减少批量操作
- 提高从库机器配置
- 主从同机房、通网络、带宽、地域
- 主从切换，日志恢复

3. 技术架构

总有同学分不清 MVC 和 DDD 的本质区别，却又总被一些理论搞的晕头转向，听不懂：领域专家、战术战略、模型推演等，这些词让原本就模糊的概念更加模糊，根本没法落地。所以给大家画了一个 MVC 和 DDD 的对比图，便于大家可以从代码实现视角的更好的理解DDD。

MVC：更偏向与数据建模实现，由数据调用驱动，所以也就引申出的DAO、PO、VO类会随着项目开发不断的膨胀，不易于迭代和维护。 DDD：以业务流程提炼领域模型为驱动，设计和实现模块开发，在一个领域中包含mode对象、仓储数据、服务实现，也更注重设计模式的使用，否则实现的DDD徒有其表更多的只是归类了 DAO、PO、VO 对象。

所以如果想了解DDD如何落地，非常建议把DDD抽奖系统的代码好好实践起来。

4. 学习运用

问题：手撸spring、手撸MyBatis如何体现在简历上？小傅哥可以给个Demo吗

回答：

体现在专业技能上，例如； 1.1 深入学习 Spring 核心流程模块，包括；IOC、AOP、依赖倒置等流程，掌握Spring解决复杂场景所运用的分治、抽象和知识(设计模式、设计原则)，在解决Spring场景问题时，可以从核心原理上给出方案。同时也具备基于 Spring 开发 SpringBoot Starter 技能，为复杂项目减少同类共性需求的开发，凝练通用的技术组件，减少研发成本。 1.2 深入学习 MyBaits 核心流程模块，包括；会话、反射、代理、事务、插件等流程，熟练掌握 ORM 框架的设计思想、实现方式和应用价值。并能按需结合 MyBatis 的插件机制，开发属于企业自己所需的功能，包括；数据分页、数据库表路由、监控日志、数据安全等方面。
体现在项目经验上，例如；—— 对校招和实习比较有用把 Spring、MyBatis 当一个学习项目来描述，这是你在离校前，最可能接触到的一个完整的、成型的、知名的，有企业使用的，框架。你就按照自己学习并开发了这样一个框架为目标来写项目，并描述出这个项目，你用了什么技术栈，解决了什么问题，学习到了哪些。
体现在项目应用上，例如；关于 Spring、MyBatis 的项目，一般都是插件类开发，比如各类的 SpringBoot Starter，MyBatis 插件，都是基于框架的深入整合类技术解决方案，体现在简历上，非常抓眼球。一看你就是有深度和自研能力的研发人员。—— 一般不让你造轮子，但需要你有造轮子的能力，这样企业中一些软件可以被你进行优化和修改。
体现在解决问题是上，例如；在你的自己的业务项目中，渗入一些关于解决了原项目使用 Spring 时，关于感知 Aware 方式或者结合 FactoryBean 包装对象等，所遇到的问题，因为你学习过源码，所以非常清晰这样的流程，因此解决了一个问题。通用 MyBatis 也适用于这样的描述方式，包括；事务、查询次数、批查询、插件能监听到的四个类（ParameterHandler、ResultSetHandler、StatementHandler、Executor ）你给了更好的选择。

5. 更多场景

这些内容都来自于日积月累的思考和编写所产生的内容，也是更符合实际场景诉求的内容。—— 这让我想起有个为了卖2万多块钱的课胡说：”不会写贪吃蛇，进公司没法写代码！“千万别被这种忽悠了！

了解更多：https://bugstack.cn/md/zsxq/introduce.html

作者：vivo 互联网大数据团队- Wang Lei

一、前言

一直以来，许多产品平台都在尝试通过可视化搭建的手段来降低 GUI 应用的研发门槛，提高生产效率。随着我们业务的发展，数据建设的完善，用户对于数据可视化的诉求也日益增多，而数据大屏是数据可视化的其中一种展示方式，它作为大数据展示媒介的一种，被广泛运用于各种会展、公司展厅、发布会等。

相比于传统手工定制的图表与数据仪表盘，通用大屏搭建平台的出现，可以解决定制开发, 数据分散带来的应用开发、数据维护成本高等问题，通过数据采集、清洗、分析到直观实时的数据可视化展现，能够多方位、多角度、全景展现各项指标，实时监控，动态一目了然。

本文将通过敏捷BI平台的通用大屏搭建能力的实现方案，来讲解一下通用可视化搭建平台整体的设计思路。

二、快速了解可视化大屏

2.1 什么是数据可视化

从技术层面上来讲，最直观的就是前端可视化框架：Echart、Antv、Chart.js、D3.js、Vega 等，这些库都能帮我们快速把数据转换成各种形式的可视化图表。

从业务层面来讲，其最主要的意义就在于通过数据 -> 图表组合 -> 可视化页面这一业务流程，来帮助用户更加直观整体的分析不同行业和场景的趋势和规律。

所以在数据领域里，对于复杂难懂且体量庞大的数据而言，图表的信息量要大得多，这也是数据可视化最根本的目的。

2.2 可视化大屏都有哪些部分

主要由可视化组件 + 事件交互 + 坐标关系组成，效果如下图所示：

2.3 可视化大屏和常见的BI报表看板的区别

经常会有同学会问到，可视化大屏和BI报表看板的区别是什么？

这里简单的做一下介绍：

大屏和报表看板都只是BI的其中一种展现方式，大屏更多是通过不同尺寸的显示器硬件上进行投屏，而报表看板更多是在电脑端进行展示使用。
大屏更加注重数据动态变化，会有极强的视觉体验和冲击力，提供丰富的轮播动画、表格滚动等动画特效。而报表看板更注重交互式数据探索分析，例如上卷下钻、排序、过滤、图表切换、条件预警等。

三、设计思路

3.1 技术选型

前端框架：React 全家桶（个人习惯）
可视化框架：EchartsDataV-React (封装度高，json结构的配置项易拓展) D3.js（可视化素粒度小、定制能力强）
拖拽插件：dnd-kit （满足树状结构视图的跨组件拖拽）
布局插件：React-Grid-Layout（网格自由布局，修改源码，支持多个方向的拖拽，自由布局、锁定缩放比等）

3.2 架构设计

下图是我们搭建平台的整体架构设计：

整个大屏搭建平台包含四个非常重要的子系统和模块：

可视化物料中心：是整个平台最基础的模块，我们在开源的图表库和自主开发的可视化组件上面定义了一层标准的 DSL 协议，这个协议和接入画布编辑器的协议是对应的，目前已经有 40+ 相关组件，组件数量还在不断增长。
画布编辑器：是搭建平台的核心与难点，支持页面布局配置、页面交互配置和组件数据配置等功能，另外还支持代码片段的配置，也可以称得上是一个低代码平台。
数据中心：是提供专门用于连接不同数据源的服务，例如直连 MySQL、ClickHouse、Elasticsearch、Presto 等，提供了大屏搭建所需要的原始数据。
管理中心：是大屏的后台运营管理模块，包含了大屏模版管理、大屏发布下线、访问权限等管理功能。

3.3 搭建流程

通过上面提到的大屏组成素，我们可以分析总结出大屏搭建主流程如下图所示：

四、核心功能实现

接下来我们会逐一对平台几个核心功能实现进行解析：

1、大屏自适应布局

背景：解决页面错乱问题，实现多种分辨率的大屏适配：

思考：首先我们想到的是移动端适配主流的 vh、vw、rem组合的方式以及 font.js+rem 等两种方案。第一种方案主要是通过媒体查询来定义父级大小，然后对组件的height、margin、padding等多种css属性采用rem作为单位，继承父级设置等单位（1vw）,实现自适应适配，第二种方案是引用第三方脚本，通过在main.js中写代码计算，使用rem进行继承,实现适配。

① vh、vw、rem组合

② font.js + rem

缺陷：当我们大屏里面使用到的第三方插件，它的样式使用的是px为单位时，例如 line-height 的设置为20px，此时就不能适应行高，就会出现重叠等错乱问题。或者我们利用 postcss-px2rem 插件进行全局替换，但是在使用过程中，需要注意对已经处理过适配的插件，例如 Ant Design，否则引入的antd 控件使用会出现样式错乱的问题

解决思路：采用了css3 的缩放 transform: scale(X，Y) 属性，主要是通过监听浏览器窗口的 onresize 事件，当窗口大小发生变化时，我们只需要根据大屏容器的实际宽高，去计算对应的放大缩小的比例，就可以实现布局的自适应了，我们也提供了不同的布局适应效果，例如等高缩放、等宽缩放、全屏铺满等，不同的缩放方式，决定了我们在计算宽高比例的优先级。因此我们后面在做画布的缩小功能，也可以直接使用这种方案来实现。

2、大屏组件通用开发流程设计

背景：随着可视化组件的增多、新增组件流程繁琐冗长，为了避免重复的造轮子以及后续引入第三方组件，需要制定一套通用的组件开发流程：

设计思路：组件 = component 组件主体 + schema 组件配置协议层 + 组件定义层（类型、从属关系、初始化宽高等）

① component 组件主体：

可视化框架选型：行业主流可视化库有 Echart、Antv、Chart.js、D3.js、Vega、DataV-React 基于可视化的通用性和定制性的需求，我们选择了 Echart、DataV-React 作为基础组件的开发框架，面对定制性要求更高的自定义组件，我们选择了可视化粒度更小的 D3.js。
封装通用 Echarts 组件（初始化、事件注册、实例注销等）：

封装通用 DataV 组件（DataV-React、自定义等组件入口，统一负责配置、数据收集、监听resize）

② schema 组件配置协议层 + 组件定义层（类型、从属关系、初始化宽高等）

我们自定义了一套 schema 组件的DSL，结构协议层。通过DSL约定了组件的配置协议，包括组件的可编辑属性、编辑类型、初始值等，之所以定义一致的协议层，主要是方便后期的组件扩展，配置后移。

JSON Schema设计：

表单DSL设计：

收益：以上是我们定制的DSL结构协议层，用户只需要填写Excel表格，就可以实现动态表单的创建，实现组件配置项分类、配置复用、配置项之间联动、属性注释等功能。目前属性配置器已经支持了常用的15种的配置UI控件，通过定制的DSL结构协议层，可以快速完成组件的配置界面初始化，为后续规划的组件物料中心做准备。

3、拖拽器实现

背景：React-Grid-Layout 拖拽插件不支持自由布局和组件不同纬度拖拽：

解决方案：通过分析源码，对不同纬度的拖拽事件以及拖拽目标碰撞事件进行了重写，并且也拓展了锁定宽高比、旋转透明度等功能。

源码分析：

resize伸缩特性增强（优化），拖拽的同时，除了修改容器宽高外，也动态调整了组件的坐标位置

堆叠显示，自由布局（优化），通过控制布局是否压缩，动态调整拖拽目标的层级zIndex来实现多图层组件操作交互和自由定位。

改造后效果展示

4、大屏状态推送

背景：大屏的后期维护需要有版本发布自更新以及大屏下线等需求，这个时候就需要有一套消息通知机制，通过命令来控制大屏的运行状态。

解决方案：基于websocket通信机制，建立长链接，实现了心跳及重连机制，实时对上线发布后的大屏进行更新或下线管理。

五、效果预览

六、总结

本文通过可视化页面搭建、no/low code 平台、Schema 动WebStorm激活2022.2.3态表单等技术思想来分析讲解了如何去设计开发一个通用的数据大屏搭建平台。

当前的设计方案基本满足了数据大屏的核心能力搭建需求。如果想实现更富有展现力，满足更多场景的大屏搭建平台，我们还需要进一步提高平台的扩展性和完善整体的物料生态，具体规划如下：

丰富和拓展大屏组件&配置能力，覆盖不同行业的可视化场景。
可视化物料平台的搭建，沉淀优秀的可视化组件、大屏模版素材。
3D以及动效渲染引WebStorm激活2022.2.3擎开发实现。

WebStorm激活2022.2.3(WebStorm 2022.2.3 发布)

漏洞描述

影响范围

修复方案

参考链接

情报订阅

由内至外 – 开源过渡

CloudWeGo 和 Kitex

Kitex 发展历史

开源的价值

开源一年变更回顾

框架的衡量指标

功能特性

Proxyless Proxyless

JSON 和 Protobuf 泛化调用支持

重试能力增强

Thrift Validator

性能优化

Thrift 高性能编解码

Protobuf 高性能编解码

gRPC 性能优化

社区共建完善生态及企业落地

社区共建的 Kitex 扩展生态

对接外部企业，协助落地

如何使用 Kitex 与内部基础设施集成

总结和展望

总结

展望

项目地址

使用指南

安装

模型权重

用GPU进行推理

VS Code插件使用指南

一、ChunJun框架介绍

01 ChunJun框架结构

02 ChunJun批量同步

03 ChunJun离线

二、实时数据采集上的实现和原理

01 一个样例

02 ChunJun插件装载逻辑

03 ChunJun插件定义

04 ChunJun数据流转

05 ChunJun动态执行

06 ChunJun间隔轮询

三、实时数据还原上的实现和原理

01 数据还原介绍

难点

02 一个样例

03 整体流程

04 DDL解析

数据还原- DDL转换

05 名字映射

06 中间数据缓存

07 目标端接收数据

四、ChunJun未来规划

对 Java 的那些爱与恨

金融系统为何独爱 Java

云原生时代下的 Java 现状

还呗为何选择 APISIX？

架构的前后变化

基于 APISIX 的应用实践

APISIX 构建部署

公司级定制插件

网关流量灰度

Java 层面网关的考虑因素

公司角度

开发者角度

总结：金融业务发展趋势

项目背景

前言

介绍

开发步骤

修改项目

使用

iOS调试及错误排查

一、引言

Presto系统架构

传统方式部署Presto存在的问题

二、使用Kubernetes部署Presto