交易明细从 Kafka 经托管 sink 写进三副本 ClickHouse，单日一千多万到三亿多行。现状是按结算日分区、至少一次写入、单分片三副本靠 Keeper；按键折叠、报表增量聚合加对账重算、整分区替换修数据在 lab 上验过，还没在现有集群上执行。

借 Ivan Velichko 在 iximiuz 上的系统解析，回顾软件部署从虚拟机到容器编排的演进脉络：分析 VM 时代的实例抽象、Docker 单进程容器的断层，以及 Kubernetes 怎样用三层对象重现经典服务模型。

边缘节点上跑代码有 VM 级隔离、同进程 V8 isolate、microVM 三种做法，出现时间重叠，至今并存；存储上，Cloudflare 按读写模式分出最终一致的 KV、单实例的 Durable Objects 和带区域只读副本的 D1。

Workers 把多租户代码放进同一进程的 V8 isolate，按 Cloudflare 的数字启动约 5 ms、内存约 3 MB；代价是只能跑 JavaScript 和 WebAssembly，没有真实文件系统和子进程，隔离靠进程级沙箱补足。

生产环境单节点 OpenSearch 的 Dashboards 对所有用户返回 401：按 _id 排序分页留下的 12.3 GiB fielddata 占着没有上限的缓存，几个跨月聚合又把堆推过了 parent 断路器上限。文中整理了时间线、原因和防护建议。

按峰值每秒 6 万到 7 万条、每天约 2.4 TB 主分片数据推算日志集群：Kafka 缓冲、节点角色分离、写入调优和 data stream 滚动；热数据在 14 台本地 NVMe 节点上保留 7 天，快照在 S3 保留约 30 天。

多站点电商的商品数据要同时处理站点间的本地化与合规差异、品类属性差异、跨洋读延迟和大促读压力。这套 PIM / MDM 架构用两层商品模型、类目属性规则、中心打版加事件分发到大区只读副本、版本号幂等写入与对账、多级缓存来逐个解决。

三个非生产环境 14 天共 47.5 GB 的日志里，一个接口的完整响应体估算占了约 23 GB。按文件后缀、字段抽样、mapping 开销和查询模式四步找出空间去向，并估算源头截断、zstd、去掉长文本 .keyword 和不存位置信息各能省多少。

开发环境的单节点 OpenSearch 查出六个问题：自报 98% 的内存使用率把 Page Cache 算成了已用，1 GiB 多的堆页被换出到 swap，PA 的 agent 没有运行，缺少基础设施告警，默认副本让集群一直 yellow，服务日志写了两份。

H5 应用容器和奖池活动条由 Cloudflare Workers 上的容器页、overlay 和 EKS 里四个 Spring Boot 服务组成，结构由同源入口、一张凭证两处验签、钱只走交易平台、推送层不存状态和 overlay 固定入口发版五条决策定下。