99热在线精品一区二区三区_国产伦精品一区二区三区女破破_亚洲一区二区三区无码_精品国产欧美日韩另类一区

本篇內(nèi)容主要講解“dubbo的重要知識(shí)點(diǎn)總結(jié)”，感興趣的朋友不妨來(lái)看看。本文介紹的方法操作簡(jiǎn)單快捷，實(shí)用性強(qiáng)。下面就讓小編來(lái)帶大家學(xué)習(xí)“dubbo的重要知識(shí)點(diǎn)總結(jié)”吧!

創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括辰溪網(wǎng)站建設(shè)、辰溪網(wǎng)站制作、辰溪網(wǎng)頁(yè)制作以及辰溪網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái)，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，辰溪網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到辰溪省份的部分城市，未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

dubbo架構(gòu)

Provider： 暴露服務(wù)的提供方，可以通過(guò)jar或者容器的方式啟動(dòng)服務(wù)
Consumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方。
Registry： 服務(wù)注冊(cè)中心和發(fā)現(xiàn)中心。
Monitor： 統(tǒng)計(jì)服務(wù)的調(diào)用次數(shù)、調(diào)用時(shí)間
Container：服務(wù)運(yùn)行的容器。

Dubbo的網(wǎng)絡(luò)傳輸協(xié)議

RPC通訊協(xié)議

Dubbo提供的序列化方式

• dubbo：Dubbo缺省協(xié)議采用單一長(zhǎng)連接和NIO異步通訊，適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用，以及服務(wù)消費(fèi)者機(jī)器數(shù)遠(yuǎn)大于服務(wù)提供者機(jī)器數(shù)的情況

• rmi：RMI協(xié)議采用JDK標(biāo)準(zhǔn)的java.rmi.*實(shí)現(xiàn)，采用阻塞式短連接和JDK標(biāo)準(zhǔn)序列化方式

• Hessian:Hessian協(xié)議用于集成Hessian的服務(wù)，Hessian底層采用Http通訊，采用Servlet暴露服務(wù)，Dubbo缺省內(nèi)嵌Jetty作為服務(wù)器實(shí)現(xiàn)

• http:采用Spring的HttpInvoker實(shí)現(xiàn)

• Webservice:基于CXF的frontend-simple和transports-http實(shí)現(xiàn)

Dubbo的注冊(cè)中心

默認(rèn)是zk，其他還有redis、Multicast、Simple 注冊(cè)中心，但不推薦。

Dubbo有哪幾種配置方式？

Spring 配置方式（XML文件）
Java API 配置方式（注解方式）

Dubbo的核心配置

• dubbo:service       服務(wù)配置（作為服務(wù)的提供者，暴露服務(wù)的配置）

• dubbo:reference     引用配置（需要調(diào)用外部服務(wù)）

• dubbo:protocol      協(xié)議配置（服務(wù)支持的協(xié)議配置，若需要支持多個(gè)協(xié)議，可以聲明多個(gè)標(biāo)簽）

• dubbo:application   應(yīng)用配置（應(yīng)用信息配置，包括當(dāng)前應(yīng)用名、應(yīng)用負(fù)責(zé)人、應(yīng)用版本、應(yīng)用環(huán)境等）

• dubbo:module        模塊配置（模塊信息配置，包括當(dāng)前模塊名、模塊負(fù)責(zé)人、模塊版本等）

• dubbo:registry      注冊(cè)中心配置（同時(shí)如果有多個(gè)不同的注冊(cè)中心，可以聲明多個(gè) 標(biāo)簽，并在 或 的 registry 屬性指定使用的注冊(cè)中心。）

• dubbo:monitor       監(jiān)控中心配置（有protocol、address兩個(gè)屬性，當(dāng)protocol="registry"，表示從注冊(cè)中心發(fā)現(xiàn)監(jiān)控中心地址，當(dāng)address="10.20.130.230:12080"表示直連監(jiān)控中心地址）

• dubbo:provider      提供方配置（服務(wù)提供者缺省值配置，該標(biāo)簽為 和 標(biāo)簽的缺省值設(shè)置。）

• dubbo:consumer      消費(fèi)方配置（服務(wù)消費(fèi)者缺省值配置，該標(biāo)簽為 標(biāo)簽的缺省值設(shè)置。）

