配置dubbo緩存文件怎麼打開

❶ bbo是如何啟動的

已知，在項目啟動過程中，我們會將bbo的配置文件寫到spring的配置文件里，如下xml文件：

<bbo:application name="anyname_provider" />
<!-- 使用zookeeper注冊中心暴露服務地址 -->
<bbo:registry address="zookeeper://127.0.0.1:2181" />
<!-- 用bbo協議在20880埠暴露服務 -->
<bbo:protocol name="bbo" port="20880" />
<!-- 聲明需要暴露的服務介面 -->
<bbo:service interface="com.shxz130.provider.Provider"
ref="demoService" />

從官方文檔中，我們能看到如下：

啟動過程.png

也就是說spring啟動過程中，隨著Spring在初始化過程中，碰到bbo命名的標簽，如（<bbo:service>,<bbo:registry>）等標簽，會由DubboNamespaceHandler類處理，具體原理見鏈接Spring自定義標簽

DubboBeanDefinitionParser代碼如下：

public class DubboNamespaceHandler extends NamespaceHandlerSupport { static {
Version.checkDuplicate(DubboNamespaceHandler.class);
} public void init() {
registerBeanDefinitionParser("application", new DubboBeanDefinitionParser(ApplicationConfig.class, true));
registerBeanDefinitionParser("mole", new DubboBeanDefinitionParser(MoleConfig.class, true));
registerBeanDefinitionParser("registry", new DubboBeanDefinitionParser(RegistryConfig.class, true));
registerBeanDefinitionParser("monitor", new DubboBeanDefinitionParser(MonitorConfig.class, true));
registerBeanDefinitionParser("provider", new DubboBeanDefinitionParser(ProviderConfig.class, true));
registerBeanDefinitionParser("consumer", new DubboBeanDefinitionParser(ConsumerConfig.class, true));
registerBeanDefinitionParser("protocol", new DubboBeanDefinitionParser(ProtocolConfig.class, true));
registerBeanDefinitionParser("service", new DubboBeanDefinitionParser(ServiceBean.class, true));
registerBeanDefinitionParser("reference", new DubboBeanDefinitionParser(ReferenceBean.class, false));
registerBeanDefinitionParser("annotation", new ());
}
}

遇到不同的標簽，會由不同的Parser處理，這里重點看服務發布，這行代碼：

registerBeanDefinitionParser("service", new DubboBeanDefinitionParser(ServiceBean.class, true));

也就是說，當Spring容器處理完<bbo:service>標簽後，會在Spring容器中生成一個ServiceBean ，服務的發布也會在ServiceBean中完成。不妨看一下ServiceBean的定義：

public class ServiceBean<T> extends ServiceConfig<T> implements InitializingBean, DisposableBean, ApplicationContextAware, ApplicationListener<ContextRefreshedEvent>, BeanNameAware {
}

該Bean實現了很多介面，關於InitializingBean，DisposableBean，ApplicationContextAware，BeanNameAware,這些介面的使用介紹如下鏈接：

• InitializingBean&DisposableBean

• BeanNameAware& ApplicationContextAware

而在Spring初始化完成Bean的組裝，會調用InitializingBean的afterPropertiesSet方法，在Spring容器載入完成，會接收到事件ContextRefreshedEvent，調用ApplicationListener的onApplicationEvent方法。

在afterPropertiesSet中，和onApplicationEvent中，會調用export()，在export()中，會暴露bbo服務，具體區別在於是否配置了delay屬性，是否延遲暴露，如果delay不為null，或者不為-1時，會在afterPropertiesSet中調用export()暴露bbo服務，如果為null,或者為-1時，會在Spring容器初始化完成，接收到ContextRefreshedEvent事件，調用onApplicationEvent，暴露bbo服務。

部分ServiceBean的代碼如下：

• public class ServiceBean<T> extends ServiceConfig<T> implements InitializingBean, DisposableBean, ApplicationContextAware, ApplicationListener<ContextRefreshedEvent>, BeanNameAware { //Spring容器初始化完成，調用


• public void onApplicationEvent(ContextRefreshedEvent event) { if (isDelay() && !isExported() && !isUnexported()) { if (logger.isInfoEnabled()) {


• logger.info("The service ready on spring started. service: " + getInterface());


• } //暴露服務


• export();


• }


• } //判斷是否延遲發布


• private boolean isDelay() {


• Integer delay = getDelay();


• ProviderConfig provider = getProvider(); if (delay == null && provider != null) {


• delay = provider.getDelay();


• } return supportedApplicationListener && (delay == null || delay == -1);


• } //當bean初始化完成調用


• public void afterPropertiesSet() throws Exception { //......此處省略10000行代碼


• if (!isDelay()) { //暴露服務


• export();


• }


• }


• }



