背景
为了减少数据库查询的延迟, 我们决定将我们的数据库迁移到离后端程序更近的一个区域.
TLDR
为了减少应用停机时间, 最后采用的是基于 pglogical 插件的逻辑复制方案.
服务器执行 docker exec
失败
# docker exec -it user-ab107i9 sh
OCI runtime exec failed: exec failed: unable to start container process: open /dev/pts/0: operation not permitted: unknown
搜索一下发现 Issue:
https://github.com/moby/moby/issues/43969
Issue 中提到这个问题在 runc v1.1.4
中已经修复.
检查一下 runc
版本, 为 1.1.3
, ok, 确认为 runc
的问题.
想着要升级 docker 版本会造成服务停止问题, 就没处理.
作为一个程序员, 平时经常使用一些开源项目, 维护一个开源项目是不容易的, 要花费很多精力在上 面, 大多数开源项目一般是作者爱心发电, 经常会在 GitHub 上看到一些已经归档了的项目, 作者表 示自己没有精力再维护这个项目了. 我想如果我们能给这些开发者一点小小的帮助, 让这些项目对他 们来说不仅仅具有精神价值, 更有物质价值, 他们或许就会花更多时间在这个项目上. 有时也惊讶于 这世上也有如此理想主义的实物 (开源软件, 互联网的分享精神…), 自己身在这个时代, 我很感激. 这可能也是我选择当程序猿的一个原因吧.
OpenTelemetry is a collection of tools, APIs, and SDKs. Use it to instrument, generate, collect, and export telemetry data (metrics, logs, and traces) to help you analyze your software’s performance and behavior.1
使用 OpenTelemetry 可以了解很多系统运行的信息, 这些数据可以分成三类: Traces, Metrics, Logs, 分别代表链路追踪, 应用的指标与日志. 在 OTel 中这些类别被称为 Signals.
定时任务是业务开发中必不可少的一个系统组件, 与消息队列, 缓存, 数据库一样. 微服务架构目前 (2022) 已经是高并发, 大规模的后端最佳实践, 本文将对比业界主流的定时任务框架, 并根据自己 的需求给出心目中微服务定时任务框架的最好选择.