@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:

@mepwang 不同领域的分布式系统差别太大了，比如 web 、游戏、分布式数据库或者计算引擎。每种领域又有很多具体的子场景，业务耦合的方式不同，架构设计的方式也都不同，甚至天差地别。通常在 web 领域流行的分布式理论，拿到 MMORPG 里就完全不能用

近十年的互联网发展速度太快了，最基本的一个需求，比如推送，很多应用可能都需要，但是传统的 RPC，server 端是不支持广播的，所以要使用 http static，http api，websocket，服务集群内部还要 RPC，而除了 http static，其他的场景 ARPC 都可以支撑，能很大程度简化技术栈，并且性能更高

@mepwang

5. 更灵活的同步异步
支持单个 Method/Router Handler 级别设置同步或者异步处理，也支持 Handler 内由业务层自主控制同步或异步回包、从而针对性定制快 /慢接口的协程数量控制与线头阻塞问题处理。

—— 主贴介绍的这部分有讲，每个 handler 都支持灵活的同步异步策略，用户可以自己设定请求来了是 one by one 的方式处理还是每个请求开一个新协程，甚至单个请求的处理函数里业务层自己根据实际情况选择同步还是新开协程或者协程池处理。至少 ARPC 框架层不存在这些坑点。除了 erlang golang 的其他语言可选的方式不多，要么像 node 这种也是语言层面提供异步以及各种语法糖，要么像 c++这种自己定制线程 /任务池、连接池各种基础轮子

另外 “多个客户端的并发请求是否会被阻塞” 不只是服务端框架的问题。请求处理对应的业务逻辑比如数据层、其他调用链等耗时操作也可能导致响应慢，还有比如业务层没有做限流导致的请求量爆炸，甚至部署的网络链路不稳定导致 transport 层拥塞，这些非框架原因导致的超载是框架自己不可控的、需要留给业务层处理。当然，有的微服务框架做得大而全，框架本身包含了限流熔断负载均衡等全家桶组件，ARPC 的定位则是网络和协议交互这一层的小而美，毕竟大而全太耗精力而且并不是所有项目都需要大而全，绝大多数团队的业务场景直接拿别人大而全的框架反倒成本太高、不太合适

@wellsc 另外，还没有深入研究 rsocket，不知道是否方便支持服务端广播之类的

@no1xsyzy "主要是 RPC 的含义就是 Remote Procedure Call"
—— 这个定义没错，但正式因为这个定义，限制了很多场景的网络交互方式，比如 web 技术栈，在不同的年代以不同的方式去支持连接复用（比如 http 1.x keepalive, 2.0 以后的长连接）、非 RPC 方式的协议（比如 socketio 、websocket ），ARPC 就是为了简化这种交互模式来反推 RPC 场景，希望能够简化依赖、一个库能支持多数业务、而不是我用了 http 满足不了需求还得使用 grpc 然后还需要再使用个自定义长连接协议或者 websocket 等，这就是为什么我说传统主流 RPC 不爽的原因

"无需应答是否要求保证送达？要保证送达需要回执，这个从 TCP 层面做还是从你应用层做多大额外开销的，把应答丢弃就行了"
"不要求送达，那 TCP 相比 UDP 的开销比你应用层更明显，游戏恐怕不太可能用你这个方法。"
—— 先说"送达"吧，这个是误解，ARPC 没说不要求送达，transport 层使用长连接或者可靠连接作为载体的应用层业务，transport 层本身来负责正常情况时连接能够保持情况下的送达，但是任何 transport 层也都无法保证自己这一层的 100%送达，比如链路中断、设备掉电、切换网络。应用层更没法保证送达，基于正常情况下的业务逻辑交互作业、加上完善的状态管理、错误处理之类的就可以了
—— 再说 "不要求送达"，这个是兄弟的误解，"不需要应答" != "不要求送达"，所以基于"不要求送达"推断"游戏能不太可能用 ARPC"也是不必要的。而且，ARPC 本身就是基于游戏和其他一些有状态服务的框架、为了反推那些被 RPC 限制了的场景技术栈和资源优化而实现的

另外，ARPC 让人感觉这个是 ARP 的 Client 。
—— 名字这个没办法，众口难调，每个人都会有不同的看法。我定义成 ARPC 大概有两层意思：一是希望像 "老 A"一样，努力做成同类基础设施中最好的；二是 "Async RPC" 的缩写，因为可以自由选择同步还是异步回包、回包方式不受传统 RPC 那种处理函数结束就意味着调用结束的限制

@so1n “不等函数调用结束就返回” —— 这个可能是兄弟误解了，ARPC 说的不是不等结束就返回，而是可以收到请求后自由选择什么时候回复，可以在处理函数中回包也可以在处理函数之外异步回包之类的，不像其他 RPC 那样函数调用结束了就返回了。