项目开源工具

[wxb]

项目开源工具

[wxb]

Temporal—durable execution platform

Introduction

Temporal is a durable execution platform that enables developers to build scalable applications without sacrificing productivity or reliability.
The Temporal server executes units of application logic called Workflows in a resilient manner that automatically handles intermittent failures, and retries failed operations.

[wxb]

Temporal 编排，就是用 Temporal 这个开源工作流引擎，把跨服务、长时间、容易失败的业务流程，写成“像普通代码一样”的逻辑，由引擎帮你自动处理状态持久化、重试、故障恢复和分布式协调。

---

一、一句话定义

Temporal = 分布式持久化工作流引擎

• 用来编排：跨微服务、跨机器、跨小时/天的长流程
• 核心：状态自动保存、失败自动重试、断了能续跑、代码即流程

---

二、解决什么痛点（非常关键）

不用 Temporal 时，你要自己写一堆：

• 状态存 DB、查状态
• 失败重试、超时、回滚
• 分布式锁、幂等、补偿逻辑
• 消息队列回调、顺序、一致性

Temporal 全部帮你做掉，你只关心业务逻辑。

---

三、核心概念（3个就够）

1. Workflow（工作流）

   • 业务流程的“骨架”
   • 串行/并行/条件分支/循环
   • 代码写的，不是配置文件

2. Activity（活动）

   • 具体执行步骤（调用接口、DB、第三方服务）
   • 可重试、可超时、可隔离
   • Workflow 调用 Activity，不直接写死调用

3. Temporal Server + Worker

   • Server：存状态、队列、调度、事件日志
   • Worker：真正跑 Activity/Workflow 的进程（可多实例、水平扩展）

---

四、编排长什么样（伪代码示例）

# Workflow：订单履约流程（长流程，跨服务）
@workflow.defn
class OrderFulfillment:
    @workflow.run
    async def run(self, order):
        # 1. 预占库存（Activity）
        await self.reserve_stock(order)

        # 2. 创建支付单（Activity）
        pay_id = await self.create_payment(order)

        # 3. 等待用户支付（等待外部事件，可等几天）
        await self.wait_for_payment(pay_id)

        # 4. 出库发货（Activity）
        await self.ship_goods(order)

        # 5. 结算（Activity）
        await self.settle_account(order)

• 流程可以跑几分钟、几小时、几天
• 任何一步失败：自动重试
• 进程挂了、机器宕机：重启后从断点继续跑
• 支持暂停、恢复、人工审批、回滚

---

五、和 MQ 编排（Choreography）的区别

• MQ（事件驱动）：各服务互相发消息，流程分散、状态难追踪、一致性难保证
• Temporal（Orchestration）：中心化编排，流程集中、状态清晰、自动容错、可回滚

简单说：

• 简单短流程 → MQ
• 复杂长流程、要一致性、要可靠 → Temporal

---

六、核心优势（记住这4点）

1. 代码即流程：不用学复杂配置，普通代码写流程
2. 状态持久化：自动存状态，宕机不丢、断点续跑
3. 容错极强：自动重试、超时、回滚、补偿
4. 分布式协调：跨服务、跨机器、水平扩展，不用自己造轮子

---

总结

Temporal 编排 = 用代码定义长流程 + 引擎自动管状态/重试/容错 + 分布式可靠执行，让复杂业务流程写得简单、跑得稳定、维护轻松。

[wxb]

OpenAPI Generator

OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)

openapi-generator.tech

[wxb]

OpenAPI Generator 核心功能总结：

1. 代码生成
   基于 OpenAPI 2.0/3.x 接口文档，一键生成客户端SDK（50+种语言）、服务端脚手架（40+技术栈），避免手写接口代码。

2. 文件结构生成
   支持生成数据库表结构（MySQL）、配置文件（Apache2）、GraphQL 模型等各类结构化文件。

3. 接口文档生成
   自动输出 HTML 等格式的离线接口文档，也能完成 OpenAPI 旧版本转新版本。

4. 高度自定义
   支持自定义模板、参数配置、自定义生成器，适配项目个性化需求。

5. 多环境集成
   提供 CLI、Maven/Gradle 插件、Docker、NPM 等多种部署使用方式，适配开发、CI/CD 流程。

