标签频道
架构取舍
该标签下的文章、提问与讨论帖。
Lambda vs Kappa 架构取舍：双链路口径漂移的量化与监控 一、现象或背景 在数据工程领域，Lambda 架构（离线批 + 实时流）与 Kappa 架构（全流式）的取舍一直是争论的焦点。我们团队在去年将核心指标从 Lambda（S
【背景】 我带团队做订单/履约/营销链路时，发现一个普遍现象：团队把"写业务库 + 通知下游"默认异步化，结果为了把异步链路跑通，不得不在下游加大量补偿、幂等、重试机制，最后反而让系统复杂度飙升。 我观察到，很多团队在遇到接口变慢、QPS
【背景】 做了 10 年性能优化，我发现一个非常普遍的模式：团队遇到接口变慢、QPS 扛不住、某个下游偶尔超时，第一反应往往是「加个队列吧」「改成异步吧」「把同步调用改成消息驱动吧」。「异步化」在很多团队里已经成了性能优化里的万金油，好像不
【背景】 带 3 年团队，最近两次技术评审都卡在同一个问题：一个「下单成功后发积分/写审计日志/通知下游」的旁路操作，研发想直接发 Kafka，理由是"标准做法、以后好扩展"；我倾向先做本地重试表（outbox 思路的简化版：业务库事务内写
【背景】 做了 10 年数据工程，这几年我遇到的最大架构争论不是「用哪个引擎」，而是「要不要把离线批链路拆掉、全走实时」。我们团队去年把核心指标从 Lambda（Spark 离线 T+1 + Flink 实时）往 Kappa（Flink 全
先声明我的底色：8 年数据工程，日常和高并发、时延、吞吐打交道，所以我对"把慢依赖异步掉"这件事，既用过、也被坑过。今天想抛一个我观察下来争议最大、却很少有人把判断标准说清楚的争点：一个同步链路里出现"慢依赖"（DB 慢查询、RPC 抖动、
【背景】 我维护一个自建 K8s 1.28 集群（containerd 1.6 + Calico IPIP，3 控制面 + 12 工作节点，64C/256G），上面跑约 40 个 Go 无状态服务。最近半年被问得最多的一句话是："我们新项目
背景：最近复盘几条链路，发现同一团队里对「要不要异步」几乎没有统一判断标准。有人把每个下游调用都塞进线程池 + 队列，理由是「别阻塞主线程」；有人坚持一个请求里能同步调用就同步调用，理由是「异步把故障藏起来了，排障时根本看不全链路」。两边都
背景 我做了 10 年嵌入式，这两年主力在容器化和 K8s 运维。最近接手一批边缘/嵌入式节点：ARMv8，2C4G 起步，内存最低只有 1GB 的型号，跑 K3s（v1.29），containerd。每加一个 sidecar，对云端 64
背景 我做了 5 年嵌入式，早期写 MCU 固件时，"启动顺序"是一个必须严格保证的硬约束：时钟先起、外设再上、调度器最后跑，任何一步乱序都是硬故障。近两年主力转容器化和 K8s 运维，最近帮两个 IoT/边缘团队做服务容器化，被问得最多的
背景 社区里聊连接池、聊超时重试、聊 Kafka 幂等都已经聊得很透了，但我发现还有一个更前置、也更容易翻车的问题没人正面聊过：一个业务操作里，哪些步骤该同步走完、哪些该扔进 MQ / 线程池异步掉？ 我做了 10 年数据工程，见过太多"为
先抛一个我 2021 年踩过的真实案例，再讲我的困惑，想听听大家的判断。 【背景案例】 某电商的"下单成功页"需要聚合 4 个下游：库存扣减、营销券核销、积分写入、物流预占。同步串行 P50 ≈ 210ms，P99 飙到 480ms（物流预
背景 我在 3 个不同团队里都见过 sidecar：Istio 的 envoy、log 采集的 filebeat/fluent-bit、mesh 里的 mTLS、还有"为了绕开 K8s 原生能力"硬塞进来的 proxy。同一个集群里，有的
文
标题
摘要