一周热榜

我曾经认为，定义清晰的接口和服务之间的契约就足以维持模块化。我共享数据库，因为这似乎是最简单的选择。我错了。共享数据库或任何跨越外部组件边界的资源，会形成一种“焊接”连接，违背了任何接口定义。这会造成潜在的故障级联，随时可能发生。 许多工程师希望避免严格定义数据所有权所带来的摩擦。他们寻求一个礼貌的中立区域，以避免冲突。我认为这种做法在智识上是不诚实的。通过避免为了强制执行真正的模块化而必须进行的对抗，你构建的系统注定会在架构变化的那一刻崩溃。 我不得不通过艰难的方式学习到这一点。现在，我在每个组件的数据层强制严格分离。虽然这在前期更困难，但这是构建能够扩展而不至于在自身重压下崩溃的系统的唯一方法。如果你在共享数据库，或者以任何方式让你的领域数据跨越到外部模块，你就不是在构建一个模块化系统，而是在推迟不可避免的崩溃。

大家好，分享我最近找到的替代方案，适用于 Elasticsearch、CloudWatch 等那些需要高额云费用或管理解决方案成本更高的服务。这是一种已知的模式，但可能不够广为人知：将日志写入 S3 作为持久存储，使用 Parquet 格式并通过 DuckDB 快速查询。这已经成为我所有副项目中处理日志的主要方式，我再也不用担心丢失日志，并且可能还可以免费存储。 <p>功能<p> <pre><code> 格式无关 - 通过可配置字段提取，支持任何 JSON 日志格式 快速 - 每秒处理 28K+ 条目 高效 - 使用 Parquet + Snappy（压缩比 3.7x） 快速查询 - DuckDB 在 56K 日志上查询时间小于 50ms 兼容 S3 - 支持 AWS S3、MinIO、DigitalOcean Spaces、R2 等 分区 - 按日期/级别进行 Hive 风格的分区（无冗余的部分后缀） 自动刷新 - 可配置的自动刷新（默认：90秒） 去重 - 可选去重 </code></pre> 欢迎随时询问有关内部实现的问题。