在java远程调用多年的沉淀
《1》首先是socket调用。在orderService
中开放socket服务,在userService
中进行远程调用。
在java的对象是不可以直接通过socket进行传输的,需要有一个序列化的过程。而且java的默认的序列化,是无法被其他语言解析的。这样导致如果有其他语言提供的服务,是无法通过java调用。因此对于socket进行了升级,通过http+xml
进行信息的传输。这就出现了webservice
《2》Web Service技术, 能使得运行在不同机器上的不同应用无须借助附加的、专门的第三方软件或硬件, 就可相互交换数据或集成。依据Web Service规范实施的应用之间, 无论它们所使用的语言、 平台或内部协议是什么, 都可以相互交换数据。
《3》内部调用协议
http协议是应用层的一种协议,对于开放给外部系统时,是一个很好的选择,它可以实现跨语言调用。如果是自己的java服务内部调用时,使用http协议,就有点浪费资源。
====》
http协议在交互之前需要进行tcp三次握手,握手成功之后进行数据传输。一个http交互下来,有请求头、请求体、响应头、响应体。这些数据,在内部调用时,很多无关紧要的数据。也许可以自定义协议,简化传输数据。这就出现了dubbo协议,一种内部调用的协议。
dubbo协议追求的是数据量小,小则快,协议的设计也符合dubbo框框架的理念,适用与内部服务之间的数据交互。安全性就没有https做的那么好,但是也不需要,毕竟dubbo协议设计的初衷就是内部使用的。
spring cloud的feign组件内部使用http协议,内部调用可能有一些资源的浪费,但是http协议可以实现跨语言调用。
为了实现动态的机器添加与移除。最终,添加了一个机器的协调者,所有开放服务的机器在这个协调者中添加自己的开放服务的信息,这个协调者中会有哪些机器开放了哪些服务。这样看来这个协调者类似一个"通讯录"。我们称这个"通讯录"为注册中心。
作为协调者的注册中心,占据着一个重要地位。这样来看,注册中心主要实现了临时数据存储的功能。可以有多种选择数据库、redis、zookeeper、eureka、nacos、或者自己实现。
期初dubbo框架官方推荐使用zookeeper为注册中心,出现nacos之后,逐渐从zookeeper转为nacos。
结论为:zookeeper在大数据计算时做注册中心是一个好的选择,但是在服务调用时,也许数据不需要超强的一致性。nacos是目前来说很友好的一个注册中心,他提供了CP+AP
。还有可视化界面,还有配置中心等功能。功能相当完善。
于springboot在大大开发了开发的速度,而且springcloud的各个组件都比较完善,feign、网关、配置中心、熔断等等。spring、springcloud和springboot明显是一家人。这让一个孤身的dubbo有点不好立足,一些公司从dubbo框架转为springcloud全家桶。
nacos
是一个新推出的注册中心,其中最亮眼的功能是提供了可视化界面,而且还附带配置中心。瞬间dubbo就找到了家人。这些组件的出现让dubbo又崛起了起来。而且dubbo本来扩展性就很好。可以进行协议扩展、调用拦截扩展、引用监听扩展、集群扩展等等。
另外dubbo3.0主力使用Triple
协议。完整兼容 gRPC over HTTP/2。推荐使用 protobuf
作为默认序列化,在性能和跨语言上的效果都会更好。
手机扫一扫
移动阅读更方便
你可能感兴趣的文章