IT瘾工具推荐

亚马逊因 AI 编码工具引发多起故障

Wed, 11 Mar 2026 08:03:54 CST

亚马逊因 AI 编码工具引发多起故障，紧急召开工程师大会

亚马逊电商部门本周二召集大批工程师开会，对近期一连串系统故障进行"深度复盘"——其中多起事故与 AI 编码工具直接相关。

据英国《金融时报》看到的内部备忘录，亚马逊近几个月出现了"事故趋势"，特征包括"高爆炸半径"（即波及面广）以及"生成式 AI 辅助的代码变更"。备忘录明确将"尚未建立完善最佳实践和安全防护的新型 GenAI 用法"列为事故的诱因之一。

具体来说，亚马逊网站和购物 App 本月曾宕机近 6 小时，用户无法完成交易、查看账户和价格。另外，AWS 旗下的 Kiro AI 编码工具在去年 12 月造成了一次长达 13 小时的服务中断——起因是工程师让 AI 工具执行某些变更，结果 AI 自行决定"删除并重建整个环境"。

作为应对，亚马逊已要求初级和中级工程师在提交任何 AI 辅助的代码变更前，必须获得资深工程师的签字批准。

值得注意的是，这些故障发生的背景是亚马逊近年来的多轮裁员——今年 1 月刚裁掉 1.6 万个企业岗位。此前已有多名工程师向《金融时报》反映，裁员导致每天需要紧急处理的高优先级事故（内部称"Sev2"）数量明显增加，但亚马逊否认裁员与故障频发有关。

这可能是整个行业的一个预警信号：当企业大规模推广 AI 编码工具、同时又在削减人手时，代码质量和系统稳定性的风险正在累积。

来源：www.ft.com/content/7cab4ec7-4712-4137-b602-119a44f771de

NotebookLM：我目前最常用、也最愿意推荐的 AI 学习与内容组织工具

Mon, 17 Nov 2025 16:44:45 CST

NotebookLM 是我迄今用过最贴合知识工作者需求的 AI 工具，它真正帮我把庞杂信息结构化，极大提升了学习和内容创作效率。

作为一个长期学习主义者、读技术规范、研究开源项目的人，我一直在寻找一种工具，能在我面对海量资料时替我“抄近道”、减少机械性阅读、帮我快速建立全局理解。 NotebookLM 是过去一年里我用下来体验最顺滑、也最稳定可靠的一个。

它不是传统意义上的“聊天式 AI 工具”，更像是一个能把你的资料吃进去、组织出来、再以各种结构化方式呈现给你的 AI 原生学习与内容组织系统。越用越觉得，它对我学习新技术、理解陌生领域、整理大项目文档、构建教学材料的帮助，是其他通用大语言模型（LLM, Large Language Model）给不了的。

NotebookLM 给我带来的核心价值

NotebookLM 在实际使用中为我带来了多方面的提升，尤其是在学习新技术、整理文档和内容创作方面表现突出。

快速理解陌生技术：把庞杂资料丢进去，它帮我生成“可学的版本”

我最常用、也是最离不开的场景，就是 学习一个我完全不熟悉的技术或开发框架。面对几十页甚至几百页的文档，我通常的做法是：

把官方文档、README、设计文档、架构草图全部加入一个 Notebook
让 NotebookLM 帮我生成：
- 学习指南
- 简报
- 关键知识点
- FAQ
- Quiz
最终得到一个结构清晰的“学习入口”，而不是一场资料洪水。

下面这张流程图展示了 NotebookLM 如何将复杂文档压缩为可学习的结构：

图 1: NotebookLM 文档结构化流程

最终我获得的是一个“整理好的知识体系”，而不是一堆等我啃的 PDF。

生成 MindMap：大量文档瞬间变成结构化知识图谱

我很依赖 MindMap 来构建“知识的骨架”。NotebookLM 的 MindMap 最大的优势有：

自动识别主题间的关联
可以交互式展开或折叠节点
支持多来源文档综合生成

虽然目前只能导出 PNG，但逻辑结构本身已经是非常好的“知识压缩”。

下表对比了不同工具的自动生成能力和可视化效果：

工具	自动生成能力	多文档整合	可视化质量	导出格式
NotebookLM	强	强	好	仅 PNG（暂不支持 SVG）
常见 LLM 工具	较弱	较弱	弱	视工具而定
思维导图软件（手工）	无	无	强	全支持

表 1: 主流工具 MindMap 能力对比

NotebookLM 最大的优势是 自动性。

生成教学大纲、培训稿、图书结构：真正节约我大量时间

NotebookLM 不只是“总结”，它能按我给的提示词帮我生成 正式的教学结构。只要把项目文档、API 说明、架构设计、案例、视频、博客全都丢进去，让它按提示词生成：

教学大纲
项目培训手册
课程结构
图书章节架构
幻灯片文本
培训案例说明

对于需要写内容、做培训、做演讲的大部分人而言，这个功能非常省心。

下面是我真实在用的典型提示词示例：

   根据提供的内容摘录，编写一份详细的培训手册，系统地阐述通过提供内容中所涉及的核心原则。手册应采用专业和指导性的语气，将复杂的概念分解为可行的步骤和课程。确保内容完全基于源材料，涵盖从所提供内容涉及的所有方面。

培训手册应包括以下内容：
1. 培训目标和预期成果
2. 培训内容和结构
3. 培训方法和工具
4. 培训评估和反馈
5. 培训总结和后续行动
6. 培训案例和实例
7. 培训资源和参考文献

实际效果往往出奇地好。

多格式输入能力：这是我见过最稳的

NotebookLM 支持直接 ingest 各种资料类型，解析能力非常稳定。下表是我的实际体验总结：

输入类型	我的实际使用体验
PDF	最稳，解析结构清晰
Google Docs	更新即同步，非常顺滑
Word / PPT	可正常识别
YouTube 视频	自动总结 + 提取关键内容，很好用
网站 URL	视网站结构，成功率高
纯文本	没问题
图片	部分成功，但足够应对截图内容

表 2: NotebookLM 多格式输入体验

相比之下，其他工具经常出现格式解析问题、乱码、丢内容、跳段落的问题。NotebookLM 在“多格式 ingest”这一点上体验特别稳定。

我目前最常用的 NotebookLM 工作流

下面这张流程图展示了我每天实际使用 NotebookLM 的工作流：

图 2: NotebookLM 日常工作流

其本质就是：让 AI 先帮我抓全局 → 再帮我深入 → 再帮我输出内容。

我遇到的小遗憾与建议

NotebookLM 已经很好用，但我仍有一些强烈期待的改进方向：

MindMap 的导出格式应该支持 SVG 或基于文本（Markmap）

目前只能 PNG，放大容易糊。下表是我对未来功能的期待：

期待功能	用途
SVG 导出	用于写书、做幻灯片、可放大不失真
Markmap 输出	对写 Markdown 的开发者最友好
原始 JSON	允许自行做二次渲染

表 3: MindMap 导出格式期待

我非常期待 NotebookLM 支持 Markmap 格式导出，这对习惯用 Markdown 写博客和文档的用户来说极为友好。

最近 Google 还推出了类似 DeepWiki 的 CodeWiki ，可为 GitHub 项目自动生成带图片的 Wiki，但目前也未支持 Mermaid 或 Markmap。

对话记录应该支持长期保存

现在的体验是：

聊天不会持续保存
只有手动“加入笔记”才能留存结果

这导致一些知识背景容易丢失，期待未来推出“Notebook 对话历史”功能。

幻灯片生产能力如果能支持模板，会更适合作为创作者工具

目前 Video Overview 的视觉风格虽然多，但无法：

上传自己的 PPT 模板
套用企业/个人品牌模版

如果未来能开放 PPT 模板能力，NotebookLM 会直接成为内容创作者的“视频生成中枢”。

Deep Research 早日上线并全面开放

我特别期待这个功能，因为它可能会让 NotebookLM 从“知识整理工具”升级为“研究级工具”。期待它能做到：

稳定地抓取更多公开网页
保证引用质量
能和 Notebook 原有资料结合

这是我个人非常关注的大升级。

移动端希望尽快增强，而不是只提供播放内容

当前移动端体验极简，只能：

听音频
查看 Notebook Guide 的摘要
简单的问答

期待移动端早日支持：

编辑 Notebook
深度对话
MindMap 交互
内容输出能力（生成文档、大纲等）

总结

NotebookLM 是我目前真正意义上“每天都在用”的 AI 工具之一，因为它做到了一件关键的事情：

把信息组织好，把知识结构化，让我不用从零开始面对庞杂文档。

无论是：

学习新技术
阅读长文档
做课程
做培训
写书
做演讲稿
做内容总结

它都能在最前期帮我节省大量时间，把注意力集中在“理解”和“创作”本身。

我会继续把 NotebookLM 作为我的重要工具之一，也会在未来继续观察它的 Deep Research、模板系统与移动端的进展。

这是一款真正贴近“知识工作者”需求的工具，也值得被更多人认识。

网络安全专家爱用的逆向工具 Top9

Tue, 17 Dec 2024 15:13:47 CST

逆向工程是指解构应用程序的过程，不论使用何种编程语言开发，目的是获得其源代码或其中的任何部分。逆向工程的代码有助于发现任何程序中的安全风险，也能用于解密任何恶意应用以进行干扰。

在寻找破解敏感数据或加密密钥的过程中，黑客们通常选择逆向工程作为一种选项，以找出整个系统中隐藏漏洞的所在之处。这导致了敏感数据的完全暴露，包括被硬编码到应用程序中的 API 密钥、 URL 和API 机密信息，开发人员用于测试的开发服务器 URL，非标准端口号，以及硬编码到应用程序文件及其子目录中的多个私钥等。

逆向工程涉及一系列步骤，包括数据编译、记录元素和功能、评估数据、记录控制流、提取流结构、审查提取的设计、生成逆向工程文档。

从实时跟踪运行的应用程序，解析二进制代码到汇编代码，管理和编辑二进制文件或嵌入式资源在 exe 文件中，逆向工具有各种各样的类型，根据其应用可以分为以下几类：

反汇编器
调试器
数据包跟踪和分析工具
脚本工具
文件分析工具

以下分享

1.十六进制编辑器

十六进制编辑器是一组用于微软 Windows 的十六进制开发工具，结合了高级的二进制编辑和字处理器的简洁易用性和多功能性。它主要用于操纵构成计算机文件的基本二进制数据。

此外，十六进制编辑器还支持查找、替换、比较、计算校验和、添加智能标签、颜色映射，并在一个扇区或文件中生成字符分布。十六进制编辑器还支持拖放功能，并可与所有的 Windows 操作系统集成，无论其迭代版本如何。

根据其不同的功能和应用，有各种不同类型的十六进制编辑器，有些允许它们以可视化方式显示文件的内部结构。因此，您可能需要在最常用的工作空间中进行快速简单的十六进制编辑。

数据检视器非常适合解释、查看和编辑十进制和二进制值。算术、逻辑、 ASCII 过程和位操作可用于帮助操作数据集。

集成结构查看器使您能够直观而充分地编辑和查看数据。结构查看器验证信息结构、对各种网络的引用，以及许多原子数据类型：char 、byte 、ubyte 、word 、uword 、long 、ulong 、longlong 、float 、double 、OLE 日期/时间、 DOSTIME 、DOSDATE 、FILETIME 和time_t 。

优点：

进行任何十六进制计算时非常方便
提供多种选项

缺点：

用户友好度不太高
有时更新问题

2.OllyDbg

OllyDbg 是一个针对 Microsoft Windows 的32 位汇编调试器。任何无法获得源代码的情况下，二进制代码的计算认知使得它在许多情况下都非常适用。此外，OllyDbg 是共享软件应用程序,可以下载使用。

OllyDbg 的一些关键特性如下：

1.保存补丁以在会话之间返回到可执行文件并进行修补升级

2.查找对象和库模式

3.代码分析——跟踪记录、查找过程切换、 API 调用、表和循环常量和字符串

4.DNow 、MMX 和为 Athlon 等SSE 数据类型和扩展提供指令

5.识别高级配置，如对事件的请求

6.用于执行的跟踪系统，日志已知可用于调和冲突

7.查找错误命令和掩盖关键字

8.检查和修改内存，设置断点并在不可见的情况下暂停应用程序

9.在会话之间输入标记，将它们还原到可执行文件并修复更新

优点：

共享软件，免费使用
功能强大的动态调试器
相对于 IDA 来说更容易操作
允许直接加载和调试 DLL
有脚本和插件可用

缺点：

仅限于 Microsoft® Windows®
只适用于 x86（或 32 位）软件
不是静态调试器

3.APKTool

Apktool 是另一种开源选择，主要用于 Android 逆向工程，可以将资源解码为几乎其原始形式。可以进行修改，并将其转换回二进制 APK/JAR 文件。

此外，Apktool 还允许逐步调试 smali 代码，并且由于项目文件的结构以及对一些重复性操作的自动化，使得处理应用程序变得更加容易。使用该程序需要 Java 7 。

优点：

在逆向 Android 应用文件方面高效
可在网上免费使用
社区支持良好

缺点：

不如 JEB 反编译工具普遍

4.WireShark

Wireshark 是一个知名的网络和网络领域的工具。它是免费和开源的，是一个 Web 调试器，可以拦截和修改 HTTP 请求，并且可以记录 HTTPS 请求。它用于数据包分析和网络故障排除。

优点：

免费且开源的 Web 调试器
支持跨平台

缺点：

对于初学者来说，可能会感到压力山大

5.Scylla

Scylla 不是一个独立的工具，而更倾向于用于重构 Windows 的x86 和x64 文件的工具。它还具有全 Unicode 支持，并且与 Windows 7 、8 和10 完全兼容。

优点：

一个开源的产品
支持 x64 和x86

缺点：

缺乏更新
有时会有错误

6.Dex2jar

Dex2jar 是一个 API，用于扫描 Dalvik Executable（.dex/.odex）格式。它与 Android 和Java .class 文件兼容。

Dex2jar 包括以下几个组件：

Dex-reader 用于扫描 Dalvik Executable（.dex/.odex）格式。它具有类似 ASM 的轻量级 API
Dex-translator 用于执行转换工作。它读取 dex 指令以 dex-or 格式，经过一些优化后，转换为 ASM 格式
Dex-用于它使用 Dex-translator 表示 dex 指令
Dex-tools 用于处理.class 文件

示例：修改应用程序、解混淆一个.jar 文件。

优点：

可以读取 Dalvik Executable 格式
轻量级 API

缺点：

只与 Android 和Java .class 文件兼容

7.CCF

CCF 是一个免费的便携式可执行编辑器，支持.NET 文件结构。 CCF 支持 32 位和 64 位PE 文件。 CCF 由NTCore 开发，还可用于解压缩 UPX 打包器。

优点：

免费的 PE 编辑器
也支持.NET 文件
支持 PE 32 位和 64 位
包含 PE 重建器
可用于解压缩 UPX

缺点：

免费版本自 2012 年以来未更新

8.Oracle VM VirtualBox

Oracle VM VirtualBox 是一个开源的虚拟化解决方案，在 Windows 、Mac 、Linux 等不同平台上皆可使用，用于在安全环境中分析恶意软件。

优点：

免费且开源
活跃的开发社区
支持虚拟机操作系统

缺点：

与 VMware 相比，功能略差

9.BinaryNinja

目前没有反编译器，但计划在将来的“高级”版本中加入。 Binary Ninja 由Vector 35 开发，以其易用性而自豪，使得自动化比其他解决方案更容易理解。

尽管易于使用，但该软件在反向工程本地主机中仍然存在一些问题。

优点：

简单易用
包含反汇编器

缺点：

不是调试器或反编译器
有时无法加载用户界面
免费版本有限

参考来源： https://www.secureblink.com/blogs/top-9-reverse-engineering-hacking-tools-for-cyber-security-experts

开源实时数据同步工具NiFi

Sat, 09 Nov 2024 21:04:10 CST

Apache NiFi简介

Apache NiFi 是一个强大的数据流管理和自动化工具，旨在简化数据的采集、传输、处理和分发。它特别适合于构建和管理复杂的数据流管道，支持从各种数据源到不同目标系统的数据传输。

Apache NiFi主要功能

Apache NiFi 是一个用于自动化数据流的强大工具，具有广泛的功能集，旨在支持从各种数据源到不同目标的复杂数据流管道。以下是 Apache NiFi 的主要功能：

数据采集与传输：
- 支持从多种数据源采集数据，包括文件系统、数据库、HTTP 服务、消息队列（如 Kafka）、传感器设备等。
- 支持将数据传输到多种目标系统，如 HDFS、数据库、云存储服务、REST API 等。
数据流可视化：
- 提供直观的 Web 用户界面，用户可以通过拖拽和配置处理器来设计和管理数据流。
- 实时显示数据流的状态和性能指标，便于监控和调试。
数据处理与转换：
- 提供丰富的内置处理器，支持数据的解析、转换、清洗、聚合和格式化等操作。
- 支持复杂的数据处理逻辑，如条件路由、数据分片、合并和拆分。
动态路由与优先级控制：
- 支持根据数据内容或属性动态路由数据到不同的处理器或目标。
- 允许为数据流设置优先级，以控制数据处理的顺序和速度。
实时流处理：
- 支持实时数据流处理，能够在数据到达时立即执行处理操作。
- 事件驱动架构，处理器在接收到数据或触发条件时自动执行。
分布式架构与扩展性：
- 支持多节点集群部署，可以水平扩展以处理大规模数据流。
- 集群中的节点通过 Apache ZooKeeper 进行协调和管理。
数据安全与合规：
- 支持数据加密、访问控制和用户身份验证，确保数据的安全性。
- 提供数据审计功能，记录数据流的处理历史和用户操作。
错误处理与重试机制：
- 自动处理数据传输和处理过程中出现的错误，支持重试和故障转移。
- 提供数据回退和恢复功能，确保数据的可靠性和完整性。
可扩展性与集成性：
- 支持自定义处理器和控制器服务的开发，用户可以根据需要扩展 NiFi 的功能。
- 与其他大数据工具和框架（如 Apache Kafka、Hadoop、Spark）紧密集成，支持复杂的数据处理和分析工作流。
监控与管理：
- 提供详细的日志记录和监控功能，帮助用户了解数据流的执行状态和性能指标。
- 支持告警和通知机制，用户可以根据特定条件设置告警，及时响应异常情况。

Apache NiFi 的设计目标是提供一个灵活、高效且易于管理的数据流管理平台，适用于各种数据集成和处理场景。其丰富的功能集使其成为企业数据管道构建和管理的理想选择。

Apache NiFi的优势

灵活性：通过丰富的处理器和自定义开发能力，NiFi 可以适应各种复杂的数据处理需求。
可扩展性：支持多节点集群部署，可以水平扩展以处理大规模数据流。
可视化管理：提供直观的 Web UI，用户可以轻松设计和管理数据流，无需编写复杂的代码。
高可用性：通过故障转移和数据重试机制，确保数据流的高可用性和可靠性。
安全性：支持数据加密、访问控制和审计，确保数据的安全性和隐私保护。

Apache NiFi的架构

Apache NiFi 的架构设计旨在提供一个灵活、高效且可扩展的数据流管理平台。它采用模块化设计，支持分布式部署，能够处理各种规模和复杂度的数据流任务。

核心组件

Web UI（用户界面）：NiFi 提供了一个直观的 Web 用户界面，用于设计、监控和管理数据流。用户可以通过拖拽和配置组件来构建数据流，并实时查看数据流的状态和性能指标。
FlowFile：FlowFile 是 NiFi 中的数据单元，包含数据内容和属性。每个 FlowFile 都有唯一标识符和元数据，支持数据的高效传输和处理。
处理器（Processor）：处理器是执行特定数据处理任务的基本单元。NiFi 提供了丰富的内置处理器，用于数据采集、转换、路由和传输。用户还可以开发自定义处理器以满足特定需求。
连接（Connection）：连接用于在处理器之间传递 FlowFile。连接可以配置为使用不同的队列策略，以控制数据的流动速度和优先级。
流程组（Process Group）：流程组用于组织和管理多个处理器和连接，形成逻辑上的子流程。这有助于复杂数据流的模块化设计和维护。
控制器服务（Controller Service）：控制器服务提供共享的配置和服务，例如数据库连接池、分布式缓存等。它们可以在多个处理器之间复用，提高资源利用率。
报告任务（Reporting Task）：报告任务用于生成和发送 NiFi 系统的运行状态和指标数据，通常用于监控和告警系统。

工作流和数据流

数据采集与处理：
- 数据流从输入处理器开始，输入处理器从外部数据源（如文件系统、HTTP、Kafka）获取数据并生成 FlowFile。
- 中间处理器对 FlowFile 进行处理，包括数据解析、转换、过滤和聚合等操作。
数据路由与分发：
- 根据业务规则和条件，NiFi 可以将 FlowFile 路由到不同的处理器或流程组。
- 输出处理器将处理后的 FlowFile 发送到目标系统（如 HDFS、数据库、云存储）。
实时监控与管理：
- Web UI 提供实时数据流监控功能，用户可以查看处理器的性能指标、队列长度、处理速率等。
- 用户可以动态调整数据流的配置和参数，以优化性能和处理逻辑。

分布式架构

多节点集群：
- NiFi 支持多节点集群部署，可以通过增加节点来扩展处理能力。集群中的每个节点都可以执行数据流任务。
- 集群节点通过 Apache ZooKeeper 进行协调和管理，以确保任务的负载均衡和高可用性。
高可用性与故障转移：
- NiFi 采用主从架构，集群中一个节点为主节点（Primary Node），负责调度任务和管理集群配置。
- 在主节点故障时，集群会自动选举新的主节点，确保数据流的持续性和可靠性。

安全性

用户认证与授权：
- 支持多种认证机制（如 LDAP、Kerberos），确保只有授权用户才能访问和管理 NiFi 系统。
- 提供细粒度的权限控制，用户可以对不同的数据流组件和操作进行授权。
数据加密：
- 支持数据传输加密和存储加密，确保数据在传输和存储过程中的安全性。
审计与日志：
- 提供详细的审计日志记录，记录用户操作和数据流处理历史，便于合规性检查和故障排查。

Apache NiFi 的架构设计使其成为一个灵活、可扩展和安全的数据流管理平台，适用于各种规模和复杂度的数据集成和处理任务。其模块化设计和丰富的功能集使得用户能够高效地构建和管理复杂的数据流管道。

Airflow、Kafka的对比

Apache NiFi、Apache Airflow 和 Apache Kafka 都是现代数据处理和管理生态系统中的重要工具，但它们各自的设计目的和应用场景有所不同。以下是它们的详细对比：

特性	Apache NiFi	Apache Airflow	Apache Kafka
主要用途	实时数据流管理和自动化	工作流调度和管理	消息队列和流处理
架构特点	可视化界面，事件驱动架构	编程接口定义工作流（DAGs），基于调度器和执行器	发布/订阅模型，分布式架构
数据处理	实时数据采集、转换和路由	批处理任务调度，不直接处理数据流	高吞吐量的消息传输，支持实时流处理
扩展性与部署	多节点集群，水平扩展	分布式调度和执行，支持多种执行器	水平扩展，通过分区和副本实现容错
安全性	细粒度权限控制和数据加密	用户认证和授权（RBAC）	SSL 加密、SASL 认证和 ACL 授权
应用场景	实时数据集成、物联网数据采集、日志管理和监控	定时数据处理任务、复杂的 ETL 管道、机器学习工作流	实时数据传输、日志收集和分析、事件驱动架构

对比总结

实时 vs 批处理：
- NiFi：适合实时数据流处理和自动化。
- Airflow：适合批处理任务调度和复杂的工作流管理。
- Kafka：适合高吞吐量的消息传输和实时流处理。
用户界面 vs 编程接口：
- NiFi：提供可视化界面，适合需要快速构建和管理数据流的场景。
- Airflow：提供编程接口，适合需要灵活定义复杂工作流的场景。
- Kafka：主要通过编程接口和命令行工具进行管理和配置。
数据流管理 vs 工作流调度 vs 消息队列：
- NiFi：专注于数据流的管理和处理。
- Airflow：专注于任务调度和工作流管理。
- Kafka：专注于消息队列和流处理。

根据具体的需求和场景，企业可以选择合适的工具或组合使用这些工具来构建复杂的数据处理和管理生态系统。例如，可以使用 NiFi 进行数据采集和预处理，使用 Kafka 进行高吞吐量的消息传输，使用 Airflow 进行批处理任务的调度和管理。

将 Android 手机变成监听工具

Tue, 15 Oct 2024 23:48:56 CST

之前的实验表明，智能手机中的陀螺仪和加速计等惯性测量单元（IMU），可以通过检测声波振动监听对话。这意味着，即使是一个没有开启麦克风权限的应用程序也可以通过 IMU 获得对话内容。为了不让攻击者获得准确信息，Google 将 Android 应用从 IMU 采样数据的频率限制在每秒 200 次，使攻击者无法准确获得对话内容。根据发表在预印本平台 arXiv 上的预印本，研究人员发现了一个漏洞——通过欺骗陀螺仪和运动传感器在时间上稍微偏移地进行测量，将应用实际采样率从每秒 200 次提高到 400 次，可以突破上述保护措施。利用这种方法，攻击者能修复获得的音频量大大提升。与每秒仅采集 200 个样本相比，他们的方法在 AI 转录时单词错误率降低了 83%。这表明，目前的安全保护措施“不足以防止复杂的窃听攻击发生”，应该对其重新评估。

Python地理数据分析工具MovingPandas

Wed, 09 Oct 2024 19:54:20 CST

MovingPandas 是一个用于分析轨迹数据的 Python 库。它在处理和分析移动对象的时空数据方面非常强大，适用于地理信息系统（GIS）、时空数据分析和可视化等领域。它是在热门的地理数据处理库 GeoPandas 的基础上构建的，GeoPandas 本身是建立在Pandas数据处理库之上的。MovingPandas 旨在提供高效、易于使用的工具，以便分析和处理包含位置信息的时间序列数据。MovingPandas使得研究移动模式、路径分析、时空聚类等任务变得更加高效和直观。

核心功能：

轨迹数据表示。MovingPandas 使用 GeoPandas GeoDataFrames 来表示轨迹数据。每条轨迹由一系列带有时间戳的点组成，形成一条时空路径。
轨迹分割。可以根据时间间隔、距离阈值等条件将轨迹分割成多个子轨迹。这对于处理长轨迹或者在某些关键事件发生前后进行分析非常有用。
轨迹特征提取。提供了多种方法来计算轨迹的特征，比如速度、加速度、方向变化等。这些特征在进行模式识别和行为分析时非常有用。
轨迹聚类。支持基于轨迹的聚类分析，可以识别出类似移动模式的轨迹群体。常用的聚类方法包括基于密度的聚类（DBSCAN）、分层聚类等。
轨迹可视化。通过与 Matplotlib 和 Folium 等库的集成，MovingPandas 能够提供强大的轨迹数据可视化功能，包括静态和交互式地图。
时空聚合。支持时空聚合分析，比如计算某个区域在特定时间段内的平均速度、轨迹数量等。

MovingPandas的使用

MovingPandas的安装

MovingPandas作者推荐在Python 3.7及以上环境下安装。请确保你的Python版本符合这一要求。如果你已经安装了Anaconda，可以使用conda命令来安装MovingPandas及其依赖包。

conda install -c conda-forge movingpandas

MovingPandas同样可以使用pip进行安装，但是不推荐，主要原因是其依赖环境较为复杂，使用pip安装可能会出现依赖项缺失或版本冲突的问题。因此，推荐使用conda进行安装。

MovingPandas接口详解

MovingPandas.Trajectory对象

在 MovingPandas 中，Trajectory 类是核心组件之一，主要用于表示和处理单个轨迹。Trajectory 对象是一个时间序列的集合，其中每个数据点代表轨迹上的一个位置，包含了位置信息（经纬度或其他地理空间参考）、时间戳和其他可能的属性（如速度、方向等）。因此，一个 Trajectory 对象是连续移动的点组成的线，这些点按照时间顺序排列。

Trajectory 对象的主要特性：

时间索引：Trajectory 对象的索引通常是时间戳，这使得基于时间的查询和操作变得直观和高效。
空间位置：每个时间点对应一个空间位置，这通常是通过经纬度坐标表示的。
其他属性：除了时间和位置，还可以包含其他相关的数据列，如速度、加速度、方向等，这些信息对于分析移动行为至关重要。

创建 Trajectory 对象通常涉及几个步骤，首先你可能需要有一个包含时空数据的pandas DataFrame。这个DataFrame应该至少包含三列：表示时间戳的列（通常会被设置为索引）、表示X坐标的列（如经度）、表示Y坐标的列（如纬度）。然后，你可以使用 MovingPandas 提供的函数或方法（如TrajectoryCollection.from_geodataframe()）来创建一个或多个 Trajectory 对象。

class movingpandas.Trajectory(df, traj_id, traj_id_col=None, obj_id=None, t=None, x=None, y=None, crs=’epsg:4326′, parent=None)

参数说明：

df：具有GeoPandas的geometry坐标列和时间戳索引的GeoDataFrame，或Pandas的DataFrame。必填参数。
traj_id：任意类型，表示轨迹的唯一标识符。必填参数。
obj_id：任意类型，表示移动物体的唯一标识符。默认为 None。
t：表示包含时间戳的列名，默认为 None。
x：表示包含x坐标的列名，使用Pandas的DataFrame需指定。默认为 None。
y：表示包含y坐标的列名，使用Pandas的DataFrame需指定。默认为 None。
crs：表示 x/y 坐标的坐标参考系统。默认为 “epsg:4326″，即 WGS84。
parent：一个Trajectory 对象，表示父轨迹。默认为 None。

基本信息与操作

copy(): 返回轨迹对象的一个副本。
drop(**kwargs) 方法用于从数据集中删除满足特定条件的行或列。
plot(self, *args, **kwargs): 绘制轨迹。
explore(*args, **kwargs) 方法用于以交互方式可视化和分析数据，支持多种参数和选项以定制显示。
is_latlon() 方法用于判断轨迹数据是否采用经纬度坐标系。
is_valid() 方法用于检查轨迹数据是否有效，例如是否包含必要的字段和合理的坐标。
size() 方法用于返回轨迹中包含的定位点数量。
get_crs() 方法用于获取当前地理数据集的坐标参考系统（CRS），返回一个描述该坐标系的对象或信息。
to_crs(self, crs): 转换轨迹的坐标参考系统。
get_column_names() 方法用于获取数据集中的所有列名，返回一个包含列名的列表。这个方法通常用于快速查看数据集的结构或在进行数据处理时动态获取列名。
get_direction_col() 方法用于获取表示方向数据的列，这些数据通常以角度或方位形式存储。
get_distance_col() 方法用于获取表示距离数据的列，这些数据通常用于计算或分析两点之间的距离。
get_speed_col() 方法用于获取表示对象速度的列名。
get_timedelta_col() 方法用于获取表示时间增量的列名。
get_traj_id_col() 方法用于获取表示轨迹标识符的列名。
get_geom_col() 方法用于获取表示几何数据的列，该列通常包含地理空间信息，如点、线或多边形。
get_angular_difference_col() 方法用于获取包含角度差异的列，这些差异通常用于分析方向或角度变化。
to_point_gdf(self): 返回包含轨迹点的GeoDataFrame。
to_line_gdf(columns=None) 方法用于将轨迹数据转换为 GeoDataFrame 格式的线条几何数据，可以选择包含特定的列。
to_linestring() 方法用于将轨迹数据转换为 LineString 对象，表示轨迹的线条几何形状。
to_linestringm_wkt() 方法用于将轨迹数据转换为包含 ZM（高程和度量）信息的 WKT（Well-Known Text）格式的 LineStringM 字符串。
to_mf_json(datetime_to_str=True, temporal_columns=None) 方法用于将轨迹数据转换为 Moving Features JSON 格式，可以选择将日期时间转换为字符串，并指定时间相关的列。
to_point_gdf(return_orig_tz=False) 方法将轨迹数据转换为 GeoDataFrame 格式的点几何数据，可以选择返回原始时区的时间。
to_traj_gdf(wkt=False, agg=False) 方法将轨迹数据转换为 GeoDataFrame 格式，可以选择生成 WKT 格式的几何数据或进行聚合处理。