• dubbo:method        方法配置（該標(biāo)簽為 或 的子標(biāo)簽，用于控制到方法級(jí)。）

• dubbo:argument      參數(shù)配置（該標(biāo)簽為 的子標(biāo)簽，用于方法參數(shù)的特征描述）

Timeout的超時(shí)時(shí)間

在dubbo的provider和consumer的配置文件中，如果都配置了timeout的超時(shí)時(shí)間，dubbo默認(rèn)以consumer中配置的時(shí)間為準(zhǔn)。
如下例子：
在provider.xml的配置：

conusmer中的配置：

最后這個(gè)service在調(diào)用時(shí)的超時(shí)時(shí)間就是3秒。
另外:
1.consumer會(huì)在超過(guò)3秒時(shí)得到一個(gè)調(diào)用超時(shí)的異常。
2.provider中代碼的執(zhí)行不會(huì)因?yàn)槌瑫r(shí)而中斷，在執(zhí)行完畢后，會(huì)得到一個(gè)dubbo的警告。

在Provider上盡量多配置Consumer端屬性

在dubbo的用戶手冊(cè)中，對(duì)配置有這樣的推薦用法：在Provider上盡量多配置Consumer端屬性
原因如下：
作服務(wù)的提供者，比服務(wù)使用方更清楚服務(wù)性能參數(shù)，如調(diào)用的超時(shí)時(shí)間，合理的重試次數(shù)，等等
在Provider配置后，Consumer不配置則會(huì)使用Provider的配置值，即Provider配置可以作為Consumer的缺省值。否則，Consumer會(huì)使用Consumer端的全局設(shè)置，這對(duì)于Provider不可控的，并且往往是不合理的
PS: 配置的覆蓋規(guī)則：

• 方法級(jí)配置級(jí)別優(yōu)于接口級(jí)別，即小Scope優(yōu)先 

• Consumer端配置 優(yōu)于 Provider配置 優(yōu)于 全局配置，最后是Dubbo Hard Code的配置值（見(jiàn)配置文檔）

在 Provider 可以配置的 Consumer 端屬性有：

• timeout：方法調(diào)用超時(shí)

• retries：失敗重試次數(shù)，缺省是2（表示加上第一次調(diào)用，會(huì)調(diào)用3次）

• loadbalance：負(fù)載均衡算法（有多個(gè)Provider時(shí)，如何挑選Provider調(diào)用），缺省是隨機(jī)（random）。還可以有輪訓(xùn)(roundrobin)、最不活躍優(yōu)先（leastactive，指從Consumer端并發(fā)調(diào)用最好的Provider，可以減少的反應(yīng)慢的Provider的調(diào)用，因?yàn)榉磻?yīng)更容易累積并發(fā)的調(diào)用）

• actives：消費(fèi)者端，最大并發(fā)調(diào)用限制，即當(dāng)Consumer對(duì)一個(gè)服務(wù)的并發(fā)調(diào)用到上限后，新調(diào)用會(huì)Wait直到超時(shí)。在方法上配置（dubbo:method ）則并發(fā)限制針對(duì)方法，在接口上配置（dubbo:service），則并發(fā)限制針對(duì)服務(wù)。

Dubbo 啟動(dòng)時(shí)如果依賴的服務(wù)不可用會(huì)怎樣？

Dubbo 缺省會(huì)在啟動(dòng)時(shí)檢查依賴的服務(wù)是否可用，不可用時(shí)會(huì)拋出異常，阻止 Spring 初始化完成，默認(rèn) check="true"，可以通過(guò) check="false" 關(guān)閉檢查。

Dubbo支持的序列化框架

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

Dubbo使用的通信框架

Dubbo 默認(rèn)使用 Netty 框架，也是推薦的選擇，另外內(nèi)容還集成有Mina、Grizzly

Dubbo的集群容錯(cuò)方案

• Failover Cluster    失敗自動(dòng)切換，自動(dòng)重試其它服務(wù)器（默認(rèn)） 

• Failfast Cluster    快速失敗，立即報(bào)錯(cuò)，只發(fā)起一次調(diào)用 

• Failsafe Cluster    失敗安全，出現(xiàn)異常時(shí)，直接忽略 

