GoLand 的下一个主要版本 GoLand 2023.1 正式发布，新版本引入了漏洞检查器和更好的 gRPC 代码导航，并使重命名重构可用于接收器。

开发者现在可以用非标准库包运行 Scratch 文件，使用正则表达式来创建你自己的搜索和替换检查，并快速地将原始字符串文字转换成双引号文字等。

漏洞检查器

• GoLand 现在可以突出显示 go.mod 中存在已知漏洞的软件包
• 有一个快速修复方法可以将依赖更新到没有漏洞的版本。
• GoLand 还可以在编辑器中直接突出显示有已知漏洞的软件包的方法调用
• 关于已知漏洞的更多信息也可以在新的依赖检查器工具窗口中找到。

gRPC导航

现在可以从 Go 代码中导航并访问消息、服务和方法的声明，以及它们在 .proto 文件中的 Go 实现。

Scratch 文件

现在可以运行具有非标准库 Go 依赖的 Scratch 文件。

重命名重构

当你重新命名一个结构中的类型参数时，重命名重构现在会建议相应地改变接收器。

Intentions 和快速修复

• 我们有一个新的 intention 操作，可以让你快速地将原始的字符串文字（由反斜线包围的字符串）转换成双引号的字符串，反之亦然。
• 简化了整数与字符串的转换： 你现在只需用 1 次 quick-fix 就可以做到这一点，而以前需要 2 次。
• GoLand 现在有了检查和快速修复功能，可以帮助您检测和删除 Go 指令中的前导空格
• 现在可以预览更多的 intention 操作和快速修复方法。

性能改进

• 通过在智能模式下执行 Scanning files to index 过程，改善了 IDE 的启动体验。
• GoLand 现在建议将特定文件夹添加到 Microsoft Defender 的排除列表中

编辑器

• 更新了 Code Vision 功能，因此 GoLand 现在可以显示某个接口的实现数量及其方法规范。
• 现在可以使用正则表达式来创建你自己的搜索和替换检查
• GoLand 的 Go Playground 集成中的共享 URL 现在包括版本参数，如果你选择 dev 或以前的版本。你也可以禁用要求你允许在 Playground 中分享代码的弹出窗口
• 现在有一个特殊的设置，允许你控制粘贴内容的位置。
• 一个新的设置允许你配置 IDE，使其仅在你选择代码时以小圆点形式显示空白处。
• 更新了 Typo 检查，使它不再检查哈希值和特殊值的拼写，也不把它们报告为拼写错误。
• 为函数调用引入了一个新的 Find Usages 组 —— Call 组。
• ……

更多详情可查看：https://blog.jetbrains.com/go/2023/04/03/goland-2023-1/

关注公众号

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

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

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

本文要点：

• 一种优雅解决 MySQL 驱动中虚引用导致 GC 耗时较长问题的解决方法
• 虚引用的作用与使用场景
• MySQL 驱动源码中的虚引用分析

背景

​ 在之前文章中写过 MySQL JDBC 驱动中的虚引用导致 JVM GC 耗时较长的问题(可以看这里)，在驱动代码（mysql-connector-java 5.1.38版本）中 NonRegisteringDriver 类有个虚引用集合 connectionPhantomRefs 用于存储所有的数据库连接，NonRegisteringDriver.trackConnection 方法负责把新创建的连接放入集合，虚引用随着时间积累越来越多，导致 GC 时处理虚引用的耗时较长，影响了服务的吞吐量：

​ 尝试减少数据库连接的生成速度，来降低虚引用的数量，但是效果并不理想。最终的解决方案是通过反射获取虚引用集合，利用定时任务来定期清理集合，避免 GC 处理虚引用耗时较长。

​ 利用定时任务清理虚引用效果立竿见影，每日几亿请求的服务 mixed GC 耗时只有 10 – 30 毫秒左右，系统也很稳定，线上运行将近一年没有任何问题。

优化——由暴力激活成功教程到优雅配置

​ 最近又有同事遇到相同的问题，使用的 mysql-connector-java 版本与我们使用的版本一致，查看最新版本（8.0.32）的代码发现对数据库连接的虚引用有新的处理方式，不像老版本（5.1.38）中每一个连接都会生成虚引用，而是可以通过参数来控制是否需要生成。类 的相关代码如下：

​ mysql-connector-java 的维护者应该是注意到了虚引用对 GC 的影响，所以优化了代码，让用户可以自定义虚引用的生成。

​ 有了这个配置，就可以在启动参数上设置属性：

​ 或者在代码里设置属性：

​ 当 com.mysql.cj.disableAbandonedConnectionCleanup=true 时，生成数据库连接时就不会生成虚引用，对 GC 就没有任何影响了。

​ 建议还是使用第一种方式，通过启动参数配置更灵活一点。

什么是虚引用

​ 有些读者看到这里知道 mysql-connector-java 生成的虚引用对 GC 有一些副作用，但是还不太了解虚引用到底是什么，有什么作用，这里我们在虚引用上做一点点拓展。

​ Java 虚引用（Phantom Reference）是Java中一种特殊的引用类型，它是最弱的一种引用。与其他引用不同，虚引用并不会影响对象的生命周期，也不会影响对象的垃圾回收。虚引用主要用于在对象被回收时收到系统通知，以便在回收时执行一些必要的清理工作。

​ 上述虚引用的定义还是比较难理解，我们用代码来辅助理解：

​ 先来生成一个虚引用：

​ 虚引用的构造方法需要两个入参，第一个就是关联的对象、第二个是虚引用队列 ReferenceQueue。虚引用需要和 ReferenceQueue 配合使用，当对象 Object o 被垃圾回收时，与 Object o 关联的虚引用就会被放入到 ReferenceQueue 中。通过从 ReferenceQueue 中是否存在虚引用来判断对象是否被回收。

​ 我们再来理解上面对虚引用的定义，虚引用不会影响对象的生命周期，也不会影响对象的垃圾回收。如果上述代码里的phantomReference 是一个普通的对象，那么在执行 System.gc() 时 Object o 一定不会被回收掉，因为普通对象持有 Object o 的强引用，还不会被作为垃圾。这里的 phantomReference 是一个虚引用的话 Object o 就会被直接回收掉。然后会将关联的虚引用放到队列里，这就是虚引用关联对象被回收时会收到系统通知的机制。

​ 一些实践能力很强的读者会复制上述代码去运行，发现垃圾回收之后队列里并没有虚引用。这是因为 Object o 还在栈里，属于是 GC Root 的一种，不会被垃圾回收。我们可以这样改写：

​ 不在 main 方法里实例化关联对象 Object o，而是利用一个 buildReference 方法来实例化，这样在执行垃圾回收的时候，Object o 已经出栈了，不再是 GC Root，会被当做垃圾来回收。这样就能从虚引用队列里取出关联的虚引用进行后续处理。

关联对象真的被回收了吗

​ 执行完垃圾回收之后，我们确实能从虚引用队列里获取到虚引用了，我们可以思考一下，与该虚引用关联的对象真的已经被回收了吗？

​ 使用一个小实验来探索答案：

​ 代码里生成一个虚引用，关联对象是一个大小为 2M 的数组，执行垃圾回收之后尝试再实例化一个大小为 4M 的数组。如果我们从虚引用队列里获取到虚引用的时候关联对象已经被回收，那么就能正常申请到 4M 的数组。（设置堆内存大小为 5M -Xmx5m -Xms5m）

​ 执行代码输出如下：

​ 从输出可以看到，申请 4M 内存的时候内存溢出，那么问题的答案就很明显了，关联对象并没有被真正的回收，内存也没有被释放。

​ 再做一点小小的改造，实例化新数组的之前将虚引用直接置为 null，这样关联对象就能被真正的回收掉，也能申请足够的内存：

​ 如果我们使用了虚引用，但是没有及时清理虚引用的话可能会导致内存泄露。

虚引用的使用场景——mysql-connector-java 虚引用源码分析

​ 读到这里相信你已经了解了虚引用的一些基本情况，那么它的使用场景在哪里呢？

​ 最典型的场景就是最开始写到的 mysql-connector-java 里处理 MySQL 连接的兜底逻辑。用虚引用来包装 MySQL 连接，如果一个连接对象被回收的时候，会从虚引用队列里收到通知，如果有些连接没有被正确关闭的话，就会在回收之前进行连接关闭的操作。

​ 从 mysql-connector-java 的 AbandonedConnectionCleanupThread 类代码中可以发现并没有使用原生的 PhantomReference 对象，而是使用的是包装过的 ConnectionFinalizerPhantomReference，增加了一个属性 NetworkResources，这是为了方便从虚引用队列中的虚引用上获取到需要处理的资源。包装类中还有一个 finalizeResources 方法，用来关闭网络连接：

​ AbandonedConnectionCleanupThread 实现了 Runnable 接口，在 run 方法里循环读取虚引用队列 referenceQueue 里的虚引用，然后调用 finalizeResource 方法来进行后置的处理，避免连接泄露：

​ 如果你希望在某些对象被回收的时候做一些后置工作，可以参考 mysql-connector-java 中的一些实现逻辑。

总结

​ 本文简述了一种优雅解决 MySQL 驱动中虚引用导致 GC 耗时较长问题的解决方法、也根据自己的理解讲述了虚引用的作用、结合 MySQL 驱动的源码描述了虚引用的使用场景，希望对你能有所帮助。

公众号：DailyHappy

一位后端写码师，一位黑暗料理制造者。

关注公众号

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

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

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

4月8日上午，在鹤壁举行的信息技术自主创新高峰论坛上，龙芯中科正式发布了新款高性能服务器处理器———龙芯 3D5000。

龙芯 3D5000 采用龙芯自主指令系统龙架构 (LoongArch)，无需国外授权，具备超强算力、性能卓越的特点，可满足通用计算、大型数据中心、云计算中心的计算需求。

据介绍，龙芯 3D5000 通过芯粒（chiplet）技术将两个 3C5000 的硅片封装在一起，是一款面向服务器市场的 32 核 CPU 产品。

具体架构上，龙芯 3D5000 内部集成了 32 个高性能 LA464 内核，频率 2.0GHz，支持动态频率及电压调节，片内 64MB L3 共享缓存，8 通道 DDR4-3200 ECC 内存，5 个 HT 3.0 高速接口，实现了双路、四路 CPU 扩展支持。

龙芯 3D5000 采用 LGA-4129 封装，TDP 功耗为 300W，不过典型功耗只有 150W，算下来每个 CPU 大约是 5W 功耗左右。性能方面，龙芯 3D5000 的 SPEC 2006 分数超过 425，浮点部分采用了双 256bit 向量单，双精度浮点性能可达 1TFLOPS（1万亿次），是典型 ARM 核心性能的 4 倍。

龙芯 3D5000 片内还集成了安全可信模块，可以取代外置可信芯片。龙芯 3D5000 还支持国密算法，内嵌独立安全模块，高性能加密解密效率可达 5Gbps 以上，足以替代高性能密码机。

大家好，我是 Kagol，OpenTiny 开源社区运营，TinyVue 跨端、跨框架组件库核心贡献者，专注于前端组件库建设和开源社区运营。

前面给大家介绍了 OpenTiny 快速创建 Vue Admin 后台管理系统和一套代码同时在 Vue2 Vue3 中使用。

• 一个 OpenTiny，Vue2 Vue3 都支持！
• 🎊这个 OpenTiny 开源项目的 CLI 可太牛了，两行命令创建一个美观大气的 Vue Admin 后台管理系统，有手就会，连我的设计师朋友都学会啦啦

本文将给大家介绍 OpenTiny 的一些特色组件。

业界组件库有的组件，OpenTiny 也都有，业界组件库没有的组件，OpenTiny 也有。

从组件数量来说，OpenTiny 比业界主流的 Element Plus 和 Ant Design 都多，足足有70个组件。

有不少是业界组件库都没有的特色组件。

IpAddress IP 输入框

IpAddress 组件是一个很有“云服务特色”的组件，我们可以用它来很方便地输入 IP 地址。

它主要支持以下特性：

• 输入满 3 位自动跳到下一段号码
• 只读态
• 禁用态
• 设置尺寸
• 自定义分隔符

看着非常简单，但是很实用！欢迎体验👏

IpAddress 组件：https://opentiny.design/tiny-vue/zh-CN/os-theme/components/ip-address

Fullscreen 全屏

Fullscreen 全屏组件看着功能也很简单，却非常实用。

它主要分成两种模式：

• pageOnly 普通全屏，只在浏览器窗口内的全屏
• teleport 沉浸式全屏，充盈整个电脑屏幕的全屏

除此之外，Fullscreen 还支持以下特性：

• 同时支持组件式和函数式两种使用方式
• 按 ESC 退出全屏
• 设置 zIndex 层级

普通全屏

沉浸式全屏

Fullscreen 组件：https://opentiny.design/tiny-vue/zh-CN/os-theme/components/fullscreen

Split 面板分割

Split 面板分割也是一个很有用的布局组件，常用于将一片区域，分割为可以拖拽调整宽度或高度的两部分区域。

主要支持以下特性：

• 横向和纵向两种分割类型
• 设置宽高阈值
• 自定义分隔器
• 嵌套使用

支持纵向分割

值得一提的是，Split 还支持嵌套使用，从而给页面动态布局调整带来了更多可能和灵活性。

Split 组件：https://opentiny.design/tiny-vue/zh-CN/os-theme/components/split

Calendar 日历

Calendar 组件是按照日历形式展示数据的容器。

主要支持以下特性：

• 年/月两种显示模式
• 自定义日期单格
• 添加日程事件
• 自定义工具栏

Calendar 组件：https://opentiny.design/tiny-vue/zh-CN/os-theme/components/calendar

Crop 图片裁切

Crop 组件主要用于图像裁切，基于 cropperjs，支持非常丰富的功能。

• 可预览
• 支持 JPG 和 PNG 格式
• 浏览图像可以手动调整选择头像区域

Crop 组件：https://opentiny.design/tiny-vue/zh-CN/os-theme/components/crop

说得再多，不如亲自体验下，OpenTiny 的更多特色组件，等你来探索！

https://opentiny.design/tiny-vue

联系我们

如果你对我们 OpenTiny 的开源项目感兴趣，欢迎添加小助手微信：opentiny-official，拉你进群，一起交流前端技术，一起玩开源。

OpenTiny 官网：https://opentiny.design/

OpenTiny 仓库：https://github.com/opentiny/

Vue 组件库：https://github.com/opentiny/tiny-vue（欢迎 Star 🌟）

Angular 组件库：https://github.com/opentiny/ng（欢迎 Star 🌟）

CLI 工具：https://github.com/opentiny/tiny-cli（欢迎 Star 🌟）

往期文章推荐

• 历史性的时刻！OpenTiny 跨端、跨框架组件库正式升级 TypeScript，10 万行代码重获新生！
• 一个 OpenTiny，Vue2 Vue3 都支持！
• 🎊这个 OpenTiny 开源项目的 CLI 可太牛了，两行命令创建一个美观大气的 Vue Admin 后台管理系统，有手就会，连我的设计师朋友都学会啦啦
• 老板：你为什么要选择 Vue？

WGCLOUD 是一款集成度较高的分布式运维监控平台，具有集群监控，易部署、易上手使用、轻量、高效、自动化等特点，server 端基于 springboot 开发，agent 端使用 go 编写。核心模块包括：主机系统信息监控，CPU 监控，CPU 温度监控，内存监控，网络流量监控，磁盘 IO 监控，磁盘空间监测，系统负载监控，硬盘 smart 健康检测，应用进程监控，端口监控，docker 监控，日志文件监控，文件防篡改保护，数据可视化监控，自动生成拓扑图、大屏可视化，数通设备监测，服务接口监测，设备账号管理，web ssh ，指令下发，告警信息（邮件、钉钉、微信等）推送 

码云仓库：https://gitee.com/wanghouhou/wgcloud

GITHUB 仓库：https://github.com/tianshiyeben/wgcloud

WGCLOUD 唯一官网：http://www.wgstart.com

WGCLOUD 支持监测的操作系统平台

支持监测 Linux 系列：Debian、RedHat、CentOS、Ubuntu、Fedora、麒麟、统信 (UOS)、龙芯 (mips) 等
支持监测 Windows 系列：Windows Server 2008 R2，2012，2016，2019，2022，Windows 7，Windows 8，Windows 10，Windows 11
支持监测 Unix 系列：solaris，FreeBSD，OpenBSD
支持监测 MacOS 系列：macOS amd64，macOS arm64
其他支持：ARM，Android（安卓），riscv64，s390x，树莓派等

WGCLOUD-v3.4.6 更新说明  2023-04-08 发布

1.新增，进程、端口、docker的监控间隔时间，支持单独配置，修改agent配置文件配置项

2.新增，第三个大屏展板

3.新增，监测主机用户的登录信息

4.新增，进程监控，支持采集进程所有者

5.新增，进程监控，支持自动恢复指令或者脚本，系统在检测到进程下线后触发，agent会自动执行用户设置的恢复指令

6.新增，数据源监测支持监控达梦数据库

7.新增，对系统中涉及到的密码加密处理

8.优化，磁盘、文件防篡改监控时间改为15分钟扫描一次，原来是30分钟

9.优化，docker容器监测

10.优化，数通SNMP监测，可以不用填写进出口流量的OID了，系统将会自动获取设备的所有接口流量和速率

11.新增，设备账号管理模块

12.bug修复，端口监控，当IP和Telnet IP都在主机列表IP时，偶尔出现数据监控的问题

13.一些已知的bug修复，优化UI，代码结构优化

Kodi 是由 Kodi 基金会开发的开源媒体播放器（前身为 XBMC，从 14.0 版本开始更名为 Kodi），Kodi 可以运行在多种操作系统和硬件平台。 它可以让用户播放本地或网络存储设备中的视频、音乐、播客及各种常见的媒体文件。

该软件最初是为计划运行在 Xbox 上的，XBMC 的名称也由此而来。后来才有了 Android、Linux、BSD、macOS、iOS 和 Windows 操作系统的原生版。

Kodi 团队证实，他们的用户论坛发生了数据泄漏，影响了超过 40 万用户的个人数据，其中包括姓名、电子邮件地址、IP 地址和密码，以及用户通过消息系统发送的信息。

Kodi 团队通过调查发现，Kodi 用户论坛（MyBB）管理控制台在今年 2 月 16 日和 2 月 21 日被两次访问。这些泄漏的数据是用论坛管理团队中一个受信任但目前不活跃的成员的账户访问的，也正因如此，Kodi 团队在此期间并没有发现什么异常。

之所以最后还是发现了数据泄露，是因为团队成员在其他互联网论坛上发现 Kodi 论坛的用户数据在被出售时才意识到这个问题。

目前 Kodi 已经禁用了此次数据泄露中所使用的账户，并对团队基础设施进行了初步审查。虽然论坛上的密码是以加密格式存储的，但该团队表示，他们必须假设所有密码都已泄露。

Kodi 团队正在调查如何最好地执行全局密码重置，以及如何最好地保证服务器主机和相关软件的完整性。目前论坛服务器已经下线了，这也会影响 Kodi pastebin 和 wiki 站点。为了彻底调查和修复问题，他们暂时也没有办法给出论坛服务器重新上线的时间表。

为了保障用户信息安全，建议在任何其他网站上使用了相同用户名和密码的用户尽快去重置一下密码，避免被撞库。

关注公众号

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

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

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

Next.js 13.3 近日正式发布，新版本添加了多个社区用户要求的受欢迎的功能，并会在下一个次要版本中将 App Router 标记为稳定，Next.js 13.3 具体更新内容包括：

基于文件的 Metadata API

在 Next.js 13.2 中，Next.js 公布了一个新的 Metadata API，允许用户通过从布局或页面导出 Metadata 对象来定义数据（例如 HTML 素中的 、和 标签）。

除了基于配置的数据外，Metadata API 现在还支持新的文件约定，开发者可以方便地自定义页面以改进 SEO 和在 Web 上共享：

动态 OG 图像生成

六个月前，Next.js 发布了 @vercel/og 和 Satori 库，它们允许您使用 JSX、HTML 和 CSS 动态生成图像。

自发布以来，随着 Vercel 客户的广泛采用和超过 900,000 次下载，Next.js 很高兴能够将动态生成的图像引入所有 Next.js 应用程序，而无需外部包。

现在可以从 导入 生成图像：

App Router 的静态导出

Next.js App Router 现在完全支持静态导出。开发者可以从静态网站或单页应用程序（SPA）开始，然后再选择性地升级，以使用需要服务器的Next.js功能。

在运行 时，Next.js会在每个路由中生成一个HTML文件。通过将严格的SPA分解成单独的HTML文件，Next.js可以避免在客户端加载不必要的JavaScript代码，减少包的大小，实现更快的页面加载。

并行路由和拦截

Next.js 13.3 引入了新的动态约定，允许开发者实现高级路由案例： 并行路由和拦截路由。这些功能使你能够在同一个视图中显示一个以上的页面，比如复杂的仪表盘等。

通过并行路由，你可以在同一个视图中同时呈现一个或多个可以独立浏览的页面。它还可以用来有条件地渲染页面。

并行路由是使用命名的 “slots” 创建的。Slots 是用 约定进行定义的。

拦截路由允许您在当前布局中加载新路由，同时 “屏蔽” 浏览器 URL。 当保持当前页面的上下文很重要时，这很有用。

拦截路由可以使用 约定进行定义，类似于相对路径 . 开发者还可以使用 约定创建相对于 目录的路径。

其他

• Next.js 主页和展示页面已经更新了新的设计
• 的快速刷新
• 针对 的 Tailwind CSS
• 改进的样式表加载
• ……

更多详情可查看：https://github.com/vercel/next.js/releases/tag/v13.3.0

关注公众号

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

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

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

Netty 4.1.91.Final 现已发布。Netty 是一个异步事件驱动的网络应用框架，主要用于可维护的高性能协议服务器和客户端的快速开发。

这是一个错误修复版本，包含了对本地 SSL 实现的一个重要修复，以及修复了一个可能导致状态机出现问题的错误。

具体更新内容包括：

• 修复当 Chanel 在聚合过程中被关闭时，引发的 PrematureChannelClosureException 异常
• 如果服务器在使用 Socks5 时返回 NO_AUTH，则无需密码即可连接
• 使用 sun.net.dns 的可选分辨率
• 引入可用于将错误传播到所有活跃 stream 的 Http2MultiplexActiveStreamsException
• 重置 stream 时使用正确的错误提醒信息
• 在 HttpContentDecoder 上添加 snappy 支持
• 在通知调用方握手完成之前不会解包多个记录
• 修复 io.netty.channel.unix.Errors 中的 Handle EHOSTUNREACH 错误

下载地址 | 发布公告

Haxe 是开源的高级严格类型编程语言，具有快速且经过优化的交叉编译器。

Haxe 可以构建目标平台是 JavaScript、C++、C#、Java、JVM、Python、Lua、PHP、Flash 的跨平台应用程序，并支持访问每个平台的原生功能。Haxe 有自己的 VM（HashLink 和 NekoVM），同时支持在解释模式下运行。用 Haxe 编写的代码可以编译为 Haxe 支持的任何目标平台语言。

Haxe 4.3 主要变化：

• 支持类型参数的默认值
• 支持 abstract 关键字引用摘要
• 在表达式级别支持静态变量
• 支持 ?.  安全导航操作符
• 添加 ?? 空合并运算符
• 支持数字分隔符
• 支持数字文字后缀
• 添加 -w 编译器选项以配置警告
• 添加新的错误报告模式
• 支持自定义数据和定义

此版本还包含其他新功能、优化、改进和错误修复，点此查看详情。

下载地址

GoEdge 是一款可以帮你快速构建 CDN & WAF 平台的工具，支持 HTTP、HTTPS、Websocket、TCP、TLS、UDP、PROXY Protocol、IPv6、WAF 等特性，支持多个第三方 DNS 服务。

在经历3年研发、1500+社群用户深度使用、5000个commits之后，GoEdge决定发布1.0.0版本。GoEdge v1.0.0版本主要大幅优化攻击拦截功能、更新免费版IP库、批量上传SSL证书。

EdgeAdmin – 管理系统

• 网站服务
  • 优化创建网站服务界面：简化界面，减少必填项
  • 当HTTP和HTTPS端口冲突时提示用户；避免用户同时在HTTP和HTTPS设置中使用同样的端口
  • 集群服务设置增加“支持低版本HTTP”选项，可以选择不支持HTTP/1.0及以下版本的HTTP协议
• 缓存
  • 修复在未初始化缓存设置时添加缓存条件产生的panic错误，但此错误不会影响系统正常运行
• 访问日志
  • 访问日志数据库节点详情中密码使用星号（*）代替，以提升安全性
• SSL证书
  • SSL证书内容输入框支持拖动文件上传
  • SSL证书支持批量上传，此功能可以在”证书管理“中找到
  • 在创建服务和修改服务设置时自动根据填写的域名匹配对应的证书
  • 创建服务和修改服务时也可以批量上传证书
  • 选择证书时可以通过用户筛选
  • 上传证书时可以选择所属用户
• 边缘节点
  • 优化节点列表显示，包括统计项宽度、连接数更加可读、带宽使用两位小数、隐藏和显示更多IP
  • 创建节点时自动从节点名称中提取节点IP，比如节点名称可以为“CDN节点192.168.2.100”，则自动提取“192.168.2.100”作为节点默认IP
  • 生成节点DNS解析时区分节点是否已安装；如果节点未完成安装，则不会解析，避免在安装过程中，用户通过域名解析访问到未安装的节点
• SSH认证
  • 创建SSH认证私钥时校验私钥内容；避免填入错误的私钥
  • SSH认证添加私钥时可以从私钥文件中直接拖入内容
• 管理员
  • 管理员列表页增加关键词搜索支持
  • 管理员列表在有弱密码的管理员下增加弱密码标识，只有超级管理员才能看到此标识
  • 首页看板可以提示有需要修改的弱密码管理员
• 日志审计
  • 日志审计增加日志级别筛选
• 管理系统
  • 如果管理系统同时设置了HTTP和HTTPS端口，那么访问HTTP登录页时自动跳转到HTTPS地址
  • 增强Cookie安全性，可以防止Cookie被截取后异地登录
• MySQL
  • 自动安装MySQL时自动生成所需的动态库软链接，以适应一些比较新的系统
  • 自动安装mysql时调整innodb_sort_buffer_size、innodb_buffer_pool_size参数值

EdgeAPI – API节点

• 数据库
  • 使用sql.json取代以往的sql.go作为数据库结构存储文件
  • 优化服务列表查询方法，避免因MySQL参数设置而导致查询失败
  • 在API节点启动时，如果无法连接到本地MySQL数据库，则尝试启动固定位置上的MySQL，避免有些用户不知道如何启动MySQL
• 域名解析
  • 修复无法同时对相同对象执行多次DNS解析任务的问题
  • DNS解析发生变化时立即触发同步任务，即让域名解析生效更快
• 配置
  • 优化节点配置生成，合并证书数据，减少配置文件尺寸
  • 增加RPC消息最大尺寸到512MB，避免大的配置信息无法传输
  • 增加命令用来快速查询节点Token，方便用户在忘记EdgeAdmin、EdgeUser、EdgeAPI令牌时令牌时快速查询
• 流量带宽
  • 合并部分流量查询和带宽查询，提升查询速度
• 消息提醒
  • 修复发送站内消息时将标题作为内容的Bug
  • 优化证书到期提醒等相关消息，可以在提示信息中看到域名相关信息
• IP名单
  • 修复删除IP名单中IP时状态设置错误的问题，此问题可能会导致节点在从IP名单中删除单个IP时消耗大量的CPU

EdgeNode – 边缘节点

• WAF
  • 在GET302和CAPTCHA验证中不记录特殊URL的访问日志，避免生成大量无效的访问日志
  • 优化IP名单上传程序，自动去重，并可以批量上传
  • 优化WAF黑名单处理，即使WAF不开启也仍然有效，并自动结合本地防火墙进行拦截
  • nftables规则使用REJECT代替DROP
• URL跳转没有选择状态码时，对搜索引擎访问默认值设置为301，以提升SEO效果
• 源站返回分片内容时提示访问用户内容不支持低版本HTTP协议
• 增加网站服务加载和删除调试日志，这些日志不会上传到API节点
• 限制单个服务每次上传的域名统计数不超过20个，避免大量的域名统计对API节点数据库造成很大的压力
• 修复在高并发下修改服务配置可能导致服务崩溃（panic）的问题
• 重启服务时自动保存未上传的带宽统计信息，以便在下次启动的时候恢复
• 增加RPC消息最大尺寸到512MB，避免大的配置信息无法传输
• 不提示单个端口Reload信息，防止不重要的日志过多
• 节点启动时自动调整相关内核参数，如net.core.somaxconn、net.ipv4.tcp_fin_timeout等

EdgeCommon – 通用库

• 修复IP查询结果显示时可能不显示县级单位的问题

完整变更说明：https://goedge.cn/docs/Releases/Index.md
下载：https://goedge.cn/downloads

智能制造一体化管理系统 [SpringBoot2 – 快速开发平台]，适用于制造业、建筑业、汽车行业、互联网、教育、政府机关等机构的管理。包含文件在线操作、工作日志、多班次考勤、CRM、ERP 进销存、项目管理、EHR、拖拽式生成问卷、日程、笔记、工作计划、行政办公、薪资模块、动态表单、知识库、公告模块、企业论坛、云售后模块、生产模块、系统模块化同步模块等多种复杂业务功能。

有一些小伙伴很好奇最近更新的内容和智能制造有什么关系？

答：目前 Skyeye 整体在做重构，优先从底层的一些功能开始，所以现在大家看到的和智能制造的联系不是很大，也希望大家能够理解，一个大型的智能制造对底层的依赖性也是非常高的。

智能制造一体化 v3.9.9 发布 ，更新内容如下：

• 已完成测试的组件：输入框，下拉框，文本框，上传组件，枚举卡槽，文字分割线，编码规则，附件上传，数据字典卡槽，团队模板，部门信息，用户选择，往来单位，凭证，账户，账套
• 已托管到表单布局的功能：角色管理，桌面管理，前台服务配置，编码管理，联系人管理 (新增 / 编辑)，CRM 客户管理，CRM 客户合同 (新增 / 编辑)，CRM 客户商机 (新增 / 编辑)，CRM 客户跟单 (新增 / 编辑)，IFS 财务账户，IFS 账套管理，IFS 会计科目，IFS 收支项目，IFS 明细账，工序管理
• 考勤模块：请假申请、加班申请、销假申请、出差申请、考勤班次等功能后端修改为低代码平台完成，待托管到表单布局
• 招聘模块：人员需求申请、转岗申请、面试者管理等功能后端修改为低代码平台完成，待托管到表单布局
• 修改若干问题

erp： https://gitee.com/doc_wei01/erp-pro

OA： https://gitee.com/doc_wei01/skyeye

报表：https://gitee.com/doc_wei01/skyeye-report  有问题可以联系作者，详情请看开发计划。

效果图

作者：京东科技 孙凯

一、前言



对前端开发者来说，Vite 应该不算陌生了，它是一款基于 nobundle 和 bundleless 思想诞生的前端开发与构建工具，官网对它的概括和期待只有一句话：“下一代的前端工具链”。

Vite 最早的版本由尤雨溪发布于3年前，经历了3年多的发展，Vite 也已逐渐迭代成熟，它的稳定性、扩展性、周边生态足以在生产环境中支撑各种业务场景的落地。但是关于Vite的优劣势分析我们就戛然而止，不在深入展开了，这不是本文的重点。

