谢看山腰，作为Apache Dubbo的PMC，说两句。

要想搞清楚题主的问题，我们需要分三个子问题来看：

  1. 什么是微服务架构
  2. 什么是Dubbo
  3. 最后来看，Dubbo是不是微服务架构

1、什么是微服务架构

什么是微服务架构，可以参考我这篇文章：

kimmking：00.什么是微服务架构?

zhuanlan.zhihu.com图标

微服务架构（MicroServices Architecture，MSA）：微服务架构可以看做是面向服务架构和分散式服务架构的拓展，使用更细粒度的服务（所以叫微服务）和一组设计准则来考虑大规模的复杂系统架构设计。也可以把它看做是SOA的一种衍生，所以总体来说，微服务架构是一种架构设计思想，也是一种做系统的方法论。

通过Martin Flowler的在【这篇文章】中对微服务描述，可以抽象出以下几个关键点：

  • 由一些独立的服务共同组成应用系统
  • 每个服务单独布署、独立跑在自己的进程中
  • 每个服务都是独立的业务
  • 分散式管理

更多的学习微服务的知识，可以参考：

kimmking：有没有讲微服务架构比较不错的书？?

zhuanlan.zhihu.com图标kimmking：微服务架构设计中如何把握「微」度，需要考虑哪几方面因素？?

zhuanlan.zhihu.com图标kimmking：梁桂钊《颠覆微服务认知：深入思考微服务的七个主流观点》?

zhuanlan.zhihu.com图标

如果想要在实际项目中更好的实践微服务架构，可以参考Gitchat上的万字长文《微服务架构深度解析与最佳实践》：

微服务架构深度解析与最佳实践?

gitbook.cn图标

微服务架构的概念，现在对于大家应该都不陌生，无论使用 Apache Dubbo、还是 Spring Cloud，都可以去尝试微服务，把复杂而庞大的业务系统拆分成一些更小粒度且独立部署的 Rest 服务。但是这个过程，具体应该怎么做？现有的条件下到底要不要做微服务？服务拆分成什么粒度才是合适的？遗留的老系统需要如何考虑重构改造？有哪些坑需要我们注意？系统怎么在分散式服务下实现数据的一致性和服务的高可用可伸缩？拆分的过程中系统数量增多，测试、部署、运维、监控，又应该如何处理？

本文将从这些问题的深度分析出发，阐述微服务架构落地的一些设计原则和利弊取舍，结合微服务架构过程的很多最佳实践经验，希望给读者带来一定的启发和思考，避免在实际应用过程中走弯路，能够多快好省的落地实现微服务架构。内容涉及：微服务架构的发展过程简介微服务架构的特点与常见特性使用微服务架构的常见技术与简单示例微服务架构存在的一些问题

如何合理拆分微服务

遗留系统应该如何改造怎么考虑拆分后的数据一致性系统和服务的高可用可伸缩如何实现拆分过程的测试和部署如何处理拆分后的运维和监控如何处理

2、什么是Dubbo

Dubbo是一个分散式服务框架，用于多个系统间的相互调用的。基于这个功能，然后衍生出服务的注册、发现，监控、路由、治理，多协议支持等等。官网首页介绍：

Apache Dubbo |?d?b??| 是一款高性能、轻量级的开源Java RPC框架，它提供了三大核心能力：面向介面的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。

简单的说，就是基于dubbo可以非常简单的、透明地在不同的系统间实现服务之间的调用，并且通过相关的工具，我们能很好的把这些东西管理起来。同时，Dubbo的中文文档，以及网上的介绍文章和分析材料，也是开源技术里最多的。

分散式服务化领域，Dubbo是国内开源技术在世界范围的一面旗帜。

Dubbo的历史可以参考下面回答的前半部分：

现在有什么好的方案替换zookeeper+ dubbo吗？?

www.zhihu.com图标

Dubbo的更多信息参考dubbo重新维护以后我的一个回复：

dubbo在Github上为什么不更新了？?

www.zhihu.com图标

3、Dubbo是不是微服务架构