在export()，暴露服務過程中，如果發現有delay屬性，則延遲delay時間，暴露服務，如果沒有，則直接暴露服務。

• public synchronized void export() { //忽略若干行代碼


• if (delay != null && delay > 0) { //當delay不為null，且大於0時，延遲delay時間，暴露服務


• delayExportExecutor.schele(new Runnable() { public void run() { //暴露服務


• doExport();


• }


• }, delay, TimeUnit.MILLISECONDS);


• } else { //直接暴露服務


• doExport();


• }


• }



而在doExport()中，驗證參數，按照不同的Protocol，比如(bbo,injvm)暴露服務，在不同的zookeeper集群節點上注冊自己的服務。

• protected synchronized void doExport() { //忽略10000行代碼


• doExportUrls(); //忽略10000行代碼


• } private void doExportUrls() {


• List<URL> registryURLs = loadRegistries(true); for (ProtocolConfig protocolConfig : protocols) { //按照不同的Protocal暴露服務


• doExportUrlsFor1Protocol(protocolConfig, registryURLs);


• }


• }





作者：一滴水的堅持
鏈接：https://www.jianshu.com/p/7f3871492c71
來源：簡書
簡書著作權歸作者所有，任何形式的轉載都請聯系作者獲得授權並註明出處。

❷ eclipse jetty啟動bbo 怎麼配置

eclipse jetty啟動

DUBBO安裝配置注意事項

管理端：

記得更改TOMCAT的埠號，不然會和監控器的8080沖突（如何部署在同一機器）

bbo.properties 文件
bbo.registry.address=zookeeper://x.x.x.x:2181
bbo.admin.root.password=用戶
bbo.admin.guest.password=密碼

=============

監控端：

bbo.properties文件

bbo.container=log4j,spring,registry,jetty
bbo.application.name=simple-monitor
bbo.application.owner=
#bbo.registry.address=multicast://224.5.6.7:1234
#bbo.registry.address=zookeeper://127.0.0.1:2181
#bbo.registry.address=redis://127.0.0.1:6379
#bbo.registry.address=bbo://127.0.0.1:9090
bbo.registry.address=zookeeper://x.x.x.x:2181
bbo.protocol.port=7070
bbo.jetty.port=8080
bbo.jetty.directory=${user.home}/monitor
bbo.charts.directory=${bbo.jetty.directory}/charts
bbo.statistics.directory=${user.home}/monitor/statistics
bbo.log4j.file=logs/bbo-monitor-simple.log
bbo.log4j.level=WARN

在安裝的時候，小嶠同學遇到了一個妖怪的問題，就是監控端可能只能在JDK1.8以上的版本才能啟動，在JDK1.7上啟動時，老是說什麼MONITOR進程已存在啟動，然後就停了。

我直接注釋相關的SHELL就搞定了。。

不知對不對。。

if [ -z "$SERVER_NAME" ]; then
SERVER_NAME=`hostname`fi#PIDS=`ps -f | grep java | grep "$CONF_DIR" |awk '{print $2}'`
#if [ -n "$PIDS" ]; then
# echo "ERROR: The $SERVER_NAME already started!"
# echo "PID: $PIDS"
# exit 1
#fiif [ -n "$SERVER_PORT" ]; then
SERVER_PORT_COUNT=`netstat -tln | grep $SERVER_PORT | wc -l` if [ $SERVER_PORT_COUNT -gt 0 ]; then
echo "ERROR: The $SERVER_NAME port $SERVER_PORT already used!"
exit 1
fifi

❸ 微服務初體驗（二）：使用Nacos作為配置中心並集成Dubbo

首先啟動Nacos，按照上篇文章的步驟，啟動Nacos服務和項目，訪問Nacos的web頁面。確保項目中的服務都注冊到注冊中心當中了。在application.yml同級目錄下添加bootstrap.yml，在Spring boot項目中bootstrap.yml會比application.yml優先初始化，所以我們需要在bootstrap.yml中引入Nacos官方指定的配置文件即可（上篇文章中已經把Nacos作為配置中心的配置寫入了application.yml，現在只需要把它從applicaiton.yml中剪切出來即可， 其中的spring:application:name會作為Nacos中新增配置時的Data ID，需要留意 ），再新增屬性gorup進行分組測試，如下圖

