@helone #32 字节的 http 和 rpc 的 benchmark 数据是自称的，第三方测评跟他们官方的数据不太一致，最好是把测试条件对齐、自己跑下实际代码看看真实数据。另外，他们这些基于自家 netpoll 的库，在一些场景消耗不太正常，甚至用空间换时间、内存消耗比其他框架高的多、稳定性也存疑（我压测的时候就遇到过多次卡死、但其他框架都没事），如果生产上允许比较高的 cpu 那可能影响业务稳定性，如果只允许有限的连接数，那每个节点又没法省更多（跟其他 go 框架相比）

@james122333 arpc 的例子，可能比标准库 rpc 用起来还要简单些吧，像 net/http 一样简单：
https://github.com/lesismal/arpc?tab=readme-ov-file#quick-start

@james122333 标准库 rpc 算是中规中举，各方面一般。也可以看下 #109 我贴的连接，测评是鸟窝老师做的，最快的那个应该算是我的 arpc ，更快，使用简单，而且功能丰富得很，可以支持的业务场景也更多，包括推送、游戏、IM ，普通 rpc 是很难做这些场景的，欢迎体验

这不是你的错, 继续找工作就是了, 心情不好的时候可以去锻炼, 锻炼能提升心态, 心态好了, 找工作也会更顺利

祝好!

@fox0001 grpc 有啥可震惊的... 主要就是靠着谷歌爹的光环, 另外就是郭德纲那句: 同行(thrift 那些垃圾)衬托

grpc 除了跨语言优势, 性能不值一提:
https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks/

> “庄家都是用的新系统，比散户的速度快，优先级高”。

@cskeleton 庄家可比这优势大多了. 比如吧, 庄家们知道各种数据, 资金流向, 重要点位资金支撑或者阻力, 庄家操盘的时候上下扫很多也都是根据这些吃来吃去, 散户相当于明牌

系统卡单不只是股票, 12306 谁能抢到票, 双十一谁能抢到最有价格, 都涉及公平, 但几乎没有告的先例, 法律上就没法支撑, 否则就没人做技术了, 因为风险太大, 系统一撑不住就要吃官司被告到破产

> 说了这么多，我只能说 go 其实更适合个人开发者和成本敏感型得小团队，因为一般这样团队，都自己写程序，最大得成本就是云服务得开支了，最后再说一句云服务器得内存,cpu,宽带真得很贵，动不动类似 spring 全家桶那样得架构真得狠费机器。

OP 格局低了, 越大团队越大业务, 省的越多. OP 个人只省了这点成本就很可以了, 对于大业务量, 那节约的成本可是大太多了

顺便安利下我这个是给大业务节约成本的仓库, 量小的标准库更适合:
https://github.com/lesismal/nbio

@cskeleton
看下#27 这句:
"
灰度可以从很小的用户数量开始, 可没说你得一半新一半旧;
可以是内部或者相关机构开放一部分账户进行测试, 可没说必须都让普通用户先上去直接当炮灰
"

再看下#28, 节前那么多被卡单的, 为啥不去告上交所.

如果想改变, 那只能学社交了, 但性格本身不适合, 难度会比较大, 不如技术专家路线那么心里干净

另外, 建议不要随便就拿自己跟马斯克乔布斯他们比, 别以为他们脾气差自己也可以, 级别相差太大, 没可比性的, 而且他们可都是全球第一产品经理级别的人

> 到时候如果同样订单一个系统能成交，另一个不能，或者一个价格好一个价格坏怕不是要吃官司

@03 而且, 如果照这么说, 价格高低好歹能成交, 节前那次被卡单的连成交都成交不了让人家上不了车, 早都该去告上交所了

@03 #16 要是信心和实力足够, 直接上一套新的也行.


按照其他层说的, 如果是采购的别人现成的不好改造, 那灰度确实很难搞. 如果可以改造, 那么:

> 到时候如果同样订单一个系统能成交，另一个不能，或者一个价格好一个价格坏怕不是要吃官司

灰度可以从很小的用户数量开始, 可没说你得一半新一半旧;
可以是内部或者相关机构开放一部分账户进行测试, 可没说必须都让普通用户先上去直接当炮灰


> 部分？灰度？交易所可不像互联网一部分用户打不开或者卡了也没什么。

所有用户全用不了的影响大, 还是少量人不能用影响大?

别瞧不起互联网, 支付宝微信这些 FIN Tech, 哪个不是涉及钱的

撮合系统的算法服务部分应该是没太大压力, 因为本来就可以按照股票 id 分散到不同的撮合节点, 卡住主要是订单和结算这些数据事务性相关的, 解决这部分性能, 撮合系统把交易来源和结算的部分按照用户分流到新旧不同的系统就可以了, 但业务上肯定影响挺大的, 改造肯定是要喝一壶的

平滑过度的话, 单独开发一套新系统, 一部分用户数据复制/迁移过去, 代理层分流这部分用户流量给新系统, 灰度一段时间如果功能都稳定就可以考虑继续迁移直到全切过去.
至于性能, 新系统的话, 随便哪个大厂的一流团队支援下, 就像当年阿里支援 12306 一样, 性能都能搞定的.

我的一些协程池为了减少常驻协程数量, 也是类似的, 但不用 chan 了, 只是 queue head go func 里批量处理所有然后退出, 不是 head 就 push

chan 在性能场景确实挺贵的

我挺喜欢这个声音的, 助眠的下雨背景音乐听腻了, 我就偶尔把炒豆子声用来助眠, 感觉特别有 hacker 氛围...

> 两个 hash 用作 key 是图什么, 避免大 key 的浪费, 或者用固定的[N]byte 避免指针类型的 gc item 数量?

关键是, 这样就不好去做非精确 key 相关的了, 比如遍历 list 之类的

Ristretto 这个 select/default 有点难崩, 还不如去掉 chan 异步直接执行, 嫌弃锁范围大同步竞争浪费必须并发的话可以考虑另一种方式: 用 chan 做 trigger, 只有 queue head 时才 trigger 写协程并且 trigger 单次处理完当前所有, pop push 各自粒度的锁
两个 hash 用作 key 是图什么, 避免大 key 的浪费, 或者用固定的[N]byte 避免指针类型的 gc item 数量?

送楼主两个成语/俗语和它们对应的场景:
1. 救人于水火 -> 雪中送炭
2. 无事献殷勤 -> 非奸即盗

别人没需要你帮约等于"2", 这个"2"是双关的"2"
劝楼主平常心, 别拿自己太当回事.
没有贬损 OP 的意思, 反而是我自己的反思总结, 别让自己那么累. 共勉.