V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  lesismal  ›  全部回复第 58 页 / 共 58 页
回复总数  1145
1 ... 49  50  51  52  53  54  55  56  57  58  
2020-12-12 09:03:44 +08:00
回复了 lesismal 创建的主题 Go 编程语言 RPC 的变革 —— ARPC 项目自荐
@mepwang

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

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

另外 “多个客户端的并发请求是否会被阻塞” 不只是服务端框架的问题。请求处理对应的业务逻辑比如数据层、其他调用链等耗时操作也可能导致响应慢,还有比如业务层没有做限流导致的请求量爆炸,甚至部署的网络链路不稳定导致 transport 层拥塞,这些非框架原因导致的超载是框架自己不可控的、需要留给业务层处理。当然,有的微服务框架做得大而全,框架本身包含了限流熔断负载均衡等全家桶组件,ARPC 的定位则是网络和协议交互这一层的小而美,毕竟大而全太耗精力而且并不是所有项目都需要大而全,绝大多数团队的业务场景直接拿别人大而全的框架反倒成本太高、不太合适
2020-12-12 07:33:08 +08:00
回复了 lesismal 创建的主题 Go 编程语言 RPC 的变革 —— ARPC 项目自荐
@wellsc 另外,还没有深入研究 rsocket,不知道是否方便支持服务端广播之类的
2020-12-12 07:25:47 +08:00
回复了 lesismal 创建的主题 Go 编程语言 RPC 的变革 —— ARPC 项目自荐
@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 那种处理函数结束就意味着调用结束的限制
2020-12-12 06:58:39 +08:00
回复了 lesismal 创建的主题 Go 编程语言 RPC 的变革 —— ARPC 项目自荐
@so1n “不等函数调用结束就返回” —— 这个可能是兄弟误解了,ARPC 说的不是不等结束就返回,而是可以收到请求后自由选择什么时候回复,可以在处理函数中回包也可以在处理函数之外异步回包之类的,不像其他 RPC 那样函数调用结束了就返回了。
2020-12-12 06:55:02 +08:00
回复了 lesismal 创建的主题 Go 编程语言 RPC 的变革 —— ARPC 项目自荐
@wellsc 看了下 rsocket-go,风格比较 java,有点臃肿了,使用起来不够方便简洁

```golang
package main

import (
"context"
"log"

"github.com/rsocket/rsocket-go"
"github.com/rsocket/rsocket-go/payload"
)

func main() {
// Connect to server
cli, err := rsocket.Connect().
SetupPayload(payload.NewString("Hello", "World")).
Transport(rsocket.TCPClient().SetHostAndPort("127.0.0.1", 7878).Build()).
Start(context.Background())
if err != nil {
panic(err)
}
defer cli.Close()
// Send request
result, err := cli.RequestResponse(payload.NewString("你好", "世界")).Block(context.Background())
if err != nil {
panic(err)
}
log.Println("response:", result)
}
```
1 ... 49  50  51  52  53  54  55  56  57  58  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   855 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 16ms · UTC 20:27 · PVG 04:27 · LAX 13:27 · JFK 16:27
Developed with CodeLauncher
♥ Do have faith in what you're doing.