简单说：只要有接口规范文档，就能自动帮你生成前后端、服务端、数据库、文档相关代码，大幅提升接口开发效率。

[wxb]

OpenTelemetry 遥测开放标准

高质量、普遍适用和可移植的遥测助你实现有效的可观测

[wxb]

OpenSearch

OpenSearch 是一款开源的企业级搜索与可观测性套件，能够大规模地梳理非结构化数据

[wxb]

Prometheus

借助领先的开源监控解决方案监控你的应用程序、系统和服务。对指标进行检测、收集、存储和查询，以用于告警、仪表盘制作及其他场景。

[wxb]

VictoriaMetrics

开源与企业级可观测性解决方案

[wxb]

Prometheus和victoriametrics 有什么区别

1. Prometheus 是啥？

一套监控采集+短时存指标+查指标的工具。

1. 主动拉取服务器、程序的运行数据（CPU、内存、接口耗时、报错量这类数字指标）；
2. 自带小型数据库存这些监控数据；
3. 自带查询语法 PromQL，配合 Grafana 画监控大盘、配告警。

短板：
存不了太久数据（默认只存15天，存几个月硬盘爆炸）、数据压缩差、量大了卡顿、难以横向扩容。

2. VictoriaMetrics（VM）是啥？

高性能时序数据库，专门用来长期存监控指标，完美兼容 Prometheus。
简单理解：Prometheus 自带的存储太弱，VM 是它的专业大容量外接硬盘。

功能：

1. 完全兼容 Prometheus 的数据格式、查询语法，Prometheus 可以直接把数据远程推给 VM；
2. 压缩极强，同样数据占用磁盘只有 Prometheus 1/10，能存数月甚至数年监控；
3. 扛得住超大监控量级，单机性能远超 Prometheus，支持分布式集群无限扩容；
4. 自带配套工具：vmagent（替代 Prometheus 做数据采集）、vmalert（告警）、内置可视化页面。

一句话总结

• Prometheus：采集监控指标 + 短期临时存储，适合小规模、短期监控；
• VictoriaMetrics：专业大容量长期存储引擎，可以搭配 Prometheus 使用，也能完全替代整套 Prometheus 做完整监控。

[wxb]

时序数据库（以VictoriaMetrics为例） vs OpenSearch：异同、选型标准

一、核心定义先分清

1. 时序数据库（TSDB，如VictoriaMetrics）
   专用数值型时间序列存储引擎，核心对象：时间戳+指标名+标签+数值，专为海量监控指标、IoT传感器数值做底层优化。
2. OpenSearch
   通用全文检索/文档搜索引擎，基于Lucene倒排索引，核心对象是JSON文档，擅长非结构化文本、半结构化日志全文检索，时序只是附带能力。

二、相同点

1. 都支持带时间戳的数据写入、按时间范围过滤、时间聚合（按小时/天统计）；
2. 均分布式水平扩展、支持集群高可用、冷热数据分层存储；
3. 都可接入OpenTelemetry、采集监控/日志数据，搭配可视化面板做观测大盘；
4. 支持告警、多标签过滤、海量流式数据实时摄入。

三、核心差异（最关键）

1. 底层存储与数据模型

• VictoriaMetrics（TSDB）
  列式时序分片存储，按时间+seriesID分区；同一指标连续数值做专用时序压缩；
  模型极简：只存数值+时间戳+标签，无冗余文本字段开销。
• OpenSearch
  倒排索引+行式文档存储；每条日志/指标完整存储整个JSON对象，所有文本字段都建分词索引；
  模型通用：支持文本、数字、数组、嵌套对象、向量，结构灵活但冗余大。

2. 存储压缩与资源开销（差距极大）

• VictoriaMetrics：压缩率极高，同等指标数据磁盘占用仅OpenSearch的1/5~1/10，内存消耗极低，单节点可承载上亿活跃时序、每秒百万级样本写入；客户案例显示AWS存储成本降低10倍。
• OpenSearch：全文分词索引占用大量内存与磁盘；纯数值指标场景资源开销是TSDB数倍，大规模监控场景硬件成本很高。

3. 查询能力侧重点

TSDB（VictoriaMetrics）强项：数值时序聚合

• 原生PromQL/MetricsQL，内置rate、sum、分位数、降采样、预测、环比同比；
• 擅长长时间范围大盘计算（查30天CPU趋势、每秒百万指标聚合），秒级返回聚合结果；
• 不擅长全文模糊匹配、关键词检索、日志原文定位。