轨迹分析与聚合统计

get_bbox(self): 返回轨迹的范围 (bounding box)。
get_start_location(self): 返回轨迹的起始位置。
get_end_location(self): 返回轨迹的结束位置。
get_start_time() 方法用于获取时间序列数据或对象轨迹的起始时间。
get_end_time() 方法用于获取某个事件或过程的结束时间，通常返回一个时间戳或日期时间对象。
get_max(column) 方法用于获取指定列 column 中的最大值。
get_min(column) 方法用于获取指定列 column 中的最小值。
get_position_at(t, method=’interpolated’) 方法用于获取在时间点 t 处的对象位置，默认使用插值方法来计算位置。
get_row_at(t, method=’nearest’) 方法用于获取在时间点 t 附近的对象所在的行，默认使用最近邻方法来选择行。
get_length(units=(None, None, None, None)) 方法用于计算并获取几何对象的长度，可以接受多个单位参数来指定长度的测量单位。
get_mcp() 方法用于获取某个对象的最小凸包 (Minimum Convex Polygon, MCP)，通常用于地理空间分析中确定一组点的最小包围区域。
add_direction(self, overwrite=False): 计算并添加方向信息到轨迹数据中。
get_direction() 方法用于计算和获取两个地理点之间的方向或方位角，通常以度数表示。
get_duration(self): 返回轨迹的总时长。
add_distance(overwrite=False, name=’distance’, units=None)：计算并添加轨迹数据中相邻点之间的距离信息。
add_acceleration(self, overwrite=False, name=’acceleration’): 计算并添加加速度信息到轨迹数据中。
add_speed(self, overwrite=False): 计算并添加速度信息到轨迹数据中。
add_angular_difference(overwrite=False, name=’angular_difference’)：计算并添加轨迹中相邻点之间的角度差异信息到轨迹数据中。
add_timedelta(overwrite=False, name=’timedelta’) ：计算并添加轨迹数据中相邻点之间的时间差信息。
add_traj_id(overwrite=False) 方法用于为轨迹数据添加或覆盖轨迹ID列，以标识相同轨迹中的所有点。
get_segment_between(t1, t2) 方法用于获取在时间点 t1 和 t2 之间的对象轨迹或数据段。
get_linestring_between(t1, t2, method=’interpolated’) 方法用于生成并获取在时间点 t1 和 t2 之间的一条线串，默认使用插值方法。
get_sampling_interval() 方法用于获取时间序列数据中的采样时间间隔。
hausdorff_distance(other, units=(None, None, None, None)) 方法用于计算当前轨迹与另一个轨迹之间的Hausdorff距离，并允许指定单位。
hvplot(*args, **kwargs) 方法用于使用hvPlot库创建高度可定制的图形和可视化。
hvplot_pts(*args, **kwargs) 方法用于使用hvPlot库对地理点数据进行可视化并创建交互式图形。
interpolate_position_at(t) 方法用于在给定时间 t 处插值并返回轨迹的位置。
intersection(feature, point_based=False) 方法用于计算轨迹与给定地理特征的交集，并可以选择基于点的方式进行计算。
intersects(polygon) 方法用于判断轨迹是否与指定的多边形区域相交。
clip(self, polygon): 按多边形裁剪轨迹。
apply_offset_minutes(column, offset) 方法用于将指定列的时间值按给定的分钟数进行偏移调整。
apply_offset_seconds(column, offset) 方法用于将指定列的时间值按给定的秒数进行偏移调整。

MovingPandas.TrajectoryCollection对象

TrajectoryCollection 类是 MovingPandas 中用于表示多条轨迹的集合。它允许用户以集合的形式操作多条轨迹，支持对这些轨迹的批量处理和分析。

可以通过传递一系列 Trajectory 对象来创建一个 TrajectoryCollection。每个 Trajectory 对象代表一条轨迹，包含了时间和位置的信息。

class movingpandas.TrajectoryCollection(data, traj_id_col=None, obj_id_col=None, t=None, x=None, y=None, crs=’epsg:4326′, min_length=0, min_duration=None)

参数说明：

data (list[Trajectory] 或 GeoDataFrame 或 DataFrame) – 包含 Trajectory 对象的列表，或一个包含轨迹 ID、点几何列和时间戳索引的 GeoDataFrame。
traj_id_col (string) – 包含轨迹 ID 的 GeoDataFrame 列名。
obj_id_col (string) – 包含移动对象 ID 的 GeoDataFrame 列名。
t (string) – 包含时间戳的 DataFrame 列名。
x (string) – 包含 x 坐标的 DataFrame 列名。
y (string) – 包含 y 坐标的 DataFrame 列名。
crs (string) – x/y 坐标的坐标参考系 (CRS)。
min_length (numeric) – 期望的轨迹最小长度。长度使用 CRS 单位计算，若 CRS 是地理坐标系（例如 EPSG:4326 WGS84），则长度以米为单位计算。（较短的轨迹将被丢弃。）
min_duration (timedelta) – 期望的轨迹最短持续时间。（较短的轨迹将被丢弃。）

相比MovingPandas.Trajectory多了一些方法：

filter(predicate): 根据给定条件过滤轨迹集合。

MovingPandas.TrajectoryCollectionAggregator对象

MovingPandas.TrajectoryCollectionAggregator 是 MovingPandas 库中的一个类，主要用于对轨迹集合进行聚合操作。通过对轨迹数据进行空间和时间上的聚合，可以帮助用户有效地分析和总结移动模式。

class movingpandas.TrajectoryCollectionAggregator(traj_collection, max_distance, min_distance, min_stop_duration, min_angle=45)

参数说明

traj_collection (TrajectoryCollection) – 要进行聚合的 TrajectoryCollection 对象。
max_distance (float) – 重要点之间的最大距离（距离使用 CRS 单位计算，若 CRS 是地理坐标系，例如 EPSG:4326 WGS84，则距离以米为单位计算）。
min_distance (float) – 重要点之间的最小距离。
min_stop_duration (datetime.timedelta) – 停止检测所需的最短持续时间。
min_angle (float) – 提取重要点的最小角度。

MovingPandas.TrajectoryCleaner对象

MovingPandas.TrajectoryCleaner 是 MovingPandas 库中的一个类，专门用于清理轨迹数据。清理操作可以帮助去除数据中的噪声、填补缺失值以及进行其他预处理步骤，确保轨迹数据的质量和一致性。

IqrCleaner(traj) 是一个类，用于基于四分位数范围 (IQR) 方法来清理轨迹数据中的异常值。
OutlierCleaner(traj) 是一个类，用于通过多种方法识别和清理轨迹数据中的离群点（异常值）。

MovingPandas.TrajectoryGeneralizer对象

MovingPandas.TrajectoryGeneralizer 是 MovingPandas 库中的一个类，用于对轨迹数据进行简化和概括。通过轨迹数据的概括，可以减少数据量，提高处理效率，并且在某些应用场景下有助于更清晰地展示轨迹特征。

TrajectoryGeneralizer(traj) 是一个类，用于通过多种算法对轨迹数据进行简化和概括，以减少数据量并提高处理效率。
DouglasPeuckerGeneralizer(traj) 是一个类，专门使用 Douglas-Peucker 算法对轨迹数据进行简化，保留主要特征点以减少数据量。
MinDistanceGeneralizer(traj) 是一个类，用于根据最小距离间隔对轨迹数据进行简化，移除距离变化小于指定阈值的点。
MinTimeDeltaGeneralizer(traj) 是一个类，用于根据最小时间间隔对轨迹数据进行简化，移除时间间隔小于指定阈值的点。
TopDownTimeRatioGeneralizer(traj) 是一个类，用于通过时间比率算法对轨迹数据进行简化，保留关键时间点以减少数据量。

MovingPandas.TrajectorySmoother对象

MovingPandas.TrajectorySmoother 是一个类，用于对轨迹数据进行平滑处理。轨迹平滑通常是为了减少由于数据采集误差和噪声导致的轨迹抖动和异常点，从而得到更加平滑和准确的轨迹线条。

KalmanSmootherCV(traj) 是一个类，用于使用常速模型（Constant Velocity Model）的卡尔曼滤波算法对轨迹数据进行平滑处理，以减少噪声和抖动。

MovingPandas.TrajectorySplitter对象

MovingPandas.TrajectorySplitter 是一个类，用于将轨迹数据根据特定条件进行分割。这在处理长时间、多段的轨迹数据时特别有用，比如在分析车辆行驶路径、运动员运动轨迹或动物迁徙路径时，可以根据特定的规则将连续的轨迹分割成多个部分，以便进行更细致的分析。

TrajectorySplitter(traj) 是一个类，用于根据指定的条件（如距离、时间或速度）对轨迹数据进行分割，生成多个段以便更细致的分析。
TemporalSplitter(traj) 是一个类，用于根据时间间隔对轨迹数据进行分割，将轨迹分成多个时间段以便更细致的时间序列分析。
ObservationGapSplitter(traj) 是一个类，用于根据观测数据中的时间间隙对轨迹进行分割，当连续观测点之间的时间间隔超过指定阈值时，将轨迹分割成多个部分。
SpeedSplitter(traj) 是一个类，用于根据速度阈值对轨迹数据进行分割，当轨迹点的速度超过指定阈值时，将轨迹分割成多个部分。
StopSplitter(traj) 是一个类，用于根据停留点（长时间停留的点）对轨迹数据进行分割，将轨迹分成移动段和停留段以便更细致的分析。

MovingPandas.TrajectoryStopDetector对象

TrajectoryStopDetector 通过分析轨迹点的时空属性来识别停留点。它会检查一个轨迹对象中的每个点，并根据设定的阈值参数（如最小速度、最小停留时间和最小停留距离等）来鉴定轨迹中是否存在停留段。

class movingpandas.TrajectoryStopDetector(traj, n_threads=1)

方法介绍：

get_stop_points(max_diameter, min_duration) 是 TrajectoryStopDetector 类中的方法，用于根据最大停留直径和最小持续时间来识别和提取轨迹数据中的停留点，并返回包含这些停留点的 GeoDataFrame。
get_stop_segments(max_diameter, min_duration) 是 TrajectoryStopDetector 类中的方法，用于根据最大停留直径和最小持续时间来识别和提取轨迹中的停留段，并返回包含这些停留段的列表。
get_stop_time_ranges(max_diameter, min_duration) 是 TrajectoryStopDetector 类中的方法，用于根据最大停留直径和最小持续时间来识别停留时间范围，并返回停留时间段的列表。

MovingPandas使用实例

准备工作

加载需要的库

import pandas as pd
import geopandas as gpd
import movingpandas as mpd
from datetime import datetime, timedelta
import matplotlib.pyplot as plt
import folium
import bokeh.io
bokeh.io.output_notebook()
from holoviews import opts
opts.defaults(opts.Overlay(active_tools=["wheel_zoom"], frame_width=500, frame_height=400))

加载数据

df = pd.read_excel("driver_log.xlsx")

# 将DataFrame 转换为 GeoDataFrame
gdf = gpd.GeoDataFrame(df, geometry=gpd.points_from_xy(df.lon, df.lat), crs='EPSG:4326')

# 将GeoDataFrame转化为TrajectoryCollection对象
tc = mpd.TrajectoryCollection(gdf, traj_id_col='session_id', obj_id_col = 'driver_no', t='log_time')
# 过滤某个司机的轨迹
df['driver_no'].value_counts()
df['driver_no'].value_counts().plot(kind='bar', figsize=(15,3))
driver_tc = tc.filter('driver_no', 'DR202407021504081000000')

# 展示司机轨迹
driver_tc.plot()

# 获取单个轨迹
my_traj = driver_tc.trajectories[0]

# 展示单个轨迹
traj_plot = my_traj.hvplot(title="Trajectory {}".format(my_traj.id),line_width=7.0, tiles="CartoLight", color="slategray")
traj_plot

停留点检测

针对单轨迹停留点检测

detector = mpd.TrajectoryStopDetector(my_traj)
## 检测停留的时间（这里检测5分钟位移100米以内）
stop_time_ranges = detector.get_stop_time_ranges(min_duration=timedelta(seconds=300), max_diameter=100)
## 检测停留的时间
for stop_time in stop_time_ranges:
    print(stop_time)
## 检测停留点
stop_points = detector.get_stop_points(min_duration=timedelta(seconds=300), max_diameter=100)
stop_points
## 展示停留点
stop_point_plot = traj_plot * stop_points.hvplot(geo=True, size="duration_s", color="deeppink")
stop_point_plot

## 停留点信息
stop_points_gdf = gpd.GeoDataFrame(stop_points, geometry="geometry", crs="EPSG:4326")
stop_points_gdf
## 使用folium展示停留点
# m = my_traj.explore(color="blue",style_kwds={"weight": 4},name="Trajectory")
# stop_points_gdf.explore(m=m,color="red",style_kwds={"style_function": lambda x: {"radius": x["properties"]["duration_s"] / 10 }},name="Stop points")
# folium.TileLayer("OpenStreetMap").add_to(m)
# folium.LayerControl().add_to(m)
# m
## 停留轨迹
stop_segments = detector.get_stop_segments(min_duration=timedelta(seconds=60), max_diameter=100)
stop_segments.to_traj_gdf()
## 停留轨迹
stop_segment_plot = stop_point_plot * stop_segments.hvplot(line_width=7.0, tiles=None, color="orange")
stop_segment_plot

## 使用folium绘图
# m = my_traj.explore(
#     color="blue",
#     popup=True,
#     style_kwds={"weight": 4},
#     name="Trajectory",
# )

# stop_segments.explore(
#     m=m,
#     color="orange",
#     popup=True,
#     style_kwds={"weight": 4},
#     name="Stop segments",
# )

# stop_points_gdf.explore(
#     m=m,
#     color="red",
#     tooltip="stop_id",
#     popup=True,
#     marker_kwds={"radius": 3},
#     name="Stop points",
# )

# folium.TileLayer("CartoDB positron").add_to(m)
# folium.LayerControl().add_to(m)

# m

## 行驶线路
split = mpd.StopSplitter(my_traj).split(min_duration=timedelta(seconds=300), max_diameter=100)
split.to_traj_gdf()
## 可视化行驶线路
split.explore(column="session_id", tiles="CartoDB positron", style_kwds={"weight": 4})

## 整体可视化
stop_segment_plot + split.hvplot(title="Trajectory {} split at stops".format(my_traj.id),line_width=7.0,tiles="CartoLight")

轨迹合集的经停点检测

## 停留点检测
detector = mpd.TrajectoryStopDetector(driver_tc)
stop_points = detector.get_stop_points(min_duration=timedelta(seconds=300), max_diameter=100)
stop_points
## 停留点可视化
ax = driver_tc.plot(figsize=(7, 7))
stop_points.plot(ax=ax, color="red")

## 使用folium可视化
## 使用方folium可视化
# m = driver_tc.explore(
#     column="session_id",
#     popup=True,
#     style_kwds={"weight": 4},
#     name="Trajectories",
# )

# stop_points.explore(
#     m=m,
#     color="red",
#     tooltip="stop_id",
#     popup=True,
#     marker_kwds={"radius": 5},
#     name="Stop points",
# )

# folium.TileLayer("CartoDB positron").add_to(m)
# folium.LayerControl().add_to(m)

# m

速度计算

## 单轨迹增加速度
my_traj.add_speed(overwrite=True,units=("km", "h"))
my_traj.df.head()

## 展示速度
my_traj.plot(column="speed", linewidth=5, capstyle='round', legend=True)
# my_traj.hvplot(c='speed', clim=(0,20), line_width=7.0, tiles='CartoLight', cmap='Viridis', colorbar=True)

## 添加方向
my_traj.add_direction(overwrite=True)
my_traj.df.head()

## 添加时差
my_traj.add_timedelta(overwrite=True)
my_traj.df.head()

## 添加距离
my_traj.add_distance(overwrite=True, name="distance (km)", units="m")
my_traj.df.head()

## 添加加速度
my_traj.add_acceleration(overwrite=True, name="acceleration (mph/s)", units=("mi", "h", "s"))
my_traj.df.head()

## 轨迹集增加速度
driver_tc.add_speed(overwrite=True,units=("km", "h"))
driver_tc.plot(column='speed', linewidth=5, capstyle='round', legend=True, vmax=20)

提取位置

## 获取起点与终点
ax = my_traj.plot()
gpd.GeoSeries(my_traj.get_start_location()).plot(ax=ax, color='blue')
gpd.GeoSeries(my_traj.get_end_location()).plot(ax=ax, color='red')

## 获取特定时间点的位置
t = datetime(2024,7,3,9,30,0)
print(my_traj.get_position_at(t, method="nearest"))
print(my_traj.get_position_at(t, method="interpolated"))
print(my_traj.get_position_at(t, method="ffill")) # from the previous row
print(my_traj.get_position_at(t, method="bfill")) # from the following row

point = my_traj.get_position_at(t, method="interpolated")
ax = my_traj.plot()
gpd.GeoSeries(point).plot(ax=ax, color='red', markersize=100)

## 获取特定时间区间的位置
segment = my_traj.get_segment_between(datetime(2024,7,3,9,10,0), datetime(2024,7,3,9,30,0))
print(segment)
ax = my_traj.plot()
segment.plot(ax=ax, color='red', linewidth=5)

## 获取特定区域内的轨迹
from shapely.geometry import Polygon

xmin, xmax, ymin, ymax = 104.135, 104.137, 30.642, 30.643
polygon = Polygon([(xmin, ymin), (xmin, ymax), (xmax, ymax), (xmax, ymin), (xmin, ymin)])
intersections = my_traj.clip(polygon)
ax = my_traj.plot()
gpd.GeoSeries(polygon).plot(ax=ax, color='lightgray')
intersections.plot(ax=ax, color='red', linewidth=5, capstyle='round')

导出轨迹

## 返回 GeoDataFrame
driver_tc.to_point_gdf()
driver_tc.to_line_gdf()
driver_tc.to_traj_gdf(wkt=True) # 生成wkt格式的聚合

# 聚合数据
driver_tc.add_speed(overwrite=True,units=("km", "h"))
driver_tc.to_traj_gdf(agg={'speed':['min', 'max','mode']})

# 导出数据
export_gdf = driver_tc.to_traj_gdf(agg={'speed':['min', 'max','mode']})
export_gdf.to_file("temp.gpkg", layer='trajectories', driver="GPKG")
gpd.read_file('temp.gpkg').plot()

轨迹分割

## 数据准备
my_traj.add_speed(overwrite=True,units=("km", "h"))
my_traj.plot(column='speed', vmax=20, linewidth=5, capstyle='round', figsize=(9,3), legend=True )

## 根据观测数据中的时间间隙对轨迹进行分割
split = mpd.ObservationGapSplitter(my_traj).split(gap=timedelta(minutes=1))
split.to_traj_gdf()
fig, axes = plt.subplots(nrows=1, ncols=len(split), figsize=(19,4))
for i, traj in enumerate(split):
    traj.plot(ax=axes[i], linewidth=5.0, capstyle='round', column='speed', vmax=20)

## 根据停留点（长时间停留的点）对轨迹数据进行分割
split = mpd.StopSplitter(my_traj).split(max_diameter=10, min_duration=timedelta(minutes=1), min_length=20)
split.to_traj_gdf()
fig, axes = plt.subplots(nrows=1, ncols=len(split), figsize=(19,4))
for i, traj in enumerate(split):
    traj.plot(ax=axes[i], linewidth=5.0, capstyle='round', column='speed', vmax=20)

## 根据速度阈值对轨迹数据进行分割
split = mpd.SpeedSplitter(my_traj).split(speed=0, duration=timedelta(minutes=1))
split.to_traj_gdf()
fig, axes = plt.subplots(nrows=1, ncols=len(split), figsize=(19,4))
for i, traj in enumerate(split):
    traj.plot(ax=axes[i], linewidth=5.0, capstyle='round', column='speed', vmax=20)

轨迹抽稀

## 展示原始轨迹
plot_defaults = {'linewidth':5, 'capstyle':'round', 'figsize':(9,3), 'legend':True}
my_traj.add_speed(overwrite=True,units=("km", "h"))
my_traj.plot(column='speed', vmax=20, **plot_defaults)

## 使用 Douglas-Peucker 算法对轨迹数据进行简化
dp_generalized  = mpd.DouglasPeuckerGeneralizer(my_traj).generalize(tolerance=0.0001)
dp_generalized.plot(column='speed', vmax=20, **plot_defaults)

print('Original length: %s'%(my_traj.get_length()))
print('Generalized length: %s'%(dp_generalized.get_length()))

## 根据最小时间间隔对轨迹数据进行简化
time_generalized = mpd.MinTimeDeltaGeneralizer(my_traj).generalize(tolerance=timedelta(minutes=3))
time_generalized.plot(column='speed', vmax=20, **plot_defaults)

## 通过时间比率算法对轨迹数据进行简化
tdtr_generalized = mpd.TopDownTimeRatioGeneralizer(my_traj).generalize(tolerance=0.001)
fig, axes = plt.subplots(nrows=1, ncols=2, figsize=(19,4))
tdtr_generalized.plot(ax=axes[0], column='speed', vmax=20, **plot_defaults)
dp_generalized.plot(ax=axes[1], column='speed', vmax=20, **plot_defaults)

fig, axes = plt.subplots(nrows=1, ncols=2, figsize=(19,4))
tdtr_generalized.plot(ax=axes[0], column='speed', vmax=20, **plot_defaults)
time_generalized.plot(ax=axes[1], column='speed', vmax=20, **plot_defaults)

平滑轨迹

split = mpd.ObservationGapSplitter(my_traj).split(gap=timedelta(minutes=1))
smooth = mpd.KalmanSmootherCV(split).smooth(process_noise_std=0.1, measurement_noise_std=10)
hvplot_defaults = {'tiles':'CartoLight', 'frame_height':320, 'frame_width':320, 'cmap':'Viridis', 'colorbar':True}
kwargs = {**hvplot_defaults, 'line_width':4}
(split.hvplot(title='Original Trajectories', **kwargs) +  smooth.hvplot(title='Smooth Trajectories', **kwargs))

kwargs = {**hvplot_defaults, 'c':'speed', 'line_width':7, 'clim':(0,20)}
(split.trajectories[1].hvplot(title='Original Trajectory', **kwargs) + smooth.trajectories[1].hvplot(title='Smooth Trajectory', **kwargs))

traj = split.trajectories[1]

cleaned = traj.copy()
cleaned = mpd.OutlierCleaner(cleaned).clean(alpha=2)

smoothed = mpd.KalmanSmootherCV(cleaned).smooth(process_noise_std=0.1, measurement_noise_std=10)
    
(traj.hvplot(title='Original Trajectory', **kwargs) + 
 cleaned.hvplot(title='Cleaned Trajectory', **kwargs) + 
 smoothed.hvplot(title='Cleaned & Smoothed Trajectory', **kwargs))

轨迹聚类和分类

## 查看数据
driver_tc.explore(column="session_id", cmap="plasma", style_kwds={"weight": 4})
## 根据最小距离间隔对轨迹数据进行简化
generalized = mpd.MinDistanceGeneralizer(driver_tc).generalize(tolerance=100)
generalized.to_traj_gdf()

## 对轨迹进行聚合操作
aggregator = mpd.TrajectoryCollectionAggregator(
    generalized,
    max_distance=1000,
    min_distance=100,
    min_stop_duration=timedelta(minutes=10),
)

## 提取显著点
pts = aggregator.get_significant_points_gdf()
pts.hvplot(geo=True, tiles="OSM")

## 获取聚合轨迹的簇
clusters = aggregator.get_clusters_gdf()
(pts.hvplot(geo=True, tiles="OSM") * clusters.hvplot(geo=True, color="red"))

## 使用folium绘制
# m = pts.explore(marker_kwds={"radius": 3}, name="Significant points")
# clusters.explore(m=m, color="red", marker_kwds={"radius": 3}, name="Cluster centroids")
# folium.TileLayer("CartoDB positron").add_to(m)
# folium.LayerControl().add_to(m)
# m

## 获取聚合后的轨迹数据的流动
flows = aggregator.get_flows_gdf()
(flows.hvplot(geo=True, hover_cols=["weight"], line_width=dim("weight") * 7, color="#1f77b3",tiles="CartoLight") * clusters.hvplot(geo=True, color="red", size=dim("n")))

## 使用Folium绘制
# m = flows.explore(style_kwds={"weight": 5},name="Flows")
# clusters.explore( m=m,color="red",style_kwds={"style_function": lambda x: {"radius": x["properties"]["n"]}}, name="Clusters")
# folium.TileLayer("OpenStreetMap").add_to(m)
# folium.LayerControl().add_to(m)
# m

距离计算

## 选择2个轨迹
my_traj = driver_tc.trajectories[3]
toy_traj = driver_tc.trajectories[1]
## 呈现数据
ax = my_traj.plot()
toy_traj.plot(ax=ax, color='red')

## 计算记录
print(f'Distance: {toy_traj.distance(my_traj)} meters') # 返回最短距离
print(f'Hausdorff distance: {toy_traj.hausdorff_distance(my_traj):.2f} meters') # 返回Hausdorff距离

Hausdorff距离可以理解为：对于集合A 中的每个点，计算它到集合B的最近距离，然后在这些距离中找到最大值；反过来对于集合 B 中的每个点，计算它到集合A 的最近距离，然后在这些距离中找到最大值。Hausdorff距离是这两个最大值中的较大者。

参考链接：

开源可视化报表工具：Superset

Thu, 04 Jan 2024 12:54:55 CST

Superset简介

Superset 是一个开源的数据可视化和数据探索平台，最初由 Airbnb 开发，后来成为了 Apache 软件基金会的顶级项目。它支持各种类型的数据源，如数据库和 SQL 引擎，并提供了一个易于使用的界面来创建和共享仪表板和图表。

主要特点包括：

数据可视化: Superset 提供了丰富的图表库，支持从简单的折线图和条形图到更复杂的地理信息系统 (GIS) 可视化等。
数据探索: 用户可以通过 Superset 的 SQL 编辑器执行查询，探索数据，并将结果可视化。
仪表板: 可以将多个图表组合成仪表板，为数据分析提供全面视图。
安全性和权限管理: Superset 支持细粒度的访问控制，允许管理员定义用户和角色，控制对数据和功能的访问。
易于集成: 作为一个开源工具，Superset 可以与多种数据源和其他数据工具集成。
自定义和扩展: 用户可以根据需要自定义图表和界面，并且可以开发新的可视化插件。

Superset 适用于数据分析师和开发人员，帮助他们快速有效地探索和可视化数据，从而做出更好的数据驱动决策。

看板示例：

拖拽式看板编辑器：

SQL编辑器：

Superset架构

Apache Superset 是一款开源的数据可视化和数据探索平台，它的架构设计允许用户轻松地进行数据分析并创建交互式的仪表板。Superset的架构主要由以下几个核心组件构成：

Web服务器

Flask：Superset使用Flask作为其Web框架，处理HTTP请求和渲染界面。
Gunicorn：在生产环境中，通常使用Gunicorn作为WSGI HTTP服务器来运行Flask应用。

SQL查询引擎

SQLAlchemy：Superset通过SQLAlchemy与数据源进行交互，它支持多种数据库。
Pandas：在某些情况下，Superset会使用Pandas库来处理数据。

数据库

元数据数据库：存储Superset的配置信息、仪表板定义、数据源定义等。
缓存数据库：用于缓存数据，提高查询性能。Redis和Memcached是常用的选项。

前端

React & JavaScript：Superset的前端主要使用React框架结合JavaScript开发，用于实现用户界面的交互和动态展示。
js：图表的渲染利用了D3.js库，提供丰富的可视化选项。

安全性

认证与授权：Superset提供灵活的认证选项（如LDAP、OAuth、数据库等）和基于角色的访问控制（RBAC）。
数据安全：支持数据级别的安全控制，确保用户只能访问授权的数据。

扩展性

插件系统：Superset支持自定义插件，允许用户扩展新的可视化类型或其他功能。
API：提供REST API，支持与其他系统的集成。

任务调度器

Celery：用于执行后台任务，如异步查询和发送报告。

Superset功能扩展

拓展Apache Superset主要涉及添加新的可视化类型、增强现有功能、集成更多数据源等方面。

开发自定义可视化插件

Superset支持通过插件机制添加新的图表和可视化类型。
可以使用React和JavaScript开发新的可视化组件。
开发完成后，将插件包含在Superset的配置中，使其成为可用的可视化类型。

集成更多数据源

Superset通过SQLAlchemy与数据源进行交互，可以添加对新数据库的支持。
通过添加相应的数据库驱动和SQLAlchemy方言，可以实现新的数据库支持。

增强现有功能

对Superset的源代码进行修改，可以增强或改变现有功能。
包括改进用户界面、增加新的数据处理功能、优化性能等。

使用API进行集成

Superset提供了REST API，可以用来与其他系统集成。
例如，可以通过API自动化仪表板的创建、更新数据源等。

安全性和认证的定制

可以定制Superset的安全性和认证机制，如集成企业的单点登录（SSO）系统。
修改认证流程以支持LDAP、OAuth等。

使用和配置Celery任务调度器

使用Celery来优化和管理后台任务，如数据刷新、报告发送等。
可以定制Celery的配置以满足特定的性能和规模需求。

参考链接：

你的Spring Boot应用启动很慢？不妨试试这个工具！

Sat, 22 Jul 2023 18:03:35 CST

睡不着闲逛，在GitHub上看到一个不错的开源项目： Spring Startup Analyzer。

从项目名称中就大概能猜到，这是一个分析Spring应用启动过程的工具。Spring Startup Analyzer通过采集Spring应用启动过程的数据，进而生成一个交互式的分析报告，帮助用户发现Spring应用启动慢的位置。同时，Spring Startup Analyzer还提供了Spring Bean异步初始化的工具，来帮助开发者加快Spring应用的启动时间。

下面一起来看看其提供的强大功能。

分析能力

我们可以先从该项目中给出HTML样例报告（点击这里查看）来看看它所提供的分析功能。

把报告内容的细节部分都收起来，可以看到如下图所示的内容：

主要有六个部分：