通过第一部分的分析，我们知道，微服务架构，不是一个具体的框架或者类库。但是我们可以用分散式服务化的框架，结合我们的业务，用微服务架构的指导思想去实现我们的具体系统。

从这个角度来说，以下的框架都是可以选的：

Java平台的：

  • Apache Dubbo
  • Spring Cloud
  • Vert.x
  • Apache ServiceComb
  • Quarkus
  • Helidon
  • Lagom(Scala)

有些大家应该听说过，不多说。Quarkus和Helidon比较新，也很有意思，介绍参见：

如何看待RedHat开源的Quarkus微服务框架？ - kimmking的回答 - 知乎

如何看待RedHat开源的Quarkus微服务框架？?

www.zhihu.com图标

Golang的：

  • go-micro

NodeJS的：

  • seneca

等等。

框架的选择，可以参考：

为何说spring cloud适合中小型项目，而不适合大型项目？?

www.zhihu.com图标

以上。

：）

Dubbo是一个RPC框架，可以用于微服务架构实践之中。但绝不是用了Dubbo就是在做微服务了，同样的这对于Spring Cloud而言也一眼的，因为微服务架构不仅包含技术上的选择，也包含了文化、组织等多方面的变革。

具体可以看看Martin Fowler关于微服务的文章微服务（Microservices）中文版 ，附上我的笔记《微服务》九大特性重读笔记 ，仅供参考～

谢邀。

什么是Dubbo？

Dubbo 是一个分散式服务框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。简单的说，Dubbo 就是个服务框架，说白了就是个远程服务调用的分散式框架。

Dubbo 框架

模块注解：

  • Provider: 暴露服务的服务提供方。
  • Consumer: 调用远程服务的服务消费方。
  • Registry: 服务注册与发现的注册中心。
  • Monitor: 统计服务的调用次调和调用时间的监控中心。
  • Container: 服务运行容器。

流程详解：

  • 0 服务容器负责启动，载入，运行服务提供者（Standalone 容器）。
  • 1 服务提供者在启动时，向注册中心注册自己提供的服务（Zookeeper/Redis）。
  • 2 服务消费者在启动时，向注册中心订阅自己所需的服务。
  • 3 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。
  • 4 服务消费者，从提供者地址列表中，基于软负载均衡演算法，选一台提供者进行调用，如果调用失败，再选另一台调用。
  • 5 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心（根据数据可以动态调整权重）。

Dubbo 集群容错

面对服务消费方，当业务逻辑中需要调用一个服务时，真正调用的其实是 Dubbo 创建的一个 Proxy，该 Proxy 会把调用转化成调用指定的 Invoker（Cluster 将 Directory 中的多个 Invoker 伪装成一个 Invoker，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个（通过 LoadBalance），Invoker 封装了 Provider 地址及 Service 介面信息）。而在这一系列的委托调用的过程里就完成了服务治理的逻辑，最终完成调用。

Dubbo 特点

  • 远程通讯: 提供对多种基于长连接的 NIO 框架抽象封装（非阻塞 I/O 的通信方式，Mina/Netty/Grizzly），包括多种线程模型，序列化（Hessian2/ProtoBuf），以及「请求-响应」模式的信息交换方式。
  • 集群容错: 提供基于介面方法的透明远程过程调用（RPC），包括多协议支持（自定义 RPC 协议），以及软负载均衡（Random/RoundRobin），失败容错（Failover/Failback），地址路由，动态配置等集群支持。
  • 自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。

Dubbo 发展历程

  • 2008 年，阿里巴巴开始内部使用 Dubbo。
  • 2009 年初，发布 1.0 版本。
  • 2010 年初，发布 2.0 版本。
  • 2011 年 10 月，阿里巴巴宣布开源，版本为 2.0.7。
  • 2012 年 3 月，发布 2.1.0 版本。
  • 2013 年 3 月，发布 2.4.10 版本。
  • 2014 年 10 月，发布 2.3.11 版本，之后版本停滞。
  • 2017 年 9 月，阿里巴巴重启维护，重点升级所依赖 JDK 及组件版本，发布 2.5.4/5 版本。
  • 2017 年 10 月，发布 2.5.6 版本。
  • 2017 年 11 月，发布 2.5.7 版本，后期集成 Spring Boot。
  • 2014 年 10 月，当当网 Fork 了 Dubbo 版本，命名为 Dubbox-2.8.0，并支持 HTTP REST 协议。