• Failback Cluster    失敗自動(dòng)恢復(fù)，記錄失敗請(qǐng)求，定時(shí)重發(fā) 

• Forking Cluster     并行調(diào)用多個(gè)服務(wù)器，只要一個(gè)成功即返回 

• Broadcast Cluster   廣播逐個(gè)調(diào)用所有提供者，任意一個(gè)報(bào)錯(cuò)則報(bào)錯(cuò)

Dubbo的負(fù)載均衡策略

• Random LoadBalance          隨機(jī)，按權(quán)重設(shè)置隨機(jī)概率（默認(rèn)） 

• RoundRobin LoadBalance      輪詢，按公約后的權(quán)重設(shè)置輪詢比率

• LeastActive LoadBalance     最少活躍調(diào)用數(shù)，相同活躍數(shù)的隨機(jī) 

• ConsistentHash LoadBalance  一致性 Hash，相同參數(shù)的請(qǐng)求總是發(fā)到同一提供者

注冊(cè)了多個(gè)同一樣的服務(wù)，如果需要測(cè)試指定的某一個(gè)服務(wù)該怎么做

可以配置環(huán)境點(diǎn)對(duì)點(diǎn)直連，繞過(guò)注冊(cè)中心，將以服務(wù)接口為單位，忽略注冊(cè)中心的提供者列表。

Dubbo支持服務(wù)多協(xié)議

Dubbo 允許配置多協(xié)議，在不同服務(wù)上支持不同協(xié)議或者同一服務(wù)上同時(shí)支持多種協(xié)議。
不同服務(wù)不同協(xié)議：

同一服務(wù)多種協(xié)議

當(dāng)一個(gè)服務(wù)接口有多種實(shí)現(xiàn)時(shí)怎么做

當(dāng)一個(gè)接口有多種實(shí)現(xiàn)時(shí)，可以用 group 屬性來(lái)分組，服務(wù)提供方和消費(fèi)方都指定同一個(gè) group 即可。
提供端：

消費(fèi)端：

服務(wù)上線怎么兼容舊版本？

可以用版本號(hào)（version）過(guò)渡，多個(gè)不同版本的服務(wù)注冊(cè)到注冊(cè)中心，版本號(hào)不同的服務(wù)相互間不引用。這個(gè)和服務(wù)分組的概念有一點(diǎn)類似。例如：
服務(wù)提供方：

服務(wù)消費(fèi)方：

此外，消費(fèi)者消費(fèi)服任意版本的服務(wù)時(shí)：

Dubbo的結(jié)果緩存機(jī)制

Dubbo 提供了聲明式緩存，用于加速熱門數(shù)據(jù)的訪問(wèn)速度，以減少用戶加緩存的工作量，使用方式：

Dubbo提供的三種緩存接口的入口，三種方式均繼承了 AbstractCacheFactory 接口，分別是：

• 1.threadlocal=com.alibaba.dubbo.cache.support.threadlocal.ThreadLocalCacheFactory

• 2.lru=com.alibaba.dubbo.cache.support.lru.LruCacheFactory（LRU基于最近最少使用原則刪除多余緩存，保持最熱的數(shù)據(jù)被緩存；該類型的緩存是跨線程的；利用鏈表實(shí)現(xiàn)，新數(shù)據(jù)插入表頭、緩存命中數(shù)據(jù)移到表頭、鏈表滿時(shí)刪除表尾數(shù)據(jù)）

• 3.jcache=com.alibaba.dubbo.cache.support.jcache.JCacheFactory

Dubbo 同步/異步調(diào)用

Dubbo 缺省協(xié)議采用單一長(zhǎng)連接，底層實(shí)現(xiàn)是 Netty 的 NIO 異步通訊機(jī)制；基于這種機(jī)制，Dubbo 實(shí)現(xiàn)了以下幾種調(diào)用方式：

• 同步調(diào)用

• 異步調(diào)用

• 參數(shù)回調(diào)

• 事件通知

Dubbo 同步調(diào)用

同步調(diào)用是一種阻塞式的調(diào)用方式，即 Consumer 端代碼一直阻塞等待，直到 Provider 端返回為止；
通常，一個(gè)典型的同步調(diào)用過(guò)程如下：

1. Consumer 業(yè)務(wù)線程調(diào)用遠(yuǎn)程接口，向 Provider 發(fā)送請(qǐng)求，同時(shí)當(dāng)前線程處于阻塞狀態(tài)；