启动的统计数据。其中包括：启动时间、Bean的数量、使用/总共的JAR包数量、未使用/总共的JAR包数量、ClassLoader数量

Spring Bean初始化数据。这里采集了每个Spring Bean的初始化时间及其细节内容

Bean初始化时间线。通过时间线的方式，清晰地展现了Spring应用启动时候，各个Bean的顺序关系以及时间消耗

方法调用的详细信息。这里统计了每个方法的调用时间、总时间开销和每次调用的平均时间

点开之后，还能看到具体每次调用时候的时间开销和一些调用细节：

启动后未使用的JAR。列出了所有Spring应用启动后没有使用的jar包，可以有效的帮助你清理不需要的依赖，为应用瘦身

应用启动过程的线程火焰图

如何使用

通过上面的介绍，相信你已经了解该工具的强大之处了。接下来就可以通过下面的方法尝试分析一下自己的应用吧：

第一步：从里面的链接中下载最新的安装包

https://github.com/linyimin0812/spring-startup-analyzer/tags

第二步：解压下载的安装包，记住解压后的路径，下面一步要用

第三步：编辑Spring Boot的启动参数，包括：

该工具采用agent的方式启动，所以要添加参数 -javaagent:$HOME/spring-startup-analyzer/lib/spring-profiler-agent.jar，这里 $HOME代表以前的解压路径，记得根据上面解压后的路径编辑这个参数
配置分析工具的参数，这里根据自己需要添加即可，比如可以配置超时时间30分钟： -Dspring-startup-analyzer.app.health.check.timeout=30，其他可配置项如下表，你可以工具自己应用的情况去修改：

第四步：查看该工具的日志，可以通过 $HOME/spring-startup-analyzer/logs路径，这里 $HOME代表以前的解压路径，日志文件的类别为：

startup.log: 启动过程中的日志
transform.log: 被re-transform的类/方法信息

另外，该工具还支持自定义扩展，这里DD没试过，就不具体介绍了。感兴趣的童鞋可以根据文档去试试。

启动优化

这里提到了一个启动加速的优化思路，就是把一些耗时的Bean初始化改成异步就能实现。该项目提供了Bean的异步初始化工具，也非常好用，只需要下面几步就能完成。

第一步：引入依赖

<dependency>     
    <groupId>io.github.linyimin0812</groupId>     
    <artifactId>spring-async-bean-starter</artifactId>     
    <version>2.0.2</version>     
</dependency>

第二步：配置参数

# 异步化的Bean可能在Spring Bean初始化顺序的末尾，导致异步优化效果不佳，打开配置优先加载异步化的Bean     
spring-startup-analyzer.boost.spring.async.bean-priority-load-enable=true     
# 指定异步的Bean名称     
spring-startup-analyzer.boost.spring.async.bean-names=testBean,testComponent     
# 执行异步化Bean初始化方法线程池的核心线程数     
spring-startup-analyzer.boost.spring.async.init-bean-thread-pool-core-size=8     
# 执行异步化Bean初始化方法线程池的最大线程数     
spring-startup-analyzer.boost.spring.async.init-bean-thread-pool-max-size=8

第三步：检查Bean是否异步初始化。查看日志$HOME/spring-startup-analyzer/logs/startup.log文件，对于异步执行初始化的方法，会按照以下格式写一条日志:

async-init-bean, beanName: ${beanName}, async init method: ${initMethodName}

但是，作者在文档中也提到了，异步并不是万能的，你还需要注意以下这几点：

应该优先从代码层面优化初始化时间长的Bean，从根本上解决Bean初始化耗时长问题
对于二方包/三方包中初始化耗时长的Bean(无法进行代码优化)再考虑Bean的异步化
对于不被依赖的Bean可以放心进行异步化，可以通过各个Bean加载耗时中的Root Bean判断Bean是否被其他Bean依赖
对于被依赖的Bean需要小心分析，在应用启动过程中不能其他Bean被调用，否则可能会存在问题

好了，今天的学习就到这里！如果您学习过程中如遇困难？可以加入我们超高质量的 Spring技术交流群，参与交流与讨论，更好的学习与进步！更多 Spring Boot教程可以点击直达！，欢迎收藏与转发支持！

最后，奉上项目地址： https://github.com/linyimin0812/spring-startup-analyzer

自动生成代码工具-cursor(集成ChatGpt)

Fri, 31 Mar 2023 20:11:04 CST

最近体验了一把cursor，自动生成代码工具，集成了最近很火的ChatGpt，目前比较好的就是代码生成工具大概就是 github copilot和 cursor，不过github copilot需要付费使用或者漫长的waitlist，所以目前比较好的是cursor

配置

配置自己经常使用的语言，比如ts、html、css等等

操作

目前来说就两个功能，如下：

ctrl+k：生成代码

描述需要生成的代码功能，回车后会自动帮你生成，比如生成一个斐波那契数列函数

如果对这段代码想做一些编辑操作，比如添加注释，只需选中代码，再次 ctrl+k 回车即可，如下：

生成之后，提供了 Accept All和 Reject All两个功能，类似于【全选/全不选】的功能

Accept All ：添加所有
Reject All ：删除所有

ctrl+l：智能对话

类型于gpt-4的功能，对他提出你的疑惑，他会给出解决方案，不用去百度答案，如下：

当对这段代码不理解时，也可以选中代码，问他实现逻辑或者代码结构等，如下：

注意：从上面对话可以看出来，cursor对于语言不敏感，所以如果想要生成对话呈中文表达，最好前面加上【请用中文】类似于这类词语

用途

cursor的功能目前对于程序员来说，算是简而全的一个代码工具，他支持多种语言，如js、ts、python、rust、go、java等等市面上比较常见的编程语言。他可以根据你的描述自动生成代码，还可以再你接受别人代码是帮助你理解、重构代码，并且可以测试bug、校验格式等等

参考链接

https://cn-sec.com/archives/1614273.html

https://cloud.tencent.com/developer/article/2242409

[分享创造] Vesta: 一个 Docker 和 Kubernetes 配置安全的快速检查工具

Sat, 17 Dec 2022 00:48:36 CST

Vesta 可以做什么

伴随着容器技术的快速发展，容器安全问题也逐渐成为企业所关注的话题，越来越多的公司以及个人开发着选择将他们的服务迁移到云上。目前市面上的容器扫描或容器配置检查的产品大部门都需要进行繁琐的环境配置，同时对机器性能也有着比较高的要求，而开发者或安全测试者或许只是需要扫描少数的镜像或者配置，繁琐的配置和高昂的机器费用对他们来说难以承担，导致安全检查的效率不佳。Vesta 是一款集容器扫描，Docker 和 Kubernetes 配置基线检查于一身的工具。检查内容包括镜像或容器中包含漏洞版本的组件，Docker 以及 Kubernetes 的危险配置。同时也是一个灵活，快速的工具，能够在各种系统上运行，包括但不限于 Windows ，Linux 以及 MacOS

Vesta 为开发者和安全测试者提供了方便、快速的解决方案。整个程序由 golang 编写，只需要使用 go build或者从 releases 下载，无需配置任何环境和数据库，并且在 1 vCPU, 2G Memory 的机器上就可运行，最大化方便使用者们。

项目地址

https://github.com/kvesta/vesta

功能介绍

Vesta 包含两大模块

scan: 扫描容器和镜像的组件信息，检测是否包含 CVE 漏洞版本
analyze: 检查 Docker 和 Kubernetes 配置，是否包含危险配置。后续考虑附加攻击方法

检查列表

Docker 检查

Supported	Check Item	Description	Severity
✔	PrivilegeAllowed	危险的特权模式	critical
✔	Capabilities	危险 capabilities 被设置	critical
✔	Volume Mount	敏感或危险目录被挂载	critical
✔	Docker Unauthorized	2375 端口打开并且未授权	critical
✔	Kernel version	当前内核版本存在逃逸漏洞	critical
✔	Network Module	Net 模式为 `host`模式并且在特定 containerd 版本下	critical
✔	Docker Server version	Docker Server 版本存在漏洞	critical/high/medium/low
✔	Docker env password check	Docker env 是否存在弱密码	high/medium
✔	Image tag check	Image 没有被打 tag 或为默认 latest	low
待定	Container env	检查数据库是否未设置密码, 包括但不限于 `MySQL`, `Redis`, `Memcache`	-
待定	IaC scan	IaC 扫描	-

Kubernetes 检查

Supported	Check Item	Description	Severity
✔	PrivilegeAllowed	危险的特权模式	critical
✔	Capabilities	危险 capabilities 被设置	critical
✔	PV and PVC	PV 被挂载到敏感目录并且状态为 active	critical/medium
✔	ClusterRoleBinding	默认账户被赋予了权限	high/medium
✔	Kubernetes-dashborad	检查 `-enable-skip-login`以及 dashborad 的账户权限	critical/high/low
✔	Kernel version (k8s versions is less than v1.24)	当前内核版本存在逃逸漏洞	critical
✔	Docker Server version (k8s versions is less than v1.24)	Docker Server 版本存在漏洞	critical/high/medium/low
✔	Kubernetes certification expiration	证书到期时间小于 30 天	medium
✔	ConfigMap and Secret check	ConfigMap 或者 Secret 是否存在弱密码	high/medium
✔	Auto Mount ServiceAccount Token	Pod 默认挂载了 `/var/run/secrets/ kubernetes.io/serviceaccount/token`.	low
✔	NoResourceLimits	没有限制资源的使用，例如 CPU,Memory, 存储	low
✔	Job and Cronjob	Job 或 CronJob 没有设置 seccomp 或 seLinux 安全策略	low
待定	CVE-2022-29179	检测 CVE-2022-29179 是否存在	critical
待定	Envoy admin	Envoy admin 被配置以及监听 `0.0.0.0`.	-
待定	Kubelet 10255 and Kubectl proxy	10255 port 打开或 Kubectl proxy 开启	-
待定	Trampoline attack	RBAC 权限不安全，容易遭受 Trampoline 攻击	-
待定	IaC scan	Iac 扫描	-

使用样例

检查 k8s 的基础配置

  $./vesta analyze k8s

2022/11/29 23:15:59 Start analysing
2022/11/29 23:15:59 Geting docker server version
2022/11/29 23:15:59 Geting kernel version

Detected 4 vulnerabilities

Pods:
+----+--------------------+------------------------------+-------------------+-----------------------+----------+--------------------------------+
| ID |     POD DETAIL     |            PARAM             |       VALUE       |         TYPE          | SEVERITY |          DESCRIPTION           |
+----+--------------------+------------------------------+-------------------+-----------------------+----------+--------------------------------+
|  1 | Name: vulntest     | test-volume                  | /etc              | Directory             | critical | Mounting '/etc' is suffer      |
|    | Namespace: default |                              |                   |                       |          | vulnerable of container        |
|    |                    |                              |                   |                       |          | escape.                        |
+    +                    +------------------------------+-------------------+-----------------------+----------+--------------------------------+
|    |                    | Privileged                   | true              | Pod                   | critical | There has a potential          |
|    |                    |                              |                   |                       |          | container escape in privileged |
|    |                    |                              |                   |                       |          | module.                        |
+    +                    +------------------------------+-------------------+-----------------------+----------+--------------------------------+
|    |                    | AllowPrivilegeEscalation     | true              | Pod                   | critical | There has a potential          |
|    |                    |                              |                   |                       |          | container escape in privileged |
|    |                    |                              |                   |                       |          | module.                        |
+    +                    +------------------------------+-------------------+-----------------------+----------+--------------------------------+
|    |                    | Resource                     | memory, cpu,      | Pod                   | low      | None of resources is be        |
|    |                    |                              | ephemeral-storage |                       |          | limited.                       |
+----+--------------------+------------------------------+-------------------+-----------------------+----------+--------------------------------+

Configures:
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+
| ID |            TYPEL            |             PARAM              |                         VALUE                          | SEVERITY |          DESCRIPTION           |
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+
|  1 | K8s version less than v1.24 | kernel version                 | 5.10.104-linuxkit                                      | critical | Kernel version is suffering    |
|    |                             |                                |                                                        |          | the CVE-2022-0185 with         |
|    |                             |                                |                                                        |          | CAP_SYS_ADMIN vulnerablility,  |
|    |                             |                                |                                                        |          | has a potential container      |
|    |                             |                                |                                                        |          | escape.                        |
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+
|  2 | ConfigMap                   | data: db.string                | db.string:mysql+pymysql://dbapp:Password123@db:3306/db | high     | ConfigMap has found weak       |
|    |                             |                                |                                                        |          | password: 'Password123'.       |
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+
|  3 | Secret                      | data: password                 | password:Password123                                   | high     | Secret has found weak          |
|    |                             |                                |                                                        |          | password: 'Password123'.       |
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+
|  4 | ClusterRoleBinding          | binding name:                  | verbs:                                                 | high     | Key permission are given to    |
|    |                             | vuln-clusterrolebinding |      | get,watch,list,create,update |                         |          | the default service account    |
|    |                             | rolename: vuln-clusterrole |   | resources: pods,services                               |          | which will cause a potential   |
|    |                             | namespace: default             |                                                        |          | container escape.              |
+----+-----------------------------+--------------------------------+--------------------------------------------------------+----------+--------------------------------+

展望

Vesta 希望能够最大化方便开发者们排查日常配置中的一些基线安全问题，并且也希望云上环境更加安全

黑客或者从事安全领域工作的人用metasploit、Nessus这些工具用的多吗？ - 知乎

Thu, 15 Dec 2022 09:48:57 CST

可耻地匿了。

作为一个世界500强的金融企业，我们对于漏洞自查这块，完全依赖于商业版Findstone，在买这个以前，自查都用的免费版Nessus。上面反映的威胁，中、高、高危一律限期整改，结束。

我们会自己写脚本来加固标装OS，会聘请军工来对自己进行透渗试测，会优化基线并推行，但是不会自己写工具实现自己的需求。因为领导相信：员工只需要做我安排的任务就可以了，这种专业的事情还是买来的好。(╯‵□′)╯︵┻━┻不止一个项目，我们私底下都说这大几百万你给我一半就行我保证给你办好绝对实现你的需求，但是领导不干啊，即使只考虑法律保障道德风险也就决定了领导还是只会去买厂商的整体解决方案不会交给我们耍的。

各位不管你们搞攻击的还是搞安全的机会都大大的啊。。。除了漏洞这块至少还有十几个领域，任一个领域做到了与世界水平相近，你们的机会就很大了，因为很多企事业单位不让用国外产品，或者在条件相同的情况下喜欢国内的二次开发，你看我都不提价格优势。。。

市面上有哪些安全漏洞扫描工具？ - 知乎

Thu, 15 Dec 2022 09:44:55 CST

AWVS、Nessus、AppScan、Goby、NetSparker、Xray等等一系列

如果细分的话应当区分web漏扫和主机漏扫。

web漏扫：通常需要爬虫爬取网页，先爬取再进行漏洞挖掘。
主机漏扫：则通常使用POC脚本扫描服务端口。

web漏扫一般建议使用AWVS配合Xray被动扫描

主机漏扫的话Goby就很不错了

下面分享一下上述软件以及使用的小技巧

AWVS配合Xray被动扫描

最新Acunetix14.6.211215172 支持Log4j检测

xray1.7.1 pro下载使用方法

上面两个软件可以配合使用，这里分享一个实用的批量扫描的脚本

批量扫描脚本分享

链接： https://pan.baidu.com/s/1HFSYtpygYVYo6acqPI0JHw

提取码：mhxv

需要先将批量扫描的网址填写到 url.txt中，按行分开

并设置好 awvs_config.ini中的api_key

" width="937">

需要和awvs中的密钥相同（AWVS后台中右上角的配置文件，打开找到API密钥，点击复制）

" width="1234">

都配置好之后，方可打开脚本，你可以选择直接让AWVS单独扫描，但这样的效果并不是很好。由于最新版本的AWVS与Xray被动扫描不太兼容，因此我们需要指定爬虫模式，然后配合Xray进行被动扫描

" width="622">

记住还要设置好代理的端口

然后运行xray，进行被动扫描并输出结果

        xray_windows_amd64.exe  webscan --listen 0.0.0.0:1111 --html-output scan-output.html

AppScan扫描

如果你不太习惯于使用面板类的应用，你可以选择使用HCL AppScan Standard

下载地址： HCL AppScan Standard v10.0.6.28111最新版

运行起来，输入好域名就可以扫描了。

新版的GUI界面，属实感觉颜值爆表（中间的框估计还没改，后面应该会优化）

测试版GUI界面进入方式：

C:\Program Files (x86)\HCL\AppScan Standard下运行 AppScanGui.exe

" width="1569">

NetSparker

与之类似的还有NetSparker，这里也是提供软件下载地址：

最新Netsparker6.2.0.33156-下载

" width="1289"> " width="1548">

Goby

Goby这里直接去官网下载就好了

Goby - 帮企业梳理资产暴露攻击面

如果你是做红队的，可以申请红队版本，里面POC还是蛮多的。

Nessus

最后是分享Nessus，其实很多公司的二次开发都是基于Nessus里的nasl脚本插件，这里我们分享了最新版本的插件以及Nessus8.15.2软件

Nessus pro8.15.2专业版 10月最新版 pro插件附使用说明

这里简单说一下，如果Nessus占用CPU过高，如何解决？

Nessus插件CPU占用过高问题

如何解决Nessus插件占用CPU过高的问题？

这里推荐使用 CPULimit模块进行限制，当然，如果你在安全公司内部有比较好的服务器，当我没说，跑满它！

CentOS安装CPULimit

        sudo yum install cpulimit

Ubuntu/Debian安装CPULimit

        sudo apt-get install cpulimit

安装好之后，我们可以进行测试，我们先找到nessus进程的pid

        ps aux | grep nessusd

" width="658">

这里看到PID是2544113，我们对其进行限制CPU占用率即可，我们这里设置的是60%

        cpulimit --pid 2544113 --limit 60

当然，你按ctrl+C退出便解除限制了，如果你想要后台运行可以使用 Nohup

        nohup cpulimit --pid 2544113 --limit 60

然后Nessus就老实了，不过这里也仅对于个人CPU不太高的用户，如果是企业，服务器够好，当时是最好的了。

其他的内容后续持续更新，欢迎评论给我留言

并发模拟的四种方式+工具，超级实用！

Mon, 05 Dec 2022 00:00:00 CST

长按关注此公众号，技术干货，及时送达！

一、Postman

Postman是一个款http请求模拟工具

首先演示一下postman最基本的使用

创建一个Springboot项目，测试的代码如下：

   import org.springframework.web.bind.annotation.GetMapping;    
import org.springframework.web.bind.annotation.RequestMapping;    
import org.springframework.web.bind.annotation.RestController;    
    
@RestController    
@RequestMapping("test")    
public class TestConrtoller {    
    
    @GetMapping("demo")    
    public String testDemo() {    
        return "result~";    
    }    
}

为了便于操作，一般会将

http://127.0.0.1:8080 是经常使用的地址+端口号，可以设置为环境

推荐下自己做的 Spring Boot 的实战项目：

https://gitee.com/yoodb/jing-xuan

点击右上角的设置图标

选择global

输入信息

以后再进行测试就能这样搞简写了

知道基本使用之后,我们来看一下如何模拟并发测试

填写基本信息后，创建

这个时候会创建出Concurrency的文件夹，我们可以把刚才测试的demo的例子放进这个文件夹下

这个时候就可以在Concurrency下看到这个接口测试了

选择并发测试：

这个时候弹出我们想要的框了

点击Run Concurrency

你可以立马感觉到CPU在“燃烧”，因为要记录并打印日志，显示的话是一条一条来的，其实测试的速度，要比你看到的打印的日志的速度快，绿色表示正常

二、Apache Bench（AB）

ApacheBench 是 Apache 服务器自带的一个web压力测试工具，简称ab。

ab又是一个命令行工具，对发起负载的本机要求很低，根据ab命令可以创建很多的并发访问线程，模拟多个访问者同时对某一URL地址进行访问，因此可以用来测试目标服务器的负载压力。总的来说ab工具小巧简单，上手学习较快，可以提供需要的基本性能指标，但是没有图形化结果，不能监控。

使用的话，首先需要安装Apache服务器

网站：http://httpd.apache.org/download.cgi

因为我的操作系统是windows10，这里选择File for Microsoft Windows

Linux下的安装是非常简单的，这里不再演示

选择 ApacheHaus

进入下载页面选择适合自己电脑的版本

文件解压到本地文件夹下，如果不是解压在c盘，需要设置参数，注意文件路径最好都是英文

关于需要设置参数，conf->httpd.conf 使用文本编辑器打开，

需要修改的有三个地方：

运行根目录，修改成自己解压到本地的路径

监听端口，默认监听端口是80，如果已被使用会报错需要修改，如果80端口未被使用，可不修改；如果修改了监听端口，则需要把ServerName localhost也相应改成同样的端口号

DocumentRoot 测试文件存放位置，且该目录必须存在

配置完成后，命令行cmd进入D:\softUtil\Apache24\bin目录下

   httpd.exe  -k  install

启动：

   httpd.exe -k start

测试:

-n :请求数
-c: 并发数

三、并发模拟工具JMeter

JMeter也是一款性能测试工具，是图形化的。

下载地址：传送门 http://jmeter.apache.org/

需要Java8+的环境

解压到你觉得合适的目录下（注意最好是英文路径）

进入它的bin目录下启动jmeter.bat即可

使用很简单，首先在测试计划部分新建一个线程组

设置好基础信息后添加HTTP请求（基本信息设置好没有OK哈，直接添加HTTP请求）

填写HTTP请求相关的内容

之后还要添加监听器，这里选择是图形结果

再添加一个查看结果树吧

在运行之前打开log Viewer

下面开始运行：

执行成功，来感受一下结果：

点进去

查看结果树

四、代码模拟

这里需要用到一个类，就是CountDownLatch。

CountDownLatch是一个计数器闭锁，通过它可以完成类似于阻塞当前线程的功能，即：一个线程或多个线程一直等待，直到其他线程执行的操作完成。

推荐下自己做的 Spring Cloud 的实战项目：

https://gitee.com/yoodb/jingxuan-springcloud

CountDownLatch用一个给定的计数器来初始化，该计数器的操作是原子操作，即同时只能有一个线程去操作该计数器。调用该类await方法的线程会一直处于阻塞状态，直到其他线程调用countDown方法使当前计数器的值变为零，每次调用countDown计数器的值减1。当计数器值减至零时，所有因调用await()方法而处于等待状态的线程就会继续往下执行。这种现象只会出现一次，因为计数器不能被重置。

下图和它的方法可以体现出来：

CountDownLatch类只提供了一个构造器：

   public CountDownLatch(int count) {  };  //参数count为计数值