本文的重点在于探究 Vite 如何实现兼容低版本浏览器，这一切还得从那个阳光明媚的午后说起🤔。

二、那个午后

本着尝鲜的态度，我在某一个项目中用了 Vite，当时还是3.x.x的版本，跟着文档配置，从项目启动到项目构建，一路都很“德芙”（纵享丝滑），在经历了 Vite 带来的短暂新鲜感后，就一直沉浸在业务模块的开发中了，因为在 Vite 刚发布后的那段时间曾看过相关原理解析，是基于浏览器原生的模块化能力按需构建BALABALA等，所以后来 Vite 的这种新鲜感对我而言并没有保持多久。

但直到有天下午我开始打包提测，审查页面素后发现构建产物居然跟以往 webpack 的产物竟然有点不一样，在好奇心的驱使下，于是我开始尝试解谜。

三、跟webpack构建产物到底哪里不一样？

1. 准备工作

为了能更好的对比两者产物究竟有什么区别，我们首先要确保我们的业务代码基本一致，不一致的地方仅仅是使用不同工具（ vite 和 webpack）进行构建，这样才能排除最大干扰因素。

于是我们分别使用最新版的 Vite 和 webpack 初始化了两个页面，为了做作区分，两个页面的仅标题和标题背景不一致，他们在浏览器中渲染后的分别长这个样子：





2. 构建工具版本说明

3. 构建工具配置项说明

至此，准备工作完毕，让我们看看两者的构建产物吧。

4. 构建产物





从产物的命名中，我们就能多少看出些许区别，webpack的产物比较简单，中规中矩，而 Vite 的 JS 文件不但比 webpack 多，而且部分文件命名中还多了一个单词：legacy，百度翻译对它的解释是：遗产;遗赠财物;遗留;后遗症；（计算机系统或产品）已停产的，通过翻译，或许你可以猜出来，名字中带 legacy 的文件大概率就是浏览器的兼容文件，那么事实到底是不是这样呢？

如果你足够细心，其实你应该可以从上面 Vite 的配置项代码中嗅到一丝端倪，在 Vite 的配置文件中，有一个名为 @vitejs/plugin-legacy 的插件，它的名字也包含 legacy，Vite 官网中对这个插件的解释是这样的：

“传统浏览器可以通过插件 @vitejs/plugin-legacy 来支持，它将自动生成传统版本的 chunk 及与其相对应 ES 语言特性方面的 polyfill。兼容版的 chunk 只会在不支持原生 ESM 的浏览器中进行按需加载。”

也就是说，这个插件它不但提供了低版本浏览器的兼容能力，还提供了检测是否支持原生 ESM 的能力。那么这个插件都做了哪些事？

主要是以下三点：

如此可见，Vite 兼容低版本浏览器的能力就是来自于 @babel/preset-env 无疑了，都是生成 polyfill 和语法转换， 但是这不就和 webpack 一样了么，事实是 Vite 又帮我们多做了一层，那就是上面反复提到的原生浏览器模块化能力 ESM。

5. Vite 的原生模块化能力

我们看看 Vite 打包后HTML中的内容，内容较多，我分开讲，先看 head 标签中的内容

代码的前两行加载了入口 JS （index-a712caef.js，记住这个文件名，后面会用到）和 CSS，JS资源使用了 ESM 的模块化方式加载，等等，嗯？JS 居然使用了 ESM ？如果当前浏览器不兼容 ESM，那这段 JS岂不是永远不会执行？

其实这就是 ESM 模块化的能力之一，对于携带 type=”module” 这个属性的 script 标签，不支持 ESM 的浏览器不会执行内部代码，所以报错也就不存在了，与之对应的 script 上还有 nomodule 这个属性，支持ESM的浏览器会忽略携带这个属性的 script，可以防止某些兼容逻辑在高版本浏览器执行，这两个属性组合使用就是为了决定浏览器在面对未知版本浏览器时的代码执行策略，我们画个简易流程图理解一下：





继续往下看。

接下来的两段内联 script 标签中的内容很关键，我们先看第一段代码，这段代码暂且命名为代码A：

期初我看上面这段代码的时候，我就想：这写的都是些个什么东西！前三行都是高级ES语法，部分浏览器根本不兼容好嘛，这都能写上去，真不怕报错和白屏？

其实要注意 script 标签上 type=”module” 这个属性，ESM模块化的好处之一就是，它在处理报错信息的时候，不像普通 script 一样会把错误抛到模块外部，内部出错也不会阻塞后续逻辑的执行和页面渲染，接下来我们验证一下这个观点，直接上代码：

执行结果如下：





先不管代码结果的输出顺序，我们在这只看输出结果，与上述结论一致的，即错误影响了内部模块，并中断了后续的代码逻辑，而外部不受影响。

在 Vite 生成的 HTML 中这样做的好处就是为了检测浏览器对相关语法的支持程度，如果模块中的语法不支持，就会停止执行；如果支持，那么同时打上一个标记，也就是上述示例代码A的倒数第二行——通过在 window 上设置全局变量（因为ESM模块中的变量影响不到外部）window.__vite_is_modern_browser = true，来标识当前浏览器是否为一个“现代浏览器”，是否支持的某些语法特性（import.meta、动态导入、异步生成器），这样可以使 Vite 后续更准确的判断该加载那些 JS。

于是接下来我们就看到了下面这段代码：

它内部判断了 window.__vite_is_modern_browser 这个全局标识是否存在，如果存在，说明上一个模块中的代码执行没有问题，直接退出；如果不存在，说明当前浏览器不是一个“现代浏览器”，那就该加载和执行兼容文件了，于是可以看到这段代码的后半段，Vite 使用 SystemJs 加载了带有 legacy 标记的文件。

到了这里还没有结束， 虽然 Vite 在个别情况下加载了兼容文件，但如果你仔细看上述代码，会发现整个加载逻辑是放在拥有 type=”module” 这个属性的 script 中的，在前面已经阐述过了， type=”module” 在低版本浏览器是不会执行的，换句话说就是，低版本浏览器的兼容文件并不会被加载。于是 Vite 为了低版本浏览器能正常执行业务逻辑，又做了如下操作——

以下代码来自 VIte 打包后 body 标签中的内容：

可以看到，在低版本浏览器中 Vite 使用了带有 nomodule 属性的 script 标签，先加载了 polyfills 文件，确保后续代码中使用的API能正确执行，再通过 SystemJs 加载入口文件执行后续逻辑，至此， Vite 兼容旧版本浏览器的逻辑算是基本讲述完毕了。

6. “魔鬼藏在细节中”

纵观Vite的整个加载流程，粗一看没有什么大问题，但是经不起推敲，我们再来捋一捋，看看还发生了什么。

第一步，Vite 在页面最开始加载了 CSS 和 JS，加载 JS 的方式是使用 ESM

第二步，Vite 判断了现代浏览器的兼容性，如果是现代浏览器，则不执行 nomodule 中的代码，也不会使用 SystemJs 加载 legacy 文件，反之亦然。

第三部，Vite 对低版本浏览器使用 nomodule 的 script 标签，加载和执行 legacy 文件。



等等，你有没有发现，第一步和第二步有些问题？

我们前面已经说过了，在第二步中，Vite 根据 window.__vite_is_modern_browser 处理了是否加载 legacy 文件的逻辑，但是这里的代码是包裹在 type=”module” 这个属性的 script 中的！问题就出现在这里！

我们想象一个场景：总有那么一部分浏览器支持 ESM 的同时，又不支持 import.meta.url; import(“_”).catch(() => 1); async function* g() { } 这三种语法之一，这是必然的，因为语法诞生的时间不一致。

这也就导致了一个 Vite 的行为：在支持 ESM、同时不支持高级上述三种语法任意一种的时候，window.__vite_is_modern_browser 为 false，Vite 通过 SystemJs 加载了 legacy 文件，但也因为当前浏览器支持 ESM，致使 Vite 在第一步中通过 ESM 加载的 JS 是重复加载！

也就是说，Vite 在这种情况下同时加载了原生模块化的文件和兼容文件！

但更值得思考的还在后面：不管是原生模块化的文件，还是兼容文件，他们对页面的处理逻辑是一致的，因为文件的同时加载，这会不会导致页面执行两次相同的逻辑？

答案是：不会。

Vite 是知道这种情况的，并且已经处理过了，它处理的手段你肯定会觉得很眼熟，就在整个 ESM 文件入口的前几行（也就是本文构建产物中的 index-a712caef.js ）——

它声明了一个函数，函数内部包含了高版本的语法，Vite 充分利用了 JS 语法边解析边执行的特性：如果当前环境不支持高版本语法，那就在语法解析阶段报错就好了，直接暴力阻止后续逻辑的执行，因为使用了原生模块化的能力，反正错误也不会抛给外面，对页面没有什么影响！

怎么样，这才是完整的 Vite 兼容方案，不得不说，真是有很多细节值得学习和思考。

对于重复加载 ESM 文件， @vitejs/plugin-legacy 是承认缺点存在的，这个插件在 README 中原文是这样解释的：

大概意思就是：它认为主流浏览器对这三种语法是广泛认可的，换句话也就是说，Vite 的目标其实还是绝大部分现代浏览器，太过低端的已经不考虑了。。。

最后放出 @vitejs/plugin-legacy 的 README 地址： https://github.com/vitejs/vite/tree/main/packages/plugin-legacy#readme

四、总结

不啰嗦，直接上加载过程完整的流程图，一百句话也不如一张图直观。

最后，实名感谢各位小伙伴的观看，如果能点个赞就更好了 🙌。



Mirrorful是一个简单、开源的设计系统框架。安装 Mirrorful 可以为你的项目生成颜色和其他设计标记，然后将这些设计标记直接导入你的应用程序。

• 以真实的来源开始新的项目
• 直观地修改主题
• 生成颜色
• 主题模板
• 轻量级 Headless 组件库
• Eslint 规则
• Figma 整合

开始

Mirrorful 是一个 NPM 包，旨在作为开发依赖项安装。

 npm install mirrorful -D

或者

 yarn add mirrorful -D

近日，一个名为 Money Message 的勒索软件组织声称，他们已经成功入侵了 PC 制造商微星（MSI）的系统，访问了微星的 CTMS 和 ERP 数据库，窃取了该公司的源代码、密钥，以及微星产品中使用的 BIOS 固件等，数据总量达到 1.5TB。

Money Message 在暗网上发布了被盗文件的截图，并要求微星支付 400 万美来赎回这些数据，否则将在本周公开这些被盗数据。

微星是我国台湾地区的一家 PC 制造商，主要生产高端的 PC 主板、GPU、笔记本、显示器和其他 PC 周边产品，深受电竞玩家的喜爱。而在事件发生后，微星则是在官网发布了一个简短声明，证实遭到了网络攻击：

MSI 的部分信息系统最近遭受了网络攻击。 信息部门发现网络异常后，及时启动相关防御机制并采取恢复措施，并将事件报告政府执法部门和网络安全部门。 目前，受影响的系统已逐步恢复正常运行，对金融业务无重大影响。

MSI 敦促用户仅从官方网站获取固件/BIOS 更新，并且不要使用来自官方网站以外来源的文件。

不过，这则简短的声明并没有透露任何细节，因此我们也不清楚这 1.5TB 的数据中是否包含微星的用户数据，以及勒索软件组织所声称的源代码和密钥等信息，也尚不清楚 Money Message 究竟是以什么方式入侵的微星，亦或是 MSI 是否有意支付这笔 400 万美的赎金。

网络安全公司 Cyble 表示，Money Message 似乎是上个月才刚刚出现的新兴勒索软件组织，虽然才成立不久，但目前已知受影响的企业已经超过五个，该组织以 Windows 和 Linux 电脑为目标，窃取用户数据，传播勒索软件。

树莓派基金会近日为正式学习编程的用户，推出网页端代码编辑器。该编辑器目前处于测试阶段，感兴趣的用户可以访问 editor.raspberrypi.org 页面免费体验。

该编辑器目前设计为仅支持 Python，但该组织表示即将支持 HTML、JavaScript 和 CSS 等其它语言。

该界面由三个窗格组成：项目中的文件列表、代码编辑器和当您“运行”按钮时运行代码结果的输出窗口。

使用该编辑器需要创建免费账号，之后系统会将你所有的项目保存在云端，你可以随时重新加载它们。你还能以 .zip 文件格式下载源代码。

注：本文使用New Bing（GPT4.0）演示

让他扮演一个Java软件开发者

第一步：我们让ChatGPT扮演一个Java软件开发者的角色

• 提示词插件：地址：ChatGPT BingChat GPT3 Prompt Generator App (Streamlit) – a Hugging Face Space by Kaludi

Java Software Developer Java软件开发者

准备一个不太好的Java代码示例

第二步：我们准备一个写得不太好的Java代码示例

• Bad Java Example：

让他优化这段代码

第三步：让newBing（ChatGPT）优化这段代码

• 并且要求「整理成比较优雅的代码结构，比如自动拆分子函数、降低if和循环嵌套，甚至实现部分设计模式。」

让他写个单测

第四步：我们最后让他收下尾——写个单测吧

最后，数据安全是最大的问题，不要乱贴数据到 ChatGPT，尤其是涉及后端核心存储账户密码、公司核心业务数据、部门核心战略规划等。因为首先，ChatGPT会使用你的问答语料进行训练；其次，你无法预料在什么Prompt提示词下，LLM模型会讲你无意中泄露的信息回答出去。

瑕不掩瑜，ChatGPT为代表的LLM模型，在充当我们无所不知的老师、充当不知疲倦的通用Util代码编写者这些角色时能极大的提高我们的开发效率，尤其在数据分析、前端、单测、重构等领域。

就像文章第一步写的一样，ChatGPT就像是一个百变身份，你可以让他扮演任何角色，而每一个角色都能在这个角色范围内帮助我们获得更美好的生活。

更有意思的用法期待大家的发掘。

摘要：Laplace 用于 Laplace 分布的概率统计与随机采样。

本文分享自华为云社区《Laplace分布算子开发经验分享》，作者：李长安。

1、任务解析

详细描述：

Laplace 用于 Laplace 分布的概率统计与随机采样， 此任务的目标是在 Paddle 框架中，基于现有概率分布方案进行扩展，新增 Laplace API，调用路径为：paddle.distribution.Laplace 。类签名及各个方法签名，请通过调研 Paddle 及业界实现惯例进行设计。要求代码风格及设计思路与已有概率分布保持一致。

实际上说了一大堆，就是一件事：实现Laplace分布算子，那么首先我们需要知道什么是 Laplace 分布，在概率论和统计学中，拉普拉斯分布是一种连续概率分布。由于它可以看作是两个不同位置的指数分布背靠背拼在一起，所以它也叫双指数分布。与正态分布对比，正态分布是用相对于μ平均值的差的平方来表示，而拉普拉斯概率密度用相对于差的绝对值来表示。如下面的代码所示，Laplace 分布的图像和正态分布实际上是有点类似的，所以它的公式也与正态分布的公式类似的。

2、设计文档撰写

设计文档是我们API设计思路的体现，是整个开发工作中必要的部分。通过上述任务简介，我们可以知道此API的开发主要为Laplace分布的开发，需要包含一些相应的方法。首先我们需要弄清楚Laplace分布的数学原理，这里建议去维基百科查看Laplace分布的数学原理，弄明白数学原理。此外，我们可以参考Numpy、Scipy、Pytorch、Tensorflow的代码实现，进行设计文档的撰写。

首先，我们应该知道Laplace分布的概率密度函数公式、累积分布函数、逆累积分布函数，并且根据公式开发出代码，公式如下所示：

参考Numpy、Scipy、Pytorch、Tensorflow的代码实现，我们这里可以很容易的实现公式对应的代码，其实现方案如下3.1小节所示。

2.1 API 实现方案

该 API 实现于 paddle.distribution.Laplace。

基于paddle.distribution API基类进行开发。

class API 中的具体实现（部分方法已完成开发，故直接使用源代码），该api有两个参数：位置参数self.loc, 尺度参数self.scale。包含以下方法：

• mean 计算均值:

• stddev 计算标准差:

• variance 计算方差:

• sample 随机采样(参考pytorch复用重参数化采样结果):

• rsample 重参数化采样:

其中 u = paddle.uniform(shape=shape, min=eps – 1, max=1); eps根据dtype决定;

• prob 概率密度(包含传参value):

直接继承父类实现

• log_prob 对数概率密度(value):

• entropy 熵计算:

• cdf 累积分布函数(value):

• icdf 逆累积分布函数(value):

• kl_divergence 两个Laplace分布之间的kl散度(other–Laplace类的一个实例):

参考文献：https://openaccess.thecvf.com/content/CVPR2021/supplemental/Meyer_An_Alternative_Probabilistic_CVPR_2021_supplemental.pdf

同时在paddle/distribution/kl.py 中注册_kl_laplace_laplace函数，使用时可直接调用kl_divergence计算laplace分布之间的kl散度。

2.2 测试和验收的考量

在我们开发完对应的代码后，我们应该如何证明我们所开发出来的代码是正确的呢？这时候就需要单测试的代码来证明我们的代码是正确的。那么什么是单测试呢？单测试的用例其实是一个“输入数据”和“预计输出”的集合。你需要跟你输入数据，根据逻辑功能给出预计输出，这里所说的根据逻辑功能是指，通过需求文档就能给出的预计输出。而非我们通过已经实现的代码去推导出的预计输出。这也是最容易被忽视的一点。你要去做单测试，然后还要通过代码去推断出预计输出，如果你的代码逻辑本来就实现错了，给出的预计输出也是错的，那么你的单测试将没有意义。实际上，这部分可以说是整个工作中最重要的部分也是比较难的部分，我们需要想出预计输出，并且如何通过已经实现的代码去推导出预计输出，只有单测试通过了，我们的开发任务才算基本完成了。

根据api类各个方法及特性传参的不同，把单测分成三个部分：测试分布的特性（无需额外参数）、测试分布的概率密度函数（需要传值）以及测试KL散度（需要传入一个实例）。

1、测试Lapalce分布的特性

• 测试方法：该部分主要测试分布的均值、方差、熵等特征。类TestLaplace继承unittest.TestCase，分别实现方法setUp（初始化），test_mean（mean单测），test_variance（variance单测），test_stddev（stddev单测），test_entropy（entropy单测），test_sample（sample单测）。
  • 均值、方差、标准差通过Numpy计算相应值，对比Laplace类中相应property的返回值，若一致即正确；
  • 采样方法除验证其返回的数据类型及数据形状是否合法外，还需证明采样结果符合laplace分布。验证策略如下：随机采样30000个laplace分布下的样本值，计算采样样本的均值和方差，并比较同分布下scipy.stats.laplace返回的均值与方差，检查是否在合理误差范围内；同时通过Kolmogorov-Smirnov test进一步验证采样是否属于laplace分布，若计算所得ks值小于0.02，则拒绝不一致假设，两者属于同一分布；
  • 熵计算通过对比scipy.stats.laplace.entropy的值是否与类方法返回值一致验证结果的正确性。
• 测试用例：单测需要覆盖单一维度的Laplace分布和多维度分布情况，因此使用两种初始化参数
  • ‘one-dim’: loc=parameterize.xrand((2, )), scale=parameterize.xrand((2, ));
  • ‘multi-dim’: loc=parameterize.xrand((5, 5)), scale=parameterize.xrand((5, 5))。

2、测试Lapalce分布的概率密度函数

• 测试方法：该部分主要测试分布各种概率密度函数。类TestLaplacePDF继承unittest.TestCase，分别实现方法setUp（初始化），test_prob（prob单测），test_log_prob（log_prob单测），test_cdf（cdf单测），test_icdf（icdf）。以上分布在scipy.stats.laplace中均有实现，因此给定某个输入value，对比相同参数下Laplace分布的scipy实现以及paddle实现的结果，若误差在容忍度范围内则证明实现正确。
• 测试用例：为不失一般性，测试使用多维位置参数和尺度参数初始化Laplace类，并覆盖int型输入及float型输入。
  • ‘value-float’: loc=np.array([0.2, 0.3]), scale=np.array([2, 3]), value=np.array([2., 5.]); * ‘value-int’: loc=np.array([0.2, 0.3]), scale=np.array([2, 3]), value=np.array([2, 5]);
  • ‘value-multi-dim’: loc=np.array([0.2, 0.3]), scale=np.array([2, 3]), value=np.array([[4., 6], [8, 2]])。

3、测试Lapalce分布之间的KL散度

• 测试方法：该部分测试两个Laplace分布之间的KL散度。类TestLaplaceAndLaplaceKL继承unittest.TestCase，分别实现setUp（初始化），test_kl_divergence（kl_divergence）。在scipy中scipy.stats.entropy可用来计算两个分布之间的散度。因此对比两个Laplace分布在paddle.distribution.kl_divergence下和在scipy.stats.laplace下计算的散度，若结果在误差范围内，则证明该方法实现正确。
• 测试用例：分布1：loc=np.array([0.0]), scale=np.array([1.0]), 分布2: loc=np.array([1.0]), scale=np.array([0.5])

3、代码开发

代码的开发主要参考Pytorch，此处涉及到单测试代码的开发，kl散度注册等代码，需要仔细阅读PaddlePaddle中其他分布代码的实现形式。

4、总结

目前，该API已经锁定贡献。回顾API的开发过程，实际上该API的开发并不难，主要的问题在于如何进行单测试，证明开发的API是正确的，并且还有一些相关的细节点，比如KL散度的注册等。还有就是最开始走了弯路，参照了Normal的开发风格，将API写成了2.0风格的，影响了一些时间，并且在最后的单测中，发现了Uniform实现方式的一些Bug，此处Debug花费了一些时间，整体来看，花时间的部分是在单测部分。

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

摘要：本文主要通过实例讲解如何通过gs_cpuwatcher.sh 脚本寻找CPU占用高语句。

本文分享自华为云社区《GaussDB(DWS) gs_cpuwatcher.sh 脚本如何寻找CPU占用高语句》，作者：fighttingman。

【工具名称】

gs_cpuwatcher

【功能描述】

1.寻找集群内节点占用CPU高的语句

【使用场景】

1. CPU sys使用率高
2. 业务整体慢

【参数说明】

无

【使用方法】

1. 直接后台执行命令

nohup sh gs_cpuwatcher.sh > cpuwatcher.log 2>&1 &

执行之前注意事项：

• 使用omm用户（线下）或者Ruby用户（线上）执行
• 将脚本放到一个磁盘空间充足的目录执行，防止把磁盘空间占满，脚本监控会产生日志，占用磁盘空间，磁盘空间最好大于20G
• 监控完之后kill这个监控进程，防止忘记这个脚本造成监控日志一直上涨，脚本默认保留3天的日志
• 脚本只有在进程的cpu使用率大于100（多核累加和）的时候才会进行查询cpu高的语句

【最佳实践&结果分析】

执行监控命令之后，检查当前目录生成的监控日志

查看日志cpu_watch_xxx.log日志，里边有记录占用CPU高的语句

日志里边记录了cpu占用高的语句，例如上图中select * from pg_class a, pg_class，脚本默认截取sql的前50个字符，可以对截取字符串进行修改，需要修改脚本

字段解释：

1. dur ：执行时长
2. start：sql的起始时间
3. state_change：sql状态改变时间
4. usename：用户名称
5. datname：连的数据库名称
6. query_id：sql的唯一标识id
7. pid：线程id
8. client_addr：客户端连的ip
9. state：sql的执行状态
10. lwtid：线程小号
11. wait_status：等待视图中的等待状态字段
12. substr：sql字段

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

在上篇文章《 开发者实战 | 如何应用Anomalib在数据集不平衡的情况下检测缺陷？-上篇》中，我们介绍了深度学习异常检测库 Anomalib（复制到浏览器打开：https://github.com/openvinotoolkit/anomalib）。简而言之，当您想进行自动缺陷检测，但数据集不平衡时，Anomalib 是一个很好的工具。

希望您已经通过入门 notebook （复制到浏览器打开：https://github.com/openvinotoolkit/anomalib/tree/main/notebooks/000_getting_started）访问并亲自试用了这个开源项目。如果没有，请不要担心，这篇博文将教您如何结合自己的数据集使用 Anomalib。

在这个示例中，我们将介绍一个令人振奋的 Dobot 机器人工业用例，其中的机械臂用于教育、工业和智能用例中。如果您没有可用的 Dobot 机器人，您可以简单地修改 notebook，避开、注释或改变机器人代码，使其为您所用。

图 4：训练和验证模块。

图 6：运行 Anomalib 模型推理的教育机器人

摘要：StampedLock是一种在读取共享变量的过程中，允许后面的一个线程获取写锁对共享变量进行写操作，使用乐观读避免数据不一致的问题，并且在读多写少的高并发环境下，比ReadWriteLock更快的一种锁。

本文分享自华为云社区《一文彻底理解并发编程中非常重要的票据锁——StampedLock》，作者：冰 河 。

什么是StampedLock?

ReadWriteLock锁允许多个线程同时读取共享变量，但是在读取共享变量的时候，不允许另外的线程多共享变量进行写操作，更多的适合于读多写少的环境中。那么，在读多写少的环境中，有没有一种比ReadWriteLock更快的锁呢？

答案当然是有！那就是我们今天要介绍的主角——JDK1.8中新增的StampedLock！没错，就是它！

StampedLock与ReadWriteLock相比，在读的过程中也允许后面的一个线程获取写锁对共享变量进行写操作，为了避免读取的数据不一致，使用StampedLock读取共享变量时，需要对共享变量进行是否有写入的检验操作，并且这种读是一种乐观读。

总之，StampedLock是一种在读取共享变量的过程中，允许后面的一个线程获取写锁对共享变量进行写操作，使用乐观读避免数据不一致的问题，并且在读多写少的高并发环境下，比ReadWriteLock更快的一种锁。

StampedLock三种锁模式

这里，我们可以简单对比下StampedLock与ReadWriteLock，ReadWriteLock支持两种锁模式：一种是读锁，另一种是写锁，并且ReadWriteLock允许多个线程同时读共享变量，在读时，不允许写，在写时，不允许读，读和写是互斥的，所以，ReadWriteLock中的读锁，更多的是指悲观读锁。

StampedLock支持三种锁模式：写锁、读锁（这里的读锁指的是悲观读锁）和乐观读（很多资料和书籍写的是乐观读锁，这里我个人觉得更准确的是乐观读，为啥呢？我们继续往下看啊）。其中，写锁和读锁与ReadWriteLock中的语义类似，允许多个线程同时获取读锁，但是只允许一个线程获取写锁，写锁和读锁也是互斥的。

另一个与ReadWriteLock不同的地方在于：StampedLock在获取读锁或者写锁成功后，都会返回一个Long类型的变量，之后在释放锁时，需要传入这个Long类型的变量。例如，下面的伪代码所示的逻辑演示了StampedLock如何获取锁和释放锁。

StampedLock支持乐观读，这是它比ReadWriteLock性能要好的关键所在。 ReadWriteLock在读取共享变量时，所有对共享变量的写操作都会被阻塞。而StampedLock提供的乐观读，在多个线程读取共享变量时，允许一个线程对共享变量进行写操作。

我们再来看一下JDK官方给出的StampedLock示例，如下所示。

在上述代码中，如果在执行乐观读操作时，另外的线程对共享变量进行了写操作，则会把乐观读升级为悲观读锁，如下代码片段所示。

这种将乐观读升级为悲观读锁的方式相比一直使用乐观读的方式更加合理，如果不升级为悲观读锁，则程序会在一个循环中反复执行乐观读操作，直到乐观读操作期间没有线程执行写操作，而在循环中不断的执行乐观读会消耗大量的CPU资源，升级为悲观读锁是更加合理的一种方式。

StampedLock实现思想

StampedLock内部是基于CLH锁实现的，CLH是一种自旋锁，能够保证没有“饥饿现象”的发生，并且能够保证FIFO（先进先出）的服务顺序。

在CLH中，锁维护一个等待线程队列，所有申请锁，但是没有成功的线程都会存入这个队列中，每一个节点代表一个线程，保存一个标记位(locked)，用于判断当前线程是否已经释放锁，当locked标记位为true时， 表示获取到锁，当locked标记位为false时，表示成功释放了锁。

当一个线程试图获得锁时，取得等待队列的尾部节点作为其前序节点，并使用类似如下代码判断前序节点是否已经成功释放锁:

只要前序节点(pred)没有释放锁，则表示当前线程还不能继续执行，因此会自旋等待；反之，如果前序线程已经释放锁，则当前线程可以继续执行。

释放锁时，也遵循这个逻辑，线程会将自身节点的locked位置标记为false，后续等待的线程就能继续执行了，也就是已经释放了锁。

StampedLock的实现思想总体来说，还是比较简单的，这里就不展开讲了。

StampedLock的注意事项

在读多写少的高并发环境下，StampedLock的性能确实不错，但是它不能够完全取代ReadWriteLock。在使用的时候，也需要特别注意以下几个方面。

StampedLock不支持重入

没错，StampedLock是不支持重入的，也就是说，在使用StampedLock时，不能嵌套使用，这点在使用时要特别注意。

StampedLock不支持条件变量

第二个需要注意的是就是StampedLock不支持条件变量，无论是读锁还是写锁，都不支持条件变量。

StampedLock使用不当会导致CPU飙升

这点也是最重要的一点，在使用时需要特别注意：如果某个线程阻塞在StampedLock的readLock()或者writeLock()方法上时，此时调用阻塞线程的interrupt()方法中断线程，会导致CPU飙升到100%。例如，下面的代码所示。

运行上面的程序，会导致thread02线程所在的CPU飙升到100%。

这里，有很多小伙伴不太明白为啥LockSupport.park();会导致thread01会永远阻塞。这里，冰河为你画了一张线程的生命周期图，如下所示。

这下明白了吧？在线程的生命周期中，有几个重要的状态需要说明一下。

• NEW：初始状态，线程被构建，但是还没有调用start()方法。
• RUNNABLE：可运行状态，可运行状态可以包括：运行中状态和就绪状态。
• BLOCKED：阻塞状态，处于这个状态的线程需要等待其他线程释放锁或者等待进入synchronized。
• WAITING：表示等待状态，处于该状态的线程需要等待其他线程对其进行通知或中断等操作，进而进入下一个状态。
• TIME_WAITING：超时等待状态。可以在一定的时间自行返回。
• TERMINATED：终止状态，当前线程执行完毕。

看完这个线程的生命周期图，知道为啥调用LockSupport.park();会使thread02阻塞了吧？

所以，在使用StampedLock时，一定要注意避免线程所在的CPU飙升的问题。那如何避免呢？

那就是使用StampedLock的readLock()方法或者读锁和使用writeLock()方法获取写锁时，一定不要调用线程的中断方法来中断线程，如果不可避免的要中断线程的话，一定要用StampedLock的readLockInterruptibly()方法获取可中断的读锁和使用StampedLock的writeLockInterruptibly()方法获取可中断的悲观写锁。

最后，对于StampedLock的使用，JDK官方给出的StampedLock示例本身就是一个最佳实践了，小伙伴们可以多看看JDK官方给出的StampedLock示例，多多体会下StampedLock的使用方式和背后原理与核心思想。

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

摘要：本案例我们利用视频字幕识别中的文字检测与识别模型，增加预训练Bert进行纠错

