dubbo 的前世今生
本文已收录 https://github.com/lkxiaolou/lkxiaolou 欢迎 star。
背景
在很久以前，网站应用是单体应用的架构，流量小，所有功能、代码都部署在一起，成本低。此时数据库访问框架 ORM 是关键。
后来流量逐渐增大，单体应用被拆分为互不相干的多个应用，这就是垂直架构，此时加速前端页面开发的 Web 框架 MVC 是关键。
再后来，垂直应用越来越大，应用间的交互不可避免，分布式服务框架 RPC 变成了关键。
dubbo
RPC，全称 Remote Procedure Call，即远程过程调用，一句话描述就是调用远程对象就像调用本地方法一样方便简单。常见的 RPC 框架有 dubbo、grpc、thrift 等。
dubbo， |ˈdʌbəʊ| 是一款高性能、轻量级的开源 Java RPC 框架，它提供了三大核心能力：面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。目前使用 dubbo 的公司非常多。
前世今生
dubbo 的发展历程可以总结为 3 个阶段：
诞生阿里：dubbo 前生 2008 年在阿里内部诞生，2011 年开源，2012 年发布 2.5.3 版本后停止更新
当当续命：2014 年当当发布 dubbox，是基于阿里开源的 dubbo 2.5.3 版本增加 rest 协议的 dubbo 版本
重启登顶 apache：2017 年阿里重启 dubbo 项目，并于 2018 年进入 apache 孵化，2019 年成为 apache 顶级项目，同时也发布了 dubbo.js，dubbo-go 等多语言 dubbo 版本，2020 年发布 3.0 往云原生项目发展的战略计划
目前支持的版本主要是 2.6.x 和 2.7.x：
2.6.x 主要以 bugfix 和少量 enhancements 为主，因此能完全保证稳定性
2.7.x 作为社区的主要开发版本，得到持续更新并增加了大量新 feature 和优化，同时也带来了一些稳定性挑战
协议
dubbo 原生的协议定义如下：
0-15: 魔数，判断是否是 dubbo 协议
16: 判断是请求还是返回
17: 判断是否期望返回
18: 判断是否为事件消息，如心跳事件
19-23: 序列化标志
24-31: 标志响应状态（类似 http status）
32-63: 请求 id
64-95: 内容长度（字节）
96-?: 序列化后的内容（换行符分隔）
dubbo 协议的优点是设计紧凑、请求响应的 header 一致；缺点是无法通过 header 定位资源，header 和 body 中字段存在冗余，协议无法扩展。
当然同时也支持扩展多种协议，如当当扩展的 rest 协议，还有最新支持的 grpc 协议等
说到扩展，可能是 dubbo 设计的最大亮点，dubbo 的扩展基于 SPI（Service Provide Interface）设计，可以无侵入代码实现非常多的功能。
注册中心
注册中心有如下特点：
动态加入，服务提供者通过注册中心动态的把自己暴露给消费者，无需消费者逐个更新配置文件。
动态发现服务，消费者可以动态发现新的服务，无需重启生效。
统一配置，避免本地配置导致每个服务配置不一致。
动态调整，注册中心支持参数动态调整，新参数自动更新到所有相关的服务节点。
统一管理，依靠注册中心数据，可以统一管理配置服务节点。dubbo 主流的注册中心一般用 zookeeper 或者 nacos，其他还有很多扩展实现。
集群
集群包含了路由、负载均衡和集群容错三个内容，从一个例子来看这三方面的差异：
一个 dubbo 的用户服务，在北京部署了 10 个，在上海部署了 20 个。一个杭州的服务消费方发起了一次调用，然后发生了以下的事情:
根据配置的路由规则，如果杭州发起的调用，会路由到比较近的上海的 20 个 provider。
根据配置的随机负载均衡策略，在 20 个 provider 中随机选择了一个来调用
假设随机到了第 7 个 provider。结果调用第 7 个 provider 失败了。根据配置的 failover 集群容错模式，重试其他服务器。重试了第 13 个 provider，调用成功。这里 1 对应了路由，2 对应了负载均衡，3 对应了集群容错。
filter
在 dubbo 的整体设计中，filter 是一个很重要的概念，包括 dubbo 本身的大多数功能，都是基于此扩展点实现的，在每次的调用过程中，filter 的拦截都会被执行。filter 是一种责任链的设计模式：
常见的 filter：监控打点、日志记录、限流降级、鉴权等。
三大中心
三大中心指注册中心，元数据中心，配置中心。为什么需要三大中心，可以看一条 dubbo 注册到注册中心上的数据：
可以看出数据量很大，这还是接口级的数据，当接口数量越来越多，注册中心的压力越来越大，变更推送的数据越来越多。
所以，我们需要元数据中心和配置中心来减轻注册中心的压力。不经常变化的数据可以放在元数据中心。
配置中心也是如此，如果没有配置中心需要全量将变更的 url 推送下去，有了配置中心只需要推送变更的配置即可。
泛化调用
我们常见的 dubbo 调用方式是引入 provider 定义的接口 jar 包，但如果没有这个 jar 包，能否发起调用？当然是可以，也确实有这样的场景，比如服务测试平台，dubbo 服务网关等。只要知道接口名，参数等信息即可发起调用。
未来发展
dubbo 当时的未来规划其实走了个曲线，并不是一步到现在的云原生方向。2019 年想走的方向是响应式编程（或者叫反应式编程）。IO 密集型的应用，通常线程池是限制吞吐的重要因素之一，假设 consumer 线程池为 100，provider 接口响应时间为 500ms，consumer 的 qps 上限为 (1000 / 500) x 100 = 200。响应式编程就是解决这个问题。
响应式编程（reactive programming）是一种基于数据流（data stream）和变化传递（propagation of change）的声明式（declarative）的编程范式。RSocket 是一个支持 reactive-stream 语义的开源网络通信协议，它将 reactive 语义的复杂逻辑封装了起来，使得上层可以方便实现网络程序。Dubbo 在 3.0.0-SNAPSHOT 版本里基于 RSocket 对响应式编程提供了支持，用户可以在请求参数和返回值里使用 Mono 和 Flux 类型的对象。
但到了 2020 年，随着云原生概念的兴起和大厂纷纷地落地，dubbo 是否也可以朝这个方向发展呢？
云原生是基于容器、服务网格、微服务、不可变基础设施和声明式 API 构建的可弹性扩展的应用，基于自动化技术构建具备高容错性、易管理和便于观察的松耦合系统，构建一个统一的开源云技术生态，能和云厂商提供的服务解耦。
dubbo 的服务级注册发现，与 k8s 容器编排的应用级服务发现相违背，dubbo 是“重 sdk”，与易管理相违背。
所以在最新的版本中支持了应用级的服务发现，原先是这样的一个接口：
使用应用级服务发现注册到注册中心上是这样
而重 sdk，未来可能会被 mesh 改善，据说阿里内部已经有 dubbo mesh 落地的业务线了。
搜索关注微信公众号"捉虫大师"，后端技术分享，架构设计、性能优化、源码阅读、问题排查、踩坑实践。
版权声明: 本文为 InfoQ 作者【捉虫大师】的原创文章。
原文链接:【http://xie.infoq.cn/article/571b27e40dd39eafba1f6b97d】。文章转载请联系作者。
还未添加个人签名 2018.09.19 加入
欢迎关注我的公众号“捉虫大师”
评论