cloud107202

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 强制删除就好了

@YIsion 这款小问题蛮多的，我的离开两米远就频繁断联，玩魂系/格斗游戏时候时不时很致命，基本处于不可用状态。不如它家低价的款稳定

人民币计价应该是 3 6

前 kotlin 重度用户。近两年综合 Java 目前的发展趋势与方向，我是认为在 Android 开发之外的服务端编程里，完全没有需要使用 kotlin 的场景