本文分享自华为云社区《Bert特调OCR》，作者：杜甫盖房子。

做这个项目的初衷是发现图比较糊/检测框比较长的时候，OCR会有一些错误识别，所以想对识别结果进行纠错。一个很自然的想法是利用语义信息进行纠错，其实在OCR训练时加入语义信息也有不少工作，感兴趣的朋友可以了解一下，为了更大程度复用已有的项目，我们决定保留现有OCR单，在之后加入独立语义纠错模块进行纠错。

本案例我们利用视频字幕识别中的文字检测与识别模型，增加预训练Bert进行纠错，最终效果如下：

我们使用进行开发，如果还没有安装，可以参考ModelBox端云协同AI开发套件（Windows）设备注册篇、ModelBox端云协同AI开发套件（Windows）SDK安装篇完成设备注册与安装。

技能开发

这个应用对应的版本已经做成模板放在华为云OBS中，可以用sdk中的工具下载，接下来我们给出该应用在中的完整开发过程：

1）下载模板

执行可看到当前公开的技能模板：

结果中的doc_ocr_db_crnn_bert即为文档识别应用模板，下载模板：

工具的参数中， 代表，即列出当前已有的模板名称； 代表，即下载对应名称的模板。下载下来的模板资源，将存放在核心库的目录下。

2）创建工程

在 sdk目录下使用创建工程

工具的参数中， 表示创建事务的类别，包括工程(server)、Python功能单(Python)、推理功能单(infer)等； 代表，即创建事务的名称； 代表，表示将使用后面参数值代表的模板创建工程，而不是创建空的工程。

目录下将创建出工程，工程内容如下所示：

3）查看流程图

工程目录下存放流程图，默认的流程图与工程同名，将流程图可视化：

图示中，灰色部分为预置功能单，其余颜色为我们实现的功能单，其中绿色为一般通用功能单，红色为推理功能单，蓝色为条件功能单，黄色为展开归拢功能单。HTTP接收图解码后做预处理，接着是文字检测，模型后处理得到检测框，经过条件功能判断，检测到文字的图送入展开功能单，切图进行文字识别，文字识别结果送入bert预处理单判断是否需要进行纠错，如需纠错则再展开并行进行语义推理，不需要纠错的就直接进行结果绘制并返回。而未检测到文字的帧则直接返回。

4）核心逻辑

本应用核心逻辑中的文字检测与识别可以参考【ModelBox OCR实战营】视频字幕识别中的相关介绍，本文重点介绍文字纠错部分。

首先查看纠错预处理功能单：

预处理单对通过函数对OCR结果进行判断，只对大于3个字的中文字符进行纠错：

通过函数定位需要纠错的字符，只对OCR置信度小于阈值的字符进行纠错：

如有需要纠错的字符，则将该句编码，进行语义推理。

语义推理后，通过对推理结果进行解码，在功能单中使用函数计算语义推理结果与OCR结果的字符相似度：

其中，decompose_text函数将单个汉字编码为笔划级别的IDS，如：

华: ⿱⿰⿰丿丨⿻乚丿⿻一丨

计算语义推理结果字符与原OCR结果字符相似度之后，综合语义推理置信度与相似度判断是否接收纠错结果：

5）三方依赖库

本应用依赖pyclipper、Shapely、pillow等工具包，ModelBox应用不需要手动安装三方依赖库，只需要配置在，应用在编译时会自动安装。

技能运行

在项目目录下执行运行应用，为了方便观察纠错结果，我们将日志切换为info：

另起终端，进入项目目录下，运行脚本进行测试：

可以在技能运行日志中观察到接受的纠错结果：

同时，在目录下可以看到应用返回的结果图片：

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

准确的讲，Redis 事务包含两种模式 : 事务模式 和 Lua 脚本。

先说结论：

Redis 的事务模式具备如下特点：

• 保证隔离性；
• 无法保证持久性；
• 具备了一定的原子性，但不支持回滚；
• 一致性的概念有分歧，假设在一致性的核心是约束的语意下，Redis 的事务可以保证一致性。

但 Lua 脚本更具备实用场景，它是另一种形式的事务，他具备一定的原子性，但脚本报错的情况下，事务并不会回滚。Lua 脚本可以保证隔离性，而且可以完美的支持后面的步骤依赖前面步骤的结果。

Lua 脚本模式的身影几乎无处不在，比如分布式锁、延迟队列、抢红包等场景。

1 事务原理

Redis 的事务包含如下命令：

事务包含三个阶段：

1. 事务开启，使用 MULTI , 该命令标志着执行该命令的客户端从非事务状态切换至事务状态 ；
2. 命令入队，MULTI 开启事务之后，客户端的命令并不会被立即执行，而是放入一个事务队列 ；
3. 执行事务或者丢弃。如果收到 EXEC 的命令，事务队列里的命令将会被执行 ，如果是 DISCARD 则事务被丢弃。

下面展示一个事务的例子。

这里有一个疑问？在开启事务的时候，Redis key 可以被修改吗？

在事务执行 EXEC 命令之前 ，Redis key 依然可以被修改。

在事务开启之前，我们可以 watch 命令监听 Redis key 。在事务执行之前，我们修改 key 值 ，事务执行失败，返回 nil 。

通过上面的例子，watch 命令可以实现类似乐观锁的效果 。

2 事务的ACID

2.1 原子性

原子性是指：一个事务中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样。

第一个例子：

在执行 EXEC 命令前，客户端发送的操作命令错误，比如：语法错误或者使用了不存在的命令。

在这个例子中，我们使用了不存在的命令，导致入队失败，整个事务都将无法执行 。

第二个例子：

事务操作入队时，命令和操作的数据类型不匹配 ，入队列正常，但执行 EXEC 命令异常 。

这个例子里，Redis 在执行 EXEC 命令时，如果出现了错误，Redis 不会终止其它命令的执行，事务也不会因为某个命令执行失败而回滚 。

综上，我对 Redis 事务原子性的理解如下：

1. 命令入队时报错， 会放弃事务执行，保证原子性；
2. 命令入队时正常，执行 EXEC 命令后报错，不保证原子性；

也就是：Redis 事务在特定条件下，才具备一定的原子性 。

2.2 隔离性

数据库的隔离性是指：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

事务隔离分为不同级别 ，分别是：

• 未提交读（read uncommitted）
• 提交读（read committed）
• 可重复读（repeatable read）
• 串行化（serializable）

首先，需要明确一点：Redis 并没有事务隔离级别的概念。这里我们讨论 Redis 的隔离性是指：并发场景下，事务之间是否可以做到互不干扰。

我们可以将事务执行可以分为 EXEC 命令执行前和 EXEC 命令执行后两个阶段，分开讨论。

1. EXEC 命令执行前

在事务原理这一小节，我们发现在事务执行之前 ，Redis key 依然可以被修改。此时，可以使用 WATCH 机制来实现乐观锁的效果。

1. EXEC 命令执行后

因为 Redis 是单线程执行操作命令， EXEC 命令执行后，Redis 会保证命令队列中的所有命令执行完 。 这样就可以保证事务的隔离性。

2.3 持久性

数据库的持久性是指 ：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

Redis 的数据是否持久化取决于 Redis 的持久化配置模式 。

1. 没有配置 RDB 或者 AOF ，事务的持久性无法保证；
2. 使用了 RDB模式，在一个事务执行后，下一次的 RDB 快照还未执行前，如果发生了实例宕机，事务的持久性同样无法保证；
3. 使用了 AOF 模式；AOF 模式的三种配置选项 no 、everysec 都会存在数据丢失的情况 。always 可以保证事务的持久性，但因为性能太差，在生产环境一般不推荐使用。

综上，redis 事务的持久性是无法保证的 。

2.4 一致性

一致性的概念一直很让人困惑，在我搜寻的资料里，有两类不同的定义。

1. 维基百科

我们先看下维基百科上一致性的定义：

Consistency ensures that a transaction can only bring the database from one valid state to another, maintaining database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This prevents database corruption by an illegal transaction, but does not guarantee that a transaction is correct. Referential integrity guarantees the primary key – foreign key relationship.

在这段文字里，一致性的核心是“约束”，“any data written to the database must be valid according to all defined rules ”。

如何理解约束？这里引用知乎问题 如何理解数据库的内部一致性和外部一致性，蚂蚁金服 OceanBase 研发专家韩富晟回答的一段话：

“约束”由数据库的使用者告诉数据库，使用者要求数据一定符合这样或者那样的约束。当数据发生修改时，数据库会检查数据是否还符合约束条件，如果约束条件不再被满足，那么修改操作不会发生。

关系数据库最常见的两类约束是“唯一性约束”和“完整性约束”，表格中定义的主键和唯一键都保证了指定的数据项绝不会出现重复，表格之间定义的参照完整性也保证了同一个属性在不同表格中的一致性。

“ Consistency in ACID ”是如此的好用，以至于已经融化在大部分使用者的血液里了，使用者会在表格设计的时候自觉的加上需要的约束条件，数据库也会严格的执行这个约束条件。

所以事务的一致性和预先定义的约束有关，保证了约束即保证了一致性。

我们细细品一品这句话： This prevents database corruption by an illegal transaction, but does not guarantee that a transaction is correct。

写到这里可能大家还是有点模糊，我们举经典转账的案例。

我们开启一个事务，张三和李四账号上的初始余额都是1000，并且余额字段没有任何约束。张三给李四转账1200。张三的余额更新为 -200 ， 李四的余额更新为2200。

从应用层面来看，这个事务明显不合法，因为现实场景中，用户余额不可能小于 0 ， 但是它完全遵循数据库的约束，所以从数据库层面来看，这个事务依然保证了一致性。

Redis 的事务一致性是指：Redis 事务在执行过程中符合数据库的约束，没有包含非法或者无效的错误数据。

我们分三种异常场景分别讨论：

1. 执行 EXEC 命令前，客户端发送的操作命令错误，事务终止，数据保持一致性；
2. 执行 EXEC 命令后，命令和操作的数据类型不匹配，错误的命令会报错，但事务不会因为错误的命令而终止，而是会继续执行。正确的命令正常执行，错误的命令报错，从这个角度来看，数据也可以保持一致性；
3. 执行事务的过程中，Redis 服务宕机。这里需要考虑服务配置的持久化模式。
   • 无持久化的内存模式：服务重启之后，数据库没有保持数据，因此数据都是保持一致性的；
   • RDB / AOF 模式： 服务重启后，Redis 通过 RDB / AOF 文件恢复数据，数据库会还原到一致的状态。

综上所述，在一致性的核心是约束的语意下，Redis 的事务可以保证一致性。

1. 《设计数据密集型应用》

这本书是分布式系统入门的神书。在事务这一章节有一段关于 ACID 的解释：

Atomicity, isolation, and durability are properties of the database,whereas consistency (in the ACID sense) is a property of the application. The application may rely on the database’s atomicity and isolation properties in order to achieve consistency, but it’s not up to the database alone. Thus, the letter C doesn’t really belong in ACID.

原子性，隔离性和持久性是数据库的属性，而一致性（在 ACID 意义上）是应用程序的属性。应用可能依赖数据库的原子性和隔离属性来实现一致性，但这并不仅取决于数据库。因此，字母 C 不属于 ACID 。

很多时候，我们一直在纠结的一致性，其实就是指符合现实世界的一致性，现实世界的一致性才是事务追求的最终目标。

为了实现现实世界的一致性，需要满足如下几点：

1. 保证原子性，持久性和隔离性，如果这些特征都无法保证，那么事务的一致性也无法保证；
2. 数据库本身的约束，比如字符串长度不能超过列的限制或者唯一性约束；
3. 业务层面同样需要进行保障 。

2.5 事务特点

我们通常称 Redis 为内存数据库 , 不同于传统的关系数据库，为了提供了更高的性能，更快的写入速度，在设计和实现层面做了一些平衡，并不能完全支持事务的 ACID。

Redis 的事务具备如下特点：

• 保证隔离性；
• 无法保证持久性；
• 具备了一定的原子性，但不支持回滚；
• 一致性的概念有分歧，假设在一致性的核心是约束的语意下，Redis 的事务可以保证一致性。

从工程角度来看，假设事务操作中每个步骤需要依赖上一个步骤返回的结果，则需要通过 watch 来实现乐观锁 。

3 Lua 脚本

3.1 简介

Lua 由标准 C 编写而成，代码简洁优美，几乎在所有操作系统和平台上都可以编译，运行。Lua 脚本可以很容易的被 C/C ++ 代码调用，也可以反过来调用 C/C++ 的函数，这使得 Lua 在应用程序中可以被广泛应用。

Lua 脚本在游戏领域大放异彩，大家耳熟能详的《大话西游II》，《魔兽世界》都大量使用 Lua 脚本。Java 后端工程师接触过的 api 网关，比如 Openresty ，Kong 都可以看到 Lua 脚本的身影。

从 Redis 2.6.0 版本开始， Redis内置的 Lua 解释器，可以实现在 Redis 中运行 Lua 脚本。

使用 Lua 脚本的好处 ：

• 减少网络开销。将多个请求通过脚本的形式一次发送，减少网络时延。
• 原子操作。Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。
• 复用。客户端发送的脚本会永久存在 Redis 中，其他客户端可以复用这一脚本而不需要使用代码完成相同的逻辑。

Redis Lua 脚本常用命令：

3.2 EVAL 命令

命令格式：

说明：

• 是第一个参数，为 Lua 5.1脚本；
• 第二个参数指定后续参数有几个 key；
• ，是要操作的键，可以指定多个，在 Lua 脚本中通过, 获取；
• ，参数，在 Lua 脚本中通过, 获取。

简单实例：

下面演示下 Lua 如何调用 Redis 命令 ，通过来执行了 Redis 命令 。

3.3 EVALSHA 命令

使用 EVAL 命令每次请求都需要传输 Lua 脚本 ，若 Lua 脚本过长，不仅会消耗网络带宽，而且也会对 Redis 的性能造成一定的影响。

思路是先将 Lua 脚本先缓存起来 , 返回给客户端 Lua 脚本的 sha1 摘要。 客户端存储脚本的 sha1 摘要 ，每次请求执行 EVALSHA 命令即可。

EVALSHA 命令基本语法如下：

实例如下：

4 事务 VS Lua 脚本

从定义上来说， Redis 中的脚本本身就是一种事务， 所以任何在事务里可以完成的事， 在脚本里面也能完成。 并且一般来说， 使用脚本要来得更简单，并且速度更快。

因为脚本功能是 Redis 2.6 才引入的， 而事务功能则更早之前就存在了， 所以 Redis 才会同时存在两种处理事务的方法。

不过我们并不打算在短时间内就移除事务功能， 因为事务提供了一种即使不使用脚本， 也可以避免竞争条件的方法， 而且事务本身的实现并不复杂。

— https://redis.io/

Lua 脚本是另一种形式的事务，他具备一定的原子性，但脚本报错的情况下，事务并不会回滚。Lua 脚本可以保证隔离性，而且可以完美的支持后面的步骤依赖前面步骤的结果。

Lua 脚本模式的身影几乎无处不在，比如分布式锁、延迟队列、抢红包等场景。

不过在编写 Lua 脚本时，要注意如下两点：

1. 为了避免 Redis 阻塞，Lua 脚本业务逻辑不能过于复杂和耗时；
2. 仔细检查和测试 Lua 脚本 ，因为执行 Lua 脚本具备一定的原子性，不支持回滚。

作者：京东零售  吴迪

前言

• 在实际开发过程中，经常使用一些开源工具库，如 lodash，以方便、快捷的进行项目开发。但是当 npm上没有自己中意或符合自身业务的工具时，我们不得不自己动手，此时拥有自己的、基于业务的工具库就显得尤为重要。
• 我们所熟知的Vue、React等诸多知名前端框架，或公司提供的一些类库，它们是如何开发、构建、打包出来的，本文将带领你了解到如何从0到1构建基于自身业务的前端工具库。

构建工具库主流方案

1. WEBPACK

• webpack 提供了构建和打包不同模块化规则的库，只是需要自己去搭建开发底层架构。
• vue-cli，基于 webpack ， vue-cli 脚手架工具可以快速初始化一个 vue 应用，它也可以初始化一个构建库。

2. ROLLUP

• rollup 是一个专门针对JavaScript模块打包器，可以将应用或库的小块代码编译成更复杂的功能代码。
• Vue、React 等许多流行前端框架的构建和打包都能看到 rollup 的身影。

为什么采用 ROLLUP 而不是 WEBPACK

• webpack 主要职能是开发应用，而 rollup 主要针对的就是 js 库的开发，如果你要开发 js 库，那 webpack 的繁琐配置和打包后的文件体积就不太适用了，通过webpack打包构建出来的源代码增加了很多工具函数以外的模块依赖代码。
• rollup 只是把业务代码转码成目标 js ，小巧且轻便。rollup对于代码的Tree-shaking和ES6模块有着算法优势上的支持，如果只想构建一个简单的库，并且是基于ES6开发的，加上其简洁的API，rollup得到更多开发者的青睐。

工具库底层架构设计

构建工具库底层架构大概需要哪些功能的支持：



架构依赖需知

在对底层架构设计的基础上，首先需要把用到的依赖库简单熟悉一下：

rollup 全家桶

typescript 相关

文档相关

单测试相关

其他依赖

底层架构搭建

1. 初始化项目

新建一个文件夹 utils-demo，执行 npm init，过程会询问构建项目的基本信息，按需填写即可：

2. 组织工具库业务开发 SRC 目录结构

创建工具库业务开发 src 文件目录，明确怎样规划工具库包，里面放置的是工具库开发需要的业务代码：



3. 安装项目依赖

要对 typescript 代码进行解析支持需要安装对 ts 支持的依赖，以及对开发的工具的一些依赖包：

这里遇到一个坑，关于最新 chalk5.0.0 不支持在 nodejs 中 require()导入，所以锁定包版本 chalk@^4.1.2

要对 typescript 进行解析和编译还需要配置 tsconfig.json，该文件中指定了用来编译这个项目的根文件和编译选项，在项目根目录，使用 tsc –init 命令快速生成 tsconfig.json 文件（前提全局安装 typescript）

初始化 tsconfig 完成之后，根目录自动生成 tsconfig.json 文件，需要对其进行简单的配置，以适用于 ts 项目，其中具体含义可以参考tsconfig.json官网

4. 组织项目打包构建 SCRIPTS 目录结构

1) 根目录创建项目打包构建 scripts 脚本文件目录，里面放置的是有关于项目打包构建需要的文件：



生成rollup配置项函数核心代码：

2) rollup 在打包构建的过程中需要进行 babel 的转译，需要在根目录添加.babelrc 文件告知 babel：

3) 此时距离打包构建工具库只差一步之遥，配置打包脚本命令，在 package.json 中配置命令：

4) 执行 yarn build，根目录会构建出一个 lib 文件夹，里面有打包构建的文件，还多了一个 stats.html，这个是可视化并分析 Rollup bundle，用来查看工具模块占用空间：



架构搭建优化

项目搭建到这里，不知机智的你能否发现问题：

1) 只要添加了一个工具，就要在入口文件导出需要打包构建的工具，在多人开发提交代码的时候将引来冲突的产生：



2) 使用工具库的时候，按需引用的颗粒度太细了，不能满足一些要求颗粒度粗的朋友，比如：

能不能这样？

能不能这样？

这样仅仅使用 date 里面的工具，就没有必要将所有的工具都引入了

解决方案：

1) 针对第一个代码冲突的问题，可以根据 src > modules 下目录结构自动生成入口文件 index.ts





自动构建入口文件核心代码：

2) 针对颗粒度的问题，可以将 modules 下各种类型工具文件夹下面也自动生成入口文件，除了全部导出，再追加 import * as 模块类名称 类型的导出

至此，基本上解决了工具库打包的问题，但是架构中还缺少本地开发调试的环境，下面为大家介绍如何架构中添加本地开发调试的系统。

本地开发调试系统

首先要明确要加入本地开发调试系统的支持，需要做到以下：

1) 跨平台设置环境变量很简单，使用 cross-env 指定 node 的环境

2) 配置 package.json 命令

3) 根据最开始架构设计的模块，在项目根目录新建 debugger 文件夹，里面存放的是工具调试的 html 静态页面



4) 接下来就是配置 scripts > rollup.config.js ，将 NODE_ENV=development 环境加入 rollup 配置，修改生成rollup配置项函数核心代码：

5) 执行 yarn dev 之后浏览器会新打开窗口，输入刚添加的工具链接，并且它是热更新的：



工具库文档系统

一个完备的工具库需要有一个文档来展示开发的工具函数，它可能需要具备以下几点支持：

typedoc（TypeScript 项目的文档生成器）能完美支持 typescript 开发工具库的文档生成器的支持，它的核心原理就是读取源代码，根据工具的注释、ts的类型规范等，自动生成文档页面

关于热更新机制的支持，第一个自然想到 browser-sync（文档系统热更新）

由于文档系统的预览功能有很多插件组合来实现的，可以借助 gulp （基于流的自动化构建工具），typedoc正好有对应的 gulp-typedocGulp 插件来执行 TypeDoc 工具插件



构建完成后打开文档系统，并且它是热更新的，修改工具方法后自动更新文档：



单测试

为确保用户使用的工具代码的安全性、正确性以及可靠性，工具库的单测试必不可少。单测试选用的是 Facebook 出品的 Jest 测试框架，它对于 TypeScript 有很好的支持。

1. 环境搭建

1) 首先全局安装 jest 使用 init 来初始化 jest 配置项

执行完之后根目录会自动生成jest.config.ts 文件，里面设置了单测试的配置规则，package.json 里面也多了一个 script 指令 test。

2) 关于jest.config.js文件配置项具体含义可以查看官网，要想完成 jest 对于 TypeScript 的测试，还需要安装一些依赖：

3) jest 还需要借助 .babelrc 去解析 TypeScript 文件，再进行测试，编辑 .babelrc 文件，添加依赖包 @babel/preset-typescript：

2. 单测试文件的编写

1) 通过以上环节，jest 单测试环境基本搭建完毕，接下来在__tests__下编写测试用例



2) 执行 yarn test

可以看到关于 debounce 防抖工具函数的测试情况显示在了控制台：



3) 同时还会发现项目根目录多了一个 coverage 文件夹，里面就是 jest 生成的测试报告：



3. 单测试文件的编写引发的思考

每次修改单测试都要执行 yarn test 去查看测试结果，怎么解决？

jest提供了 watch 指令，只需要配置 scripts 脚本就可以做到，单测试的热更新。

以后会写很多工具的测试用例，每次 test 都将所有工具都进行了测试，能否只测试自己写的工具？

jest 也提供了测试单个文件的方法，这样 jest 只会对防抖函数进行测试（前提全局安装了 jest）。

工具库包的发布

至此工具库距离开发者使用仅一步之遥，就是发布到npm上，发包前需要在 package.json 中声明库的一些入口，关键词等信息。

登陆npm，你会看到自己的 packages 里面有了刚刚发布的工具库包：



写在最后

以上就是作者整理的从0到1构建基于自身业务的前端工具库的全过程，希望能给阅读本文的开发人员带来一些新的想法与尝试。

在此基础上已经成功在京东npm源发布了应用于京东汽车前端的工具库@jdcar/car-utils，并在各个业务线及系统得到落地。

当然，架构优化之路也还远未结束，比如：打包构建的速度、本地开发按需构建、工具库脚手架化等，后续我们也会基于自身业务以及一些新技术，持续深入优化，在性能上进一步提升，在功能上进一步丰富。本文或存在一些浅显不足之处，也欢迎大家评论指点。

参考资料

[1] rollup 英文文档（https://rollupjs.org/guide/en/#quick-start）

[2] rollup 中文文档（https://rollupjs.org/guide/zh/#introduction）

[3] Rollup.js 实战学习笔记（https://chenshenhai.github.io/rollupjs-note/）

[4] Rollup 打包工具的使用（https://juejin.cn/post/）

[5] TypeScript、Rollup 搭建工具库（https://juejin.cn/post/0）

[6] 使用 rollup.js 封装各项目共用的工具包（https://juejin.cn/post/）

[7] 如何开发一个基于 TypeScript 的工具库并自动生成文档（https://juejin.cn/post/）

[8] 一款优雅、简洁的 JavaScript 测试框架（https://jestjs.io/zh-Hans/）

作者：京东科技 周明亮

AST 基础与功能

在前端里面有一个很重要的概念，也是最原子化的内容，就是 AST ，几乎所有的框架，都是基于 AST 进行改造运行，比如：React / Vue /Taro 等等。 多端的运行使用，都离不开 AST 这个概念。

在大家理解相关原理和背景后，我们可以通过手写简单的编译器，简单实现一个 Javascript 的代码编译器，编译后在浏览器端正常运行。

通过实现一个自定义的编译器，我们发现我们自己也能写出很多新的框架。最终目标都是通过编译转换，翻译为浏览器识别的 Javascript + CSS + HTML。

没错！翻译翻译～

 

当然我们也可以以这个为基础，去实现跨端的框架，直接翻译为机器码，跑到各种硬件上。当然一个人肯定比较困难，你会遇到各种各样的问题需要解决，不过没关系，只要你有好的想法，拉上一群人，你就能实现。

大家记得点赞，评论，收藏，一键三连啊～

分析器

说到这个代码语义化操作前，我们先说说分析器，其实就是编译原理。当你写了一段代码，要想让机器知道，你写了啥。

那机器肯定是要开始扫描，扫描每一个关键词，每一个符号，我们将进行词法分析的程序或者函数叫作词法分析器（Lexical analyzer），通过它的扫描可以将字符序列转换为单词（Token）序列的过程。

扫描到了关键词，我们怎么才能把它按照规则，转换为机器认识的特定规则呢？比如你扫描到：

机器怎么知道要创建一个 变量 a 并且等于 1 呢？

所以，这时候就引入一个概念：语法分析器（Syntactic analysis，Parser）。通过语法分析器，不断的调用词法分析器，进行语法检查、并构建由输入的单词组成的数据结构（一般是语法分析树、抽象语法树等层次化的数据结构）。

在JS的世界里，这个扫描后得到的数据结构 抽象语法树 【AST】。可能很多人听过这个概念，但是具体没有深入了解。机缘巧合，刚好我需要用到这个玩意，今天就简单聊聊。

抽象语法树 AST

AST 是 Abstract Syntax Tree 的缩写，也就是：抽象语法树。在代码的世界里，它叫这个。在语言的世界里面，他叫语法分析树。

语言世界，举个栗子：

语法分析树：
主语：我，人称代词。
谓语：写，动词。
宾语：文章，名词。

长一点的可能会有：主谓宾定状补。是不是发现好熟悉，想当年大家学语文和英语，那是一定要进行语法分析，方便你理解句子要表达的含义。

PS：对我来说，语法老难了！！！哈哈哈，大家是不是找到感觉了～

接下来我们讲讲代码里面的抽象语法树。

那我们用来进行语法分析，能够得到什么内容了？这时候我们可以借助已有的工具，将他们进行分析，进行一个初级入门。

其实我们也可以完全自己进行分析，不过这样就不容易入门，定义的语法规则很多，如果只是看，很容易就被劝退了。而通过辅助工具，我们可以很快接受相关的概念。

常用的工具有很多，比如：Recast 、Babel、Acorn 等等

也可以使用在线 AST 解析：AST Explorer，左上角菜单可以切换到各种解析工具，并且支持各类编程语言的解析，强大好用，可以用来学习，帮助你理解 AST。

 

为了帮助大家理解，我们一点点的进行解析，并且去掉了部分属性，留下主干部分，完整的可以通过在线工具查看。【不同解析器，对于根节点或者部分属性稍有区别，但是本质是一样的。】

接下来，我们一个一个节点看，首先是第一个节点 Program

Program 是代码程序的根节点，通过它进行节点一层一层的遍历操作。 上面我们看出它有两个节点，一个是变量声明节点，另外一个是函数声明节点。

如果我们再定义一个变量或者函数，这时候 body 就又会产生一个节点。我们要扫描代码文件时，我们就是基于 body 进行层层的节点扫描，直到把所有的节点扫描完成。

上面对应的代码，就是 const me = “我” ，这个节点告诉我们。 声明一个变量，使用类型是：VariableDeclaration, 他的唯一标识名是：me，初始化值：“我”。

后续的函数分析，也是一样的。

这个节点，清楚的告诉我们，这个函数名是什么，他里面有哪些内容，入参是什么，调用了什么函数对象。

我们发现，通过语法分析器的解析，我们可以把代码，变成一个对象。这个对象将代码分割为原子化的内容，很容易能够帮助机器或者我们去理解它的组成。

这个就是分析器的作用，我们不再是一大段一大段的看代码逻辑，而是一小段一小段的看节点。

有了这个我们可以干什么呢？

AST 在 JS 中的用途

1. 自定义语法分析器，写一个新的框架。

通过对现有的 AST 理解，我们可以依葫芦画瓢，写出自定义的语法分析器，转成自定义的抽象语法树，再进行解析转为浏览器可识别的 Javascript 语言，或者其他硬件上能识别的语言。

比如：React / Vue 等等框架。其实这些框架，就是自定义了一套语法分析器，用他们特定的语言，进行转换，翻译翻译，生成相关的DOM节点，操作函数等等 JS 函数。

2. 利用已有语法分析器，实现多端运行。

通过已有的 AST，我们将代码进行翻译翻译，实现跨平台多端运行。我们将得到代码进行语法解析，通过遍历所有的节点，我们将他们进行改造，使得它能够运行在其他的平台上。

比如：Taro / uni-app 等等框架。我们只要写一次代码，框架通过分析转换，就可以运行到 H5 / 小程序等等相关的客户端。

3. 进行代码改造，预编译增强处理。

依旧是通过已有的 AST，我们将代码进行分析。再进行代码混淆，代码模块化处理，自动进行模块引入，低版本兼容处理。

比如：Webpack / Vite 等等打包工具。我们写完代码，通过他们的处理，进行增强编译，增强代码的健壮性。

AST 的应用实践

我们在进行框架的改造或者适配时，我们可能才会用到这个。常规的方法，可能有两种：

• 按照特定的写法，通过正则表达式，直接进行大段代码替换。
• / mingliang start */ const a = 1 / mingliang end */

如，我们找到这段代码注释，直接通过 code.replace(/mingliang/g, ‘xxxx’) 类似这种方式替换。

• 通过引入运行，改造相关的变量，再重新写入。

我们可能先 let config = require(a.js) 运行这个文件，我们就得到了这个 config 这个变量值。

之后我们改写变量 config.a = 2,

最后，重新通过 fs.writeSync(‘a.js’, ‘return ‘ + JSON.stringify(config, null, 2)) 写入。

现在，我们就可以掌握新的方法，进行代码改造。

作者：京东科技 胡骏

引言

岁月如梭，十载流年

前端技术，蓬勃向前

HTML，CSS，JavaScript

演绎出璀璨夺目的技术画卷

回到十年前，前端技术就像一名戴着厚重眼镜的书呆子，总是小心翼翼，被各种各样的浏览器兼容性问题欺负（就像在小学被欺负一样）。

但随着时间的推移，这个书呆子开始锻炼，变得越来越强壮，终于能够对抗那些讨厌的兼容性问题

进入中学时期，前端技术遇到了那个改变它一生的朋友——jQuery。在jQuery的帮助下，前端技术变得更加自信，能够在各种浏览器之间轻松穿梭（就像找到了武林秘籍，功力大增）。

