Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

模块管理的问题 #50

Closed
lxzan opened this issue May 15, 2023 · 27 comments
Closed

模块管理的问题 #50

lxzan opened this issue May 15, 2023 · 27 comments

Comments

@lxzan
Copy link

lxzan commented May 15, 2023

在根目录执行go mod tidy报错, 注释掉extension/protocol/quic代码后再执行go mod tidy, 项目根目录的go.mod会增加许多依赖.
建议优化下模块管理.

@lxzan
Copy link
Author

lxzan commented May 15, 2023

可以使用go work管理多模块项目

@lesismal
Copy link
Owner

arpc核心功能是 zero dependency 的,不依赖三方,go.mod只是为了占位。
其他extesion、examples都主要是作为参考,因为关注较少、没有像nbio-examples那样单独拆成一个repo,后续可能会把extension、examples拆出去

@lesismal
Copy link
Owner

需要 extension examples 定制的,在extension examples 或者用户自己代码目录下的 go mod 就可以了,不污染 arpc 的 zero dependency

@lxzan
Copy link
Author

lxzan commented May 15, 2023

感觉这样不太好, 没指定extension的版本, 如果某个extension变更比较大, 就编译报错了

@lesismal
Copy link
Owner

这是给用户做参考实现的,并不算是arpc本身的功能

@lesismal
Copy link
Owner

extension examples这些代码,用户直接拷贝到自己代码里去随意修改就可以了

@lxzan
Copy link
Author

lxzan commented May 15, 2023

好吧

@lxzan lxzan closed this as completed May 15, 2023
@lxzan
Copy link
Author

lxzan commented May 17, 2023

看了下 extension/protocol/websocket , 感觉抽象开销太高, 直接TCP就行了, protocol下面应该放传输层协议而不是应用层协议. 一般来说, 翻墙软件才需要伪装成WebSocket

@lesismal
Copy link
Owner

扩展里只是示例,有性能需要的自己定制就行了。
而且你只考虑了rpc场景、性能敏感时的开销问题,但ws很多是针对h5,比如游戏,比如网站论坛推送之类的,简单的业务不是性能敏感的,主要是是方便易用。
其他的定制方式,比如使用ws,你可以看下nbio的定制,自己收到message去handler解析然后OnMessage就可以了:
https://github.com/lesismal/arpc/blob/master/examples/nbio/server/server.go

有特殊需要的场景,我都特殊定制的,比如对RPC有最高性能需求,那可以把arpc再裁剪一下,比如:

  1. header可以再简化
  2. 中间件那些for循环的逻辑都不需要
  3. context也不需要handler结束后还保持生命周期
  4. 去掉用户随意使用codec的便利、收到一个body就先解析出来然后再丢给逻辑协程,这样原来的buffer就更好地复用
  5. 。。。。

很多细节可以极致,现在的方案是功能丰富且便利用户,并不是性能作为第一性的。有实际业务需要的地方,我都可以做比较极致的优化

@lesismal
Copy link
Owner

你不要把extension和examples当成定势,那只是我提供的一点示例

@lxzan
Copy link
Author

lxzan commented May 17, 2023

我再看看源码吧, arpc功能比我的uRouter丰富很多, 基本抽象也有很大差异. uRouter仅支持请求-应答模式, 基本抽象是模仿http的Request和ResponseWriter, 抽象开销比较小.

@lesismal
Copy link
Owner

传统的游戏服务器,或者工业系统上下位机之类的通信协议,都是数值类型做命令号的,小系统1 byte足够,大系统2 bytes也足够,性能更友好,也不需要中间件之类的这些玩意。
只有web领域这些垃圾协议包括RPC采用字符串做router,中间件各种需求。

通信的本质是协议交互,http最早设计成request-response模式非常失误,因为设计得太垃圾,才需要websocket/socketio/webrtc这些去不停打补丁。

所以arpc这种我自己的框架,基本不是去向这些传统的垃圾协议靠拢

@lxzan
Copy link
Author

lxzan commented May 17, 2023

字符串对人友好,二进制对机器友好。现在的http的广泛使用早就超出了最初设计者的想象,根本原因还是方便,请求应答模式足以应对大多数web/app的交互,不需要开发者去操心连接生命周期管理。强调实时的场景才需要socket

@lesismal
Copy link
Owner

字符串对人友好,二进制对机器友好。现在的http的广泛使用早就超出了最初设计者的想象,根本原因还是方便,请求应答模式足以应对大多数web/app的交互,不需要开发者去操心连接生命周期管理。强调实时的场景才需要socket

这都是扯淡的说法,不要人云亦云拿别人整理好的文章思考问题。你上面这些说法是因为已经这样了才这样强行说好。
看二进制内容浏览器和ide一样都能可视化,keepalive一样是长连接复用,反倒是纯短链接几乎没人用,而且框架或者协议在七层提供的用户接口提供这些机制就可以了,谁整天去tcpdump wireshark抓包分析字节流啊?
别听那帮谬论,要懂得自己思考

@lxzan
Copy link
Author

lxzan commented May 17, 2023

经验之谈, 没看什么技术文章. 我用postman+json不写代码就能凭记忆修改路由和消息体调试接口, tcp socket + protobuf可以吗