接著打開Nacos的服務的web頁面，打開配置管理->配置列表，點擊右側新增按鈕，進行新增。
Data ID： bootstrap.yml配置文件中spring:application:name對應的名稱 ；
Group：指定分組（便於不同環境下的項目配置管理，因為筆者這里屬於測試，所以填寫的是和上文中的配置文件中group對應的test一致）；
描述：針對於該配置的描述；
配置格式：配置文件的格式，要和Data ID中的後綴格式一致（這里筆者用的是yml，那麼下面就選擇yaml，注意該位置也可以選擇properties，但是必須和上面bootstrap.yml文件中的file-extension的值相匹配）；
配置內容：具體的配置內容（這里筆者將項目中的application.yml中的配置全部拷貝至其中）；

測試啟動consumer服務，在application.yml中為空的時候，項目啟動埠還是如Nacos配置中的9011，說明項目依賴Nacos的配置中心成功，其他服務如法炮製即可：

新增一個測試Controller，然後加上@RefreshScope註解，表明該Controller中的配置數據為自動刷新 。

編輯Nacos中的配置文件consumer新增相關參數type: test，訪問Controller，返回test。效果如下圖：

將Nacos中consumer.yml文件的type: test修改為type: prod，在不重啟項目的情況下重新訪問對應的controller，效果如下圖：

因為Dubbo是屬於各個服務之間都要公用的依賴，所以將其引入cloud-common當中，詳細的版本可以去 mvnrepository 搜索合適自己項目的

引入依賴後需要編寫消費者服務中的配置文件，將Dubbo服務注冊至Nacos，新增如下內容，其中subscribed-services指的是生產者服務，prot：-1指的是埠隨機，registry:address:指的是Dubbo對應的注冊中心那這里就應該設置為Nacos

接下來新增介面服務，項目類型為Maven項目，在項目中新增一個介面。並在cloud-provider（生產者）和cloud-consumer（消費者）pom.xml文件中都引入該模塊

在生產者實際服務中實現該介面對應的方法

在服務消費者的Controller中引入該Service，並在該Service上加入@Reference註解，注意在引入jar包的時候選擇帶有Dubbo的，不要使用Jdk原生的

編寫消費者服務中測試Dubbo調用的介面，進行測試，測試結果如下圖：

❹ Dubbo——HTTP 協議 + jsON-RPC

Protocol 還有一個實現分支是 AbstractProxyProtocol，如下圖所示：

從圖中我們可以看到：gRPC、HTTP、WebService、Hessian、Thrift 等協議對應的 Protocol 實現，都是繼承自 AbstractProxyProtocol 抽象類。

目前互聯網的技術棧百花齊放，很多公司會使用 Node.js、Python、Rails、Go 等語言來開發 一些 Web 端應用，同時又有很多服務會使用 Java 技術棧實現，這就出現了大量的跨語言調用的需求。Dubbo 作為一個 RPC 框架，自然也希望能實現這種跨語言的調用，目前 Dubbo 中使用「HTTP 協議 + JSON-RPC」的方式來達到這一目的，其中 HTTP 協議和 JSON 都是天然跨語言的標准，在各種語言中都有成熟的類庫。

下面就重點來分析 Dubbo 對 HTTP 協議的支持。首先，會介紹 JSON-RPC 的基礎，並通過一個示例，快速入門，然後介紹 Dubbo 中 HttpProtocol 的具體實現，也就是如何將 HTTP 協議與 JSON-RPC 結合使用，實現跨語言調用的效果。

Dubbo 中支持的 HTTP 協議實際上使用的是 JSON-RPC 協議。

JSON-RPC 是基於 JSON 的跨語言遠程調用協議。Dubbo 中的 bbo-rpc-xml、bbo-rpc-webservice 等模塊支持的 XML-RPC、WebService 等協議與 JSON-RPC 一樣，都是基於文本的協議，只不過 JSON 的格式比 XML、WebService 等格式更加簡潔、緊湊。與 Dubbo 協議、Hessian 協議等二進制協議相比，JSON-RPC 更便於調試和實現，可見 JSON-RPC 協議還是一款非常優秀的遠程調用協議。

