Post #62

去年九月 meta 分享了他们用 XDP 来做服务优雅发布: https://lpc.events/event/11/contributions/950/, 我兴致勃勃想去了解 BPF_PROG_TYPE_SK_REUSEPORT 是如何解构时代难题, 看完后大失所望, 对 TCP 服务几乎没什么卵用, 和转移 listening sock + graceful term 的方案相比几乎没有什么好处却平白无故增加了复杂度, 而对真正的痛点: 新旧实例并行运行的资源占用问题, 却视而不见. 我倒是有额外几个想法: 1. 优雅热更新, 真正的热更新, pid 不变的那种, 对于古典容器是有意义的, 因为业务进程是 pid ns 的一号进程, 死了就被内核销毁全部 pid ns, 所以要原地升级. 2. server 端的 lb per call, 但 "call" 是一个业务概念, TCP 层并不能在没有额外知识的帮助下分辨什么是一个 call. http2 有 stream 的概念, 得以实现 grpc 的 lb per stream(call). 2.1. 假设有办法让 TCP 知道什么是一个 call, 那么也许可以用 bpf_msg_redirect_hash + sockmap 来实现跨进程的流量分发: 长链接 sock0 收到一个请求, 查看 sockmap, 重定向给其他 socket (可能是其他进程). 2.2. 但是和 client 端实现 lb per call 相比还是不够好, client 的实现更简单, 服务可以跨节点(sockmap 只能单节点), 所以感觉还是没什么用...