2. Provider 接到 Consumer 的請(qǐng)求后，開始處理請(qǐng)求，將結(jié)果返回給 Consumer；

3. Consumer 收到結(jié)果后，當(dāng)前線程繼續(xù)往后執(zhí)行。

這里有 2 個(gè)問(wèn)題：

• Consumer 業(yè)務(wù)線程是怎么進(jìn)入阻塞狀態(tài)的？

• Consumer 收到結(jié)果后，如何喚醒業(yè)務(wù)線程往后執(zhí)行的？

其實(shí)，Dubbo 的底層 IO 操作都是異步的。Consumer 端發(fā)起調(diào)用后，得到一個(gè) Future 對(duì)象。對(duì)于同步調(diào)用，業(yè)務(wù)線程通過(guò)Future#get(timeout)，阻塞等待 Provider 端將結(jié)果返回；timeout則是 Consumer 端定義的超時(shí)時(shí)間。當(dāng)結(jié)果返回后，會(huì)設(shè)置到此 Future，并喚醒阻塞的業(yè)務(wù)線程；當(dāng)超時(shí)時(shí)間到結(jié)果還未返回時(shí)，業(yè)務(wù)線程將會(huì)異常返回。

Dubbo 異步調(diào)用

基于 Dubbo 底層的異步 NIO 實(shí)現(xiàn)異步調(diào)用，對(duì)于 Provider 響應(yīng)時(shí)間較長(zhǎng)的場(chǎng)景是必須的，它能有效利用 Consumer 端的資源，相對(duì)于 Consumer 端使用多線程來(lái)說(shuō)開銷較小。異步調(diào)用，對(duì)于 Provider 端不需要做特別的配置。
在 Consumer 端配置需要異步調(diào)用的方法，均需要使用 標(biāo)簽進(jìn)行描述：

Dubbo Consumer 端發(fā)起調(diào)用后，同時(shí)通過(guò)RpcContext.getContext().getFuture()獲取跟返回結(jié)果關(guān)聯(lián)的Future對(duì)象，然后就可以開始處理其他任務(wù)；當(dāng)需要這次異步調(diào)用的結(jié)果時(shí)，可以在任意時(shí)刻通過(guò)future.get(timeout)來(lái)獲取。
一些特殊場(chǎng)景下，為了盡快調(diào)用返回，可以設(shè)置是否等待消息發(fā)出：

• sent="true" 等待消息發(fā)出，消息發(fā)送失敗將拋出異常；

• sent="false" 不等待消息發(fā)出，將消息放入 IO 隊(duì)列，即刻返回。

默認(rèn)為false。配置方式如下：

如果你只是想異步，完全忽略返回值，可以配置 return="false"，以減少 Future 對(duì)象的創(chuàng)建和管理成本：

此時(shí)，RpcContext.getContext().getFuture()將返回null。

Dubbo 參數(shù)回調(diào)

參數(shù)回調(diào)有點(diǎn)類似于本地 Callback 機(jī)制，但 Callback 并不是 Dubbo 內(nèi)部的類或接口，而是由 Provider 端自定義的；Dubbo 將基于長(zhǎng)連接生成反向代理，從而實(shí)現(xiàn)從 Provider 端調(diào)用 Consumer 端的邏輯。

Provider 端定義 Service 和 Callback：

public interface CallbackService {
    void addListener(String key, CallbackListener listener);
}

public interface CallbackListener {
    void changed(String msg);
}

Provider 端實(shí)現(xiàn) service ：

public class CallbackServiceImpl implements CallbackService {

    private final Map listeners = new ConcurrentHashMap();

    public CallbackServiceImpl() {
        Thread t = new Thread(new Runnable() {
            public void run() {
                while (true) {
                    try {
                        for (Map.Entry entry : listeners.entrySet()) {
                            try {
                                entry.getValue().changed(getChanged(entry.getKey()));
                            } catch (Throwable t) {
                                listeners.remove(entry.getKey());
                            }
                        }
                        Thread.sleep(5000); // timely trigger change event
                    } catch (Throwable t) {
                        t.printStackTrace();
                    }
                }
            }
        });
        t.setDaemon(true);
        t.start();
    }