Dubbo 负责人说明（重启维护是接受的采访）：

阿里内部使用 HSF，原因业务属性和规模有关。

这里就不得不提到目前的一些文章在谈到微服务的时候总是拿 Spring Cloud 和 Dubbo 来对比，需要强调的是 Dubbo 未来的定位并不是要成为一个微服务的全面解决方案，而是专注在 RPC 领域，成为微服务生态体系中的一个重要组件。至于大家关注的微服务化衍生出的服务治理需求，我们会在 Dubbo 积极适配开源解决方案，甚至启动独立的开源项目予以支持。受众主要来自国内各友商以及个人开发者，希望将来能够将用户拓展到全球，代表国人在 RPC 领域与 gRPC（基于 HTTP 2.0）、Finagle 等竞争。

Dubbo 一些优点

  • Dubbo 支持 RPC 调用，服务之间的调用性能会很好。
  • 支持多种序列化协议，如 Hessian、HTTP、WebService。
  • Dobbo Admin后台管理功能强大，提供了路由规则、动态配置、访问控制、权重调节、均衡负载等功能。
  • 在国内影响力比较大，中文社区文档较为全面。
  • 阿里最近重启维护。

Dubbo 一些问题

  • Registry 严重依赖第三方组件（zookeeper 或者 redis），当这些组件出现问题时，服务调用很快就会中断。
  • Dubbo 只支持 RPC 调用。使得服务提供方（抽象介面）与调用方在代码上产生了强依赖，服务提供者需要不断将包含抽象介面的 jar 包打包出来供消费者使用。一旦打包出现问题，就会导致服务调用出错，并且以后发布部署会成很大问题（太强的依赖关系）。
  • 另外，以后要兼容 .NET Core 服务，Dubbo RPC 本身不支持跨语言（可以用跨语言 RPC 框架解决，比如 Thrift、gRPC（重复封装了），或者自己再包一层 REST 服务，提供跨平台的服务调用实现，但相对麻烦很多）
  • Dubbo 只是实现了服务治理，其他微服务框架并未包含，如果需要使用，需要结合第三方框架实现（比如分散式配置用淘宝的 Diamond、服务跟踪用京东的 Hydra，但使用相对麻烦些），开发成本较高，且风险较大。
  • 社区更新不及时（虽然最近在疯狂更新），但也难免阿里以后又不更新了，就尴尬了。
  • 主要是国内公司使用，但阿里内部使用 HSF，相对于 Spring Cloud，企业应用会差一些。

所以dubbo也算是微服务架构。

来源：博客园

作者：田园里的蟋蟀

原文：Java 微服务框架选型（Dubbo 和 Spring Cloud？）

发布于 2020-02-24继续浏览内容知乎发现更大的世界打开Chrome继续王者王者程序猿

这么说吧，dubbo可以是微服务的一部分，但不能以偏概全说dubbo就是微服务，微服务涉及的面比较广，比如服务发现，服务治理，服务网关，服务监控，链路追踪等等，可以用到的组件也比较多，而dubbo最多只能说是专注于服务治理的组件，所以从这一点上来看，可替代它的技术也是相当之多的，比如一系列rpc框架都可以

这么说吧，dubbo可以是微服务的一部分，但不能以偏概全说dubbo就是微服务，微服务涉及的面比较广，比如服务发现，服务治理，服务网关，服务监控，链路追踪等等，可以用到的组件也比较多，而dubbo最多只能说是专注于服务治理的组件，所以从这一点上来看，可替代它的技术也是相当之多的，比如一系列rpc框架都可以

不是 微服务架构的范围有点广 dubbo只不过是个RPC框架 提供了一种微服务中的通信及服务发现的功能

不是，他是RPC框架，要想构建微服务框架需要在dubbo基础上进行扩展。

推荐阅读：
相关文章