然后下面这3个方法是CountDownLatch类中最重要的方法(上图能够反映出来）

   public void await() throws InterruptedException { };   //调用await()方法的线程会被挂起，它会等待直到count值为0才继续执行    
public boolean await(long timeout, TimeUnit unit) throws InterruptedException { };  //和await()类似，只不过等待一定的时间后count值还没变为0的话就会继续执行    
public void countDown() { };  //将count值减1

下面还需要看一个类Semaphore

Semaphore与CountDownLatch相似，不同的地方在于Semaphore的值被获取到后是可以释放的，并不像CountDownLatch那样一直减到底。另外，推荐公众号Java精选，回复java面试，获取面试资料，支持在线刷题。

它也被更多地用来限制流量，类似阀门的功能。如果限定某些资源最多有N个线程可以访问，那么超过N个主不允许再有线程来访问，同时当现有线程结束后，就会释放，然后允许新的线程进来。有点类似于锁的lock与 unlock过程。相对来说他也有两个主要的方法：

用于获取权限的acquire(),其底层实现与CountDownLatch.countdown()类似;
用于释放权限的release()，其底层实现与acquire()是一个互逆的过程。

通过这两个类可以进行并发的模拟：

测试一下：

   import lombok.extern.slf4j.Slf4j;    
    
import java.util.concurrent.*;    
    
@Slf4j    
public class CuncurrencyTest {    
    
    // 请求总数    
    public static int clientTotal = 5000;    
    
    // 同时并发执行的线程总数    
    public static int threadTotal = 200;    
    
    public static int count = 0;    
    
    public static void main(String[] args) throws InterruptedException {    
        // 定义线程池    
        ExecutorService executorService = Executors.newCachedThreadPool();    
        // 定义信号量 最大的线程数量    
        final Semaphore semaphore = new Semaphore(threadTotal);    
        final CountDownLatch countDownLatch = new CountDownLatch(clientTotal);    
    
        for (int i = 0; i < clientTotal; i++) {    
            executorService.execute(() -> {    
                try {    
                    semaphore.acquire();    
                    add();    
                    semaphore.release();    
                } catch (InterruptedException e) {    
                    e.printStackTrace();    
                    log.error("exception",e);    
                }    
                countDownLatch.countDown();    
            });    
        }    
        countDownLatch.await();    
        executorService.shutdown();    
        log.info("count:{}",count);    
    
    }    
    
    private static void  add() {    
        count++;    
    }    
}

因为count不是线程安全的，且没有做防护措施，结果是错的

上面是对代码的并发模拟的简单形式，值得注意的是，这里提到的两个类不是专门做并发模拟，它们的用途很广泛，大家可以了解一下。

来源：blog.csdn.net/qq_42322103/article/details/102736170

版权声明：此内容来源网络，版权归原作者所有。我们转载的内容，都会注明来源，除非无法确认。若有侵权，烦请告知，我们会立即删除并表示歉意。谢谢！

PS：文章若对您有用，请帮助 点赞、在看、转发吧！- END -点击卡片关注我们，更多技术干货，及时为您送达！

Meta开源JavaScript内存泄漏监测工具MemLab

Thu, 22 Sep 2022 11:26:54 CST

一、MemLab简介

上周，Facebook母公司Meta 宣布了开源 MemLab，一个基于 Chromium 的浏览器的 JavaScript 应用程序内存泄漏监测工具。同时，Facebook 技术团队指出：“应用程序的性能和功能正确性问题通常会被用户立即留意到。然而内存泄漏却不一样，它不容易被立即察觉，但它每次都会吃掉一大块内存，使得整个网络会话的响应变得非常慢。”

为了帮助开发人员解决这个问题，Meta 构建了MemLab，它可以自动进行内存泄漏检测并更容易找到泄漏的根本原因。据官方公告称，Meta 内部使用它成功地控制了不可持续的内存增长，并识别了产品和基础设施中的内存泄漏和内存优化机会。目前，Meta 已经在 GitHub 上开源了 MemLab。

Facebook在 2020 年被重新设计为单页应用程序 (SPA)，该应用程序的大部分渲染和导航使用客户端 JavaScript。而 Meta 的大多数其他流行网络应用程序都使用了类似的架构来构建，包括 Instagram 和 Workplace。

虽然这种架构使其能够提供更快的用户交互、更好的开发人员体验和更像应用程序的感觉，但在客户端维护 Web 应用程序状态会使有效管理客户端内存变得更加复杂。且内存泄漏的后果在单页应用程序（SPA）中更为严重，因为用户可能会在较长时间内持续与页面交互，而 MemLab 就是专为这种场景设计的。

在许多情况下，JavaScript 可能会泄漏内存。比如，Facebook 工程师 Liang Gong 和 Glenn Conner 就在公告中谈到，当你向 Chrome 控制台发送一个对象时，Chrome 会对其进行隐藏引用，以防止它被收集。另外，auth0 工程师 Sebastian Peyrott 也曾谈到，其他可能出现泄漏或未绑定内存增长的情况则与意外使用全局变量、忘记计时器或回调以及 DOM 外引用有关。

虽然 Chrome 开发者工具提供了检查 JavaScript 代码的内存行为的基本手段，比如时间线视图和配置文件视图，但这并不直接，也不能自动化。相反，MemLab 则可以很容易地集成到 CI/CD 管道中，Gong 和 Conner 介绍道。

二、工作原理

MemLab 的工作原理是通过预定义的测试场景运行 headless 浏览器并对 JavaScript heap snapshots 进行差异分析来发现内存泄漏。要达到这一目的，需要经过如下几步：

导航到页面并返回；
查找未释放的对象；
显示泄露追踪结果。

据悉，MemLab 使用了一个名为“Puppeteer”的 Node.js 库。它可以控制 Google Chrome 或其它基于 Chromium 内核打造的浏览器，且默认情况下以 headless 模式运行（方便命令行交互）。

Facebook 工程师解释称，MemLab 的工作方式就是导航到一个页面、然后离开。正常情况下，可预计该页面分配的大部分内存也将被释放。但若没有被释放，则意味其存在极高的内存泄露可能性。

我们知道，React 使用存储在树结构中、被称作 Fibers 的对象，来表示内存中的浏览器文档对象模型（DOM）。据该团队所述，这可能是存在“巨大内存泄露”的一个主要原因。拥有强连接图的缺点很是显著，若有任何外部引用指向图的任何部分，就无法对整个图开展垃圾回收。

对于浏览器内存泄漏检测，MemLab 需要开发人员提供的唯一输入是一个测试场景文件，该文件定义了如何通过 overriding Puppeteer API 和 CSS 选择器的三个回调来与网页进行交互。MemLab 会自动对 JavaScript heap 进行差异化处理，完善内存泄漏，并对结果进行汇总。

MemLab 的另一特性，就是提供了 JavaScript 堆的图形视图、启用了用于检查堆快照的 API 。这意味着开发者能够编写开展内存断言的测试，例如声明某个对象将不再存在于内存中。

此外还有一个用于查找重复字符串实例的工具，在某个案例中，团队发现字符串占用了 70% 的堆、且其中半数至少有一个重复的实例。包括 Chrome、Edge、Firefox 在内的浏览器，都有附带内存检查工具。但正如以为开发者在 Hacker News 上吐槽的那样，这些开发工具难以在调试过程中揪出内存泄露的问题。

最后，MemLab 的另一项强大功能，就是可以在测试期间作为命令过程的一部分而运行。这意味着如果代码中引入了严重的泄露，开发者们也能够在投入生产环境前加以捕获。

除了内存泄漏检测之外，MemLab还包括一组用于查找内存优化机会的内置CLI命令和api，并提供如下的功能：

堆内容分解
监测单个对象的内存使用情况
查找重复的字符串实例

比如，监测浏览内存泄漏部分UI。

跟踪UI内存泄漏的整个链路。

三、基本使用

3.1 安装与使用

首先，需要全局安装MemLab插件，安装的命令如下：

  npm install -g memlab

例如下面是找到谷歌Maps中的内存泄漏的例子，我妈可以创建一个场景文件来定义如何与谷歌Maps进行交互，比如将其命名为test-google-maps.js。

  function url() {
  return 'https://www.google.com/maps/@37.386427,-122.0428214,11z';
}


async function action(page) {
  await page.click('button[aria-label="Hotels"]');
}


async function back(page) {
  await page.click('[aria-label="Clear search"]');
}


module.exports = {action, back, url};

现在使用下面的命令运行上面的js代码, 当memlab与web页面进行交互时就会运行内置的泄漏检测器检测内存泄漏。

  memlab run --scenario test-google-maps.js

执行结束之后，Memlab就会打印内存泄漏结果，显示每个泄漏对象集群的一个代表性保留跟踪。

  MemLab found 46 leak(s)
--Similar leaks in this run: 4--
--Retained size of leaked objects: 8.3MB--
[Window] (native) @35847 [8.3MB]
  --20 (element)--->  [InternalNode] (native) @130981728 [8.3MB]
  --8 (element)--->  [InternalNode] (native) @130980288 [8.3MB]
  --1 (element)--->  [EventListener] (native) @131009888 [8.3MB]
  --1 (element)--->  [V8EventListener] (native) @224808192 [8.3MB]
  --1 (element)--->  [eventHandler] (closure) @168079 [8.3MB]
  --context (internal)--->  [<function scope>] (object) @181905 [8.3MB]
  --bigArray (variable)--->  [Array] (object) @182925 [8.3MB]
  --elements (internal)--->  [(object elements)] (array) @182929 [8.3MB]
...

接着，我们就可以通过这些捕获的跟踪信息定位到里面的方法。

当然，我没也可以使用Memlab查看基于从Chromium、Hermes、memlab或任何node.js或electronic .js程序中获取的单个JavaScript堆快照检测到的内存问题。

  memlab view-heap --snapshot <PATH TO .heapsnapshot FILE>

然后，我没可以使用对象的id，比如node-id @28173来精确定位特定的堆对象。

当然，Memlab也支持自定义的检漏器，自定义检漏器时需要在场景文件中添加一个 filterLeak文档。对于目标交互分配的每个未释放的堆对象(节点)将调用filterLeak。

  function filterLeak(node, heap) {
  // ... your leak detector logic
  // return true to mark the node as a memory leak
};

heap是最终JavaScript堆快照的图形表示。

3.2 堆分析与研究

除了检测内存泄露意外，Memlab还提供了很多其他有用的命令，比如查看某个对象在运行的交互过程中的整个链路。

  memlab analyze unbound-object

获取V8/hermes .heapsnapshot文件。

  memlab analyze unbound-object --snapshot-dir <DIR_OF_SNAPSHOT_FILES>

使用memlab analyze查看所有内置内存分析。

  memlab trace --node-id <HEAP_OBJECT_ID>

3.3 Memlab API

Memlab的npm包支持在浏览器中启动端到端运行并检测内存泄漏。

  const memlab = require('memlab');


const scenario = {
    url: () => 'https://www.google.com/maps/@37.386427,-122.0428214,11z',
    action: async (page) => await page.click('button[aria-label="Hotels"]'),
    back: async (page) => await page.click('[aria-label="Clear search"]'),
}
memlab.run({scenario});

3.4 内存断言

Memlab支持在Node.js程序中进行Jest测试，也可以使用图视图API来获得其自身状态的堆图视图，执行自内存检查，并编写各种内存断言。

  import type {IHeapSnapshot} from '@memlab/core';
import {config, takeNodeMinimalHeap, tagObject} from '@memlab/core';
test('memory test', async () => {
  config.muteConsole = true;
  const o1 = {};
  let o2 = {};
  tagObject(o1, 'memlab-mark-1');
  tagObject(o2, 'memlab-mark-2');
  o2 = null;
  const heap: IHeapSnapshot = await takeNodeMinimalHeap();
   //断言函数
  expect(heap.hasObjectWithTag('memlab-mark-1')).toBe(true);
  //断言函数
  expect(heap.hasObjectWithTag('memlab-mark-2')).toBe(false);
}, 30000);

附件： https://github.com/facebookincubator/memlab

开发一个在线代码对比工具

Sat, 23 Jul 2022 09:32:39 CST

highlight: monokai

我正在参加「创意开发投稿大赛」详情请看：掘金创意开发大赛来了！

前言

在开发过程中，我们经常需要用到代码对比，对比下代码是否一致，有哪些改动，方便我们可以查看问题，今天我们就来说实现下，其实很简单，不需要后端，纯前端就可以实现。

Monaco Editor

Monaco Editor 是 VS Code 中使用的开源代码编辑器，拥有代码高亮和代码自动补全的功能，并且内置了一个 Diff Editor。

官网就有一个 Diff Editor 的演示，我们要开发的就是在这个基础之上，加上语言切换的功能，让这个 Diff Editor 拥有内置云语言的语法高亮。

TypeScript, JavaScript, CSS, LESS, SCSS, JSON, HTML、XML, PHP, C#, C++, Razor, Markdown, Diff, Java, VB, CoffeeScript, Handlebars, Batch, Pug, F#, Lua, Powershell, Python, Ruby, SASS, R, Objective-C

官网罗列了这些语言，但远不止于此。

马上掘金

代码片段使用 monaco-editor 创建一个简单的代码编辑器

代码片段使用 monaco-editor 创建一个简单的 Diff 编辑器

Monaco Editor 有 2 种加载方式，分别是 amd 和 esm，也就是 Requirejs 和 ES Modules。马上掘金中使用的是 requirejs。

技术栈选择

我准备把常用的工具做成一个工具网站，所以我选择使用 next.js，并且可以使用 vercel 免费持续部署。

关于 Monaco Editor 在 next.js 中的配置，之前有介绍过，大家可以看这篇文章《在 Next.js 中使用 Monaco Editor》。

实现 Diff Editor

  import type { editor as MonacoEditor } from "monaco-editor";
import { useEffect, useRef, useState } from "react";
import * as monaco from "monaco-editor";

export default function TextDiffPage() {
 const editorContainer = useRef<HTMLDivElement | null>(null);
 const [language, setLanguage] = useState("text");
 const [inlineView, setInlineView] = useState(false);

 const [diffEditor, setDiffEditor] =
   useState<MonacoEditor.IStandaloneDiffEditor | null>(null);

 const createModel = (
   value: string,
   language: string,
   type: "original" | "modified"
 ) => {
   return monaco.editor.createModel(value, language);
 };

 const initEditor = async () => {
   const originalModel = createModel(`Hello World`, language, "original");
   const modifiedModel = createModel(`Goodbye World`, language, "modified");
   const editor = monaco.editor.createDiffEditor(editorContainer.current, {
     minimap: { enabled: false },
     theme: "vs-dark",
     renderSideBySide: !inlineView,
     originalEditable: true,
   });
   editor.setModel({
     original: originalModel,
     modified: modifiedModel,
   });

   setDiffEditor(editor);
 };

 useEffect(() => {
   initEditor();
   return () => {
     if (diffEditor) diffEditor.dispose();
   };
 }, []);

 useEffect(() => {
   if (diffEditor) {
     diffEditor.updateOptions({
       renderSideBySide: !inlineView,
     });
   }
 }, [inlineView]);

 return (
   <div className="h-screen flex flex-col">
     <header className="h-16 border-b dark:border-neutral-800 flex-shrink-0 flex items-center px-3 space-x-5">
       <label className="space-x-1 flex items-center">
         <input
           type="checkbox"
           checked={inlineView}
           onChange={(e) => setInlineView(e.target.checked)}
         />
         <span>Inline diff</span>
       </label>
     </header>
     <div ref={editorContainer} className="h-full"></div>
   </div>
 );
}

上述代码很简单，可能有同学对 createModel 方法比较疑惑，为什么是 Model ？好比 Monaco Editor 是一个容器，容器可以设置 Model、切换 Model，比如 vscode 中，每打开一个文件就是一个 Model，文件切换就是切换 model，每个文件都有状态，比如光标位置，历史记录等，这些状态都存在 model 中，这样就不会因为文件切换而状态混淆。

  // typescript 禁用类型检查
monaco.languages.typescript.typescriptDefaults.setDiagnosticsOptions({
  noSemanticValidation: true,
  noSyntaxValidation: false,
});

// typescript jsx 格式使用 React 语法解析
monaco.languages.typescript.typescriptDefaults.setCompilerOptions({
  jsx: monaco.languages.typescript.JsxEmit.React,
});

对与一些 typescript 的语法校验我们可以选择关闭，jsx 不支持，可以设置为 react 语法支持。

最后

最后我的工具网站也开源了，包含一些前端常用工具，还可以在线刷面试题。

如果对你有帮助，可以随手点个赞，这对我真的很重要。

以上就是本文全部内容，希望这篇文章对大家有所帮助，也可以参考我往期的文章或者在评论区交流你的想法和心得，欢迎一起探索前端。

简述前端包管理工具机制和相关实践

Wed, 01 Jun 2022 00:00:00 CST

简述前端包管理工具机制和相关实践

npm 依赖管理机制

区别于 Python 的包管理工具 pip 的全局安装，npm 会安装依赖包到当前项目目录，使不同项目的依赖更成体系，这样做的好处是减轻了包作者的 API 兼容性压力；但是缺陷是如果两个项目依赖了一个相同的库，一般这个库会在这两个项目中各安装一次，即相同的依赖包会被多次安装。
我们先通过一张流程图(源自掘金)来了解下 npm install 的整体流程

可以看到执行 npm install 后依次会进行以下流程

检查 package-lock.json
通过和 package.json 对比确定是否远程获取包信息
扁平化构建依赖树
添加缓存
下载包并解压到 node_modules
生成新的 lock 文件值得注意的是，早期 npm 版本(v5.0 - v5.4)发现 package.json 和 package-lock.json 不一致时，对依赖的安装方式是不一样的。 所以对于团队而言，最佳实践应该是保持 npm 版本的一致性！

缓存机制

我们可以从流程图中看到，npm install 的流程中会查找和使用缓存，以及下载包后会添加缓存的环节。由于依赖嵌套机制，项目中 node_moudles 占用的磁盘空间无疑是最大的，如果安装时每次都通过网络下载获取，那么时间成本是巨大的。常见的优化方式是“空间换时间”，npm 也通过缓存机制来解决这个问题。
简单了解下缓存的目录的和清除机制。
通过 npm config get cache命令可以查询到缓存目录：默认是用户主目录下的 .npm/_cacache 目录。
npm cache clean --force即可强制清除缓存。

yarn 带来了什么？

yarn 是于 2016 年诞生的，它的出现解决了历史上 npm 的很多问题，比如缺乏对于依赖的完整性和一致性保障(npm v3 版本还没有 package-lock.json)，以及 npm 安装速度过慢的问题等。npm 目前已经迭代到 v8 版本，在很多方面已经借鉴了 yarn 的优点，但是我们不妨了解下 yarn 诞生时带来的理念。

确定性。通过 yarn.lock 等机制，保证了确定性，这里的确定性包括但不限于明确的依赖版本、明确的依赖安装结构等。即在任何机器和环境下，都可以以相同的方式被安装。
模块扁平化安装。将依赖包的不同版本，按照一定策略，归结为单个版本，以避免创建多个副本造成冗余。
更快的速度。yarn 采取并行安装的机制进行包的安装任务，提高了性能；yarn 引入的缓存机制使二次安装的速度更快。
更好的语义化。yarn 的命令更加简洁。 解决早期 npm 的依赖管理问题

文章的开始提到 npm 是将依赖放到项目的 node_modules 中，同时如果 node_modules 中的依赖 A 还依赖了其他依赖 B，那么 B 也会被安装到 A 的 node_modules 文件夹，依次递归最终形成非常复杂和庞大的依赖树。
这种依赖管理方式会随着项目的迭代，node_moudles 会变得越来越复杂，从而造成：

非常深的项目依赖层级，难以排查问题
依赖被重复安装，浪费磁盘，网络等资源，安装速度慢那么 yarn 是如何解决这个问题的呢？那就是模块扁平化安装机制。假如我们有这样一个文件依赖结构。

  App   
 -a@2.0   
   -b@2.0   
 -b@2.0   
 -c@1.0   
   -b@2.0

yarn 在安装依赖时会打平依赖，并对重复依赖进行提升，最终形成的依赖结构如下：

  App   
 -a@2.0   
 -b@2.0   
 -c@1.0

但是需要注意的是： 模块的安装顺序可能影响 node_modules 内的文件结构。在 npm v3 版本中，假如项目一开始依赖了 a@1.0，此时 a@1.0 会被安装在顶层目录；随着迭代，又引入了模块 b@1.0，而 b@1.0 又依赖了 a@2.0，此时 a@2.0 会被安装在 b@1.0 下，因为顶层已经有一个 a@1.0 了。

pnpm: 最先进的包管理工具？

在各个场景下，pnpm 相比较于 npm(v8)和 yarn(v3)在性能上都有不错的提升。
pnpm 之所以有如此大的性能提升，简单来说 pnpm 是通过全局 store（目录 ${os.homedir}/.pnpm-store）来存储 node_modules 依赖的 hard-links，当在项目文件中引用依赖的时候则是通过 symlink 去找到对应虚拟磁盘目录下(.pnpm 目录)的依赖地址。相比于 npm 和 yarn 会在每个项目中都安装一份 node_moudles, pnpm 的全局 store 则实现了“安装一次，所有项目复用”，这样避免了二次安装带来的时间消耗。
除此之外，pnpm 本身的设计机制解决了 monorepo 的很多痛点，比如 ”幽灵依赖“和 ”依赖重复安装“的问题。如图：下面两小节内容源自：pnpm: 最先进的包管理工具 ^[1]

幽灵依赖

Phantom dependencies 被称之为幽灵依赖，解释起来很简单，即某个包没有被安装(package.json 中并没有，但是用户却能够引用到这个包)。
引发这个现象的原因一般是因为 node_modules 结构所导致的，例如使用 yarn 对项目安装依赖，依赖里面有个依赖叫做 foo，foo 这个依赖同时依赖了 bar，yarn 会对安装的 node_modules 做一个扁平化结构的处理(npm v3 之后也是这么做的)，会把依赖在 node_modules 下打平，这样相当于 foo 和 bar 出现在同一层级下面。那么根据 nodejs 的寻径原理，用户能 require 到 foo，同样也能 require 到 bar。

  package.json -> foo(bar 为 foo 依赖)   
node_modules   
  /foo   
  /bar -> 依赖

那么这里这个 bar 就成了一个幽灵依赖，如果某天某个版本的 foo 依赖不再依赖 bar 或者 foo 的版本发生了变化，那么 require bar 的模块部分就会抛错。

依赖重复安装

这个问题其实也可以说是 hoist 导致的，这个问题可能会导致有大量的依赖的被重复安装，举个例子:
例如有个 package，下面依赖有 lib_a、lib_b、lib_c、lib_d，其中 a 和 b 依赖 util_e@1.0.0，而 c 和 d 依赖 util_e@2.0.0。
那么早期 npm 的依赖结构应该是这样的:

  - package   
  - package.json   
  - node_modules   
     - lib_a   
       - node_modules <- util_e@1.0.0   
     - lib_b   
       - node_modules <- util_e@1.0.0   
     _ lib_c   
       - node_modules <- util_e@2.0.0   
     - lib_d   
       - node_modules <- util_e@2.0.0

这样必然会导致很多依赖被重复安装，于是就有了 hoist 和打平依赖的操作:

  - package   
  - package.json   
  - node_modules   
     - util_e@1.0.0   
     - lib_a   
     - lib_b   
     _ lib_c   
       - node_modules <- util_e@2.0.0   
     - lib_d   
       - node_modules <- util_e@2.0.0

但是这样也只能提升一个依赖，如果两个依赖都提升了会导致冲突，这样同样会导致一些不同版本的依赖被重复安装多次，这里就会导致使用 npm 和 yarn 的性能损失。
如果是 pnpm 的话，这里因为依赖始终都是存在 store 目录下的 hard links ，一份不同的依赖始终都只会被安装一次，因此这个是能够被彻彻底底的消除的。

项目中的相关场景实践和常见问题

npm link

适用场景：本地调试 npm 模块，将模块链接到对应的业务项目中运行使用方法：假如我们需要把模块 pkg-a 链接到主项目 App 中，首先在 pkg-a 根目录中执行 npm link，然后在 App 根目录中执行 npm link pkg-a 即可。调试完可以使用 npm unlink 取消关联。原理：npm link 通过软连接将 pkg-a 链接到 node 模块的全局目录和可执行文件中，实现 npm 包命令的全局可执行。

npx

适用场景：在 npm 5.2.0 版本之后，npm 内置了 npx 的包。npx 是一个简单的 cli 工具，可以帮助我们快速的调试，还可以让我们在不通过 npm 安装包的前提下执行一些 npm 包。

使用方法：
Before:一般情况下，如果我们想使用 es-lint, 会先通过 npm install es-lint, 然后在项目根目录执行 ./node_modules/.bin/es-lint your_file.js 或者通过 package.json 的 npm scripts 调用 eslint。
After:npx es-lint your_file.js
原理：npx 在运行时会自动去 ./node_moudles/.bin 和环境变量寻找命令

是否提交 lock.json 到代码仓库

前面我们提到 yarn 带来了 .lock 文件的机制，使得在任何环境下执行 install，都能得到一致的 node_modules 安装结果。但是是否需要提交 lockfiles(package-lock.json/yarn.lock) 到代码仓库呢？
npm 官方文档 ^[2]是建议把 package-lock.json 文件提交到代码仓库的。在多人协作的项目中，这样做确实没有问题。但是如果开发的是库，在 npm publish 的时候最好忽略 lockfiles。因为库一般是被其他项目依赖的，在不使用 lockfiles 的情况下，由于新版 npm 和 yarn 的 hoist 机制，可以复用住项目已经加载过的包，减少依赖重复和体积。
但是存在这样一种现象：即使在一些发布时忽略 lockfiles 的库中，在主项目顶层存在相关依赖包的前提下，最终生成的 lockfile 仍然没复用主项目的包。这是为什么呢？原因是库的依赖包版本和主项目存在的依赖包版本不一致。具体看下图：主项目的 yarn.lock 中显示 browser 这个包依赖了 @babel/runtime@7.0.0

主项目 node_modules 顶层的 @babel/runtime 版本为 7.10.1

知道了原因，那么如何减少库项目的依赖项呢。到这里，解决方案也就呼之欲出了：

库项目尽量使用和主项目版本一致的依赖包
在库项目 package.json 的 “peerDevpendencies” 字段中声明主项目已有的依赖包

合入其他分支代码后编译报错

相信很多同学都遇到过和我一样的问题：当自己的 feat 分支代码合入 master 或者业务班车分支的代码时，重新 yarn 时，有时候会编译失败，报大量 "can't resolve module xxx"的错误。这种错误有很多情况是依赖版本不一致的问题，但是又极其难以定位，令人头痛。那么此时有另外一个思路，那就是从 master 拉一个最新的分支再进行合入。
但更好的解决方式是：建议在日常开发过程中，定时合入 master 代码，一方面可以合入最新的 feat，另一方面可以避免长时间不合入，最后在上线阶段合入代码，可能出现大量冲突，解决不当或遗漏而造成的编译问题。同时也可以考虑将工具升级为 pnpm，以解决潜在的“幽灵依赖”和“依赖嵌套”问题，同时带来性能上的提升。

参考资料

[1]

pnpm: 最先进的包管理工具: https://bytedance.feishu.cn/docs/doccngSUrvF0qPVmBE1rq1iPZQf

[2]

npm官方文档: https://docs.npmjs.com/cli/v7/configuring-npm/package-lock-json

中台工具产品方法论

Thu, 28 Apr 2022 17:50:15 CST

背景

做中台工具产品不是一件容易的事情，需要对接上层所有业务方，做的慢业务方不满意，做的快业务方未必会给好的评价。

属于容易背锅，细节极其多，用户反馈建议多，但又难以出成绩和证明自己做的好。

场景

虚构一些场景，大家肯定都遇到过。

场景1

老板：XX功能我觉得不错，做了吗？

产品经理：收到，我研究下。

几天之后……

老板：XX和XX等N个功能都不错，马上排期做下。

产品经理：收到。

评价：产品经理是初级的工具人，执行命令，最终老板大概率不会满意，因为产品功能都是老板自己提的，上线未必效果好。

老板会认为自己是个有想法的人，同时认为产品经理没有想法，产品经理挺冤枉，干的比黄牛累。出了成绩是老板高瞻远瞩，没有成绩是没执行好。

对话通常以被动接受信息，缺乏有效的反馈和互动。收集大量需求导致执行慢，可能会被技术同事认为是战斗力等于5的渣渣。

场景2

老板：XX功能我觉得不错，做了吗？

产品经理：收到，我研究下…（几小时之后）这个功能挺好，和技术同事工作量比较大，会在下一个版本中增加。

评价：高级工具人，收到信息之后，能够给予执行的时间点，对工作量和项目节奏有一定把控能力。

场景3

老板：XX功能我觉得不错，做了吗？

产品经理：研究过了，用户给我们反馈过，XX竞品也有这个功能。我们已经在当前规划中了，计划在下一个版本中增加。

评价：有一定自主工作意识，对产品有一定思考，老板只是信息源之一，能从用户反馈和竞品等渠道提炼产品需求，有主动找信息和需求的能力。但很少反驳别人的想法，对事情的优先级把控能力还不够。

场景4

老板：XX功能我觉得不错，做了吗？

产品经理：研究过了，会放在下一个版本中增加。我们当前版本是主要提升另外一个模块的易用性，用户意见比较大，是影响产品NPS的主要因素，上线之后预期会影响xx%比例的用户。而你提的XX功能属于体验优化，我们会在下一个版本中迭代。

评价：有优先级掌控意识，在和老板的对话中体现了自身的专业性，体现了用户反馈、NPS和数据来驱动产品迭代，在产品标准上和老板拉齐认知。产品的目的在于提升NPS等，不局限于讨论某个功能点。即使拒绝了老板需求，老板也会认为产品经理有自己的思考。

但是缺陷在于，产品经理的眼光只能看到未来1-2个月的规划，对长期规划还缺乏把控。

场景5

老板：XX功能我觉得不错，做了吗？

产品经理：已经在规划当中了，房产中介对这个需求有很强需求，而其他类型的用户需求不高。我们今年的目标是满足电商等前5的用户诉求，这些行业对公司贡献大，我们最近做了调研发现电商等用户对XX功能有很强的诉求，提炼了N个需求来，比如XX……

评价：对全局有掌控，对公司战略目标有理解，基于战略目标拆解出了自己的目标，能够主导项目迭代。

老板满意，合作方满意，技术同事跟着干活能自己做事情的价值，对产品经理认可度很高，不会带着项目组做无用功。

场景6

老板：XX功能我觉得不错，做了吗？

产品经理：需求可以做，功能产品侧都可以做，细节是永远做不完的，但是缺乏方向性。我认为SaaS产品的核心目标是收入，当前提升收入的抓手我们还没有明确。通过数据分析、用户访谈和专家访谈，我觉得有xx场景是可以深挖的，这些行业还有50%+增量收入，期望与其他团队能联动在未来半年中达成这项目标。而你提的XX功能，不是典型的应用场景。

评价：这样的产品经理已经可以做业务负责人了，有完善的方向判断能力和产品方法论，有能力带领项目组走向成功。

而老板是资源，说服老板投入更多精力在某个方向，老板会对产品经理更为信任，提功能细节的次数会很少，更多是讨论项目方向，输入外界信息来帮助产品经理做判断。

做产品，超出用户预期，他们才会满意。做产品经理也是一样，认知超越周围的同事，大家才会认可你。

解放双手！推荐一款阿里开源的低代码工具，YYDS！

Tue, 19 Apr 2022 01:31:26 CST

之前分享过一些低代码相关的文章，发现大家还是比较感兴趣的。之前在我印象中低代码就是通过图形化界面来生成代码而已，其实真正的低代码不仅要负责生成代码，还要负责代码的维护，把它当做一站式开发平台也不为过！最近体验了一把阿里开源的低代码工具 LowCodeEngine，确实是一款面向企业级的低代码解决方案，推荐给大家！

SpringBoot实战电商项目mall（50k+star）地址： https://github.com/macrozheng/mall

LowCodeEngine简介

LowCodeEngine是阿里开源的一套面向扩展设计的企业级低代码技术体系，目前在在Github上已有 4.7K+Star。这个项目大概是今年2月中旬开源的，两个月不到收获这么多Star，确实非常厉害！

LowCodeEngine主要具有如下特性：

提炼自企业级低代码平台的低代码引擎，奉行高度可扩展、最小内核、最强生态的设计理念；
部署简单，基本上就是开箱即用，拥有完善的物料体系、功能强大的设置器、丰富的插件等；
可视化编辑器具有完善的工具链，支持物料体系、设置器、插件等生态元素；
强大的扩展能力，已支撑近 100 个各种垂直类低代码平台；
使用 TypeScript 开发，能生成基于React的前端代码。

下面是LowCodeEngine使用过程中的一张效果图，功能还是很强大的！

搭建低代码平台

接下来我们将使用LowCodeEngine搭建一个低代码开发平台，仅需5分钟，可以说是开箱即用！

首先我们需要想下载LowCodeEngine编辑器的示例代码，下载地址：https://github.com/alibaba/lowcode-demo

下载成功后解压到指定目录，安装此项目需要使用 Node.js和 npm，确保已经安装完毕，由于依赖中有些 npm源无法访问，这里推荐使用 cnpm来安装，先使用如下命令安装 cnpm；

  npm install -g cnpm --registry=https://registry.npmmirror.com

cnpm安装成功后，进入解压目录使用如下命令安装依赖；

  cnpm install

依赖安装完成后，使用 npm start命令启动项目；

项目运行成功后将运行在 5556端口上，访问地址：http://localhost:5556

使用低代码平台

之前在我的开源项目 mall中有个品牌管理功能，接下来我们将使用LowCodeEngine来实现下它，看看低代码开发有何神奇之处！

目标效果

mall项目中的品牌管理功能效果如下，这里使用低代码简单实现下品牌列表功能。

组件库

首先我们从 组件库中选择 查询筛选组件，通过拖拽的形式插入编辑区中；

然后选中 查询筛选组件，通过右侧的 设置器进行设置；

可以点击组件左侧的 编辑按钮对组件进行详细设置，比如说组件外观和输入提示等；

接下来再拖拽一个 高级表格组件到编辑器中去；

同样选中 高级表格组件可以对表格进行设置，我们可以通过 数据列来设置需要显示的数据。

数据源

由于表格中的数据需要访问接口来获取，这里我们可以通过 数据源功能来实现，这里我们调用演示环境的API，填入请求参数即可，值得注意的是由于数据列表在 data.list属性中，我们需要定制下请求成功的处理函数；

接下来选中 高级表格组件，修改 表格数据源，选择 表达式输入，填入我们之前设置的 数据源ID即可；

然后修改 数据列信息，将每个数据列 数据字段修改为JSON数据中对应的属性即可。

预览及出码

如果想查看搭建的页面效果的话，点击右上角的 预览按钮即可；

下面是由低代码生成的页面预览效果；

如果你想获取工具生成的代码的话，点击右上角的 出码按钮即可，支持直接下载。

其他功能

如果你想自定义一些函数的话，可以通过 源码面板进行自定义；

通过 大纲视图我们可以查看整个界面的结构。

总结

今天体验了一把阿里开源的低代码开发工具，功能确实很强大。但是低代码并不意味着可以不写代码了，想用好低代码工具还得熟悉工具生成的代码。LowCodeEngine目前仅支持生成React的前端代码，所以想要实现更为复杂的业务系统，还得熟悉React。如果有小伙伴想更深入了解低代码的概念，推荐看下这篇文章《阿里低代码引擎和生态建设实战及思考》。

参考资料

项目地址：https://github.com/alibaba/lowcode-engine
项目官网：https://lowcode-engine.cn/
操作指南：https://www.yuque.com/lce/usage

Calibre 5.36 发布，功能强大的开源电子书工具

Sun, 06 Feb 2022 09:45:55 CST

Calibre 开源项目是 Calibre 官方出的电子书管理工具。它可以查看，转换，编辑和分类所有主流格式的电子书。Calibre 是个跨平台软件，可以在 Linux、Windows 和 macOS 上运行。

Calibre 5.36.0 正式发布，此次更新内容如下：

新功能

编辑元数据对话框：允许通过「首选项->外观->编辑」元数据来控制哪些自定义列出现在这个对话框中。
编辑元数据对话框：允许在 "All on 1 tab" 模式下手动调整对话框的各个部分的大小。
编辑书籍：拼写检查，更新捆绑的英语和西班牙语词典
BibTeX 目录：支持自定义列等标签

错误修正

Amazon 元数据下载：修复评论中的段落被合并的问题
Amazon.de 元数据下载：修复某些书籍的出版日期和系列信息没有被获取的问题
邮件发送：修复通过 Hotmail 发送电子邮件从本周开始无法工作的问题，因为微软改变了 SMTP 服务器的名称
不要删除波兰语标题的文章
电子书查看器：当使用朗读时，在暂停或停止朗读前不会自动查找高亮显示的单词
电子书阅览器：修复打印时 Ctrl+p 快捷键不起作用的问题
查看特定格式且文件丢失时显示错误
编辑书籍：修复以非字开头/结尾的类的重命名不工作的问题
编辑书籍：预览面板：修复在 macOS 上行末的连字符被呈现为方框的问题
修复在图像缩小到适合大小时，修剪图像对话框中显示的不正确的选择尺寸
编辑书籍：修复从另一个编辑器实例粘贴文件时，如果已存在相同名称的文件，则导致失败的问题。

更多详情可查看： https://calibre-ebook.com/whats-new

比较Flyway与Liquibase两大数据库迁移工具_Java

Sun, 16 Jan 2022 12:14:03 CST

众所周知，对于那些使用着关系型数据库引擎的各类应用程序而言，数据库迁移工具的选用是至关重要的。它们不但能够让各种复杂且重复的过程更加自动化，而且可以让我们更加轻松且准确地完成各种大型的迁移任务。

下面，我将对两种最常见的开源迁移工具--Flyway和Liquibase，进行介绍与比较，以方便您在实际项目中做出合理的选择。

Flyway的介绍

Flyway是由Redgate公司带来的一款开源式的数据库迁移工具。该工具注重规则上的简约性，而非繁琐的配置。

目前，它能够支持诸如Postgres、Oracle、SQL Server、DB2、H2、以及MariaDB等大多数主流数据库引擎。同时，Flyway还可以支持诸如：Amazon RDS、Google Cloud SQL、以及Heroku等基于云端业务的数据库服务。

该工具所用到的脚本既可以用纯SQL(支持多种SQL语法)，又能够用Java(主要用于更复杂的转换)来进行编写。同时，它既带有命令行客户端，又提供支持Maven和Gradle的插件。此外，它的Java API，还适用于Android系统。

Flyway的Evolve非常适用于习惯了使用.NET和C#的用户。因此，如果您对其有兴趣的话，请查看文末列出的它在GitHub上的链接页面。

Liquibase的介绍

作为于2006年推出的、可用于数据库迁移的开源类工具，Liquibase是基于变更日志(changelog)和变更集(changesets)文件的相关概念实现的。这些文件可以由SQL、XML、YAML、以及JSON编写而成。它们通过存储那些针对数据库结构的更改，以便将其应用到任何其他数据库的实例上。

目前，Liquibase支持的数据库种类包括：Postgres、Oracle、DB2、H2、MariaDB、SQL Server、以及SQLite等。同时，它还支持诸如：Azure SQL、Amazon RDS、以及Amazon Aurora等许多基于云的数据库。

您可以使用诸如Maven、Gradle、甚至是Ant之类的构建工具，从Shell中运行Liquibase的迁移脚本。此外，您可以一次生成纯粹的SQL查询，以便您的DBA、Ops、DevOps团队、或负责数据库的任何人，可以进一步执行此类查询。

有了对于上述两种工具的基本概念，下面让我们来讨论一下它们之间的相同点和不同之处。

Flyway和Liquibase之间的相似之处

在某种程度上，两者都属于开源的，并且能够免费提供各种功能。当然它们也都具有提供更多高级功能的付费版本。
两者都可以使用简单、传统的SQL，来编写出迁移脚本。
两者都能完美地“面向Java”，并且都内置了针对Maven和Gradle之类基本构建工具的支持，以及可以与诸如：Spring Boot等最常见的Java框架相集成。
两者都可以从命令行处运行简单的shell脚本。
虽然两者支持的数据库版本和驱动程序，可能存在着一些细微的差异，但是从整体而言，它们能够支持的数据库品种大致相似。
在处理数据库更改时，两者用到了相同的方法，即：基于迁移的数据库交付。
两种工具都实现了由Martin Fowler提出和诠释的数据库重构(Evolutionary database) 的概念(详见本末链接)。

Flyway和Liquibase之间的不同之处

下面，让我们从横跨多个数据库引擎来运行相同脚本的角度，来讨论Flyway和Liquibase的不同之处。

首先，我们会碰到的一个实际问题是：如何针对实例生产差异(diff)。您会发现，我们可以直接使用Liquibase来生成相关差异;却无法使用Flyway来实现，而且即便是其付费版本也无法达到。这便是我们往往在项目中选择Liquibase，而非Flyway的主要原因之一。

其次，我们来看看Java客户端。Flyway拥有原生的Java API，它可以帮助我们进行诸如BLOB和CLOB的更改、以及高级批量数据的修改等较为复杂的迁移。这些功能在某些受限制的迁移场景中，是非常实用的。因此这反过来成为了用户选用Flyway，而非Liquibase的主要原因之一。

接着，我们来讨论两种工具是如何处理回滚的。我们设置Liquibase的changelog文件相对比较容易。实际上，changelog的XML结构甚至已经为回滚代码定义好了一个特殊的字段。而Flyway仅在其付费版本中提供了回滚处理的服务。因此，如果您不介意使用付费工具的话，可以考虑使用Flyway的相关功能。当然，据说Liquibase的付费版本，对于不同类型的回滚，具有更完备的支持。您如果有时间和精力的话，可以去试用一下。

最后，让我们来看看更改顺序的管理。对此，两种工具有着完全不同的处理方法。Flyway采取的是线性数据库版本控制的概念。这意味着，应用更改的顺序，取决于迁移脚本的名称顺序。实际上，Flyway的迁移脚本有着一个完整的命名规则。如果您希望它能够按照预期执行的话，就必须遵循该规则。而在Liquibase中，数据库实例的更改顺序，基于整个changelog文件中的特定更改位置。也就是说，如果您将更改按照某种特定的顺序放在changelog中的话，那么对于数据库的更改也将以完全相同的顺序执行并完成。

小结

综上所述，我们对Flyway和Liquibase两种数据库迁移工具进行了综合比较。总的说来，Flyway的优点在于，其迁移脚本更具有可读性。如果您非常熟悉SQL的话，那么它用起来更加便捷、更加顺手。当然，它的缺点是无法实现跨平台的使用。而Liquibase正好相反，其优点在于可以跨平台被使用，其不足之处在于，由于它功能强大，因此我们可能需要花费一定的精力，去维护它的迁移脚本。

容器安全扫描工具推荐 (insights.thoughtworks.cn)

Tue, 04 Jan 2022 00:00:00 CST

在现代软件开发中，我们会使用一些公共镜像作为基础镜像来快速构建我们的应用镜像，并将其部署到生产环境中。

随着越来越多的应用程序被容器化，容器安全也随之变得越来越重要。在项目的流水线中，我们可以使用漏洞扫描器进行扫描并提前获得反馈，实现 “安全左移” ，也可以更好的实践敏捷。

基于容器的应用程序的安全痛点

现在，我们使用先进的技术来构建我们的应用程序，如 NodeJS、 Java 和 Kotlin 等，然后将代码库存储在托管的 Git 平台上，如 GitHub、Gitlab 等。代码库由我们的业务代码和依赖关系组成；对于依赖项，我们可以使用专业的扫描工具来确保安全，比如 NodeJS 的 npm audit , GitHub 的 Dependabot；至于我们的业务代码，可以使用其他的一些安全工具可以扫描，比如 SoneQube 等。

因此，对于依赖（ Dependencies）和我们的业务代码，这些都在我们的控制之下，我们可以确保应用程序的安全性，并且在 Pipeline 上获得快速反馈；同时在我们将应用程序部署到生产环境之前可以通过使用各种工具建立信心。但是，通常情况下我们的应用程序运行的系统环境是不受我们控制的，可能存在潜在的安全漏洞。在这我们可以换位思考一下，如果我们不能保证我们的应用程序运行的系统的环境安全，就会导致各种各样意想不到的问题，如黑客攻击、用户信息泄露、财产损失，更会对公司的声誉造成损害。所以，确保我们产出物（Artifact）的安全是很重要的。

保持容器镜像安全的两个方案

方案1：在镜像注册表中定期扫描

通过这种方式，我们需要为镜像注册表添加一个安全扫描程序，扫描程序可以是一个定时任务（Cron Job）作业，也可以是由特定的人触发的可执行操作。

如果是一个定时任务，它将在特定时刻由定时任务自动触发。例如，Docker Hub 会在特定的时间扫描他们的官方注册表，当有任何漏洞被扫描出来时，它会向镜像维护者发送报警信息。

方案2：将扫描工具集成到 Pipeline 中

另一种方法是在 Pipeline 上对镜像产物进行扫描，这样更加简单高效。当我们将代码推送到代码存储库时， Pipeline 将自动执行扫描镜像的命令。因为 Pipeline 每次都是无差别地执行，所以我们可以发现任何安全问题并及时报警修复。

现在，越来越多的团队或公司使用敏捷来开发他们的项目。如果我们能够尽早地发现任何安全问题或者漏洞，我们就可以在产品发布之前降低产品的安全风险。 Pipeline 是确保每一行代码和基础运行环境的安全性是的最好方法之一，因为它可以在提交代码时自动执行。

容器安全扫描工具对比

针对上述解决方案，我们调查了 Trivy、Claire、Anchore Engine、Quay、Docker hub 和 GCR 等几种扫描工具，从不同维度进行对比。

参考 Trivy 官网

首先，我们可以将这些扫描工具按照其执行的环境简单分类；因为 Docker Hub、GCR 和 Quay 是需要在服务端也就是容器注册中心运行的，所以适合方案1； Trivy、Clair 和 Anchor Engine 可以在 Pipeline 上工作，所以适合解决方案2。

对于第一个维度：OS Package，这些所有的扫描工具都可以做到，但是对于第二个维度：Application dependencies，只有 Trivy 和 Anchore Engine 可以做到，对于第五个维度: Suitable for CI, 只有前三个符合条件。

对于漏洞数据库的更新，Clair 会定期从一组配置的源中获取漏洞元数据库（Vulnnerability Database），并将数据存储在其数据库中，只要不获取最新的漏洞元数据，每次执行都用之前的漏洞数据库，漏洞数据库的时效性有点差。 Trivy 和 Anchore Engine 则是每次运行都将下载最新的漏洞数据库并将其缓存在本地文件中，当扫描工具再次运行时，它将检查并更新数据库以保持数据库为最新状态。

同时，对于 Trivy、Clair 和 Anchore Engine，这三者的社区非常活跃，所以我们不能用没有人来帮你解决你的问题来评判；而且作为一种工具，它必须易于使用并且有良好的文档可供参考。经过调研，发现 Trivy 的文档非常详细，非常友好，而且 Trivy 的使用方式更加友好，比如我们可以过滤掉（.trivyignore）你指定的漏洞，对于最新发现的漏洞，官方没有给出修复版本，这时候我们就可以忽略这个漏洞继续构建，但 Anchore Engine 做不到。

2020年3月16日，领先的云原生应用和基础设施安全平台供应商 Aqua Security 宣布，其开源的 Trivy 漏洞扫描器将作为一个集成选项添加到其使用的云原生平台、CNCF 的 Harbor 注册表和 Mirantis Docker Enterprise 中。你可以在这里找到这篇文章。

Trivy集成到流水线中的使用方法

Trivy 支持多种扫描方式，如扫描容器镜像、Git 仓库和文件系统等；下面，我们使用 GitHub Actions 以 Docker 运行 Trivy 扫描构建好的镜像产出物来展示 Trivy 的强大之处，下面是 GitHub Actions 的部分代码：

   - name: Trivy scanner
  run: |
         docker run --rm -v 
/var/run/docker.sock:/var/run/docker.sock \
           aquasec/trivy image --severity HIGH,CRITICAL 
--exit-code 1 dashboard:${{ github.sha }}

在这需要对以下几个参数做特别说明：

-v /var/run/docker.sock:/var/run/docker.sock 如果想扫描本地主机上的镜像，需要挂载 docker.sock
--severity 设置要扫描的漏洞级别
--exit-code 发现漏洞时 Trivy 的退出状态(默认值：0)；在 Pipeline 中，如果将该值设置为1，且有漏洞被发现，则 Pipeline 将退出，而不会继续运行。如果将其设置为0，则 Pipeline 将继续运行，但会报告结果。所以，如果你想在发现漏洞后阻止 Pipeline 继续执行，可以设置它为1。

想了解更多关于参数和使用方法的信息，请访问 Trivy 的官方网站： https://github.com/aquasecurity/trivy。

总结

无论你在哪里，安全都是一个非常重要的问题。我们可以将 “安全左移（Shift Left Security）”，这样就可以减少生产环境中的安全风险；对于扫描工具 Trivy 来说，它对于保证镜像的安全性非常有用，它不仅可以扫描镜像，还可以扫描 Git 仓库，文件系统等。
最后，非常感谢同事张思楚、王亦晨和邢砚敏等人的大力支持和指导，在他们热心帮助和辛苦付出之下才有了这篇文章。

[原]btrace 开源！基于 Systrace 高性能 Trace 工具

Thu, 30 Dec 2021 15:24:06 CST

介绍

btrace（又名 RheaTrace）是抖音基础技术团队自研的一款高性能 Android Trace 工具，它基于 Systrace 实现，并针对 Systrace 不足之处加以改进，核心改进点如下。

效率提升：编译期间为 App 方法自动注入自定义事件，并提供高效、灵活配置规则。
性能提升：改进 Systrace 文件实时写 atrace 数据方式，性能提升最大 400 % 以上。
实用性提升：额外提供更详细 IO 等数据，大幅提升方法耗时归因效率；使用独创方案彻底来解决方法因执行异常引起 trace 数据不闭合问题。

项目地址：

https://github.com/bytedance/btrace

目前字节跳动已有多款 App 接入，包括抖音、TikTok、今日头条、幸福里等均已接入 RheaTrace，并为其体验优化提供强有力支持。借助 RheaTrace 将为您的 App 带来极致流畅体验，RheaTrace 使用效果如下（因保密原则，每个方法用 ID 表示）。

Systrace 简介

如果我们使用过 Systrace 分析应用性能，我们都知道 Systrace 提供 Category 配置让用户决定采集哪些系统 atrace 数据，如下命令，从 sched 开始后续是不同类别的 atrace 数据。

   python systrace.py -o mynewtrace.html sched freq idle am wm gfx view \
    binder_driver hal dalvik camera input res

atrace 的数据类型见下图：

其中，用户空间 atrace 类型包括应用层自定义 Trace 事件、系统层 gfx 渲染相关 Trace、系统层锁相关 Trace 信息等，其最终都是通过调用 Android SDK 提供 Trace.beginSection 或者 ATRACE_BEGIN 记录到同一个文件 /sys/kernel/debug/tracing/trace_marker 中。此节点允许用户层写入数据，ftrace 会记录该写入操作时间戳。当用户层发生函数调用时，ftrace 可以记录被跟踪函数的运行时间。atrace 若需记录用户层某一 trace 类型，只需激活对应 TAG 类型即可。如选择 gfx，则会激活 ATRACE_TAG_GRAPHICS，并将渲染事件记录到 trace_marker 文件中。

内核空间的数据主要是一些补充分析数据，如 freq、sched、binder 等，常用 CPU 调度相关信息包括：

CPU 频率变化情况。
任务执行情况。
大小核调度情况。
CPU Boost 调度情况。

关于图中一些标签释义。

CPU 使用率：右边柱状图越高，表明使用率越高。
CPU 序号：标识 CPU 核心序号，表示该设备有 8 个核心，编号 0 -7。
CPU 频率：右边对应的粉色柱状图表示其频率变化趋势。
调度任务：标识在该 CPU 核心上正在运行的任务，点击任务可查看其 ID、优先级等信息。

这些信息 App 可以直接读取 /sys/devices/system/cpu 节点下相关信息获得，而另外一部分标识线程状态信息则只能通过系统或者 adb 才能获取，且这些信息不是统一节点控制，需要激活各自对应的事件节点，让 ftrace 记录下不同事件的 tracepoint。内核在运行时，根据节点的使能状态，会往 ftrace 缓冲中记录事件。

例如，激活线程调度状态信息记录，需要激活类似如下相关节点。

   events/sched/sched_switch/enable
events/sched/sched_wakeup/enable

激活后，则可以获取到线程调度状态相关的信息，比如：

Running: 线程在正常执行代码逻辑。
Runnable: 可执行状态，等待调度，如果长时间调度不到，说明 CPU 繁忙。
Sleeping: 休眠，一般是在等待事件驱动。
Uninterruptible Sleep: 不可中断的休眠，需要看 Args 描述来确定当时状态。
Uninterruptible Sleep - Block I/O: IO 阻塞。

最终，上述两大类事件记录都汇集到内核态同一缓冲中， Systrace 工具是通过指定抓取 trace 类别等参数，然后触发手机端 /system/bin/atrace 开启对应文件节点信息，接着 atrace 会读取 ftrace 缓存，生成只包含 ftrace 信息的 atrace_raw 信息，最终通过脚本转换成可视化 HTML 文件，大致流程如下。

RheaTrace 揭秘

本章节将从 RheaTrace 重点优势一一介绍。

Systrace 源码分析

Systrace 提供 Trace#beginSection(String) 和 Trace.endSection() 采集 atrace 数据，首先，我们大致了解下 atrace 工作原理，以 android.os.Trace#beginSection 作为分析入口。

   public static void beginSection(@NonNull String sectionName) {
    if (isTagEnabled(TRACE_TAG_APP)) {
        if (sectionName.length() > MAX_SECTION_NAME_LEN) {
            throw new IllegalArgumentException("sectionName is too long");
        }
        nativeTraceBegin(TRACE_TAG_APP, sectionName);
    }
}

android.os.Trace#beginSection 会调用 nativeTraceBegin 方法，该方法实现参考 frameworks/base/core/jni/android_os_Trace.cpp。

   static void android_os_Trace_nativeTraceBegin(JNIEnv* env, jclass,
        jlong tag, jstring nameStr) {
    withString(env, nameStr, [tag](char* str) {
        atrace_begin(tag, str);
    });
}

atrace_begin 方法实现参考 system/core/libcutils/include/cutils/trace.h。

   #define ATRACE_BEGIN(name) atrace_begin(ATRACE_TAG, name)
static inline void atrace_begin(uint64_t tag, const char* name)
{
    if (CC_UNLIKELY(atrace_is_tag_enabled(tag))) {
        void atrace_begin_body(const char*);
        atrace_begin_body(name);
    }
}

atrace_begin_body 方法实现参考 system/core/libcutils/trace-dev.cpp。

   void atrace_begin_body(const char* name)
{
    WRITE_MSG("B|%d|", "%s", name, "");
}

atrace_begin_body 最终实现在宏 WRITE_MSG 实现，代码如下：

   #define WRITE_MSG(format_begin, format_end, name, value) { \
    ...
    write(atrace_marker_fd, buf, len); \
}

