服务注册与发现:服务怎么找到彼此
微服务拆开后,服务之间怎么找到彼此?配置文件写死 IP 追不上动态扩缩容。注册中心维护服务名到实例列表的映射,靠心跳检测存活。客户端发现 vs 服务端发现、CP vs AP 的取舍,以及选错了会怎样。
微服务拆开后,服务之间怎么找到彼此?配置文件写死 IP 追不上动态扩缩容。注册中心维护服务名到实例列表的映射,靠心跳检测存活。客户端发现 vs 服务端发现、CP vs AP 的取舍,以及选错了会怎样。
我换过好几个 AI 编程助手。Kimi Code 用了一阵,换 Claude Code,后来又试了 Codex。每次换的时候有个很直观的感受——之前的协作上下文全没了。 Claude 里讨论过的方案细节,Kimi 不知道。Kimi 里记着的任务进度,Claude 接不上。Agent 换一个,记忆清零
负载均衡不只是轮询分请求。节点能力不同要加权,实时负载不同要动态选,有状态要保亲和,缓存要一致性哈希,节点上下线要平滑过渡,健康检查要主动加被动,还得和熔断配合。多层配合比单层完美更靠谱。
三个架构决策,每个都在简洁和稳健之间选了简洁。Checkpoint 搭载在数据上、优化器规则注入流处理语义、插件共享宿主 runtime。如果是我会怎么选。
一个用 Rust 写的列式流处理引擎,不做分布式有状态计算,在生产环境跑通了上千条 pipeline。我为什么选它做深度研究。
级联故障的根因不是下游挂了,是上游在等待中耗尽资源。熔断在失败率升高时停止调用,降级在不可用时给兜底响应。两者配套才有意义——光熔断不降级是快死,光降级不熔断挡不住资源耗尽。
Nginx、Apache、Tomcat、Caddy、Traefik,还有框架自带的 uvicorn、Gunicorn、net/http——这些 Web 服务器各自擅长什么,什么场景选什么。
消息队列用异步解耦换来了高吞吐和高可用,代价是丢失、重复、顺序三个问题。不存在三全其美的方案,只有想清楚放弃哪个。
脑裂:集群分区后两个子集各自选出主节点,并行写入导致数据分叉。根因不是节点真挂了,而是看起来挂了——网络分区、心跳超时、VM暂停都会触发。防护靠 quorum + fencing token + 租约三层。Raft/Paxos 防选主脑裂,但 fencing 仍需存储层配合。
朴素重试(失败立刻重试)在大规模下会引发重试风暴和级联放大。正确策略四件套:指数退避(给下游恢复时间)+抖动(打破同步)+重试预算(限制总重试流量)+只重试瞬时故障且幂等的操作。再配熔断器兜底——重试失败到阈值就停止,别一直试一个挂掉的服务。重试不是"再试一次",是需要设计的工程。