    public void addListener(String key, CallbackListener listener) {
        listeners.put(key, listener);
        listener.changed(getChanged(key)); // send notification for change
    }

    private String getChanged(String key) {
        return "Changed: " + new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date());
    }
}

在 Provider 端暴露服務(wù)：

Consumer 端實(shí)現(xiàn) Callback 接口

CallbackService callbackService = ...;
callbackService.addListener("foo.bar", new CallbackListener() {
        public void changed(String msg) {
            System.out.println("callback1:" + msg);
        }
});

Callback 接口的實(shí)現(xiàn)類在 Consumer 端，當(dāng)方法發(fā)生調(diào)用時(shí)，Consumer 端會(huì)自動(dòng) export 一個(gè) Callback 服務(wù)。而 Provider 端在處理調(diào)用時(shí)，判斷如果參數(shù)是 Callback，則生成了一個(gè) proxy，因此服務(wù)實(shí)現(xiàn)類里在調(diào)用 Callback 方法的時(shí)候，會(huì)被傳遞到 Consumer 端執(zhí)行 Callback 實(shí)現(xiàn)類的代碼。

Dubbo 事件通知

事件通知允許 Consumer 端在調(diào)用之前、調(diào)用之后或出現(xiàn)異常時(shí)，觸發(fā) oninvoke、onreturn、onthrow 三個(gè)事件。
可以通過(guò)在配置 Consumer 時(shí)，指定事件需要通知的方法，如：

其中，NotifyImpl 的代碼如下：

public class NotifyImpl implements Notify {

    public Map ret = new HashMap();
    
    public void onreturn(String name, int id) {
        ret.put(id, name);
        System.out.println("onreturn: " + name);
    }

    public void onthrow(Throwable ex, String name, int id) {
        System.out.println("onthrow: " + name);
    }
}

這里要強(qiáng)調(diào)一點(diǎn)，自定義 Notify 接口中的三個(gè)方法的參數(shù)規(guī)則如下：

• oninvoke 方法參數(shù)與調(diào)用方法的參數(shù)相同；

• onreturn方法第一個(gè)參數(shù)為調(diào)用方法的返回值，其余為調(diào)用方法的參數(shù)；

• onthrow方法第一個(gè)參數(shù)為調(diào)用異常，其余為調(diào)用方法的參數(shù)。

上述配置中，sayHello方法為同步調(diào)用，因此事件通知方法的執(zhí)行也是同步執(zhí)行。可以配置 async=true 讓方法調(diào)用為異步，這時(shí)事件通知的方法也是異步執(zhí)行的。特別強(qiáng)調(diào)一下， oninvoke 方法不管是否異步調(diào)用，都是同步執(zhí)行的。

Dubbo 支持分布式事務(wù)嗎？

目前暫時(shí)不支持，后續(xù)可能采用基于 JTA/XA 規(guī)范實(shí)現(xiàn)

Dubbo 服務(wù)降級(jí)（2.2.0以上的版本支持）

可以通過(guò)服務(wù)降級(jí)功能臨時(shí)屏蔽某個(gè)出錯(cuò)的非關(guān)鍵服務(wù)，并定義降級(jí)后的返回策略。
向注冊(cè)中心寫入動(dòng)態(tài)配置覆蓋規(guī)則：

• RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();

• Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));

• registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService？category=configurators&dynamic=false&application=foo&mock=force:return+null"));

其中：
mock=force:return+null 表示消費(fèi)方對(duì)該服務(wù)的方法調(diào)用都直接返回 null 值，不發(fā)起遠(yuǎn)程調(diào)用。用來(lái)屏蔽不重要的服務(wù)不可用時(shí)，對(duì)調(diào)用方的影響。
還可以改為 mock=fail:return+null 表示消費(fèi)方對(duì)該服務(wù)的方法調(diào)用在失敗后，再返回 null 值，不拋異常。用來(lái)容忍不重要服務(wù)不穩(wěn)定時(shí)對(duì)調(diào)用方的影響。

Dubbo 如何優(yōu)雅停機(jī)？

Dubbo 是通過(guò) JDK 的 ShutdownHook 來(lái)完成優(yōu)雅停機(jī)的，所以如果使用 kill -9 PID 等強(qiáng)制關(guān)閉指令，是不會(huì)執(zhí)行優(yōu)雅停機(jī)的，只有通過(guò) kill PID 時(shí)，才會(huì)執(zhí)行。