通过 WRITE_MSG 实现，可知，atrace 数据是实时写入 fd 为 atrace_marker_fd 的文件中，如果多线程同时写入，则会出现锁问题，导致性能损耗加大。

RheaTrace 核心优势

效率提升

RheaTrace 会在 App 编译期间自动插入 Trace 跟踪函数，大大提高效率。针对不同 Android Gradle Plugin 版本，我们支持 Proguard 之后插桩，这样可以减少 App 方法插桩量，同时也过滤 Empty、Set/Get 等简单方法。

思路基于 matrix-gradle-plugin 大量改造实现。

   rheaTrace {

   compilation {
      //为每个方法生成唯一 ID，若为 true，Trace#beginSection(String) 传入的是方法 ID。
      traceWithMethodID = true
      //决定哪些包名下的类您不需要做性能跟踪。
      traceFilterFilePath = "${project.rootDir}/rhea-trace/traceFilter.txt"
      //一些特定方法保持 ID 值固定不变。
      applyMethodMappingFilePath = "${project.rootDir}/rhea-trace/keep-method-id.txt"
   }
   runtime {
        ......
   }
}

为减少包体积、性能影响，我们也借鉴 matrix 慢函数思路，支持为每个函数生成唯一 ID， traceWithMethodID 为 true， Trace#beginSection(String)传入的是方法 ID，不再是方法名。有时候我们想某些方法 ID 固定不变，同样借鉴 matrix 慢函数思路，我们提供 applyMethodMappingFilePath 配置规则文件路径。
为进一步减少 App 方法插桩量，我们提供 traceFilterFilePath 文件配置让您决定哪些包、类、方法不做自定义事件跟踪，关于其用法请参考 RheaTrace Gradle Config。

性能提升

在 Systrace 概述中，我们了解到 atrace 数据是实时写入文件，且存在多线程同时写入带来的锁问题。因此，我们采取策略是拿到 atrace 文件 fd，在 atrace 数据写入前，先将其写至 LockFreeRingBuffer内存中，然后再将循环读取内存中 atrace 数据，写入我们定义的文件中。

