有网友碰到这样的问题“现在企业都是用的哪些分布式框架,dubbo是不是过时了?”。小编为您整理了以下解决方案,希望对您有帮助:
解决方案1:
回顾40多年发展历程,RPC已在众多大中小企业所普及。我们所熟知的阿里的Dubbo、腾讯的Tars、Google的gRPC、的Thrift、京东的JSF、美团的OCTO-RPC、Spring Cloud等。这些RPC框架在各自公司根据自己的业务情况,支撑着几乎全部业务系统,更为重要的是在大促618和11.11期间,RPC框架的抗压能力更为显著。
服务化在架构设计层面属于抽象概念,那最终真正用于服务化落地实现的关键还需要RPC协议。在上述个大厂不同的RPC框架对序列化实现、可读性、扩展性以及通用性方面都不尽相同。但无论是哪一种RPC框架,他们的设计和实现思路都未离开Nelson的理念:支持分布式系统异构。那在分布式系统异构中,必然离不开RPC的两个最为核心部分:
在众多优秀框架中,我们不得不提到一个被业界公认的优秀RPC分布式框架Dubbo。Dubbo3 提供了 Triple、Dubbo2 协议,这是 Dubbo 框架的原生协议。除此之外,Dubbo3 也对众多第三方协议进行了集成,并将它们纳入 Dubbo 的编程与服务治理体系,包括 gRPC、Thrift、JsonRPC、Hessian2、REST 等。
接下来我会从10个方面,来聊一聊为什么很多企业会选择Dubbo做为公司内部分布式框架。
Dubbo是阿里巴巴公司开源的一个高性能优秀的服务框架,使得应用可通过高性能的 RPC 实现服务的输出和输入功能,可以和Spring框架无缝集成。它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。
企业选择Dubbo的10个理由:
1. 对业务代码侵入性极低。跨网络服务间的调用方式要比本地同一进程空间执行方法复杂的多,比如通信协议、对象序列化、网络传输等复杂细节。RPC框架为我们屏蔽了非业务相关的实现细节,这个能是开发人员只关注自身的业务逻辑即可。透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入。
2. 服务自动注册与发现。实现服务发现的方式有很多种,Dubbo 提供的是一种 Client-Based 的服务发现机制,通常还需要部署额外的第三方注册中心组件来协调服务发现过程,如常用的 Nacos、Consul、Zookeeper 等,Dubbo 自身也提供了对多种注册中心组件的对接,用户可以灵活选择。官方推荐使用Zookeeper注册中心。
3. 可适配云原生微服务。随着互联网技术的不断更新且硬件设施成本也越来越低,云原生时代的基础设施能力也在不断向上释放,Dubbo也逐渐走在了适配云原生微服务的变更的道路上。
4. 三大中心高可用天然保障。Dubbo包括三大中心:注册中心、配置中心和元数据中心。但在实际生产环境当中,难免会有异地部署、同城多活、多地多中心等场景。那在这些方面Dubbo能否保障系统的高可用呢?答案是肯定的。Dubbo天然支持多注册中心、多元数据中心、多配置中心,来满足同城多活、两地三中心、异地多活等部署架构模式的需求。
5. 灵活的流量路由管理策略。通过 Dubbo 定义的路由规则,可以实现对流量分布控制。Dubbo提供了支持Mesh方式的流量管理策略,可以很容易实现 A/B测试、金丝雀发布、蓝绿发布等能力。
6. 易于对Dubbo进行二次开发。Dubbo 中的扩展能力是从 JDK 标准的 SPI 扩展点发现机制加强而来,它改进了 JDK 标准的 SPI很多问题,Dubbo 考虑到适用场景面的问题,没有强依赖 Spring 等 IoC 容器,而是选择了最简单的 Factory 方式管理扩展。
7. 完备的技术文档体系。目前Dubbo已作为Apache顶级项目,自然少不了完善的文档。Apache Dubbo提供了详细的开发说明文档、众多技术牛人博客以及完善的社区生态。
8. 服务监控界面可视化。Dubbo-admin和Dubbo-monitor提供了完善的服务接口管理和监控功能,针对不同应用的不同接口,能够进行多版本、多协议、多注册中心管理。监控中心负责统计各服务调用次数,调用时间等,统计先在内存汇总后每分钟一次发送到监控中心服务器为服务的监控运维采集数据。
9. 监控对服务性能影响小。序列化方面,Dubbo采用效率最高的二进制传输方式。请求协议采用单一长连接和NIO通讯机制,从而提升了通信效率,不用反复连接,直接传输数据,并且支持大并发量。
10. 完备的全链路跟踪方案。Dubbo可收集每个调用链路上每个服务的执行耗时,以及整合孤立日志,便于运维人员根据TraceId便可知道整个请求链路的运行状态,从而能很好的提升排查问题效率。
由于Dubbo框架是由Java语言开发,如果是项目中使用了其他非Java语言,那需要选择其他RPC框架做技术选型。如果在未来Dubbo做到多语言适配,在RPC分布式框架领域内是否有一统江湖的可能呢?让我们拭目以待。
Copyright © 2019- 517ttc.cn 版权所有 赣ICP备2024042791号-8
违法及侵权请联系:TEL:199 18 7713 E-MAIL:2724546146@qq.com
本站由北京市万商天勤律师事务所王兴未律师提供法律服务