随后，前端技术开始追求更高的境界。它遇到了三位美丽的姑娘：Angular、React和Vue。这三位姑娘带给了前端技术无尽的魅力，让它迅速崛起，成为了技术江湖中的一股新兴力量。

如今，前端技术已经变得越来越强大，像一个熟练掌握各种武功的高手。它的发展速度之快，令人瞠目结舌，仿佛在短短十年内成为了武林盟主。它带领着一群忠诚的拜金党（程序员），在技术江湖中闯荡，创造了一个又一个的传奇。

而现在，前端技术正在为未来的挑战做准备，它还能带给我们多少惊喜，以及如何抵抗那些不断涌现的挑战者？让我们一起拭目以待，看这场武林大戏如何演绎。

一、历程

前端技术开发在过去的十年里经历了从HTML、CSS到JavaScript的演变。在这个历程中，前端工程师的角色也发生了变化，他们不再只是单纯的代码开发者，还需要与设计师、产品经理、运营人员等其他团队成员协作，共同完成网站的开发。

• _2010年以前，_前端工程师主要负责网站的静态页面开发，如网页设计、图片处理等。在这个阶段，前端工程师的技能主要包括HTML、CSS和JavaScript等基本技术。

• _2010年，_JavaScript成为了前端开发的主要语言。随着JavaScript的普及和发展，越来越多的前端工程师开始关注JavaScript的应用和开发。

• _2011年，_jQuery成为了前端开发的主流库，并且HTML5和CSS3开始受到重视。这也是前端开发变得更加动态和交互性的开始。

• _2012年，_响应式设计和移动设备优先的设计理念开始流行，前端开发在移动端上崭露头角。

• _2013年，_Angular引入了模块化和数据绑定的概念，Bootstrap实现了响应式框架，前端开发变得更加简单和高效。

• _2014年，_React发布，革新出组件化的思想，前端开发变得更加灵活和可维护。

• _2015年，_ES6发布，带来了诸如箭头函数、模板字符串和解构赋值等语言的改进，使JavaScript变得更加易用和现代化。同年，Vue的发布迅速获得了广泛应用。

• _2016年，_前端工具链的发展得到了加速，例如Webpack和Babel等工具的普及使得前端工程化得到了广泛推广。

• _2017年，_JavaScript库和框架更加多样，Angular、React和Vue等都在不断地演进和优化。PWA技术的普及使得网页更接近原生应用的用户体验。

• _2018年，_JavaScript框架的选择更加复杂，同时CSS预处理器（例如Sass和Less）和CSS-in-JS的技术也逐渐成熟。

• _2019年，_前端技术继续保持快速发展的趋势，更加注重用户体验和开发效率。例如，React Hooks和Vue 3等技术的推出使得前端代码更简洁并可维护。

• _2020年，_因新冠疫情影响，居家办公及远程工作成为新趋势。虚拟会议和在线教育等普及推动了前端技术的发展，也更加重视了访问性和用户体验。

• _2021年，_新技术和工具不断推陈出新。Web Assembly使得前端代码获得更高的效率，而预渲染和静态站点生成等技术让前端应用可以获得更快的加载速度。

• _2022年，_VR（虚拟现实）和AR（增强现实）技术的不断发展，前端开发者需要开发出更加适合VR/AR场景的应用程序。

• _2023年至今，_AI（人工智能）技术的突破性进展，前端技术将在AI 技术的加持下得到更广泛的应用，从而带来更智能和更高效的前端开发体验。

二、HTML5和CSS3的普及

HTML5和CSS3，这两个神秘代码世界的统治者，它们的名字听起来像是一对科学家的昵称，但它们的影响力却是无与伦比的：让我们的网页从普通变得绚丽多彩。

作为一名网页开发者，我们经常需要面对一些令人头疼的问题：浏览器兼容性、页面加载速度缓慢等。但是，当HTML5和CSS3出现在我们的视野中时，一切都变得不一样了。

HTML5是一种用于网页开发的语言，它具有更强的多媒体功能，比如说可以轻松地嵌入音频和视频。它还具有更强的语义，使我们可以更容易地描述页面内容。

而CSS3则是一种用于美化网页的语言，它提供了更多的样式选项，比如说可以实现圆角、阴影等效果。它还支持响应式设计，可以让我们的网页在不同的设备上都能得到最佳的展示效果。

用HTML5和CSS3开发的网页不仅美观，而且更快。我们不再需要使用大量的JavaScript代码来实现一些简单的功能，因为HTML5和CSS3已经帮我们完成了这些工作。

不仅如此，HTML5和CSS3还使得网页开发变得更有趣。我们可以创造出各种各样的动画效果，比如说滚动、旋转等，而不需要依赖任何第三方工具。这不仅让我们的网页更具吸引力，也使我们的用户更容易理解和使用。

HTML5就像一个网页的“建造师”，它负责把网页的框架建造出来，而CSS3则是一个“装饰师”，它负责把网页的外观和感觉打造出来。这对搭档携手合作，把一栋美丽的大厦（网站）拔地而起。

三、JavaScript框架的崛起

JavaScript框架，从这个词语中我们就能感受到它的强大和威力，如同统治世界的巨龙，横行天下，让所有的开发者都震撼不已。

在过去的十年里，我们见证了许多JavaScript框架的诞生和发展。最早的Angular和Backbone逐渐被React和Vue等框架所取代。这些框架不仅简化了开发者的工作流程，还引入了组件化的开发思想，提升了Web应用的可维护性和可扩展性。

另外，JavaScript框架也推动了Web前端技术的进步，引入了许多新的概念和理念，如组件化、数据驱动等等，使得Web前端开发变得更加简单而清晰。

3.1 React：让你的用户界面如此简单

React，这是一个神奇的JavaScript框架，它可以让你的用户界面变得如此简单，以至于你会想：“这就是魔法吗？”

React的核心思想是组件化，它把用户界面拆分成许多小的组件，每个组件都可以独立运行，并且可以方便地复用。这样，你就可以更加简单高效地开发出高质量的用户界面。

React的另一个优秀特性是Virtual DOM，它可以帮助你更快速地渲染用户界面，并且不会影响用户体验。这就像是一个超级快速的缓存，让你的用户界面飞快地呈现在用户面前。

React还提供了一些非常实用的功能，比如说React Router，它可以帮助你管理路由，让用户界面更加流畅；而React Redux可以帮助你管理应用状态，让你的代码更加整洁。

此外，React是一个非常活跃的开源项目，它的开发者们一直在不断改进和完善，值得每一个前端开发者去学习和使用。

3.2 Vue：充满了年轻的活力和智慧

Vue是另一个JavaScript框架，可以让你快速构建网页，就像是一个魔术师，把一堆杂乱无章的东西变成了一个美丽的魔术。

Vue的核心思想是数据驱动+组件化。这听起来很高大上，但其实就像是你在做一道数学题，先把问题分解成若干小问题，再一步步解决。

Vue有一个很酷的特性：双向绑定。这听起来很神秘，但实际上就像是你和你的好朋友之间的对话，你说了什么，他就知道了。

学习和使用Vue的过程中，你会发现开发变得更加简单和有趣，就像是在做一道神奇的拼图，一步步把图片拼出来，比如说它有很多组件，就像是一个工具箱，你可以随时随地使用。组件的好处在于，它可以把复杂的功能分解成若干个简单的部分，这样就可以很容易地管理和维护你的代码。

同时，Vue有很多很多的插件，可以让你的开发体验更加顺畅。插件的好处在于，它可以帮助你实现一些复杂的功能，这样就不必自己写一坨代码。

Vue还有一个很棒的社区，可以帮助你解决一些棘手的问题，也方便了你与其他开发者交流经验，编码世界有了朋友，永远不会孤单。

3.3 谨慎：利剑具有两面性

JavaScript框架是一个非常重要的工具，就像一把利剑帮助开发者切开困难，让开发者更加简便高效地开发前端应用，也推动了前端技术的进步，并抵达成功的彼岸。

但是，请记住，刀刃朝向你，也有可能伤到自己，因此请开发者在使用JavaScript框架时要谨慎小心。

四、Node.js和前后端分离

首先，让我们回顾一下过去，那时候前后端是紧密结合在一起的，像一对结婚多年的夫妇。它们有着许多共同的爱好，但是有时它们也会产生冲突，就像夫妇间的争吵一样，前后端争吵也是不可避免。

但是，随着技术的发展，我们发现了一个新的解决方案：前后端分离。就像夫妇分居一样，前后端也可以分开，以避免冲突，Node.js就是这个分离的功臣。

Node.js可以帮助前端和后端分开，各自独立工作。前端可以专注于用户界面的开发，后端可以专注于数据的处理，就像夫妇分别在各自的工作岗位上工作一样，前后端也可以分别在各自的领域里工作。

Node.js的出现让JavaScript可以在服务器端运行，为前后端分离的架构模式提供了可能。前后端分离使开发者可以更加专注于前端应用的开发，提高开发效率。同时，Node.js的诞生也带来了诸如npm、yarn等包管理器的出现，开发者可以轻松地引入和管理第三方库。

4.1 npm：被忽视的少年

首先，让我们了解一下npm的历史。它曾经是一个年轻的少年，总是被忽视。但是随着它长大，它变得越来越强大，并且成为了Node.js开发的重要组成部分。

以前，如果我们想要安装一个库，需要手动下载，并且手动安装它。这是一件非常繁琐的事情，而且很容易出错。但是，随着npm的出现，一切都变得更简单了。只需要运行一条命令（如：），就可以轻松地安装任何库。

npm还提供了一个巨大的软件仓库，其中包含了数以千计的库和工具。它就像一个图书馆，你可以随心所欲地查阅和使用。

但是，npm不仅仅是一个简单的安装工具。它还像一个管家，辅助我们管理依赖关系，并帮助我们发布代码和维护代码库。它还有许多其他功能，例如构建工具，测试工具等。因此，如果你想充分利用npm，请不要仅仅停留在它的基础功能上。

4.2 yarn：少年的替身

首先，让我们了解一下yarn的由来。它的诞生是为了解决npm的一些问题，就像是一个少年的替身，它试图取代npm并成为新的领导者。

yarn可以帮助我们快速安装依赖包，并管理依赖关系，像一个组织者可以帮助我们维护代码库，以此节省时间并提高开发效率。

yarn还提供了一个更好的版本控制系统，可以帮助我们管理依赖项的版本。如果你在多个项目中使用相同的依赖项，可以确保所有项目使用相同的版本，从而避免了版本冲突，譬如一个和平协调员。

除了管理依赖关系和解决依赖冲突外，yarn还可以帮助我们更快地进行安装，因为它可以在本地缓存安装过的依赖项。这意味着，如果你在多个项目中使用相同的依赖项，它们将不会再次下载，从而减少了安装时间。

此外，yarn支持并行安装，这意味着它可以同时安装多个依赖项，从而加快安装速度。这是一个非常有用的功能，特别是当你需要安装大量依赖项时。

yarn也有一个很棒的社区，可以帮助你解决任何问题。如果你在使用yarn时遇到问题，可以在社区中寻求帮助。这是一个非常有价值的资源，可以帮助你更快地解决问题。

五、构建工具和自动化

构建工具和自动化是现代软件开发的重要组成部分，就像给你的代码加上糖衣一样，帮助我们提高开发效率，并且可以让我们更专注于代码本身。

Grunt、Gulp、Webpack等工具的出现，使得开发者可以方便地实现代码压缩、合并、优化以及模块化等功能。而随着CI/CD的普及，自动化测试和部署变得更加便捷，大大提高了软件开发的质量和开发速度。

5.1 Grunt：猪叫的声音？

Grunt，这不是一个军人，也不是一个猪叫的声音。实际上，它是个非常酷的JavaScript任务运行器，可以帮助你自动化各种任务，如代码构建，单测试和文件合并。它的目的是让你的工作变得更轻松、更有效率，而且不需要你不停地敲代码。

想象一下，每次你修改了一个文件，你就需要手动编译、压缩、合并、测试等等。这听起来很枯燥，对吧？但是，如果有一个工具能帮你自动完成这些任务，那该有多好！这就是Grunt的作用。

Grunt的核心思想是使用插件（plugins）来完成各种任务。有数以百计的插件可以帮助你实现从编译Sass到压缩JavaScript的各种任务。插件是通过npm安装的。Grunt有许多内置任务，例如：文件压缩，CSS预处理，JavaScript检查等。此外，还有大量第三方插件，也可以助你完成更多任务。

Grunt的配置文件是，用于定义任务和任务的配置。Grunt使用JavaScript代码配置任务，因此对JavaScript基础知识的了解是使用Grunt的必备条件。

Grunt的任务可以在命令行中通过运行以下命令执行：。如果你想要实时监控文件的变化，并在文件变化时自动执行任务，你可以使用命令。

如果你是一个JavaScript开发者，那么Grunt是一个不可或缺的工具。它可以让你的工作变得更快捷、更高效，让你有更多的时间去做其他有趣的事情，比如喝咖啡、写文章或者是找对象。

5.2 Gulp：古老的咒语？

让我们来说说Gulp的名字。它的名字听起来有点像一个古老的魔法咒语，你想：“Gulp！” 然后你的代码就会变得更快、更简洁、更酷。不过，实际上Gulp并不是魔法，而是非常实用的构建工具。

Gulp的工作原理很简单：它通过创建一系列的任务，来自动完成你的工作流程。比如说，你可以创建一个任务，来自动编译你的Sass文件，或者压缩你的JavaScript文件。这样，你就不需要手动执行这些步骤了，Gulp会帮你完成。

Gulp还有一个非常酷的功能：它可以实时监控你的文件，并在你修改了文件后立即执行相应的任务。这样，你就可以实时看到更改的内容，而不需要手动重新执行。

Gulp如何使用呢？首先，你需要安装Node.js和npm，因为Gulp是基于Node.js的。其次，安装Gulp的命令行工具，只需在终端中运行以下命令即可：。接下来，你需要在项目目录中创建一个文件，这是npm的配置文件，用于管理项目依赖。你可以通过运行以下命令来创建一个文件：。然后，你需要安装Gulp，只需在项目目录中运行以下命令即可：。最后，创建一个文件，这是Gulp的配置文件，用于编写你的任务。

现在，你已经准备好使用Gulp了。开始编写你的任务，并运行以下命令来执行吧：。

5.3 Webpack：订制的包包？

Webpack可以帮你把代码压缩成小而美的包，就像私人订制的收纳柜，它可以装下你所有的包包，并且把它们整齐地放在一起，使你的“奢侈”更加有序！

但是，如果你犯了错误，它就像一个恶魔般出现在你面前，吼叫着告诉你：“Error: This is error！”所以，请小心使用Webpack。

不过，只要你已经掌握了Webpack的使用方法，那么它将成为你的最佳伙伴，因为它可以为你节省大量的时间，并且让你的代码变得更加整洁。

你可以告诉Webpack：“嘿，Webpack！帮我处理图片和字体！” 然后Webpack就会用它的魔力，将它们变成小小的Data URL或文件。你不会相信，Webpack的魔力是如此的强大，它甚至可以帮你处理模块依赖。

那么，如何使用Webpack呢？首先，你需要安装它（就像是奢侈品店要先开门才能买包）。安装很简单，只需要在终端中输入：；然后，创建一个配置文件（就像是奢侈品店的导览图，告诉你每样包包在哪里）。配置文件一般命名为，内容如下：。接下来，只需要在终端中输入打包命令：；最后，引用打包后的文件就可以了（背起新包包，开启一场冒险之旅）。

六、PWA和Web性能优化

在这个快节奏的数字化时代，越来越多的用户转向使用移动设备和Web应用程序。

PWA成为了一个重要的技术趋势，它的全称是“Progressive Web App”，翻译成中文就是“渐进式Web应用程序”。简单来说，PWA是一个既可以在浏览器上运行的Web应用程序，同时也可以像原生应用一样在离线时使用。它的最大优点就是可靠性，因为PWA可以像原生应用一样缓存数据和资源，这意味着它可以在离线时运行，而不会像普通的Web应用程序一样无法使用。

此外，Web性能优化也成为了开发者关注的重点。我们需要知道一个简单的事实，那就是用户喜欢快速的网站。如果你的网站速度太慢，那就会让你的用户感觉像一头正在沙漠里跑步的骆驼一样疲惫不堪，感到痛苦和沮丧，这会让他们不得不离开，去寻找新的绿洲。

所以，为了确保你的网站速度足够快，你需要采取一些优化措施。以下是一些可以提高Web应用性能的技巧：

1. 使用CDN（内容分发网络）：CDN是一组分布在世界各地的服务器，它们可以缓存你的网站内容，并将其分发到全球各地的用户。这可以大大加快你的网站加载速度，因为用户可以从离他们最近的服务器获取内容。

2. 压缩文件大小：压缩你的HTML、CSS和JavaScript文件可以减少它们的大小，从而加快它们的加载速度。你可以使用像Gzip这样的压缩算法来实现这一点。

3. 使用缓存：缓存是一种将网站数据存储的技术。例如浏览器缓存：在响应头中设置缓存策略来控制缓存时间；以及服务器端缓存：使用Memcached或Redis等缓存服务器，以减少响应时间。这样一来，当用户再次访问你的网站时，它们可以从缓存中加载数据，而不必重新下载，大大加快你的网站加载速度。

4. 减少HTTP请求：有一个叫做“夹心饼干法则”的说法。这个法则认为，在一次HTTP请求中，中间的响应部分应该像夹心饼干一样短，而请求和响应头和尾应该像饼干的两端一样长。这听起来很有趣，但其实它也是有道理的，因为请求和响应头和尾中包含的信息比较少，而响应中间部分则包含了网页的实际内容，因此应该尽可能地减少其大小。你可以通过将HTML和CSS以及JavaScript文件合并成一个文件，或者通过使用CSS Sprites将多个图像合并成一个文件来减少HTTP请求的数量。

5. 使用响应式图片：图片是网站加载速度最慢的资源之一。为了提高网站加载速度，你可以使用响应式图片，这些图片可以根据用户的设备屏幕大小来动态地调整大小。这样一来，用户只会下载他们所需的图像大小，而不是下载整个大图像。

6. 使用懒加载技术：懒加载是一种延迟加载技术，它可以延迟加载页面上的图像、视频和其他资源，直到它们真正需要时才出现。这可以减少页面的初始加载时间，因为只有当用户滚动到需要加载的部分时，它们才会被加载。

你知道吗，Google Chrome浏览器可以使用一个名为“Lighthouse”的工具来检查网站的PWA和性能方面的指标。但你可能不知道的是，这个工具还有一个有趣的功能，就是可以为你的网站生成一份“独家报告”，这样你就可以像读报纸一样轻松地查看网站的PWA和性能状况了。但是，要牢记的是，优化Web应用性能是一个不断发展的过程，需要持续监测和调整以确保最佳体验。

七、Web组件和跨平台框架

Web组件和跨平台框架是现代Web开发中的两个热门话题，它们就像是现代Web开发的两座巨大城堡，吸引着无数开发者前来探索和征服。

首先，我们来谈谈Web组件。Web组件是一种现代的Web开发技术，它允许开发者将Web应用程序分解成可重用的组件，这些组件可以在不同的Web应用程序中共享和重用。比如，你可以将一个搜索框组件用于多个Web页面，而不必每次都重新编写。

Web组件的好处不仅在于可重用性，还在于它们的灵活性。你可以根据需要自定义Web组件，为你的Web应用程序添加新的功能和样式。

但是，Web组件并不是“银弹”，它们在某些方面仍然有限制。比如，Web组件难以处理动态数据，因为它们是静态的。此外，Web组件也不是完美的跨平台解决方案，因为它们可能无法兼容不同的Web浏览器和设备。

这就引出了我们的下一个话题：跨平台框架。跨平台框架是一种可以在多个平台上运行的软件框架，包括Web、移动和桌面应用程序。它们允许开发者编写一次代码，然后在不同的平台上运行，无需进行任何额外的修改。

跨平台框架的好处显而易见：它们可以大大减少开发时间和开发成本。但是，跨平台框架并非完美无缺。它们可能会受到不同平台的限制，从而无法充分利用每个平台的功能和性能。此外，跨平台框架还可能会导致性能问题和代码质量问题。

现在，我们来看看如何将这两种技术结合起来。使用Web组件和跨平台框架可以让你搭建你的虚拟王国，充分利用Web组件的可重用性和灵活性，同时充分利用跨平台框架的跨平台能力和效率。

当然，这并不是说将Web组件和跨平台框架混合在一起就是万无一失的。你需要仔细考虑你的应用场景，确保使用这两种技术的方式是最优的。

比如，你可以使用Web组件来构建你的用户界面，然后使用跨平台框架来将Web应用程序转换为移动应用程序。这样，你就可以在多个平台上运行相同的代码，而且用户体验也会更加一致。

或者，你可以使用跨平台框架来编写你的应用程序逻辑，然后使用Web组件来定制你的用户界面。这样，你可以在不同的Web应用程序中重用你的用户界面，而且你的应用程序逻辑也可以在多个平台上运行。

再者，你也可以将这两种技术都使用在同一个应用程序中。这样，你可以充分利用Web组件的可重用性和灵活性，同时充分利用跨平台框架的跨平台能力和效率。只要你能合理地使用这些技术，就可以打造出更好的Web应用程序。

Web组件和跨平台框架都是非常有前途的技术，它们可以为现代Web开发带来很多好处，为我们带来更加灵活、高效和强大的Web开发工具和平台。无论是Web组件还是跨平台框架，它们都是我们构建虚拟王国的重要基石。

八、前端安全问题

在当今数字化时代，前端安全已成为互联网世界中的重要一环。不管是个人用户，还是企业机构，前端安全都需要被高度重视。尽管我们已经发展出了各种各样的安全技术和防御手段，但是前端安全问题仍然是一个不断增长的挑战。

8.1 XSS攻击：你的网站很容易被攻击

你听说过XSS攻击吗？这种攻击方式是通过篡改网页的HTML并在用户浏览器中注入恶意代码的一种攻击方式。这些恶意代码通常是JavaScript脚本，它们可以被用来窃取用户的敏感信息，如用户名、密码、银行账户信息等等。

如果你的网站存在XSS漏洞，那么恶意攻击者就可以在你的网站上注入一些不良代码，这些代码可能会窃取用户的登录凭证或者其他敏感信息。所以，尽管你的网站已经被SSL加密保护，你的用户仍然面临着被XSS攻击的风险。

如何防御XSS攻击呢？其实非常简单，你只需要在所有的输入框中过滤掉所有的HTML标签和JavaScript脚本即可。但是，如果你认为这么做会影响用户体验，那么你可以考虑使用HTML的特殊字符转义功能来替换这些标签和脚本。

8.2 CSRF攻击：请勿相信恶意链接

现在让我们来谈谈CSRF攻击。这种攻击方式是通过篡改用户的HTTP请求来伪造用户的身份，从而进行一些非法的操作。这种攻击方式通常是通过欺骗用户一个恶意链接来实现的。一旦用户了这个链接，攻击者就可以获得用户的凭证，然后模拟用户的请求，从而执行一些非法的操作。

假设，你的网站有一个删除账户的功能，攻击者就可以利用CSRF攻击来让用户误删除自己的账户。这听起来非常可怕，但是不要担心，我们可以通过一些简单的方法来防御这种攻击。

首先，我们可以在所有的表单提交中添加一个随机的Token值。这个Token值可以通过后台生成，然后在前端将其嵌入到表单中。当用户提交表单时，我们可以检查这个Token值是否匹配，如果不匹配，则拒绝这个请求。这样就可以简单的避免CSRF攻击了。

8.3 CSP策略：请勿允许不信任的资源

CSP策略是一种非常有用的前端安全措施。CSP策略可以帮助我们限制网页中可加载的资源，从而减少被攻击的风险。例如，我们可以限制只允许加载来自指定域名的JavaScript文件，这样就可以避免恶意代码的注入。

但是，如果你不小心将不信任的资源允许加载到你的网页中，那么你的网站就可能面临被攻击的风险。假设你的网站允许用户上传文件，并在网页中显示这些文件，如果你没有限制文件的类型和内容，那么攻击者就可能上传恶意文件，并在用户浏览器中注入恶意代码。

所以，如果你想保证你的网站的安全性，那么你应该始终谨慎地过滤用户上传的文件，只允许加载来自可信任来源的资源。

我们可以认识到，前端安全是一项非常重要的技术挑战。如果你是一位前端开发人员，那么应该始终将前端安全作为开发过程中的一个重要考虑因素。只有这样，我们才能够为用户提供安全可靠的Web服务。

九、前端工程师的多化技能

作为一名前端工程师，一定是个充满多化技能的大神。不仅仅要会写代码，还要会与设计师沟通，管理版本控制，解决兼容性，甚至还要有点艺术细胞。

1. 代码技能：前端工程师最基本的技能，也是最重要的技能。不仅需要掌握 HTML、CSS、JavaScript，还需要掌握一些前端框架和库，比如 React、Vue、Angular 等。当然，这些都不是问题，对于一名优秀的前端工程师来说，这只是小菜一碟。

2. 与设计师沟通：设计师们总是有各种奇怪的想法，然后她们会告诉你：“我要实现这个效果，你帮我写一下”。但是，很快会发现这个效果并不现实，于是你需要与设计师进行沟通，告诉她们这个效果无法实现。当然，你不能用技术术语来向她们解释，否则她们会摆出一副“我听不懂”的表情。所以，你需要用她们喜欢听的语言，比如“我理解你的设计需求，并深刻认识到其对于网站效果的重要性。不过，由于技术和浏览器的限制，我们需要寻找其他的可行方案来实现类似的效果，以保证网站的性能和可访问性，我会尽最大的努力提供最佳的解决方案。”

3. 管理版本控制：代码管理是一个很重要的问题，特别是当你和其他人合作的时候。你需要使用Git进行版本控制，这样才能确保代码的稳定性和可靠性。当然，你也需要了解一些Git的命令，比如 commit、push、pull 等等。不过，如果你不小心把代码弄挂了，那也不用担心，只要跟团队的其他成员说“我不小心把代码弄挂了”，他们就会告诉你怎么做了。

4. 解决兼容性：不同的浏览器之间有很多不兼容，而前端工程师需要解决这些问题。比如，IE浏览器总是出现各种奇怪的bug，但是你不能告诉用户：“你用的是IE，这不是我的问题”。相反，你需要找到问题的根源，然后解决它。这是一个非常重要的技能，因为它涉及到用户体验和网站的稳定性。

5. 有点艺术细胞：前端工程师不仅仅是一个代码的机器，还需要有一点艺术细胞。毕竟，好的界面设计是网站的关键之一。所以需要了解一些基本的设计原则，比如颜色搭配、排版等等。当然并不需要成为一个设计师，但是需要知道如何运用这些原则来改进网站的设计。

6. 学习新技能：前端工程师是一个不断学习的过程。每天都有新的技术和框架出现，并且要不断学习并掌握这些技能。但是，并不需要成为一个全栈工程师，只要掌握所需要的技能，然后专注于自己的领域即可。当然，这也意味着要学会如何筛选有用的信息，因为不可能学习完所有的技术和框架。

7. 解决问题：前端工程师是一个解决问题的岗位。当网站出现问题时，需要迅速找到问题的根源，并解决它。但是，也不一定要独自解决所有的问题，可以向同事寻求帮助，或者参加一些开发者社区来寻找解决方案。最终要记住的是，解决问题是前端工程师最重要的技能之一。

8. 与团队合作：前端工程师需要和设计师、后端工程师、测试人员等等进行合作，以确保网站的成功。在与团队合作中，要学会如何与不同的人合作，并且尽力避免出现冲突。

前端工程师需要掌握很多不同的技能，但这并不意味着要成为一个万能的人。相反，只需要专注于自己的领域在不断地技术学习过程中成长。

十、AI与前端技术结合

回顾过去，畅想未来，立足当下，来讲个故事吧。

在一个遥远的星球上，有一个叫做前端技术的孤独王国。这个王国的居民们都是非常优秀的程序员，他们用HTML、CSS和JavaScript这三种神奇的武器来构建网站，为用户带来无尽的愉悦。然而，这个王国有一个问题，那就是他们一直无法征服一个名为AI的神秘国度。

终于有一天，一个勇敢的前端战士——HTML骑士，决定向AI国度发起挑战。他带着两个小伙伴：CSS猎人和JavaScript法师，踏上了一段充满挑战的探险之旅。

他们沿着神秘的网络海洋航行，一路上遇到了各种令人捧腹大笑的趣事。先是在一个叫做布局的洲际，他们被一群叫做“浮动”的怪兽困扰，CSS猎人拔出了他的弹性盒子弓箭，一箭穿心，解决了怪兽。接下来，他们来到了一个充满奇特生物的动画之地，JavaScript法师用他的神奇魔法，让这些生物如同表演马戏团一般，给他们带来了一场场精彩绝伦的表演。

然后，他们终于来到了AI国度的边境。在那里，他们遇到了一个脾气古怪的巨人，他叫做机器学习。这个巨人用一种叫做数学的强大力量来支配着这片土地。HTML骑士认为，要征服这个国度，就必须挑战巨人，并将他的力量与前端技术融合。

于是，在他们与巨人大战三百回合后，JavaScript法师从中意外领悟了神奇魔法，召唤出一个叫做TensorFlow.js的强大法宝。这个法宝让前端技术也能够掌握机器学习的力量。HTML骑士和CSS猎人纷纷表示赞叹，他们觉得自己终于找到了一种将AI与前端技术结合的方法。

在这之后，他们三人一起用TensorFlow.js建立了一个名为“智能前端”的新城堡。这座城堡里，前端技术与AI融合得天衣无缝，为用户带来前所未有的体验。

城堡的大门上，HTML骑士精心设计了一个智能问答系统。这个系统可以回答用户关于前端技术的各种问题，让新手程序员们感叹不已。而这一切，都得益于TensorFlow.js和机器学习的神奇力量。

城堡的内部，CSS猎人则利用AI技术打造了一套全新的自适应布局。这套布局能够根据用户的喜好和设备自动调整，让每个访问者都能享受到最佳的浏览体验。他还研发了一种名为“智能配色”的神奇法术，能够根据用户的喜好自动调整网页的颜色搭配，让网站变得更加美观大方。

而在城堡的核心区域，JavaScript法师则运用AI技术开发了一系列令人惊叹的交互功能。比如，他创造了一种可以根据用户行为自动优化的推荐算法，将用户感兴趣的内容精准推送。此外，他还设计了一款智能聊天机器人，可以与用户进行即时互动，解答他们的疑问。

在“智能前端”城堡的建设过程中，他们三人不仅发挥出了各自的特长，还不断地学习AI技术，将其与前端技术相互融合。这让他们的作品充满了趣味与智慧，吸引了无数程序员和用户前来参观。

在这段充满挑战的探险之旅中，HTML骑士、CSS猎人和JavaScript法师用他们的智慧和勇气，成功地将AI技术引入前端领域。他们的故事传遍了整个网络世界，成为了程序员们争相传颂的佳话。

如今，前端技术和AI的结合已经成为了一种趋势，越来越多的开发者开始探索这个领域的无限可能。而在这个探索过程中，他们总是能从HTML骑士、CSS猎人和JavaScript法师的故事中汲取勇气与智慧，勇往直前，为未来的网络世界描绘出一个更加美好、充满创意和智慧的蓝图。