在 Java 體系中，有很多成熟的 JSON-RPC 框架，例如 jsonrpc4j、jpoxy 等，其中，jsonrpc4j 本身體積小巧，使用方便，既可以獨立使用，也可以與 Spring 無縫集合，非常適合基於 Spring 的項目。

下面先來看看 JSON-RPC 協議中請求的基本格式：

JSON-RPC請求中各個欄位的含義如下：

在 JSON-RPC 的服務端收到調用請求之後，會查找到相應的方法並進行調用，然後將方法的返回值整理成如下格式，返回給客戶端：

JSON-RPC響應中各個欄位的含義如下：

Dubbo 使用 jsonrpc4j 庫來實現 JSON-RPC 協議，下面使用 jsonrpc4j 編寫一個簡單的 JSON-RPC 服務端示例程序和客戶端示常式序，並通過這兩個示常式序說明 jsonrpc4j 最基本的使用方式。

首先，需要創建服務端和客戶端都需要的 domain 類以及服務介面。先來創建一個 User 類，作為最基礎的數據對象：

接下來創建一個 UserService 介面作為服務介面，其中定義了 5 個方法，分別用來創建 User、查詢 User 以及相關信息、刪除 User：

UserServiceImpl 是 UserService 介面的實現類，其中使用一個 ArrayList 集合管理 User 對象，具體實現如下：

整個用戶管理業務的核心大致如此。下面我們來看服務端如何將 UserService 與 JSON-RPC 關聯起來。

首先，創建 RpcServlet 類，它是 HttpServlet 的子類，並覆蓋了 HttpServlet 的 service() 方法。我們知道，HttpServlet 在收到 GET 和 POST 請求的時候，最終會調用其 service() 方法進行處理；HttpServlet 還會將 HTTP 請求和響應封裝成 HttpServletRequest 和 HttpServletResponse 傳入 service() 方法之中。這里的 RpcServlet 實現之中會創建一個 JsonRpcServer，並在 service() 方法中將 HTTP 請求委託給 JsonRpcServer 進行處理：

最後，創建一個 JsonRpcServer 作為服務端的入口類，在其 main() 方法中會啟動 Jetty 作為 Web 容器，具體實現如下：

這里使用到的 web.xml 配置文件如下：

完成服務端的編寫之後，下面再繼續編寫 JSON-RPC 的客戶端。在 JsonRpcClient 中會創建 JsonRpcHttpClient，並通過 JsonRpcHttpClient 請求服務端：

在 AbstractProxyProtocol 的 export() 方法中，首先會根據 URL 檢查 exporterMap 緩存，如果查詢失敗，則會調用 ProxyFactory.getProxy() 方法將 Invoker 封裝成業務介面的代理類，然後通過子類實現的 doExport() 方法啟動底層的 ProxyProtocolServer，並初始化 serverMap 集合。具體實現如下：

在 HttpProtocol 的 doExport() 方法中，與前面介紹的 DubboProtocol 的實現類似，也要啟動一個 RemotingServer。為了適配各種 HTTP 伺服器，例如，Tomcat、Jetty 等，Dubbo 在 Transporter 層抽象出了一個 HttpServer 的介面。

bbo-remoting-http 模塊的入口是 HttpBinder 介面，它被 @SPI 註解修飾，是一個擴展介面，有三個擴展實現，默認使用的是 JettyHttpBinder 實現，如下圖所示：

HttpBinder 介面中的 bind() 方法被 @Adaptive 註解修飾，會根據 URL 的 server 參數選擇相應的 HttpBinder 擴展實現，不同 HttpBinder 實現返回相應的 HttpServer 實現。HttpServer 的繼承關系如下圖所示：

這里以 JettyHttpServer 為例簡單介紹 HttpServer 的實現，在 JettyHttpServer 中會初始化 Jetty Server，其中會配置 Jetty Server 使用到的線程池以及處理請求 Handler：

可以看到 JettyHttpServer 收到的全部請求將委託給 DispatcherServlet 這個 HttpServlet 實現，而 DispatcherServlet 的 service() 方法會把請求委託給對應接埠的 HttpHandler 處理：

了解了 Dubbo 對 HttpServer 的抽象以及 JettyHttpServer 的核心之後，回到 HttpProtocol 中的 doExport() 方法繼續分析。

