其实dubbo是微服务框架吗的问题并不复杂，但是又很多的朋友都不太了解springcloud是微服务还是分布式，因此呢，今天小编就来为大家分享dubbo是微服务框架吗的一些知识，希望可以帮助到大家，下面我们一起来看看这个问题的分析吧！
软件产品架构中什么是单体架构、SOA架构、微服务架构
软件产品架构是不断迭代演化的，从单体服务架构发展到现在的服务化、微服务的架构。
单体架构单体架构就是所有的业务模块都是耦合在一个项目中，开发、部署都在一起；如果其中一个模块需要上线升级，那么所有模块都要一起启停；
在早期，单体架构的项目团队成员需要是“全栈”，因为前端、后端、数据库都是一波人负责，后来开始进行了逻辑分层，团队也分成了前端UI团队、后端和DBA团队，每个团队都有自己负责的职责。
然而随着业务逻辑越来越复杂，模块和模块之间的耦合度越来越高；另外随着用户和数据量的增多，单体架构也不再能够支撑高并发和大数据。
SOA架构为了解决上面的问题，SOA出现了。
SOA代表了面向服务的架构，SOA将应用程序的业务模块进行拆分，形成独立的应用系统，系统和系统之间通过明确的接口串联起来；
每个系统内部结构和逻辑发生改变，并不影响对外提供的服务，只要保持接口不变，服务内部对外是透明的；
SOA架构中，服务定义标注的接口，可以提供给多个调用方使用，增加了服务的重用性。
SOA架构时代有两个很重要技术实现方式：WebService和ESB：前者提供了标准的数据传输协议，后者实现了服务编排和协议转换。
微服务架构但是随着用户和数据量的进一步增长，SOA也暴露出来一些缺点，比如SOAP协议、XML较重；服务管理不完善；ESB本身就比较重，而且它本身算是一个单点，在软件架构中，单点意味着风险。
在微服务的架构中，各个微服务可以独立开发，独立部署；微服务之间通常使用Restful风格的API通信，传输格式也通常选择JSON；
微服务是SOA架构的延续，它们和单体应用相比，大大提高了系统的负载能力，解决了应用高并发的需求；
服务和服务之间的耦合度也被降低，并且项目团队可以被拆分成多个小团队，每个微服务都可以进行敏捷开发部署；
每个团队的技术栈也可以不相同，只要遵守接口协议即可。
至于微服务和SOA架构的区别，我是这样理解的：SOA架构和微服务架构都属于分布式架构，分布式的思想就是把不同的业务模块，部署在不同的服务器上，以应对高并发的问题；SOA是一种分布式架构，把业务系统分成多个子系统，提供不同的服务，再通过服务组合、编排实现业务流程；微服务是SOA的升华，如果非要说点儿不同的，那么微服务更加强调服务的细分和专业，去ESB总线、去中心化，部署粒度更细，服务扩展更灵活。
当然SOA、微服务的出现，在解决一些问题的时候，也带来了另外一部分的问题，比如增加了网络开销、服务依赖性、增加了测试运维难度、数据一致性问题等等。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。dubbo和feign哪个用得多
dubbo用的多。
ApacheDubbo(incubating)|?d?b??|是一款高性能、轻量级的开源JavaRPC框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。
Dubbo是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案、服务治理方案。
微服务框架排行
微服务架构的经典开发框架1,SpringCloud：最早最成熟，Java开源微服务框架方案2,Dubbo:阿里巴巴开源Java服务治理框架Spring3,3,CloudAlibaba阿里开源Java微服务框架方案
4,SOFA：蚂蚁金服开源Java金融微服务框架方案GoMicro：
5,Go语言开源微服务框架。
dubbo和微服务的区别
1.从架构角度上
Dubbo内部实现功能没有SpringCloud强大（全家桶），只是实现服务治理，还缺少分布式配置中心、服务网关、服务链路追踪、消息总线、服务注册与发现、断路器等，如果需要用到这些组件，Dubbo需要另外去整合其他框架，他没有一个比较完善的生态圈。
2.从更新迭代速度
Dubbo为阿里巴巴开源的分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，是SOA服务化治理方案的核心框架，后期由于其他原因停止更新维护，由当当网更新升级为Dubbox，在由以SpringCloud为首兴起的一代微服务架构之后，阿里巴巴又重新开始维护更新Dubbol，就更新迭代速度而言，Dubbo目前更新速度没有SpringCloud快，而且SpringCloud更新升级到SpringCloud2.0之后，SpringCloud生态圈会越来完善和稳定。
3.从开发背景角度
Dubbo的开发背景是阿里巴巴，在中国也推出了非常多的优秀的开源框架
但是在SpringCloud的背景是Spring家族以及Netflix公司，Spring是专注于企业级开源框架开发，在中国，或者在整个世界上Spring框架都应用的非常广泛。所有相对来说SpringCloud的背景比Dubbo更加强大，有更多的人愿意去使用他。
微服务框架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是微服务框架吗和springcloud是微服务还是分布式的答案你都知道了吗？欢迎再次光临本站哦！
