请教关于Node和Java后端交互问题?
发布于 6 年前 作者 dpc761218914 5921 次浏览 来自 问答

现在尝试:java+dubbo+zookeeper后端=》Node中间件=》vue前端,但是node和java后端交互出现问题,目前使用node-zookeeper-dubbo模块和java后端交互,做测试的时候,会出现这样或那样的问题。

假如这样的方式:如果所有的dubbo服务都放在java端,java端向node中间件提供http请求,Node端就是简单的转发请求、做日志、缓存等。性能会差吗?在并发较大的情况下(例如使用request模块)

或者大家有什么更好的node中间件和java dubbo交互的方法吗?

17 回复

http 的话,一般业务的量级都没啥问题的。

阿里的话,用 HSF 协议,是序列化过的。

主要的流程是:

  • 需求分析和概要设计,Java 同学产出 interface,并发布到 maven
  • 前端同学通过 CLI 工具,自动下载对应的 jar,解析生成对应的 javascript rpc proxy 类,并自动生成 mock
  • 前端同学 Controller 里面直接调用这些 proxy 去请求数据
  • proxy 内部会自动做序列化和反序列化

相关文章:

grpc了解一下 这种跨语言架构慎用,如果没有过高的性能要求就少给自己挖坑,毕竟稳定性比高性能重要

@yuedun GRPC 确实不错,但实践过一段时间,Node 的 SDK 这块完善度和质量还有比较大的完善空间,坑较多。

@atian25 所以,nodejs虽然可以很容易使用一些高级技术,但最终发现还是保持简单才是最好的。一般采用node就是为了快速开发,如果因为一些技术拖慢了,那还不如使用java开发,既稳又能扩大团队

@atian25 超级感谢,很详细。请教一下,其实HSF和grpc都没用过,不是很熟悉,而且貌似坑也多。如果用http的话,如果java后端做分布式、集群之类的。然后提供http接口给Node使用,然后node做一些简单的权限、日志、缓存等服务后,给vue前端提供http统一规范的接口,这样可以满足一般的业务量级吗?

@yuedun 嗯,感谢回答,其实也是考虑的node的快速开发和高并发等等特性。数据交互、缓存、日志等应该比较方便。

@dpc761218914 可以的,绝大部分业务的量级都没问题的

@atian25 嗯嗯,谢谢指导~

刚好上个月实现了这种node的dubbo provider功能,为了充分利用java开源社区的智慧,采用了proxy设计模式。node与jvm通过json协议走HTTP通信,通过第三方配置服务实现配置解耦

@royalrover 感谢回答,你这是直接通过node与java交互吗?通过Node.js 调用 Java? 像这样:https://www.cnblogs.com/zhuanzhuanfe/p/7627176.html 还是有其他的方式呢?他们如何通过http通信呢? java直接暴露http请求接口吗?

现在项目里 前端 到 node 走的 http node 到 go服务 走的 grpc

不知道这样好不好

@dpc761218914 我说的是node应用作为dubbo provider。 如果node作为consumer,那么很直接通过tcp走dubbo协议和provider交互。

@royalrover 是的,我是consumer,不知道性能怎么样呢?

@OXOYO 嗯嗯,也在摸索中~~

@dpc761218914 不太懂地讨论一下,是不是http的性能要比grpc等的差?但http应该算是比较通用的沟通协议,基本没啥坑。但rpc之类的可能在不同应用上要做通用化的处理是不是比较麻烦?但相对于http性能会高一个量级?

@dpc761218914 consumer就更简单了,直接走dubbo协议就可以了,拼装dubbo协议头与body体。其实这种客户端只要做了HA功能,性能倒是其次了。性能大多不会发生在客户端调用上面,而是对应服务提供方的吞吐量以及时延等。

@dpc761218914 我们这边50台服务器基本上能满足到日均10亿的量级,但是问题排查跟报警会很痛苦,因为后端java服务一般都提供rpc接口,如果用http交互,他们需要再前面加一层http服务,http服务前面还要搞一层负载均衡; 这样如果后端接口超时,你就只能拿到负载均衡的ip,也不知道是哪台后端服务器出问题难以排查,而且报警消息基本上无效后端不认。。。 而且调用链路变长,性能变差,出错的环节也增多,所以你的情况跟我一样建议用rpc跟后端交互。

回到顶部