OpenSearch强项：全文检索、复杂文本过滤

• 模糊匹配、短语检索、通配符、分词高亮、错误拼写纠错、嵌套文档查询；
• 适合：搜报错堆栈、接口异常日志、安全审计日志关键词；
• 做大规模指标聚合性能差，长时间范围查询容易OOM、超时。

4. 运维与场景适配

• VictoriaMetrics：轻量化，单节点开箱即用，无需复杂索引调优；原生适配K8s、Prometheus监控生态；
• OpenSearch：运维复杂，需手动调分片、索引生命周期、分词模板；分片合并、段合并消耗大量CPU，大规模集群维护成本高。

5. 配套生态（结合你提供的VictoriaMetrics官网）

VictoriaMetrics完整可观测栈拆分：

• VictoriaMetrics：指标metrics（CPU、内存、QPS等数值）
• VictoriaLogs：日志专用存储（替代OpenSearch存日志，压缩更强）
• VictoriaTraces：链路Trace存储
  OpenSearch是一体化方案：指标+日志+Trace全塞同一个引擎，但每项都不如专用组件。

四、什么时候必须用时序数据库（VictoriaMetrics）

满足任意一条，优先选TSDB：

1. 核心数据是纯数值监控指标
   服务器/容器/中间件CPU、内存、磁盘、网络、接口QPS、延迟、错误率、业务埋点数值、光伏/风电IoT传感器读数；每秒数十万~亿级数值写入。
2. 需要长期低成本保存时序趋势
   保留数月/数年历史指标，做月度容量规划、长期性能复盘；OpenSearch存储成本会爆炸，客户实测存储成本高5~10倍。
3. 依赖时序聚合大盘、持续告警
   Grafana监控面板、Prometheus告警、自动降采样；需要快速计算多维度指标趋势、环比同比。
4. 希望低资源、轻量化部署
   边缘设备、树莓派、中小服务器集群，不想投入大量内存/磁盘；VictoriaMetrics单节点即可承载大规模监控。
5. 现有Prometheus生态，想零改造迁移
   vmagent完美兼容Prometheus Remote Write，20分钟完成迁移，无需修改采集代码、查询语句。

五、什么时候必须用OpenSearch

满足任意一条，优先OpenSearch：

1. 核心需求是日志全文检索
   需要根据报错关键词、堆栈、用户ID、请求参数模糊搜索原始日志；排查线上故障、检索异常堆栈、按关键字过滤全量日志原文。
2. 安全审计、SIEM场景
   审计登录日志、防火墙日志、攻击行为日志，需要模糊检索、分词匹配、向量检索（OpenSearch原生向量库）。
3. 业务全文检索需求（非观测场景）
   电商商品搜索、企业文档知识库、站内内容检索，需要分词、相关性打分、模糊查询。
4. 数据结构极度灵活、大量非结构化文本
   日志字段不固定、嵌套JSON、长文本堆栈、任意自定义字段，需要动态映射无需预定义Schema。
5. Trace链路完整文本检索
   需要根据接口名、异常message、用户参数精准定位单条完整链路详情（纯数值时序库只存Trace指标，不存完整文本链路内容）。

六、行业标准组合方案（大厂通用，含Airbnb、Spotify案例）

VictoriaMetrics（TSDB） + OpenSearch 分工搭配，互不替代

1. VictoriaMetrics：存纯数值指标（CPU、QPS、延迟、设备传感器数值），做监控大盘、容量趋势、告警、长期存储降本；
2. OpenSearch：存原始日志、完整链路Trace文本、安全审计日志，做故障关键词检索、堆栈排查、审计检索；
   官网案例Airbnb方案：vmagent采集指标写入VictoriaMetrics做千万级指标聚合，日志/完整链路存入检索引擎做故障排查，成本降低10倍。

极简选型口诀

• 看数值趋势、监控大盘、海量指标、省钱长期存储 → 时序数据库VictoriaMetrics
• 看日志原文、关键词搜报错、全文检索、安全审计 → OpenSearch
• 完整可观测标准架构：两者搭配各司其职，不要用OpenSearch硬扛大规模指标，也不要用时序库检索日志堆栈。