有人说，前端技术与AI的结合就像一场狂欢。程序员们欢笑着跳动，发挥着自己的想象力，创造出一个又一个令人叹为观止的作品。在这场狂欢中，每个人都是舞者，每个人都是艺术家，每个人都在为这个美丽的网络世界贡献着自己的力量。

如同那个遥远的星球上，那个欢呼雀跃的前端王国，如今我们所生活的这个网络世界也充满了欢声笑语。而在这片欢乐的土地上，那些勇敢的前端战士们正携手AI，共同书写着属于他们的传奇！

随着技术的不断发展，我们相信前端技术与AI的结合将会走得更远，创造出更多不可思议的奇迹。也许有一天，我们的网络世界将变得如同童话般美好，充满智慧的光辉。而在那个时候，我们将不禁想起那个勇敢的HTML骑士、CSS猎人和JavaScript法师，怀念他们当年那段充满挑战的探险之旅，为他们的勇气与智慧而感慨不已。

在探险的道路上，我们将一路欢笑并肩前行，勇敢地追求那个梦寐以求的未来。也许在某个不经意的瞬间，我们会发现，那个童话般的前端王国，其实就在我们心中，等待着我们去探索、去发现、去唤醒它，让它绽放出最耀眼的光芒。

后记

前端技术的演进从未停歇，仍然充满了机遇与挑战……

让我们一起期待下一个十年，见证前端技术的更多精彩！

作者：京东零售 王雷

1、Redis集群方案比较

• 哨兵模式

 

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般。

特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率。

• 高可用集群模式

 



redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群不需要sentinel哨兵也能完成节点移除和故障转移的功能。

需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单。

2、Redis高可用集群搭建

• redis集群搭建

redis集群需要至少三个master节点，我们这里搭建三个master节点，并且给每个master再搭建一个slave节点，总共6个redis节点，这里用三台机器部署6个redis实例，每台机器一主一从，搭建集群的步骤如下：

3、Java操作redis集群

借助redis的java客户端jedis可以操作以上集群，引用jedis版本的maven坐标如下：

Java编写访问redis集群的代码非常简单，如下所示：

集群的Spring Boot整合Redis连接代码见示例项目：redis-sentinel-cluster

1、引入相关依赖：

springboot项目核心配置：

访问代码：

4、Redis集群原理分析

Redis Cluster 将所有数据划分为 16384 个 slots(槽位)，每个节点负责其中一部分槽位。槽位的信息存储于每个节点中。

当 Redis Cluster 的客户端来连接集群时，它也会得到一份集群的槽位配置信息并将其缓存在客户端本地。这样当客户端要查找某个 key 时，可以直接定位到目标节点。同时因为槽位的信息可能会存在客户端与服务器不一致的情况，还需要纠正机制来实现槽位信息的校验调整。

• 槽位定位算法

Cluster 默认会对 key 值使用 crc16 算法进行 hash 得到一个整数值，然后用这个整数值对 16384 进行取模来得到具体槽位。

HASH_SLOT = CRC16(key) mod 16384

• 跳转重定位

当客户端向一个错误的节点发出了指令，该节点会发现指令的 key 所在的槽位并不归自己管理，这时它会向客户端发送一个特殊的跳转指令携带目标操作的节点地址，告诉客户端去连这个节点去获取数据。客户端收到指令后除了跳转到正确的节点上去操作，还会同步更新纠正本地的槽位映射表缓存，后续所有 key 将使用新的槽位映射表。

 

• Redis集群节点间的通信机制

redis cluster节点间采取gossip协议进行通信

维护集群的数据(集群节点信息，主从角色，节点数量，各节点共享的数据等)有两种方式：集中式和gossip

• 集中式

优点在于数据的更新和读取，时效性非常好，一旦数据出现变更立即就会更新到集中式的存储中，其他节点读取的时候立即就可以立即感知到；不足在于所有的数据的更新压力全部集中在一个地方，可能导致数据的存储压力。 很多中间件都会借助zookeeper集中式存储数据。

• gossip：

 



gossip协议包含多种消息，包括ping，pong，meet，fail等等。

1）meet：某个节点发送meet给新加入的节点，让新节点加入集群中，然后新节点就会开始与其他节点进行通信；

2）ping：每个节点都会频繁给其他节点发送ping，其中包含自己的状态还有自己维护的集群数据，互相通过ping交换数据(类似自己感知到的集群节点增加和移除，hash slot信息等)；

3）pong: 对ping和meet消息的返回，包含自己的状态和其他信息，也可以用于信息广播和更新；

4）fail: 某个节点判断另一个节点fail之后，就发送fail给其他节点，通知其他节点，指定的节点宕机了。

gossip协议的优点在于数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力；缺点在于数据更新有延时可能导致集群的一些操作会有一些滞后。

gossip通信的10000端口

每个节点都有一个专门用于节点间gossip通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口。 每个节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几点接收到ping消息之后返回pong消息。

• 网络抖动

真实世界的机房网络往往并不是风平浪静的，它们经常会发生各种各样的小问题。比如网络抖动就是非常常见的一种现象，突然之间部分连接变得不可访问，然后很快又恢复正常。

为解决这种问题，Redis Cluster 提供了一种选项cluster-node-timeout，表示当某个节点持续 timeout 的时间失联时，才可以认定该节点出现故障，需要进行主从切换。如果没有这个选项，网络抖动会导致主从频繁切换 (数据的重新复制)。

Redis集群选举原理分析

当slave发现自己的master变为FAIL状态时，便尝试进行Failover，以期成为新的master。由于挂掉的master可能会有多个slave，从而存在多个slave竞争成为master节点的过程， 其过程如下：

1）slave发现自己的master变为FAIL

2）将自己记录的集群currentEpoch加1，并广播FAILOVER_AUTH_REQUEST 信息

3）其他节点收到该信息，只有master响应，判断请求者的合法性，并发送FAILOVER_AUTH_ACK，对每一个epoch只发送一次ack

4）尝试failover的slave收集master返回的FAILOVER_AUTH_ACK

5）slave收到超过半数master的ack后变成新Master(这里解释了集群为什么至少需要三个主节点，如果只有两个，当其中一个挂了，只剩一个主节点是不能选举成功的)

6）slave广播Pong消息通知其他集群节点。

从节点并不是在主节点一进入 FAIL 状态就马上尝试发起选举，而是有一定延迟，一定的延迟确保我们等待FAIL状态在集群中传播，slave如果立即尝试选举，其它masters或许尚未意识到FAIL状态，可能会拒绝投票

延迟计算公式：

DELAY = 500ms + random(0 ~ 500ms) + SLAVE_RANK * 1000ms

SLAVE_RANK表示此slave已经从master复制数据的总量的rank。Rank越小代表已复制的数据越新。这种方式下，持有最新数据的slave将会首先发起选举（理论上）。

集群脑裂数据丢失问题

redis集群没有过半机制会有脑裂问题，网络分区导致脑裂后多个主节点对外提供写服务，一旦网络分区恢复，会将其中一个主节点变为从节点，这时会有大量数据丢失。

规避方法可以在redis配置里加上参数(这种方法不可能百分百避免数据丢失，参考集群leader选举机制)：

*注意：这个配置在一定程度上会影响集群的可用性，比如slave要是少于1个，这个集群就算leader正常也不能提供服务了，需要具体场景权衡选择。

集群是否完整才能对外提供服务

当redis.conf的配置
cluster-require-full-coverage为no时，表示当负责一个插槽的主库下线且没有相应的从库进行故障恢复时，集群仍然可用，如果为yes则集群不可用。

Redis集群为什么至少需要三个master节点，并且推荐节点数为奇数？

因为新master的选举需要大于半数的集群master节点同意才能选举成功，如果只有两个master节点，当其中一个挂了，是达不到选举新master的条件的。

奇数个master节点可以在满足选举该条件的基础上节省一个节点，比如三个master节点和四个master节点的集群相比，大家如果都挂了一个master节点都能选举新master节点，如果都挂了两个master节点都没法选举新master节点了，所以奇数的master节点更多的是从节省机器资源角度出发说的。

Redis集群对批量操作命令的支持

对于类似mset，mget这样的多个key的原生批量操作命令，redis集群只支持所有key落在同一slot的情况，如果有多个key一定要用mset命令在redis集群上操作，则可以在key的前面加上{XX}，这样参数数据分片hash计算的只会是大括号里的值，这样能确保不同的key能落到同一slot里去，示例如下：

假设name和age计算的hash slot值不一样，但是这条命令在集群下执行，redis只会用大括号里的 user1 做hash slot计算，所以算出来的slot值肯定相同，最后都能落在同一slot。

哨兵leader选举流程

当一个master服务器被某sentinel视为下线状态后，该sentinel会与其他sentinel协商选出sentinel的leader进行故障转移工作。每个发现master服务器进入下线的sentinel都可以要求其他sentinel选自己为sentinel的leader，选举是先到先得。同时每个sentinel每次选举都会自增配置纪(选举周期)，每个纪中只会选择一个sentinel的leader。如果所有超过一半的sentinel选举某sentinel作为leader。之后该sentinel进行故障转移操作，从存活的slave中选举出新的master，这个选举过程跟集群的master选举很类似。

哨兵集群只有一个哨兵节点，redis的主从也能正常运行以及选举master，如果master挂了，那唯一的那个哨兵节点就是哨兵leader了，可以正常选举新master。

不过为了高可用一般都推荐至少部署三个哨兵节点。为什么推荐奇数个哨兵节点原理跟集群奇数个master节点类似。

作者：京东科技 高飞

前言

本文旨在通过部署微前端项目的实践过程中沉淀出一套部署方案，针对项目分别部署在不同的服务器上的场景，就一些重点步骤、碰到的问题做了一些总结。

部署顺序

因为线上部署主应用时需要用到子应用的线上可访问地址，因此部署顺序应该是先部署子应用，保证子应用能够线上可访问后，再将子应用的线上可访问地址配置到主应用，最后再将主应用部署到线上环境。

部署分支

线上环境部署统一用master分支的代码

应用构建打包

主应用构建打包

主应用 csd-tech-main-app基于 ant-design-pro，需要在config目录中配置微前端项目的访问地址。

在config目录下配置config.test.ts用于测试环境的打包配置，生产环境打包配置放在在config.prod.ts中。由于本次部署是在本地机器测试部署，因此子应用访问地址都用localhost，如果部署到测试环境，或者生产环境，可以换成对应的访问地址。

测试环境打包配置：

生产环境打包配置：

然后，我们需要在微应用注册信息中，将我们加载微应用的地址换成我们配置的地址，代码实现如下：

最后，我们在 package.json 中，通过不同的命令区分不同环境，代码实现如下：

在配置完成后，我们在命令行运行如下命令，将主应用构建打包：

在构建打包完成后，我们将构建好的 dist 目录移动到nginx配置根目录下的 html 目录下，并重命名为 csd-tech-main-app，目录结构如下（见下图）

 

到这里，我们的主应用就构建打包好了，接下来我们介绍各个微应用构建打包过程。

调度系统(dlink)微应用构建打包

进入项目目录，直接使用打包命令构建打包即可，在命令行运行：

在构建打包完成后，我们将构建好的 dist 目录移动到nginx配置目录下的 html 目录下，并重命名为 datalink ，目录结构如下（见下图）

 

数据迁移系统（datax）微应用构建打包

进入项目目录，直接使用打包命令构建打包即可，在命令行运行：

在构建打包完成后，我们将构建好的 dist 目录移动到nginx配置目录下的 html 目录下，并重命名名为datax ，目录结构如下（见下图）

 

标签系统微应用构建打包

进入项目目录，直接使用打包命令构建打包即可，在命令行运行：

在构建打包完成后，我们将构建好的 dist 目录移动到nginx配置目录下的 html 目录下，并重命名名为label-system ，目录结构如下（见下图）

 

Nginx 服务器部署方案

在将我们的主应用和微应用全部打包完成后，我们将介绍如何使用 Nginx 完成微前端架构的部署。

Nginx 部署方案是可以作为生产方案使用的。

配置时有三点注意事项：

•搭建nginx服务之前，保证所用到的端口是空闲

•子应用和主应用的 nginx 配置基本上是一致的，唯一不同的是子应用需要配置允许跨域访问。这是因为我们的微前端架构需要通过 ajax 请求子应用资源，所以需要配置跨域，通过 同源策略 的限制。

•子应用和主应用所用到接口地址都需要在 nginx 配置代理

本地测试nginx服务配置如下：

在配置完成后，我们需要重启一下 nginx 服务。

输入nginx启动命令启动nginx

在浏览器中访问主应用测试地址 localhost:8000 ，登录后如下图：

 



在浏览器中访问datalink子应用测试地址 localhost:8888 ，登录后如下图：

 


在浏览器中访问datax子应用测试地址 localhost:9528 , 登录后如下图：

 


在浏览器中访问标签系统子应用测试地址 localhost:8080 , 登录后如下图：

 


至此，nginx 服务部署大功告成！

扩展

如果需要把服务部署到真实服务器，只需要把所有的 localhost 都换成真实注册的域名即可，其他配置都可以复用！

这周有个让人眼前一亮的图像识别模型 segment-anything，它能精细地框出所有可见物体，它标记出的物体边界线清晰可见。如此出色的模型，自然获得了不少人的赞赏，开源没几天，就拿下了 18k+ 的 star，而上周开源不到 48 小时获得 35k+ star 的推特推荐算法，本周也成功突破 50k+ 关卡。

依旧是 AI 热度不减的一周，本周的 AI 专场收录了一个离线生图工具，以及一个自托管 AI 编程助手。此外，还有 Meta 开源出来的重构版构建系统 buck2 也是大受欢迎，还有随着各类 AI 工具火起来的向量数据库，weaviate 也小小地展露了下头角。

还有比较少见的工具类应用，一款极简的输入法 rime-ice 也值得一看。

以下内容摘录自微博@HelloGitHub 的 GitHub Trending 及 Hacker News 热帖（简称 HN 热帖），选项标准： | | ，根据项目 release 时间分类，发布时间不超过 14 day 的项目会标注 ，无该标志则说明项目 release 超过半月。由于本文篇幅有限，还有部分项目未能在本文展示，望周知 🌝

• 本文目录
  • 1. 本周特推
    • 1.1 AI 专场
    • 1.2 Meta 开源构建系统：buck2
  • 2. GitHub Trending 周榜
    • 2.1 嵌入式数据库：chroma
    • 2.2 万物皆可分：segment-anything
    • 2.3 流处理：arroyo
    • 2.4 极简输入法：rime-ice
    • 2.5 向量数据库：weaviate
  • 3. HelloGitHub 热评
    • 3.1 GIF 录屏工具：ScreenToGif
    • 3.2 Nginx 可视化管理平台：nginx-proxy-manager
  • 4. 往期回顾

1. 本周特推

1.1 AI 专场

在这波 AI 热度消退之前，热点趋势的特推部分会增加一个模块来分享新的 AI 应用。

macOS 跑 SD：MochiDiffusion

主语言：Swift

MochiDiffusion 内置 Apple 的 Core ML Stable Diffusion 框架，以实现在搭载 Apple 芯片上用极低的内存占用发挥出模型最优性能。部分特性：

• 可离线生图
• 高性能，极低的内存占用
• 图转图，Image2Image
• 自定义 Stable Diffusion Core ML 模型
• 无需担心损坏模型

GitHub 地址→https://github.com/godly-devotion/MochiDiffusion

自托管 AI 编程助手：tabby

主语言：Python、TypeScript

自托管的 AI 编程助手，可作为 Copilot 的替代品。特性：

• 无需数据库和云服务；
• 具有可视化、配置模型和 MLOps 的 Web 界面；
• 接入 OpenAPI；
• 消费级别的 GPU 支持（用不同方法优化的 FP-16 权重加载）

GitHub 地址→https://github.com/TabbyML/tabby

1.2 Meta 开源构建系统：buck2

主语言：Rust

Meta 开源的大规模构建系统 buck2 继承于 buck1，但是不同于 buck1 采用 Java 编写，buck2 由 Rust 编写而成。重构 buck1 的想法源自想要提供更快速、更高效的构建服务，buck2 有以下特性：

• 解耦特定语言规则，buck2 的核心构建系统没有任何特定的语言规则，这意味着它有更好的可扩展性。buck2 核心部分用 Rust 编写，语言规则部分（例如：如何构建 C++）由 Starklark 编写；
• 构建系统由单一增量依赖图提供支持，由此消减多类 bug 并增加并发性；
• 规则 API 的设计主要为提供先进的性能特性，以及动态依赖特征；
• 集成远程执行，能在远程机器执行操作，它采用了同 Bazel 一样的 API，并已经用 Buildbarn 和 EngFlow 进行远程执行测试；
• 集成虚拟文件系统，不用整仓检测，按需获取文件即可；

GitHub 地址→https://github.com/facebook/buck2

2. GitHub Trending 周榜

2.1 嵌入式数据库：chroma

本周 star 增长数：1,200+，主语言：Python、TypeScript

Chroma 是一个用于 Python / JavaScript LLM 应用程序的嵌入式数据库，它具有内存快速访问的优势。它只有 4 个核心函数：

GitHub 地址→https://github.com/chroma-core/chroma

2.2 万物皆可分：segment-anything

本周 star 增长数：18,000+，主语言：Jupyter Notebook

这个代码库提供了使用 SegmentAnything 模型（SAM）进行推理的代码，SAM 是一种输入诸如点、框等 prompt 生成高质量目标 mask 的模型，它有非常出彩的标记效果。btw，项目开源不到一周已经有 18k+ star。

GitHub 地址→https://github.com/facebookresearch/segment-anything

2.3 流处理：arroyo

本周 star 增长数：700+，主语言：Rust、TypeScript

arroyo 是一个 Rust 编写的分布式流处理引擎，旨在高效地对流数据进行状态计算。与传统的批处理不同，流处理引擎可以处理有界和无界数据源，一旦结果可用就立即输出。

GitHub 地址→https://github.com/ArroyoSystems/arroyo

2.4 极简输入法：rime-ice

本周 star 增长数 1,850+，主语言：Go、Lua

雾凇拼音一个极简风的输入法，支持简体、全拼、双拼。值得一提的事，作者自己维护了一个词库：

• 字表
• 基础词库
• 搜狗流行词
• 扩展词库，小词库
• 扩展词库，大词库

GitHub 地址→https://github.com/iDvel/rime-ice

2.5 向量数据库：weaviate

本周 star 增长数：500+，主语言：Go

Weaviate 是一个开源的向量数据库，可以存储对象和向量，允许将向量搜索与结构化过滤相结合，并具有云原生数据库的容错性和可扩展性，可通过 GraphQL、REST 和各种语言客户端进行访问。

GitHub 地址→https://github.com/weaviate/weaviate

3. HelloGitHub 热评

在这个章节，我们将会分享下本周 HelloGitHub 网站上的热评项目，HG 开源项目评价体系刚上线不久，期待你的评价 :D

3.1 GIF 录屏工具：ScreenToGif

主语言：C#

一款 Windows 上的免费 GIF 录屏工具，易安装、好上手，支持录制指定区域画面，且可以将视频导出为 gif 等文件格式。

HG 评价地址→https://hellogithub.com/repository/b49e4c9dd1834dc1b9f3352c89ef0239

3.2 Nginx 可视化管理平台：nginx-proxy-manager

主语言：JavaScript

它开箱即用，支持 Docker 一键部署，可以让用户通过 Web 界面在线配置、管理 Nginx 服务，支持转发、重定向、SSL 证书、高级配置等功能。

HG 评价地址→https://hellogithub.com/repository/43d04968e8ed4bdfae28023b1c

4. 往期回顾

往期回顾：

• Python 霸榜的一周，又有什么新 AI 力作呢？「GitHub 热点速览」
• 开源不到 48 小时获 35k star 的推荐算法「GitHub 热点速览」

以上为 2023 年第 14 个工作周的 GitHub Trending 🎉如果你 Pick 其他好玩、实用的 GitHub 项目，来 HelloGitHub 和大家一起分享下哟 🌝

技术原理

关于技术实现，用到的材料主要有XR806开发板、两个9g的舵机，以及一个红外光传感器。

工作机制非常简单，如图所示：

上电后舵机复位到初始状态，任何开始工作，由一号舵机把待分类的棋子推移到检测区域，由红外传感器判断棋子的颜色，白色返回值为1，黑色则为0。

硬件模型制作

这一部分看似工作量大，但其实是参考了网上一些开源的例程，只不过加以了尺寸改动。

实现方法可以用3d打印或者激光切割亚克力，我选择了后者因为时间相对简短。使用的建模软件为Solidworks2019，亚克力板厚度后3mm，画好零件后，搭建好装配体确认尺寸无误后转为dxf格式即可用CNC机床切割。（我是用了学校的CNC，网上切也很便宜哈）

电路部分

使用的开发板为XR806，一款iot产品开发板，他最大的特点就是适配的轻鸿蒙，使用起来能有不错的体验。

需要驱动的设备就是两个舵机及一个红外传感器。

舵机就是一种位置伺服的驱动器，适用于那些需要角度不断变化并可以保持的控制系统。其工作原理是：控制信号由接收机的通道进入信号调制芯片，获得直流偏置电压。它内部有一个基准电路，产生周期为20ms，宽度为1.5ms的基准信号，将获得的直流偏置电压与电位器的电压比较，获得电压差输出。最后，电压差的正负输出到电机驱动芯片决定电机的正反转。当电机转速一定时，通过级联减速齿轮带动电位器旋转，使得电压差为0，电机停止转动。

以180度角度伺服为例，那么对应的控制关系是这样的：

0.5ms————–0度；

1.0ms————45度；

1.5ms————90度；

2.0ms———–135度；

2.5ms———–180度；

拆开看看：

减速齿轮

驱动电路

因为片子上的字眼实在太小，令人“望眼欲穿”，本来还想查查有没有技术文档研究一下，只能放弃先了。刚好鸿蒙也适配了pwm的接口驱动xr806，所以我们只要修改freq频率和duty占空比两个选项如下即可。

关于其他基础操作姿势可以参考我之前的一篇呼吸灯的demo帖子。还有一点值得一提的是关于这种舵机的输入信号口我是用806上的接口直接驱动的，并没有再拉高，内部是否需要或者有没有额外的驱动由于没有舵机内部电路的原理图也暂时无从得知，但总感觉在调节duty占空这一参数时舵机时而会不听使唤（占空比调制不准确），希望有大佬指点。

红外传感器原理则相对简单，一个红外发射管和一个红外接收管。模块通电后红外发射管向前方不断发射一定频率的红外线，

通过板载了一个电压比较器LM393

比较输出和输入的信号做出相应反馈，体现到我手里这块小板子上就是接收到红外信号为1，没有接收到（遇到黑色物体）则为0。所以读取判断值的代码相对简单：

整体代码部分

openHarmony用的是gn和ninja编译，由很多种上手学习方式，如果说gn对标的是gcc脚本构建生成器，ninja就对应的是makefile构建系统文档了。

BUILD.gn

main.c

最后在编译选项中加上即可

总结
到此基本功能是实现了，但有很多缺陷如我没有直观地体现出来分类后各种棋子的数量，也并没有给他加上控制开始和停止的操作。（没有一个对是否仍有棋子未被分类的判断机制）这些后续可以通过增加显示屏、替换红外传感器为压感贴片或者使用摄像头去学习判等等···最遗憾的是这个小demo暂时还没有发挥出XR806及鸿蒙的一些特征，如联网、连蓝牙。仅仅是个突发奇想的点子，希望能起到抛砖引玉的作用。后面我也会继续尝试给他加上其他功能。

再贴上一些前置学习内容：
官方文档：https://xr806.docs.aw-ol.com/

XR806开发板引脚功能表：https://bbs.aw-ol.com/topic/496/资料释放-xr806鸿蒙开发板引脚功能表

SDK获取到编译烧录：https://bbs.aw-ol.com/topic/499/xr806鸿蒙开发实战1-实操下载xr806鸿蒙代码并编译烧写

鸿蒙的外设接口：文件接口的头文件在：

源码在：

带有iot字样的接口就是鸿蒙的接口。

端口复用：

可以看到关于pwm的相关端口配置

项目中所用到的引脚：

一号舵机信号线———PA20

二号舵机信号线———PA19

红外传感信号线———PA13

用面包板引出开发板上的电源跟地供外设共用。

当下，酝酿能量的超级边缘。

最近，我们在谈视频化狂飙、谈AIGC颠覆、谈算力动能不足，很少谈及边缘。但“边缘”恰恰与这一切相关，且越发密不可分，它是未来技术发展的极大影响因子。

“到2025年，超过70%的组织将为其⾄少⼀个边缘计算系统，部署超⼤规模云边缘解决⽅案，并会结合其云部署。这比例远⾼于2022年的不到15%。”

这是Gartner在最近发布的 Competitive Landscape : Hyperscale Edge Solution Providers 报告中，给出的大胆又直接的判断。

Gartner视角中的“边缘”价值

“边缘是物和⼈与⽹络数字世界连接的物理位置，它是数字化转型，以及⼈、物和企业之间新交互的关键推动因素。”Gartner的描述，极度契合当下的边缘之力。

由边缘发展而来的边缘计算，正在呈现快速发展之势，它满⾜了对靠近边缘处理数据的⽇益增⻓的需求。它还通过解决延迟、带宽、⾃主性和隐私要求，来补充数字业务⽤例的云计算，这就顺势揭开了“边缘”的意义和能力。

提到云计算，固有印象一定是中心云。而边缘计算和中心云计算是相辅相成的，非相互竞争或排斥。下图显示，两种计算可以通过不同的⽅式解决不同的需求，从⽽创造新的价值。

中心云和边缘的关系

从中心到边缘，与Gartner所观察的一致，我们发现：

l “边缘”是趋于简单的解决路径

超⼤规模边缘正在成为在当今IT现代化和数字计划中，实现边缘计算以及解决数据主权需求的越来越简单的⽅法，因为用户在当今组织中的分布和普及程度越来越⾼。

l “边缘”是公共云的最强助力

公共云功能得到当今超⼤规模边缘的补充，许多情况下，它在利⽤云到边缘模型的同时，也提供与公共云区域相同的功能。

在此之上，涉及一个概念，分布式云。

分布式云是⼀种新兴技术趋势，推动云外⽅法。分布式云满⾜了客户让云计算资源更接近数据和业务活动发⽣的物理位置的需求，同时保留了公共云的集中管理能⼒。

分布式云连续体

从中心云到分布式云，从云计算到边缘计算，成就了边缘云的存在，可以说是一种最具亲和力的云计算存在形态，而其酝酿的价值一定在超大规模之上来发挥。

正如Gartner所述，“5G为通信服务提供商提供了⽀持新的边缘计算⽤例的机会，而超⼤规模云提供商正在竞相成为电信边缘基础设施的领先者。”

6家“全球超大规模边缘供应商”

Gartner提到，“随着超级边缘（也称为超⼤规模边缘）变得⼴泛可⽤，它们将在短期内与单个超⼤规模企业及其特许经营权相关联。这将产⽣对‘多重超⼤规模’边缘架构和采用模型的需求，类似于在云世界中的多云采⽤模型。”

在5G代开的连接通道之下，更打开了一种可以称之为“超级边缘”的边缘解决方案和产品新世界。

与传统边缘不同，超级边缘构建在超⼤规模云提供商提供的平台上，作为其分布式云解决⽅案的⼀部分。5G的⾼速、低延迟连接将许多功能卸载到这些超级边缘，⽽不是依赖集中式云数据中⼼来处理某些超级计算和分布式⼯作负载，这便解决了传统边缘一直面临的延时挑战，尤其可以应对云游戏和高性能计算的应用场景。

供应商使⽤不同的⽅法来开发新产品以满⾜这些新的边缘计算要求。然⽽，所有超⼤规模云提供商都基于相同的原则开发他们的产品，Gartner称之为“从云到边缘”的⽅法。

通过从云到边缘的⽅法，超⼤规模云提供商将公共云架构分发到边缘，从⽽实现中心和边缘之间的⼀致性。

从云端到边缘的方法

此次最新报告中，从全球范围内，Gartner指出了6家最具代表性的“全球超大规模边缘供应商”，分别为：阿里云、AWS、谷歌云、IBM、微软天青、甲骨文，这6家各具声色，为边缘云赛道带来独特价值。

报告中指出，阿里云的云内容分发⽹络 (CDN) 业务，提供在阿⾥云的云边缘节点服务 (ENS) 上运⾏的标准边缘计算服务。带有CDN的ENS，提供了⽐以前的解决⽅案更⾼的收益，以及横向服务扩展、运营和维护以及为客户提供的按需付费选项。

正如Gartner所描述，阿里云基于CDN节点构建的全球化边缘基础设施，通过500+节点结合算网融合技术，实现全球覆盖，聚焦在音视频、云游戏、云渲染、边缘组网、云网融合五类场景化解决方案。未来，更多的全球节点还会转变为边缘计算（ENS）模式，带来更大的覆盖与价值。

与此同时，Gartner也指出，AWS的边缘产品组合通过多种选项部署到边缘，为客户提供⼀种混合体验；Google分布式云(GDC)可以跨多个位置运⾏，包括⾕歌的⽹络边缘、运营商边缘、客户边缘和客户数据中⼼；IBM Cloud Satellite是IBM的出云解决⽅案，满⾜⾏业对以软件为中⼼的未来需求，以越来越灵活的⽅式将云服务扩展到不同的环境；微软⽀持多种边缘集成技术，包括连接、管理、安全和云原⽣开发，并给予边缘高度多样化的需求，且特别关注垂直合作伙伴关系的建立；Oracle构建了OCI分布式云，并提供⼀套包含五个分布式云产品的套件，向全球客户提供其分布式云服务。

从产品、功能的成熟度、市场的吸引力、市场的独特主张，Gartner提出的这6大全球超大规模边缘供应商，着力不同，呈现强劲的发展势头。

在全球释放“超级边缘”的能量

在全球构建超级边缘之力，绝非一件简单的事。

阿里云实现了国内31个省的全面覆盖，也就是说，用户在中国大陆的这些区域内都能获得充沛的算力支撑。在云计算基础设施服务方面，阿里云边缘云基于统一的飞天底座，提供一云多芯、一云多态的云计算架构，从中心向边缘辐射，让算力无限延伸。

作为中国最大、技术领先、全球覆盖的边缘云计算平台，阿里云边缘云在海外部署了60多个节点，覆盖海外30多个国家，以亚太区域为核心，在欧美、中东非等区域均能提供算力支持。

在边缘节点算力建设上，阿里云在全球提供500多个强有力的全节点，具备边缘云多态计算、融合存储、融合网络等所有云能力，通过合计170万核的通用算力CPU核，和400P FLOPS的异构算力核，以满足更多边缘创新场景的算力刚需。

伴随全球业务发展，阿里云先后在韩国、泰国、德国、印尼、菲律宾和沙特新增了七座数据中心，面向广大的海外用户提供云服务。同时，边缘云小型轻量和快速交付的特性，使得其相较中心云而言，部署更为灵活、分布更为广泛。

在网络传输层，就近用户侧部署边缘云，可有利于优化异地运营商的网络接入；通过专属网络连接边缘云与中心云，则有利于为上层业务开展屏蔽边缘云与中心云之间的复杂网络环境。

在业务应用层，将中心化的云服务延展为云边协同的服务，不仅可以通过边缘算力和存储满足数据本地贮存的需求，还可以通过应用本地下沉、边缘就近访问等技术手段提升业务体验，对传统中心云的服务形成恰到好处的补充。

