proto 3 VS proto 2
proto 3 是 proto 2 的简化版，当前两个版本均处于活跃状态。 常见问题proto 3 和 proto 2 是导线（wire）兼容的：这意味着若在 proto 2 和 proto 3 中构造具有相同的二进制表示，那么它们可以跨版本引用符号，并生成配合良好的代码。 区别存在性（optional） proto 2: 原生支持 optional。新应用中可以使用封装（wrapper）类型来表
归档: 2024
使用 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 的更详细介绍可以参考
通过 Pulsar CDC 获取 Postgres 数据表变更记录
在当今数据驱动的时代，数据的实时性、完整性和一致性成为了企业业务成功的关键因素。随着微服务单服单库（每个微服务都有自己单独的数据库）的应用，以及数据量的爆炸性增长和业务的快速迭代，传统的数据处理和同步方式已难以满足现代企业的需求。Apache Pulsar，作为一个云原生的分布式消息和流处理平台，凭借其卓越的吞吐量和低延迟特性，正在逐渐成为大数据和流处理领域的明星。而Pulsar CDC技术的引入
使用 clap 和 opendal 开发一个云存储 cli
在使用 gitlab 做 CI/CD 时，需要将构建好的制品推送到云存储中（比如 华为云 OBS、阿里云 OSS、AWS S3 等），然后在部署的时候再直接从云存储中下载。为方便使用，就使用 clap 和 opendal 开发了一个简单的云存储命令行工具，此示例支持 OBS 和 OSS，需要添加其它云存储支持也非常方便，具体可以参考 https://docs.rs/opendal/latest/o