• 服務(wù)提供方：停止時(shí)，先標(biāo)記為不接收新請(qǐng)求，新請(qǐng)求過(guò)來(lái)時(shí)直接報(bào)錯(cuò)，讓客戶端重試其它機(jī)器。然后，檢測(cè)線程池中的線程是否正在運(yùn)行，如果有，等待所有線程執(zhí)行完成，除非超時(shí)，則強(qiáng)制關(guān)閉。

• 服務(wù)消費(fèi)方：停止時(shí)，不再發(fā)起新的調(diào)用請(qǐng)求，所有新的調(diào)用在客戶端即報(bào)錯(cuò)。然后，檢測(cè)有沒(méi)有請(qǐng)求的響應(yīng)還沒(méi)有返回，等待響應(yīng)返回，除非超時(shí)，則強(qiáng)制關(guān)閉。

Dubbo 的服務(wù)提供者能實(shí)現(xiàn)失效踢出是什么原理？

服務(wù)失效踢出是基于 Zookeeper 的臨時(shí)節(jié)點(diǎn)原理。
zk 中的節(jié)點(diǎn)分為臨時(shí)節(jié)點(diǎn)和永久節(jié)點(diǎn)，節(jié)點(diǎn)的類型在創(chuàng)建時(shí)即被確定，并且不能改變。

• ZooKeeper的臨時(shí)節(jié)點(diǎn)：該節(jié)點(diǎn)的生命周期依賴于創(chuàng)建它們的會(huì)話。一旦會(huì)話結(jié)束，臨時(shí)節(jié)點(diǎn)將被自動(dòng)刪除，當(dāng)然可以也可以手動(dòng)刪除。另外，需要注意是，ZooKeeper的臨時(shí)節(jié)點(diǎn)不允許擁有子節(jié)點(diǎn)。

• ZooKeeper的永久節(jié)點(diǎn)：該節(jié)點(diǎn)的生命周期不依賴于會(huì)話，并且只有在客戶端顯示執(zhí)行刪除操作的時(shí)候，他們才能被刪除。

在分布式系統(tǒng)中，我們常常需要知道某個(gè)機(jī)器是否可用，傳統(tǒng)的開發(fā)中，可以通過(guò)Ping某個(gè)主機(jī)來(lái)實(shí)現(xiàn)，Ping得通說(shuō)明對(duì)方是可用的，相反是不可用的。
在 ZK 中我們讓所有的機(jī)器都注冊(cè)一個(gè)臨時(shí)節(jié)點(diǎn)，要判斷一個(gè)節(jié)點(diǎn)是否可用，我們只需要判斷這個(gè)臨時(shí)節(jié)點(diǎn)在 ZK 中是否存在就可以了，不需要直接去連接需要檢查的機(jī)器，降低系統(tǒng)的復(fù)雜度。

Dubbo 服務(wù)讀寫推薦的容錯(cuò)策略是怎樣的？

讀操作建議使用 Failover 失敗自動(dòng)切換，默認(rèn)重試兩次其他服務(wù)器。
寫操作建議使用 Failfast 快速失敗，發(fā)一次調(diào)用失敗就立即報(bào)錯(cuò)。

如何解決服務(wù)調(diào)用鏈過(guò)長(zhǎng)的問(wèn)題？

Dubbo 可以使用 Pinpoint 和 Apache Skywalking(Incubator) 實(shí)現(xiàn)分布式服務(wù)追蹤，當(dāng)然還有其他很多方案。

Dubbo 的管理控制臺(tái)能做什么？

管理控制臺(tái)主要包含：路由規(guī)則，動(dòng)態(tài)配置，服務(wù)降級(jí)，訪問(wèn)控制，權(quán)重調(diào)整，負(fù)載均衡，等管理功能。

到此，相信大家對(duì)“dubbo的重要知識(shí)點(diǎn)總結(jié)”有了更深的了解，不妨來(lái)實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

網(wǎng)頁(yè)標(biāo)題：dubbo的重要知識(shí)點(diǎn)總結(jié)
當(dāng)前路徑：http://www.ef60e0e.cn/article/gjcshg.html