V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
graysheeep
V2EX  ›  程序员

rpc 的意思是,远程过程调用,那么一个服务器上的远程服务能否在浏览器端通过 ajax 调用么

  •  
  •   graysheeep · 2018-03-26 17:23:09 +08:00 · 5648 次点击
    这是一个创建于 2444 天前的主题,其中的信息可能已经有所发展或是发生改变。

    如题,看 demo 都是一个 server 端,一个 client 端,都是用同一种语言比如 go,或者 java 实现。那么如果用 java 起了一个 grpc 服务,能否在浏览器端用 ajax 进行调用呢?

    20 条回复    2018-03-27 13:32:26 +08:00
    noe132
        1
    noe132  
       2018-03-26 17:27:03 +08:00
    那就变成 restFUL api 了?
    zenxds
        2
    zenxds  
       2018-03-26 17:27:14 +08:00
    rpc 的协议一般不是 HTTP
    feverzsj
        3
    feverzsj  
       2018-03-26 17:30:59 +08:00
    可以,只要你客户端有支持 grpc 的库
    graysheeep
        4
    graysheeep  
    OP
       2018-03-26 17:33:34 +08:00
    @zenxds grpc 是 http2
    graysheeep
        5
    graysheeep  
    OP
       2018-03-26 17:34:19 +08:00
    @noe132 额是的。还是说有更科学的做法?
    hyperdak288
        7
    hyperdak288  
       2018-03-26 17:44:55 +08:00
    只要是 http 请求,你就能通过浏览器调用呀。

    RPC 一部分是 tcp 通信,另外一部分是直接 http 的,http 这种当然可以访问了。

    比如你看 spring boot 的 rpc 就都是 http,dubbo 的当当扩展版 dubbox 也是一样的支持 http
    forestyuan
        8
    forestyuan  
       2018-03-26 17:45:19 +08:00
    可能还会牵涉到权限问题吧
    nine99
        9
    nine99  
       2018-03-26 18:10:17 +08:00
    🙄
    wweir
        10
    wweir  
       2018-03-26 19:45:10 +08:00 via Android
    既然提到了 go,那就得说下,golang 标准库提供了 jsonrpc 包,并且提供了 httpServer 的 rpc 支持
    那么问题来了真有人用这玩意么?
    agagega
        11
    agagega  
       2018-03-26 20:30:17 +08:00   ❤️ 1
    提出 REST 的那个老哥,他在他博士论文的最后提到了 RESTful 和 RPC 机制的比较。两者的确很像,但是不能一概而论。RPC 在概念上就是把调用放到了两台主机上。而基于 HTTP 协议的 RESTful API 能够充分地利用 HTTP 协议的一系列基础设施,从缓存到 CDN 到代理什么的。RESTful 强调的是「资源」的概念,而不是简单的「返回值」。
    aa6563679
        12
    aa6563679  
       2018-03-26 21:53:04 +08:00 via iPhone
    浏览器要考虑跨域问题,不跨域的话 http 接口都能调
    bolide2005
        13
    bolide2005  
       2018-03-26 22:08:34 +08:00   ❤️ 4
    首先,rpc 使用 http 调用一点毛病也没有,rpc 本事并没有规定一定使用哪种通信协议实现,只是在一般情况下,我们选择使用 rpc 会有一定的性能上的考虑,那么这时候就会偏向于使用更高效的传输方式,比如使用 TCP 传输序列化后的二进制数据,而不是使用 http 传输字节码;
    其次,grpc 确实使用了 http2,golang 的 rpc 标准包里也有通过 http 实现通信的方法,但实质上,它们都只是借用了 http 来建立连接,当连接建立后,里面传输的都是序列化后的二进制,而转换数据到二进制的过程,是在 stub 函数中进行的;
    然后回到 rpc 的定义来看,其实 rpc 要解决的问题,就是怎么样可以像调用本地同进程的函数一样,调用一个 remote server ? rpc 给出的解决方案就是使用桩函数来屏蔽 remote 调用,在 client 本地直接调用桩函数;
    那么楼主的问题到这里就可以解决了:当然可以使用 ajax 来调用 rpc server,但需要生成 ajax (也就是 javascript )可以直接使用的 stub function,在这个 function 里进行 remote 交互,至于是否在这里进行序列化,讲道理是应该的,这样能提高传输效率,但如果不做也没问题。只不过,要是这样的话,为何不直接使用 restul ?相比 rpc 调用,restful 不仅更容易调试,也容易进行权限和参数的控制,同时更加灵活。
    zhengxiaowai
        14
    zhengxiaowai  
       2018-03-26 22:10:43 +08:00
    RPC 一般采用二进制协议,当然用 HTTP 也没有错
    WispZhan
        15
    WispZhan  
       2018-03-26 22:54:03 +08:00
    RPC 的定义里,本身并没有限制语言以及具体传输协议实现方式。它是一个用于进程间通讯的调用过程,侧重点再过程。返回值只是其结果。

    因此,应用协议上用 HTTP 也好,用 Websocket 也罢;传输协议是 TCP 也好,是 UDP 也罢;数据载体是文本(ACSII)也好,是二进制也罢。从定义上是没有区分的。

    通常来说采用二进制流传输的 RPC 比较多,因为相比文本,流量更小,更容易解析,可读性差。但文本可读性更高,但体积较大。

    感觉现在 RPC 和 RPC 框架 的定义,有点模糊了。好像现在说 RPC 都是指 RPC 框架了。RPC 框架的好处是服务端与客户端定义的数据模型可以被框架统一生成。甚至于有的框架可以直接生产客户端代码……

    ---

    宗上所述,广义上,RESTful 也可以说成是 rpc。
    你这个应用场景,明显直接 ajax 掉 http 接口更方便…… gprc,难道你要用 js 操作字节么?
    如果你是 node 后端和 java 后端互调的话,RPC 或许好点。
    zachguo
        16
    zachguo  
       2018-03-27 02:34:55 +08:00 via Android
    dangyuluo
        17
    dangyuluo  
       2018-03-27 03:28:55 +08:00
    最近在研究 Mongoose OS 的 RPC,载体可以是 Websocket,MQTT,Http 或者是串口通讯。所以说 RPC 是广义的请求-相应,不仅只要服务端提供,可以以各种方式调用,当然你用 Ajax 也可以了。
    liukefeng2008
        18
    liukefeng2008  
       2018-03-27 09:57:14 +08:00
    jsonRPC 了解一下
    ZSeptember
        19
    ZSeptember  
       2018-03-27 11:20:13 +08:00
    可以啊,只要 RPC 库使用 HTTP 协议作为通讯方式就行
    lolizeppelin
        20
    lolizeppelin  
       2018-03-27 13:32:25 +08:00 via Android
    http 协议不适合执行需要一定时间返回的

    所以才不用 http 协议跑 rpc
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1190 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 33ms · UTC 18:38 · PVG 02:38 · LAX 10:38 · JFK 13:38
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.