網(wǎng)絡(luò)通信

協(xié)議

• TCP/IP

擴展：由網(wǎng)絡(luò)層的IP協(xié)議和傳輸層的TCP協(xié)議組成,TCP負責(zé)發(fā)現(xiàn)傳輸?shù)膯栴}，一有問題就發(fā)出信號，要求重新傳輸，直到所有數(shù)據(jù)安全正確地傳輸?shù)侥康牡亍６鳬P是給因特網(wǎng)的每一臺聯(lián)網(wǎng)設(shè)備規(guī)定一個地址。

• UDP/IP
• Multicast

IO

• BIO
• NIO
• AIO

基于消息方式的系統(tǒng)間通信

1.當(dāng)系統(tǒng)之間要通信時，就向外發(fā)送消息，消息可以使字節(jié)流、字節(jié)數(shù)組，甚至是java對象，其他系統(tǒng)收到消息后則進行相應(yīng)的業(yè)務(wù)處理。消息方式的通信，通常是基于網(wǎng)絡(luò)協(xié)議來實現(xiàn)的，常用的系統(tǒng)間通信的協(xié)議有：TCP/IP和UDP/IP

2.TCP/IP是一種可靠的網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)膮f(xié)議。TCP/IP要求通信雙方首先建立連接，之后再進行數(shù)據(jù)的傳輸TCP/IP負責(zé)保證數(shù)據(jù)傳輸?shù)目煽啃裕〝?shù)據(jù)的可到達、數(shù)據(jù)到達的順序等。但由于TCP/IP需要保證連接及數(shù)據(jù)傳輸?shù)目煽浚虼丝赡軙奚恍┬阅堋?/p>

3.UDP/IP是一種不保證數(shù)據(jù)一定到達的網(wǎng)絡(luò)數(shù)據(jù)傳輸協(xié)議。UDP/IP并不直接給通信雙方建立連接，而是發(fā)送發(fā)到網(wǎng)絡(luò)上進行傳遞。由于UDP/IP不建立連接，并且不能保證數(shù)據(jù)傳輸?shù)目煽浚虼诵阅苌媳憩F(xiàn)相對較好，但是可能會出現(xiàn)數(shù)據(jù)丟失以及數(shù)據(jù)亂序的現(xiàn)象。

4.TCP/IP和UDP/IP可用于完成數(shù)據(jù)的傳輸，但是要完成系統(tǒng)間通信，還需要對數(shù)據(jù)進行處理。列如讀取和寫入數(shù)據(jù)，按照標準分為同步IO和異步IO兩種。其中同步IO中最常用的是BIO(Blocking IO)和NIO(Non-Blocking IO)

5.從程序角度而言，BIO就是當(dāng)發(fā)起IO的讀取或?qū)懖僮鲿r，均為阻塞方式，只有當(dāng)程序讀到了流或?qū)⒘鲗懭氩僮飨到y(tǒng)后才釋放資源。f.NIO是基于事件驅(qū)動思想的，實現(xiàn)上通常采用Reactor模式，從程序角度而言，當(dāng)發(fā)起IO的讀或?qū)懖僮鲿r，是非租塞的。

基于Java包

• TCP/IP

(BIO)Socket ServerSocket一連接一線程.一個socket需要一個線程處理。建立連接、讀數(shù)據(jù)，寫數(shù)據(jù)的操作都可能阻塞。為了支持并發(fā)連接需要線程池

(NIO)SocketChannel ServerSocketChannel服務(wù)端一個線程監(jiān)聽連接的事件，一個或多個線程來監(jiān)聽網(wǎng)絡(luò)讀寫事件。當(dāng)有實際的網(wǎng)絡(luò)流讀寫事件發(fā)生后，再放入線程池中處理。一請求一線程.NIO的明顯好處就是不需要為每一個socket分配一個線程，而可以在一個線程中處理多個scoket。

• UDP/IP
• Multicast

組播（Multicast）傳輸：在發(fā)送者和每一接收者之間實現(xiàn)點對多點網(wǎng)絡(luò)連接。如果一臺發(fā)送者同時給多個的接收者傳輸相同的數(shù)據(jù)，也只需復(fù)制一份的相同數(shù)據(jù)包。它提高了數(shù)據(jù)傳送效率。減少了骨干網(wǎng)絡(luò)出現(xiàn)擁塞的可能性。

開源框架

• Netty
• Mina(apache，基于java NIO，對外屏蔽了JavaNIO的復(fù)雜性)

性能角度

連接管理

連接池連接復(fù)用短連接、長連接

