@iyangyuan 我不用 java 😂，随便搜了下 Spring Cloud HTTP2 相关，https://www.jianshu.com/p/ed3f8f983764，好像 Spring Cloud 还是有很大提升空间。
并且，"能罩得住" 和 "能罩得住得更好" 也不是同一件事 😁

@IamYourDad 兄弟，我也没太看懂，能详细描述下不？比如

“样例里面 server->client 是不是多次一举啊“，这里的多此一举是不是指 ctx.Write()？比如，return xxx 然后框架层自己 Write 给 client 就行了、不需要让用户自己去 Write ？如果是这个意思，请看主贴的这个部分： "2. Server 端函数调用的写法，函数返回即是调用结束，不够灵活" 。而且，这里是可以异步回包的，方便业务层灵活定制业务模块的任务池、流控等，比如：

func onEcho(ctx *arpc.Context) {
str := ""
err := ctx.Bind(&str)
if err != nil {
log.Printf("/echo error: %v", err)
return
}

// 这里也可能不直接用 go 、而是使用其他业务模块的协程池异步回包
go func() {
// do something.
ctx.Write(str)
}()
}

另外，兄弟，建议改个 ID，你这个 ID 别人读出来或者看文字心里默读的时候其实是你自己吃亏啊。。。😅😂

@no1xsyzy 嗯嗯，文字交流、一些场景没有既定的“黑话”，大家可能会理解出一些歧义 😅

其实需要确认对方执行了的场景，使用 Call 的方式等应答结果就行了.MQTT 既然是基于 tcp，业务层再去设计重传相关的我始终感觉有点别扭😅
我个人对 tcp 的设计也不太满意，有了 BBR 之后传输效率更合理些了，但是 三次握手四次断开 依旧很浪费，2 次握手就足够了，毕竟后面每次都会带 ack ；断开也是 2 次就够了——两边各断开一次、一次断双工，因为工作十几年了，我自己业务还从没遇到过需要半双工分别断开的场景，或者说没遇到过半双工分别断开优于双工同时断开的场景，并且，由于仍然可能存在掉电、线路故障等情况导致任何数据的无法送达，所以关闭一半反倒是作茧自缚 😅。
所以，超脱到 4 层之上，再看送达相关的问题可能会简单些：非事务性的业务，送不送大无所谓；事务 /弱事务性的，业务层的自行保障措施省略不掉。所以对于网络交互层的关注，放在保障线路、设备稳定性等工程属性上就好了

游戏、VOIP 电话之类的丢帧就丢帧吧，后面的状态同步过来正确就好，这种场景我也会选择使用 udp，这些特殊场景还是得自家定制才对性能最友好，否则就 pb 咱都觉得性能不够

@xeaglex 哈哈哈，欢迎品尝 ^_^

@kevinwan 我选择把世界上最好的语言供奉起来，干业务这种还是交给 go 好些 😂

@kevinwan 赞，这个够灵活，哈哈哈 👍👍👍

@tkl 感谢支持！😊😊😊

@DoctorCat 好，闲了研究下

@kevinwan 感谢大佬支持！😊😊😊

go-zero 是比较完整的一套微服务方案，是面向业务的一套整体架构
arpc 轻量，目前只做网络交互的部分，相当于对标 gRPC 、rpcx 、标准库 rpc 之类的，是面向架构的一个基础设施

所以咱们没什么可比性，要说关系的话，就是 go-zero 可以考虑使用 arpc 😊😊😊

@teawithlife 感谢支持！😊😊😊

@DoctorCat 你们使用的哪些 tracing ？我空了学习研究下看看自己能不能加上

@DoctorCat 没有默认支持其他 tracing，有中间件机制可以进行扩展。

这里有个简单 tracing 的扩展示例：
https://github.com/lesismal/arpc/tree/master/extension/middleware/coder/tracer

这里是简单 tracing 的使用示例：
https://github.com/lesismal/arpc/tree/master/examples/middleware/coder/trace

欢迎各路道友 pr 或者自己项目扩展实现、交流 😁

@kevinwan 感谢支持！多多交流跟各位大佬学习！

欢迎各位体验、尝试 😊

@kevinwan 还是举推送的例子，gRPC 这些好像不太便利。很多接口类业务，其实如果换成有状态服务，性能和软硬件消耗都能节省不少，但是难度当然也略高些，如果是用户之间还存在复杂交互耦合的（比如游戏），则业务复杂度和编码难度更高

@lesismal @kevinwan @fox0001

网络交互是通用的基础设施，4 种基础网络交互模式也早已有之，所以我这个也不算创新 😂😂，只是希望把通用的基础设施能推向 web 等其他曾经受限的领域，让做业务更容易、并且性能更高、更节能。

@fox0001 这么说也对，因为其实我最早不是做 web 服务为主的业务的，最开始做就都是有状态的长连接服务，后面再做 web 类的，觉得 http 相关的 api 、rpc 技术栈虽然工程实践上积累了很多，但是基础设施还是太低效了。这几年又是挖矿，又是全球升温环境恶化，而且以后随着大数据、AI 、5G+这些的更加普及，计算量会越来越大，对应的能源消耗也会越来越大。以前的 http 因其文本协议的便利极大促进了互联网的发展，但也正是由于它短链接、文本格式等低效浪费问题，会造成日趋爆发的数据和计算量的巨大浪费，所以才会有 http 2.0 3.0 quic mqtt 各种升级方案。

@kevinwan 嗯嗯 star 支持了。前阵子还提了个服务注册发现确保强一致的 [issues/227]( https://github.com/tal-tech/go-zero/issues/227) ，其实加上强一致保障不复杂，etcd 的 "go.etcd.io/etcd/client/v3/concurrency" 子包自带了分布式锁的实现：

```golang
client, err := clientv3.New(clientv3.Config{
Endpoints: endpoints,
DialTimeout: 5 * time.Second,
})
if err != nil {
log.Error("NewRegister [%v, %v] clientv3.New failed: %v", key, value, err)
return nil, err
}

session, err := concurrency.NewSession(client)
if err != nil {
log.Error("NewRegister [%v, %v] concurrency.NewSession failed: %v", key, value, err)
return nil, err
}

mux := concurrency.NewMutex(session, RegisterMutexPrefix)
err = mux.Lock(context.TODO())
if err != nil {
log.Error("NewRegister [%v, %v] Lock failed: %v", key, value, err)
return nil, err
}
defer mux.Unlock(context.TODO())
```

然后先 Get 判断再 Put 就行了

@XiLingHost 这个都行，代码 package 都是 arpc，个人开发者没那么大的社区影响力，ARPC/aRPC/arpc 都随意 :joy: