现在尝试：java+dubbo+zookeeper后端=》Node中间件=》vue前端，但是node和java后端交互出现问题，目前使用node-zookeeper-dubbo模块和java后端交互，做测试的时候，会出现这样或那样的问题。
假如这样的方式：如果所有的dubbo服务都放在java端，java端向node中间件提供http请求，Node端就是简单的转发请求、做日志、缓存等。性能会差吗？在并发较大的情况下（例如使用request模块）
或者大家有什么更好的node中间件和java dubbo交互的方法吗？
http 的话，一般业务的量级都没啥问题的。
阿里的话，用 HSF 协议，是序列化过的。
主要的流程是：
相关文章：
@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 consumer就更简单了，直接走dubbo协议就可以了，拼装dubbo协议头与body体。其实这种客户端只要做了HA功能，性能倒是其次了。性能大多不会发生在客户端调用上面，而是对应服务提供方的吞吐量以及时延等。
grpc了解一下 这种跨语言架构慎用，如果没有过高的性能要求就少给自己挖坑，毕竟稳定性比高性能重要
@yuedun GRPC 确实不错，但实践过一段时间，Node 的 SDK 这块完善度和质量还有比较大的完善空间，坑较多。
@atian25 所以，nodejs虽然可以很容易使用一些高级技术，但最终发现还是保持简单才是最好的。一般采用node就是为了快速开发，如果因为一些技术拖慢了，那还不如使用java开发，既稳又能扩大团队
@atian25 超级感谢，很详细。请教一下，其实HSF和grpc都没用过，不是很熟悉，而且貌似坑也多。如果用http的话，如果java后端做分布式、集群之类的。然后提供http接口给Node使用，然后node做一些简单的权限、日志、缓存等服务后，给vue前端提供http统一规范的接口，这样可以满足一般的业务量级吗？
@yuedun 嗯，感谢回答，其实也是考虑的node的快速开发和高并发等等特性。数据交互、缓存、日志等应该比较方便。
@dpc761218914 不太懂地讨论一下，是不是http的性能要比grpc等的差？但http应该算是比较通用的沟通协议，基本没啥坑。但rpc之类的可能在不同应用上要做通用化的处理是不是比较麻烦？但相对于http性能会高一个量级？
@dpc761218914 我们这边50台服务器基本上能满足到日均10亿的量级，但是问题排查跟报警会很痛苦，因为后端java服务一般都提供rpc接口，如果用http交互，他们需要再前面加一层http服务，http服务前面还要搞一层负载均衡； 这样如果后端接口超时，你就只能拿到负载均衡的ip，也不知道是哪台后端服务器出问题难以排查，而且报警消息基本上无效后端不认。。。 而且调用链路变长，性能变差，出错的环节也增多，所以你的情况跟我一样建议用rpc跟后端交互。