dubbo的前世今生
背景
在很久以前，網(wǎng)站應(yīng)用是單體應(yīng)用的架構(gòu)，流量小，所有功能、代碼都部署在一起，成本低。此時(shí)數(shù)據(jù)庫訪問框架ORM是關(guān)鍵。
后來流量逐漸增大，單體應(yīng)用被拆分為互不相干的多個(gè)應(yīng)用，這就是垂直架構(gòu)，此時(shí)加速前端頁面開發(fā)的Web框架MVC是關(guān)鍵。
再后來，垂直應(yīng)用越來越大，應(yīng)用間的交互不可避免，分布式服務(wù)框架RPC變成了關(guān)鍵。
dubbo
RPC，全稱Remote Procedure Call，即遠(yuǎn)程過程調(diào)用，一句話描述就是調(diào)用遠(yuǎn)程對象就像調(diào)用本地方法一樣方便簡單。常見的RPC框架有dubbo、grpc、thrift等。
dubbo， |?d?b??| 是一款高性能、輕量級的開源Java RPC框架，它提供了三大核心能力：面向接口的遠(yuǎn)程方法調(diào)用，智能容錯(cuò)和負(fù)載均衡，以及服務(wù)自動(dòng)注冊和發(fā)現(xiàn)。目前使用dubbo的公司非常多。
前世今生
dubbo的發(fā)展歷程可以總結(jié)為3個(gè)階段：
誕生阿里：dubbo前生2008年在阿里內(nèi)部誕生，2011年開源，2012年發(fā)布2.5.3版本后停止更新 當(dāng)當(dāng)續(xù)命：2014年當(dāng)當(dāng)發(fā)布dubbox，是基于阿里開源的dubbo 2.5.3版本增加rest協(xié)議的dubbo版本 重啟登頂apache：2017年阿里重啟dubbo項(xiàng)目，并于2018年進(jìn)入apache孵化，2019年成為apache頂級項(xiàng)目，同時(shí)也發(fā)布了dubbo.js，dubbo-go等多語言dubbo版本，2020年發(fā)布3.0往云原生項(xiàng)目發(fā)展的戰(zhàn)略計(jì)劃
目前支持的版本主要是2.6.x和2.7.x：
2.6.x 主要以 bugfix 和少量 enhancements 為主，因此能完全保證穩(wěn)定性 2.7.x 作為社區(qū)的主要開發(fā)版本，得到持續(xù)更新并增加了大量新 feature 和優(yōu)化，同時(shí)也帶來了一些穩(wěn)定性挑戰(zhàn)
特性概覽
協(xié)議
dubbo原生的協(xié)議定義如下：
0-15: 魔數(shù)，判斷是否是dubbo協(xié)議 16: 判斷是請求還是返回 17: 判斷是否期望返回 18: 判斷是否為事件消息，如心跳事件 19-23: 序列化標(biāo)志 24-31: 標(biāo)志響應(yīng)狀態(tài)（類似http status） 32-63: 請求id 64-95: 內(nèi)容長度（字節(jié)） 96-?: 序列化后的內(nèi)容（換行符分隔）
dubbo協(xié)議的優(yōu)點(diǎn)是設(shè)計(jì)緊湊、請求響應(yīng)的header一致；缺點(diǎn)是無法通過header定位資源，header和body中字段存在冗余，協(xié)議無法擴(kuò)展。
當(dāng)然同時(shí)也支持?jǐn)U展多種協(xié)議，如當(dāng)當(dāng)擴(kuò)展的rest協(xié)議，還有最新支持的grpc協(xié)議等
說到擴(kuò)展，可能是dubbo設(shè)計(jì)的最大亮點(diǎn)，dubbo的擴(kuò)展基于SPI（Service Provide Interface）設(shè)計(jì)，可以無侵入代碼實(shí)現(xiàn)非常多的功能。
注冊中心
注冊中心有如下特點(diǎn)：
動(dòng)態(tài)加入，服務(wù)提供者通過注冊中心動(dòng)態(tài)的把自己暴露給消費(fèi)者，無需消費(fèi)者逐個(gè)更新配置文件。 動(dòng)態(tài)發(fā)現(xiàn)服務(wù)，消費(fèi)者可以動(dòng)態(tài)發(fā)現(xiàn)新的服務(wù)，無需重啟生效。 統(tǒng)一配置，避免本地配置導(dǎo)致每個(gè)服務(wù)配置不一致。 動(dòng)態(tài)調(diào)整，注冊中心支持參數(shù)動(dòng)態(tài)調(diào)整，新參數(shù)自動(dòng)更新到所有相關(guān)的服務(wù)節(jié)點(diǎn)。 統(tǒng)一管理，依靠注冊中心數(shù)據(jù)，可以統(tǒng)一管理配置服務(wù)節(jié)點(diǎn)。dubbo主流的注冊中心一般用zookeeper或者nacos，其他還有很多擴(kuò)展實(shí)現(xiàn)。
集群
集群包含了路由、負(fù)載均衡和集群容錯(cuò)三個(gè)內(nèi)容，從一個(gè)例子來看這三方面的差異：
一個(gè)dubbo的用戶服務(wù)，在北京部署了10個(gè)，在上海部署了20個(gè)。一個(gè)杭州的服務(wù)消費(fèi)方發(fā)起了一次調(diào)用，然后發(fā)生了以下的事情:
根據(jù)配置的路由規(guī)則，如果杭州發(fā)起的調(diào)用，會(huì)路由到比較近的上海的20個(gè)provider。 根據(jù)配置的隨機(jī)負(fù)載均衡策略，在20個(gè)provider中隨機(jī)選擇了一個(gè)來調(diào)用 假設(shè)隨機(jī)到了第7個(gè)provider。結(jié)果調(diào)用第7個(gè) provider 失敗了。根據(jù)配置的failover集群容錯(cuò)模式，重試其他服務(wù)器。重試了第13個(gè)provider，調(diào)用成功。
這里1對應(yīng)了路由，2對應(yīng)了負(fù)載均衡，3對應(yīng)了集群容錯(cuò)。
filter
在dubbo的整體設(shè)計(jì)中，filter是一個(gè)很重要的概念，包括dubbo本身的大多數(shù)功能，都是基于此擴(kuò)展點(diǎn)實(shí)現(xiàn)的，在每次的調(diào)用過程中，filter的攔截都會(huì)被執(zhí)行。filter是一種責(zé)任鏈的設(shè)計(jì)模式：
常見的filter：監(jiān)控打點(diǎn)、日志記錄、限流降級、鑒權(quán)等。
三大中心
三大中心指注冊中心，元數(shù)據(jù)中心，配置中心。為什么需要三大中心，可以看一條dubbo注冊到注冊中心上的數(shù)據(jù)：
/dubbo/org.apache.dubbo.demo.DemoService/providers/dubbo%3A%2F%2F172.23.234.48%3A20880%2Forg.apache.dubbo.demo.DemoService%3Fanyhost%3Dtrue%26application%3Ddubbo-demo-api-provider%26default%3Dtrue%26deprecated%3Dfalse%26dubbo%3D2.0.2%26dynamic%3Dtrue%26generic%3Dfalse%26interface%3Dorg.apache.dubbo.demo.DemoService%26metadata-type%3Dremote%26methods%3DsayHello%2CsayHelloAsync%26pid%3D21563%26release%3D%26side%3Dprovider%26timestamp%3D1600336623852
可以看出數(shù)據(jù)量很大，這還是接口級的數(shù)據(jù)，當(dāng)接口數(shù)量越來越多，注冊中心的壓力越來越大，變更推送的數(shù)據(jù)越來越多。
所以，我們需要元數(shù)據(jù)中心和配置中心來減輕注冊中心的壓力。不經(jīng)常變化的數(shù)據(jù)可以放在元數(shù)據(jù)中心。上述注冊數(shù)據(jù)拆分之后：
/dubbo/org.apache.dubbo.demo.DemoService/providers/dubbo%3A%2F%2F172.23.234.48%3A20880%2Forg.apache.dubbo.demo.DemoService%3Fapplication%3Ddubbo-demo-api-provider%26deprecated%3Dfalse%26dubbo%3D2.0.2%26timestamp%3D1600336144382
配置中心也是如此，如果沒有配置中心需要全量將變更的url推送下去，有了配置中心只需要推送變更的配置即可。
泛化調(diào)用
我們常見的dubbo調(diào)用方式是引入provider定義的接口jar包，但如果沒有這個(gè)jar包，能否發(fā)起調(diào)用？當(dāng)然是可以，也確實(shí)有這樣的場景，比如服務(wù)測試平臺，dubbo服務(wù)網(wǎng)關(guān)等。只要知道接口名，參數(shù)等信息即可發(fā)起調(diào)用。
未來發(fā)展
dubbo當(dāng)時(shí)的未來規(guī)劃其實(shí)走了個(gè)曲線，并不是一步到現(xiàn)在的云原生方向。2019年想走的方向是響應(yīng)式編程（或者叫反應(yīng)式編程）。IO密集型的應(yīng)用，通常線程池是限制吞吐的重要因素之一，假設(shè)consumer線程池為100，provider接口響應(yīng)時(shí)間為500ms，consumer的qps上限為 (1000 / 500) x 100 = 200。響應(yīng)式編程就是解決這個(gè)問題。
響應(yīng)式編程（reactive programming）是一種基于數(shù)據(jù)流（data stream）和變化傳遞（propagation of change）的聲明式（declarative）的編程范式。RSocket 是一個(gè)支持 reactive-stream 語義的開源網(wǎng)絡(luò)通信協(xié)議，它將 reactive 語義的復(fù)雜邏輯封裝了起來，使得上層可以方便實(shí)現(xiàn)網(wǎng)絡(luò)程序。Dubbo 在 3.0.0-SNAPSHOT 版本里基于 RSocket 對響應(yīng)式編程提供了支持，用戶可以在請求參數(shù)和返回值里使用Mono和Flux類型的對象。
但到了2020年，隨著云原生概念的興起和大廠紛紛地落地，dubbo是否也可以朝這個(gè)方向發(fā)展呢？
云原生是基于容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式API構(gòu)建的可彈性擴(kuò)展的應(yīng)用，基于自動(dòng)化技術(shù)構(gòu)建具備高容錯(cuò)性、易管理和便于觀察的松耦合系統(tǒng)，構(gòu)建一個(gè)統(tǒng)一的開源云技術(shù)生態(tài)，能和云廠商提供的服務(wù)解耦。
dubbo的服務(wù)級注冊發(fā)現(xiàn)，與k8s容器編排的應(yīng)用級服務(wù)發(fā)現(xiàn)相違背，dubbo是“重sdk”，與易管理相違背。
所以在最新的版本中支持了應(yīng)用級的服務(wù)發(fā)現(xiàn)，原先是這樣的一個(gè)接口：
/dubbo/org.apache.dubbo.demo.DemoService/providers/dubbo%3A%2F%2F172.23.234.48%3A20880%2Forg.apache.dubbo.demo.DemoService%3Fapplication%3Ddubbo-demo-api-provider%26deprecated%3Dfalse%26dubbo%3D2.0.2%26timestamp%3D1600336144382
使用應(yīng)用級服務(wù)發(fā)現(xiàn)注冊到注冊中心上是這樣
/services/dubbo-demo-api-provider/172.23.234.48:20880
而重sdk，未來可能會(huì)被mesh改善，據(jù)說阿里內(nèi)部已經(jīng)有dubbo mesh落地的業(yè)務(wù)線了。
推薦閱讀：
歡迎關(guān)注微信公眾號：互聯(lián)網(wǎng)全棧架構(gòu)，收取更多有價(jià)值的信息。