基于遠程調(diào)用方式的系統(tǒng)間通信

遠程調(diào)用方式應(yīng)該可能的是系統(tǒng)間的通信和系統(tǒng)內(nèi)部一樣，讓使用者感覺調(diào)用遠程同調(diào)用本地一樣，但其實并沒有辦法做到完全透明。由于遠程調(diào)用帶來的網(wǎng)絡(luò)問題、超時問題，序列化反序列化問題、復(fù)雜調(diào)試問

基于java包

• RMI(Remote Method Invocation)

原理：client----[proxy]----->封裝對象、序列化為流<----[TCP/IP BIO]---->反序列化、調(diào)用----->反射調(diào)用實例對象

• webservice

開源框架

• Spring RMI(簡單就實現(xiàn)RMI方式的java遠程調(diào)用)
• Apache CXF

性能角度

• 反射
• 序列化、反序列化

消息通信

• rabbitmq
• kafka

大型分布式應(yīng)用架構(gòu)基礎(chǔ)

單體架構(gòu)

在java領(lǐng)域可以理解為一個javaweb應(yīng)用。

分布式架構(gòu)

什么是傳統(tǒng)的分布式架構(gòu)？簡單來說，按照業(yè)務(wù)垂直切分，每個應(yīng)用都是單體架構(gòu)，通過API相互調(diào)用。

面向服務(wù)的SOA架構(gòu)

• 背景：

在構(gòu)建了共用業(yè)務(wù)邏輯系統(tǒng)和拆分系統(tǒng)后，最明顯的問題就是系統(tǒng)之間如何交互。如果不控制會出現(xiàn)系統(tǒng)之間存在多種交互方式：http、TCP/IP+NIO、Hessian、RMI、WebService等;同步異步都可能出現(xiàn)，這會導(dǎo)致開發(fā)人員每訪問一個共用業(yè)務(wù)邏輯系統(tǒng)或拆分出來的系統(tǒng)，都有可能需要學(xué)習(xí)不同交互方式；同時也會造成各開發(fā)團隊重復(fù)造輪子，提供不同交互方式用的框架，這對于應(yīng)用的性能可用性而言帶來了極大的挑戰(zhàn)。

• 關(guān)于SOA

面向服務(wù)的家否是一種軟件體系結(jié)構(gòu)，其應(yīng)用程序的不同組件通過網(wǎng)絡(luò)上的協(xié)議向其他提供服務(wù)和消費服務(wù)。簡單來說，soa是不同業(yè)務(wù)建立不同的服務(wù)，服務(wù)之間的數(shù)據(jù)交互可以通過服務(wù)接口分級，這樣松散耦合提高服務(wù)的可重用性，也讓業(yè)務(wù)邏輯變得可組合，并且每個服務(wù)根據(jù)適應(yīng)情況作出合理的分布式部署，從而讓服務(wù)變得規(guī)范、高性能、高可用。soa架構(gòu)中兩個主要角色：服務(wù)提供者(provider)和服務(wù)消費者(consumer).阿里開源的Dubbo是soa的典型實現(xiàn)。

微服務(wù)架構(gòu)

將單一程序開發(fā)成一個微服務(wù)，每個微服務(wù)運行在自己的進程中，并使用輕量級機制通信，通常采用HTTP RestFul API.這些服務(wù)圍繞業(yè)務(wù)能力來劃分構(gòu)建的，并通過全完自動化部署機制來獨立部署。這些服務(wù)可以使用不同的編程需要，以及不同數(shù)據(jù)存儲技術(shù)，以保證最低限度的集中式管理。

SOA和微服務(wù)架構(gòu)的區(qū)別

SOA往往與企業(yè)服務(wù)總線（ESB）聯(lián)系在一起，主要原因在于SOA的實施思路是根據(jù)ESB模式來整合集成大量單一龐大的系統(tǒng)，這是soa主要的落地方式。微服務(wù)相對于和ESB聯(lián)系在一起的SOA顯示輕便敏捷得多，微服務(wù)將復(fù)雜的業(yè)務(wù)組件化，實際也是一種面向服務(wù)思想的體現(xiàn)。對于微服務(wù)來說，它是SOA的一種體現(xiàn)，但是它比ESB實現(xiàn)的SOA更加輕便、敏捷和簡單。

 以上就是動力節(jié)點小編介紹的"Java分布式基礎(chǔ)學(xué)習(xí)指南"，希望對大家有幫助，如有疑問，請在線咨詢，有專業(yè)老師隨時為您服務(wù)。