实践数据显示，在全球互联网用户增长最快、网络等基建水平相对落后的新兴市场国家，采用边缘云就近用户提供服务，可以将异地用户的业务访问时延缩短50%以上，从而有力应对“长距离传输”和“最后一公里接入”为业务开展带来的挑战。

随着互联网出海进度的加快，中国企业席卷全球的脚步由国内延伸至欧美、东南亚、印度，进而扩展至更广阔的拉美、中东和非洲市场。在视频直播、游戏、在线教育等领域，国内出海企业已日渐占据了海外市场的半壁江山。

得益于国内边缘云的商业化积累和与出海企业的长期深入合作，阿里云率先将边缘云的场景化服务能力由国内延伸至海外，致力于在更广阔的地域为出海企业提供与国内一致的技术支持和服务体验，助力企业业务全球版图的扩张。

写在最后

在全球，阿里云边缘云构建了泛在融合的算力网络，打造“一点接入、即取即用”的算力服务，为新兴企业、新兴场景注入真正落地的动力之源。

如今，全球都沸腾在AIGC的风潮里，而“边缘”也许会成为新内容形态的动能中心，它利用算网融合的能力，在边缘端和云边协同机制下，解决更复杂的渲染和AI计算，以更自如的算力，让AIGC更自如地普惠。

不仅如此，边缘算力所拥有的低时延、安全、隐私等优势，更符合对AI创作所有权和隐私权之需。而“边缘”对AIGC时代的助攻，也只是我们能预见的冰山一角。

可以确定的是，用户群日益分散，需求日新月异，欲望的极限不断被打破，在每个边缘端不断被满足，这一切都为超⼤规模边缘提供商创造⼀系列的机会。

最后，把视线抬高，边缘云更像是新兴技术下的影响雷达，众多颠覆性技术的蔓延之势，总离不开边缘的存在。

概述

之前分享了如何通过DAS和公网连接GaussDB，本篇介绍第三种通过内网连接GaussDB。

1.1 实验介绍

本实验主要描述如何通过内网从另一台弹性云服务器ECS上连接到GaussDB实例。
掌握使用内网来连接GaussDB数据库实例。

1.2 购买GaussDB数据库（可选）

说明：如果已经购买好了GaussDB数据库可以跳过此章节，直接进入下一章节，如果没有购买好请参考 GaussDB 数据库实验环境搭建指导进行购买。

1.3 购买弹性云服务器 ECS

1.3.1 购买ECS服务器

步骤 1登录华为云官网。
登录https://www.huaweicloud.com/，进入华为云官网，输入账号密码，登录。
步骤 2进入控制台，单击服务列表，选择弹性云服务器ECS。

步骤 3进入服务器购买界面。

步骤 4配置服务器。
在左上角选择数据库（重要 ）后，选择按需计费-华北北京四，CPU架构选择x86计算，规格选择通用计算增强型 | sn3.medium.2 | 1vCPUs | 2GiB，镜像为CentOS 8.0 64bit，单击下一步 网络配置。

在网络配置界面，网络选择默认网络、安全组选择默认安全组，公网带宽选择按流量计费，然后单击下一步 高级配置。

在高级配置界面，只要设置密码，其余默认即可，然后单击下一步 确认配置。

在确认配置界面，勾选我已经阅读并同意《镜像免责声明》，然后单击 立即购买。注意，购买后即进行实际按时计费。

提交完成后，回到返回到服务器列表界面。

服务器创建中。

等待几分钟后，服务器创建成功。注意已启动计费。

1.3.2 安装客户端并连接数据库

步骤 1以root用户远程登录服务器并创建“/tmp/tools”目录。可以使用华为云自带的或者连接工具进行登录。

这里需要注意下，GaussDB的公网IP默认禁ping，因此IP可能是ping不通的，但是不影响通过公网Data Studio或者私网服务器工具putty/xshell登录。
创建“/tmp/tools”目录：

步骤 2获取软件安装包，并解压上传安装文件。
下载地址为：https://dbs-download.obs.cn-north-1.myhuaweicloud.com/GaussDB/09/GaussDB_opengauss_client_tools.zip
在本地（例如D:/download）下载ZIP文件后进行解压缩。
由于购买的ecs为CentOS操作系统，这个操作系统基于X86，所以进入Euler2.5_X86_64文件夹，显示如下：

使用WinSCP工具连接弹性云服务器，主机名为弹性公网IP，用户名为root，密码为购买弹性云服务器时自定义的密码：

切换到对应文件夹:
左边：D:DownloadGaussDB_opengauss_client_toolsEuler2.5_X86_64
右边：/tmp/tools

将文件“GaussDB-Kernel-V500R001C10-EULER-64bit-gsql.tar.gz”上传到申请的弹性云服务器“/tmp/tools”路径下。
选中文件GaussDB-Kernel-V500R001C10-EULER-64bit-gsql.tar.gz，单击上传或者直接拖过去：

上传成功：

重新连接弹性云服务器，切换到“/tmp/tools”目录，解压文件。

步骤 3设置环境变量。
打开“~/.bashrc”文件。

按下i键进入INSERT模式，在其中输入如下内容后，按下Esc后输入“:wq!”命令保存并退出。

使环境变量配置生效。

步骤 4内网连接数据库。
从ECS服务器上连接到如下GaussDB数据库。
先查看GaussDB数据库的IP地址，内网地址可直接获取：

跨区的也可以使用弹性公网IP。

然后在ECS服务器执行如下命令进行连接，postgres为需要连接的数据库名称，IP的话分布式为CN的IP地址，主备版为主DN的IP地址，root为登录数据库的用户名，8000为CN的端口号。

输入数据库root用户密码，进行成功登录

数据库使用

如果ESC服务器不再使用了，记得把ESC服务器资源及时清除，避免持续计费。
内网连接GaussDB实验结束。

前言

大家好！我是 Rainbond 创始人刘凡，今年是 Rainbond 创立和开源的第七年，这个过程中我见证了Docker、K8s、云原生等技术的演进，Rainbond 也进化成为一体化的云原生管理平台，基于这么多年的产品研发及行业沉淀，我来分享我们对云原生的一些思考，以及云原生技术为企业数字化转型带来的新模式。

个人数字化三大驱动力

谈到企业数字化，首先我们来回顾一下个人数字化的历程和驱动力，通过分析和总结个人数字化，对我们理解企业数字化有借鉴意义。众所周知个人数字化最大的驱动力是移动互联网。移动互联网定义了技术实现和用户体验，催生了大量应用场景，为我们的生活带来了极大的便利。下面我们详细解析一下移动互联网的驱动力。

个人数字化三个最关键的驱动力，分别是易用性、生态建设及服务化。

• 易用性：Android、iPhone手机等终端产品，可以做到较强易用性，小孩都能顺畅使用，是由其触摸屏及苹果定义的Iphone交互体验所决定的，易用性让移动终端的用户快速增长，从而为个人数字化提供了坚实的用户基础。
• 生态建设：iPhone建立了App Store（应用商店）模式，通过应用生态，更多厂商可以为移动设备开发应用，产生了大量可以使用的应用，这些应用能覆盖到个人数字化生活的方方面面，生态建设为个人数字化提供了更多应用。
• 服务化：软件本身是没有价值的，只有把软件变成服务，才能给用户带来价值，而服务订阅是可持续发展的商业模式，它让个人数字化能够良性发展。

云原生驱动企业数字化的四种模式

而对于企业数字化，云原生技术等同于个人数字化时代的移动互联网，在整个企业数字化进程中扮演非常重要的角色，已驱动着企业数字化。基于对个人数字化的总结，我们来分析一下企业数字化的驱动力。

企业数字化中应用多且复杂，与个人数字化有很大不同。所以除了个人数字化里面所提及的易用性、生态建设、服务化三个关键点，我们还需要关注应用全生命周期赋能，它是企业数字化的最底层驱动力。下面我分别从易用性、生态建设、服务化、应用全生命周期赋能这四个方面来讲解一下具体的实现模式。

1、云原⽣的“易⽤性”模式 – 应⽤级抽象模型

易用性越高，受众人群越大，易用性每提高一点，用户基数呈现几何倍数增加。云原生的易用性，涉及三个层次。

• 最下面一层是Kubernetes和容器技术，Kubernetes和容器技术解决了运维管理中环境管理和自动化调度问题，提升了对复杂应用运维管理的易用性，但K8s和容器技术门槛比较高，要使用起来还是需要专门的学习，适合专职的工程师。如果要让更多人能使用起来，还需要更加易用。
• 第二层是通过应用级抽象模型搭建应用管理平台，使用者不需要关心容器和K8s等底层技术，只需要关注业务本身，管理的范畴也扩大到应用的全生命周期，使用的关注点上移，重心在业务创造，体验上实现现积木式业务模块拼装和能力按需扩展。在这一层面，易用性相比容器抽象，大幅度提升，所有开发人员都可以快速上手，使用人群能进一步扩大。
• 最上层，提供服务级使用体验，使用群体可以完全不用懂技术，类似手机App Store的使用体验，即点即用，用户实现自助安装和升级，这层的易用性适合所有企业用户。

2、云原⽣的“⽣态建设”模式 – 云原生应⽤市场

企业数字化的生态建设与个人数字化类似，也需要通过应用市场来实现。但是，由于企业数字化中应用和资源的复杂度较高，要实现应用市场，需要建立应用和资源的标准和规范，并且要能够完全解耦。此外，在交付的形态也更为复杂，需要解决各种企业场景的交付问题。

为了适应真实的企业数字化场景，云原生应用市场需要解决这些问题：

• 在应用供应方面，软件供应商可以自助加入和上架应用，根据不同颗粒度的软件有不同类型的软件厂商加入。小颗粒基础能力厂商提供业务组件、技术组件、中间件、API等；中等颗粒度的行业产品和通用产品厂商提供通用软件产品和行业软件等；大颗粒度的行业解决方案厂商和集成商提供完整的解决方案，或基于能力和产品拼装行业解决方案。

• 在计算资源供应方面，厂商也可以自助将自己的资源加入，前提是要符合K8S、API等标准。这样，应用市场就拥有了各种资源、各种应用、各种底层等模块。

• 在交付能力方面，对于行业中小用户来说，可直接全自助交付，强调服务化和低成本化；另一方面，对于行业大型用户来说，可以基于他们自身的基础设施，实现软件自动化安装，供应商可远程对基础设施进行维护管理及定制开发。

总的来说，云原生生态建设需要通过应用市场的方式来落地，真正激活整个生态及整个软件行业，并实现最终用户自助的灵活性和生产应用场景的多样性。只有这样，才能适应真实的企业数字化场景，推动云原生技术的进一步发展和应用。

3、云原⽣的“服务化”模式 – ⾃服务SaaS

随着数字化的加速发展，越来越多的企业开始使用云原生技术来构建自己的数字化平台。云原生技术的一个重要应用就是自服务SaaS，通过自动化的运维过程，实现自助式的SaaS服务交付，大幅度提升企业数字化的效率。

自服务SaaS，顾名思义，就是利用云原生技术将企业软件自动化为SaaS服务的方式，提供给企业用户使用。这种服务模式不仅可以帮助企业降低成本，还能够提高数字化服务的交付效率，为企业带来更大的价值。

自服务SaaS的实现需要从以下五个方面考虑：

第一，企业软件。通过将企业软件进行云原生改造，实现自动化的运维过程。这样，企业可以快速部署应用，提高数字化服务的交付速度和效率。

第二，计算资源。通过云原生技术实现自动化计算资源调度，将企业应用交付到自己的计算资源中，解决数据安全问题，并降低成本。

第三，自动安装。通过云原生技术实现自动化的安装过程，用户只需简单操作，即可快速使用企业应用，提高数字化服务的用户体验。

第四，自动运维。通过云原生技术实现自动化的运维过程，实时监控应用的运行状态，并自动修复故障，提高数字化服务的可靠性和稳定性。

第五，多租户。通过云原生技术实现多租户机制，为不同用户提供独立的应用服务，并实现资源的隔离和共享。

4、云原⽣为应⽤全⽣命周期赋能，实现企业应⽤⼀体化管理

云原生为企业应用生态赋能，主要涉及应用生命周期的四个方面。

首先，从开发角度看，云原生可以实现源代码的自动识别和构建，并提供云端开发、云端调试以及一体化的开发环境。这样可以让开发人员专注于业务代码的开发，而无需进行太多的迁移工作。

其次，从架构角度看，云原生可以实现可拼装的业务逻辑、无侵入的微服务架构以及按需扩展的服务治理能力。这些特性最终带来的价值是模块化的复用率大幅度提高，所有厂商都可以找到合适的定位，从而实现积木式的拼装体验。因此，每个企业都可以通过云原生快速落地数字化转型。

第三，从交付角度看，云原生可以通过应用模版实现一键安装和升级，并自动适应各种交付环境，从而实现自动化交付和灰度发布，提高迭代和交付效率，同时提高交付过程的标准化。

最后，从运维角度看，云原生可以让底层的系统运维环节变得更加简单，应用层运维变得更加自动化。这不仅可以为企业带来效率提升，同时也让开发者除了编写代码以外，还能够实现对整个开发过程的可控，从而提高资源利用率。

企业数字化的iPhone时刻

这些驱动力构成了云原生的基础，使得企业能够更快地进行数字化转型，并且通过新模式来提高数字化转型的效率和质量。我相信随着云原生技术的不断发展和普及，很快就会出现“云原生的iPhone时刻”，这将助推企业数字化建设全面开花。

功能或特点 MyBatis-Flex MyBatis-Plus Fluent-Mybatis 对 entity 的基本增删改查 ✅ ✅ ✅ 分页查询 ✅ ✅ ✅ 分页查询之总量缓存 ✅ ❌ ❌ 分页查询无 SQL 解析设计（更轻量，及更高性能） ✅ ❌ ✅ 多表查询： from 多张表 ✅ ❌ ❌ 多表查询： left join、inner join 等等 ✅ ❌ ✅ 多表查询： union，union all ✅ ❌ ✅ 单主键配置 ✅ ✅ ✅ 多种 id 生成策略 ✅ ✅ ✅ 支持多主键、复合主键 ✅ ❌ ❌ 字段的 typeHandler 配置 ✅ ✅ ✅ 除了 Mybatis，无其他第三方依赖（更轻量） ✅ ❌ ❌ QueryWrapper 是否支持在微服务项目下进行 RPC 传输 ✅ ❌ 未知 逻辑删除 ✅ ✅ ✅ 乐观锁 ✅ ✅ ✅ SQL 审计 ✅ ❌ ❌ 数据填充 ✅ ✔️
 
（收费） ✅ 数据脱敏 ✅ ✔️
 
（收费） ❌ 字段权限 ✅ ✔️
 
（收费） ❌ 字段加密 ✅ ✔️
 
（收费） ❌ 字典回显 ✅ ✔️
 
（收费） ❌ Db + Row ✅ ❌ ❌ Entity 监听 ✅ ❌ ❌ 多数据源支持 ✅ 借助其他框架或收费，不支持非Spring项目 ❌ 多租户 ✅ ✅ ❌

2023-04-08 V3.3.5

* UMessageTip: 解决了Release模式下GDI位图未释放的Bug
* Demo: 重写FMain，从UIForm继承
* UITreeView: 修改LabelEdit属性
* 内置的一些容器增加关闭过滤下拉框的事件
* UINumPadTextBox: 增加了最大值、最小值等属性
* UGraphics: 重构了一遍绘图方法
* UIComboDataGridViewItem: 增加多语翻译
* UIComboTreeView: 显示清除按钮
* UControl: 修复关闭弹窗null的Bug
* UIDropControl: DropDownList时，显示水印文字

更新日志 

1. 立即购买支持多个商品
2. 新增公共加入购物车操作
3. 订单分组多订单场景下仅支持快递模式
4. 起购数和限购数提升到规格层级
5. 新增视频扫码组件
6. 自提订单取货支持扫码操作
7. 自定义页面改为html+css+javascript代码编辑模式
8. 多端多系统标识调支持用户信息共享
9. 用户新增所属平台标记
10. api接口token各端独立，并加强token加密
11. 内置多语言模块（前后端及语言可控）
12. 可视化设计支持鼠标悬停图片放大控制
13. 可视化页面支持自定义协议url
14. 订单、订单售后、消息新增钩子
15. 图标导航支持纯净模式
16. 地区支持唯一编号快捷选择
17. 弹窗支持拖动和双击全屏缩小
18. 后台管理窗口支持多窗口并行
19. 单独售后仅退款自动退数量优化
20. 进销存支持与商城双向同步和运单打印及商品标签打印
21. 新增商品服务插件
22. 新增组合搭配插件
23. 新增批量下单插件
24. 小程序整体结构及功能细节优化

进销存效果图片（支持多商户使用）

门店收银台效果图片（O2O 多门店）

小程序端效果图片（内置多种配色）

可视化 DIY 拖拽装修展示

PC 端展示

后台管理展示

文档 源码 在线体验 模板性能测试 表达式引擎性能测试  性能优化指南 

最新模板性能测试，各个模板引擎均采用最新版本， Score 越大越好

Beetl>Rocker>>Freemarker>>Thymeleaf==Velociy

 Benchmark Mode Cnt Score Error Units Beetl.benchmark thrpt 5 .506 ± 19090.130 ops/s Freemarker.benchmark thrpt 5 48062.783 ± 9054.282 ops/s Handlebars.benchmark thrpt 5 48505.286 ± 6078.944 ops/s Rocker.benchmark thrpt 5 .041 ± 11827.123 ops/s Thymeleaf.benchmark thrpt 5 14495.261 ± 1460.815 ops/s Velocity.benchmark thrpt 5 12071.498 ± 4226.219 ops/s

最新规则引擎性能测试，Score 越大越好

JfireEL>> Aviator=Beetl=Jexl3 >>Spel>>Mvel=Groovy>>Nashor

 Benchmark Mode Cnt Score Error Units Aviator.forExpresss thrpt 5 .321 ± 4657.336 ops/s Aviator.ifExpresss thrpt 5 .542 ± .101 ops/s Aviator.simpleExpress thrpt 5 .018 ± 38439.986 ops/s Beetl.forExpresss thrpt 5 .017 ± 28454.020 ops/s Beetl.ifExpresss thrpt 5 .443 ± 78687.317 ops/s Beetl.reflect thrpt 5 62972.088 ± 85785.390 ops/s Beetl.simpleExpress thrpt 5 .130 ± .699 ops/s Groovy.ifExpresss thrpt 5 .364 ± 1472.301 ops/s Groovy.simpleExpress thrpt 5 .720 ± 1533.726 ops/s Jexl3.forExpresss thrpt 5 .632 ± 42390.393 ops/s Jexl3.ifExpresss thrpt 5 .752 ± .400 ops/s Jexl3.simpleExpress thrpt 5 .173 ± .114 ops/s JfireEL.ifExpresss thrpt 5 .920 ± .385 ops/s JfireEL.simpleExpress thrpt 5 .084 ± .504 ops/s Mvel.forExpresss thrpt 5 11954.857 ± 84.105 ops/s Mvel.ifExpresss thrpt 5 .242 ± 1827.288 ops/s Mvel.simpleExpress thrpt 5 .646 ± 1320.717 ops/s Nashorn.ifExpresss thrpt 5 10010.541 ± 752.057 ops/s Nashorn.simpleExpress thrpt 5 8993.022 ± 518.940 ops/s Spel.ifExpresss thrpt 5 .540 ± 41826.542 ops/s Spel.simpleExpress thrpt 5 .839 ± 2553.017 ops/s 

关注公众号

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

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

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

更新内容：

[修复] common.js 没有被导入 layui 模块的问题。

[修复] 消息列表，不存在消息仍显示徽章提示的问题。

[修复] card-list 的 image 素大小异常。

[修复] layui-table 的 cell 内，pear-btn 无间隔。

[优化] common.js 中过时 api 调用。

[修复] table.css 表格列错位问题。

[修复] tab.js 部分方法无法使用的问题。

[修复] common.js 的 submit 请求同一个url参数缓存的问题。

[修复] drawer.html 页面错误的代码。

[升级] layui@2.8.0-rc.15

关注公众号

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

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

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

关注公众号

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

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

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

sms-aggregation 聚合短信发送工具

作者介绍

• 名称：wind
• dromara 开源组织成员，dromara/sms_aggregation 作者
• java高级开发工程师，拥有丰富实战经验
• 个人空间：https://gitee.com/MR-wind
• 官方文档：https://wind.kim/

关于 SMS Aggregation

​ SMS Aggregation 是一款聚合短信发送工具，统一了各个厂商的发送功能和发送方法，省去学习不同短信厂商的差异化的时间，极简单的使用，可以让你在三分钟内完成短信发送功能的编写，并且额外添加了许多常用的工具和方法，让简单的事情回归简单的本质

使用

1. 引入maven依赖
2. 配置yml文件
3. 注入统一接口
4. 调用对应方法
5. 完成短信发送

支持厂商

各个厂商正在不断的适配中，最新的支持请查看官网

• 阿里云国内短信
• 腾讯云国内短信
• 华为云国内短信
• 合一短信
• 云片短信

配置文件

以下以阿里云短信为例

注入接口

调用对应方法

已发送标准短信为例

关注项目

对项目有什么想法或者建议，可以加我微信拉交流群，或者创建issues，一起完善项目

个人微信: Crazy-d1810

sms-aggregation 聚合短信发送工具

作者介绍

• 名称：wind

• dromara 开源组织成员，dromara/sms_aggregation 作者

• java高级开发工程师，拥有丰富实战经验

• 个人空间：https://gitee.com/MR-wind

• 官方文档：https://wind.kim/

关于 SMS Aggregation

SMS Aggregation 是一款聚合短信发送工具，统一了各个厂商的发送功能和发送方法，省去学习不同短信厂商的差异化的时间，极简单的使用，可以让你在三分钟内完成短信发送功能的编写，并且额外添加了许多常用的工具和方法，让简单的事情回归简单的本质

使用

1. 引入maven依赖

2. 配置yml文件

3. 注入统一接口

4. 调用对应方法

5. 完成短信发送

支持厂商

各个厂商正在不断的适配中，最新的支持请查看官网

• 阿里云国内短信

• 腾讯云国内短信

• 华为云国内短信

• 合一短信

• 云片短信

配置文件

以下以阿里云短信为例

注入接口

调用对应方法

已发送标准短信为例

关注项目

对项目有什么想法或者建议，可以加我微信拉交流群，或者创建issues，一起完善项目

个人微信

关于 Dromara

Dromara 是由国内顶尖的开源项目作者共同组成的开源社区。提供包括分布式事务，流行工具，企业级认证，微服务RPC，运维监控，Agent监控，分布式日志，调度编排等一系列开源产品、解决方案与咨询、技术支持与培训认证服务。技术栈全面开源共建、 保持社区中立，致力于为全球用户提供微服务云原生解决方案。让参与的每一位开源爱好者，体会到开源的快乐。

Dromara开源社区目前拥有10+GVP项目，总star数量超过十万，构建了上万人的开源社区，有成千上万的个人及团队在使用Dromara社区的开源项目。

UKUI (Ultimate Kylin User Interface) 是由openKylin社区UKUI SIG组开发维护的一款轻量级 Linux 桌面环境，默认搭载于openKylin开源操作系统、优麒麟开源操作系统和银河麒麟商业发行版中，同时支持 Debian、Ubuntu、ArchLinux、openEuler 等十款主流 Linux 发行版。基于 QT 进行开发，注重易用性和敏捷度，可以不依赖其它套件而独自运行，给用户带来亲切和高效的使用体验。

为进一步提升用户体验，openKylin社区对UKUI网站（https://www.ukui.org  ）进行了全新改版升级，并已于近期正式上线。各位小伙伴你发现了吗？是否有给大家带来一些惊喜呢？现在就让小K给大家简单介绍一下全新UKUI网站具体都有哪些亮点升级吧。

一、内容全面更新

新版UKUI网站对内容进行了全新规划，菜单导航信息分类更清晰，提炼出设计、开发、参与、文档、公告五个模块，方便用户更快定位到自己想要查看的内容。

二、视觉全新设计

区别于以往的只有夜间模式，新版UKUI网站新增了白天模式，用户可随意切换成自己喜欢的模式。同时对2种模式下的页面布局进行了优化，页面整体更简洁大气，减轻大家浏览网页时的视觉疲劳。

三、中英文双语切换

新版UKUI网站支持中英文实时切换，同时满足国内和国际用户诉求。

四、全面兼容各种设备

新版UKUI网站全面考虑了在PC电脑端、平板端、移动端上等不同设备上的展示效果，保障网站页面信息在不同设备上均能良好展示。

欢迎各位小伙伴“https://www.ukui.org/  ”前往体验，如果在体验过程中发现问题或不足，欢迎大家前往openKylin小程序提交反馈~

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

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

审核：openKylin

3月29日凌晨，腾讯旗下的微信和等业务曾出现崩溃状况，包括微信语音对话、朋友圈、微信支付，以及文件传输、空间和邮箱在内的多个功能无法使用。

虽然该故障在当天稍晚时候就被修复，但腾讯仍然对本次事故开出了堪称严厉的处罚单。

根据界面新闻的独家报道，本次事故由广州电信机房冷却系统故障导致，腾讯将它定义为公司一级事故。

腾讯管理层认为，这次事故暴露出容灾设计方案和应急预案不完善的隐患，有关业务部门的风险防范意识不到位，所以对大量相关领导做出了处罚。其中包含公司高级执行副总裁、TEG（技术工程事业群）总裁卢山（LS）和WXG（微信事业群）副总裁周颢（harveyzhou）在内的管理者承担领导责任，被予以通报批评。值得注意的是，卢山目前为腾讯总办（腾讯总裁办公室，为公司最高决策机构）成员。

此外，TEG华南数据中心的两位总经理和总监被处以降级和免职处罚，WXG技术架构部的两位总监和组长当期绩效考核给予Underperform等评级（二星级别，最高为五星）。

MySQL在生产环境中被广泛地应用，大量的应用和服务都对MySQL服务存在重要的依赖关系，可以说如果数据层的MySQL实例发生故障，在不具备可靠降级策略的背景下就会直接引发上层业务，甚至用户使用的障碍；同时MySQL中存储的数据也是需要尽可能地减少丢失的风险，以避免故障时出现数据丢失引发的资产损失、客诉等影响。

在这样对服务可用性和数据可靠性需求的背景下，MySQL在Server层提供了一种可靠的基于日志的复制能力(MySQL Replication)，在这一机制的作用下，可以轻易构建一个或者多个从库，提高数据库的高可用性、可扩展性，同时实现负载均衡：

从比较宽泛的角度来探讨复制的原理，MySQL的Server之间通过二进制日志来实现实时数据变化的传输复制，这里的二进制日志是属于MySQL服务器的日志，记录了所有对MySQL所做的更改。这种复制模式也可以根据具体数据的特性分为三种：

2.2.1 Binlog事件类型

对于Binlog的定义而言，可以认为是一个个单一的Event组成的序列，这些单独的Event可以主要分为以下几类：

各类Event出现是具有显著的规律的：

• XID_EVENT标志一个事务的结尾

• 当发生了DDL类型的QUERY_EVENT，那么也是一次事务的结束提交点，且不会出现XID_EVENT

• GTID_EVENT只有开启了GTID_MODE（MySQL版本大于5.6）

• TABLE_MAP_EVENT必定出现在某个表的变更数据前，存在一对多个ROW_EVENT的情况

除了上面和数据更贴近的事件类型外，还有ROTATE_EVENT（标识Binlog文件发生了切分），FORMAT_DESCRIPTION_EVENT（定义数据格式）等。

2.2.2 Binlog的生命周期

Binlog和Innodb Log（redolog）的存在方式是不同的，它并不会轮转重复覆写文件，Server会根据配置的单个Binlog文件大小配置不断地切分并产生新的Binlog，在一个.index文件记录当前硬盘上所有的binlog文件名，同时根据Binlog过期时间回收删除掉过期的Binlog文件，这两个在目前自建数据库的配置为单个大小1G，保留7天。

所以这种机制背景下，只能在短期内追溯历史数据的状态，而不可能完整追溯数据库的数据变化的，除非是还没有发生过日志过期回收的Server。 

2.2.3 Binlog事件示例

Binlog是对Server层生效的，即使没有从库正在复制主库，只要在配置中开启了log_bin，就会在对应的本地目录存储binlog文件，使用mysqlbinlog打开一个Row格式的示例binlog文件：

2.2.4 复制基准值

Binlog在产生时是严格有序的，但它本身只具备秒级的物理时间戳，所以依赖时间进行定位或排序是不可靠的，同一秒可能有成百上千的事件，同时对于复制节点而言，也需要有效可靠的记录值来定位Binlog中的水位，MySQL Binlog支持两种形式的复制基准值，分别是传统的Binlog File:Binlog Position模式，以及5.6版本后可用的全局事务序号GTID。

• FILE Position

只要开启了log_bin，MySQL就会具有File Position的位点记录，这一点不受GTID影响。

这个值必须要准确，因为这种模式下从库获取的数据完全取决于有效的开启点，那么如果存在偏差，就会丢失或执行重复数据导致复制中断。

• GTID

MySQL 会在开启GTID_MODE=ON的状态下，为每一个事务分配唯一的全局事务ID，格式为：server_uuid:id

从库在读取到Binlog后，会自动根据自身Executed_GTID_Set记录比对是否存在已执行或未执行的Binlog事务，并做对应的忽略和执行操作。

2.3.1 基本复制流程

• 时序关系

当集群进入运行的状态时，从库会持续地从主库接收到Binlog事件，并做对应的处理，那么这个过程中将会按照下述的数据流转方式：

1. Master将数据更改记录在Binlog中，BinlogDump Thread接到写入请求后，读取对应的Binlog

2. Binlog信息推送给Slave的I/O Thread。

3. Slave的I/O 线程将读取到的Binlog信息写入到本地Relay Log中。

4. Slave的SQL 线程读取Relay Log中内容在从库上执行。

上述过程都是异步操作，所以在某些涉及到大的变更，例如DDL改变字段，影响行数较大的写入、更新或删除操作都会导致主从间的延迟激增，针对延迟的场景，高版本的MySQL逐步引入了一些新的特性来帮助提高事务在从库重放的速度。

• Relay Log的意义

Relay log在本质上可以认为和binlog是等同的日志文件，即使是直接在本地打开两者也只能发现很少的差异；

2.3.2 半同步复制

• 时序关系

从半同步复制的时序图来看，实际上只是在主库Commit的环节多了等待接收从库ACK的阶段，这里只需要收到一个从节点的ACK即可继续正常的处理流程，这种模式下，即使主库宕机了，也能至少保证有一个从库节点是可以用的，此外还减少了同步时的等待时间。

2.3.3 小结

在当前生产环境的在线数据库版本背景下，由MySQL官方提供的复制方式主要如上文介绍的内容，当然目前有还很多基于MySQL或兼容MySQL的衍生数据库产品，能在可用性和可靠性上做更大的提升，本文就不继续展开这部分的描述。

期望业务层限制使用是不现实的，MySQL则在5.6版本开始尝试引入可用的并行复制方案，总的来说，都是通过尝试加强在从库层面的应用速度的方式。

2.4.1 基于Schema级别的并行复制

基于库级别的并行复制是出于一个非常简易的原则，实例中不同Database/Schema内的数据以及数据变更是无关的，可以并行去处置。