在 HttpProtocol.doExport() 方法中會通過 HttpBinder 創建前面介紹的 HttpServer 對象，並記錄到 serverMap 中用來接收 HTTP 請求。這里初始化 HttpServer 以及處理請求用到的 HttpHandler 是 HttpProtocol 中的內部類，在其他使用 HTTP 協議作為基礎的 RPC 協議實現中也有類似的 HttpHandler 實現類，如下圖所示：

在 HttpProtocol.InternalHandler 中的 handle() 實現中，會將請求委託給 skeletonMap 集合中記錄的 JsonRpcServer 對象進行處理：

skeletonMap 集合中的 JsonRpcServer 是與 HttpServer 對象一同在 doExport() 方法中初始化的。最後，我們來看 HttpProtocol.doExport() 方法的實現：

介紹完 HttpProtocol 暴露服務的相關實現之後，下面再來看 HttpProtocol 中引用服務相關的方法實現，即 protocolBindinRefer() 方法實現。該方法首先通過 doRefer() 方法創建業務介面的代理，這里會使用到 jsonrpc4j 庫中的 JsonProxyFactoryBean 與 Spring 進行集成，在其 afterPropertiesSet() 方法中會創建 JsonRpcHttpClient 對象：

下面來看 doRefer() 方法的具體實現：

在 AbstractProxyProtocol.protocolBindingRefer() 方法中，會通過 ProxyFactory.getInvoker() 方法將 doRefer() 方法返回的代理對象轉換成 Invoker 對象，並記錄到 Invokers 集合中，具體實現如下：

本文重點介紹了在 Dubbo 中如何通過「HTTP 協議 + JSON-RPC」的方案實現跨語言調用。首先介紹了 JSON-RPC 中請求和響應的基本格式，以及其實現庫 jsonrpc4j 的基本使用；接下來我們還詳細介紹了 Dubbo 中 AbstractProxyProtocol、HttpProtocol 等核心類，剖析了 Dubbo 中「HTTP 協議 + JSON-RPC」方案的落地實現。

❺ Dubbo簡介

Dubbo是Alibaba開源的分布式服務框架，它按照分層的方式來架構，使用這種方式可以使各層解耦。

Dubbo在調用遠程的服務的時候再本地有一個介面，就想調用本地方法一樣去調用，底層實現好參數傳輸和遠程服務運行結果傳回之後的返回。

Dubbo的特點：

（1）它主要使用高效的網路框架和序列化框架，讓分布式服務之間調用效率更高。

（2）採用注冊中心管理眾多的服務介面地址，當你想調用服務的時候只需要跟注冊中心詢問即可，不像使用WebService一樣每個服務都得記錄好介面調用方式。

（3）監控中心時實現服務方和調用方之間運行狀態的監控，還能控制服務的優先順序、許可權、權重、上下線等，讓整個龐大的分布式服務系統的維護和治理比較方便。

（4）高可用，如果有服務掛了，注冊中心就會從服務列表去掉該節點，客戶端會像注冊中心請求另一台可用的服務節點重新調用。同時注冊中心也能實現高可用（ZooKeeper）。

（5）負載均衡，採用軟負載均衡演算法實現對多個相同服務的節點的請求負載均衡。

Dubbo需要四大基本組件：Rigistry,Monitor,Provider,Consumer。

1、監控中心的配置文件-bbo.properties文件

（1）容器，監控中心是在jetty和spring環境下運行，依賴於注冊中心，日誌系統是log4j

    bbo.container = log4j,spring,registry,jetty

（2）監控服務的名稱，監控系統對整個Dubbo服務系統來說也是一個服務

    bbo.application.name = simple-monitor

（3）服務的所有者，這是Dubbbo的服務的功能，可以指定服務的負責人

    bbo.application.owner = coselding

（4）注冊中心的地址，配置後監控中心就能通過注冊中心獲取當前可用的服務列表及其狀態，在頁面向你匯報Dubbo中的服務運行情況。

    bbo.registr.address = multicast://{ip}:{port} //廣播

    bbo.registr.address = zookeeper://{ip}:{port} //zookeper

    bbo.registr.address = redis://{ip}:{port} //redis

    bbo.registr.address = bbo://{ip}:{port} //bbo

（5）bbo協議埠號

    bbo.protocol.port = 7070

（6）jetty工作埠號

    bbo.jetty.port = 8082

（7）工作目錄，用於存放監控中心的數據

    bbo.jetty.directory = ${user.home}/monitor

