開放式系統(tǒng)互聯(lián)通信參考模型（英語(yǔ)：Open System Interconnection Reference Model，縮寫為 OSI），簡(jiǎn)稱為OSI模型（OSI model），一種概念模型，由國(guó)際標(biāo)準(zhǔn)化組織（iso）提出，一個(gè)試圖使各種計(jì)算機(jī)在世界范圍內(nèi)互連為網(wǎng)絡(luò)的標(biāo)準(zhǔn)框架。定義于ISO/IEC 7498-1
它是一個(gè)七層的、抽象的模型體，不僅包括一系列抽象的術(shù)語(yǔ)或概念，也包括具體的協(xié)議。
作用如下：
應(yīng)用層
網(wǎng)絡(luò)服務(wù)與最終用戶的一個(gè)接口。
協(xié)議有：HTTP FTP TFTP SMTP SNMP DNS TELNET HTTPS POP3 DHCP
表示層
數(shù)據(jù)的表示、安全、壓縮。（在五層模型里面已經(jīng)合并到了應(yīng)用層）
格式有，JPEG、ASCll、DECOIC、加密格式等
會(huì)話層
建立、管理、終止會(huì)話。（在五層模型里面已經(jīng)合并到了應(yīng)用層）
對(duì)應(yīng)主機(jī)進(jìn)程，指本地主機(jī)與遠(yuǎn)程主機(jī)正在進(jìn)行的會(huì)話
傳輸層
定義傳輸數(shù)據(jù)的協(xié)議端口號(hào)，以及流控和差錯(cuò)校驗(yàn)。
協(xié)議有：TCP UDP，數(shù)據(jù)包一旦離開網(wǎng)卡即進(jìn)入網(wǎng)絡(luò)傳輸層
網(wǎng)絡(luò)層
進(jìn)行邏輯地址尋址，實(shí)現(xiàn)不同網(wǎng)絡(luò)之間的路徑選擇。
協(xié)議有：ICMP IGMP IP（IPV4 IPV6） ARP RARP
數(shù)據(jù)鏈路層
建立邏輯連接、進(jìn)行硬件地址尋址、差錯(cuò)校驗(yàn)?[2]??等功能。（由底層網(wǎng)絡(luò)定義協(xié)議）
將比特組合成字節(jié)進(jìn)而組合成幀，用MAC地址訪問介質(zhì)，錯(cuò)誤發(fā)現(xiàn)但不能糾正。
物理層
建立、維護(hù)、斷開物理連接。（由底層網(wǎng)絡(luò)定義協(xié)議）
TCP/IP 層級(jí)模型結(jié)構(gòu)，應(yīng)用層之間的協(xié)議通過逐級(jí)調(diào)用傳輸層（Transport layer）、網(wǎng)絡(luò)層（Network Layer）和物理數(shù)據(jù)鏈路層（Physical Data Link）而可以實(shí)現(xiàn)應(yīng)用層的應(yīng)用程序通信互聯(lián)。
需要知道并了解的協(xié)議
http協(xié)議：在應(yīng)用層
作用
HTTP是客戶端瀏覽器或其他程序與Web服務(wù)器之間的應(yīng)用層通信協(xié)議。在Internet上的Web服務(wù)器上存放的都是超文本信息，客戶機(jī)需要通過HTTP協(xié)議傳輸所要訪問的超文本信息。
HTTP包含命令和傳輸信息，不僅可用于Web訪問，也可以用于其他因特網(wǎng)/內(nèi)聯(lián)網(wǎng)應(yīng)用系統(tǒng)之間的通信，從而實(shí)現(xiàn)各類應(yīng)用資源超媒體訪問的集成。
工作原理
HTTP是基于客戶/服務(wù)器模式，且面向連接的。典型的HTTP事務(wù)處理有如下的過程：?
（1）客戶與服務(wù)器建立連接；
（2）客戶向服務(wù)器提出請(qǐng)求；
（3）服務(wù)器接受請(qǐng)求，并根據(jù)請(qǐng)求返回相應(yīng)的文件作為應(yīng)答；
（4）客戶與服務(wù)器關(guān)閉連接。
客戶與服務(wù)器之間的HTTP連接是一種一次性連接，它限制每次連接只處理一個(gè)請(qǐng)求，當(dāng)服務(wù)器返回本次請(qǐng)求的應(yīng)答后便立即關(guān)閉連接，下次請(qǐng)求再重新建立連接。這種一次性連接主要考慮到WWW服務(wù)器面向的是Internet中成干上萬(wàn)個(gè)用戶，且只能提供有限個(gè)連接，故服務(wù)器不會(huì)讓一個(gè)連接處于等待狀態(tài)，及時(shí)地釋放連接可以大大提高服務(wù)器的執(zhí)行效率。?[8]
HTTP是一種無狀態(tài)協(xié)議，即服務(wù)器不保留與客戶交易時(shí)的任何狀態(tài)。這就大大減輕了服務(wù)器記憶負(fù)擔(dān)，從而保持較快的響應(yīng)速度。HTTP是一種面向?qū)ο蟮膮f(xié)議。允許傳送任意類型的數(shù)據(jù)對(duì)象。它通過數(shù)據(jù)類型和長(zhǎng)度來標(biāo)識(shí)所傳送的數(shù)據(jù)內(nèi)容和大小，并允許對(duì)數(shù)據(jù)進(jìn)行壓縮傳送。當(dāng)用戶在一個(gè)HTML文檔中定義了一個(gè)超文本鏈后，瀏覽器將通過TCP/IP協(xié)議與指定的服務(wù)器建立連接。?[8]
從技術(shù)上講是客戶在一個(gè)特定的TCP端口（端口號(hào)一般為80）上打開一個(gè)套接字。如果服務(wù)器一直在這個(gè)周知的端口上傾聽連接，則該連接便會(huì)建立起來。然后客戶通過該連接發(fā)送一個(gè)包含請(qǐng)求方法的請(qǐng)求塊。
HTTP規(guī)范定義了9種請(qǐng)求方法，每種請(qǐng)求方法規(guī)定了客戶和服務(wù)器之間不同的信息交換方式，常用的請(qǐng)求方法是GET和POST。服務(wù)器將根據(jù)客戶請(qǐng)求完成相應(yīng)操作，并以應(yīng)答塊形式返回給客戶，最后關(guān)閉連接。
https協(xié)議：在應(yīng)用層和ssl層（應(yīng)用層和傳輸層之間）
作用
HTTPS 協(xié)議是由 HTTP 加上?TLS/SSL?協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，主要通過數(shù)字證書、加密算法、非對(duì)稱密鑰等技術(shù)完成互聯(lián)網(wǎng)數(shù)據(jù)傳輸加密，實(shí)現(xiàn)互聯(lián)網(wǎng)傳輸安全保護(hù)。設(shè)計(jì)目標(biāo)主要有三個(gè)。
（1）數(shù)據(jù)保密性：保證數(shù)據(jù)內(nèi)容在傳輸?shù)倪^程中不會(huì)被第三方查看。就像快遞員傳遞包裹一樣，都進(jìn)行了封裝，別人無法獲知里面裝了什么?[4]?。
（2）數(shù)據(jù)完整性：及時(shí)發(fā)現(xiàn)被第三方篡改的傳輸內(nèi)容。就像快遞員雖然不知道包裹里裝了什么東西，但他有可能中途掉包，數(shù)據(jù)完整性就是指如果被掉包，我們能輕松發(fā)現(xiàn)并拒收?[4]?。
（3）身份校驗(yàn)安全性：保證數(shù)據(jù)到達(dá)用戶期望的目的地。就像我們郵寄包裹時(shí)，雖然是一個(gè)封裝好的未掉包的包裹，但必須確定這個(gè)包裹不會(huì)送錯(cuò)地方，通過身份校驗(yàn)來確保送對(duì)了地方
與HTTP原理區(qū)別
HTTPS 主要由兩部分組成：HTTP + SSL / TLS，也就是在 HTTP 上又加了一層處理加密信息的模塊。服務(wù)端和客戶端的信息傳輸都會(huì)通過 TLS 進(jìn)行加密，所以傳輸?shù)臄?shù)據(jù)都是加密后的數(shù)據(jù)。
HTTP 原理
① 客戶端的瀏覽器首先要通過網(wǎng)絡(luò)與服務(wù)器建立連接，該連接是通過TCP 來完成的，一般 TCP 連接的端口號(hào)是80。 建立連接后，客戶機(jī)發(fā)送一個(gè)請(qǐng)求給服務(wù)器，請(qǐng)求方式的格式為：統(tǒng)一資源標(biāo)識(shí)符（URL）、協(xié)議版本號(hào)，后邊是 MIME 信息包括請(qǐng)求修飾符、客戶機(jī)信息和許可內(nèi)容??。
② 服務(wù)器接到請(qǐng)求后，給予相應(yīng)的響應(yīng)信息，其格式為一個(gè)狀態(tài)行，包括信息的協(xié)議版本號(hào)、一個(gè)成功或錯(cuò)誤的代碼，后邊是 MIME 信息包括服務(wù)器信息、實(shí)體信息和可能的內(nèi)容?[2]?。
HTTPS 原理
① 客戶端將它所支持的算法列表和一個(gè)用作產(chǎn)生密鑰的隨機(jī)數(shù)發(fā)送給服務(wù)器??；
② 服務(wù)器從算法列表中選擇一種加密算法，并將它和一份包含服務(wù)器公用密鑰的證書發(fā)送給客戶端；該證書還包含了用于認(rèn)證目的的服務(wù)器標(biāo)識(shí)，服務(wù)器同時(shí)還提供了一個(gè)用作產(chǎn)生密鑰的隨機(jī)數(shù)?[2]?；
③ 客戶端對(duì)服務(wù)器的證書進(jìn)行驗(yàn)證（有關(guān)驗(yàn)證證書，可以參考數(shù)字簽名），并抽取服務(wù)器的公用密鑰；然后，再產(chǎn)生一個(gè)稱作 pre_master_secret 的隨機(jī)密碼串，并使用服務(wù)器的公用密鑰對(duì)其進(jìn)行加密（參考非對(duì)稱加 / 解密），并將加密后的信息發(fā)送給服務(wù)器?[2]?；
④ 客戶端與服務(wù)器端根據(jù) pre_master_secret 以及客戶端與服務(wù)器的隨機(jī)數(shù)值獨(dú)立計(jì)算出加密和?MAC密鑰（參考 DH密鑰交換算法）??；
⑤ 客戶端將所有握手消息的 MAC 值發(fā)送給服務(wù)器?[2]?；
⑥ 服務(wù)器將所有握手消息的 MAC 值發(fā)送給客戶端?[2]?。
優(yōu)缺點(diǎn)
優(yōu)點(diǎn)
使用 HTTPS 協(xié)議可認(rèn)證用戶和服務(wù)器，確保數(shù)據(jù)發(fā)送到正確的客戶機(jī)和服務(wù)器?[2]?；
HTTPS 協(xié)議是由 SSL+HTTP 協(xié)議構(gòu)建的可進(jìn)行加密傳輸、身份認(rèn)證的網(wǎng)絡(luò)協(xié)議，要比 HTTP 協(xié)議安全，可防止數(shù)據(jù)在傳輸過程中不被竊取、改變，確保數(shù)據(jù)的完整性?[2]?。
HTTPS 是現(xiàn)行架構(gòu)下最安全的解決方案，雖然不是絕對(duì)安全，但它大幅增加了中間人攻擊的成本?[2]?。
缺點(diǎn)
相同網(wǎng)絡(luò)環(huán)境下，HTTPS 協(xié)議會(huì)使頁(yè)面的加載時(shí)間延長(zhǎng)近 50%，增加 10%到 20%的耗電。此外，HTTPS 協(xié)議還會(huì)影響緩存，增加數(shù)據(jù)開銷和功耗?[2]?。
HTTPS 協(xié)議的安全是有范圍的，在黑客攻擊、拒絕服務(wù)攻擊和服務(wù)器劫持等方面幾乎起不到什么作用?[2]?。
最關(guān)鍵的是，SSL 證書的信用鏈體系并不安全。特別是在某些國(guó)家可以控制?CA?根證書的情況下，中間人攻擊一樣可行?[2]?。
成本增加。部署 HTTPS 后，因?yàn)?HTTPS 協(xié)議的工作要增加額外的計(jì)算資源消耗，例如 SSL 協(xié)議加密算法和 SSL 交互次數(shù)將占用一定的計(jì)算資源和服務(wù)器成本。在大規(guī)模用戶訪問應(yīng)用的場(chǎng)景下，服務(wù)器需要頻繁地做加密和解密操作，幾乎每一個(gè)字節(jié)都需要做加解密，這就產(chǎn)生了服務(wù)器成本。隨著云計(jì)算技術(shù)的發(fā)展，數(shù)據(jù)中心部署的服務(wù)器使用成本在規(guī)模增加后逐步下降，相對(duì)于用戶訪問的安全提升，其投入成本已經(jīng)下降到可接受程度?[4]?。
RPC協(xié)議
英文原義：Remote Procedure Call Protocol
中文釋義：（RFC-1831）遠(yuǎn)程調(diào)用協(xié)議 ,最初由RFC-1050定義。
注解：一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請(qǐng)求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。
RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。
RPC采用客戶機(jī)/服務(wù)器模式。請(qǐng)求程序就是一個(gè)客戶機(jī)，而服務(wù)提供程序就是一個(gè)服務(wù)器。首先，調(diào)用進(jìn)程發(fā)送一個(gè)有進(jìn)程參數(shù)的調(diào)用信息到服務(wù)進(jìn)程，然后等待應(yīng)答信息。在服務(wù)器端，進(jìn)程保持睡眠狀態(tài)直到調(diào)用信息的到達(dá)為止。當(dāng)一個(gè)調(diào)用信息到達(dá)，服務(wù)器獲得進(jìn)程參數(shù)，計(jì)算結(jié)果，發(fā)送答復(fù)信息，然后等待下一個(gè)調(diào)用信息，最后，客戶端調(diào)用過程接收答復(fù)信息，獲得進(jìn)程結(jié)果，然后調(diào)用執(zhí)行繼續(xù)進(jìn)行。
目前，有多種RPC模式和執(zhí)行。最初由Sun公司提出。IETF ONC憲章重新修訂了Sun版本，使得ONC RPC協(xié)議成為IETF標(biāo)準(zhǔn)協(xié)議?，F(xiàn)在使用最普遍的模式和執(zhí)行是開放式軟件基礎(chǔ)的分布式計(jì)算環(huán)境（DCE）。
遠(yuǎn)程過程調(diào)用（RPC）信息協(xié)議由兩個(gè)不同結(jié)構(gòu)組成：調(diào)用信息和答復(fù)信息。
rpc調(diào)用過程
常用到的rpc框架
目前常用的RPC框架如下：
Thrift：thrift是一個(gè)軟件框架，用來進(jìn)行可擴(kuò)展且跨語(yǔ)言的服務(wù)的開發(fā)。它結(jié)合了功能強(qiáng)大的軟件堆棧和代碼生成引擎，以構(gòu)建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 這些編程語(yǔ)言間無縫結(jié)合的、高效的服務(wù)。
Dubbo：Dubbo是一個(gè)分布式服務(wù)框架，以及SOA治理方案。其功能主要包括：高性能NIO通訊及多協(xié)議集成，服務(wù)動(dòng)態(tài)尋址與路由，軟負(fù)載均衡與容錯(cuò)，依賴分析與降級(jí)等。 Dubbo是阿里巴巴內(nèi)部的SOA服務(wù)化治理方案的核心框架，Dubbo自2011年開源后，已被許多非阿里系公司使用。
Spring Cloud：Spring Cloud由眾多子項(xiàng)目組成，如Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等，提供了搭建分布式系統(tǒng)及微服務(wù)常用的工具，如配置管理、服務(wù)發(fā)現(xiàn)、斷路器、智能路由、微代理、控制總線、一次性token、全局鎖、選主、分布式會(huì)話和集群狀態(tài)等，滿足了構(gòu)建微服務(wù)所需的所有解決方案。Spring Cloud基于Spring Boot, 使得開發(fā)部署極其簡(jiǎn)單。
gRPC: 一開始由 google 開發(fā)，是一款語(yǔ)言中立、平臺(tái)中立、開源的遠(yuǎn)程過程調(diào)用(RPC)系統(tǒng)。
bRPC：百度開源的rpc框架，是一個(gè)基于protobuf接口的RPC框架，在百度內(nèi)部稱為“baidu-rpc”，它囊括了百度內(nèi)部所有RPC協(xié)議，并支持多種第三方協(xié)議，從目前的性能測(cè)試數(shù)據(jù)來看，brpc的性能領(lǐng)跑于其他同類RPC產(chǎn)品。
Rest和RPC接口區(qū)別
接口調(diào)用通常包含兩個(gè)部分，序列化和通信協(xié)議。常見的序列化協(xié)議包括json、xml、hession、protobuf、thrift、text、bytes等；通信比較流行的是http、soap、websockect，RPC通?；赥CP實(shí)現(xiàn)，常用框架例如dubbo，netty、mina、thrift
首先解釋下兩種接口調(diào)用：
Rest：嚴(yán)格意義上說接口很規(guī)范，操作對(duì)象即為資源，對(duì)資源的四種操作（post、get、put、delete），并且參數(shù)都放在URL上,但是不嚴(yán)格的說Http+json、Http+xml，常見的http api都可以稱為Rest接口。
Rpc:我們常說的遠(yuǎn)程方法調(diào)用，就是像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法，通信協(xié)議大多采用二進(jìn)制方式
http vs 高性能二進(jìn)制協(xié)議
http相對(duì)更規(guī)范，更標(biāo)準(zhǔn)，更通用，無論哪種語(yǔ)言都支持http協(xié)議。如果你是對(duì)外開放API，例如開放平臺(tái)，外部的編程語(yǔ)言多種多樣，你無法拒絕對(duì)每種語(yǔ)言的支持，相應(yīng)的，如果采用http，無疑在你實(shí)現(xiàn)SDK之前，支持了所有語(yǔ)言，所以，現(xiàn)在開源中間件，基本最先支持的幾個(gè)協(xié)議都包含RESTful。
RPC協(xié)議性能要高的多，例如Protobuf、Thrift、Kyro等，（如果算上序列化）吞吐量大概能達(dá)到http的二倍。響應(yīng)時(shí)間也更為出色。千萬(wàn)不要小看這點(diǎn)性能損耗，公認(rèn)的，微服務(wù)做的比較好的，例如，netflix、阿里，曾經(jīng)都傳出過為了提升性能而合并服務(wù)。如果是交付型的項(xiàng)目，性能更為重要，因?yàn)槟阗u給客戶往往靠的就是性能上微弱的優(yōu)勢(shì)。RESTful
你可以看看，無論是Google、Amazon、netflix（據(jù)說很可能轉(zhuǎn)向grpc），還是阿里，實(shí)際上內(nèi)部都是采用性能更高的RPC方式。而對(duì)外開放的才是RESTful。
Rest 調(diào)用及測(cè)試都很方便，Rpc就顯得有點(diǎn)麻煩，但是Rpc的效率是毋庸置疑的，所以建議在多系統(tǒng)之間采用Rpc，對(duì)外提供服務(wù)，Rest是很適合的
duboo在生產(chǎn)者和消費(fèi)者兩個(gè)微服務(wù)之間的通信采用的就是Rpc,無疑在服務(wù)之間的調(diào)用Rpc更變現(xiàn)的優(yōu)秀
Rpc在微服務(wù)中的利用
1、 RPC 框架是架構(gòu)微服務(wù)化的首要基礎(chǔ)組件 ，它能大大降低架構(gòu)微服務(wù)化的成本，提高調(diào)用方與服務(wù)提供方的研發(fā)效率，屏蔽跨進(jìn)程調(diào)用函數(shù)（服務(wù)）的各類復(fù)雜細(xì)節(jié)
2、 RPC 框架的 職責(zé) 是： 讓調(diào)用方感覺就像調(diào)用本地函數(shù)一樣調(diào)用遠(yuǎn)端函數(shù)、讓服務(wù)提供方感覺就像實(shí)現(xiàn)一個(gè)本地函數(shù)一樣來實(shí)現(xiàn)服務(wù)
RPC的好處：
RPC 的主要功能目標(biāo)是讓構(gòu)建分布式計(jì)算（應(yīng)用）更容易，在提供強(qiáng)大的遠(yuǎn)程調(diào)用能力時(shí)不損失本地調(diào)用的語(yǔ)義簡(jiǎn)潔性。 為實(shí)現(xiàn)該目標(biāo)，RPC 框架需提供一種透明調(diào)用機(jī)制讓使用者不必顯式的區(qū)分本地調(diào)用和遠(yuǎn)程調(diào)用。
服務(wù)化的一個(gè)好處就是，不限定服務(wù)的提供方使用什么技術(shù)選型，能夠?qū)崿F(xiàn)大公司跨團(tuán)隊(duì)的技術(shù)解耦。
如果沒有統(tǒng)一的服務(wù)框架，RPC框架，各個(gè)團(tuán)隊(duì)的服務(wù)提供方就需要各自實(shí)現(xiàn)一套序列化、反序列化、網(wǎng)絡(luò)框架、連接池、收發(fā)線程、超時(shí)處理、狀態(tài)機(jī)等“業(yè)務(wù)之外”的重復(fù)技術(shù)勞動(dòng)，造成整體的低效。所以，統(tǒng)一RPC框架把上述“業(yè)務(wù)之外”的技術(shù)勞動(dòng)統(tǒng)一處理，是服務(wù)化首要解決的問題
幾種協(xié)議
Socket使用時(shí)可以指定協(xié)議Tcp,Udp等；
RIM使用Jrmp協(xié)議，Jrmp又是基于TCP/IP；
RPC底層使用Socket接口，定義了一套遠(yuǎn)程調(diào)用方法；
HTTP是建立在TCP上，不是使用Socket接口，需要連接方主動(dòng)發(fā)數(shù)據(jù)給服務(wù)器，服務(wù)器無法主動(dòng)發(fā)數(shù)據(jù)個(gè)客戶端；
Web Service提供的服務(wù)是基于web容器的，底層使用http協(xié)議，類似一個(gè)遠(yuǎn)程的服務(wù)提供者，比如天氣預(yù)報(bào)服務(wù)，對(duì)各地客戶端提供天氣預(yù)報(bào)，是一種請(qǐng)求應(yīng)答的機(jī)制，是跨系統(tǒng)跨平臺(tái)的。就是通過一個(gè)servlet，提供服務(wù)出去。
hessian是一套用于建立web service的簡(jiǎn)單的二進(jìn)制協(xié)議，用于替代基于XML的web service，是建立在rpc上的，hessian有一套自己的序列化格式將數(shù)據(jù)序列化成流，然后通過http協(xié)議發(fā)送給服務(wù)器
1、RMI（遠(yuǎn)程方法調(diào)用）
JAVA自帶的遠(yuǎn)程方法調(diào)用工具，不過有一定的局限性，畢竟是JAVA語(yǔ)言最開始時(shí)的設(shè)計(jì)，后來很多框架的原理都基于RMI，RMI的使用如下：
對(duì)外接口
<span style="font-size:12px;">public interface IService extends Remote {??
????public String queryName(String no) throws RemoteException;??
}</span>
服務(wù)實(shí)現(xiàn)
import java.rmi.RemoteException;
import java.rmi.server.UnicastRemoteObject;
// 服務(wù)實(shí)現(xiàn)
public class ServiceImpl extends UnicastRemoteObject implements IService {
/**
*/
? ? private static final long serialVersionUID =682805210518738166L;
/**
? ? * @throws RemoteException
? ? */
? ? protected ServiceImpl()throws RemoteException {
super();
}
/* (non-Javadoc)
* @see com.suning.ebuy.wd.web.IService#queryName(java.lang.String)
*/
? ? @Override
? ? public String queryName(String no)throws RemoteException {
// 方法的具體實(shí)現(xiàn)
? ? ? ? System.out.println("hello" +no);
return String.valueOf(System.currentTimeMillis());
}
}
RMI客戶端
[java]view plain copy
import java.rmi.AccessException;
import java.rmi.NotBoundException;
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
// RMI客戶端
public class Client {
public static void main(String[] args) {
// 注冊(cè)管理器
? ? ? ? Registry registry =null;
try {
// 獲取服務(wù)注冊(cè)管理器
? ? ? ? ? ? registry = LocateRegistry.getRegistry("127.0.0.1",8088);
// 列出所有注冊(cè)的服務(wù)
? ? ? ? ? ? String[] list = registry.list();
for (String s : list) {
System.out.println(s);
}
}catch (RemoteException e) {
}
try {
// 根據(jù)命名獲取服務(wù)
? ? ? ? ? ? IService server = (IService) registry.lookup("vince");
// 調(diào)用遠(yuǎn)程方法
? ? ? ? ? ? String result = server.queryName("ha ha ha ha");
// 輸出調(diào)用結(jié)果
? ? ? ? ? ? System.out.println("result from remote : " + result);
}catch (AccessExceptione) {
}catch (RemoteException e) {
}catch (NotBoundExceptione) {
}
}
}
RMI服務(wù)端
[java]view plain copy
import java.rmi.RemoteException;
import java.rmi.registry.LocateRegistry;
import java.rmi.registry.Registry;
// RMI服務(wù)端
public class Server {
public static void main(String[] args) {
// 注冊(cè)管理器
? ? ? ? Registry registry =null;
try {
// 創(chuàng)建一個(gè)服務(wù)注冊(cè)管理器
? ? ? ? ? ? registry = LocateRegistry.createRegistry(8088);
}catch (RemoteException e) {
}
try {
// 創(chuàng)建一個(gè)服務(wù)
? ? ? ? ? ? ServiceImpl server =new ServiceImpl();
// 將服務(wù)綁定命名
? ? ? ? ? ? registry.rebind("vince", server);
System.out.println("bind server");
}catch (RemoteException e) {
}
}
}
2、Hessian（基于HTTP的遠(yuǎn)程方法調(diào)用）
基于HTTP協(xié)議傳輸，在性能方面還不夠完美，負(fù)載均衡和失效轉(zhuǎn)移依賴于應(yīng)用的負(fù)載均衡器，Hessian的使用則與RMI類似，區(qū)別在于淡化了Registry的角色，通過顯示的地址調(diào)用，利用HessianProxyFactory根據(jù)配置的地址create一個(gè)代理對(duì)象，另外還要引入Hessian的Jar包。
3、Dubbo（淘寶開源的基于TCP的RPC框架）
基于Netty的高性能RPC框架，是阿里巴巴開源的，總體原理如下：
Dubbo通訊協(xié)議
第一、dubbo(默認(rèn)）
Dubbo 缺省協(xié)議采用單一長(zhǎng)連接和 NIO 異步通訊，適合于小數(shù)據(jù)量大并發(fā)的服務(wù)調(diào)用，以及服務(wù)消費(fèi)者機(jī)器數(shù)遠(yuǎn)大于服務(wù)提供者機(jī)器數(shù)的情況。反之，Dubbo 缺省協(xié)議不適合傳送大數(shù)據(jù)量的服務(wù)，比如傳文件，傳視頻等，除非請(qǐng)求量很低。
缺省協(xié)議，使用基于 netty?和 hessian?3.2.1?的 tbremoting 交互。
連接個(gè)數(shù)：?jiǎn)芜B接
連接方式：長(zhǎng)連接
傳輸協(xié)議：TCP
傳輸方式：NIO 異步傳輸
序列化：Hessian 二進(jìn)制序列化
適用范圍：傳入傳出參數(shù)數(shù)據(jù)包較?。ńㄗh小于100K），消費(fèi)者比提供者個(gè)數(shù)多，單一消費(fèi)者無法壓滿提供者，盡量不要用 dubbo 協(xié)議傳輸大文件或超大字符串。
適用場(chǎng)景：常規(guī)遠(yuǎn)程服務(wù)方法調(diào)用
第二、RMI
RMI 協(xié)議采用 JDK 標(biāo)準(zhǔn)的?java.rmi.*?實(shí)現(xiàn)，采用阻塞式短連接和 JDK 標(biāo)準(zhǔn)序列化方式。如果正在使用 RMI 提供服務(wù)給外部訪問?，同時(shí)應(yīng)用里依賴了老的 common-collections 包的情況下，存在反序列化安全風(fēng)險(xiǎn)。
連接個(gè)數(shù)：多連接
連接方式：短連接
傳輸協(xié)議：TCP
傳輸方式：同步傳輸
序列化：Java 標(biāo)準(zhǔn)二進(jìn)制序列化
適用范圍：傳入傳出參數(shù)數(shù)據(jù)包大小混合，消費(fèi)者與提供者個(gè)數(shù)差不多，可傳文件。
適用場(chǎng)景：常規(guī)遠(yuǎn)程服務(wù)方法調(diào)用，與原生RMI服務(wù)互操作
第三、hessian?????
Hessian協(xié)議用于集成 Hessian 的服務(wù)，Hessian 底層采用 Http 通訊，采用 Servlet 暴露服務(wù)，Dubbo 缺省內(nèi)嵌 Jetty 作為服務(wù)器實(shí)現(xiàn)。Dubbo 的 Hessian 協(xié)議可以和原生 Hessian 服務(wù)互操作，即：
提供者用 Dubbo 的 Hessian 協(xié)議暴露服務(wù)，消費(fèi)者直接用標(biāo)準(zhǔn) Hessian 接口調(diào)用
或者提供方用標(biāo)準(zhǔn) Hessian 暴露服務(wù)，消費(fèi)方用 Dubbo 的 Hessian 協(xié)議調(diào)用。
特性
連接個(gè)數(shù)：多連接
連接方式：短連接
傳輸協(xié)議：HTTP
傳輸方式：同步傳輸
序列化：Hessian二進(jìn)制序列化
適用范圍：傳入傳出參數(shù)數(shù)據(jù)包較大，提供者比消費(fèi)者個(gè)數(shù)多，提供者壓力較大，可傳文件。
適用場(chǎng)景：頁(yè)面?zhèn)鬏敚募鬏?，或與原生hessian服務(wù)互操作
第四、Http??????
基于 HTTP 表單的遠(yuǎn)程調(diào)用協(xié)議，采用 Spring 的 HttpInvoker 實(shí)現(xiàn)
特性
連接個(gè)數(shù)：多連接
連接方式：短連接
傳輸協(xié)議：HTTP
傳輸方式：同步傳輸
序列化：表單序列化
適用范圍：傳入傳出參數(shù)數(shù)據(jù)包大小混合，提供者比消費(fèi)者個(gè)數(shù)多，可用瀏覽器查看，可用表單或URL傳入?yún)?shù)，暫不支持傳文件。
適用場(chǎng)景：需同時(shí)給應(yīng)用程序和瀏覽器 JS 使用的服務(wù)。
第五、WebService
??????基于 WebService 的遠(yuǎn)程調(diào)用協(xié)議，基于?Apache CXF?的?frontend-simple?和?transports-http?實(shí)現(xiàn)?？梢院驮?WebService 服務(wù)互操作，即：
提供者用 Dubbo 的 WebService 協(xié)議暴露服務(wù)，消費(fèi)者直接用標(biāo)準(zhǔn) WebService 接口調(diào)用，
或者提供方用標(biāo)準(zhǔn) WebService 暴露服務(wù)，消費(fèi)方用 Dubbo 的 WebService 協(xié)議調(diào)用。
特性
連接個(gè)數(shù)：多連接
連接方式：短連接
傳輸協(xié)議：HTTP
傳輸方式：同步傳輸
序列化：SOAP 文本序列化
適用場(chǎng)景：系統(tǒng)集成，跨語(yǔ)言調(diào)用
第六、thrift
?????? 當(dāng)前 dubbo 支持?1的 thrift 協(xié)議是對(duì) thrift 原生協(xié)議?2?的擴(kuò)展，在原生協(xié)議的基礎(chǔ)上添加了一些額外的頭信息，比如 service name，magic number 等。
使用 dubbo thrift 協(xié)議同樣需要使用 thrift 的 idl compiler 編譯生成相應(yīng)的 java 代碼，后續(xù)版本中會(huì)在這方面做一些增強(qiáng)。
第七、緩存
memcached:基于 memcached?實(shí)現(xiàn)的 RPC 協(xié)議?。
redis:基于 Redis?實(shí)現(xiàn)的 RPC 協(xié)議?。
微服務(wù)架構(gòu)核心要素
Dubbo只是實(shí)現(xiàn)了服務(wù)治理，而Spring Cloud子項(xiàng)目分別覆蓋了微服務(wù)架構(gòu)下的眾多部件，而服務(wù)治理只是其中的一個(gè)方面。Dubbo提供了各種Filter，對(duì)于上述中“無”的要素，可以通過擴(kuò)展Filter來完善。
例如
1．分布式配置：可以使用淘寶的diamond、百度的disconf來實(shí)現(xiàn)分布式配置管理
2．服務(wù)跟蹤：可以使用京東開源的Hydra，或者擴(kuò)展Filter用Zippin來做服務(wù)跟蹤
3．批量任務(wù)：可以使用當(dāng)當(dāng)開源的Elastic-Job、tbschedule
點(diǎn)評(píng)：從核心要素來看，Spring Cloud 更勝一籌，在開發(fā)過程中只要整合Spring Cloud的子項(xiàng)目就可以順利的完成各種組件的融合，而Dubbo缺需要通過實(shí)現(xiàn)各種Filter來做定制，開發(fā)成本以及技術(shù)難度略高。
性能比較
說明：客戶端和服務(wù)端配置均采用阿里云的ECS服務(wù)器，4核8G配置，dubbo采用默認(rèn)的dubbo協(xié)議
點(diǎn)評(píng)：dubbo支持各種通信協(xié)議，而且消費(fèi)方和服務(wù)方使用長(zhǎng)鏈接方式交互，通信速度上略勝Spring Cloud，如果對(duì)于系統(tǒng)的響應(yīng)時(shí)間有嚴(yán)格要求，長(zhǎng)鏈接更合適。
服務(wù)依賴方式
Dubbo：服務(wù)提供方與消費(fèi)方通過接口的方式依賴，服務(wù)調(diào)用設(shè)計(jì)如下：
interface層：服務(wù)接口層，定義了服務(wù)對(duì)外提供的所有接口
Molel層：服務(wù)的DTO對(duì)象層，
business層：業(yè)務(wù)實(shí)現(xiàn)層，實(shí)現(xiàn)interface接口并且和DB交互
因此需要為每個(gè)微服務(wù)定義了各自的interface接口，并通過持續(xù)集成發(fā)布到私有倉(cāng)庫(kù)中，調(diào)用方應(yīng)用對(duì)微服務(wù)提供的抽象接口存在強(qiáng)依賴關(guān)系，開發(fā)、測(cè)試、集成環(huán)境都需要嚴(yán)格的管理版本依賴。
通過maven的install & deploy命令把interface和Model層發(fā)布到倉(cāng)庫(kù)中，服務(wù)調(diào)用方只需要依賴interface和model層即可。在開發(fā)調(diào)試階段只發(fā)布Snapshot版本。等到服務(wù)調(diào)試完成再發(fā)布Release版本，通過版本號(hào)來區(qū)分每次迭代的版本。通過xml配置方式即可方面接入dubbo，對(duì)程序無入侵。
Spring Cloud：服務(wù)提供方和服務(wù)消費(fèi)方通過json方式交互，因此只需要定義好相關(guān)json字段即可，消費(fèi)方和提供方無接口依賴。通過注解方式來實(shí)現(xiàn)服務(wù)配置，對(duì)于程序有一定入侵。
點(diǎn)評(píng)：Dubbo服務(wù)依賴略重，需要有完善的版本管理機(jī)制，但是程序入侵少。而Spring Cloud通過Json交互，省略了版本管理的問題，但是具體字段含義需要統(tǒng)一管理，自身Rest API方式交互，為跨平臺(tái)調(diào)用奠定了基礎(chǔ)。
組件運(yùn)行流程
下圖中的每個(gè)組件都是需要部署在單獨(dú)的服務(wù)器上，gateway用來接受前端請(qǐng)求、聚合服務(wù)，并批量調(diào)用后臺(tái)原子服務(wù)。每個(gè)service層和單獨(dú)的DB交互。
Dubbo組件運(yùn)行流程
gateWay:前置網(wǎng)關(guān)，具體業(yè)務(wù)操作，gateWay通過dubbo提供的負(fù)載均衡機(jī)制自動(dòng)完成
Service：原子服務(wù)，只提供該業(yè)務(wù)相關(guān)的原子服務(wù)
Zookeeper：原子服務(wù)注冊(cè)到zk上
Spring Cloud 組件運(yùn)行
Spring Cloud
所有請(qǐng)求都統(tǒng)一通過 API 網(wǎng)關(guān)（Zuul）來訪問內(nèi)部服務(wù)。
網(wǎng)關(guān)接收到請(qǐng)求后，從注冊(cè)中心（Eureka）獲取可用服務(wù)。
由 Ribbon 進(jìn)行均衡負(fù)載后，分發(fā)到后端的具體實(shí)例。
微服務(wù)之間通過 Feign 進(jìn)行通信處理業(yè)務(wù)。
微服務(wù)架構(gòu)組成以及注意事項(xiàng)
到底使用是dubbo還是Spring Cloud其實(shí)并不重要，重點(diǎn)在于如何合理的利用微服務(wù)。下面是一張互聯(lián)網(wǎng)通用的架構(gòu)圖,其中每個(gè)環(huán)節(jié)都是微服務(wù)的核心部分。
架構(gòu)分解
網(wǎng)關(guān)集群：數(shù)據(jù)的聚合、實(shí)現(xiàn)對(duì)接入客戶端的身份認(rèn)證、防報(bào)文重放與防數(shù)據(jù)篡改、功能調(diào)用的業(yè)務(wù)鑒權(quán)、響應(yīng)數(shù)據(jù)的脫敏、流量與并發(fā)控制等
業(yè)務(wù)集群：一般情況下移動(dòng)端訪問和瀏覽器訪問的網(wǎng)關(guān)需要隔離，防止業(yè)務(wù)耦合
Local
Cache：由于客戶端訪問業(yè)務(wù)可能需要調(diào)用多個(gè)服務(wù)聚合，所以本地緩存有效的降低了服務(wù)調(diào)用的頻次，同時(shí)也提示了訪問速度。本地緩存一般使用自動(dòng)過期方式，業(yè)務(wù)場(chǎng)景中允許有一定的數(shù)據(jù)延時(shí)。
服務(wù)層：原子服務(wù)層，實(shí)現(xiàn)基礎(chǔ)的增刪改查功能，如果需要依賴其他服務(wù)需要在Service層主動(dòng)調(diào)用
Remote Cache：訪問DB前置一層分布式緩存，減少DB交互次數(shù)，提升系統(tǒng)的TPS
DAL：數(shù)據(jù)訪問層，如果單表數(shù)據(jù)量過大則需要通過DAL層做數(shù)據(jù)的分庫(kù)分表處理。
MQ：消息隊(duì)列用來解耦服務(wù)之間的依賴，異步調(diào)用可以通過MQ的方式來執(zhí)行
數(shù)據(jù)庫(kù)主從：服務(wù)化過程中畢竟的階段，用來提升系統(tǒng)的TPS
（二）注意事項(xiàng)
服務(wù)啟動(dòng)方式建議使用jar方式啟動(dòng)，啟動(dòng)速度快，更容易監(jiān)控
緩存、緩存、緩存，系統(tǒng)中能使用緩存的地方盡量使用緩存，通過合理的使用緩存可以有效的提高系統(tǒng)的TPS
服務(wù)拆分要合理，盡量避免因服務(wù)拆分而導(dǎo)致的服務(wù)循環(huán)依賴
合理的設(shè)置線程池，避免設(shè)置過大或者過小導(dǎo)致系統(tǒng)異常
來源鏈接：
https://blog.csdn.net/qq_41587754/article/details/80133775
http://www.itdecent.cn/p/b0343bfd216e
https://blog.csdn.net/qq_34988624/article/details/86481801
