概述交友项目的服务拆分完成后第一个绕不开的问题就是应用层要调域服务的业务方法走 HTTP 还是走 RPC。这一课就是为回答它准备的。铺垫了 HTTP 与 RPC 的差别之后把 Dubbo 从诞生、入门、高级特性到 SpringCloud 整合整条线串起来最后落到项目工程里那几个tanhua-dubbo-*模块上。纲要为什么拆完微服务还得学 DubboRPC 与 HTTP 的实际差距以及两者在生产里的组合形态Dubbo 前置课的知识地图认识 Dubbo → 快速入门 → 高级特性 → SpringCloud 整合每一段解决什么问题、学完能做什么、涉及哪些注解与配置项关键注解与配置速查表暴露服务 / 引用服务 / 注册中心 / 协议 / 质量保障学习路径哪些必须动手跑通哪些可以先理解后补与项目项目的衔接tanhua-dubbo-db/tanhua-dubbo-mongo怎样把业务能力暴露给应用层下一篇的入口拆完微服务为什么还要学 Dubbo服务拆分之后一个工程被切成若干独立进程服务之间怎么调用立刻成了必须解决的问题。SpringCloud 那套给的是 HTTP 方案RestTemplate直接发请求或者用 Feign 声明式调用。能跑通为什么还要引入 Dubbo先看历史脉络。软件架构从单体演进到微服务中间还夹着一层过渡形态——分布式 SOA 架构。做法是把单体里核心的功能单元抽出来通过 RPC 远程调用。SOA 与微服务最大的分水岭就在通信协议微服务走 REST API本质是 HTTPSOA 走 RPC基于 TCP。Dubbo 正是 SOA 思路下的服务治理组件。那今天为什么还要用它两个现实理由。性能与契约。RPC 用二进制序列化加长连接复用省掉了 HTTP 每次请求的报文头和三次握手往返接口契约走共享 api 模块提供者和消费者编译的是同一份接口字段对不上编译期就报错而不是等联调时才发现 JSON 少了一个字段。超时、重试、多版本、负载均衡策略这些治理项Dubbo 都在框架层给了配置入口。组合使用是常态。课程最后专门讲了 SpringCloud 整合 Dubbo用 SpringCloud 的注册与治理体系承载 Dubbo 的 RPC 调用。也就是说它并不站在 SpringCloud 的对立面而是作为其中一环存在——加入 Dubbo 的主要目的就是替换 Feign把相对低效的 HTTP 通信换成 RPC。维度HTTPRestTemplate / FeignRPCDubbo传输协议HTTP/1.1文本报文头基于 TCP 的 Dubbo 协议自定义二进制协议序列化JSON 为主可读性好、体积大Hessian2 等二进制序列化体积小连接短连接为主可配连接池长连接复用省握手开销接口契约靠文档或 OpenAPI运行期才暴露不一致共享 api 模块编译期校验服务治理依赖 SpringCloud 组件补齐超时 / 重试 / 多版本 / 负载均衡框架内置适用场景对外 API、跨语言、调试友好内部服务间高频调用、追求吞吐两者不是二选一。项目项目里应用层对域服务走 Dubbo对外接口仍是 HTTP各取所长。Dubbo 前置课的知识地图整门前置课是四段递进后一段都建立在前一段跑通的基础上。① 认识 Dubbo前世今生 RPC 概念② 快速入门搭环境 写一对 Provider/Consumer③ 高级特性启动检查 / 超时重试 / 多版本 / 负载均衡④ SpringCloud 整合 Dubbo用云原生注册体系承载 RPC解决Dubbo 是什么、和 HTTP 差在哪解决一个调用怎么跑起来学完能独立搭起最小可运行工程解决生产环境怎么配学完能调参、能定位雪崩解决已有 SpringCloud 项目怎么平滑接入 RPC认识 DubboDubbo 于 2011 年由阿里巴巴开源是国内服务治理与 SOA 理念落地的核心框架后来捐给 Apache 基金会。这一节要建立三个概念RPC 是什么、Dubbo 的四个角色Provider / Consumer / Registry / Monitor各干什么、以及它和 SpringCloud 的关系。后面所有配置都能挂到这套角色模型上理解。快速入门这一段的产出是一个能跑起来的最小工程装好 Nacos 注册中心和 dubbo-admin 控制台写一个服务提供者实现并暴露接口再写一个服务消费者引用并调用。走通之后做代码优化——把接口抽到公共的user-api模块让双方共享同一份契约再处理序列化。调用链路上Provider 启动时把服务注册到 NacosConsumer 启动时订阅并拿到地址列表之后基于软负载均衡直接选一台调用。ConsumerRegistryNacosProviderConsumerRegistryNacosProvider调用失败换另一台提供者重试启动时注册自己提供的服务启动时订阅自己需要的服务返回提供者地址列表变更时长连接推送基于负载均衡算法发起 RPC 调用高级特性入门跑通只能算能用这段讲的是敢不敢上线。四个特性都是围绕稳定性展开的超时与重试消费者永久等待会拖干线程池超时timeout默认 1000ms让线程及时归还重试retries默认 2用来兜住网络抖动但要求接口幂等。启动检查默认启动时校验依赖服务是否可用不可用直接抛异常。生产环境该开开发时没有提供者反而碍事用checkfalse关掉。多版本灰度发布场景下让新版本UserServiceImpl2只服务一部分用户通过version区分。负载均衡集群部署时从 Random / RoundRobin / LeastActive / ConsistentHash 四种策略里选。SpringCloud 整合 Dubbo最后一段回答已经有 SpringCloud 项目怎么加 Dubbo。核心改动是把远程调用从 Feign 换成 Dubbo抽出dubbo-api接口模块提供者与消费者分别引入 Nacos 注册中心与 Dubbo 依赖注册中心地址从nacos://...改成spring-cloud://localhost表示复用 SpringCloud 的注册中心。关键注解与配置速查表后续每篇都会用到这几组配置先按用途归档方便回过头来查。用途注解 / 配置项位置说明暴露服务DubboService提供者实现类声明这是一个要被远程调用的服务实现引用服务DubboReference消费者字段注入远程服务的代理对象协议与端口dubbo.protocol.name/dubbo.protocol.port提供者 yml默认协议dubbo示例端口20881注册中心独立dubbo.registry.address: nacos://127.0.0.1:8848双方 yml直连 Nacos注册中心整合dubbo.registry.address: spring-cloud://localhost双方 yml复用 SpringCloud 注册中心包扫描dubbo.scan.base-packages提供者 yml扫描DubboService所在包超时timeout消费者 yml / 注解单位毫秒默认 1000重试retries消费者 yml / 注解默认 2非幂等接口设 0启动检查check消费者 yml / 注解开发期设false多版本version提供者与消费者灰度发布时对齐版本号负载均衡loadbalance消费者注解Random默认/RoundRobin/LeastActive/ConsistentHash学习路径按必须动手跑通和可以先理解后补分两拨推进。必须跑通的是能被验证的东西装 Nacosstartup.cmd -m standalone访问127.0.0.1:8848/nacos和 dubbo-admin 控制台。写一对 Provider / Consumer在 dubbo-admin 里观察服务是否注册成功、消费者能否拿到地址列表。故意把提供者方法改成Thread.sleep(5000)把消费者timeout调到 1000看超时异常长什么样再把retries打开观察重试行为。这一步不做后面的超时配置永远只是背下来的。可以先理解后补的是那些不改代码也看不出差别的东西多版本灰度、负载均衡策略的选择理解语义即可等真正做灰度发布时再回来细调。SpringCloud 整合的细节spring-cloud://localhost的含义、依赖坐标先知道有这么回事进项目后自然会对上。与项目项目的关系前置课不是孤立的语法练习它的服务对象就是接下来的交友项目项目。项目的工程里业务能力被放进独立的 Dubbo 域服务模块由应用层远程调用tanhua ├── tanhua-app-server # 应用层面向接口的 HTTP 入口通过 Dubbo 引用域服务 ├── tanhua-dubbo │ ├── tanhua-dubbo-db # 基于 MySQL 的域服务负责用户、动态等数据 │ ├── tanhua-dubbo-mongo # 基于 MongoDB 的域服务负责圈子、评论等文档数据 │ └── tanhua-dubbo-interface # 共享接口模块Provider 与 Consumer 的契约所在 ├── tanhua-model # 实体类 ├── tanhua-commons # 公共工具 └── tanhua-autoconfig # 自动配置应用层的application.yml引用这些服务时用的就是前置课里的那套配置dubbo:#dubbo配置registry:address:spring-cloud://localhost# 复用 SpringCloud 的注册中心consumer:check:false# 开发期关闭启动检查而域服务模块负责暴露能力dubbo:protocol:name:dubboport:20881registry:address:spring-cloud://localhostscan:base-packages:com.tanhua.dubbo.api# 扫描 DubboService 实现对照一下就很清楚spring-cloud://localhost正是整合那一节的内容check: false是启动检查那一节的内容scan.base-packages是入门案例那一节的内容。前置课里每一个配置项在项目工程里都有对应的落点。理解了这层关系学 Dubbo 就不是在背配置而是在为看懂项目铺路。官方文档Apache Dubbo 官网Nacos 官网Dubbo Admin 仓库总结几个要点收一下。HTTP 能解决服务调用但 RPC 在性能、契约严谨度和治理能力上更贴合内部高频调用而且常和 SpringCloud 组合出现——这是学 Dubbo 的现实理由。前置课的知识地图是四段式认识 Dubbo 建立概念模型快速入门跑通最小工程并抽取公共接口高级特性解决生产可用性SpringCloud 整合回答存量项目怎么接入。四段层层递进跳着看会断线。学习上别只读不跑。装 Nacos、写一对 Provider/Consumer、改超时和重试看现象这三件事的收益远大于把配置表背下来。多版本和整合细节属于用到再补。最后落到项目上——项目的tanhua-dubbo-db/tanhua-dubbo-mongo就是用 Dubbo 暴露业务能力的前置课的配置在工程里处处可见。把它当成为项目做的准备而不是一节独立的框架语法课。下一篇按讲义顺序进入Dubbo 简介先把 Dubbo 的内部结构和它在分布式调用里的定位讲透。