@guonaihong 好像很久没出现了，是在忙着搬砖嘛 :joy:

nbio 的 websocket 解析器，是支持异步流数据解析的、同步 io 的数据丢进去也一样解析，所以本身是有点吃亏的、逻辑比同步解析复杂得多，而且涉及半包 cache 之类的，否则只是同步解析，还能实现得更快。同步和异步 io 都能处理，所以结合自身的 IOModMixed ，能把性能和硬件消耗做到最佳，不同在线量全 cover ，其他框架高在线量太吃硬件资源了

@Nazz #9 gws 不是一骑绝尘的。。。你看我 #19 ，你把 tinyws 和 nbio 的 IOModBlocking 和 IOModMixed 也跑来对比下试试。。

@dw2693734d
哈哈哈，没参与日常维护，就之前偶尔读了下 melody 源码，发现那有个并发的问题会低概率导致 panic ，肉眼看出来，写测试一模拟果然就复现了，然后 pr 了下，那时候正好是疫情严重时期，作者消失很久了，我都担心他会不会感染了严重了之类的，还好后来他又出现了，并且 merge 了我的 pr

一些知名库的作者对并发这块的实现其实也不够好，一是被 go 官方和很多人鼓吹要用 chan 、少用锁，二是 go 这种多并发流确实复杂、肉眼难看出问题、测试压测也很难测出问题、甚至没办法模拟复现只能靠肉眼和想象力。。。

最近一个比较火的 conc 库也扫了几眼，接口设计非常优雅美丽，但是代码的实现也是受到太多尽量用 chan 少用锁这种观点的影响，所以它的实现是性能差一些的，不过这点性能损失对通常的项目也没什么影响、也还好

@Nazz
我这简单测了多个，tinyws ，nbio ，gws ，都高于 gorilla 的，三者数据差不多，连接数不是特别大的时候，我环境下 tinyws 略快一点点，nbio 、gws 差不多，nbio 的内存占用最少，连接数越大，nbio 会越均衡。没有做大量测试，比如不同 body size ，综合情况没做统计：
https://github.com/lesismal/nbio-examples/tree/master/websocket_1m

@Trim21
不知道他有没有把 gobwas/ws 用于他们大业务量的项目。
但 gobwas/ws 的实际问题是存在的，所以跟它用到哪里了不是直接关系，有问题就是有问题，只是可能问题影响范围他们可以接受，但并不代表别人的业务也能接受，尤其是被别人盯上随便来攻击一下的时候，影响要更大得多。
而且你看他的 issue 列表里也确实是别人提出了生产环境遇到了问题，我在那里讨论，他都是想着 timeout 之类的方式去解决，但那并不能解决问题。所以我才说它需要“三靠”才能稳定。。。但总不能大家项目都“三靠”保平安吧。。。

@0o0O0o0O0o
哈哈哈，感谢关注支持！
刚看到 melody 里有人提到因为 gorilla 不维护了、要不要切换到基于 nbio 或者其他基于框架，我也去凑热闹回复了下
https://github.com/olahol/melody/issues/73

nbio websocket 直接基于标准库 http 的例子以及多种 io 模式的说明：
https://github.com/lesismal/nbio/releases/tag/v1.3.5

旧帖发了那么久，一条回复都没有：
https://www.v2ex.com/t/892703

1. gorilla 虽然不维护了，但是生产被用了那么多，已经足够稳定，可以继续使用，从另一个角度讲，人家足够稳定没有必要继续维护了，凭什么就不能用了
2. 基于 gorilla 的 melody 接口设计比较不错，推荐
3. gorilla 虽然不错，但性能一般，而且需要类似 melody 那种做些额外的封装，比如广播场景需要单独的写协程、否则遇到单个 conn 阻塞可能导致其他 conn 被卡
4. fasthttp/websocket 在 gorilla 基础上改造，性能也一般


推荐下我自己的吧：
https://github.com/lesismal/nbio

1. 可以直接基于标准库 http 的框架之上使用、性能好于 gorilla ；
2. 可以使用 nbio 自带的 poller 作为网络异步 io ，能够支持海量并发比如百万连接，而其他基于标准库阻塞 io 接口的框架连接数太多时协程数量太大，内存容易 oom ，gc 容易卡顿；
3. 支持多种 io 模式，IOModMixed 模式下能够同步阻塞 io 与异步非阻塞 io 共用，新连接到来时根据当前在线量是否在设置的阈值以内，低于阈值使用标准库的同步阻塞 io 接口获得更高性能，高于阈值使用 nbio 的异步非阻塞 io 、协程数量最高占用配置的数量、动态退出，协程数量、内存各项占用均衡稳定
4. 不需要额外封装读写协程，只需要设置好 OnOpen/OnClose/OnMessage/KeepaliveTime 等用户需要的参数，用户专心处理业务逻辑

