今天给各位分享dubbo和feign哪个用得多的知识，其中也会对dubbo不建议用进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
本文目录
dubbo调用耗时如何优化
Dubbo是一个高性能、轻量级的分布式服务框架，但是在调用过程中，如果涉及到复杂的业务逻辑或者远程调用，可能会产生较高的耗时。以下是一些优化Dubbo调用耗时的建议：
1.拆分服务：将复杂的服务拆分成更小的服务，这样可以减少单个服务的调用耗时，提高服务性能。
2.调整Dubbo参数：可以通过调整Dubbo的参数来优化性能。例如，可以增加线程池大小、调整超时时间等。
3.优化网络：Dubbo调用过程中，网络延迟是一个重要的因素。可以通过优化网络结构、使用高速网络设备、采用压缩算法等方式来降低网络延迟。
4.缓存数据：对于一些频繁调用的服务，可以考虑使用缓存来减少远程调用次数。可以使用本地缓存或者分布式缓存来缓存数据。
5.异步调用：对于一些耗时的服务调用，可以采用异步调用的方式，避免阻塞主线程。可以使用异步回调、Future等方式实现异步调用。
6.批量调用：对于一些连续的调用，可以考虑批量调用，减少网络交互次数。可以通过批量参数、批量结果等方式实现批量调用。
7.序列化优化：Dubbo支持多种序列化协议，如Hessian2、Kryo、FST等。可以根据实际情况选择合适的序列化协议来优化序列化性能。
8.消除不必要的数据同步：在分布式系统中，数据同步是一个重要的安全措施。但是，过度的数据同步可能会增加Dubbo调用的耗时。可以通过减少数据同步的频率、使用异步同步等方式来优化性能。
9.使用负载均衡：Dubbo支持多种负载均衡策略，如随机、轮询、最少活跃调用等。可以根据实际情况选择合适的负载均衡策略来平衡服务器的负载，提高Dubbo调用的性能。
总之，优化Dubbo调用耗时需要根据实际情况进行综合考虑，可以从服务设计、网络优化、参数调整、缓存等方面入手，选择合适的优化措施来提高Dubbo调用的性能。
dubbo和feign哪个用得多
dubbo用的多。
ApacheDubbo(incubating)|?d?b??|是一款高性能、轻量级的开源JavaRPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案、服务治理方案。
doubble框架用的什么协议
默认使用dubbo协议。单一长连接和NIO异步通讯，适合大并发小数据量的服务调用，以及消费者远大于提供者。rmi协议、hessian协议、http协议、webservice
微服务框架spring cloud和dubbo有什么区别
首先，从严格意义上来说，Dubbo和SpringCloud的定位是不一样的。Dubbo是一个高性能的、基于java的开源RPC框架，注意它的定位是是高性能和RPC框架。SpringCloud提供了一系列通用工具来帮助开发者在分布式系统里快速构建一些常见模式，比如分布式配置管理、服务发现、熔断降级、智能路由、微代理、控制总线、一次性令牌、全局锁、分布式选主、分布式session等一些列解决方案，它的设计目标是提供一整套服务治理能力，它具有一套完整的微服务解决方案体系。
dubbo只是一个分布式的RPC框架，如果一定要按照分布式系统架构里的功能来定义的话，只是解决了服务发现、服务路由、服务降级和负载均衡方面的能力，新版本里也提供了动态配置中心和服务治理相关的能力，但相比SpringCloud而言，还是差了相当一部分的能力。
从功能支持上来说，dubbo的角色定位可能更像是另外一个大名鼎鼎的框架，那就是gRPC，而且两者在使用的方式以及工作原理上都非常相似，都是基于序列化协议来解决分布式系统中的远程调用问题，在使用上可以通过约定接口或者通过proto文件生成代码文件来“提升用户的使用”。
如果你在系统设计之初就已经考虑到了后续可能会涉及到各种服务治理能力，比如分布式配置、全局锁、分布式session等常见需求，那么使用SpringCloud将会减少你很多的工作，因为这些基本上都是"套件"，相互配合使用会非常顺畅。如果你想要的只是解决分布式架构后的远程调用问题，那么Dubbo是一个不错的选择。
SpringCloud和Dubbo的基本差异大概就是如上所述，如果你不知道该如何做选择，这里再补充几个比较关键的差异点，希望能帮助你更好的结合自身业务做出选择：
能力支持方面
上文也提到，SpringCloud提供了一整套微服务治理的功能组件，很多组件基本上都是"开箱即用"的，并且相互之间能很好的兼容，举个例子，如果要在SpringCloud里实现服务发现、负载均衡和熔断降级，你只需要引用SpringCloud的依赖组件即可，直接通过注解便可使用，基本上零配置；而dubbo框架，除了上述提到的能力支持之外，如果想要使用熔断降级，那你可能需要额外引用hystrix或者resilience4j来实现；温馨提示，hystrix官方目前也已经宣布不再更新，并且推荐使用resilience4j。
协议兼容方面
SpringCloud里并没有限制服务之间的通信协议，但是主流的一些客户端比如restTemple、feign等都是直接支持使用Ribbon来做服务注册发现和智能路由的，其底层通信的协议都是HTTP；而dubbo框架缺省是基于NIO异步传输使用TCP长连接并采用Hessian二进制序列化方式通信的；
这会涉及后续系统在扩展上的兼容性问题，比如需要调用一个三方系统或者是被第三方系统调用，相比而言HTTP协议可能更加通用。
模型定义方面
dubbo在模型设计上将一个接口定义为一个服务，而SpringCloud里则是将一个应用定义为一个服务，这两者在模型上是存在很大差异的，你也许会奇怪，这个对使用会有影响吗？从现有使用方面来说是没有什么影响的，但是你如果有关注ServiceMesh最新微服务技术的话，目前对Dubbo协议这块可能支持暂时还不完善，其中很大一部分原因就是因为在服务模型上与K8S的服务模型有差异；
调用性能方面
如果分布式系统中比较关注远程调用的性能，那Dubbo可能是一个较好的选择，基于NIO和TCP长连接的通信传输方式，在性能上相比HTTP协议是有绝对优势的；当然基于SpringCloud你也可以使用gRPC协议来解决性能问题，那就是另外一个问题了。
好了，关于dubbo和feign哪个用得多和dubbo不建议用的问题到这里结束啦，希望可以解决您的问题哈！
