通用分布式任务调度系统设计

目标设计一款可靠、易用、可扩展、轻量的通用分布式任务调度系统。暂且将此系统称为：fusion-scheduler，融合各类业务的调度系统之意。 可靠：采用分布式设计，避免任务丢失，支持对失败任务的自动或手动重试 易用：支持固定间隔、固定延迟、CRON 表达式、API 触发、工作流、MapReduce 等调度方式，满足各类业务需求 可扩展：支持动态添加、删除任务、动态修改任务配置，支持动态添加、删

通用分布式任务调度系统设计

目标设计一款可靠、易用、可扩展、轻量的通用分布式任务调度系统。暂且将此系统称为：fusion-scheduler，融合各类业务的调度系统之意。 可靠：采用分布式设计，避免任务丢失，支持对失败任务的自动或手动重试 易用：支持固定间隔、固定延迟、CRON 表达式、API 触发、工作流、MapReduce 等调度方式，满足各类业务需求 可扩展：支持动态添加、删除任务、动态修改任务配置，支持动态添加、删

docs: 撰写《Rust gRPC 编译手册：tonic-build》

Rust gRPC 编译手册：tonic-build

前面章节已经简单介绍了 tonic-build 的使用，本节将深入 tonic-build，详细介绍在编译 .proto 文件时可提供的定制功能。 安装cargo使用 tonic-build 需要在 Cargo.toml 中配置以下依赖 123456[dependencies]tonic = "0.12"prost = "0.13"[build-depend

深入浅出 gRPC-Web：使用 tonic 和 nice-grpc

什么是 gRPC-WebgRPC-Web 是一个基于 gRPC 的跨平台 Web 客户端。使用 gRPC，可以在 .proto 文件中定义服务，并使用任何一种支持 gRPC 的编程语言编写客户端和服务端实现，而这些语言反过来又可以在从大型数据中心内的服务器到个人的平板电脑等各种环境中运行——不同语言和环境之间通信的所有复杂性都由 gRPC 来处理。还可以获得使用 protocol buffer 的

在 Next.js 中整合 gRPC 和 gRPC-WEB：构建高效的全栈应用

本文将介绍如何在 Next.js 应用中结合 Tonic 框架，实现 gRPC 和 gRPC-WEB 的无缝集成。我们将详细介绍如何在服务端组件和 API 路由中使用 gRPC 与后端微服务通信，以及如何在客户端组件中利用 gRPC-WEB 直接与后端服务交互。这种方法充分发挥了 Next.js 的服务端渲染能力和 gRPC 的高性能特性，同时保证了前后端的一致性和开发效率。 对于 gRPC 和

proto 3 VS proto 2

proto 3 是 proto 2 的简化版，当前两个版本均处于活跃状态。 常见问题proto 3 和 proto 2 是导线（wire）兼容的：这意味着若在 proto 2 和 proto 3 中构造具有相同的二进制表示，那么它们可以跨版本引用符号，并生成配合良好的代码。 区别存在性（optional） proto 2: 原生支持 optional。新应用中可以使用封装（wrapper）类型来表

使用 Rust 进行高效能的后端开发：00

或许，应该先定义下 高效能（我心中的）： 健壮：程序缺陷和bug少，能够在编译时发现大多数错误。 高性能：API 服务应具备低延迟和高吞吐量的能力，以适应高并发场景。 低资源消耗：在相同吞吐量和响应速度下，占用的系统资源（CPU、内存）越低越好。 开发效率：开发效率应高于大部分语言/框架，以减少开发成本和提升业务快速响应效率。这里强调一点，我认为的开发效率聚集的真实开发的效率，不包括学

“我的”未来技术选型

技术先给出结论，后面有机会建立新团队或启动新项目时，我会优先考虑如下技术选型（这里列出对于大部分系统开发需要的主要技术）： 后端：Python + Rust WEB：Vue（TS） RPC：gRPC 数据库：PostgreSQL APP：平台原生技术，Kotlin(Android)、Swfit(iOS)、ArkTS/Cangjie(Harmony) 综合考虑了正确性、健壮性、开发效率

软件架构：通过 CDC 技术聚合多个微服务的数据

本文讨论 CDC 技术在微服务开发中的应用。在使用微服务以后，除了微服务带来的优势，随之而来的也有以前使用单体应用时不曾遇到的问题，比如：分库以后的多表联查、数据一致性等问题。本文将讨论以下两大问题应用 CDC 技术的解决方案： 分库后的多表联查 CQRS（读写分离） 实时数仓 数据一致性 采用事件消息表实现事件驱动性设计 基于最终一致性的分布式事物 有关 CDC 的更详细介绍可以参考