（8）監控中心報表存放目錄

    bbo.charts.directory=${bbo.jetty.directory}/charts

（9）監控中心數據資料目錄

    bbo.statistics.directory=${user.home}/monitor/statistics

（10）監控中心日誌文件路徑

    bbo.log4j.file=logs/bbo-monitor-simple.log

（11）監控中心日誌記錄級別

    bbo.log4j.level=WARN

2、Dubbo提供負載均衡方式

（1）Random，隨機，按權重配置隨機概率，調用量越大分布越均勻，默認方式。

（2）RounRobin，輪詢，按權重設置輪詢比例，如果存在比較慢的機器容易在這台機器上請求阻塞較多。

（3）LeastActive，最少活躍調用數，不支持權重，只能根據自動識別的活躍數分配，不能靈活調配。

（4）ConsistenHash，一致性hash，對相同參數的請求路由到一個服務提供者上，如果有類似灰度發布需求可採用。

3、Dubbo過濾器

Dubbo初始化過程載入ClassPath下的META-INF/bbo/internal/，META-INF/bbo/，META-INF/services/三個路徑下的com.alibaba.bbo.rpc.Filter文件。文件內容：

    Name = FullClassName,這些類必須實現Filter介面。

自定義Filter類：

配置文件在配置過濾器，consumer.xml中：

Dubbo對過濾器的載入過程：

    先載入三個路徑下的com.alibaba.bbo.rpc.Filter文件裡面的鍵值對，key為過濾器名稱，value為過濾器的類的全限定名(這個類必須實現Dubbo中的Filter介面)。

    自定義的類中@Active註解是過濾器設定的全局基本屬性。

    Spring在載入consumer.xml文件時，通過 <bbo:consumer filter="xxx" id = "xxx" retrries = "0">這個配置指定消費者端要載入的過濾器，通過filter屬性指定過濾器名稱。

@Activate註解-自動激活，group屬性是表示匹配了對應的角色才被載入，value表示表明過濾條件，不寫則表示所有條件都會被載入，寫了則只有bbo URL中包含該參數名且參數值不為空才被載入，這個參數會以bbo協議的一個參數K-V對傳到Provider。

4、Dubbo的Provider配置

5、Dubbo的Consumer配置

1、Dubbo是什麼？

Dubbo是阿里巴巴開源的基於Java的高性能RPC分布式框架。

2、為什麼使用Dubbo？

很多公司都在使用，經過很多線上的考驗，內部使用了Netty，Zookeeper，保證了高性能可用性。

使用Dubbo可以將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，可以提高業務復用靈活性擴展，使前端應用能快速的響應對邊的市場需求。分布式架構可以承受更大規模的並發流量。

Dubbo的服務治理圖：

3、Dubbo和Spring Cloud的區別

兩個沒有關聯，但是非要說區別，有如下幾點：

（1）通信方式不同，Dubbo使用RPC通信，Spring Cloud使用HTTP Restful方式

（2）組成部分不同

4、Dubbo支持的協議

bbo://  （推薦）；rmi:// ；hessian:// ；http:// ；webservice:// ；thrift:// ；memcached:// ；redis:// ；rest:// 。

5、Dubbo需要容器嗎？

不需要，如果硬要容器的話，會增加復雜性，同時也浪費資源。

6、Dubbo內置的服務容器

Spring Container；Jetty Container；Log4j Container。

7、Dubbo中節點角色

Register，Monitor，Provider，Consumer，Container(服務運行的容器)。

8、Dubbo的服務注冊和發現的流程圖

9、Dubbo的注冊中心

默認使用Zookeper作為注冊中心，還有Redis，Multicast，bbo注冊中心。

10、Dubbo的配置方式

Spring配置方式和Java API配置方式

11、Dubbo的核心配置

（1）bbo:service 服務配置

（2）bbo:referece 引用配置

（3）bbo:protocol 協議配置

（4）bbo:application 應用配置

（5）bbo:registry 注冊中心配置

（6）bbo:monitor 監控中心配置

（7）bbo:provider 提供方配置

（8）bbo:consumer 消費方配置

（9）bbo:method 方法配置

（10）bbo:argument 參數配置

12、在Provider 節點上可以配置Consumer端的屬性有哪些？

（1）timeout：方法調用超時

（2）retries：失敗重試次數，默認是2次

（3）loadbalance：負載均衡演算法，默認隨機

（4）actives消費者端，最大並發調用控制