2.4.2 基于组提交的复制（Group Commit）

基于Schema的并行复制在大部分场景是没有效力的，例如一库多表的情况下，但改变从库的单执行线程的思路被延续了下来，在5.7版本新增加了一种基于事务组提交的并行复制方式，在具体介绍应用在复制中的组提交策略前，需要先介绍Server本身Innodb引擎提交事务的逻辑：

主库在大规模并发执行事务时，因为每个事务都触发加锁落盘，反而使得所有的Binlog串行落盘，成为性能上的瓶颈。针对这个问题，MySQL本身在5.6版本引入了事务的组提交能力（这里并不是指在从库上应用的逻辑），设计原理很容易理解，只要是能在同一个时间取得资源，开启Prepare的所有事务，都是可以同时提交的。

在主库具有这一能力的背景下，可以很容易得发现从库也可以应用相似的机制来并行地去执行事务，下面介绍MySQL具体实现经历的两个阶段：

• 基于Commit-Parents-Based

  MySQL中写入是基于锁的并发控制，所以所有在Master端同时处于Prepare阶段且未提交的事务就不会存在锁冲突，在Slave端执行时都可以并行执行。

  
  

  因此可以在所有的事务进入prepare阶段的时候标记上一个logical timestamp（实现中使用上一个提交事务的sequence_number），在Slave端同样timestamp的事务就可以并发执行。

  
  

  但这种模式会依赖上一个事务组的提交，如果本身是不受资源限制的并发事务，却会因为它的commit-parent没有提交而无法执行；

  
  

• 基于Logic-Based

  针对Commit-Parent-Based中存在的限制进行了解除，纯粹的理解就是只有当前事务的sequence_number一致就可以并发执行，只根据是否能取得锁且无冲突的情况即可以并发执行，而不是依赖上一个已提交事务的sequence_number。

当前vivo的在线MySQL数据库服务标准架构是基于一主一从一离线的异步复制集群，其中一从用于业务读请求分离，离线节点不提供读服务，提供给大数据离线和实时抽数/DB平台查询以及备份系统使用；针对这样的应用背景，存储研发组针对MySQL场景提供了两种额外的扩展服务：

虽然MySQL的主从复制可以提高系统的高可用性，但是MySQL在5.6,5.7版本是不具备类似Redis的自动故障转移的能力，如果主库宕机后不进行干预，业务实际上是无法正常写入的，故障时间较长的情况下，分离在从库上的读也会变得不可靠。

3.1.1 VSQL(原高可用2.0架构)

那么在当前这样标准一主二从架构的基础上，为系统增加HA高可用组件以及中间件组件强化MySQL服务的高可用性、读拓展性、数据可靠性：

• HA组件管理MySQL的复制拓扑，负责监控集群的健康状态，管理故障场景下的自动故障转移；

• 中间件Proxy用于管理流量，应对原有域名场景下变更解析慢或缓存不生效的问题，控制读写分离、实现IP、SQL的黑白名单等；

3.1.2 数据可靠性强化

数据本身还是依赖MySQL原生的主从复制模式在集群中同步，这样仍然存在异步复制本身的风险，发生主库宕机时，如果从库上存在还未接收到的主库数据，这部分就会丢失，针对这个场景，我们提供了三种可行的方案：

• 日志远程复制

配置HA的中心节点和全网MySQL机器的登录机器后，按照经典的MHA日志文件复制补偿方案来保障故障时的数据不丢失，操作上即HA节点会访问故障节点的本地文件目录读取候选主节点缺失的Binlog数据并在候选主上重放。

优势

劣势

• 日志集中存储

依赖数据传输服务中的BinlogServer模块，提供Binlog日志的集中存储能力，HA组件同时管理MySQL集群以及BinlogServer，强化MySQL架构的健壮性，真实从库的复制关系全部建立在BinlogServer上，不直接连接主库。

优势

劣势

• 改变为半同步复制

MySQL集群开启半同步复制，通过配置防止退化（风险较大），Agent本身支持半同步集群的相关监控，可以减少故障切换时日志丢失的量（相比异步复制）

优势

劣势

目前来说，我们采用的是日志远程复制的方案，同时今年在规划集中存储的BinlogServer方案来强化数据安全性；不过值得一提的是，半同步也是一种有效可行的方式，对于读多写少的业务实际上是可以考虑升级集群的能力，这样本质上也可以保证分离读流量的准确性。

3.2.1 基于Binlog的跨系统数据流转

通过利用Binlog，实时地将MySQL的数据流转到其它系统，包括MySQL，ElasticSearch，Kafka等MQ已经是一种非常经典的应用场景了，MySQL原生提供的这种变化数据同步的能力使其可以有效地在各个系统间实时联动，DTS（数据传输服务）针对MySQL的采集也是基于和前文介绍的复制原理一致的方法，这里介绍我们是如何利用和MySQL 从节点相同的机制去获取数据的，也是对于完整开启复制的拓展介绍：

（1）如何获取Binlog

比较常规的方式有两种：

• 监听Binlog文件，类似日志采集系统的操作

• MySQL Slave的机制，采集者伪装成Slave来实现

本文只介绍第二种，Fake Slave的实现方式

（2）注册Slave身份

这里以GO SDK为例，GO的byte范围是0~255，其它语言做对应转换即可。

（3）发起复制指令

以上两个命令通过客户端连接执行后，就可以在主库上观察到一个有效的复制连接。

3.2.2 利用并行复制模式提升性能

以上两个命令通过客户端连接执行后，就可以在主库上观察到一个有效的复制连接。

DTS消费单实现了对消费自kafka的事件的事务重组以及并发的事务解析工作，但实际最终执行还是串行单线程地向MySQL回放，这一过程使得性能瓶颈完全集中在了串行执行这一步骤。

（1）连接池改造

旧版的DTS的每一个消费任务只有一条维持的MySQL长连接，该消费链路的所有的事务都在这条长连接上串行执行，产生了极大的性能瓶颈，那么考虑到并发执行事务的需求，不可能对连接进行并发复用，所以需要改造原本的单连接对象，提升到近似连接池的机制。

go-mysql/client包本身不包含连接池模式，这里基于事务并发解析的并发度在启动时，扩展存活连接的数量。

（2）并发选择连接

• 利用逻辑时钟

开启GTID复制的模式下，binlog中的GTID_EVENT的正文内会包含两个值：

lastCommitted是我们并发的依据，原则上，LastCommitted相等事务可以并发执行，结合原本事务并发解析完成后会产生并发度（配置值）数量的事务集合，那么对这个列表进行分析判断，进行事务到连接池的分配，实现一种近似负载均衡的机制。

• 非并发项互斥

（3）校验点更新

但不论怎样进行优化，并发执行事务必然会引入更多的风险，例如并发事务的回滚无法控制，目标实例和源实例的因果一致性被破坏等，业务可以根据自身的需要进行权衡，是否开启并发的执行。

（4）小结

最后，关于MySQL的复制能力不仅对于MySQL数据库服务本身的可用性、可靠性有巨大的提升，也提供了Binlog这一非常灵活的开放式的数据接口用于扩展数据的应用范围，通过利用这个“接口”，很容易就可以达成数据在多个不同存储结构、环境的实时同步，未来存储组也将会聚焦于BinlogServer这一扩展服务来强化MySQL的架构，包括但不限于数据安全性保障以及对下游数据链路的开放等。

• MySQL官方文档

• 数据库内核月报

前言

监控指标诚然是发现问题于微末之时的极佳手段，但指标往往有其表达的极限。在很多情况下，单独看一个黄金指标并不能表征系统的健康程度，反而有可能被其迷惑，进而忽略相关问题。(本文所提及的Linux Kernel源码版本为4.18.10)

Bug现场

某天中午，某应用的999线突然升高。由于是个QPS高达几十万的查询服务，1分钟的升高就会影响数千个请求。初步判断应用容量不够，直接进行相关扩容，扩容后反而加剧了问题!不得已又做了一次紧急扩容，999线才恢复。这两波操作过去，20多分钟已经过去了。

为了防止问题再次发生，我们必须要彻查相关原因。于是笔者也就参与了调查。

Young GC升高

首先是去看常用的指标，例如CPU idle, GC Time。发现有一些机器的CPU达到了60%，而在这些机器中，young gc有一个大幅度的增长。

为什么Young GC升高

看上去GC问题。那么，笔者就开始思考为什么young gc升高。翻看gc日志。看到故障期间，不停的young gc。但这些young gc的表现很诡异。有时候young gc很快，只有数十毫秒，有时确达到了数百毫秒。而且这个耗时的跳跃没什么规律，不是从某个时间点之后就一直是数百毫秒，而是数十和数百一直参杂着。

观察young GC的详细输出，在数百毫秒的young GC时间里，大部分时间都在[Object Copy]上。令人奇怪的是。其Copy的Object大小确实差不多的。而这是个非常单纯的查询服务，故障期间，它的流量分布以及对应的Object分布不应该有非常大的变化。那么究竟是什么原因让同样大小以及数量的Object Copy会有十倍的差距呢？

再仔细观察，不仅仅是Object Copy，在其它的GC阶段也会出现时间暴涨的情况，只不过大部分集中在Object Copy而已。仅仅靠这些信息是无法看出来相关问题的。

为什么只有部分机器Young GC升高

继续观察监控，发现问题出现在一部分机器上。而这部分机器都在一个机房(B机房)里面。另一个机房(A机房)的机器没有受任何影响。当然，出问题的机器都出现了Young GC飙高的现象。难道两个机房的流量分布不一样？经过一番统计，发现接口的调用分布只是略微有些不同。但细细思考一下，如果是机房流量分布不一样，由于同机房是负载均衡的。要出问题，也是同机房都出问题。但问题只集中B机房的一部分机器中。

寻找这些机器的共同特征

young gc都大幅升高

那么既然只有一部分机器出问题。那么笔者开始搜索起这些机器的共同特征。young gc在这部分机器耗时都大幅增长。但由于笔者尚不能通过gc日志找出原因。那么就寻找了其它特征。

CPU.Busy

首先，是CPU.busy指标。笔者发现，出问题的机器CPU都在60%左右。但是，正常的节点CPU也有60%的，也有50%的，特征不是很明显。

delta_nr_throttled和delta_throttled_time

在笔者观察某台故障机器监控指标的时候发现，发现delta_nr_throttled和delta_throttled_time这个指标大幅度升高。

我们看下这两个指标的含义

由于线上应用这边采用的是docker容器，所以会有这两个指标。而这两个指标表明了，这个CGroup由于CPU消耗太高而被宿主机的Kernel限制运行。而令人奇怪的是，这些机器的CPU最多只有60%左右，按理来说只有达到100%才能被限制(throttled/limit)。

宿主机CPU飙升

既然是宿主机限制了相关docker容器，那么很自然的联想到宿主机出了问题。统计了一下出故障容器在宿主机上的分布。发现出问题的所有容器都是集中出现在两台宿主机上！

查看了下这两台宿主机的CPU Busy，发现平均已经90%多了。

宿主机超卖

详细观察了下这两个宿主机，发现它们超卖非常严重。而且当前这个出问题的应用非常集中的部署在这两个宿主机上。一台48核的宿主机，仅仅出问题的这个应用就分配了10个，而且分配的资源是每个容器8核(实际上是时间片)。那么按照，每个容器使用了60%计算，正好用满了这个宿主机的核

为什么第一次扩容后加剧了问题

因为这次是通过API自动扩容，而由于打散度计算的原因，还是扩容到了这两台已经不堪重负的CPU上。同时应用启动加载时候的CPU消耗也加剧了宿主机CPU的消耗。

为什么第二次扩容之后999线恢复正常

因为第二次直接通过API手动扩容，一次性在10多台宿主机上机器上扩了一倍的机器。这样分配在这两台不堪重负的宿主机上的应用流量降低到一半左右。进而使得999线恢复正常。

为什么容器相关的CPU busy在宿主机已经接近100%的情况下，依旧只展示60%的

很明显的，容器的CPU Busy在很大程度上误导了我们的决策。在之前的容量压测中，压到期望的TPS时候CPU Busy只有50%多，而且基本是按照TPS线性增长的，就使得我们觉得这个应用在当前的资源下容量是绰绰有余。毕竟CPU Busy显示的还是非常健康的。

但没想到，在压测CPU 50%多的时候，其实已经到了整个应用容量的极限。线上的流量和压测流量的构造有稍微一点的区别，让CPU涨了个5%左右,过了那个宿主机CPU的临界点，进而就导致了应用出现了非常高的999线。

容器CPU busy和idle的计算

为了探究这个问题，笔者就不得不看下容器的CPU busy是如何计算出来的。毕竟Linux的CGroup并没有提供CPU Busy这个指标。翻阅了一下监控的计算公式。

那么我们可以看一下cpuacct.usage是如何计算的。Kernel的代码实现为:

由代码可见，其计算是将所有CPU中的关于当前CGroup的cpuusage->usages中的user和system time相加，进而获取到最终此。那么我们可以进一步看下CGroup中的cpuusage是如何计算的。这边笔者以我们常用的CFS(完全公平调度的代码实现为例):

由上面代码可知，kernel会在进程间切换的时候，将当前进程的运行时间记入到相关。那么就是这个cputime的计算了。

好了，翻了一大堆代码，我们的cpuusage实际上就是这个cgroup在这一次CFS的kernel调度时间片中实际运行的时间。而我们的应用主要是一个Java进程，那么其基本就是这个Java进程运行了多长时间。值得注意的是，每个CPU的调度都会进行这样的计算。如下图所示:

那么我们来看一下在超卖情况下的表现。如下图所示:

(图中1.25s只是为了绘图方便，实际调度时间切片非常小)

如果超卖了，而且进程都比较繁忙，那么每个CGroup肯定不能完全的占用宿主机的CPU。指定到某个CPU上就势必会有多个CGroup交替进行。而之前的容器CPU.Busy计算公式

反应的实际上是这个容器在这个CPU(核)上运行了多长时间。而完全不能反应CPU的繁忙程度。

如果不超卖，每个CGroup被均匀的分到各自的CPU上互不影响(当然如果cgroup绑核了那隔离性更好)，那么这个计算公式才能够比较准确的反映CPU的情况。

nr_throttled和throttled_time

在Kernel中这两个参数表示由于分配给Cgroup的cfs_quota_us时间片额度用完。进而导致被内核限制,限制的次数为nr_throttled，限制的总时间为throttled_time。

但这边和上面的推论有一个矛盾的点,如果由于CPU超卖而引起的问题的话。那么每个CGroup并不能分到800ms这样总的时间片。因为按照上面的推算，每个CGroup最多分到60% * 800=480ms的时间片。而这个时间片是不应该触发nr_throttled和throttled_time的！

就在笔者对着Kernel源码百思不得其解之际，笔者发现Linux Kernel在5.4版本有个优化

也就是说在5.4版本之前，在一些场景下low cpu usage依旧能导致cgroup被throttled。而这个场景即是:

出故障的应用使用了大量的线程去处理请求，同时也有大量的IO操作(操作分布式缓存)，符合此Bug的描述。

# 那么到底是内核Bug还是超卖是主因呢？

这个疑问当然靠对比来解决，我们在故障之后，做了一次压测(CPU.Busy > 60%)，这次应用是不超卖的。这次delta_nr_throttled和delta_throttled_time依旧存在，不过比故障时的数量少了一个数量级。

同时999线从故障时候的暴涨6倍变成了只增长1倍。

很明显的，宿主机超卖是主因！而且宿主机超卖后的宿主机CPU负载过高还加重了这个Bug的触发。

关于Cgroup的核数分配

线上的Cgroup(容器)的核数分配实际上是按照(核数=cfs_quota_us/cfs_period_us)这个模型去分配的，同时并不会在cpuset进行绑核。也就是说一个48核的容器，应用的各个线程可以跑在任何一个核上，只不过只分配了8核的时间片额度。这就利用了Cgroup的带宽控制机制CFS_BANDWITH。

改进措施

很明显的改进措施可以是下面几种:

为什么Young GC会变慢

回过头来看看young gc为什么会慢就很明显了。因为在young gc时候，被shedule出去了，而且没有其它的空闲CPU让jvm可以schedule回来，白白浪费了很长时间。

因为object copy在这个应用的young gc中是最耗费CPU以及时间的操作，所以自然在object copy阶段出现变慢的现象。

当然，进程schedule可以处在各种时间点，所以并不仅仅是Young GC变慢了，在请求处理阶段也可能变慢。

总结

指标虽然能够比较准确且客观的反映两个时间点的变化。但指标的定义和对指标的解读确实比较主观的，没有理解清楚指标所能表达的极限以及使用场景。往往会让我们排查问题进入误区！

摘要：Redis事务包含两种模式：事务模式和Lua脚本。

本文分享自华为云社区《一文讲透 Redis 事务》，作者： 勇哥java实战分享。

准确的讲，Redis事务包含两种模式：事务模式和Lua脚本。

先说结论：

Redis的事务模式具备如下特点：

• 保证隔离性；
• 无法保证持久性；
• 具备了一定的原子性，但不支持回滚；
• 一致性的概念有分歧，假设在一致性的核心是约束的语意下，Redis 的事务可以保证一致性。

但Lua脚本更具备实用场景，它是另一种形式的事务，他具备一定的原子性，但脚本报错的情况下，事务并不会回滚。Lua脚本可以保证隔离性，而且可以完美的支持后面的步骤依赖前面步骤的结果。

Lua脚本模式的身影几乎无处不在，比如分布式锁、延迟队列、抢红包等场景。

1 事务原理

Redis的事务包含如下命令：

事务包含三个阶段：

1. 事务开启，使用 MULTI , 该命令标志着执行该命令的客户端从非事务状态切换至事务状态 ；
2. 命令入队，MULTI 开启事务之后，客户端的命令并不会被立即执行，而是放入一个事务队列 ；
3. 执行事务或者丢弃。如果收到 EXEC 的命令，事务队列里的命令将会被执行 ，如果是 DISCARD 则事务被丢弃。

下面展示一个事务的例子。

这里有一个疑问？在开启事务的时候，Redis key 可以被修改吗？

在事务执行 EXEC 命令之前 ，Redis key 依然可以被修改。

在事务开启之前，我们可以 watch 命令监听 Redis key 。在事务执行之前，我们修改 key 值 ，事务执行失败，返回 nil 。

通过上面的例子，watch 命令可以实现类似乐观锁的效果 。

2 事务的ACID

2.1 原子性

原子性是指：一个事务中的所有操作，或者全部完成，或者全部不完成，不会结束在中间某个环节。事务在执行过程中发生错误，会被回滚到事务开始前的状态，就像这个事务从来没有执行过一样。

第一个例子：

在执行 EXEC 命令前，客户端发送的操作命令错误，比如：语法错误或者使用了不存在的命令。

在这个例子中，我们使用了不存在的命令，导致入队失败，整个事务都将无法执行 。

第二个例子：

事务操作入队时，命令和操作的数据类型不匹配 ，入队列正常，但执行 EXEC 命令异常 。

这个例子里，Redis 在执行 EXEC 命令时，如果出现了错误，Redis 不会终止其它命令的执行，事务也不会因为某个命令执行失败而回滚 。

综上，我对 Redis 事务原子性的理解如下：

1. 命令入队时报错， 会放弃事务执行，保证原子性；
2. 命令入队时正常，执行 EXEC 命令后报错，不保证原子性；

也就是：Redis 事务在特定条件下，才具备一定的原子性 。

2.2 隔离性

数据库的隔离性是指：数据库允许多个并发事务同时对其数据进行读写和修改的能力，隔离性可以防止多个事务并发执行时由于交叉执行而导致数据的不一致。

事务隔离分为不同级别 ，分别是：

• 未提交读（read uncommitted）
• 提交读（read committed）
• 可重复读（repeatable read）
• 串行化（serializable）

首先，需要明确一点：Redis 并没有事务隔离级别的概念。这里我们讨论 Redis 的隔离性是指：并发场景下，事务之间是否可以做到互不干扰。

我们可以将事务执行可以分为 EXEC 命令执行前和 EXEC 命令执行后两个阶段，分开讨论。

• EXEC 命令执行前

在事务原理这一小节，我们发现在事务执行之前 ，Redis key 依然可以被修改。此时，可以使用 WATCH 机制来实现乐观锁的效果。

• EXEC 命令执行后

因为 Redis 是单线程执行操作命令， EXEC 命令执行后，Redis 会保证命令队列中的所有命令执行完 。 这样就可以保证事务的隔离性。

2.3 持久性

数据库的持久性是指 ：事务处理结束后，对数据的修改就是永久的，即便系统故障也不会丢失。

Redis 的数据是否持久化取决于 Redis 的持久化配置模式 。

1. 没有配置 RDB 或者 AOF ，事务的持久性无法保证；
2. 使用了 RDB模式，在一个事务执行后，下一次的 RDB 快照还未执行前，如果发生了实例宕机，事务的持久性同样无法保证；
3. 使用了 AOF 模式；AOF 模式的三种配置选项 no 、everysec 都会存在数据丢失的情况 。always 可以保证事务的持久性，但因为性能太差，在生产环境一般不推荐使用。

综上，redis 事务的持久性是无法保证的 。

2.4 一致性

一致性的概念一直很让人困惑，在我搜寻的资料里，有两类不同的定义。

• 维基百科

我们先看下维基百科上一致性的定义：

Consistency ensures that a transaction can only bring the database from one valid state to another, maintaining database invariants: any data written to the database must be valid according to all defined rules, including constraints, cascades, triggers, and any combination thereof. This prevents database corruption by an illegal transaction, but does not guarantee that a transaction is correct. Referential integrity guarantees the primary key – foreign key relationship.

在这段文字里，一致性的核心是“约束”，“any data written to the database must be valid according to all defined rules ”。

如何理解约束？这里引用知乎问题 如何理解数据库的内部一致性和外部一致性，蚂蚁金服 OceanBase 研发专家韩富晟回答的一段话：

“约束”由数据库的使用者告诉数据库，使用者要求数据一定符合这样或者那样的约束。当数据发生修改时，数据库会检查数据是否还符合约束条件，如果约束条件不再被满足，那么修改操作不会发生。

关系数据库最常见的两类约束是“唯一性约束”和“完整性约束”，表格中定义的主键和唯一键都保证了指定的数据项绝不会出现重复，表格之间定义的参照完整性也保证了同一个属性在不同表格中的一致性。

“ Consistency in ACID ”是如此的好用，以至于已经融化在大部分使用者的血液里了，使用者会在表格设计的时候自觉的加上需要的约束条件，数据库也会严格的执行这个约束条件。

所以事务的一致性和预先定义的约束有关，保证了约束即保证了一致性。

我们细细品一品这句话： This prevents database corruption by an illegal transaction, but does not guarantee that a transaction is correct。

写到这里可能大家还是有点模糊，我们举经典转账的案例。

我们开启一个事务，张三和李四账号上的初始余额都是1000，并且余额字段没有任何约束。张三给李四转账1200。张三的余额更新为 -200 ， 李四的余额更新为2200。

从应用层面来看，这个事务明显不合法，因为现实场景中，用户余额不可能小于 0 ， 但是它完全遵循数据库的约束，所以从数据库层面来看，这个事务依然保证了一致性。

Redis 的事务一致性是指：Redis 事务在执行过程中符合数据库的约束，没有包含非法或者无效的错误数据。

我们分三种异常场景分别讨论：

1. 执行 EXEC 命令前，客户端发送的操作命令错误，事务终止，数据保持一致性；
2. 执行 EXEC 命令后，命令和操作的数据类型不匹配，错误的命令会报错，但事务不会因为错误的命令而终止，而是会继续执行。正确的命令正常执行，错误的命令报错，从这个角度来看，数据也可以保持一致性；
3. 执行事务的过程中，Redis 服务宕机。这里需要考虑服务配置的持久化模式。

• 无持久化的内存模式：服务重启之后，数据库没有保持数据，因此数据都是保持一致性的；
• RDB / AOF 模式： 服务重启后，Redis 通过 RDB / AOF 文件恢复数据，数据库会还原到一致的状态。

综上所述，在一致性的核心是约束的语意下，Redis 的事务可以保证一致性。

• 《设计数据密集型应用》

这本书是分布式系统入门的神书。在事务这一章节有一段关于 ACID 的解释：

Atomicity, isolation, and durability are properties of the database,whereas consistency (in the ACID sense) is a property of the application. The application may rely on the database’s atomicity and isolation properties in order to achieve consistency, but it’s not up to the database alone. Thus, the letter C doesn’t really belong in ACID.

原子性，隔离性和持久性是数据库的属性，而一致性（在 ACID 意义上）是应用程序的属性。应用可能依赖数据库的原子性和隔离属性来实现一致性，但这并不仅取决于数据库。因此，字母 C 不属于 ACID 。

很多时候，我们一直在纠结的一致性，其实就是指符合现实世界的一致性，现实世界的一致性才是事务追求的最终目标。

为了实现现实世界的一致性，需要满足如下几点：

1. 保证原子性，持久性和隔离性，如果这些特征都无法保证，那么事务的一致性也无法保证；
2. 数据库本身的约束，比如字符串长度不能超过列的限制或者唯一性约束；
3. 业务层面同样需要进行保障 。

2.5 事务特点

我们通常称 Redis 为内存数据库 , 不同于传统的关系数据库，为了提供了更高的性能，更快的写入速度，在设计和实现层面做了一些平衡，并不能完全支持事务的 ACID。

Redis 的事务具备如下特点：

• 保证隔离性；
• 无法保证持久性；
• 具备了一定的原子性，但不支持回滚；
• 一致性的概念有分歧，假设在一致性的核心是约束的语意下，Redis 的事务可以保证一致性。

从工程角度来看，假设事务操作中每个步骤需要依赖上一个步骤返回的结果，则需要通过 watch 来实现乐观锁 。

3 Lua 脚本

3.1 简介

Lua 由标准 C 编写而成，代码简洁优美，几乎在所有操作系统和平台上都可以编译，运行。Lua 脚本可以很容易的被 C/C ++ 代码调用，也可以反过来调用 C/C++ 的函数，这使得 Lua 在应用程序中可以被广泛应用。

Lua 脚本在游戏领域大放异彩，大家耳熟能详的《大话西游II》，《魔兽世界》都大量使用 Lua 脚本。Java 后端工程师接触过的 api 网关，比如 Openresty ，Kong 都可以看到 Lua 脚本的身影。

从 Redis 2.6.0 版本开始， Redis内置的 Lua 解释器，可以实现在 Redis 中运行 Lua 脚本。

使用 Lua 脚本的好处 ：

• 减少网络开销。将多个请求通过脚本的形式一次发送，减少网络时延。
• 原子操作。Redis会将整个脚本作为一个整体执行，中间不会被其他命令插入。
• 复用。客户端发送的脚本会永久存在 Redis 中，其他客户端可以复用这一脚本而不需要使用代码完成相同的逻辑。

Redis Lua 脚本常用命令：

3.2 EVAL 命令

命令格式：

说明：

• script是第一个参数，为 Lua 5.1脚本；
• 第二个参数numkeys指定后续参数有几个 key；
• key [key …]，是要操作的键，可以指定多个，在 Lua 脚本中通过KEYS[1], KEYS[2]获取；
• arg [arg …]，参数，在 Lua 脚本中通过ARGV[1], ARGV[2]获取。

简单实例：

下面演示下 Lua 如何调用 Redis 命令 ，通过redis.call()来执行了 Redis 命令 。

“hello world”

3.3 EVALSHA 命令

使用 EVAL 命令每次请求都需要传输 Lua 脚本 ，若 Lua 脚本过长，不仅会消耗网络带宽，而且也会对 Redis 的性能造成一定的影响。

思路是先将 Lua 脚本先缓存起来 , 返回给客户端 Lua 脚本的 sha1 摘要。 客户端存储脚本的 sha1 摘要 ，每次请求执行 EVALSHA 命令即可。

EVALSHA 命令基本语法如下：

实例如下：

4 事务 VS Lua 脚本

从定义上来说， Redis 中的脚本本身就是一种事务， 所以任何在事务里可以完成的事， 在脚本里面也能完成。 并且一般来说， 使用脚本要来得更简单，并且速度更快。

因为脚本功能是 Redis 2.6 才引入的， 而事务功能则更早之前就存在了， 所以 Redis 才会同时存在两种处理事务的方法。

不过我们并不打算在短时间内就移除事务功能， 因为事务提供了一种即使不使用脚本， 也可以避免竞争条件的方法， 而且事务本身的实现并不复杂。

— https://redis.io/

Lua 脚本是另一种形式的事务，他具备一定的原子性，但脚本报错的情况下，事务并不会回滚。Lua 脚本可以保证隔离性，而且可以完美的支持后面的步骤依赖前面步骤的结果。

Lua 脚本模式的身影几乎无处不在，比如分布式锁、延迟队列、抢红包等场景。

不过在编写 Lua 脚本时，要注意如下两点：

1. 为了避免 Redis 阻塞，Lua 脚本业务逻辑不能过于复杂和耗时；
2. 仔细检查和测试 Lua 脚本 ，因为执行 Lua 脚本具备一定的原子性，不支持回滚。

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

Review PR 是开源项目的重要一环。对于项目维护者来说，社区有人来贡献代码，是一件值得开心的事情，说明自己的项目受到了认可。开源项目将通过社区贡献变得更强大。对于贡献代码的开发者来说，编程能力获得了开源项目的认可，也是一件值得写到简历的事情。在 Review 代码的过程中加上了 ChatGPT，会发生什么化学反应？

我司 Second State 最近在自己的开源项目的 GitHub repo 中引入了一个基于 ChatGPT 的 PR Review 机器人。当有人提交新的 PR 的时候，这个机器人会总结 PR在干什么、潜在的风险与问题、以及这个 PR 里的每次 commit 都干了什么。这对 Reviewer 来说，能够大大增加 review PR 的速度。更重要的是 ChatGPT 还能找到代码里的潜在问题，提供更高效的写代码的方式。下面我们来看一个真实的例子。

看看下面这段代码，你有发现什么问题吗？

这段代码是检查一个给定的正整数 是否为素数。其中，变量 被初始化为 的平方根转换为整数，这可以有效地减少计算量。然后，使用 循环逐个测试从 2到 之间的所有数字是否是 的因数。如果 能被其中任何一个数字整除，则说明 不是素数，并且代码将返回 。反之，如果代码成功通过所有循环，则说明 是素数，并且将返回 。这段代码看起来属于 Rust 语言，而 是在 Rust 和 JavaScript 之间交换数据的类型之一，所以它可能用于将这段 Rust 代码嵌入到 JavaScript 中。

声明，以上代码解释文字由 ChatGPT 生成。

简单来说，如果给定的数字是 1927，这段代码就会先开根 1927，得出结果43，然后就开始循环除以从2开始到43的整数，一直到43结束。 从 2 到 43 所有的数字中，如果有能整除的数字，那1927就不是质数，如果没有，那1927 就是质数。

写到这里是不是也没有发现什么问题，这段代码在开始的时候就开根了正整数 n，已经提高了效率。

那让我们看看 ChatGPT 的 review 是什么样的，下面的 ChatGPT Review 结果是基于 GPT4 的。

之前已经介绍过，我们在 Second State 的主要 repo 都部署了一个基于 ChatGPT 的 PR Review 机器人。在部署这个机器人后，有人新提了 PR ， 机器人会自动总结并审阅 PR，以往的 PR 也可以通过自己定义的关键词来触发机器人让它工作。

