使用 Rust 进行高效能的后端开发：00
或许，应该先定义下 高效能（我心中的）： 高性能：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
数据的相等性比较引发的 BUG
问题相同的代码逻辑，在不同的环境得出了不同的结果。在业务系统里是正确的，但是数据系统里却计算出了不同的结果。给一个示例： 12345Integer x = 1234567;Long y = 1234567L;if (x.equals(y))) { // 处理业务逻辑} 我们预期if语句判断能够成功并进入进行处理业务逻辑，但实际上这里会始终返回 false。这是因为jav
使用 Pulsar CDC 同步 PostgreSQL
问题监控发现 PostgreSQL 的 pg_wal 日志文件一直在持续增长，设置的 max_wal_size = 2GB 参数值未起作用。 12-bash-4.2$ du -sh $PGDATA/pg_wal61G /data/pgsql/12/data/pg_wal 12345postgres=# select pg_walfile_name('0/14CB2278
微服务：代码分层
本篇是微服务系统的第一篇，我将基于自身的经验和在公司项目中的实践来记录我们施行微服务的过程和方式。
Pulsar 2.7：集群，认证、授权，函数计算，CDC
一些问题 Apache Pulsar 2.7.1 当 Functions Worker 独立运行时，客户端需要直接 Worker，现在的 Pulsar 还不能通过 broker 找到 Worker 地址。社区已有相应的 PR #6425 修复 当配置了 Pulsar 集群配置了认证/授权，且 connector 使用进程模式运行时，现在 connector 未继承 Functions Worke
使用 gRPC 设计 API 的优势
现阶段 API 设计的问题在开发过程中，有一些很困扰前、后端团队交互的问题： 谁来设计 API？ 提供什么形式的 API？ 什么时候可以提供 API？ 对于第一个问题，通常情况下都是由后端人员来设计 API，这就造成前端人员会在开发初期的一段时间内没法作数据模型和服务端交互方面的工作。这时，一些独立的 API 管理工具就派上用场了，比如：类似 yapi 这样的 API 管理/Mock 工具。前