首先我们通过 dlopen 获取 libcutils.so 对应句柄，通过对应 symbol 从中找到 atrace_enabled_tags 和 atrace_marker_fd 对应指针，设置 atrace_enabled_tags 用以打开 atrace，代码实现片段如下。

   int32_t ATrace::InstallAtraceProbe() {
  ......
  {
    std::string lib_name("libcutils.so");
    std::string enabled_tags_sym("atrace_enabled_tags");
    std::string marker_fd_sym("atrace_marker_fd");

    ...
    ...
    atrace_marker_fd_ = reinterpret_cast<int*>(
        dlsym(handle, marker_fd_sym.c_str()));

    if (atrace_marker_fd_ == nullptr) {
      ALOGE("'atrace_marker_fd' is not defined");
      dlclose(handle);
      return INSTALL_ATRACE_FAILED;
    }
    if (*atrace_marker_fd_ == -1) {
      *atrace_marker_fd_ = kTracerMagicFd;
    }
  dlclose(handle);
  return OK;
  }

思路参考 profilo#installSystraceSnooper，本文不做过多介绍。

接着，通过 PLT Hook libcutils.so 中 write、write_chk 方法，判定该方法传入 fd 是否与 atrace_marker_fd 一致，若一致，则将 atrace 数据写入我们定义的文件中。

   ssize_t proxy_write(int fd, const void* buf, size_t count) {
  BYTEHOOK_STACK_SCOPE();

  if (ATrace::Get().IsATrace(fd, count)) {
    ATrace::Get().LogTrace(buf, count);
    return count;
  }
  ...

  ATRACE_END();
  return ret;
}

有时候，我们可能仅需要关注主线程 atrace 数据，如果能将子线程 atrace 数据过滤掉，那么整体性能将进一步提升。一种很简单的思路，就是将 Trace#beginSection(String) 包装一层，如下代码片段。

   static void t(String methodId) {
    if (!isMainProcess) {
        return;
    }
    if (mainThreadOnly) {
        if (Thread.currentThread() == sMainThread) {
            Trace.beginSection(methodId);
        }
    } else {
        Trace.beginSection(methodId);
    }
}

该方法仅能过滤我们为 App 方法插桩的 atrace 数据，系统层 atrace 数据无法过滤。为更彻底实现仅采集主线程数据，我们通过 PLT Hook 代理 atrace_begin_body 和 atrace_end_body 实现，在该方法进入前，判断当前线程 id 是否为主线程，如果不是，则不记录该条数据，代码实现片段如下。

   void proxy_atrace_begin_body(const char *name) {
    BYTEHOOK_STACK_SCOPE();
    if (gettid() == TraceProvider::Get().GetMainThreadId()) {
        BYTEHOOK_CALL_PREV(proxy_atrace_begin_body, name);
    }
}

void proxy_atrace_end_body() {
    BYTEHOOK_STACK_SCOPE();
    if (gettid() == TraceProvider::Get().GetMainThreadId()) {
        BYTEHOOK_CALL_PREV(proxy_atrace_end_body);
    }
}

针对降低性能损耗，RheaTrace 提供编译配置供用户选择，针对不同使用场景配置合理参数。

   rheaTrace {
    ......

    runtime {
        mainThreadOnly false
        startWhenAppLaunch true
        atraceBufferSize "500000"
    }
}

上述配置释义如下。

mainThreadOnly：为 true 表示仅采集主线程 trace 数据。
startWhenAppLaunch：是否 App 启动开始就采集 trace 数据。
atraceBufferSize：指定内存存储 atrace 数据 ring buffer 的大小，如果其值过小会导致 trace 数据写入不完整，若您抓取多线程 trace 数据，建议将值设为百万左右量级；最小值为 1 万，最大值为 5 百万。

实用性提升

针对已有的 atrace 数据，额外拓展 IO 等信息；另外为通过 Python 脚本彻底解决方法因执行异常导致 trace 数据闭合异常问题，保证每个方法 trace 数据的准确性。

目前我们基于 JVMTI 方案，在 Android 8.0 及以上设备可以获取类加载以及内存访问相关 trace 数据，目前仅支持编译类型为 debuggable 的 App，目前处于实验功能，本文暂先不过多介绍。

IO 数据拓展

背景简介

在抖音启动性能优化时，我们曾统计冷启动的耗时，其中占比最长的是进程处于 D 状态（不可中断睡眠态，Uninterruptible Sleep ，通常我们用 PS 查看进程状态显示 D，因此俗称 D 状态）时间。此部分耗时占总启动耗时约 40%，进程为什么会被置于 D 状态呢？处于 uninterruptible sleep 状态的进程通常是在等待 IO，比如磁盘 IO，其他外设 IO，正是因为得不到 IO 响应，进程才进入 uninterruptible sleep 状态，所以要想使进程从 uninterruptible sleep 状态恢复，就得使进程等待 IO 恢复，类似如下。

但在使用 Systrace 进行优化时仅能得到如上内核态的调用状态，却无法得知具体的 IO 操作是什么。

方案介绍

因此，我们专门设计一套获取 IO 耗时信息方案，其包括用户空间和内核空间两部分。

一是在用户空间，为采集所需 IO 耗时信息，我们通过 Hook IO 操作标准函数簇，包括 open，write，read，fsync，fdatasync 等，插入对应 atrace 埋点用于统计对应的 IO 耗时，以 fsync 为例。

其对应 hook 代码逻辑如下：

   int proxy_fsync(int fd) {
  BYTEHOOK_STACK_SCOPE();
  ATRACE_BEGIN_VALUE("fsync:", FileInfo(fd).c_str());

  int ret = BYTEHOOK_CALL_PREV(proxy_fsync, fd);

  ATRACE_END();
  return ret;
}

二是在内核空间，除 systrace 或 atrace 可直接支持启用功能外，ftrace 还提供其他功能，并包含对调试性能问题至关重要的一些高级功能（需要 root 访问权限，通常也可能需要新内核）。我们基于此添加显示定制 IO 信息等功能，开启 /sys/kernel/debug/tracing/events/android_fs节点下 ftrace 信息，用于收集 IO 相关的信息。内核空间 IO 信息是通过 python 脚本开启，详见 io_extender.py。

解决方法闭合错误问题

背景介绍

RheaTrace 会自动在每个方法入口、出口处分别插入 Trace#beginSection(String) 和 Trace#endSection() ，一个方法有且只有一个入口，但会有多个出口，方法出口对应的结束字节码指令有 return 和 throw 等。

   public static void testCrash() {
        try {
            testA();
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    public static void testA() {
        testB();
        testC();
    }

    public static void testB() {
        int ret = 2 / 0; // <----- crash event
        testD(ret);
    }

    public static void testC() {
        Log.d("btrace", "do some things.");
    }

    public static void testD(int num) {
        Log.d("btrace", "box size: " + num);
    }

上面的代码很简单，即 testCrash -> testA -> testB，其中 testB 出现异常，最终是在 testCrash 中捕获。通过本示例可知，testA、testB 方法出口均未正常执行完成，这也就导致 trace 数据不闭合，生成的 trace 数据如下，从中可以看出，B 和 E 数量上并不匹配，且仅从 trace 上看，我们也无法知道 E 属于哪个方法。

   5108949.231989: B|28045| TestCrash:a
5108949.232055: B|28045| TestCrash:b
5108949.232554: B|28045| TestCrash:c
5108949.232580: E|28045

方案介绍

为解决该问题，RheaTrace 做了取巧处理，方法的出口由插入 Trace#endSection()改为 Trace#beginSection(String)。那我们如何知道哪条 trace 是开始，哪条是结束？我们看如下示例。

   5108949.231989: B|28045|B:TestCrash:a
5108949.232055: B|28045|B:TestCrash:b
5108949.232554: B|28045|B:TestCrash:c
5108949.232580: B|28045|E:TestCrash:a

如上 trace 数据，每个方法描述前都会加上 B: 或 E、 T, B: 表示方法开始，E 表示方法 retrun 结束， T: 表示方法 throw 结束。然后通过 Python 脚本处理并还原正常 trace 数据。如此做以后，我们就可以明确知道方法开始和结束，同时针对异常结束方法，我们会做补全处理，处理后的 trace 数据如下。

   5108949.231989: B|28045|TestCrash:a
5108949.232055: B|28045|TestCrash:b
5108949.232554: B|28045|TestCrash:c
5108949.232554: E|28045|TestCrash:c
5108949.232554: E|28045|TestCrash:b
5108949.232580: E|28045|TestCrash:a

关于 Python 脚本的处理过程，本文不做过多介绍，大家可以阅读相关源码即可。

RheaTrace 工作流程

流程概述

RheaTrace 作为线下性能分析利器，我们首先看下其整体工作流程。

如上文介绍，我们将 Systrace 中 atrace 数据做拦截，将其转存至我们自定义的文件中。

Systrace 格式

首先我们 Systrace 生成的 trace.html 中 atrace 数据格式。

   <idle>-0     (-----) [001] d.h4 1308823.803921: sched_waking: comm=TimerDispatch pid=704 prio=97 target_cpu=001
          <idle>-0     (-----) [001] dnh5 1308823.803929: sched_wakeup: comm=TimerDispatch pid=704 prio=97 target_cpu=001
          <idle>-0     (-----) [001] d..2 1308823.803943: sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=TimerDispatch next_pid=704 next_prio=97
          <idle>-0     (-----) [003] d.s3 1308823.803980: sched_waking: comm=kworker/3:0 pid=11120 prio=120 target_cpu=003
          <idle>-0     (-----) [003] d.s4 1308823.803986: sched_blocked_reason: pid=11120 iowait=0 caller=worker_thread+0x4fc/0x804
   TimerDispatch-704   (  643) [001] .... 1308823.803988: tracing_mark_write: B|643|TimerIteration #9392
          <idle>-0     (-----) [003] dns4 1308823.803988: sched_wakeup: comm=kworker/3:0 pid=11120 prio=120 target_cpu=003
   TimerDispatch-704   (  643) [001] .... 1308823.803992: tracing_mark_write: E|643
          <idle>-0     (-----) [003] d..2 1308823.803997: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=kworker/3:0 next_pid=11120 next_prio=120
   TimerDispatch-704   (  643) [001] .... 1308823.804011: tracing_mark_write: C|643|VSP-mode|0
   TimerDispatch-704   (  643) [001] .... 1308823.804014: tracing_mark_write: C|643|VSP-timePoint|405332069786762
   TimerDispatch-704   (  643) [001] .... 1308823.804016: tracing_mark_write: C|643|VSP-prediction|405332075389317
   TimerDispatch-704   (  643) [001] .... 1308823.804022: tracing_mark_write: B|643|app-alarm in:5602555 for vs:15880333
   TimerDispatch-704   (  643) [001] .... 1308823.804024: tracing_mark_write: E|643

文本形式打开 trace.html，在其底部是填充的 trace 数据，如上所示数据片段，带有 tracing_mark_write 标签的即包含 atrace 数据。在 trace.html 文件中有关于 trace 格式介绍，如下数据片段。

   # tracer: nop
#
# entries-in-buffer/entries-written: 178063/178063   #P:8
#
#                                      _-----=> irqs-off
#                                     / _----=> need-resched
#                                    | / _---=> hardirq/softirq
#                                    || / _--=> preempt-depth
#                                    ||| /     delay
#           TASK-PID    TGID   CPU#  ||||    TIMESTAMP  FUNCTION
#              | |        |      |   ||||       |         |
          <idle>-0     (-----) [003] d.s2 1308814.493991: sched_waking: comm=rcu_preempt pid=9 prio=120 target_cpu=003
          <idle>-0     (-----) [000] d.s2 1308814.493997: sched_waking: comm=rcu_sched pid=10 prio=120 target_cpu=000

在 trace.html 中，一条完整的 atrace 数据为：

   .sample.android-19452 (19452) [005] .... 1308823.801863: tracing_mark_write: B|19452|activityStart
......
.sample.android-19452 (19452) [005] .... 1308824.801753: tracing_mark_write: E|19452

在上文介绍 Systrace 时候，我们提到， Trace#beginSection(String) 和 Trace.endSection() 最终是调用如下宏。

   #define WRITE_MSG(format_begin, format_end, name, value) { \
    ...
    write(atrace_marker_fd, buf, len); \
}

其中， write 函数传入的 trace 数据为：

   B|19452|activityStart
......
E|19452

B 表示 Section 进入， E 表示 Section 退出，从以上数据片段可以看出，相较于 trace.html 中 atrace 数据少了很多信息，缺少的信息是内核补全。

Systrace 工具中 --from-file 是可以将原始 atrace 数据转化为可视化的 html 文件。因此，针对 atrace 数据我们需要补全缺少的信息。结合前面介绍的 trace 格式说明及多次验证，可被 Systrace 工具识别的 atrace 文件格式满足如下：

   <ThreadName>-<TheadID> [001] ...1 <Timestamp>: trace_mark_write:<B|E>|<ProcessID>|<TAG>

格式说明：

<ThreadName>：线程名，若为主线程，可指定为包名。
<ThreadID>：线程 ID。
<Time seconds>：方法开始或者结束时间戳。
<B|E>：标记该条记录为方法开始(B)还是结束(E)。
<ProcessID>：所在进程 ID。
<TAG>：方法标记，字符长度不可超过 127。

[001] 和 ...1 对应的数据用户层是无法获取，因此硬编码写死。

RheaTrace 格式

Systrace 中相关 atrace 数据格式有很多冗余信息，冗余信息是可以通过脚本来进行补充，这样在 atrace 存储过程中可以减少一定数据量的存储。

仅采集主线程 atrace 数据，其对应格式如下：

   1306401.857369: B|16667|VerifyClass com.bytedance.rheatrace.atrace.TraceEnableTagsHelper
1306401.857498: E|16667
1306401.857560: B|16667|VerifyClass com.bytedance.rheatrace.common.ReflectUtil
1306401.857825: E|16667
1306401.857876: B|16667|VerifyClass kotlin.jvm.internal.Intrinsics
1306401.858241: E|16667
1306401.858523: B|16667|VerifyClass com.bytedance.rheatrace.core.RheaNoticeManager
1306401.858633: E|16667

因为 RheaTrace 仅支持采集主进程 trace 数据，因此，进程 ID 信息无需写入，另外主线程名为包名也无需写入，主线程 ID 与进程 ID 一致也无需写入，剩余信息均为格式模板信息也无需写入，唯一需要记录的是时间戳。

采集所有线程 atrace 数据，其对应格式如下。

   1306401.859162 16667: B|16667|RheaApplication#onCreate
1306401.859173 16667: E|16667
1306401.859756 16667: E|16667
1306401.859877 16667: B|16667|activityStart
1306401.862738 16680: B|16667|JIT compiling int sun.util.locale.StringTokenIterator.nextDelimiter(int) (baseline=0, osr=0)
1306401.862772 16680: B|16667|Compiling
1306401.863154 16680: B|16667|ScopedCodeCacheWrite
1306401.863172 16680: B|16667|mprotect all
1306401.863207 16680: E|16667

当采集多线程数据时，我们需要获取对应的线程 ID，线程名我们没有通过在 App 期间获取，而是读取 Systrace 工具生成 trace.html 中读取。如下数据片段，我们可以获取进程 ID 为 16667 对应的所有线程 ID 及名称。当然也会存在线程 ID 如下数据片段找不到的情况，我们暂时用 <...>代替。

   USER            PID   TID CMD
root              1     1 init
root              1   548 init
root              2     2 kthreadd
root              3     3 rcu_gp
root              5     5 kworker/0:0H
root              7     7 mm_percpu_wq
root              8     8 ksoftirqd/0
root              9     9 rcu_preempt
root             10    10 rcu_sched
root             11    11 rcu_bh
.....
u0_a168       16667 16684 FinalizerWatchd
u0_a168       16667 16685 Binder:16667_1
u0_a168       16667 16686 Binder:16667_2
u0_a168       16667 16687 Binder:16667_3
u0_a168       16667 16688 Profile Saver
u0_a168       16667 16689 async-writer
u0_a168       16667 16690 RenderThread
u0_a168       16667 16693 HWC release
u0_a168       16667 16694 GPU completion

通过 RheaTrace 提供的脚本，我们就可以将原始 atrace 数据加工为标准 atrace 格式，如下数据片段。

   .sample.android-16667 [001] ...1 1306401.857369: tracing_mark_write: B|16667|VerifyClass com.bytedance.rheatrace.atrace.TraceEnableTagsHelper
 .sample.android-16667 [001] ...1 1306401.857498: tracing_mark_write: E|16667
 .sample.android-16667 [001] ...1 1306401.857560: tracing_mark_write: B|16667|VerifyClass com.bytedance.rheatrace.common.ReflectUtil
 .sample.android-16667 [001] ...1 1306401.857825: tracing_mark_write: E|16667
 .sample.android-16667 [001] ...1 1306401.857876: tracing_mark_write: B|16667|VerifyClass kotlin.jvm.internal.Intrinsics
 .sample.android-16667 [001] ...1 1306401.858241: tracing_mark_write: E|16667
 .sample.android-16667 [001] ...1 1306401.858523: tracing_mark_write: B|16667|VerifyClass com.bytedance.rheatrace.core.RheaNoticeManager
 .sample.android-16667 [001] ...1 1306401.858633: tracing_mark_write: E|16667

当通过 Systrace 命令获取 trace.html 后，trace.html 中的 atrace 因为被 RheaTrace 拦截写入自定义文件中，因此生成的 trace.html 文件中是不包含 atrace 数据。

如果不包含 atrace，那么 trace.html 的作用将非常小，因此，我们需要将 atrace 数据填充进入 trace.html 中，经过验证 atrace 数据满足如下格式，能够被 trace.html 识别。

   <ThreadName>-<TheadID> (ProcessID) [001] ...1 <Timestamp>: trace_mark_write:<B|E>|<ProcessID>|<TAG>

相较于标准 atrace 文件，它多了 (ProcessID)数据。

有了上述介绍，我们介绍下 RheaTrace 生成的 systrace.html 中间会生成哪些文件。

   python rheatrace.py -a rhea.sample.android -t 3 -o ./output/systrace.html

在 systrace.html 同级目录下会生成 .build 目录，其中包括上述中间产物文件。

   ├── .build
│   ├── atrace-standard          //标准 atrace 格式，可直接用 perfetto 打开。
│   ├── rhea-atrace              //从设备中拉取的 rhea-atrace.gz 文件解压得到，原始 RheaTrace 格式的 atrace 数据。
│   ├── systrace-fs-origin.html  //如果设备 root，其中会包括内核 IO 事件，前文有提到。
│   └── systrace-origin.html     //通过 Systrace 工具抓取的可视化 trace 文件，不包含 atrace 数据。
└── systrace.html                //atrace-standard 与 systrace-fs-origin.html 或 systrace-origin.html 合并得到。

未来规划

支持 App 独立抓取 atrace 数据，无需依赖 Systrace 环境。
提供稳定、高效的 trace 采集环境，适配更多手机机型。
支持更多维度的 trace 信息，比如渲染、内存等，更方便定位函数耗时原因。
进一步降低性能损耗，到达线上使用要求。

作者：ByteDanceTech 发表于 2021/12/30 15:24:06 原文链接 https://blog.csdn.net/ByteDanceTech/article/details/122248282

阅读：33

超级好用的免费开源文件同步工具：Syncthing

Mon, 27 Dec 2021 10:09:20 CST

相信不少小伙伴跟TJ君有一样的经历，当然相信也会有小伙伴是因为更换设备导致的文件丢失，不管怎么说，临时用用还行，平时大家还是不要把重要的文件直接存储在微信上，还是该备份的备份，该传输到本地的传输。存到网盘？你确定不开通个VIP那上传下载速度能用？

那么今天的问题就来了，平时大家都用什么文件传输工具呢？

今天TJ君要和大家分享的就是一款免费、开源的文件同步工具， Syncthing

作为一款P2P性质的文件同步工具，Syncthing在Github上广受欢迎，已经收获了42k的Star！

Syncthing有五大特点：

1、避免数据丢失
2、安全防范攻击者
3、便捷使用
4、自动化运行
5、高兼容性

像Windwos、macOS、Android、Linux这些主流平台都支持Syncthing，所以Syncthing可以跨平台的进行文件传输。

目前最新的版本是v1.18.5版本，在18天前更新，说明作者也一直在优化迭代。

以windows为例，只需要安装好Syncthing电脑端的应用程序，打开浏览器访问 http://127.0.0.1:8384/ 就可以进入 Syncthing传输平台。

如果在其他设备，例如手机端也安装完Syncthing，便会有同步提示，通过后就可以进行文件传输了。速度很快哦！

不知道大家有没有从TJ的图中发现，虽然Syncthing的开源项目都是英文描述，但是其使用界面却是中文的，算不算也是给我们大天朝的一个小小的福利呢？想试试这款工具传输文件进行备份的小伙伴们，赶紧来试试吧！

扫描下方二维码，关注公众号“TJ君”，回复“Syncthing”，获取仓库地址！

尝试解析下 Epub.js：一个在浏览器上渲染 Epub 图书的工具

Sat, 20 Nov 2021 00:00:00 CST

一直在看 Epub 类型的图书，很好奇一个 Epub 解析器是如果工作的。碰巧看到了 Epub.js，体验了一下还可以。就尝试分析一下它的实现。本文会先介绍下 EPUB 格式,再来分析 Epubjs 的实现. 我前端经验仅限于了解常见标签含义，可能会有各种错误恳请斧正。

Epub

EPub是一个自由的开放标准，属于一种可以“自动重新排版”的内容；也就是文字内容可以根据阅读设备的特性，以最适于阅读的方式显示。EPub档案内部使用了XHTML或DTBook（一种由DAISY Consortium提出的XML标准）来展现文字、并以zip压缩格式来包裹档案内容。EPub格式中包含了数位版权管理（DRM）相关功能可供选用

以上来自维基百科: https://zh.wikipedia.org/wiki/EPUB

本文参考的规范为: Epub 3.2该规范发布于 2019-05-08, 定义了 EPUB 图书格式和 EPUB 图书的浏览器应实现的功能. Epub格式由以下规范组成:

EPUB Packages — 定义内容的每个Rendition的要求。
EPUB Content Documents — 定义了在 EPUB 出版物上下文中使用的 XHTML、SVG 和 CSS 的配置文件。
EPUB Media Overlays — 定义了文本和音频同步的格式和处理模型。
EPUB Open Container Format — 定义了一种文件格式和处理模型，用于将一组相关资源封装到单个文件 (ZIP) EPUB 容器中。
EPUB Accessibility — 定义 EPUB 出版物的可访问性一致性和发现要求。

如下图: EPUB图书的内容是由一个或多个Rendition组成，每个Rendition都由所谓的EPUB Package 表示。 EPUB Package包含呈现内容所需的所有资源。其中的关键文件是Package Document，它包括阅读系统用于向用户呈现EPUB图书的所有元数据（例如标题和作者等）。它还提供了一个完整的资源清单，并包括一个 SPINE(用来表是文档出现的顺序)。 EPUB Package还包括另一个称为EPUB Navigation Document的文件。本文档提供了导航功能，例如目录，允许用户快速轻松地导航内容。 EPUB 图书的资源捆绑在一个基于 ZIP 的文件中，文件扩展名为.epub. 作为符合 ZIP 格式的文件，EPUB 出版物可以被许多软件程序解压缩，从而简化了它们的使用。

参考规范来制作一个简单Epub 图书

按照下图的方式来组织目录和文件

mimetype 文件名固定, 内容也固定位: `application/epub+zip`

META-INF/container.xml 为入口文件,文件名固定.

内容如下: 其中rootfile指定了package file

    <?xml version='1.0' encoding='utf-8'?><containerxmlns="urn:oasis:names:tc:opendocument:xmlns:container"version="1.0"><rootfiles><rootfilefull-path="OPS/package.opf"media-type="application/oebps-package+xml"/></rootfiles></container

OPS/package.opf

Package 文件, 定义了书籍的 meta 信息, 资源列表和阅读顺序(Spine) 内容如下:

metadata: 标签定义的作者等信息
manifest: 定义了资源列表,如正文页面, 目录, 封面图片, CSS, JS 等等
spine: 定义了书籍连续阅读的顺序.
- Liner 代表顺序是否为必要顺序. 如目录和封面不一定强制按照这个顺序来阅读. 或者说是在做阅读器是可以把 Liner=no页面弹窗
- 和目录/书签最显著的区别, Spine 是按照资源文件来组织循序. 目录/书签等是可以指定到资源内的标签.

    <?xml version='1.0' encoding='utf-8'?><packagexmlns="http://www.idpf.org/2007/opf"unique-identifier="uuid_id"version="3.2"prefix="calibre: https://calibre-ebook.com"><metadataxmlns:dc="http://purl.org/dc/elements/1.1/"><dc:titleid="id">Calvin用来演示 EPUBJS 的书</dc:title><dc:creatorid="Creator">Calvin Wang</dc:creator><dc:identifierid="uuid_id">urn:uuid:5F1E4C07-2A52-48BC-BBA5-E98564559794</dc:identifier><dc:language>zh-CN</dc:language><metaproperty="dcterms:modified">2021-11-14T08:32:29Z</meta></metadata><manifest><itemid="cover"href="cover.xhtml"media-type="application/xhtml+xml"/><itemid="toc"properties="nav"href="toc.xhtml"media-type="application/xhtml+xml"/><itemid="firstpage"href="first_page.xhtml"media-type="application/xhtml+xml"/><itemid="secondpage"href="second_page.xhtml"media-type="application/xhtml+xml"/><itemid="ncxtoc"href="toc.ncx"media-type="application/x-dtbncx+xml"/><itemid="cover-image"properties="cover-image"href="images/cover.png"media-type="image/png"/></manifest><spinetoc="ncxtoc"><itemrefidref="cover"linear="no"/><itemrefidref="toc"linear="no"/>ß<itemrefidref="firstpage"linear="yes"/><itemrefidref="secondpage"linear="yes"/></spine></package>

其他页面

    <--!CoverPage--><?xml version="1.0" encoding="UTF-8"?><htmlxmlns="http://www.w3.org/1999/xhtml"xmlns:epub="http://www.idpf.org/2007/ops"><head><title>Cover Page</title><metacharset="utf-8"/></head><body><div><imgsrc="images/cover.png"alt="Cover Image"title="Cover Image"/></div></body></html><--!firstpage--><?xml version="1.0" encoding="UTF-8"?><htmlxmlns="http://www.w3.org/1999/xhtml"xmlns:epub="http://www.idpf.org/2007/ops"><head><title>First Page</title><metacharset="utf-8"/></head><body><sectionepub:type="bodymatter chapter"><header><h1><spanid="c002p0000">First Page</span></h1></header><p><spanid="c002p0001">First Page: aaaaaaaaaaaa</span></p><p><spanid="c002p0002">First Page: bbbbbbbbbbbbb</span></p></section></body></html><--!TOCPage--><?xml version='1.0' encoding='utf-8'?><htmlxmlns="http://www.w3.org/1999/xhtml"xmlns:epub="http://purl.org/dc/elements/1.1/"><head><title>Cover</title></head><body><navxmlns:ns0="http://www.idpf.org/2007/ops"ns0:type="toc"><ol><li><ahref="cover.xhtml">Cover Page</a></li><li><ahref="toc.xhtml">Nav Page</a></li><li><ahref="first_page.xhtml">First Page</a></li><li><ahref="second_page.xhtml">Second Page</a></li></ol></nav></body></html>

把目录打包成 EPUB 文件

如下图: 用 ZIP 压缩文件至 first-epub.epub

    zip-r../first-epub.epub*

把做好的图书用自带的 Book 打开来看看

Epub.js

Epub.js 是一个 JavaScript 库，用于在浏览器中跨多种设备呈现 ePub 文档。 Epub.js 为常见的电子书功能（如渲染、持久化和分页）提供了一个接口，而无需开发专用的应用程序或插件。重要的是，它是 BSD 许可证。

翻译自项目 README

来看看官方的DEMO

高亮备注分页等等常用功能是均支持的

来实现一个”Hello Word”

    <!DOCTYPE html><html><head><metacharset="utf-8"><title>Demo for Epub.js</title><scriptsrc="https://cdnjs.cloudflare.com/ajax/libs/jszip/3.1.5/jszip.min.js"></script><scriptsrc="https://futurepress.github.io/epub.js/dist/epub.js"></script></head><body><divid="nav"><selectid="toc"></select></div><divid="viewer"></div><script>var$viewer=document.getElementById("viewer");// Load the opfvarbook=ePub("https://blog.calvin.wang/assets/first-epub.epub",{store:"epubjs-test"});varrendition=book.renderTo("viewer",{width:"100%"});vardisplayed=rendition.display();book.loaded.navigation.then(function(toc){var$select=document.getElementById("toc"),docfrag=document.createDocumentFragment();toc.forEach(function(chapter){varoption=document.createElement("option");option.textContent=chapter.label;option.ref=chapter.href;docfrag.appendChild(option);});$select.appendChild(docfrag);$select.onchange=function(){varindex=$select.selectedIndex,url=$select.options[index].ref;rendition.display(url);returnfalse;};});</script></body></html>

来看看它有哪些 Model

Book: 用来代表一个 Epub 图书,用来加载和解析其内容
- Container: 用来解析 Container, 主要用来从 “META-INF/container.xml”获取 PackagePath
- Packaging: 用来解析 Package, 主要用来获取manifest cover spine metadata nav ncx
Rendition: 负责将 Book 的内容渲染在网页上,并进行控制.
- Manager: 用来控制网页上的呈现方式(default: DefaultViewManager)
- View: 展现在页面上的样式(default: IframeView)
EpubCFI: 是一个规范,定义了一种标准化方法，用于通过使用片段标识符来引用 EPUB® 出版物中的任意内容. 可以参考: http://idpf.org/epub/linking/cfi/epub-cfi.html
辅助类:
- Theme: 样式主题
- Annotations: 注解

流程怎么控制的

Rendition:
- 支持HOOK的阶段:
  - content: Pages/View内容被解析和加载,现有的 HOOK
    - handleLinks: 处理内容中的连接
    - passEvents: 内容中产生的事件同步
    - adjustImages: 调整图片
  - unloaded: Pages/View内容从屏幕中卸载
  - render: Pages/View被渲染到屏幕
Spin:
- 支持HOOK的阶段:
  - Serialize: Pages/View 被转换为 text
  - Content: Pages/View 被加载和解析. 现有的 HOOK
    - injectStylesheet: 注入样式表
    - injectScript: 注入脚本

还没有完全看懂的内容, 感觉是语言特性:

Promise 的用处?
Event的传递方式?

2021年敏捷管理工具推荐

Mon, 15 Nov 2021 00:00:00 CST

敏捷和DevOps已经很流行了，对应的工具也不少（例如JIRA、Azure DevOps、云效等等），我们在本篇文章里捋一捋截止到2021年11月都有哪些有名的敏捷工具。

1. JIRA

JIRA是Atlassian公司著名的敏捷管理工具，可以管理史诗（Epic)、用户故事(User Story)、任务（Task)，同时可以使用看板可以跟踪管理相关工作项的状态。
问题追踪和管理：用它管理项目，跟踪任务、bug、需求，通过jira的邮件通知功能进行协作通知，在实际工作中使工作效率提高很多

问题跟进情况的分析报告：可以随时了解问题和项目的进展情况
项目类别管理功能：可以将相关的项目分组管理
组件/模块负责人功能：可以将项目的不同组件/模块指派相应的负责人，来处理所负责的组件的Issues
项目email地址功能：每个项目可以有不同的email（该项目的通知邮件从该地址发出）
无限制的工作流：可以创建多个工作流为不同的项目使用

2. Azure DevOps

Azure DevOps 是由微软开发的服务平台，它提供了多种工具，可用于更好地进行团队协作。它还具有用于自动构建过程，测试，版本控制和程序包管理的工具。

Azure DevOps 提供了 5 个主要模块：

Azure Boards：这些是敏捷的工具，可以帮助我们规划、跟踪和讨论我们的工作，甚至与其他团队一起工作。
Azure Repos：提供无限的、云托管的私人和公共 Git 存储库。
Azure Pipelines：使用适用于任何语言、平台和云的 CI/CD 进行构建、测试和部署。
Azure Test Plans：使用适用于应用的手动测试和探索测试工具来提高代码整体质量。。
Azure Artifacts：与整个团队共享来自公共源和专用源的 Maven、npm、NuGet 和 Python 包。以简单且可缩放的方式将包共享集成到 CI/CD 管道中。

3. TAPD

TAPD（Tencent Agile Product Development）是腾讯的敏捷研发协作平台，提供贯穿敏捷研发生命周期的一站式服务。覆盖从产品概念形成、产品规划、需求分析、项目规划和跟踪、质量测试到构建发布、用户反馈跟踪的产品研发全生命周期，提供了灵活的可定制化应用和强大的集成能力，帮助研发团队有效地管理需求、资源、进度和质量，规范和改进产品研发过程，提高研发效率和产品质量。

产品功能:

敏捷需求规划：能够快速高效的对需求进行全周期管理。通过需求收集、分解，规划并实施，快速响应市场变化，灵活处理需求变更，过程可追溯，清晰更透明。
迭代计划：通过迭代进行目标制定与计划评审，完成工作分配，使用故事墙与燃尽图进行研发过程跟踪。迭代全程目标清晰，进度可控，研发过程敏捷迭代，小步快跑。
测试计划：对于迭代质量的全程把控。通过快速编写并管理测试用例，制定测试计划并执行，利用缺陷跟踪管理进行问题跟踪与解决，能够实现对测试工作的高效管理，保障产品高质量交付。
缺陷管理：对缺陷进行全方位记录与跟踪。配合缺陷统计报表对 BUG 进行统计分析，能够及时了解开发的质量并进行跟踪修复。同时可通过邮件创建定时报告发送给项目成员，让团队成员及时了解迭代开发质量。
工时管理：合理分配团队资源，利用工时进行工作量统计，配合工时花费报告，能够实时掌握团队成员工作完成情况与项目进展，过程清晰，风险可控。
文档管理：提供思维导图、在线文档、文件管理等功能，支持多人实时协作编辑，帮助团队集中管理项目文件，方便团队进行头脑风暴、内容分享与知识沉淀。

4 云效

云效提供项目管理、需求管理、缺陷管理、任务管理、迭代规划等丰富的项目管理功能及效能数据统计，支持单项目管理、跨项目协作等丰富的协作场景。

产品功能：

需求管理：管理需求从提出、设计、开发、测试、发布的完整流程。
迭代规划：提供将需求规划进迭代并完成迭代的交付。
项目管理：管理项目从创建、规划、实施、交付的完整流程。
研发效能度量：支持工时统计。

5 Leangoo

Leangoo是一个以看板为核心的敏捷项目协作工具，通过看板共享和实时同步团队工作来实现高效协同。团队工作体现为卡片，内容可以是需求、任务、问题等。
产品Backlog
Scrum任务板
用户故事

6. Ones

Ones 适用需求管理、任务管理、缺陷管理、迭代管理等敏捷场景
产品功能：

需求管理
迭代规划
缺陷管理
进度管理

HTTP抓包工具之Charles

Tue, 02 Nov 2021 09:20:20 CST

Charles简介

Charles是一个HTTP代理服务器，当浏览器连接Charles的代理访问互联网时，Charles可以监控浏览器发送和接收的所有数据。它允许一个开发者查看所有连接互联网的HTTP通信，这些包括request, response和HTTP headers （包含cookies与caching信息）。

Charles主要功能：

支持SSL代理。可以截取分析SSL的请求。
支持流量控制。可以模拟慢速网络以及等待时间（latency）较长的请求。
支持AJAX调试。可以自动将json或xml数据格式化，方便查看。
支持AMF调试。可以将Flash Remoting 或 Flex Remoting信息格式化，方便查看。
支持重发网络请求，方便后端调试。
支持修改网络请求参数。
支持网络请求的截获并动态修改。
检查HTML，CSS和RSS内容是否符合W3C标准。

以上介绍了Charles的主要功能，个人在使用过程中主要用的是抓取HTTP和HTTPS请求。特别是HTTPS的请求，抓取起来还是有一些麻烦，特此记录。

Charles 抓包原理

市面上绝大多数的抓包软件，背后的原理都是中间人攻击（Man-in-the-middle attack，缩写：MITM）。

维基百科是这样定义 MITM 的：中间人攻击在密码学和计算机安全领域中是指攻击者与通讯的两端分别建立独立的联系，并交换其所收到的数据，使通讯的两端认为他们正在通过一个私密的连接与对方直接对话，但事实上整个会话都被攻击者完全控制。

上面的定义写的很清晰，下图中结合箭头方向就能看懂 HTTP Packets 的流向：

Charles的使用

Charles的安装过程是比较简单，只需到官网下载安装即可。比较困难的是HTTPS请求的配置。

Windows下HTTPS请求抓包

1、配置SSL支持。点击【Proxy】–>【SSL Proxying Settings…】，在弹出选项卡中，勾选【Enable SSL Proxying】点击【add】，在Host输入【*】表示接收任何主机，在Prot输入【*】表示任何端口，最后点击【ok】保存。

2、安装证书。点击【Help】–>【SSL Proxying】–>【Install Charles Root Certificate】，按照引导流程安装证书。

完成后打开IE进行测试：出现证书错误！

打开Chrome测试：

打开Edge测试：

都被安全拦截了，装了证书都不起作用。

解决方案：安装Firefox！

安装完毕后在开启Charles时，使用Firefox打开，http://chls.pro/ssl，弹出如下页面：

选择保存文件后按确定。文件默认保存到下载文件夹。

打开Firefox【设置】–>【隐私与安全】–>【证书】–>【查看证书】

使用【证书管理器】–>【证书办法机构】–>【导入】进行导入操作。

iOS下HTTPS请求抓包

在PC上开启共享网络。将手机连接到PC共享的WIFI上。

在手机上设置代理地址，代理IP为PC的IP，端口为Charles的端口。

在手机自带浏览器Safari中输入chls.pro，完成后需要进入【设置】安装描述文件。安装完毕后，如果是iOS 10 以后需要进入【设置】–>【通用】–>【关于本机】–>【证书信任设置】，开启证书。

Android下HTTPS请求抓包

在PC上开启共享网络。将手机连接到PC共享的WIFI上。

在手机上设置代理地址，代理IP为PC的IP，端口为Charles的端口。

在手机默认浏览器中输入chls.pro，下载downloadfile.crt文件，然后在【我的下载】中进行打开，按引导进行安装。

数据同步工具之FlinkCDC/Canal/Debezium对比-技术圈

Sun, 31 Oct 2021 12:10:29 CST

前言

数据准实时复制（CDC）是目前行内实时数据需求大量使用的技术，随着国产化的需求，我们也逐步考虑基于开源产品进行准实时数据同步工具的相关开发，逐步实现对商业产品的替代。本文把市面上常见的几种开源产品，Canal、Debezium、Flink CDC 从原理和适用做了对比，供大家参考。

本文首发微信公众号《import_bigdata》

Debezium

Debezium is an open source distributed platform for change data capture. Start it up, point it at your databases, and your apps can start responding to all of the inserts, updates, and deletes that other apps commit to your databases. Debezium is durable and fast, so your apps can respond quickly and never miss an event, even when things go wrong.

Debezium是一种CDC（Change Data Capture）工具，工作原理类似大家所熟知的Canal, DataBus, Maxwell等，是通过抽取数据库日志来获取变更。

Debezium最初设计成一个Kafka Connect 的Source Plugin，目前开发者虽致力于将其与Kafka Connect解耦，但当前的代码实现还未变动。下图引自Debeizum官方文档，可以看到一个Debezium在一个完整CDC系统中的位置。

Kafka Connect 为Source Plugin提供了一系列的编程接口，最主要的就是要实现SourceTask的poll方法，其返回 List<SourceRecord>将会被以最少一次语义的方式投递至Kafka。

Debezium MySQL 架构

Debezium抽取原理

Reader体系构成了MySQL模块中代码的主线，我们的分析从Reader开始。

Reader继承关系

从名字上应该可以看出，真正主要的是SnapshotReader和BinlogReader，分别实现了对MySQL数据的全量读取和增量读取，他们继承于AbstractReader，里面封装了共用逻辑，下图是AbstractReader的内部设计。

可以看到，AbstractReader在实现时，并没有直接将enqueue喂进来的record投递进Kafka，而是通过一个内存阻塞队列BlockingQueue进行了解耦，这种设计有诸多好处：

职责解耦

如上的图中，在喂入BlockingQueue之前，要根据条件判断是否接受该record；在向Kafka投递record之前，判断task的running状态。这样把同类的功能限定在特定的位置。

线程隔离

BlockingQueue是一个线程安全的阻塞队列，通过BlockingQueue实现的生产者消费者模型，是可以跑在不同的线程里的，这样避免局部的阻塞带来的整体的干扰。如上图中的右侧，消费者会定期判断running标志位，若running被stop信号置为了false，可以立刻停止整个task,而不会因MySQL IO阻塞延迟相应。

Single与Batch的互相转化

Enqueue record是单条的投递record，drain_to是批量的消费records。这个用法也可以反过来，实现batch到single的转化。

可能你还知道阿里开源的另一个MySQL CDC工具canal，他只负责stream过程，并没有处理snapshot过程，这也是debezium相较于canal的一个优势。

对于Debezium来说，基本沿用了官方搭建从库的这一思路，让我们看下官方文档描述的详细步骤。

MySQL连接器每次获取快照的时候会执行以下的步骤：

获取一个全局读锁，从而阻塞住其他数据库客户端的写操作。
开启一个可重复读语义的事务，来保证后续的在同一个事务内读操作都是在一个一致性快照中完成的。
读取binlog的当前位置。
读取连接器中配置的数据库和表的模式（schema）信息。
释放全局读锁，允许其他的数据库客户端对数据库进行写操作。
（可选）把DDL改变事件写入模式改变topic（schema change topic），包括所有的必要的DROP和CREATEDDL语句。
扫描所有数据库的表，并且为每一个表产生一个和特定表相关的kafka topic创建事件（即为每一个表创建一个kafka topic）。
提交事务。
记录连接器成功完成快照任务时的连接器偏移量。

部署

基于 Kafka Connect

最常见的架构是通过 Apache Kafka Connect 部署 Debezium。Kafka Connect 为在 Kafka 和外部存储系统之间系统数据提供了一种可靠且可伸缩性的方式。它为 Connector 插件提供了一组 API 和一个运行时：Connect 负责运行这些插件，它们则负责移动数据。通过 Kafka Connect 可以快速实现 Source Connector 和 Sink Connector 进行交互构造一个低延迟的数据 Pipeline：

Source Connector（例如，Debezium）：将记录发送到 Kafka
Sink Connector：将 Kafka Topic 中的记录发送到其他系统

如上图所示，部署了 MySQL 和 PostgresSQL 的 Debezium Connector 以捕获这两种类型数据库的变更。每个 Debezium Connector 都会与其源数据库建立连接：

MySQL Connector 使用客户端库来访问 binlog。
PostgreSQL Connector 从逻辑副本流中读取数据。

除了 Kafka Broker 之外，Kafka Connect 也作为一个单独的服务运行。默认情况下，数据库表的变更会写入名称与表名称对应的 Kafka Topic 中。如果需要，您可以通过配置 Debezium 的 Topic 路由转换来调整目标 Topic 名称。例如，您可以：

将记录路由到名称与表名不同的 Topic 中
将多个表的变更事件记录流式传输到一个 Topic 中

变更事件记录在 Apache Kafka 中后，Kafka Connect 生态系统中的不同 Sink Connector 可以将记录流式传输到其他系统、数据库，例如 Elasticsearch、数据仓库、分析系统或者缓存（例如 Infinispan）。

Debezium Server

另一种部署 Debezium 的方法是使用 Debezium Server。Debezium Server 是一个可配置的、随时可用的应用程序，可以将变更事件从源数据库流式传输到各种消息中间件上。

下图展示了基于 Debezium Server 的变更数据捕获 Pipeline 架构：

Debezium Server 配置使用 Debezium Source Connector 来捕获源数据库中的变更。变更事件可以序列化为不同的格式，例如 JSON 或 Apache Avro，然后发送到各种消息中间件，例如 Amazon Kinesis、Google Cloud Pub/Sub 或 Apache Pulsar。

嵌入式引擎

