本篇內(nèi)容主要講解“dubbo的重要知識點(diǎn)總結(jié)”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“dubbo的重要知識點(diǎn)總結(jié)”吧!
創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括辰溪網(wǎng)站建設(shè)、辰溪網(wǎng)站制作、辰溪網(wǎng)頁制作以及辰溪網(wǎng)絡(luò)營銷策劃等。多年來,我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,辰溪網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟(jì)效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到辰溪省份的部分城市,未來相信會繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!
Provider: 暴露服務(wù)的提供方,可以通過jar或者容器的方式啟動服務(wù)
Consumer:調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方。
Registry: 服務(wù)注冊中心和發(fā)現(xiàn)中心。
Monitor: 統(tǒng)計(jì)服務(wù)的調(diào)用次數(shù)、調(diào)用時(shí)間
Container:服務(wù)運(yùn)行的容器。
RPC通訊協(xié)議
dubbo:Dubbo缺省協(xié)議采用單一長連接和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)
默認(rèn)是zk,其他還有redis、Multicast、Simple 注冊中心,但不推薦。
Spring 配置方式(XML文件)
Java API 配置方式(注解方式)
dubbo:service 服務(wù)配置(作為服務(wù)的提供者,暴露服務(wù)的配置)
dubbo:reference 引用配置(需要調(diào)用外部服務(wù))
dubbo:protocol 協(xié)議配置(服務(wù)支持的協(xié)議配置,若需要支持多個(gè)協(xié)議,可以聲明多個(gè)<dubbo:protocol>標(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 注冊中心配置(同時(shí)如果有多個(gè)不同的注冊中心,可以聲明多個(gè) <dubbo:registry> 標(biāo)簽,并在 <dubbo:service> 或 <dubbo:reference> 的 registry 屬性指定使用的注冊中心。)
dubbo:monitor 監(jiān)控中心配置(有protocol、address兩個(gè)屬性,當(dāng)protocol="registry",表示從注冊中心發(fā)現(xiàn)監(jiān)控中心地址,當(dāng)address="10.20.130.230:12080"表示直連監(jiān)控中心地址)
dubbo:provider 提供方配置(服務(wù)提供者缺省值配置,該標(biāo)簽為 <dubbo:service> 和 <dubbo:protocol> 標(biāo)簽的缺省值設(shè)置。)
dubbo:consumer 消費(fèi)方配置(服務(wù)消費(fèi)者缺省值配置,該標(biāo)簽為 <dubbo:reference> 標(biāo)簽的缺省值設(shè)置。)
dubbo:method 方法配置(該標(biāo)簽為 <dubbo:service> 或 <dubbo:reference> 的子標(biāo)簽,用于控制到方法級。)
dubbo:argument 參數(shù)配置(該標(biāo)簽為 <dubbo:method> 的子標(biāo)簽,用于方法參數(shù)的特征描述)
在dubbo的provider和consumer的配置文件中,如果都配置了timeout的超時(shí)時(shí)間,dubbo默認(rèn)以consumer中配置的時(shí)間為準(zhǔn)。
如下例子:
在provider.xml的配置:
<dubbo:service timeout="4000" retries="0" interface="com.dingding.tms.bms.service.BillingZfbCodOrderService" ref="billingZfbCodOrderService" registry="globalRegistry"/>
conusmer中的配置:
<dubbo:reference id="billingInterService" interface="com.dingding.tms.bms.service.BillingInterService" protocol="dubbo" check="false" registry="globalRegistry" timeout="3000"/>
最后這個(gè)service在調(diào)用時(shí)的超時(shí)時(shí)間就是3秒。
另外:
1.consumer會在超過3秒時(shí)得到一個(gè)調(diào)用超時(shí)的異常。
2.provider中代碼的執(zhí)行不會因?yàn)槌瑫r(shí)而中斷,在執(zhí)行完畢后,會得到一個(gè)dubbo的警告。
在dubbo的用戶手冊中,對配置有這樣的推薦用法:在Provider上盡量多配置Consumer端屬性
原因如下:
作服務(wù)的提供者,比服務(wù)使用方更清楚服務(wù)性能參數(shù),如調(diào)用的超時(shí)時(shí)間,合理的重試次數(shù),等等
在Provider配置后,Consumer不配置則會使用Provider的配置值,即Provider配置可以作為Consumer的缺省值。否則,Consumer會使用Consumer端的全局設(shè)置,這對于Provider不可控的,并且往往是不合理的
PS: 配置的覆蓋規(guī)則:
方法級配置級別優(yōu)于接口級別,即小Scope優(yōu)先
Consumer端配置 優(yōu)于 Provider配置 優(yōu)于 全局配置,最后是Dubbo Hard Code的配置值(見配置文檔)
在 Provider 可以配置的 Consumer 端屬性有:
timeout:方法調(diào)用超時(shí)
retries:失敗重試次數(shù),缺省是2(表示加上第一次調(diào)用,會調(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對一個(gè)服務(wù)的并發(fā)調(diào)用到上限后,新調(diào)用會Wait直到超時(shí)。在方法上配置(dubbo:method )則并發(fā)限制針對方法,在接口上配置(dubbo:service),則并發(fā)限制針對服務(wù)。
Dubbo 缺省會在啟動時(shí)檢查依賴的服務(wù)是否可用,不可用時(shí)會拋出異常,阻止 Spring 初始化完成,默認(rèn) check="true",可以通過 check="false" 關(guān)閉檢查。
推薦使用Hessian序列化,還有Duddo、FastJson、Java自帶序列化。
Dubbo 默認(rèn)使用 Netty 框架,也是推薦的選擇,另外內(nèi)容還集成有Mina、Grizzly
Failover Cluster 失敗自動切換,自動重試其它服務(wù)器(默認(rèn))
Failfast Cluster 快速失敗,立即報(bào)錯(cuò),只發(fā)起一次調(diào)用
Failsafe Cluster 失敗安全,出現(xiàn)異常時(shí),直接忽略
Failback Cluster 失敗自動恢復(fù),記錄失敗請求,定時(shí)重發(fā)
Forking Cluster 并行調(diào)用多個(gè)服務(wù)器,只要一個(gè)成功即返回
Broadcast Cluster 廣播逐個(gè)調(diào)用所有提供者,任意一個(gè)報(bào)錯(cuò)則報(bào)錯(cuò)
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ù)的請求總是發(fā)到同一提供者
可以配置環(huán)境點(diǎn)對點(diǎn)直連,繞過注冊中心,將以服務(wù)接口為單位,忽略注冊中心的提供者列表。
Dubbo 允許配置多協(xié)議,在不同服務(wù)上支持不同協(xié)議或者同一服務(wù)上同時(shí)支持多種協(xié)議。
不同服務(wù)不同協(xié)議:
<!-- 多協(xié)議配置 --> <dubbo:protocol name="dubbo" port="20880" /> <dubbo:protocol name="rmi" port="20980" /> <!-- 使用dubbo協(xié)議暴露服務(wù) --> <dubbo:service interface="com.ricky.dubbo.api.DemoService" ref="demoService" protocol="dubbo"/> <!-- 使用rmi協(xié)議暴露服務(wù) --> <dubbo:service interface="com.ricky.dubbo.api.HelloService" ref="helloService" protocol="rmi"/>
同一服務(wù)多種協(xié)議
<!-- 多協(xié)議配置 --> <dubbo:protocol name="dubbo" port="20880" /> <dubbo:protocol name="rmi" port="20980" /> <!-- 使用rmi協(xié)議暴露服務(wù) --> <dubbo:service interface="com.ricky.dubbo.api.HelloService" ref="helloService" protocol="dubbo,rmi"/>
當(dāng)一個(gè)接口有多種實(shí)現(xiàn)時(shí),可以用 group 屬性來分組,服務(wù)提供方和消費(fèi)方都指定同一個(gè) group 即可。
提供端:
<dubbo:service interface="…" ref="…" group="實(shí)現(xiàn)1" /> <dubbo:service interface="…" ref="…" group="實(shí)現(xiàn)2" />
消費(fèi)端:
<dubbo:reference id="…" interface="…" group="實(shí)現(xiàn)1" /> <dubbo:reference id="…" interface="…" group="實(shí)現(xiàn)2" />
可以用版本號(version)過渡,多個(gè)不同版本的服務(wù)注冊到注冊中心,版本號不同的服務(wù)相互間不引用。這個(gè)和服務(wù)分組的概念有一點(diǎn)類似。例如:
服務(wù)提供方:
<dubbo:service interface="com.foo.BarService" version="1.0.0" /> <dubbo:service interface="com.foo.BarService" version="2.0.0" />
服務(wù)消費(fèi)方:
<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" /> <dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />
此外,消費(fèi)者消費(fèi)服任意版本的服務(wù)時(shí):
<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />
Dubbo 提供了聲明式緩存,用于加速熱門數(shù)據(jù)的訪問速度,以減少用戶加緩存的工作量,使用方式:
<dubbo:reference interface="com.foo.BarService" cache="threadlocal" />
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 缺省協(xié)議采用單一長連接,底層實(shí)現(xiàn)是 Netty 的 NIO 異步通訊機(jī)制;基于這種機(jī)制,Dubbo 實(shí)現(xiàn)了以下幾種調(diào)用方式:
同步調(diào)用
異步調(diào)用
參數(shù)回調(diào)
事件通知
同步調(diào)用是一種阻塞式的調(diào)用方式,即 Consumer 端代碼一直阻塞等待,直到 Provider 端返回為止;
通常,一個(gè)典型的同步調(diào)用過程如下:
Consumer 業(yè)務(wù)線程調(diào)用遠(yuǎn)程接口,向 Provider 發(fā)送請求,同時(shí)當(dāng)前線程處于阻塞狀態(tài);
Provider 接到 Consumer 的請求后,開始處理請求,將結(jié)果返回給 Consumer;
Consumer 收到結(jié)果后,當(dāng)前線程繼續(xù)往后執(zhí)行。
這里有 2 個(gè)問題:
Consumer 業(yè)務(wù)線程是怎么進(jìn)入阻塞狀態(tài)的?
Consumer 收到結(jié)果后,如何喚醒業(yè)務(wù)線程往后執(zhí)行的?
其實(shí),Dubbo 的底層 IO 操作都是異步的。Consumer 端發(fā)起調(diào)用后,得到一個(gè) Future 對象。對于同步調(diào)用,業(yè)務(wù)線程通過Future#get(timeout),阻塞等待 Provider 端將結(jié)果返回;timeout則是 Consumer 端定義的超時(shí)時(shí)間。當(dāng)結(jié)果返回后,會設(shè)置到此 Future,并喚醒阻塞的業(yè)務(wù)線程;當(dāng)超時(shí)時(shí)間到結(jié)果還未返回時(shí),業(yè)務(wù)線程將會異常返回。
基于 Dubbo 底層的異步 NIO 實(shí)現(xiàn)異步調(diào)用,對于 Provider 響應(yīng)時(shí)間較長的場景是必須的,它能有效利用 Consumer 端的資源,相對于 Consumer 端使用多線程來說開銷較小。異步調(diào)用,對于 Provider 端不需要做特別的配置。
在 Consumer 端配置需要異步調(diào)用的方法,均需要使用 <dubbo:method/>標(biāo)簽進(jìn)行描述:
<dubbo:reference id="asyncService" interface="com.alibaba.dubbo.samples.async.api.AsyncService"> <dubbo:method name="goodbye" async="true"/> </dubbo:reference>
Dubbo Consumer 端發(fā)起調(diào)用后,同時(shí)通過RpcContext.getContext().getFuture()獲取跟返回結(jié)果關(guān)聯(lián)的Future對象,然后就可以開始處理其他任務(wù);當(dāng)需要這次異步調(diào)用的結(jié)果時(shí),可以在任意時(shí)刻通過future.get(timeout)來獲取。
一些特殊場景下,為了盡快調(diào)用返回,可以設(shè)置是否等待消息發(fā)出:
sent="true" 等待消息發(fā)出,消息發(fā)送失敗將拋出異常;
sent="false" 不等待消息發(fā)出,將消息放入 IO 隊(duì)列,即刻返回。
默認(rèn)為false。配置方式如下:
<dubbo:method name="goodbye" async="true" sent="true" />
如果你只是想異步,完全忽略返回值,可以配置 return="false",以減少 Future 對象的創(chuàng)建和管理成本:
<dubbo:method name="goodbye" async="true" return="false" />
此時(shí),RpcContext.getContext().getFuture()將返回null。
參數(shù)回調(diào)有點(diǎn)類似于本地 Callback 機(jī)制,但 Callback 并不是 Dubbo 內(nèi)部的類或接口,而是由 Provider 端自定義的;Dubbo 將基于長連接生成反向代理,從而實(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<String, CallbackListener> listeners = new ConcurrentHashMap<String, CallbackListener>(); public CallbackServiceImpl() { Thread t = new Thread(new Runnable() { public void run() { while (true) { try { for (Map.Entry<String, CallbackListener> 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ù):
<bean id="callbackService" class="com.alibaba.dubbo.samples.callback.impl.CallbackServiceImpl"/> <dubbo:service interface="com.alibaba.dubbo.samples.callback.api.CallbackService" ref="callbackService" connections="1" callbacks="1000"> <dubbo:method name="addListener"> <!-- index 表示參數(shù)索引,如下 index=1 ,表示第一個(gè)參數(shù)是 callback 回調(diào)參數(shù) --> <dubbo:argument index="1" callback="true"/> <!--<dubbo:argument type="com.demo.CallbackListener" callback="true" />--> </dubbo:method> </dubbo:service>
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 端會自動 export 一個(gè) Callback 服務(wù)。而 Provider 端在處理調(diào)用時(shí),判斷如果參數(shù)是 Callback,則生成了一個(gè) proxy,因此服務(wù)實(shí)現(xiàn)類里在調(diào)用 Callback 方法的時(shí)候,會被傳遞到 Consumer 端執(zhí)行 Callback 實(shí)現(xiàn)類的代碼。
事件通知允許 Consumer 端在調(diào)用之前、調(diào)用之后或出現(xiàn)異常時(shí),觸發(fā) oninvoke、onreturn、onthrow 三個(gè)事件。
可以通過在配置 Consumer 時(shí),指定事件需要通知的方法,如:
<bean id="demoCallback" class="com.alibaba.dubbo.samples.notify.impl.NotifyImpl" /> <dubbo:reference id="demoService" check="false" interface="com.alibaba.dubbo.samples.notify.api.DemoService" version="1.0.0" group="cn"> <dubbo:method name="sayHello" onreturn="demoCallback.onreturn" onthrow="demoCallback.onthrow"/> </dubbo:reference>
其中,NotifyImpl 的代碼如下:
public class NotifyImpl implements Notify { public Map<Integer, String> ret = new HashMap<Integer, String>(); 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í)行的。
目前暫時(shí)不支持,后續(xù)可能采用基于 JTA/XA 規(guī)范實(shí)現(xiàn)
可以通過服務(wù)降級功能臨時(shí)屏蔽某個(gè)出錯(cuò)的非關(guān)鍵服務(wù),并定義降級后的返回策略。
向注冊中心寫入動態(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)方對該服務(wù)的方法調(diào)用都直接返回 null 值,不發(fā)起遠(yuǎn)程調(diào)用。用來屏蔽不重要的服務(wù)不可用時(shí),對調(diào)用方的影響。
還可以改為 mock=fail:return+null 表示消費(fèi)方對該服務(wù)的方法調(diào)用在失敗后,再返回 null 值,不拋異常。用來容忍不重要服務(wù)不穩(wěn)定時(shí)對調(diào)用方的影響。
Dubbo 是通過 JDK 的 ShutdownHook 來完成優(yōu)雅停機(jī)的,所以如果使用 kill -9 PID 等強(qiáng)制關(guān)閉指令,是不會執(zhí)行優(yōu)雅停機(jī)的,只有通過 kill PID 時(shí),才會執(zhí)行。
服務(wù)提供方:停止時(shí),先標(biāo)記為不接收新請求,新請求過來時(shí)直接報(bào)錯(cuò),讓客戶端重試其它機(jī)器。然后,檢測線程池中的線程是否正在運(yùn)行,如果有,等待所有線程執(zhí)行完成,除非超時(shí),則強(qiáng)制關(guān)閉。
服務(wù)消費(fèi)方:停止時(shí),不再發(fā)起新的調(diào)用請求,所有新的調(diào)用在客戶端即報(bào)錯(cuò)。然后,檢測有沒有請求的響應(yīng)還沒有返回,等待響應(yīng)返回,除非超時(shí),則強(qiáng)制關(guā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)建它們的會話。一旦會話結(jié)束,臨時(shí)節(jié)點(diǎn)將被自動刪除,當(dāng)然可以也可以手動刪除。另外,需要注意是,ZooKeeper的臨時(shí)節(jié)點(diǎn)不允許擁有子節(jié)點(diǎn)。
ZooKeeper的永久節(jié)點(diǎn):該節(jié)點(diǎn)的生命周期不依賴于會話,并且只有在客戶端顯示執(zhí)行刪除操作的時(shí)候,他們才能被刪除。
在分布式系統(tǒng)中,我們常常需要知道某個(gè)機(jī)器是否可用,傳統(tǒng)的開發(fā)中,可以通過Ping某個(gè)主機(jī)來實(shí)現(xiàn),Ping得通說明對方是可用的,相反是不可用的。
在 ZK 中我們讓所有的機(jī)器都注冊一個(gè)臨時(shí)節(jié)點(diǎn),要判斷一個(gè)節(jié)點(diǎn)是否可用,我們只需要判斷這個(gè)臨時(shí)節(jié)點(diǎn)在 ZK 中是否存在就可以了,不需要直接去連接需要檢查的機(jī)器,降低系統(tǒng)的復(fù)雜度。
讀操作建議使用 Failover 失敗自動切換,默認(rèn)重試兩次其他服務(wù)器。
寫操作建議使用 Failfast 快速失敗,發(fā)一次調(diào)用失敗就立即報(bào)錯(cuò)。
Dubbo 可以使用 Pinpoint 和 Apache Skywalking(Incubator) 實(shí)現(xiàn)分布式服務(wù)追蹤,當(dāng)然還有其他很多方案。
管理控制臺主要包含:路由規(guī)則,動態(tài)配置,服務(wù)降級,訪問控制,權(quán)重調(diào)整,負(fù)載均衡,等管理功能。
到此,相信大家對“dubbo的重要知識點(diǎn)總結(jié)”有了更深的了解,不妨來實(shí)際操作一番吧!這里是創(chuàng)新互聯(lián)網(wǎng)站,更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢,關(guān)注我們,繼續(xù)學(xué)習(xí)!
當(dāng)前標(biāo)題:dubbo的重要知識點(diǎn)總結(jié)
文章來源:http://vcdvsql.cn/article46/gjcshg.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供營銷型網(wǎng)站建設(shè)、網(wǎng)站內(nèi)鏈、網(wǎng)站營銷、小程序開發(fā)、網(wǎng)站改版、手機(jī)網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)