@lxzan
Copy link
Author

lxzan commented May 17, 2023

字符串对人友好,二进制对机器友好。现在的http的广泛使用早就超出了最初设计者的想象,根本原因还是方便,请求应答模式足以应对大多数web/app的交互,不需要开发者去操心连接生命周期管理。强调实时的场景才需要socket

这都是扯淡的说法,不要人云亦云拿别人整理好的文章思考问题。你上面这些说法是因为已经这样了才这样强行说好。 看二进制内容浏览器和ide一样都能可视化,keepalive一样是长连接复用,反倒是纯短链接几乎没人用,而且框架或者协议在七层提供的用户接口提供这些机制就可以了,谁整天去tcpdump wireshark抓包分析字节流啊? 别听那帮谬论,要懂得自己思考

如果KeepAlive就能应对一切场景谁还玩心跳啊

@lesismal
Copy link
Owner

经验之谈, 没看什么技术文章. 我用postman+json不写代码就能凭记忆修改路由和消息体调试接口, tcp socket + protobuf可以吗

这个比较是不合理的,tcp pb你是自定义协议,不具备rfc或者统一标准,如果有统一标准,工具里一样可以做到方便修改。json本身是自释义的,你如果http pb一样不方便修改pb,但是工具可以去做导入pb定义然后你只改结构体之类的。

@lesismal
Copy link
Owner

如果KeepAlive就能应对一切场景谁还玩心跳啊

你搞混了http keepalive 和tcp心跳的含义和用途,这俩没有直接的可比性

@lxzan
Copy link
Author

lxzan commented May 17, 2023

经验之谈, 没看什么技术文章. 我用postman+json不写代码就能凭记忆修改路由和消息体调试接口, tcp socket + protobuf可以吗

这个比较是不合理的,tcp pb你是自定义协议,不具备rfc或者统一标准,如果有统一标准,工具里一样可以做到方便修改。json本身是自释义的,你如果http pb一样不方便修改pb,但是工具可以去做导入pb定义然后你只改结构体之类的。

多了一些步骤调试就不如json便捷了, 很多人重视简便胜过性能

@lesismal
Copy link
Owner

经验之谈, 没看什么技术文章

得出这个结论是因为你以前的主要工作是花在这些curd上了,以自己的舒适区去对比其他没有被广泛优化工具链的场景,但如果早期的http rfc就是二进制,现在的浏览器和社区工具链也一样完善。
考虑现有的东西是否够好,要加上想象,去想想如果不这样可以做哪些可以做到哪些,然后用各自的好来对比。
你再想想如果文本那么好,为什么还要搞2.0和3.0?
2.0这个垃圾就不说了,3.0很优秀

@lxzan
Copy link
Author

lxzan commented May 17, 2023

如果KeepAlive就能应对一切场景谁还玩心跳啊

你搞混了http keepalive 和tcp心跳的含义和用途,这俩没有直接的可比性

HTTP自带的KeepAlive很方便啊, 对用户无感知.

@lxzan
Copy link
Author

lxzan commented May 17, 2023

考虑现有的东西是否够好,要加上想象,去想想如果不这样可以做哪些可以做到哪些,然后用各自的好来对比。

应用层是文本还是二进制对我业务开发流程没有影响, 基本无感知, 日常工作接触最多的是IDL. 考虑到历史进程, HTTP1设计得还不错, XML做IDL是垃圾.

@lxzan
Copy link
Author

lxzan commented May 17, 2023

经验之谈, 没看什么技术文章

得出这个结论是因为你以前的主要工作是花在这些curd上了,以自己的舒适区去对比其他没有被广泛优化工具链的场景,但如果早期的http rfc就是二进制,现在的浏览器和社区工具链也一样完善。 考虑现有的东西是否够好,要加上想象,去想想如果不这样可以做哪些可以做到哪些,然后用各自的好来对比。 你再想想如果文本那么好,为什么还要搞2.0和3.0? 2.0这个垃圾就不说了,3.0很优秀

就算是同一类协议的不同版本使用场景也不一样, 搞大一统有点费力不讨好了
H3适合API Server不适合CDN

@lesismal
Copy link
Owner

不是要搞大一统,也没办法搞大一统。因为http服务不是中心化的,没法做到一家发版全球更新。
所以这个资源浪费还会存在很多年,软硬件,能源,都浪费挺多的,很不环保

@lxzan
Copy link
Author

lxzan commented May 17, 2023

很多劣质的东西照样流行 😂
例如伪JWT, Restful...
每个人的品味和分辨能力都不一样

@lesismal
Copy link
Owner

很多劣质的东西照样流行 😂
例如伪JWT, Restful...
每个人的品味和分辨能力都不一样

就是最早的时候没有,一些先驱设计出一些不完善的东西,其他人跟风,就流行了,没办法,大规模的这种就只能交给时间去慢慢替换掉。但咱们不能因为这些东西还算好用就不去追求更好了,单从优劣分析的角度该批评缺点的就批评它,不批评就没有进不了。说不定几十年后AI大一统了很快就把这些糟粕替换掉了:joy:

@lxzan
Copy link
Author

lxzan commented May 17, 2023

流量多吸引新人去尝试, 然后糟粕流行了起来

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants