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

@Nazz 年纪大了马上要整不动了😂

@Nazz
对于异步写的问题，其实 gws 只对标 gorilla/websocket 的话就可以不考虑它，因为只是提供 ws 的基础库，gorilla/websocket 和 net.TCPConn 也同样需要用户自己去封装读写。
但是用户使用涉及广播时，应该建议用户自己注意写阻塞可能导致的问题。
而且读写个一个协程虽然并不复杂，但细节也并不那么简单，一致性、时序性、timeout 等细节，都需要仔细处理。而且我个人就遇到过 5+以上的朋友来让我帮忙 review 他们 ws 的代码，其中有些代码的封装，其实他们是知道写阻塞可能导致的问题的，所以他们封装了单独协程+chan 写的代码，但一些细节上仍然存在问题比如导致 panic 、状态不一致、timer 泄露甚至协程泄露等。

@Nazz

> 断开连接是自动的
> 以我多年 crud 的经验来看，似乎很少有人关心 write 是否返回了错误. 一般来说，在 write 之前业务逻辑都处理好了，或者开启了协程去处理错误，有错误关闭连接退出就好

不是能不能断开的问题，而是 WriteMessage 后及时性的问题。按 go 的习俗，应该是 if err != nil 就处理了，但是 WriteMessage 不返回 err ，如果这后面还有其他逻辑，就造成了后面逻辑代码的浪费，虽然整体可能不影响，但你提供 err 返回毕竟也没什么复杂度。标准库也好、其他 repo 也好大家都是这样，你这里的设计会显得不符合习惯。
而且其实这样做，相当于是基于标准库的同步 io 、能够顺序代码的情况下，糅杂进来了异步框架的回调机制。nbio 的 OnError 这些也是回调，但那是因为 io 和逻辑协程是在不同协程，为了避免用户再占用一个协程来处理，只能回调，并且 nbio 的 WriteMessage 这些也是提供 err 返回的，所以也还算符合 go 的习惯

> 使用 channel 异步写会增加一倍的常驻协程，我更倾向于广播的时候开启一小批临时协程
> async write 这块我还有个 idea ，可以维护一个全局的 WriteMessageQueue

这两种实际使用的前提都是：业务无所谓，卡了就卡了吧

但对于工程严谨性和高实时要求的业务而言，都无法允许你说的这两种策略，因为都解决不了我说的问题，只要你是在单个循环中处理多个 conn ，就都可能存在一些健康 conn 被某些网络不佳的 conn 造成卡顿的问题。
举个例子，RPG 游戏，地图上广播的消息非常多，如果某个玩家的连接卡了，其他人都跟着卡，这是不可接受的，否则游戏服务提供者上线用不了多久就可以解散项目了，除非项目本来也没人、本来挣不到钱。
其他的游戏类型，比如 FPS 、Moba 类、其他 PVP 的动作类，都是同样的无法忍受这种一人卡多人的问题的。
复杂的 APP 业务同样会存在类似的消息推送及时性需要。
既然是做通用框架，就不要投机取巧了。协程多了硬件不够用，你还可以加机器解决，但是业务卡了公司都可能直接倒闭的，这是不行的。技术方案该硬刚的地方需要硬刚，该加机器的时候就要加机器。

> 我就和基于 std net 的库比一比

nbio 是支持直接使用标注库 std net 、不使用 nbio 自己的 poller io 的，这里例子代码就是基于标准库的，另外也有描述多种 io 模式的特点、可以根据自家业务特性来 cover 不同场景：
https://github.com/lesismal/nbio/releases/tag/v1.3.5

@Nazz 这样似乎有个问题，就是执行 WriteMessage 的地方没有收到 err 、出错了不好处理后续流程、比如应该踢掉连接，OnError 里收到 err 却不知道 WriteMessage 的上下文

@liuxu
以前基于 fasthttp 的有个 github.com/dgrr/fastws ，好像有点拉跨。这个基于 gorilla 的改天我也看看

> gws 在 write 时非常直接，一个锁就发数据了，其他 2 个框架 write 前或多或少的用管道或锁处理了下别的状态情况，然后才一个锁发数据

不管是锁还是 chan ，只要不是发送队列而是直接 conn write ，就都需要注意广播业务存在 #14 的问题

@Nazz #11 很正常，for loop 处理单个慢、其他要等，我在其他帖子里说的跨协程的各种逃逸成本、亲和性差之类的，异步部分只有在连接数达到阈值才有优势，所以我自己的库以前只支持异步的时候性能就是干不过基于标准库的，无奈加上了多种 io 模式支持后、阻塞 io 的 conn 就能干过了。
基于 fasthttp 的 fastws 那个实现好像是个前几年的在校生搞的，性能和资源占用好像更拉跨，也可以对比下看看

@Trim21
我总结了下，使用 gobwas/ws 的项目大概需要几个“靠”：
1. 一靠运气好（公网速度稳定）
2. 二靠没人搞
3. 三靠业务小

手动狗头:dog: