背景目前nodejs的应用越来越广泛，但是很难对接java的dubbo系统，所以我们需要实现node端的dubboprovider逻辑。Java的dubboprovider和consumer在一个jar中，提供服务配置、注册、集群和负载均衡、监控和多种协议。使用nodejs实现一个可用的dubboproviderSDK是没有问题的。最简单的实现是将对应的ZK集群注册接口映射到机器IP，消费者访问对应的rpc接口即可。但在可用的基础上，仍需提供相关的配置、注册、监控等配套设施，才能实现高商用。在评估各种实现方案后，决定放弃节点提供商SDK的开发，采用节点+代理的代理模式。agent是一个java服务，可以和node服务交互，提供dubboprovider功能。agent部署在nodejs服务机上，作为dubbo服务的入口。同时，节点服务返回的数据类型由代理进行转换映射，如object(node)->Map(Java)，具体转换规则由节点接口提供者提供。调用接口jar包，消费者可以使用jar包调用。在整体架构上，vitamin是一个统一的基于数据库的配置平台，解耦了各个系统的强依赖。Node中间件Node中间件提供dubbo接口上报和服务提供功能。上报http接口要暴露的Dubbo服务配置信息（接口+版本+方法），即映射关系。node提供的rpc服务以HTTP的形式存在（兼容之前的业务），由agent调用，数据类型为JSON。Agent根据Vitamin的实时配置向zookeeper注册dubbo服务（泛化）。泛化服务的每个方法都会根据Vitamin中的映射关系找到对应的http本地接口（localhost）进行调用——入参和返回值为json和Java类型转换Node业务端Node提供普通的HTTP+JSON服务，可复用历史接口提供dubbo接口对应的jar包。需要保证http接口json和jar的模型转换关系是可行的。上游业务获取到jar包依赖后，像普通dubbo服务一样调用将Dubbo方法入参转为NodeJshttp调用参数：强类型转弱类型，直接将NodeJs服务返回的json转为Dubbo方法即可返回值：弱类型转强类型解决方法：Dubbo泛化服务返回一个Map，当消费者拿到这个Map后，会自动根据客户端进行相应的字段注入。大量服务超时可能导致代理连接池或线程池满存在单机性能问题