13、Dubbo啟動時如果依賴的服務不可用會怎樣

Dubbo預設會在啟動時檢查依賴的服務是否可用，不可用時會拋出異常，阻止Spring初始化完成。默認check ="true"。

14、Dubbo序列化框架

推薦使用Hessian序列化，還有Dubbo，FastJson，Java自帶序列化。

15、Dubbo的通信框架

默認使用Netty框架，另外也提供了Mina，Grizzly。

16、Dubbo集群容錯方案

（1）Failover Cluster，失敗自動切換，自動重試其他伺服器。

（2）Failfast Cluster，快速失敗，立即報錯，只發起一次調用。

（3）Failsafe Cluster，失敗安全，出現異常時，直接忽略。

（4）Failback Cluster，失敗自動恢復，記錄失敗請求，定時重發。

（5）Forking Cluster，並行調用多個伺服器，只要一個返回成功即可。

（6）Broadcast Cluster，廣播逐個調用所有提供者，任意一個報錯則報錯。

17、Dubbo的負載均衡策略

（1）Random LoadBalance，隨機，按權重設置隨機概率，默認。

（2）RoundRobin LoadBalace，輪詢，按公約後的權重設置輪訓比例。

（3）LeastActive LoadBalace，最少活躍調用數，相同活躍數的隨機。

（4）ConsistenHash LoadBalance，一致性hash，相同參數的請求總是發到用一個伺服器。

18、指定某一個服務

可以配置環境點對點直連，繞過注冊中心，將以服務介面為單位，忽略注冊中心的提供者列表。

<bbo:reference interface="com.weidian.bbo.IMyDemo" version="1.0" id="myDemo" url="bbo://127.0.0.1:20880/"></bbo:reference>

19、Dubbo多協議

Dubbo允許配置多協議，在不同伺服器上支持不同協議，或者同一服務支持多種協議。

20、當一個服務有多種實現時怎麼做？

當一個介面有多種是現實，可以用group屬性來分組，服務提供方和消費方都指定同一個group即可。

21、兼容舊版本

使用版本號過度，多個不同版本的服務注冊到注冊中心，版本號不同的服務相互間不引用。

22、Dubbo可以緩存嗎？

Dubbo提供聲明式緩存，用於加速熱門數據的訪問速度，以減少用戶加緩存的工作量。

23、Dubbo服務之間的調用時阻塞的嗎？

默認是同步等待結果阻塞的，支持非同步調用。Dubbo是基於NIO的非阻塞實現並行調用的，客戶端不需要啟動多線程即可完成並行調用多個遠程服務，相對多線程開銷較小，非同步調用會返回一個Future對象。

24、Dubbo不支持分布式事務

25、Dubbo必須依賴的包

Dubbo必須依賴JDK，其他為可選。

26、Dubbo使用過程中的問題

Dubbo的設計目的是為了滿足高並發小數據量的rpc請求，在大數據量下性能表現不是很好，建議使用rmi或http協議。

27、Dubbo的管理控制台的作用

路由規則，動態配置，服務降級，訪問控制，權重調整，負載均衡。

28、Spring boot整合Dubbo

（1）添加依賴

        <!-- https://mvnrepository.com/artifact/com.alibaba.boot/bbo-spring-boot-project -->

        <dependency>

            <groupId>com.alibaba.boot</groupId>

            <artifactId>bbo-spring-boot-starter</artifactId>

            <version>0.1.0</version>

        </dependency>

        <!-- https://mvnrepository.com/artifact/com.101tec/zkclient -->

        <dependency>

            <groupId>com.101tec</groupId>

            <artifactId>zkclient</artifactId>

            <version>0.10</version>

        </dependency>

（2）配置bbo

    ## Dubbo 服務提供者配置

    spring.bbo.application.name=provider

    spring.bbo.registry.address=zookeeper://127.0.0.1:2181

    spring.bbo.protocol.name=bbo

    spring.bbo.protocol.port=20880

    spring.bbo.scan=org.spring.springboot.bbo

    ## Dubbo 服務消費者配置

    spring.bbo.application.name=consumer

    spring.bbo.registry.address=zookeeper://127.0.0.1:2181

    spring.bbo.scan=org.spring.springboot.bbo

❻ bbo privider與consumer同時配置retry以哪個為主

bbo配置優先順序：
方法級>介面級>全局級
消費方配置優先於提供方配置
所以，retry如果都配了，以消費方為主。