您好,登錄后才能下訂單哦!
本篇內容主要講解“Java Dubbo框架知識點總結”,感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷,實用性強。下面就讓小編來帶大家學習“Java Dubbo框架知識點總結”吧!
Dubbo 是一個分布式、高性能、透明化的 RPC 服務框架,提供服務自動注冊、自動發現等高效服務治理方案, 可以和 Spring 框架無縫集成。
RPC 指的是遠程調用協議,也就是說兩個服務器交互數據。
互聯網的快速發展,Web應用程序的規模不斷擴大,一般會經歷如下四個發展階段。
單一應用架構:當網站流量很小時,只需一個應用,將所有功能都部署在一起即可。
垂直應用架構:當訪問量逐漸增大,單一應用按照有業務線拆成多個應用,以提升效率。此時,用于加速前端頁面開發的 Web框架(MVC) 是關鍵。
分布式服務架構:當垂直應用越來越多,應用之間交互不可避免,將核心業務抽取出來,作為獨立的服務,逐漸形成穩定的服務中心,使前端應用能更快速的響應多變的市場需求。此時,用于提高業務復用及整合的 分布式服務框架(RPC) 是關鍵。
流動計算架構:當服務越來越多,容量的評估,小服務資源的浪費等問題逐漸顯現,此時需增加一個調度中心基于訪問壓力實時管理集群容量,提高集群利用率。此時,用于提高機器利用率的 資源調度和治理中心(SOA) 是關鍵。
透明化的遠程方法調用,就像調用本地方法一樣調用遠程方法,只需簡單配置,沒有任何API侵入。
軟負載均衡及容錯機制,可在內網替代F5等硬件負載均衡器,降低成本,減少單點。
服務自動注冊與發現,不再需要寫死服務提供方地址,注冊中心基于接口名查詢服務提供者的IP地址,并且能夠平滑添加或刪除服務提供者。
Remoting:網絡通信框架,提供對多種NIO框架抽象封裝,包括“同步轉異步”和“請求-響應”模式的信息交換方式。
Cluster:服務框架,提供基于接口方法的透明遠程過程調用,包括多協議支持,以及軟負載均衡,失敗容錯,地址路由,動態配置等集群支持。
Registry:服務注冊,基于注冊中心目錄服務,使服務消費方能動態的查找服務提供方,使地址透明,使服務提供方可以平滑增加或減少機器。
組件角色 | 說明 |
Provider | 暴露服務的服務提供方 |
Consumer | 調用遠程服務的服務消費方 |
Registry | 服務注冊與發現的注冊中心 |
Monitor | 統計服務的調用次數和調用時間的監控中心 |
Container | 服務運行容器 |
Provider(提供者)綁定指定端口并啟動服務
提供者連接注冊中心,并發本機IP、端口、應用信息和提供服務信息發送至注冊中心存儲
Consumer(消費者),連接注冊中心,并發送應用信息、所求服務信息至注冊中心
注冊中心根據消費者所求服務信息匹配對應的提供者列表發送至Consumer應用緩存
Consumer在發起遠程調用時基于緩存的消費者列表擇其一發起調用
Consumer與Provider解耦,雙方都可以橫向增減節點數
注冊中心本身可做對等集群,可動態增減節點,并且任意一臺宕掉后,將自動切換到另一臺
去中心化,雙方不直接依懶注冊中心,即使注冊中心全部宕機短時間內也不會影響服務的調用
服務接口層(Service):該層是與實際業務邏輯相關的,根據服務提供方和服務消費方的業務設計對應的接口和實現。
配置層(Config):對外配置接口,以ServiceConfig和ReferenceConfig為中心。
服務代理層(Proxy):服務接口透明代理,生成服務的客戶端Stub和服務器端Skeleton。
服務注冊層(Registry):封裝服務地址的注冊與發現,以服務URL為中心。
集群層(Cluster):封裝多個提供者的路由及負載均衡,并橋接注冊中心,以Invoker為中心。
監控層(Monitor):RPC調用次數和調用時間監控。
遠程調用層(Protocol):封裝RPC調用,以Invocation和Result為中心,擴展接口為Protocol、Invoker和Exporter。
信息交換層(Exchange):封裝請求響應模式,同步轉異步,以Request和Response為中心。
網絡傳輸層(Transport):抽象mina和netty為統一接口,以Message為中心。
dubbo:單一長連接和NIO異步通訊,適合大并發小數據量的服務調用,以及消費者遠大于提供者。傳輸協議TCP,異步,Hessian序列化
rmi:采用JDK標準的rmi協議實現,傳輸參數和返回參數對象需要實現Serializable接口,使用Java標準序列化機制,使用阻塞式短連接,傳輸數據包大小混合,消費者和提供者個數差不多,可傳文件,傳輸協議TCP。
Java序列化存在安全漏洞
webservice: 基于WebService的遠程調用協議,集成CXF實現,提供和原生WebService的互操作。多個短連接,基于HTTP傳輸,同步傳輸,適用系統集成和跨語言調用
http:基于Http表單提交的遠程調用協議,使用Spring的HttpInvoke實現。多個短連接,傳輸協議HTTP,傳入參數大小混合,提供者個數多于消費者,需要給應用程序和瀏覽器JS調用
hessian:集成Hessian服務,基于HTTP通訊,采用Servlet暴露服務,Dubbo內嵌Jetty作為服務器時默認實現,提供與Hession服務互操作。多個短連接,同步HTTP傳輸,Hessian序列化,傳入參數較大,提供者大于消費者,提供者壓力較大,可傳文件
默認使用dubbo協議。
Multicast注冊中心:Multicast注冊中心不需要任何中心節點,只要廣播地址,就能進行服務注冊和發現。基于網絡分組傳輸實現
Zookeeper注冊中心:基于分布式協調系統Zookeeper實現,采用Zookeeper的watch機制實現數據變更
redis注冊中心:基于redis實現,采用key/Map存儲,key存儲服務名和類型,Map中key存儲服務URL,value存儲服務過期時間。基于redis的發布/訂閱模式通知數據變更
Simple注冊中心
過多的服務URL,配置困難
負載均衡分配節點壓力過大的情況下也需要部署集群
服務依賴混亂,啟動順序不清晰
過多服務導致性能指標分析難度較大,需要監控
可以的,啟動Dubbo時,消費者會從Zookeeper拉取注冊的生產者的地址接口等數據,緩存在本地。
每次調用時,按照本地存儲的地址進行調用。
Dubbo采用全Spring配置方式,透明化接入應用,對應用沒有任何API侵入,只需用Spring加載Dubbo的配置即可,Dubbo基于Spring的Schema擴展進行加載。
默認使用NIO Netty框架
Random LoadBalance: 隨機選取提供者策略,有利于動態調整提供者權重。截面碰撞率高,調用次數越多,分布越均勻
RoundRobin LoadBalance: 輪循選取提供者策略,平均分布,但是存在請求累積的問題
LeastActive LoadBalance: 最少活躍調用策略,解決慢提供者接收更少的請求
ConstantHash LoadBalance: 一致性Hash策略,使相同參數請求總是發到同一提供者,一臺機器宕機,可以基于虛擬節點,分攤至其他提供者,避免引起提供者的劇烈變動
缺省值為Random隨機調用。
Failover Cluster:失敗自動切換,當出現失敗,重試其它服務器。通常用于讀操作,但重試會帶來更長延遲。
Failfast Cluster:快速失敗,只發起一次調用,失敗立即報錯。通常用于非冪等性的寫操作,比如新增記錄。
Failsafe Cluster:失敗安全,出現異常時,直接忽略。通常用于寫入審計日志等操作。
Failback Cluster:失敗自動恢復,后臺記錄失敗請求,定時重發。通常用于消息通知操作。
Forking Cluster:并行調用多個服務器,只要一個成功即返回。通常用于實時性要求較高的讀操作,但需要浪費更多服務資源。可通過 forks="2" 來設置最大并行數。
Broadcast Cluster:廣播調用所有提供者,逐個調用,任意一臺報錯則報錯 。通常用于通知所有提供者更新緩存或日志等本地資源信息。
Failover Cluster。
默認使用Hessian序列化,還有Duddo、FastJson、Java自帶序列化。
Dubbo超時時間設置有兩種方式:
服務提供者端設置超時時間,在Dubbo的用戶文檔中,推薦如果能在服務端多配置就盡量多配置,因為服務提供者比消費者更清楚自己提供的服務特性。
服務消費者端設置超時時間,如果在消費者端設置了超時時間,以消費者端為主,即優先級更高。因為服務調用方設置超時時間控制性更靈活。如果消費方超時,服務端線程不會定制,會產生警告。
21、服務調用超時問題
Dubbo在調用服務不成功時,默認是會重試兩次的。
Dubbo通過Token令牌防止用戶繞過注冊中心直連,然后在注冊中心上管理授權。Dubbo還提供服務黑白名單,來控制服務所允許的調用方。
DubboX基于Dubbo上做了一些擴展,如增加了服務可 restful 調用,更新了開源組件等。
大家熟知的就是Spring Cloud,當然國外也有類似的多個框架。
Dubbo是SOA時代的產物,它的關注點主要在于服務的調用,流量分發、流量監控和熔斷。而Spring Cloud誕生于微服務架構時代,考慮的是微服務治理的方方面面。另外,由于依托了Spring、Spring Boot,兩個框架在開始目標就不一致,Dubbo定位于服務治理,而Spirng Cloud是一個生態。
最大的區別:Dubbo底層是使用Netty這樣的NIO框架,是基于TCP協議傳輸的,配合以Hession序列化完成RPC通信。
而Spring Cloud是基于Http協議+Rest接口調用遠程過程的通信,相對來說,Http請求會有更大的報文,占用的帶寬也會更多。但是REST相比RPC更為靈活,服務提供方和調用方的依賴只依靠一紙契約,不存在代碼級別的強依賴,這在強調快速演化的微服務環境下顯得更為合適。至于注重通信速度還是方便靈活性方面,具體情況具體考慮。
定義一個Service Interface:(HelloService.java)
package com.x.hello.api; public interface HelloService { String sayHello(String name); }
接口的實現類:(HelloServiceImpl.java)
package com.x.hello.impl; import com.x.hello.api.HelloService; public class HelloServiceImpl implements HelloService { public String sayHello(String name){ return "Hello" + name; } }
Spring配置:(provider.xml)
<?xmlversion="1.0"encoding="UTF-8"?> <beans> <!--Application name--> <dubbo:applicationname="hello-world-app"/> <!--registry address, used for service to register itself--> <dubbo:registryaddress="multicast://224.5.6.7:1234"/> <!--expose this service through dubbo protocol, through port 20880--> <dubbo:protocolname="dubbo" port="20880"/> <!--which service interface do we expose?--> <dubbo:serviceinterface="com.x.hello.api.HelloService" ref="helloService"/> <!--designate implementation--> <beanid="helloService" class="com.x.hello.impl.HelloServiceImpl"/> </beans>
測試代碼:(Provider.java)
import org.springframework.context.support.ClassPathXmlApplicationContext; public class Provider { public static void main(String[] args){ // 啟動成功,監聽端口為20880 ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(newString[]{"provider.xml"}); // 按任意鍵退出 System.in.read(); } }
Spring配置文件:(consumer.xml)
<?xmlversion="1.0"encoding="UTF-8"?> <beans> <!--consumer application name--> <dubbo:applicationname="consumer-of-helloworld-app"/> <!--registry address, used for consumer to discover services--> <dubbo:registryaddress="multicast://224.5.6.7:1234"/> <!--whichservicetoconsume?--> <dubbo:referenceid="helloService" interface="com.x.hello.api.HelloService"/> </beans>
客戶端測試代碼:(Consumer.java)
import org.springframework.context.support.ClassPathXmlApplicationContext; import com.alibaba.hello.api.HelloService; public class Consumer { public static void main(String[] args) { ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(newString[]{"consumer.xml"}); // Get service invocation proxy HelloService helloService =(HelloService)context.getBean("helloService"); // Do invoke! String hello = helloService.sayHello("world"); System.out.println(hello); } }
到此,相信大家對“Java Dubbo框架知識點總結”有了更深的了解,不妨來實際操作一番吧!這里是億速云網站,更多相關內容可以進入相關頻道進行查詢,關注我們,繼續學習!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。