cloud107202

> 只想投个几千, 不用赚多少 别陪太多就行

所有人一开始都这么想，可人性是最难控制的。你扔 1000 ，幸运拿到 20cm 盈利 200 ，这时候会不会想，要是我投入的是 10000 或是 10w 呢，悲剧都是这样开始的

没提前埋伏到就算了，巨亏都发生在牛市，好好感悟这句话

哪个好用不清楚，能给你排除一个 gluster-fs ，它的 csi-driver 只能搜出两个，活跃的十分不成熟，另一个很早被弃坑

debian 好点

ubuntu 里面有个 snap 组件，在个别机器会触发持续的高 CPU 占用，只有完全卸载才能解决

极大概率是 DNS 解析导致的(遇到过走 ipv6 解析，5s timeout 后回落到 ipv4)。从请求发送端看看，尤其是用了 alpine 镜像的服务容器

针对你的困扰出发，核心就是这也许是你头一次针对 websocket 场景编程。这里跟 HTTP 的语义封装没关系，尤其是没有请求-响应的通讯模式，没有路由的概念。先定义消息类型（完全由你自行定义），把消息发跟收分开处理就好，各自独立

第二种是直接用 pb 的高阶用法，oneof 字段。参考这里 https://zhuanlan.zhihu.com/p/453913153 例子，可以避开对 bytes 的 raw byte manipulation. 有兴趣研读 pb 文档的话，我推荐第二种

抛弃路由的概念，用 pb 定义消息结构就好。举个例子

message FetchChatHistoryRequest(id, count, start, end, e.g.)
message FetchChatHistoryResponse(repeat string xxx)
message SendChatMsg(string target, string content)

在实现里收到消息，解析类型，派发给对应 Type 的逻辑做业务逻辑处理，他们的逻辑当是独立离散的。
理解这一层之后，收发两端都有个需要，就是识别一个 raw bytes 比如 Java 语言会接收到 byte[] 作为消息包，要知道它具体是什么。 这里有两种思路： 第一是像二楼这样，外层用 TCP 的 TV 或 TLV 来包装一下，就是 type-length-value 这种。前两个字段一定要定长，比如 type 是 4byte 的数字类型，自己给上述消息定义好类型 id 。lenght 是 8byte 的长整形，数值是后面 value 部分的长度。value 里就是 pb 消息，encoded pb bytes 。 自己写个简单的 encoding / decoding 逻辑

snap 这东西就很离谱，我们生产环境有一太负载飙到 40-60 毫无线索，top/ps 也看不出来。把 snap 强制删除就好了