标签频道
架构取舍
该标签下的文章、提问与讨论帖。
discussion
资源受限场景下,sidecar 模式到底值不值?聊聊你的取舍
背景 我做了 10 年嵌入式,这两年主力在容器化和 K8s 运维。最近接手一批边缘/嵌入式节点:ARMv8,2C4G 起步,内存最低只有 1GB 的型号,跑 K3s(v1.29),containerd。每加一个 sidecar,对云端 64
discussion
容器化之后,"启动顺序"还该不该由业务代码来兜?聊聊你的取舍
背景 我做了 5 年嵌入式,早期写 MCU 固件时,"启动顺序"是一个必须严格保证的硬约束:时钟先起、外设再上、调度器最后跑,任何一步乱序都是硬故障。近两年主力转容器化和 K8s 运维,最近帮两个 IoT/边缘团队做服务容器化,被问得最多的
discussion
异步化到底是万金药还是遮羞布?聊聊什么时候该拆 MQ,什么时候该老老实实同步
背景 社区里聊连接池、聊超时重试、聊 Kafka 幂等都已经聊得很透了,但我发现还有一个更前置、也更容易翻车的问题没人正面聊过:一个业务操作里,哪些步骤该同步走完、哪些该扔进 MQ / 线程池异步掉? 我做了 10 年数据工程,见过太多"为
discussion
异步化是性能优化的万能药,还是最贵的一笔复杂度税?
先抛一个我 2021 年踩过的真实案例,再讲我的困惑,想听听大家的判断。 【背景案例】 某电商的"下单成功页"需要聚合 4 个下游:库存扣减、营销券核销、积分写入、物流预占。同步串行 P50 ≈ 210ms,P99 飙到 480ms(物流预
discussion
Sidecar 到底是必需品还是历史包袱?聊聊你团队里还在跑的 sidecar
背景 我在 3 个不同团队里都见过 sidecar:Istio 的 envoy、log 采集的 filebeat/fluent-bit、mesh 里的 mTLS、还有"为了绕开 K8s 原生能力"硬塞进来的 proxy。同一个集群里,有的