Comments (27)
不是要搞大一统,也没办法搞大一统。因为http服务不是中心化的,没法做到一家发版全球更新。
所以这个资源浪费还会存在很多年,软硬件,能源,都浪费挺多的,很不环保
from arpc.
可以使用go work
管理多模块项目
from arpc.
arpc核心功能是 zero dependency 的,不依赖三方,go.mod只是为了占位。
其他extesion、examples都主要是作为参考,因为关注较少、没有像nbio-examples那样单独拆成一个repo,后续可能会把extension、examples拆出去
from arpc.
需要 extension examples 定制的,在extension examples 或者用户自己代码目录下的 go mod 就可以了,不污染 arpc 的 zero dependency
from arpc.
感觉这样不太好, 没指定extension
的版本, 如果某个extension变更比较大, 就编译报错了
from arpc.
这是给用户做参考实现的,并不算是arpc本身的功能
from arpc.
extension examples这些代码,用户直接拷贝到自己代码里去随意修改就可以了
from arpc.
好吧
from arpc.
看了下 extension/protocol/websocket , 感觉抽象开销太高, 直接TCP就行了, protocol下面应该放传输层协议而不是应用层协议. 一般来说, 翻墙软件才需要伪装成WebSocket
from arpc.
扩展里只是示例,有性能需要的自己定制就行了。
而且你只考虑了rpc场景、性能敏感时的开销问题,但ws很多是针对h5,比如游戏,比如网站论坛推送之类的,简单的业务不是性能敏感的,主要是是方便易用。
其他的定制方式,比如使用ws,你可以看下nbio的定制,自己收到message去handler解析然后OnMessage就可以了:
https://github.com/lesismal/arpc/blob/master/examples/nbio/server/server.go
有特殊需要的场景,我都特殊定制的,比如对RPC有最高性能需求,那可以把arpc再裁剪一下,比如:
- header可以再简化
- 中间件那些for循环的逻辑都不需要
- context也不需要handler结束后还保持生命周期
- 去掉用户随意使用codec的便利、收到一个body就先解析出来然后再丢给逻辑协程,这样原来的buffer就更好地复用
- 。。。。
很多细节可以极致,现在的方案是功能丰富且便利用户,并不是性能作为第一性的。有实际业务需要的地方,我都可以做比较极致的优化
from arpc.
你不要把extension和examples当成定势,那只是我提供的一点示例
from arpc.
我再看看源码吧, arpc功能比我的uRouter丰富很多, 基本抽象也有很大差异. uRouter仅支持请求-应答模式, 基本抽象是模仿http的Request和ResponseWriter, 抽象开销比较小.
from arpc.
传统的游戏服务器,或者工业系统上下位机之类的通信协议,都是数值类型做命令号的,小系统1 byte足够,大系统2 bytes也足够,性能更友好,也不需要中间件之类的这些玩意。
只有web领域这些垃圾协议包括RPC采用字符串做router,中间件各种需求。
通信的本质是协议交互,http最早设计成request-response模式非常失误,因为设计得太垃圾,才需要websocket/socketio/webrtc这些去不停打补丁。
所以arpc这种我自己的框架,基本不是去向这些传统的垃圾协议靠拢
from arpc.
字符串对人友好,二进制对机器友好。现在的http的广泛使用早就超出了最初设计者的想象,根本原因还是方便,请求应答模式足以应对大多数web/app的交互,不需要开发者去操心连接生命周期管理。强调实时的场景才需要socket
from arpc.
字符串对人友好,二进制对机器友好。现在的http的广泛使用早就超出了最初设计者的想象,根本原因还是方便,请求应答模式足以应对大多数web/app的交互,不需要开发者去操心连接生命周期管理。强调实时的场景才需要socket
这都是扯淡的说法,不要人云亦云拿别人整理好的文章思考问题。你上面这些说法是因为已经这样了才这样强行说好。
看二进制内容浏览器和ide一样都能可视化,keepalive一样是长连接复用,反倒是纯短链接几乎没人用,而且框架或者协议在七层提供的用户接口提供这些机制就可以了,谁整天去tcpdump wireshark抓包分析字节流啊?
别听那帮谬论,要懂得自己思考
from arpc.
经验之谈, 没看什么技术文章. 我用postman+json不写代码就能凭记忆修改路由和消息体调试接口, tcp socket + protobuf可以吗
from arpc.
字符串对人友好,二进制对机器友好。现在的http的广泛使用早就超出了最初设计者的想象,根本原因还是方便,请求应答模式足以应对大多数web/app的交互,不需要开发者去操心连接生命周期管理。强调实时的场景才需要socket
这都是扯淡的说法,不要人云亦云拿别人整理好的文章思考问题。你上面这些说法是因为已经这样了才这样强行说好。 看二进制内容浏览器和ide一样都能可视化,keepalive一样是长连接复用,反倒是纯短链接几乎没人用,而且框架或者协议在七层提供的用户接口提供这些机制就可以了,谁整天去tcpdump wireshark抓包分析字节流啊? 别听那帮谬论,要懂得自己思考
如果KeepAlive就能应对一切场景谁还玩心跳啊
from arpc.
经验之谈, 没看什么技术文章. 我用postman+json不写代码就能凭记忆修改路由和消息体调试接口, tcp socket + protobuf可以吗
这个比较是不合理的,tcp pb你是自定义协议,不具备rfc或者统一标准,如果有统一标准,工具里一样可以做到方便修改。json本身是自释义的,你如果http pb一样不方便修改pb,但是工具可以去做导入pb定义然后你只改结构体之类的。
from arpc.
如果KeepAlive就能应对一切场景谁还玩心跳啊
你搞混了http keepalive 和tcp心跳的含义和用途,这俩没有直接的可比性
from arpc.
经验之谈, 没看什么技术文章. 我用postman+json不写代码就能凭记忆修改路由和消息体调试接口, tcp socket + protobuf可以吗
这个比较是不合理的,tcp pb你是自定义协议,不具备rfc或者统一标准,如果有统一标准,工具里一样可以做到方便修改。json本身是自释义的,你如果http pb一样不方便修改pb,但是工具可以去做导入pb定义然后你只改结构体之类的。
多了一些步骤调试就不如json便捷了, 很多人重视简便胜过性能
from arpc.
经验之谈, 没看什么技术文章
得出这个结论是因为你以前的主要工作是花在这些curd上了,以自己的舒适区去对比其他没有被广泛优化工具链的场景,但如果早期的http rfc就是二进制,现在的浏览器和社区工具链也一样完善。
考虑现有的东西是否够好,要加上想象,去想想如果不这样可以做哪些可以做到哪些,然后用各自的好来对比。
你再想想如果文本那么好,为什么还要搞2.0和3.0?
2.0这个垃圾就不说了,3.0很优秀
from arpc.
如果KeepAlive就能应对一切场景谁还玩心跳啊
你搞混了http keepalive 和tcp心跳的含义和用途,这俩没有直接的可比性
HTTP自带的KeepAlive很方便啊, 对用户无感知.
from arpc.
考虑现有的东西是否够好,要加上想象,去想想如果不这样可以做哪些可以做到哪些,然后用各自的好来对比。
应用层是文本还是二进制对我业务开发流程没有影响, 基本无感知, 日常工作接触最多的是IDL. 考虑到历史进程, HTTP1设计得还不错, XML做IDL是垃圾.
from arpc.
经验之谈, 没看什么技术文章
得出这个结论是因为你以前的主要工作是花在这些curd上了,以自己的舒适区去对比其他没有被广泛优化工具链的场景,但如果早期的http rfc就是二进制,现在的浏览器和社区工具链也一样完善。 考虑现有的东西是否够好,要加上想象,去想想如果不这样可以做哪些可以做到哪些,然后用各自的好来对比。 你再想想如果文本那么好,为什么还要搞2.0和3.0? 2.0这个垃圾就不说了,3.0很优秀
就算是同一类协议的不同版本使用场景也不一样, 搞大一统有点费力不讨好了
H3适合API Server不适合CDN
from arpc.
很多劣质的东西照样流行 😂
例如伪JWT, Restful...
每个人的品味和分辨能力都不一样
from arpc.
很多劣质的东西照样流行 😂
例如伪JWT, Restful...
每个人的品味和分辨能力都不一样
就是最早的时候没有,一些先驱设计出一些不完善的东西,其他人跟风,就流行了,没办法,大规模的这种就只能交给时间去慢慢替换掉。但咱们不能因为这些东西还算好用就不去追求更好了,单从优劣分析的角度该批评缺点的就批评它,不批评就没有进不了。说不定几十年后AI大一统了很快就把这些糟粕替换掉了:joy:
from arpc.
流量多吸引新人去尝试, 然后糟粕流行了起来
from arpc.
Related Issues (20)
- panic: unaligned 64-bit atomic operation on 32 bit HOT 5
- 可以同时监听 WebSocket 协议和 raw socket 吗? HOT 4
- question about BeforeRecv HOT 9
- issue with client HOT 14
- 同学,您这个项目引入了204个开源组件,存在3个漏洞,辛苦升级一下 HOT 3
- 例子里的micro下面的client.go的serviceManager.ClientBy获取不到服务 HOT 6
- Is there an elegant way to handle multiple client sessions? HOT 5
- 为什么需要设计这个maxload? HOT 3
- 处理Notify消息错误 HOT 4
- data race问题 HOT 5
- 您好请问用php语言写rpc的client端有例子吗? HOT 2
- Could you update readme slack link? HOT 10
- timeout不工作的问题 HOT 7
- 请问server和client端是如何管理tcp连接的?需要业务层自己做连接池对连接进行复用吗? HOT 3
- 怎么添加和获取message.values HOT 11
- 可以类似http那种增加header信息吗? HOT 5
- client 调用 server 附带的 values 会被原样再发送回来,是否可控不发送 HOT 7
- client经常性出现client reconnecting的错误 HOT 12
- arpc.js in /extension is out of sync with /examples HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from arpc.