j***a 开发RPC,j***a开发rpc

dubbo原理深度解析？
微服务调用为什么用RPC框架，http不更简单吗？

dubbo原理深度解析？

dubbo原理和机制：

Dubbo是一个高性能优秀的服务框架，它使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和Spring框架无缝集成。

Dubbo是一款高性能、轻量级的开源 java RPC框架。

（图片来源网络，侵删）

它提供了三大核心能力：

1、面向接口的远程方法调用；

2、智能容错和负载均衡；

（图片来源网络，侵删）

3、服务自动注册和发现。

注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小。

监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示。

（图片来源网络，侵删）

服务提供者向注册中心注册其提供的服务，并汇报调用时间到监控中心，此时间不包含网络开销。

微服务调用为什么用RPC框架，http不更简单吗？

首先微服务也有用***的，现在流行的feign，底层就是***，也是我们经常提到的restful编程方式。

Rpc在国内最具有代表的是dubbo，底层可以选择 netty通讯，速度肯定是比***快的。

但是微服务不是一个简单的调用，涉及到很多方面，比如容错，高并发，熔断，事务等等。普通的***代码是无法解决这些问题的。一般需要很多组件来配合，比如feign就要配合ro***，hystrix等来配合，dubbo也需要zookeeper来配合。

所以这两者在我们的开发中，都很常见。

*** 对应 tcp，RPC 对的是rest。这问题是orange vs apple，不是一回事。jsonRPC 是可以走tcp protocal 也可以走 ***. 但rest只能走***, 因为rest METHOD 在tcp 不存在。 gPRC 也可以走***通常走tcp. 如果是edge service, 一般要支持***协议. TCP协议效率更高，不需要在*** header上浪费很多不必要的数据，而且支持duplex很自然，这一点即使是***2也不完善，除非用web socket. Micro service，如果不是edge service，一般用tcp效率高，jsonRPC比较容易测试, gRPC数据可读性差，但接口更严格效率更高，尤其是binary data 传输效率高，不需要转换为base64.