使用 Debezium Connector 的另一种方法是嵌入式引擎。在这种情况下，Debezium 不会通过 Kafka Connect 运行，而是作为嵌入到您自定义 Java 应用程序中的库运行。这对于在您的应用程序本身内获取变更事件非常有帮助，无需部署完整的 Kafka 和 Kafka Connect 集群，也不用将变更流式传输到 Amazon Kinesis 等消息中间件上。

特性

Debezium 是一组用于 Apache Kafka Connect 的 Source Connector。每个 Connector 都通过使用该数据库的变更数据捕获 (CDC) 功能从不同的数据库中获取变更。与其他方法（例如轮询或双重写入）不同，Debezium 的实现基于日志的 CDC：

确保捕获所有的数据变更。
以极低的延迟生成变更事件，同时避免因为频繁轮询导致 CPU 使用率增加。例如，对于 MySQL 或 PostgreSQL，延迟在毫秒范围内。
不需要更改您的数据模型，例如 ‘Last Updated’ 列。
可以捕获删除操作。
可以捕获旧记录状态以及其他元数据，例如，事务 ID，具体取决于数据库的功能和配置。

Flink CDC

2020 年 7 月提交了第一个 commit，这是基于个人兴趣孵化的项目；
2020 年 7 中旬支持了 MySQL-CDC；
2020 年 7 月末支持了 Postgres-CDC；

一年的时间，该项目在 GitHub 上的 star 数已经超过 800。

Flink CDC 发展

Flink CDC 底层封装了 Debezium， Debezium 同步一张表分为两个阶段：

全量阶段：查询当前表中所有记录；
增量阶段：从 binlog 消费变更数据。

大部分用户使用的场景都是全量 + 增量同步，加锁是发生在全量阶段，目的是为了确定全量阶段的初始位点，保证增量 + 全量实现一条不多，一条不少，从而保证数据一致性。从下图中我们可以分析全局锁和表锁的一些加锁流程，左边红色线条是锁的生命周期，右边是 MySQL 开启可重复读事务的生命周期。

以全局锁为例，首先是获取一个锁，然后再去开启可重复读的事务。这里锁住操作是读取 binlog 的起始位置和当前表的 schema。这样做的目的是保证 binlog 的起始位置和读取到的当前 schema 是可以对应上的，因为表的 schema 是会改变的，比如如删除列或者增加列。在读取这两个信息后，SnapshotReader 会在可重复读事务里读取全量数据，在全量数据读取完成后，会启动 BinlogReader 从读取的 binlog 起始位置开始增量读取，从而保证全量数据 + 增量数据的无缝衔接。

表锁是全局锁的退化版，因为全局锁的权限会比较高，因此在某些场景，用户只有表锁。表锁锁的时间会更长，因为表锁有个特征：锁提前释放了可重复读的事务默认会提交，所以锁需要等到全量数据读完后才能释放。

经过上面分析，接下来看看这些锁到底会造成怎样严重的后果：

Flink CDC 1.x 可以不加锁，能够满足大部分场景，但牺牲了一定的数据准确性。Flink CDC 1.x 默认加全局锁，虽然能保证数据一致性，但存在上述 hang 住数据的风险。

Flink CDC 1.x得到了很多用户在社区的反馈，主要归纳为三个：

全量 + 增量读取的过程需要保证所有数据的一致性，因此需要通过加锁保证，但是加锁在数据库层面上是一个十分高危的操作。底层 Debezium 在保证数据一致性时，需要对读取的库或表加锁，全局锁可能导致数据库锁住，表级锁会锁住表的读，DBA 一般不给锁权限。
不支持水平扩展，因为 Flink CDC 底层是基于 Debezium，起架构是单节点，所以Flink CDC 只支持单并发。在全量阶段读取阶段，如果表非常大 (亿级别)，读取时间在小时甚至天级别，用户不能通过增加资源去提升作业速度。
全量读取阶段不支持 checkpoint：CDC 读取分为两个阶段，全量读取和增量读取，目前全量读取阶段是不支持 checkpoint 的，因此会存在一个问题：当我们同步全量数据时，假设需要 5 个小时，当我们同步了 4 小时的时候作业失败，这时候就需要重新开始，再读取 5 个小时。

通过上面的分析，可以知道 2.0 的设计方案，核心要解决上述的三个问题，即支持无锁、水平扩展、checkpoint。

目前，Flink CDC 2.0 也已经正式发布，此次的核心改进和提升包括：

并发读取，全量数据的读取性能可以水平扩展；
全程无锁，不对线上业务产生锁的风险；
断点续传，支持全量阶段的 checkpoint。

本文发自微信公众号《import_bigdata》

Canal

canal [kə'næl]，译意为水道/管道/沟渠，主要用途是基于 MySQL 数据库增量日志解析，提供增量数据订阅和消费。

早期阿里巴巴因为杭州和美国双机房部署，存在跨机房同步的业务需求，实现方式主要是基于业务 trigger 获取增量变更。从 2010 年开始，业务逐步尝试数据库日志解析获取增量变更进行同步，由此衍生出了大量的数据库增量订阅和消费业务。

基于日志增量订阅和消费的业务包括：

数据库镜像
数据库实时备份
索引构建和实时维护(拆分异构索引、倒排索引等)
业务 cache 刷新
带业务逻辑的增量数据处理

当前的canal支持源端MySQL版本包括 5.1.x , 5.5.x , 5.6.x , 5.7.x , 8.0.x。

工作原理

MySQL主备复制原理

MySQL master 将数据变更写入二进制日志( binary log, 其中记录叫做二进制日志事件binary log events，可以通过 show binlog events 进行查看)
MySQL slave 将 master 的 binary log events 拷贝到它的中继日志(relay log)
MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据

canal 工作原理

canal 模拟 MySQL slave 的交互协议，伪装自己为MySQL slave,向MySQL master发送dump协议
MySQL master收到 dump 请求，开始推送 binary log 给 slave (即 canal )
canal 解析 binary log 对象(原始为 byte 流)

Binlog获取详解

Binlog发送接收流程，流程如下图所示:

首先，我们需要伪造一个slave，向master注册，这样master才会发送binlog event。注册很简单，就是向master发送COM_REGISTER_SLAVE命令，带上slave相关信息。这里需要注意，因为在MySQL的replication topology中，都需要使用一个唯一的server id来区别标示不同的server实例，所以这里我们伪造的slave也需要一个唯一的server id。

接着实现binlog的dump。MySQL只支持一种binlog dump方式，也就是指定binlog filename + position，向master发送COM_BINLOG_DUMP命令。在发送dump命令的时候，我们可以指定flag为BINLOG_DUMP_NON_BLOCK，这样master在没有可发送的binlog event之后，就会返回一个EOF package。不过通常对于slave来说，一直把连接挂着可能更好，这样能更及时收到新产生的binlog event。

Dump命令包图如下所示:

如上图所示,在报文中塞入binlogPosition和binlogFileName即可让master从相应的位置发送binlog event。

canal结构

说明：

server代表一个canal运行实例，对应于一个jvm，也可以理解为一个进程
instance对应于一个数据队列（1个server对应1..n个instance)，每一个数据队列可以理解为一个数据库实例。

Server设计

server代表了一个canal的运行实例，为了方便组件化使用，特意抽象了Embeded(嵌入式) / Netty(网络访问)的两种实现

Embeded : 对latency和可用性都有比较高的要求，自己又能hold住分布式的相关技术(比如failover)
Netty : 基于netty封装了一层网络协议，由canal server保证其可用性，采用的pull模型，当然latency会稍微打点折扣，不过这个也视情况而定。(阿里系的notify和metaq，典型的push/pull模型，目前也逐步的在向pull模型靠拢，push在数据量大的时候会有一些问题)

Instance设计

instance代表了一个实际运行的数据队列，包括了EventPaser,EventSink,EventStore等组件。

抽象了CanalInstanceGenerator，主要是考虑配置的管理方式：

manager方式：和你自己的内部web console/manager系统进行对接。(目前主要是公司内部使用，Otter采用这种方式) spring方式：基于spring xml + properties进行定义，构建spring配置.

下面是canalServer和instance如何运行：

    canalServer.setCanalInstanceGenerator(new CanalInstanceGenerator() {      
      
            public CanalInstance generate(String destination) {      
                Canal canal = canalConfigClient.findCanal(destination);      
                // 此处省略部分代码 大致逻辑是设置canal一些属性      
      
                CanalInstanceWithManager instance = new CanalInstanceWithManager(canal, filter) {      
      
                    protected CanalHAController initHaController() {      
                        HAMode haMode = parameters.getHaMode();      
                        if (haMode.isMedia()) {      
                            return new MediaHAController(parameters.getMediaGroup(),      
                                parameters.getDbUsername(),      
                                parameters.getDbPassword(),      
                                parameters.getDefaultDatabaseName());      
                        } else {      
                            return super.initHaController();      
                        }      
                    }      
      
                    protected void startEventParserInternal(CanalEventParser parser, boolean isGroup) {      
                        //大致逻辑是 设置支持的类型      
                        //初始化设置MysqlEventParser的主库信息，这处抽象不好，目前只支持mysql      
                    }      
      
                };      
                return instance;      
            }      
        });      
        canalServer.start(); //启动canalServer      
      
        canalServer.start(destination);//启动对应instance      
        this.clientIdentity = new ClientIdentity(destination, pipeline.getParameters().getMainstemClientId(), filter);      
        canalServer.subscribe(clientIdentity);// 发起一次订阅，当监听到instance配置时，调用generate方法注入新的instance

instance模块：

eventParser (数据源接入，模拟slave协议和master进行交互，协议解析)
eventSink (Parser和Store链接器，进行数据过滤，加工，分发的工作)
eventStore (数据存储)
metaManager (增量订阅&消费信息管理器)

EventParser设计

大致过程：

整个parser过程大致可分为几步：

Connection获取上一次解析成功的位置 (如果第一次启动，则获取初始指定的位置或者是当前数据库的binlog位点)
Connection建立链接，发送BINLOG_DUMP指令

    // 0. write command number      
// 1. write 4 bytes bin-log position to start at      
// 2. write 2 bytes bin-log flags      
// 3. write 4 bytes server id of the slave      
// 4. write bin-log file name

Mysql开始推送Binaly Log
接收到的Binaly Log的通过Binlog parser进行协议解析，补充一些特定信息(补充字段名字，字段类型，主键信息，unsigned类型处理)
传递给EventSink模块进行数据存储，是一个阻塞操作，直到存储成功
存储成功后，由CanalLogPositionManager定时记录Binaly Log位置

EventSink设计

说明：

数据过滤：支持通配符的过滤模式，表名，字段内容等
数据路由/分发：解决1:n (1个parser对应多个store的模式)
数据归并：解决n:1 (多个parser对应1个store)
数据加工：在进入store之前进行额外的处理，比如join

数据1:n业务

为了合理的利用数据库资源，一般常见的业务都是按照schema进行隔离，然后在mysql上层或者dao这一层面上，进行一个数据源路由，屏蔽数据库物理位置对开发的影响，阿里系主要是通过cobar/tddl来解决数据源路由问题。

所以，一般一个数据库实例上，会部署多个schema，每个schema会有由1个或者多个业务方关注。

数据n:1业务

同样，当一个业务的数据规模达到一定的量级后，必然会涉及到水平拆分和垂直拆分的问题，针对这些拆分的数据需要处理时，就需要链接多个store进行处理，消费的位点就会变成多份，而且数据消费的进度无法得到尽可能有序的保证。

所以，在一定业务场景下，需要将拆分后的增量数据进行归并处理，比如按照时间戳/全局id进行排序归并。

EventStore设计

目前仅实现了Memory内存模式，后续计划增加本地file存储，mixed混合模式。
借鉴了Disruptor的RingBuffer的实现思路

RingBuffer设计：

定义了3个cursor

Put : Sink模块进行数据存储的最后一次写入位置 Get : 数据订阅获取的最后一次提取位置 Ack : 数据消费成功的最后一次消费位置

借鉴Disruptor的RingBuffer的实现，将RingBuffer拉直来看：

实现说明：

Put/Get/Ack cursor用于递增，采用long型存储buffer的get操作，通过取余或者与操作。(与操作：cusor & (size - 1) , size需要为2的指数，效率比较高)

HA机制设计

canal的ha分为两部分，canal server和canal client分别有对应的ha实现

canal server: 为了减少对mysql dump的请求，不同server上的instance要求同一时间只能有一个处于running，其他的处于standby状态.
canal client: 为了保证有序性，一份instance同一时间只能由一个canal client进行get/ack/rollback操作，否则客户端接收无法保证有序。

整个HA机制的控制主要是依赖了zookeeper的几个特性，watcher和EPHEMERAL节点(和session生命周期绑定)，可以看下我之前zookeeper的相关文章。

Canal Server:

大致步骤：

canal server要启动某个canal instance时都先向zookeeper进行一次尝试启动判断 (实现：创建EPHEMERAL节点，谁创建成功就允许谁启动)
创建zookeeper节点成功后，对应的canal server就启动对应的canal instance，没有创建成功的canal instance就会处于standby状态
一旦zookeeper发现canal server A创建的节点消失后，立即通知其他的canal server再次进行步骤1的操作，重新选出一个canal server启动instance
canal client每次进行connect时，会首先向zookeeper询问当前是谁启动了canal instance，然后和其建立链接，一旦链接不可用，会重新尝试connect

Canal Client的方式和canal server方式类似，也是利用zookeeper的抢占EPHEMERAL节点的方式进行控制。

本文发自微信公众号《import_bigdata》

总结

CDC 的技术方案非常多，目前业界主流的实现机制可以分为两种：

基于查询的 CDC：

离线调度查询作业，批处理。把一张表同步到其他系统，每次通过查询去获取表中最新的数据；
无法保障数据一致性，查的过程中有可能数据已经发生了多次变更；
不保障实时性，基于离线调度存在天然的延迟。

基于日志的 CDC：

实时消费日志，流处理，例如 MySQL 的 binlog 日志完整记录了数据库中的变更，可以把 binlog 文件当作流的数据源；
保障数据一致性，因为 binlog 文件包含了所有历史变更明细；
保障实时性，因为类似 binlog 的日志文件是可以流式消费的，提供的是实时数据。

对比常见的开源 CDC 方案，我们可以发现：

对比增量同步能力:

        - 基于日志的方式，可以很好的做到增量同步；          
- 而基于查询的方式是很难做到增量同步的。

对比全量同步能力，基于查询或者日志的 CDC 方案基本都支持，除了 Canal。
而对比全量 + 增量同步的能力，只有 Flink CDC、Debezium、Oracle Goldengate 支持较好。
从架构角度去看，该表将架构分为单机和分布式，这里的分布式架构不单纯体现在数据读取能力的水平扩展上，更重要的是在大数据场景下分布式系统接入能力。例如 Flink CDC 的数据入湖或者入仓的时候，下游通常是分布式的系统，如 Hive、HDFS、Iceberg、Hudi 等，那么从对接入分布式系统能力上看，Flink CDC 的架构能够很好地接入此类系统。
在数据转换 / 数据清洗能力上，当数据进入到 CDC 工具的时候是否能较方便的对数据做一些过滤或者清洗，甚至聚合？

在 Flink CDC 上操作相当简单，可以通过 Flink SQL 去操作这些数据；
但是像 DataX、Debezium 等则需要通过脚本或者模板去做，所以用户的使用门槛会比较高。

另外，在生态方面，这里指的是下游的一些数据库或者数据源的支持。Flink CDC 下游有丰富的 Connector，例如写入到 TiDB、MySQL、Pg、HBase、Kafka、ClickHouse 等常见的一些系统，也支持各种自定义 connector。

使用python打造自己的信息收集工具 - FreeBuf网络安全行业门户

Thu, 23 Sep 2021 17:36:12 CST

介绍：

该篇章主要介绍如何编写自己的信息收集工具，主要流程如下：

1、向bing搜索引擎发起request请求，获取url数据

2、使用正则表达式对获取的数据进行处理

3、用多线程，对处理的数据进行二次请求，返回标题等数据

4、使用openyxl模块，将数据保存为.xlsx格式

请注意：

该篇章目的是熟悉python编程，学习python的一些常见模块，在编写程序的过程中会有很多操作和方式方法，望大家能共同加油学到东西。本文仅用于技术讨论与研究，这里使用的技术仅用于学习教育目的，如果列出的技术用于其他任何目标，本站及作者概不负责。

本文涉及到模块有：

#coding:utf-8        
import requests     #发起request请求      
import urllib3      #处理请求https异常报错问题      
import re       #使用正则表达式对请求到的数据进行处理      
from optparse import OptionParser   #自定义输入参数      
import threading        #多线程模块      
import queue            #多线程辅助模块，使用队列的方式对多线程进行控制      
from bs4 import BeautifulSoup   #与re类似 使用正则表达式对请求到的数据进行处理      
import time,datetime    #获取当前的时间      
from openpyxl import  * #数据处理，将获取到的数据保存在excel文件中

属性：

heads = {                       #全局变量  请求头      
'User-Agent':'Mozilla/5.0 (Windows NT 10.0; Win64; x64)                          AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36',   #模拟浏览器请求      
'Connection':'close',        
'Accept-Encoding':'gzip, deflate'      
}      
count=1                         #全局变量  用于序号字段      
queueLock = threading.Lock()    #全局变量  使用线程锁处理 线程异常问题      
class DoRun(threading.Thread):  #自定义 多线程运行时使用的类

方法：

def get_Input():    #获取search语句 和 page      
def getUrls(search,page):       #构造搜索语句，在bing搜索引擎搜索数据并返回urls      
def req(url):   #对url进行验证，返回numb,url,title,status      
def init_excel(filename):  #创建.xlsx表格，并初始化内容      
def Save_Date(date,filename):   #将数据存储到表格当中      
def run():     #核心代码

完整代码如下：

#coding:utf-8        
import requests     #发起request请求      
import urllib3      #处理请求https异常报错问题      
import re       #使用正则表达式对请求到的数据进行处理      
from optparse import OptionParser   #自定义输入参数      
import threading        #多线程模块      
import queue            #多线程辅助模块，使用队列的方式对多线程进行控制      
from bs4 import BeautifulSoup   #与re类似 使用正则表达式对请求到的数据进行处理      
import time,datetime    #获取当前的时间      
from openpyxl import  * #数据处理，将获取到的数据保存在excel文件中      
      
heads = {                       #全局变量  请求头      
'User-Agent':'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36',   #模拟浏览器请求      
'Connection':'close',        
'Accept-Encoding':'gzip, deflate'      
}      
count=1                         #全局变量  用于序号字段      
queueLock = threading.Lock()    #全局变量  使用线程锁处理 线程异常问题      
class DoRun(threading.Thread):  #自定义 多线程运行时使用的类      
def __init__(self,queue,filename):      
threading.Thread.__init__(self)      
self._queue=queue      
self._filename=filename      
def run(self):      
while not self._queue.empty():      
js=req(self._queue.get())      
#print(js)      
queueLock.acquire()      
if(js):      
Save_Date(js,self._filename)      
queueLock.release()              
def init_excel(filename):  #创建.xlsx表格，并初始化内容      
wb=Workbook()      
filename=filename+".xlsx"      
ws=wb.create_sheet(index=0,title="域名")      
head=['序号','域名','标题','状态']      
for i in range(0,4):      
ws.cell(1,i+1).value=head[i]      
wb.save(filename)      
def Save_Date(date,filename):   #将数据存储到表格当中      
filename=filename+".xlsx"      
wb_save=load_workbook(filename)      
ws_save=wb_save.worksheets[0]      
current_row=ws_save.max_row+1      
current_col=1      
for key in date:      
ws_save.cell(date['numb']+1,current_col).value=str(date[key])      
current_col+=1      
wb_save.save(filename)      
def req(url):   #对域名进行验证，返回状态码，title      
global count      
dir={'numb':0,'url':'url','title':'None','status':0}      
stat=0      
title="None"      
      
try:      
urllib3.disable_warnings()      
response = requests.get(url=url,headers=heads,verify=False,timeout=10)   #请求漏洞的url      
if response.status_code == 200:      
bs=BeautifulSoup(response.content,"html.parser")      
title=bs.find("title").text      
stat=response.status_code      
dir['numb']=count      
dir['url']=url      
dir['title']=title      
dir['status']=stat      
count+=1      
print("[+]"+url+"\ttitle:"+title)      
return dir      
else:      
print('[-]请求失败：\t{}\t{}'.format(url,response.status_code))      
except Exception as e:      
print('[-]请求失败: {}\t'.format(e,url))      
def getUrls(search,page):       #构造搜索语句，在bing搜索引擎 搜索数据并返回urls      
count=1      
urls=[]      
url="https://cn.bing.com/search?q={}&first={}"      
for i in range(1,page):      
if(i!=1):      
count=(i-2)*10+9      
url=url.format(search,i)      
try:      
resp=requests.get(url=url,headers=heads)      
html=resp.text      
if(resp.status_code==200):      
res=re.findall(r'<a target="_blank" href="(.*?)"',html)      
for u in res:      
if(u not in urls):      
urls.append(u)      
else:      
print('[-]请求失败：\t{}\t{}'.format(url,resp.status_code))      
except Exception as e:      
print('[-]请求失败: {}\t'.format(e,url))      
      
return urls      
def get_Input():    #获取search语句 和 page      
optParser = OptionParser()      
optParser.add_option('-s','--search',action = 'store',type = "string" ,dest = 'search',help='漏扫文件的目录',default="search_def")      
optParser.add_option("-p","--page", action="store", type="int",dest="page",help='要搜索的页数',default=10)                  
optParser.add_option("-t","--threads", action="store", type="int",dest="threads",help='线程数量，默认为10',default=10)                  
(options , args) = optParser.parse_args()      
return options.search,options.page,options.threads      
def run():                
que=queue.Queue()      
print(datetime.datetime.now())              #打印开始时间      
search,page,thread_count=get_Input()        #获取输入的参数 如searce 、线程数、页面数      
if(search=="search_def"):      
print(r"[-]错误，未输入指定参数：python3 temp.py -s site:qq.com [-p 10] [-t 20] ")      
return      
print(search)      
threads=[]      
urls=getUrls(search,page)     #获取urls      
filename=''.join(re.findall("([a-z,0-9])",search))      #将输入的内容进行处理 ，作为文件的名称      
init_excel(filename)        #创建并初始化excel        
for url in urls:      
que.put(url)            #将获取的urls添加到queue中        
for i in range(thread_count):      
threads.append(DoRun(que,filename))     #使用多线程 默认调用 run()函数      
for i in threads:      
i.start()               #启动多线程      
for i in threads:      
i.join()                #等待线程结束      
      
print(datetime.datetime.now())      #打印结束时间      
run()

使用说明：****

python3 .\bingying.py -s "site:.com" -p 10 -t 30      
Options:      
-h, --help  show this help message and exit      
-s SEARCH, --search=SEARCH    搜索的语法(默认 site:.com)      
-p PAGE, --page=PAGE          要搜索的页数（一页10条数据，默认10页）      
-t THREADS, --threads=THREADS 线程数量，(默认为10)

结果呈现

[译] Kubernetes 必备工具：2021

Mon, 19 Jul 2021 00:00:00 CST

tools

有别于前些天的文章 - 常用的几款工具让 Kubernetes 集群上的工作更容易偏重于工具类来提升工作效率，今天这篇文章更加适合用来做选型时的参考。

文档翻译自 Kubernetes Essential Tools: 2021 ^[1]，篇幅较长，做了部分增删。

介绍

在本文中，我将尝试总结我最喜欢的 Kubernetes ^[2] 工具，并特别强调最新的和鲜为人知但我认为会非常流行的工具。

这只是我根据我的经验得出的个人清单，但为了避免偏见，我还将尝试提及每种工具的替代方案，以便你可以根据自己的需要进行比较和决定。我将尽可能缩短这篇文章并提供链接，以便你可以自行探索更多内容。我的目标是回答这个问题：“我如何在 Kubernetes 中做 X？” 通过描述不同软件开发任务的工具。

K3D

K3D ^[3] 是我最喜欢的在笔记本电脑上运行 Kubernetes (K8s) 集群的方式。它非常 轻巧且速度非常快。它是使用 Docker 围绕 K3S ^[4] 的包装器。所以，你只需要 Docker 来运行它并且资源使用率非常低。唯一的问题是 它不完全符合 K8s 标准，但这不应该是本地开发的问题。对于测试环境，你可以使用其他解决方案。K3D 比 Kind 快，但 Kind 完全兼容。

备选

• K3S ^[5] 物联网或者边缘计算• Kind ^[6] 完全兼容 Kubernetes 的备选• MicroK8s ^[7]• MiniKube ^[8]

Krew

Krew ^[9] 是管理的必备工具 Kubectl 插件，这是一个必须有任何 K8S 用户。我不会详细介绍超过 145 个可用插件 ^[10]，但至少安装 kubens ^[11] 和 kubectx ^[12]。

Lens

Lens ^[13] 是适用于 SRE、Ops 和开发人员的 K8s IDE。它适用于任何 Kubernetes 发行版：本地或云端。它快速、易于使用并提供实时可观察性。使用 Lens 可以非常轻松地管理多个集群。如果你是集群操作员，这是必须的。

备选

•对于那些喜欢轻量级终端替代品的人来说，K9s ^[14] 是一个很好的选择。K9s 会持续观察 Kubernetes 的变化，并提供后续命令来与你观察到的资源进行交互。

Helm

Helm ^[15] 不需要介绍，它是 Kubernetes 最著名的包管理器。你应该在 K8s 中使用包管理器，就像在编程语言中使用它一样。Helm 允许你将应用程序打包到 Charts ^[16] 中，将复杂的应用程序抽象为易于定义、安装和更新的可重用简单组件。

它还提供了强大的模板引擎。Helm 很成熟，有很多预定义的 charts，很好的支持，而且很容易使用。

备选

• Kustomize ^[17] 是 helm 的一个更新和伟大的替代品，它不使用模板引擎，而是一个覆盖引擎，在其中你有基本的定义和覆盖在它们之上。

ArgoCD

我相信 GitOps ^[18] 是过去十年中最好的想法之一。在软件开发中，我们应该使用单一的事实来源来跟踪构建软件所需的所有移动部分，而 Git 是做到这一点的完美工具。我们的想法是拥有一个 Git 存储库，其中包含应用程序代码以及表示所需生产环境状态的基础设施 (IaC ^[19]) 的声明性描述；以及使所需环境与存储库中描述的状态相匹配的自动化过程。

GitOps: versioned CI/CD on top of declarative infrastructure. Stop scripting and start shipping.

— Kelsey Hightower

尽管使用 Terraform ^[20] 或类似工具，你可以实现基础设施即代码（IaC ^[21]），但这还不足以将你在 Git 中的所需状态与生产同步。我们需要一种方法来持续监控环境并确保没有配置漂移。使用 Terraform，你将不得不编写脚本来运行 terraform apply并检查状态是否与 Terraform 状态匹配，但这既乏味又难以维护。

Kubernetes 从头开始构建控制循环的思想，这意味着 Kubernetes 一直在监视集群的状态以确保它与所需的状态匹配，例如，运行的副本数量与所需的数量相匹配复制品。GitOps 的想法是将其扩展到应用程序，因此你可以将你的服务定义为代码，例如，通过定义 Helm Charts，并使用利用 K8s 功能的工具来监控你的应用程序的状态并相应地调整集群。也就是说，如果更新你的代码存储库或Helm Chart，生产集群也会更新。这是真正的持续部署 ^[22]。核心原则是应用程序部署和生命周期管理应该自动化、可审计且易于理解。

对我来说，这个想法是革命性的，如果做得好，将使组织能够更多地关注功能，而不是编写自动化脚本。这个概念可以扩展到软件开发的其他领域，例如，你可以将文档存储在代码中以跟踪更改的历史并确保文档是最新的；或使用ADR ^[23]跟踪架构决策。

在我看来，在最好的 GitOps 工具 Kubernetes 是 ArgoCD ^[24]。你可以在此处 ^[25]阅读更多信息。ArgoCD 是 Argo 生态系统的一部分，其中包括一些其他很棒的工具，其中一些我们将在稍后讨论。

使用 ArgoCD，你可以在代码存储库中拥有每个环境，你可以在其中定义该环境的所有配置。Argo CD 在指定的目标环境中自动部署所需的应用程序状态。

ArgoCD 被实现为一个 kubernetes 控制器，它持续监控正在运行的应用程序并将当前的实时状态与所需的目标状态（如 Git 存储库中指定的）进行比较。ArgoCD 报告并可视化差异，并且可以自动或手动将实时状态同步回所需的目标状态。

备选

•Flux ^[26] 刚刚发布了一个具有许多改进的新版本。它提供了非常相似的功能。

Argo 工作流（Workflows）和 Argo 事件（Events）

在 Kubernetes 中，你可能还需要运行批处理作业或复杂的工作流。这可能是你的数据管道、异步流程甚至 CI/CD 的一部分。最重要的是，你甚至可能需要运行对某些事件做出反应的驱动微服务，例如文件上传或消息发送到队列。对于所有这些，我们有 Argo Workflows ^[27] 和 Argo Events ^[28]。

尽管它们是独立的项目，但它们往往会被部署在一起。

Argo Workflows 是一个类似于 Apache Airflow ^[29] 的编排引擎，但它是 Kubernetes 原生的。它使用自定义 CRD 来定义复杂的工作流程，使用 YAML 的步骤或 DAG，这在 K8s 中感觉更自然。它有一个漂亮的 UI、重试机制、基于 cron 的作业、输入和输出跟踪等等。你可以使用它来编排数据管道、批处理作业等等。

有时，你可能希望将管道与异步服务（如 Kafka 等流引擎、队列、webhooks 或深度存储服务）集成。例如，你可能想要对上传到 S3 的文件等事件做出反应。为此，你将使用 Argo 事件（Event） ^[30]。

这两个工具组合为你的所有管道需求提供了一个简单而强大的解决方案，包括 CI/CD 管道，它允许你在 Kubernetes 中本地运行 CI/CD 管道。

备选

•对于 ML 管道，你可以使用 Kubeflow ^[31]。•对于 CI/CD 管道，你可以使用 Tekton ^[32]。

Kaniko

我们刚刚看到了如何使用 Argo Workflows 运行 Kubernetes 原生 CI/CD 管道。一个常见的任务是构建 Docker 镜像，这在 Kubernetes 中通常是乏味的，因为构建过程实际上是在容器本身上运行的，你需要使用变通方法来使用主机的 Docker 引擎。

底线是你不应该使用 Docker 来构建你的镜像：改用 Kanico ^[33]。Kaniko 不依赖于 Docker 守护进程，而是完全在用户空间中执行 Dockerfile 中的每个命令。这使得在无法轻松或安全地运行 Docker 守护程序的环境中构建容器镜像成为可能，例如标准的 Kubernetes 集群。这消除了在 K8s 集群中构建镜像的所有问题。

Istio

Istio ^[34] 是市场上最著名的服务网格 ^[35]，它是开源的并且非常受欢迎。我不会详细介绍什么是服务网格，因为它是一个巨大的话题，但是如果你正在构建微服务 ^[36]，并且可能应该这样做，那么你将需要一个服务网格来管理通信、可观察性、错误处理、安全性。与其用重复的逻辑污染每个微服务的代码（译者：SDK 侵入），不如利用服务网格为你做这件事。

