最新

我开发了 EventFlux，这是一个用 Rust 编写的开源流处理引擎。这个想法很简单：当你不需要管理集群和配置的开销来处理简单的流式场景时，何必去处理这些呢？ 它作为一个单一的二进制文件运行，使用 50-100MB 的内存，启动时间在毫秒级，并且能够处理每秒超过 100 万个事件。无需 Kubernetes、JVM 或 Kafka 集群——只需编写 SQL 并运行即可。 需要明确的是，这并不是要在大规模上替代 Flink。如果你需要数百个连接器或在分布式集群中处理数百万事件的吞吐量，Flink 是合适的工具。EventFlux 更适合那些 SQL 优先开发和最小基础设施更为重要的简单部署场景。 GitHub: [https://github.com/eventflux-io/engine](https://github.com/eventflux-io/engine) 文档: [https://eventflux.io](https://eventflux.io) 欢迎反馈！

在不同类型的项目中——基础设施、数字系统、组织变革——我注意到一个反复出现的模式：当执行开始时，结果往往已经受到限制。<p>这并不是因为无能或恶意，而是因为早期的决策往往比理解更快地固化。<p>以下是一些似乎反复出现的观察：<p>早期的时间表成为社会事实 初始时间表通常是在有限信息的基础上制定的，但一旦向上层共享，它们很快就不再是临时的。它们成为资金、声誉和信心的锚点。后来的证据被迫适应这个日期，而不是日期根据证据进行调整。<p>风险被记录而非管理 风险登记表通常详尽且诚恳，但记录风险的行为可能代替了实际改变决策。应对某些风险需要重新审视范围、顺序或假设——这通常被视为不稳定而非负责任。<p>治理过滤现实 报告结构往往优化为提供安慰。坏消息被延迟或软化，并不是出于恶意，而是因为在没有解决方案的情况下，这样做感觉不具建设性。当问题清晰浮现时，剩下的选择通常是昂贵的或二元的。<p>复杂性被推迟，而非减少 早期的批准往往奖励简单性。为了推动进展，接口、依赖关系和操作约束被最小化。复杂性并没有消失——它只是稍后出现，当灵活性最低时。<p>让我感到震惊的是，许多项目并不是“出错”，而是逻辑上从它们所建立的假设中推进——而这些假设往往从一开始就是错误的。