我们试验了一个之前的 PR，让 ChatGPT总结并审阅，ChatGPT 在 Potential problems 提到了下面这段话：

The function can be optimized further, as it checks for divisibility with even numbers after 2, which isn’t necessary.

GPT4 说 函数可以被更好的优化，因为没有必要检查2之后的偶数。看到这里，你有没有恍然大悟，想拍大腿的感觉。已经不能被2整除，就不用试 4 6 8 10 等偶数了，因为肯定也不能整除。节省了一半工作量！优秀还得是 ChatGPT，这是连人都容易忽略的地方。当然还可以继续沿着这个思路优化，任何在这个循环中发现的素数的倍数（比如 3 的倍数，5 的倍数），都不用在下面试啦。ChatGPT 也能帮你写这个通用的算法。

上面这个例子节选自 ChatGPT 在 WasmEdge-quickjs 项目的 PR Review： https://github.com/second-state/wasmedge-quickjs/pull/82 ChatGPT 还提了很多建设性意见，这个 PR 的改动不大，大家可以自行查看改动的代码与ChatGPT 的 Review。

ChatGPT 在复杂 PR 中也有不错的表现，这个 PR 有 56 次 commit。下面的链接可以查 Review 的具体情况。 https://github.com/WasmEdge/WasmEdge/pull/2314#issuecomment-

通过上面的例子，我们现在可以回答文章标题提出的问题了：那些让 ChatGPT review 代码的程序员，后来都怎么样了？这个答案是 ChatGPT 可以赋能程序员，让软件更好、更快地吃掉世界。

看到这里，你一定有个问题，如何在自己的 GitHub Repo 安装一个这样的机器人，让 ChatGPT 提升自己的代码能力？下面就是手把手教程，教你在5分钟上线一个自己的 ChatGPT Review 机器人。

部署自己的 ChatGPT Review 机器人

首先我们要用到 flows.network 这个平台，这是一个联接 AI 大模型与真实世界 SaaS 的工作流自动化平台。使用它的好处之一是不用自己搭服务器（serverless），也不用自己做 Oauth，直接写了业务代码上传就可以！flows.nework 有着非常用户友好的界面。

首先第一步是 fork flows.network 的 github-pr-summary repo。这是开源的，你也可以根据自己的需求在代码里自定义 prompt，详情请见下文。这里将介绍如何通过无代码的形式，部署自己的机器人。

repo 地址：https://github.com/flows-network/github-pr-summary/

fork 之后，就可以直接去 flows.network 部署。

首先你要在 flows.network 有一个账号，你可以直接用 github 账号登录，不需要任何费用。

然后 Create a flow 按钮，创建一个新的flow。然后在 UI 中导入你刚刚 fork 的这个 repo。

然后点开 advanced，去配置环境变量，让 flows.network 知道你要在哪个 github repo 部署这个机器人，OpenAI API Key 是什么，哪个词语能够唤醒这个 function。

• : 填写你个人的 github 账号. 当发布 review 的时候，这个机器人会扮演你的角色来 review。
• : 填写你想部署机器人的 Github repo 属于哪个组织。
• : 填写你想部署机器人的 Github repo 名字。
• : 填写你想给 OpenAI Key 命名的名字，后续我们直接用到。
• : 填写你想要触发这个机器人的词语。

输入这些环境变量后，就可以 deploy 按钮。这个时候 flows.network 会自动进行build 你的函数，未来你的 repo 如果有了新的 commit，flows.network 也会自动帮你 build 部署。

下一步是配置我们需要连接的 SaaS，flows.network 会根据你的函数提示你需要验证哪些 SaaS 的账号。刚刚我们在环境变量里已经填写我们想在哪个 repo 部署机器人，OpenAI API key 的名字是什么，现在我们要授权 flows.network ，让它能够访问你的 repo 和你的 OpenAI API key，才能真正生效。

紫色的 connect 连接 OpenAI 账号，你需要输入你从 OpenAI 申请到的 API Key 并命名这个 OpenAI Key。 这里的名字要和前面在环境变量输入的名字一致。

OpenAI 验证完后，继续验证 GitHub， Connect ，你会打开一个由 GitHub 提供的验证页面，选择你刚刚选好的 Repo， 安装 flows network integration，这样才能在你的 repo 进行评论。

这些都设置好后， Go to the Flow 按钮。等待函数编译完，flow 的状态变成 running，就可以让 ChatGPT 帮你 review PR 啦。

进阶玩法：自定义规则与 prompt

github-pr-summary repo 是开源的，你也可以根据自己的需求在代码里自定义 prompt。 函数逻辑主要在 文件。

repo 地址：https://github.com/flows-network/github-pr-summary/

这段代码里的 system 与 question 都可以根据自己需求进行重写。比如，如果你的项目是纯 Rust 或 纯 C++ 代码，你可以让 ChatGPT 扮演成一个有经验的 Rust / C++ 开发者，而不是笼统的有经验的软件开发者。如果你有 GPT4 的权限，也可以在代码里把模型换成 GPT4。这些都可以根据你自己的需求来定制。

上面我们介绍了通过 flows network 平台的环境变量把一些参数如部署到哪个 GitHub repo、OpenAI API key 的名字传到函数里，这里我们来介绍如何直接在代码里告诉 flows.network。

参照下面的代码，把 里的 改成自己个人的 github 账号，把 的 改成自己的 github repo 所在的 org，把 的 改成你的 github repo 名字， 里的 改成你想给 OpenAI Key 命名的名字。最后是 里的 改成你想触发这个的词语，也可以不改，就用这个。 这里的逻辑和环境变量那一步是一样的，只是我们直接在代码里改了。

如果你改好了你的函数，那下一步就是去 flows.network 部署你的函数，只需要点点点点，就能上线一个 GitHub 机器人。

看到这里，实属真爱了！flows.network 与 GitHub PR Summary bot 正在 Product Hunt 上 launch，觉得还不错的朋友，请下方的链接给这个机器人投一票吧。

https://www.producthunt.com/posts/gpt-nitro-for-github-pr

<a href=”https://www.producthunt.com/posts/gpt-nitro-for-github-pr?utm_source=badge-featured&utm_medium=badge&utm_souce=badge-gpt-nitro-for-github-pr” target=”_blank”><img src=”https://api.producthunt.com/widgets/embed-image/v1/featured.svg?post_id=&theme=light” alt=”GPT Nitro for Github PR – A ChatGPT-based reviewer for your GitHub pull requests | Product Hunt” style=”width: 250px; height: 54px;” width=”250″ height=”54″ /></a>

作者： 殷达

背景

最近，云原生计算基金会 CNCF 下的 App Delivery TAG （应用交付领域小组）发布了《CNCF 平台工程白皮书》，KubeVela 被纳入“统一 API 层”项目。

原文下载链接：

https://appdelivery.cncf.io/whitepapers/platforms/

回溯 2019 年，Kubernetes 逐渐成为部署和管理基础设施的事实标准。越来越多的平台工程师开始在 Kubernetes 之上构建平台，并向最终用户提供服务。容器化部署和声明式 API 大大降低了复杂系统操作的难度。

然而，当集群中存在数千个工作负载和相关资源时，操作人员很难识别逻辑关系，并根据其内部关系进行准确且符合业务需要的管理。

同时，像 Helm 或 Kustomize 这样的工具已经探索了 打包和交付  Kubernetes 资源的解决方案。这些已被证明是非常有效的，显然 Helm Chart 现在是在 Kubernetes 中打包和分发制品最受欢迎的方式。

另一方面，各种项目也开始定义应用程序。这些尝试不仅是简单地打包资源，而是从自上而下的视角寻求解决方案。与将离散的对象分组以更方便使用相比，应用程序旨在弥合业务应用的研发者和基础设施之间的认知差距。开放应用模型 Open Application Model（OAM） [ 1] 及其对 KubeVela 的实现正是从这里开始。

Pic 1. OAM is proposed to bridge the gap between app developers and the use of underlying infrastructures

应用程序模型的诞生

由微软和阿里云支持的开放应用程序模型（OAM），其目标是为云原生应用程序应该是什么样子提供一个理论模型。它最初被设计为不与 Kubernetes 绑定，并且倾向于为操作应用程序提供统一的接口。OAM 提出了组件和特性的概念，以对应用程序架构进行抽象。这对于原生 Kubernetes 用户来说是一个很大的变革，但这是有原因的。

在 Kubernetes 中，Deployment 或 Service 等资源侧重于实现。每种资源类型都提供特定的功能。一些低级功能，（如运行容器），会转到 Pod 等基本单。一些更高级别功能，例如容器编排，处理回滚的功能，（例如 Deployment 或 StatefulSet），则是建立在较低级别的功能之上的。毫无疑问， “为平台构建者服务的平台” 这个定位获得了巨大的成功。但对于应用开发人员来说，社区正在迫使他们成为 Kubernetes 专家才能使事情正常运行。此外，对低级资源的肤浅理解实际上可能导致不正确操作带来的显著风险。

组件

OAM 切入的视角与传统的解决方案显著不同。应用程序的真正组成是什么？应用程序开发人员需要什么？

运行应用程序的东西。 对于应用程序来说，这绝对是最核心的部分。在 Kubernetes 中，它可以是 Deployment、Pods 或其他东西。在 Kubernetes 之外，它可以是 Docker 容器、虚拟机或云执行引擎。99.9% 的应用程序开发人员创建程序并运行它。OAM 将运行应用程序的整个内容定义为组件。它不仅仅是一组资源。没有组件，你将无法知道应用程序的用途。

Pic 2. Example of a component inside an OAM application

随着微服务变得越来越普遍，许多应用程序开发人员开始将庞大的单体程序分解为小的部分。OAM 的定义中的每个可运行的部分都可以建模为一个组件，作为一个整体，它们共同组成了一个完整的 OAM 应用程序。它们的内部逻辑关系也在组件中绘制。

特性

要使应用程序正常运行，还需要其他一些东西。例如，在 Kubernetes 中，我们有 Service、ConfigMap、PersistentVolumeClaim 和许多其他资源，它们为 Deployment 提供特定的功能。但是这些资源是为了满足某些技术需求而创建的，而不是以目的为导向的。ConfigMap 为Kubernetes 用户提供了一种存储配置数据的方法，但要让容器使用该配置，用户需要在 Deployment 中添加卷部分并设置容器参数或环境变量。

如果我们再次改变视角，考虑应用程序开发人员在使用这些资源时真正想要做什么，我们可能会得出这样一个结论即许多资源都是为应用程序组件提供额外功能。创建 Service 或 Ingress 对象是为应用程序提供访问而创建的。PersistentVolumeClaim 和 Deployment 中的卷部分是为提供存储而创建的。 第三方对象（如 Prometheus 中的ServiceMonitor）用于提供观察规则。这些提供功能的辅助资源和修改在 OAM 中被定义为特性。

这些特性 Trait 不能独立工作。这些功能附加到组件并用作装饰。没有它，应用程序的主要目的不会改变，但会不完整。

Pic 3. Example of an OAM application containing two components with traits attached

更多

除了 Component 和 Trait 之外，还有其他东西可以从不同的层面为应用程序工作。

每个应用程序可能包含多个原子功能单，即 Component（组件），每个 Component 可以由多个 Trait 修饰。如果我们想定义一些与运行 Component 没有明确一对一关系的应用程序级别的行为或策略，需要更多的应用程序定义。

截至目前，OAM 还没有对这部分建模提出决定性的解决方案。已经提出了包括 Scope、Policy、Workflow、Scope 在内的一些概念，用于定义应用程序的使用范围。Policy 用于描述常见的策略和行为。Workflow 侧重于应用程序的交付方面。其中一些已被 KubeVela 采用，KubeVela 是基于 Kubernetes 的 OAM 实现之一，在模型的演进上可以帮助我们通过实践来驱动设计。

从理论到实践

开放应用模型（Open Application Model）的规范从概念上为那些希望从应用开发人员的角度对应用程序和构建平台进行建模的平台构建者们提供指导。在过去的几年中，包括 KubeVela、Crossplane、Verrazzano 和 Intuit 在内的采用者都做了各种尝试。尽管 OAM 规范被提出为与基础架构无关，但到目前为止，目前大部分的（功能）实现都是基于 Kubernetes 作为控制平面。

回顾历史，我们得出的结论是，在 Kubernetes 上进行应用程序建模尤为重要。在将 OAM 规范应用于 Kubernetes 时，KubeVela 做了很多工作来解决各种细节上的技术问题。这些问题又可以分为三个不同的方向：抽象、交付和管理。

抽象

OAM 中的组件定义了应用程序的运行实例。不同类型的组件适用于不同类型的运行实例。在 Kubernetes 中，它对应于不同的工作负载实现，如 Deployment 或 StatefulSet。KubeVela 将这些类型声明为 ComponentDefinition，并为可扩展性解决方案引入 CUE。CUE 用于模板化 Kubernetes 资源，因此平台构建者可以进行任意的自定义操作。

Pic 4. KubeVela leverages CUE for templating Component and Trait

在 Trait 这层，抽象的方法与 Component 类似，也就是用 TraitDefinition 来声明不同类型。与 Component 的主要区别之一是，某些类型的 Trait 需要对 Component Definition 所抽象的资源进行修改。例如，为了暴露端口，我们需要同时添加 Service 对象并在 Deployment 规范中暴露端口。CUE 本身并没有提供这样的方法，但是KubeVela 会以某种方式对 CUE 进行扩展来实现了这一功能。除静态渲染外，KubeVela 的抽象层还有运行时感知能力。这意味着渲染逻辑可以根据运行环境进行更改，就像它当前运行的 Kubernetes 版本一样。当 KubeVela 用作跨集群的统一控制平面时，这一点尤其有用。

Pic 5. In traditional system, application developer needs to deal with version upgrades across clusters

总之，与 Helm Chart 使用的 Go Template 或通过 Kustomization 做配置简化类似，KubeVela 中抽象层的实现在功能上是完整包含的。另一方面，KubeVela 将这些抽象基础建立在 ComponentDefinitions 和 TraitDefinitions 之上，以便更好地实现重用。与直接使用 Helm Chart 对整个应用程序进行模板化相比，这为平台构建者提供了更精细的选择。这反过来又为平台工程师和业务研发人员之间的职责划分提供了更清晰的界限：平台工程师负责 X-Definitions，业务研发负责应用程序。

Pic 6. KubeVela leaves the abstraction implementation to platform engineers and lets app developers to use predefined types of Components and Traits to compose Applications

交付

抽象层主要解决构建、打包和分发应用的问题。在交付应用程序并将它们作为统一的整体时，情况会变得更加复杂。应用程序作为一个整体，在 KubeVela 中，被视为是交付的基本单。一个应用程序内部不同组件之间的关系可以决定如何交付这些组件，这些关系会在 dependsOn 字段中指示。

除了资源调度外，应用程序的交付有时还涉及更多，比如对生产环境的高风险交付进行人工审核、在自动交付完成时通知、跨多集群进行差异化交付等。为了让用户能够自定义交付过程，KubeVela 在应用程序模型中添加了 Workflow，其中 WorkflowStepDefinition 利用 CUE 定义原子执行单。

Pic 7. KubeVela provides a consistent, programmable, declarative workflow to orchestrate app delivery process

一些用户可能会遇到多个关联应用程序进行交付的情况，KubeVela 甚至为此提供了更高级别的解决方案，称为 Pipeline。同时，应用程序模型是否应该与交付一起设计，也是一个有争议的问题。像 Tekton、Argo Workflow 这样的独立交付工具已经发展了多年。其他 CI 工具如 Jenkins 或 GitHub Actions 也在不断发展以支持各种交付场景。KubeVela 在将应用程序模型和交付流程结合在一起方面迈出了极为前瞻性的一步，因为它认为这种方法是将应用程序模型投入到生产使用的最佳实践。但是OAM 规范并没有急于添加工作流等内容，因为对于理论建模的答案仍需要更广泛的讨论。

管理

应用程序模型不仅用于交付，声明式 API 面向终态的能力也同样适用。因此，在实践中，应用程序模型也被用于 KubeVela 的一致性对比。KubeVela 确保在交付过程成功完成后不会偏离期望状态，这符合 Kubernetes 的最终面向状态的理念。

Pic 8. KubeVela constantly ensures there’s no configuration drift for the delivered application

此外，KubeVela 还嵌入了许多其他管理操作，包括版本管理、权限控制、资源共享和垃圾回收。目前这些功能不包含在 OAM 规范中，但被认为是未来 OAM 规范的一部分。

总体而言，为了满足在 Kubernetes 上应用程序使用的各种需求，KubeVela 一直在 OAM 规范之外做不断的尝试，并探索更多可能的应用操作方式。

如果您对更多的技术细节感兴趣，请参阅此博客 [ 2] 。

未来

很多人质疑为什么 OAM 的 Github 仓库似乎不活跃了。对于主要关心生产实践和模型使用的人来说，答案是，KubeVela 作为 OAM 的 实现 一直在高速发展，采纳 KubeVela 的用户一直在增加，并且 KubeVela 刚刚成为一个 CNCF 孵化项目，这也意味着 OAM 模型的采纳者一直在快速增加。

至于理论模型，KubeVela 仍在等待来自工业生产实践的更多反馈和证据，我们不希望过快的对规范引入变更导致规范的稳定性出现问题。我们的计划是 KubeVela 的实践被广泛采用并逐渐稳定后，再向 OAM 规范提出其额外附加的概念，如工作流程或策略。我们希望在 CNCF基金会的帮助下越来越多的人能加入社区，使在现代化应用的部署和运维变得更容易、更高效、更可靠。

最后做个预告，在 4 月 17 日至 21 日即将举办的 KubeCon + CloudNativeCon Europe 2023 中，将有三场围绕 KubeVela 的话题分享，欢迎大家提前锁定，了解 KubeVela 最新的技术升级、社区动态和企业实践：

（*TimeZone:Europe/Amsterdam)

• Wednesday, April 19 • 15:25 – 16:00 ：Building a Platform Engineering Fabric with the Kube API at Autodesk – Jesse Sanford & Greg Haynes, Autodesk

https://kccnceu2023.sched.com/event/1HyXP/building-a-platform-engineering-fabric-with-the-kube-api-at-autodesk-jesse-sanford-greg-haynes-autodesk

• Thursday, April 20 • 16:30 – 18:00 ：Tutorial: Deploying Cloud-Native Applications Using Kubevela and OAM – Daniel Higuero, Napptive

https://kccnceu2023.sched.com/event/1K8nU/challenges-of-modern-application-delivery-a-retrospection-of-kubevela-highlight-technologies-jianbo-sun-da-yin-alibaba-cloud

• Friday April 21 • 11:00 – 11:35 ：Challenges of Modern Application Delivery: A Retrospection of KubeVela Highlight Technologies – Jianbo Sun & Da Yin, Alibaba Cloud

https://kccnceu2023.sched.com/event/1K8nU/challenges-of-modern-application-delivery-a-retrospection-of-kubevela-highlight-technologies-jianbo-sun-da-yin-alibaba-cloud

英文原文地址：https://www.cncf.io/blog/2023/03/31/kubevela-the-road-to-cloud-native-application-and-platform-engineering/

您可以通过如下材料了解更多关于 KubeVela 以及 OAM 项目的细节：

• 项目代码库：https://github.com/kubevela/kubevela 欢迎 Star/Watch/Fork！
• 项目官方主页与文档：kubevela.io ，从 1.1 版本开始，已提供中文、英文文档，更多语言文档欢迎开发者进行翻译。
• 项目钉钉群：；Slack：CNCF #kubevela Channel
• 加入微信群：请先添加以下 maintainer 微信号，表明进入 KubeVela 用户群：

相关链接：

[1] Open Application Model（OAM）

https://oam.dev/

[2] 此博客

https://kubevela.net/blog/2022/11/29/retro-2022

此处查看 KubeVela 项目官网

前篇《虚拟云网络系列 | Antrea 应用于 VMware 方案功能简介（六）》中，我们以实际画面展示了采用 NSX 搭配基于 Antrea 的 Kubernetes Cluster 内，在 NSX UI 管理界面内可以查看到 K8S 丛集的相关信息，并且可以基于 Namespace / Service / Pod Label 等，将要管理的 Pod 纳入 Antrea 群组。本篇内，同样地我想要以实际的画面与大家展示，在 NSX 内如何配置对应的 K8S 防火墙规则，并且查询相关日志。

在前篇展示内我们建立了一个叫做 dvwa-ns 的群组，把所有在 dvwa-ns namespace 内的 Pods 都加到这个群组内。接下来我们要做的展示如下：

• 在上述群组内的 Pod，可以连往任何地方，但不能连到 9.9.9.9 这个 IP 地址；
• 防火墙规则符合时，可以提供日志记录。

下图是我要实现上面的这个防火墙政策，在 NSX – Security – Policy Management – Distributed Firewall 内输入的规则：

几个重点讨论如下：

1.定义规则前，我们需要建立一个 Policy Section，也就是上图内的 TKGM-Cluster。在 Section 内，必须要特别配置 Applied To 指明这个段落内的包含的所有规则是要运作在哪个 Kubernetes Cluster 上。下面的放大图内可以看到，这个 Section 内的规则是配置到 tkgm-122-tkc03 这个丛集内的（其他的 Kubernetes Cluster 不会接收到此规则）。

2.在段落内的第一条规则（ 3052 号），配置到 dvwa-ns 这个群组上，目的地往 9.9.9.9 的网络流都设定要拒绝（ Reject ）。因此这是一条对应 dvwa-ns 这个群组内的 Pod 上面的egress 规则（对外往指定 IP 地址拒绝）。

3.在段落内的第二条规则（ 3051 号）同样配置到 dvwa-ns 这个群组上，所有的网络流都设定为允许（ Allow ）。因此这是一条对应 dvwa-ns 这个群组内的 Pod 上面的预设规则（所有其他 Traffic 都允许）。

4.在段落内，规则当然是有顺序性的，3052 号规则在上方会先比对，如果没有 match 才会比对到下方的 3051 号规则。

5.在每条规则内最后像是齿轮的图标时，我们可以设定这条规则是否要启用日志，如下图。

6.这样规则就设定完成了，应该很直觉。但大家不知道是否有注意到在规则配置上方，与虚机配置时一样，同样有 ETHERNET – EMERGENCY – INFRASTRUCTURE – ENVIRONMENT – APPLICATION 五个 Catogories。这五个项次和之前我们虚机微分段的概念一样，是有顺序性的，管理者可以依据不同的需求，在各项次内配置对应的规则，优先权是 Ethernet > Emergency > Infrastructure > Environment > Application。举例来说，在 Kubernetes Cluster 内每个 Pod 与服务间的相互连线，都需要查询内部的 DNS，因此若任何 Kubernetes 应用要正常运作，DNS 连线绝对不能阻挡掉。我们需要在 Infrastructure 内设定通用规则，所有 DNS Traffic 都一定要允许通过，如下图所示：

上面的配置完成后，在 NSX 接口右上角按 Publish ，NSX Manager 就会把相关规则派送到对应的 Kubernetes Cluster 内，由 Antrea 接手进行对应的 Antrea Network Policy 设定。

接着我们到受上述安全政策规范，用来展示的这个 Pod 上面。

DVWA 是一个专门用来做渗透测试与 WAF 功能展示的示范应用，利用上面的工具，我们尝试去 ping 9.9.9.9，以及另一个 168.95.1.1 两个 Internet 上的 IP 地址。大家可以看到，往 9.9.9.9 的连线被拒绝了，但往 168.95.1.1 的连线可以正常 ping 通：

可见得防火墙规则有依照上面我们的配置生效。

其次，在规则内我们有要求要启用日志。Antrea 默认会将防火墙日志放在每个 Kubernetes Nodes 内的 /var/log/antrea/networkpolicy/np.log 目录下， Kubernetes 管理者可以用不同的工具将这个 log 导出，送往集中的日志管理系统，比如说 Log Insight。在我们的展示环境内，使用 Fluentbit 套件把 log 送出，在 Log Insight 内可以看到下列的日志。首先我们搜寻往 9.9.9.9 的相关日志，可以看到由 10.61.2.10 往 9.9.9.9 的 ICMP 连线被拒绝：

接着搜寻往 168.95.1.1 的相关日志，可以看到由 10.61.2.10 往 168.95.1.1 的 ICMP 连线允许通过：

前篇我们有谈到 NSX 可以抓取 Kubernetes 里面的相关信息，当然包含 Pod 以及对应的 IP 地址。因此我们可以到 Inventory 内看这个 DVWA pod 的相关信息，很明确地，IP Address 是 10.61.2.10 没有错：

这两篇内我们用实际的画面让大家看到采用 NSX 搭配 Antrea 时，如何在 UI 管理界面内进行群组、安全政策的配置，并且能收集日志。简单的总结，与传统的 Kubernetes Network Policies 比较，采用 NSX + Antrea 的运作方式，能够：

• 以方便的图形化用户管理界面进行防火墙政策配置；
• 具备企业需求的安全日志（ log ）功能；
• 如同标准企业等级防火墙，可以明确配置 deny 规则，也可以依据顺序进行防火墙规则比对；
• 目前虽仅有 L4 防火墙，L7 及 IDPS 相关功能已经在 Antrea 的后续 Roadmap 列表上。

希望能让大家感受到 NSX + Antrea 的威力。下一篇，回到技术层面，我们要讨论一下 Antrea + NSX 的运作架构，并继续讨论安装整合的方法。

内容来源｜公众号：VMware 中国研发中心

本文作者：Colin Jao （饶康立）, VMware 资深技术顾问，主要负责 VMware NSX 产品线，目前致力于网络虚拟化、分布式安全防护技术与新应用递送方案的介绍与推广。

本文介绍了 API 货币化和 APISIX 实现 API 货币化方法。

作者刘维，API7.ai 技术工程师，Apache APISIX Contributor

原文链接

什么是 API 货币化

想象你开发并部署了一个服务，能够搜集你所在城市所有超市的打折和优惠信息，其他的开发者想要使用你的数据，就需要你提供相应的 API， 然后其他开发者通过支付费用获得你的授权，再使用你提供的 API 获取想要的数据，像这样通过 API 的方式将数据的使用转化为金钱就是 API 货币化，API 货币化是使你的服务盈利的一种理想方式。

在决定采用 API 货币化的商业模式后，接下来需要考虑的就是如何计费，可以选择按调用次数计费，或者直接订阅计费，但不管采用哪种计费方式，都需要统计不同用户的 API 调用数量，如果超出数量还需要进行限流限速操作，所以能否识别出用户的身份很关键。但仅仅识别出用户的个人身份还不够，因为往往购买服务的都是企业用户，企业员工在登录企业账号后，需要能够共享同一个计费账号，所以识别出用户所属组织也同样重要。

API 货币化的应用

现实生活中 API 货币化的应用无处不在，例如每个人都要接触的验证码功能，各个云厂商提供的消息队列，文字识别等服务，各个安全厂家提供的 WAF 和内容过滤等服务，这种模式是如此的成功，以至于我们迫切需要一个合适的技术栈来为 API 货币化打下坚实的基础，也就是说我们需要对 API 进行精细的管理。

在管理 API 时，我们需要能够控制谁可以在哪里发布什么，并且要确保发布这些 API 符合组织标准，诸如 URL 模式、命名约定、访问控制规则。并且能让每个业务职能部门独立管理自己的 API，包括对已发布的 API 进行更新或设计改进，执行流量控制、速率限制和安全策略。也需要能够实时观测使用情况、性能及其他指标。

要对 API 进行管理需要引入的工具就是 API 网关，API 网关可以帮助你解决管理 API 过程中遇到的各种问题。作为一个中央代理，API 网关将所有从客户端传入的请求路由到预定的目的地（后端服务），使你的 API 更安全和更容易管理，同时大部分 API 网关支持各种授权和认证协议，能够对 API 进行复杂的权限控制，还有速率限制等诸多功能。

有许多流行的 API 网关开源项目，其中最为引人注目的就是 Apache APISIX 和其替代的企业 SaaS 解决方案 API7 Cloud。

APISIX 的 API 货币化实践

Apache APISIX 不仅支持上面提到的各种功能，还通过其丰富的插件，能够与 Prometheus、OpenTelemetry、Apache Skywalking 等多种可观察性平台进行集成，以进一步增强其分析 API 的能力并获得完整的可视性。同时 Apache APISIX 针对上文提到的识别用户身份，提出了 consumer 的概念。

不同 consumer 对应不同的用户，通过在 consumer 上绑定对应的插件和上游，不同的 consumer 假如请求同一个 API，经用户认证体系识别后，网关服务根据当前请求用户信息，会对应不同的 Plugin 或 Upstream 配置，方便对不同的用户进行管理。

但是仅仅支持 consumer 还不够，针对上文提到的企业用户，需要多个 consumer 共享同一个消费额度，并且如果只能分别管理每个 consumer 的配置，操作就太过繁琐了。因此 APISIX 提出了 consumer group 的概念，有了 consumer group，多个 consumer 就能共享同一套配置和同一个消费配额。

了解了 APISIX 在 API 货币化的实践，下面我们来看看具体的应用。

• 给企业配置限流限速，企业的用户共享同一配置

总结

企业通过 API 货币化将服务和数据转化为收入，要实现 API 货币化需要引入专业的 API 管理工具：API 网关，现在最热门的 API 网关是 APISIX，APISIX 在 API 货币化上有丰富的实践，包括 consumer, consumer group 等概念极大方便了用户对 API 的管理，赋能企业更顺畅的将 API 货币化落地。

关于 API7.ai 与 APISIX

API7.ai（支流科技 ）是一家提供 API 处理和分析的开源基础软件公司，于 2019 年开源了新一代云原生 API 网关 — APISIX 并捐赠给 Apache 软件基金会。此后，API7.ai 一直积极投入支持 Apache APISIX 的开发、维护和社区运营。与千万贡献者、使用者、支持者一起做出世界级的开源项目，是 API7.ai 努力的目标。

Excelize 是 Go 语言编写的用于操作 Office Excel 文档基础库，基于 ECMA-376，ISO/IEC 29500 国际标准。可以使用它来读取、写入由 Microsoft Excel™ 2007 及以上版本创建的电子表格文档。支持 XLAM / XLSM / XLSX / XLTM / XLTX 等多种文档格式，高度兼容带有样式、图片(表)、透视表、切片器等复杂组件的文档，并提供流式读写 API，用于处理包含大规模数据的工作簿。可应用于各类报表平台、云计算、边缘计算等系统。入选 2020 Gopher China – Go 领域明星开源项目(GSP)、2018 年开源中国码云最有价值开源项目 GVP (Gitee Most Valuable Project)，目前已成为 Go 语言最受欢迎的 Excel 文档基础库。

开源代码

GitHub: github.com/xuri/excelize

Gitee: gitee.com/xurime/excelize

中文文档: xuri.me/excelize/zh-hans

2023年4月10日，社区正式发布了 2.7.1 版本，该版本包含了多项新增功能、错误修复和兼容性提升优化。下面是有关该版本更新内容的摘要，完整的更改列表可查看 changelog。

此版本中最显著的变化包括：

兼容性提示

• 移除了  数据类型中的  字段
• 使用  数据类型代替 
• 使用  代替  数据类型中的  字段
• 移除了已导出的数据类型 
• 将数据类型  重命名为 
• 添加图表函数  改为使用  类型枚举值指定图表类型
• 修改了 7 个函数的签名，具体更改详见官方文档中的更新说明