@0o0O0o0O0o @learningman 欢迎也来瞧瞧。gws 比较新、我也有提 issue 可以看下

企业招新人给的新人价格，老员工带一下都不会，可能是需要反思一下自己的管理能力了。

如果现在的“领导”带团队不行，那公司可能要考虑高价招经验丰富的人进来了
如果用高价招到靠谱的人进来，那不一定谁带团队了

三分天注定，七分靠打拼。
我觉得:
1. 认知应该属于打拼的部分
2. 七分天注定

我裤子都脱了，你就给我看这个...

1. Body size：json 字节数包含引号逗号方括号花括号、key 这些，字节数远大于 pb ，所以流量更浪费、对应的网络时间消耗也大一些
2. Codec：即使高性能的实现，通常后端相同语言 codec 性能也比 pb 差
json 胜在自释，更灵活；但是其他 rpc 也可以使用 pb ，比如 http+pb+rpc
3. Transport：grpc 绑定了 HTTP2.0 ； json rpc 可以用 tcp 或者其他可靠的协议，如果内网无所谓安全可以使用 4 层的 tcp ，json rpc 在 transport 这层上的消耗比 grpc 节省很多，性能可能更快
4. 工程性：强类型结构化，工程更规范。pb 默认这样子了，json 也可以工程规范约束使用强类型结构化，也可以规范

单说 grpc 的话，我觉得谷歌挺坑的。HTTP2.0 没有解决 4 层 TCP 的线头阻塞问题，对于 rpc 场景，多数是内网，直接 tcp 性能和消耗更友好。rpc 的交互模式就是残疾，对于更广阔的领域的交互需求支撑比较麻烦。

我的 arpc 除了多语言支持不够（只支持 golang 和前端 js ），其他各方面都比 grpc 强太多了：
1. transport 可定制，能使用 tcp/tls/kcp/utp/quic/websocket...各种实现了 net.Listener/net.Conn 的协议
2. codec 可定制，能使用 json/pb/msgpack...各种，你想用啥旧用啥
3. 交互方式多种多样，支持的业务场景丰富，除了支持传统 rpc 的 Client Call ，也支持 Client Notify/Server Call/Server Notify ，而且支持 CallAsync ，在这些丰富的交互模式下，可以做推送、IM 、游戏...各种业务
4. 支持中间件，比如你用 gin ，很多中间件，arpc 也可以各种定制
5. 其他扩展，比如你想单机百万连接，可以再基于 nbio 做网络层
6. 性能：请搜索参考鸟窝老师这个文章，三方压测比较客观：”2022 Go 生态圈 rpc 框架 Benchmark“。性能甩 grpc 简直不是一条街的，完全不屑于跟 grpc 比性能...
7. 易用性：3 中列举了支持各种交互模式和业务，使用上也非常简单，就像 golang 标准库 http handler 一样 easy ，不需要像 grpc 那样生成僵硬呆板的代码
8. 异步的粒度：arpc 支持最灵活的异步，请参考这里： https://github.com/lesismal/arpc/issues/41
...

真的有点不屑于跟其他 rpc 对比了。。。

恭喜这个 **B**

旧闻：“逃犯为何偏偏在张学友演唱会上被抓？人脸识别在中国大爆发”

学友演唱会上的人脸识别违法不？

我没读过太多别人源码，更多时候我是自己写

既然多数说的是 CURD 岗，OP 这个题目，换成“揪着算法”也适用

我和一个好哥们以前面试别人，如果公司给对应的岗位的薪资上限是 N ，但是候选人期望薪资小于 N 、比如只有 0.8N ，那遇到基础好的，我俩通常都给 N ，并且会告诉候选人如果 HR 咬人、该怎么跟 SB HR battle
所以希望 OP 不要记恨所有问得深一点的面试官，只要记恨那些故意恶心人甚至它自己都搞不懂问题的王八蛋面试官就好了

好奇问一下，躺平如何保健

免费的律师，咱可是不太敢用的呀

> “后端重业务，前端重技术”

既然楼主这样认为，那么后端留给其他人确实更好些。