一周热榜

我曾经认为，在服务之间定义清晰的接口和契约，就足以维持模块化。我共享一个数据库，因为它看起来是最省事的做法。我错了。共享数据库或任何跨越到外部组件边界的资源，都会创建一个“焊接”接头，它无视任何接口定义。这会引发一连串的故障，随时可能发生。<p>许多工程师希望避免严格定义数据所有权带来的摩擦。他们寻求一个礼貌、中立的区域来避免冲突。我认为这种方法在智力上是不诚实的。通过避免执行真正模块化所需的冲突，你构建的系统注定会在模式发生变化的那一刻崩溃。<p>我不得不为此付出惨痛的代价。我现在对每个组件的数据层都强制执行严格的分离。这在前期更难，但它是构建能够扩展而不会因自身重量而崩溃的系统的唯一方法。如果你正在共享数据库，或者以任何方式让你的域数据跨越到外部模块的边界，那么你并没有构建一个模块化系统。你只是在推迟不可避免的崩溃。

大家好，分享一下我最新的替代方案，可以替代 Elasticsearch、CloudWatch 等，这些方案要么需要支付高昂的云服务费用，要么托管解决方案的成本更高。这虽然是一个已知的模式，但可能还不够普及：将日志写入 S3 作为持久化存储，使用 Parquet 格式，并用 DuckDB 进行快速查询。这已经成为我所有副项目摄取日志的主要方式，而且我再也不用担心丢失日志，而且存储可能还是免费的。<p>功能<p><pre><code> 格式无关 - 通过可配置的字段提取，适用于任何 JSON 日志格式 快速 - 每秒摄取 28K+ 条目 高效 - Parquet + Snappy (3.7 倍压缩) 快速查询 - 在 56K 条日志上，DuckDB 查询时间小于 50 毫秒 S3 兼容 - AWS S3、MinIO、DigitalOcean Spaces、R2 等 分区 - 类似 Hive 的按日期/级别分区（没有冗余的分区后缀） 自动刷新 - 可配置的自动刷新（默认：90 秒） 去重 - 可选的去重 </code></pre> 很乐意回答关于内部机制的任何问题