rpc深度分析

https://my.oschina.net/tantexian/blog/632100?p={{page}}

当然，我知道在dubbo不支持rest的情况下，很多朋友采用的架构是spring mvc restful调用dubbo (spring) service来发布restful服务的。这种方式我觉得也非常好，只是如果不修改spring mvc并将其与dubbo深度集成，restful服务不能像dubbo中的其他远程调用协议比如webservices、dubbo rpc、hessian等等那样，享受诸多高级的服务治理的功能，比如：注册到dubbo的服务注册中心，通过dubbo监控中心监控其调用次数、TPS、响应时间之类，通过dubbo的统一的配置方式控制其比如线程池大小、最大连接数等等，通过dubbo统一方式做服务流量控制、权限控制、频次控制。另外spring mvc仅仅负责服务端，而在消费端，通常是用spring restTemplate，如果restTemplate不和dubbo集成，有可能像dubbo服务客户端那样自动或者人工干预做服务降级。如果服务端消费端都是dubbo系统，通过spring的rest交互，如果spring rest不深度整合dubbo，则不能用dubbo统一的路由分流等功能。

上述各个组件之间的关系（引自Dubbo文档）说明如下：

这里的Invoker是Provider的一个可调用Service的抽象，Invoker封装了Provider地址及Service接口信息。

Directory代表多个Invoker，可以把它看成List，但与List不同的是，它的值可能是动态变化的，比如注册中心推送变更。

Cluster将Directory中的多个Invoker伪装成一个Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个。

Router负责从多个Invoker中按路由规则选出子集，比如读写分离，应用隔离等。

LoadBalance负责从多个Invoker中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选。

http://www.infoq.com/cn/news/2014/10/dubbox-open-source/

dubboX 实现了基于http+JSON的rest服务扩展https://github.com/dangdangdotcom/dubbox/tree/dubbox-2.8.4

RestEasy，jboss开源项目，基于restful的web service框架

我们在用dubbo，朋友的公司也有在用的，面临的问题也大致相似，问题定位、熔断和监控方面的问题让人没有那么的放心，最近打算尝试在spring-cloud中寻找答案。

spring cloud整机，dubbo需要自己组装；整机的性能有保证，组装的机子更自由。

新浪-motan、google维护的grpc