@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 不要记恨所有问得深一点的面试官，只要记恨那些故意恶心人甚至它自己都搞不懂问题的王八蛋面试官就好了

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

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

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

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

@dcsuibian 多年前的第一批，2023 报导而已

可以搜下几位专家的一些帖子看看，结合自己的数据类型定制+测试优化下就差不多了：
真实环境下大内存 Go 服务性能优化一例
曹大带我学 Go （ 11 ）—— 从 map 的 extra 字段谈起

如果是通用缓存基础设施，用已有的那几个就可以了。但通用缓存都是走了一道序列化的，如果追求性能，表现会差一些。
如果不是通用缓存则不需要序列化，性能可以最大化，但要根据具体业务结合 kv 类型定制去指针化了。

前端请求 api/rpc ，后端之间 rpc 都一套就能搞定搞定，自带了简单的 pub/sub 扩展，也方便

只做 api 的话，可以试试我这个，可以用 websocket ，也可以用 http：
https://github.com/lesismal/arpc/tree/master/examples/webchat