简而言之，服务网格是一个专用的基础设施层，你可以将其添加到你的应用程序中。它允许你透明地添加可观察性、流量管理和安全性等功能，而无需将它们添加到你自己的代码中。

如果 Istio 用于运行微服务，尽管你可以在任何地方运行 Istio 并使用微服务，但 Kubernetes 已被一次又一次地证明是运行它们的最佳平台。 Istio 还可以将你的 K8s 集群扩展到其他服务，例如 VM，允许你拥有在迁移到 Kubernetes 时非常有用的混合环境。

备选

• Linkerd ^[37] 是一种更轻巧且可能更快的服务网格。Linkerd 从头开始为安全性而构建，包括默认 mTLS ^[38]、使用 Rust 构建的数据平面 ^[39]、内存安全语言 ^[40]和定期安全审计 ^[41]等功能• Consul ^[42] 是为任何运行时和云提供商构建的服务网格，因此它非常适合跨 K8s 和云提供商的混合部署。如果不是所有的工作负载都在 Kubernetes 上运行，这是一个不错的选择。

Argo Rollouts

我们已经提到，你可以使用 Kubernetes 使用 Argo Workflows 或使用 Kanico 构建图像的类似工具来运行 CI/CD 管道。下一个合乎逻辑的步骤是继续并进行持续部署。由于涉及高风险，这在真实场景中是极具挑战性的，这就是为什么大多数公司只做持续交付，这意味着他们已经实现了自动化，但他们仍然需要手动批准和验证，这个手动步骤是这是因为团队 不能完全信任他们的自动化。

那么，你如何建立这种信任以摆脱所有脚本并完全自动化从源代码到生产的所有内容？答案是：可观察性。你需要将资源更多地集中在指标上，并收集准确表示应用程序状态所需的所有数据。目标是使用一组指标来建立这种信任。如果你在 Prometheus ^[43] 中拥有所有数据，那么你可以自动部署，因为你可以根据这些指标自动逐步推出应用程序。

简而言之，你需要比 K8s 开箱即用的 滚动更新 ^[44]更高级的部署技术。我们需要使用金丝雀部署 ^[45]进行渐进式交付。目标是逐步将流量路由到应用程序的新版本，等待收集指标，分析它们并将它们与预定义的规则进行匹配。如果一切正常，我们增加流量；如果有任何问题，我们会回滚部署。要在 Kubernetes 中执行此操作，你可以使用提供 Canary 发布等的 Argo Rollouts 。

Argo Rollouts ^[46] 是一个 Kubernetes 控制器 ^[47]和一组 CRD ^[48]，可提供高级部署功能，例如蓝绿、金丝雀、金丝雀分析、实验和向 Kubernetes 的渐进式交付功能。

尽管像 Istio ^[49] 这样的服务网格提供 Canary 发布，但 Argo Rollouts 使这个过程变得更加容易并且以开发人员为中心，因为它是专门为此目的而构建的。除此之外，Argo Rollouts 可以与任何服务网格集成。

Argo Rollouts 功能：

•蓝绿更新策略•金丝雀更新策略•细粒度、加权的流量转移•自动回滚和促销或人工判断•可定制的指标查询和业务 KPI 分析•入口控制器集成：NGINX、ALB•服务网格集成：Istio、Linkerd、SMI•指标提供者集成：Prometheus、Wavefront、Kayenta、Web、Kubernetes Jobs

备选

•Istio ^[50] 作为 Canary 版本的服务网格。Istio 不仅仅是一个渐进式交付工具，它还是一个完整的服务网格。Istio 不会自动部署，Argo Rollouts 可以与 Istio 集成来实现这一点。•Flagger ^[51] 与 Argo Rollouts 非常相似，并且与 Flux ^[52] 很好地集成在一起，因此如果你使用 Flux，请考虑使用 Flagger。•Spinnaker ^[53] 是 Kubernetes 的第一个持续交付工具，它具有许多功能，但使用和设置起来有点复杂。

Crossplane

Crossplane ^[54] 是我最喜欢的 K8s 工具，我对这个项目感到非常兴奋，因为它给 Kubernetes 带来了一个关键的缺失部分：像管理 K8s 资源一样管理第三方服务。这意味着，你可以使用 YAML 中定义的 K8s 资源来配置云提供商数据库，例如 AWS RDS ^[55] 或 GCP Cloud SQL，就像你在 K8s 中配置数据库一样。

使用 Crossplane，无需使用不同的工具和方法分离基础设施和代码。 你可以使用 K8s 资源定义一切。这样，你就无需学习 Terraform ^[56] 等新工具并将它们分开保存。

Crossplane 是一个开源 Kubernetes 附加组件，它使平台团队能够组装来自多个供应商的基础设施，并公开更高级别的自助 API 供应用程序团队使用，而无需编写任何代码。

Crossplane 扩展了你的 Kubernetes 集群，为你提供适用于任何基础架构或托管云服务的 CRD。此外，它允许你完全实现持续部署，因为与 Terraform 等其他工具相反，Crossplane 使用现有的 K8s 功能（例如控制循环）来持续观察你的集群并自动检测任何对其起作用的配置漂移。例如，如果你定义了一个托管数据库实例并且有人手动更改它，Crossplane 将自动检测问题并将其设置回以前的值。这将实施基础设施即代码和 GitOps 原则。Crossplane 与 ArgoCD 配合使用效果很好，它可以查看源代码并确保你的代码存储库是唯一的真实来源，并且代码中的任何更改都会传播到集群以及外部云服务。如果没有 Crossplane，你只能在 K8s 服务中实现 GitOps，而不能在不使用单独进程的情况下在云服务中实现，现在你可以做到这一点，这太棒了。

备选

•Terraform ^[57] 是最著名的 IaC 工具，但它不是 K8s 原生的，需要新技能并且不会自动监视配置漂移。•Pulumi ^[58] 是一种 Terraform 替代品，它使用开发人员可以测试和理解的编程语言工作。

Knative

如果你在云中开发应用程序，你可能已经使用了一些无服务器技术，例如 AWS Lambda ^[59]，它是一种称为 FaaS ^[60] 的事件驱动范例。

我过去已经讨论过 Serverless ^[61]，因此请查看我之前的文章 ^[62]以了解更多信息。Serverless 的问题在于它与云提供商紧密耦合，因为提供商可以为事件驱动的应用程序创建一个很好的生态系统。

对于 Kubernetes，如果你希望将函数作为代码运行并使用事件驱动架构，那么你最好的选择是 Knative ^[63]。Knative 旨在在 Kubernetes 上运行函数，在 Pod 之上创建一个抽象。

特点：

•针对常见应用程序用例的具有更高级别抽象的重点 API。•在几秒钟内建立一个可扩展、安全、无状态的服务。•松散耦合的功能让你可以使用所需的部分。•可插拔组件让你可以使用自己的日志记录和监控、网络和服务网格。•Knative 是可移植的：在 Kubernetes 运行的任何地方运行它，不用担心供应商锁定。•惯用的开发者体验，支持 GitOps、DockerOps、ManualOps 等常用模式。•Knative 可以与常见的工具和框架一起使用，例如 Django、Ruby on Rails、Spring 等等。

备选

•Argo Events ^[64] 为 Kubernetes 提供了一个事件驱动的工作流引擎，可以与 AWS Lambda 等云引擎集成。它不是 FaaS，而是为 Kubernetes 提供了一个事件驱动的架构。•OpenFaas ^[65]

Kyverno

Kubernetes 提供了极大的灵活性，以赋予敏捷的自治团队权力，但能力越大，责任越大。必须有一组 最佳实践和规则，以确保以一致且有凝聚力的方式来部署和管理符合公司政策和安全要求的工作负载。

有几种工具可以实现这一点，但没有一个是 Kubernetes 原生的…… 直到现在。Kyverno ^[66] 是为 Kubernetes 设计的策略引擎，策略作为 Kubernetes 资源进行管理，并且不需要新的语言来编写策略。Kyverno 策略可以验证、改变和生成 Kubernetes 资源。

你可以应用有关最佳实践、网络或安全性的任何类型的策略。例如，你可以强制所有服务都有标签或所有容器都以非 root 身份运行。你可以在此处 ^[67]查看一些政策示例。策略可以应用于整个集群或给定的命名空间。你还可以选择是只想审核策略还是强制执行它们以阻止用户部署资源。

备选

•Open Policy Agent ^[68] 是著名的云原生基于策略的控制引擎。它使用自己的声明性语言，并且可以在许多环境中运行，而不仅仅是在 Kubernetes 上。它比 Kyverno ^[69] 更难管理，但更强大。

Kubevela

Kubernetes 的一个问题是开发人员需要非常了解和理解平台和集群配置。许多人会争辩说 K8s 的抽象级别太低，这会给只想专注于编写和交付应用程序的开发人员带来很多摩擦。

在开放式应用程序模型（OAM ^[70]）的设立是为了克服这个问题。这个想法是围绕应用程序创建更高级别的抽象，它独立于底层运行时。你可以在此处阅读规范。

专注于应用程序而不是容器或协调器，开放应用程序模型 [OAM] 带来了模块化、可扩展和可移植的设计，用于使用更高级别但一致的 API 对应用程序部署进行建模。

Kubevela ^[71] 是 OAM 模型的一个实现。KubeVela 与运行时无关，可本地扩展，但最重要的是，以应用程序为中心。在 Kubevela 中，应用程序是作为 Kubernetes 资源实现的一等公民。 集群运营商（Platform Team）和开发者（Application Team）是有区别的。集群操作员通过定义组件（组成应用程序的可部署/可配置实体，如 Helm Chart）和特征来管理集群和不同的环境。开发人员通过组装组件和特征来定义应用程序。

KubeVela 是一个云原生计算基金会 ^[72]沙箱项目，虽然它仍处于起步阶段，但它可以在不久的将来改变我们使用 Kubernetes 的方式，让开发人员无需成为 Kubernetes 专家即可专注于应用程序。但是，我确实对 OAM 在现实世界中的适用性有一些担忧，因为系统应用程序、ML 或大数据过程等一些服务在很大程度上依赖于低级细节，这些细节可能很难融入 OAM 模型中。

备选

•Shipa ^[73] 遵循类似的方法，使平台和开发团队能够协同工作，轻松将应用程序部署到 Kubernetes。

Snyk

任何开发过程中一个非常重要的方面是安全性，这一直是 Kubernetes 的一个问题，因为想要迁移到 Kubernetes 的公司无法轻松实现其当前的安全原则。

Snyk ^[74] 试图通过提供一个可以轻松与 Kubernetes 集成的安全框架来缓解这种情况。它可以检测容器映像、你的代码、开源项目等中的漏洞。

备选

•Falco ^[75] 是 Kubernetes 的运行时安全线程检测工具。

Velero

如果你在 Kubernetes 中运行工作负载并使用卷来存储数据，则需要创建和管理备份。Velero ^[76] 提供简单的备份/恢复过程、灾难恢复机制和数据迁移。

与其他直接访问 Kubernetes etcd 数据库执行备份和恢复的工具不同，Velero 使用 Kubernetes API 来捕获集群资源的状态并在必要时恢复它们。此外，Velero 使你能够在配置的同时备份和恢复你的应用程序持久数据。

Schema Hero

软件开发中的另一个常见过程是在使用关系数据库时管理 模式演变。

SchemaHero ^[77] 是一种开源数据库架构迁移工具，可将架构定义转换为可应用于任何环境的迁移脚本。它使用 Kubernetes 声明性来管理数据库模式迁移。你只需指定所需的状态，然后 SchemaHero 管理其余的。

备选

•LiquidBase ^[78] 是最著名的替代品。它更难使用，且不是 Kubernetes 原生的，但它具有更多功能。

Bitnami Sealed Secrets

我们已经介绍了许多 GitOps 工具，例如 ArgoCD ^[79]。我们的目标是将所有内容保留在 Git 中，并使用 Kubernetes 声明性来保持环境同步。我们刚刚看到我们如何（并且应该）在 Git 中保留真实来源，并让自动化流程处理配置更改。

在 Git 中通常很难保留的一件事是诸如数据库密码或 API 密钥之类的秘密，这是因为你永远不应该在代码存储库中存储秘密。一种常见的解决方案是使用外部保管库（例如 AWS Secret Manager ^[80] 或 HashiCorp Vault ^[81]）来存储机密，但这会产生很多摩擦，因为你需要有一个单独的流程来处理机密。理想情况下，我们希望有一种方法可以像任何其他资源一样安全地在 Git 中存储机密。

Sealed Secrets ^[82] 旨在克服这个问题，允许你使用强加密将敏感数据存储在 Git 中。Bitnami Sealed Secrets 本地集成在 Kubernetes 中，允许你仅通过在 Kubernetes 中运行的 Kubernetes 控制器而不是其他任何人来解密密钥。控制器将解密数据并创建安全存储的原生 K8s 机密。这使我们能够将所有内容作为代码存储在我们的 repo 中，从而允许我们安全地执行持续部署，而无需任何外部依赖。

Sealed Secrets 由两部分组成：

•集群端控制器•客户端实用程序： kubeseal

该 kubeseal 实用程序使用非对称加密来加密只有控制器才能解密的机密。这些加密的秘密被编码在一个 SealedSecret K8s 资源中，你可以将其存储在 Git 中。

备选

•AWS Secret Manager ^[83]•HashiCorp Vault ^[84]）

Capsule

许多公司使用 多租户来管理不同的客户。这在软件开发中很常见，但在 Kubernetes 中很难实现。 命名空间是将集群的逻辑分区创建为隔离切片的好方法，但这不足以安全地隔离客户，我们需要强制执行网络策略、配额等。你可以为每个名称空间创建网络策略和规则，但这是一个难以扩展的乏味过程。此外，租户将不能使用多个命名空间，这是一个很大的限制。

创建 分层命名空间是为了克服其中一些问题。这个想法是为每个租户拥有一个父命名空间，为租户提供公共网络策略和配额，并允许创建子命名空间。这是一个很大的改进，但它在安全和治理方面没有对租户的本地支持。此外，它还没有达到生产状态，但 1.0 版预计将在未来几个月内发布。

当前解决此问题的常用方法是为每个客户创建一个集群，这是安全的并提供租户所需的一切，但这很难管理且非常昂贵。

Capsule ^[85] 是一种为单个集群中的多个租户提供原生 Kubernetes 支持的工具。使用 Capsule，你可以为所有租户拥有一个集群。Capsule 将为租户提供 “几乎” 原生体验（有一些小限制），他们将能够创建多个命名空间并使用集群，因为它们完全可用，隐藏了集群实际上是共享的事实。

Capsule 架构

在单个集群中，Capsule Controller 在称为 Tenant 的轻量级 Kubernetes 抽象中聚合多个命名空间，这是一组 Kubernetes 命名空间。在每个租户内，用户可以自由创建他们的命名空间并共享所有分配的资源，而策略引擎则使不同的租户彼此隔离。

租户级别定义的网络和安全策略、资源配额、限制范围、RBAC 和其他策略由租户中的所有命名空间自动继承，类似于分层命名空间。然后用户可以自由地自治操作他们的租户，而无需集群管理员的干预。Capsule 是 GitOps 就绪的，因为它是声明性的，并且所有配置都可以存储在 Git 中。

vCluster

vCluster ^[86] 在多租户方面更进了一步，它在 Kubernetes 集群内提供了虚拟集群。每个集群都在一个常规命名空间上运行，并且是完全隔离的。虚拟集群有自己的 API 服务器和独立的数据存储，所以你在 vCluster 中创建的每个 Kubernetes 对象都只存在于 vcluster 内部。此外，您可以将 kube 上下文与虚拟集群一起使用，以像使用常规集群一样使用它们。

只要您可以在单个命名空间内创建部署，您就可以创建虚拟集群并成为该虚拟集群的管理员，租户可以创建命名空间、安装 CRD、配置权限等等。

vCluster 使用 k3s ^[87] 作为其 API 服务器，使虚拟集群超轻量级且经济高效；由于 k3s 集群 100% 合规，虚拟集群也 100% 合规。 vClusters 是超轻量级的（1 个 pod），消耗很少的资源并且可以在任何 Kubernetes 集群上运行，而无需对底层集群进行特权访问。与 Capsule 相比，它确实使用了更多的资源，但它提供了更多的灵活性，因为多租户只是用例之一。

其他工具

•kube-burner ^[88] 用于 压力测试。它提供指标和警报。•混沌工程的 Litmus ^[89]。•kubewatch ^[90] 用于监控，但主要关注基于 Kubernetes 事件（如资源创建或删除）的推送通知。它可以与 Slack 等许多工具集成。•BotKube ^[91] 是一个消息机器人，用于监控和调试 Kubernetes 集群。与 kubewatch 类似，但更新并具有更多功能。•Mizu ^[92] 是一个 API 流量查看器和调试器。•kube-fledged ^[93] 是一个 Kubernetes 插件，用于直接在 Kubernetes 集群的工作节点上创建和管理容器镜像的缓存。因此， 应用程序 pod 几乎立即启动，因为不需要从注册表中提取图像。

结论

在本文中，我们回顾了我最喜欢的 Kubernetes 工具。我专注于可以合并到任何 Kubernetes 发行版中的开源项目。我没有涵盖诸如 OpenShift ^[94] 或 Cloud Providers Add-Ons 之类的商业解决方案，因为我想让它保持通用性，但我鼓励您探索如果您在云上运行 Kubernetes 或使用商业工具，您的云提供商可以为您提供什么。

我的目标是向您展示您可以在 Kubernetes 中完成您在本地所做的一切。我还更多地关注鲜为人知的工具，我认为这些工具可能具有很大的潜力，例如 Crossplane ^[95]、Argo Rollouts ^[96]或 Kubevela ^[97]。我更感兴趣的工具是 vCluster ^[98]、Crossplane ^[99] 和 ArgoCD/Workflows。

引用链接

[1] Kubernetes Essential Tools: 2021: https://itnext.io/kubernetes-essential-tools-2021-def12e84c572
[2] Kubernetes: https://kubernetes.io/
[3] K3D: https://k3d.io/
[4] K3S: https://k3s.io/
[5] K3S: https://k3s.io/
[6] Kind: https://kind.sigs.k8s.io/
[7] MicroK8s: https://microk8s.io/
[8] MiniKube: https://minikube.sigs.k8s.io/docs/
[9] Krew: https://krew.sigs.k8s.io/
[10] 插件: https://krew.sigs.k8s.io/plugins/
[11] kubens: https://github.com/ahmetb/kubectx
[12] kubectx: https://github.com/ahmetb/kubectx
[13] Lens: https://k8slens.dev/
[14] K9s: https://k9scli.io/
[15] Helm: https://helm.sh/
[16] Charts: https://artifacthub.io/
[17] Kustomize: https://kustomize.io/
[18] GitOps: https://www.gitops.tech/
[19] IaC: https://en.wikipedia.org/wiki/Infrastructure_as_Code
[20] Terraform: https://www.terraform.io/
[21] IaC: https://en.wikipedia.org/wiki/Infrastructure_as_code
[22] 持续部署: https://en.wikipedia.org/wiki/Continuous_deployment
[23] ADR: https://github.com/jamesmh/architecture_decision_record
[24] ArgoCD: https://argoproj.github.io/argo-cd/
[25] 此处: https://argoproj.github.io/argo-cd/core_concepts/
[26] Flux: https://fluxcd.io/
[27] Argo Workflows: https://argoproj.github.io/argo-workflows/
[28] Argo Events: https://argoproj.github.io/argo-events/
[29] Apache Airflow: https://airflow.apache.org/
[30] Argo 事件（Event）: https://argoproj.github.io/argo-events/
[31] Kubeflow: https://www.kubeflow.org/
[32] Tekton: https://tekton.dev/docs/pipelines/pipelines/
[33] Kanico: https://github.com/GoogleContainerTools/kaniko
[34] Istio: https://istio.io/
[35] 服务网格: https://en.wikipedia.org/wiki/Service_mesh
[36] 微服务: https://microservices.io/
[37] Linkerd: https://linkerd.io/
[38] 默认 mTLS: https://linkerd.io/2.10/features/automatic-mtls/
[39] 使用 Rust 构建的数据平面: https://github.com/linkerd/linkerd2-proxy
[40] 内存安全语言: https://github.com/linkerd/linkerd2-proxy
[41] 定期安全审计: https://github.com/linkerd/linkerd2/blob/main/SECURITY_AUDIT.pdf
[42] Consul: https://www.consul.io/
[43] Prometheus: https://prometheus.io/
[44] 滚动更新: https://www.educative.io/blog/kubernetes-deployments-strategies
[45] 金丝雀部署: https://semaphoreci.com/blog/what-is-canary-deployment
[46] Argo Rollouts: https://kubernetes.io/docs/concepts/architecture/controller/
[47] Kubernetes 控制器: https://kubernetes.io/docs/concepts/architecture/controller/
[48] CRD: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
[49] Istio: https://istio.io/
[50] Istio: https://istio.io/
[51] Flagger: https://flagger.app/
[52] Flux: https://fluxcd.io/
[53] Spinnaker: https://spinnaker.io/
[54] Crossplane: https://crossplane.io/
[55] AWS RDS: https://aws.amazon.com/rds/
[56] Terraform: https://www.terraform.io/
[57] Terraform: https://www.terraform.io/
[58] Pulumi: https://www.pulumi.com/
[59] AWS Lambda : https://aws.amazon.com/lambda/
[60] FaaS: https://en.wikipedia.org/wiki/Function_as_a_service
[61] Serverless: https://en.wikipedia.org/wiki/Serverless_computing
[62] 之前的文章: https://itnext.io/scaling-my-app-serverless-vs-kubernetes-cdb8adf446e1
[63] Knative: https://itnext.io/scaling-my-app-serverless-vs-kubernetes-cdb8adf446e1
[64] Argo Events: https://argoproj.github.io/argo-events/
[65] OpenFaas: https://www.openfaas.com/
[66] Kyverno: https://kyverno.io/
[67] 此处: https://github.com/kyverno/policies/
[68] Open Policy Agent: https://www.openpolicyagent.org/
[69] Kyverno: https://kyverno.io/
[70] OAM: https://oam.dev/
[71] Kubevela: https://kubevela.io/
[72] 云原生计算基金会: https://cncf.io/
[73] Shipa: https://www.shipa.io/getting-started/
[74] Snyk: https://snyk.io/
[75] Falco: https://falco.org/
[76] Velero: https://velero.io/
[77] SchemaHero: https://schemahero.io/
[78] LiquidBase: https://www.liquibase.org/
[79] ArgoCD: https://argoproj.github.io/argo-cd/
[80] AWS Secret Manager: https://aws.amazon.com/secrets-manager/
[81] HashiCorp Vault: https://www.vaultproject.io/
[82] Sealed Secrets: https://github.com/bitnami-labs/sealed-secrets
[83] AWS Secret Manager: https://aws.amazon.com/secrets-manager/
[84] HashiCorp Vault: https://www.vaultproject.io/
[85] Capsule: https://github.com/clastix/capsule
[86] vCluster: https://www.vcluster.com/
[87] k3s: https://k3s.io/
[88] kube-burner: https://github.com/cloud-bulldozer/kube-burner
[89] Litmus: https://github.com/litmuschaos/litmus
[90] kubewatch: https://github.com/bitnami-labs/kubewatch
[91] BotKube: https://www.botkube.io/
[92] Mizu: https://getmizu.io/
[93] kube-fledged: https://github.com/senthilrch/kube-fledged
[94] OpenShift: https://www.openshift.com/
[95] Crossplane: https://crossplane.io/
[96] Argo Rollouts: https://kubevela.io/
[97] Kubevela: https://kubevela.io/
[98] vCluster: https://www.vcluster.com/
[99] Crossplane: https://crossplane.io/

jvm 性能调优工具之 jmap - 简书

Fri, 02 Jul 2021 09:03:12 CST

概述

命令jmap是一个多功能的命令。它可以生成 java 程序的 dump 文件，也可以查看堆内对象示例的统计信息、查看 ClassLoader 的信息以及 finalizer 队列。

jmap 用法

参数：

option：选项参数。
pid：需要打印配置信息的进程ID。
executable：产生核心dump的Java可执行文件。
core：需要打印配置信息的核心文件。
server-id可选的唯一id，如果相同的远程主机上运行了多台调试服务器，用此选项参数标识服务器。
remote server IP or hostname远程调试服务器的IP地址或主机名。

option

no option：查看进程的内存映像信息,类似 Solaris pmap 命令。
heap：显示Java堆详细信息
histo[:live]：显示堆中对象的统计信息
clstats：打印类加载器信息
finalizerinfo：显示在F-Queue队列等待Finalizer线程执行finalizer方法的对象
dump:<dump-options>：生成堆转储快照
F：当-dump没有响应时，使用-dump或者-histo参数. 在这个模式下,live子参数无效.
help：打印帮助信息
J<flag>：指定传递给运行jmap的JVM的参数

示例一：no option

命令：jmap pid
描述：查看进程的内存映像信息,类似 Solaris pmap 命令。

使用不带选项参数的jmap打印共享对象映射，将会打印目标虚拟机中加载的每个共享对象的起始地址、映射大小以及共享对象文件的路径全称。这与Solaris的pmap工具比较相似。

示例二：heap

命令：jmap -heap pid
描述：显示Java堆详细信息

打印一个堆的摘要信息，包括使用的GC算法、堆配置信息和各内存区域内存使用信息

    C:\Users\jjs>jmap -heap 5932
Attaching to process ID 5932, please wait...
Debugger attached successfully.
Server compiler detected.
JVM version is 25.91-b15

using thread-local object allocation.
Parallel GC with 4 thread(s)

Heap Configuration:
   MinHeapFreeRatio         = 0
   MaxHeapFreeRatio         = 100
   MaxHeapSize              = 1073741824 (1024.0MB)
   NewSize                  = 42991616 (41.0MB)
   MaxNewSize               = 357564416 (341.0MB)
   OldSize                  = 87031808 (83.0MB)
   NewRatio                 = 2
   SurvivorRatio            = 8
   MetaspaceSize            = 21807104 (20.796875MB)
   CompressedClassSpaceSize = 1073741824 (1024.0MB)
   MaxMetaspaceSize         = 17592186044415 MB
   G1HeapRegionSize         = 0 (0.0MB)

Heap Usage:
PS Young Generation
Eden Space:
   capacity = 60293120 (57.5MB)
   used     = 44166744 (42.120689392089844MB)
   free     = 16126376 (15.379310607910156MB)
   73.25337285580842% used
From Space:
   capacity = 5242880 (5.0MB)
   used     = 0 (0.0MB)
   free     = 5242880 (5.0MB)
   0.0% used
To Space:
   capacity = 14680064 (14.0MB)
   used     = 0 (0.0MB)
   free     = 14680064 (14.0MB)
   0.0% used
PS Old Generation
   capacity = 120061952 (114.5MB)
   used     = 19805592 (18.888084411621094MB)
   free     = 100256360 (95.6119155883789MB)
   16.496143590935453% used

20342 interned Strings occupying 1863208 bytes.

示例三：histo[:live]

命令：jmap -histo:live pid
描述：显示堆中对象的统计信息

其中包括每个Java类、对象数量、内存大小(单位：字节)、完全限定的类名。打印的虚拟机内部的类名称将会带有一个’*’前缀。如果指定了live子选项，则只计算活动的对象。

示例四：clstats

命令：jmap -clstats pid
描述：打印类加载器信息

-clstats是-permstat的替代方案，在JDK8之前，-permstat用来打印类加载器的数据
打印Java堆内存的永久保存区域的类加载器的智能统计信息。对于每个类加载器而言，它的名称、活跃度、地址、父类加载器、它所加载的类的数量和大小都会被打印。此外，包含的字符串数量和大小也会被打印。

示例五：finalizerinfo

命令：jmap -finalizerinfo pid
描述：打印等待终结的对象信息

Number of objects pending for finalization: 0 说明当前F-QUEUE队列中并没有等待Fializer线程执行final

示例六：dump:<dump-options>

命令：jmap -dump:format=b,file=heapdump.phrof pid
描述：生成堆转储快照dump文件。

以hprof二进制格式转储Java堆到指定filename的文件中。live子选项是可选的。如果指定了live子选项，堆中只有活动的对象会被转储。想要浏览heap dump，你可以使用jhat(Java堆分析工具)读取生成的文件。

这个命令执行，JVM会将整个heap的信息dump写入到一个文件，heap如果比较大的话，就会导致这个过程比较耗时，并且执行的过程中为了保证dump的信息是可靠的，所以会暂停应用，线上系统慎用。

IT瘾工具推荐

亚马逊因 AI 编码工具引发多起故障

NotebookLM：我目前最常用、也最愿意推荐的 AI 学习与内容组织工具

NotebookLM 给我带来的核心价值

快速理解陌生技术：把庞杂资料丢进去，它帮我生成“可学的版本”

生成 MindMap：大量文档瞬间变成结构化知识图谱

生成教学大纲、培训稿、图书结构：真正节约我大量时间

多格式输入能力：这是我见过最稳的

我目前最常用的 NotebookLM 工作流

我遇到的小遗憾与建议

MindMap 的导出格式应该支持 SVG 或基于文本（Markmap）

对话记录应该支持长期保存

幻灯片生产能力如果能支持模板，会更适合作为创作者工具

Deep Research 早日上线并全面开放

移动端希望尽快增强，而不是只提供播放内容

总结

网络安全专家爱用的逆向工具 Top9

1.十六进制编辑器

2.OllyDbg

3.APKTool

4.WireShark

5.Scylla

6.Dex2jar

7.CCF

8.Oracle VM VirtualBox

9.BinaryNinja

开源实时数据同步工具NiFi

Apache NiFi简介

Apache NiFi主要功能

Apache NiFi的优势

Apache NiFi的架构

核心组件

工作流和数据流

分布式架构

安全性

Airflow、Kafka的对比

相关文章:

将 Android 手机变成监听工具

Python地理数据分析工具MovingPandas

MovingPandas的使用

MovingPandas的安装

MovingPandas接口详解

MovingPandas.Trajectory对象

MovingPandas.TrajectoryCollection对象

MovingPandas.TrajectoryCollectionAggregator对象

MovingPandas.TrajectoryCleaner对象

MovingPandas.TrajectoryGeneralizer对象

MovingPandas.TrajectorySmoother对象

MovingPandas.TrajectorySplitter对象

MovingPandas.TrajectoryStopDetector对象

MovingPandas使用实例

准备工作

停留点检测

速度计算

提取位置

导出轨迹

轨迹分割

轨迹抽稀

平滑轨迹

轨迹聚类和分类

距离计算

相关文章:

开源可视化报表工具：Superset

Superset简介

Superset架构

Superset功能扩展

相关文章:

你的Spring Boot应用启动很慢？不妨试试这个工具！

分析能力

如何使用

启动优化

自动生成代码工具-cursor(集成ChatGpt)

配置

操作

ctrl+k：生成代码

ctrl+l：智能对话

用途

参考链接

[分享创造] Vesta: 一个 Docker 和 Kubernetes 配置安全的快速检查工具

Vesta 可以做什么