摘要：都是分開(kāi)部署，多帶帶上線的。序列化畢竟是遠(yuǎn)程通信，需要將對(duì)象轉(zhuǎn)化成二進(jìn)制流進(jìn)行傳輸。服務(wù)化架構(gòu)的演進(jìn)架構(gòu)當(dāng)業(yè)務(wù)規(guī)模很小時(shí)，將所有功能都不熟在同一個(gè)進(jìn)程中，通過(guò)雙機(jī)或者負(fù)載均衡器實(shí)現(xiàn)負(fù)債分流此時(shí)，分離前后臺(tái)邏輯的架構(gòu)是關(guān)鍵。

為什么需要RPC，而不是簡(jiǎn)單的HTTP接口？

剛開(kāi)始還是菜鳥(niǎo)的時(shí)候，時(shí)常把RPC和HTTP搞混淆，本身概念還沒(méi)理解清楚，心里就浮躁的不行，導(dǎo)致鬧出了不少笑話(huà)。

RPC（Remote Promote Call） 一種進(jìn)程間通信方式。允許像調(diào)用本地服務(wù)一樣調(diào)用遠(yuǎn)程服務(wù)。

RPC框架的主要目標(biāo)就是讓遠(yuǎn)程服務(wù)調(diào)用更簡(jiǎn)單、透明。RPC框架負(fù)責(zé)屏蔽底層的傳輸方式（TCP或者UDP）、序列化方式（XML/JSON/二進(jìn)制）和通信細(xì)節(jié)。開(kāi)發(fā)人員在使用的時(shí)候只需要了解誰(shuí)在什么位置提供了什么樣的遠(yuǎn)程服務(wù)接口即可，并不需要關(guān)心底層通信細(xì)節(jié)和調(diào)用過(guò)程。

HTTP協(xié)議是應(yīng)用層的超文本傳送協(xié)議，它是Web的基礎(chǔ)。HTTP協(xié)議位于TCP/IP協(xié)議棧的應(yīng)用層?；贖TTP協(xié)議的客戶(hù)/服務(wù)器模式的信息交換過(guò)程，分四個(gè)過(guò)程：建立連接、發(fā)送請(qǐng)求信息、發(fā)送響應(yīng)信息、關(guān)閉連接。
?

第七層：應(yīng)用層：?????定義了用于在網(wǎng)絡(luò)中進(jìn)行通信和數(shù)據(jù)傳輸?shù)慕涌?- 用戶(hù)程式；提供標(biāo)準(zhǔn)服務(wù)，比如虛擬終端、文件以及任務(wù)的傳輸 和處理；?
第六層：表示層：?????掩蓋不同系統(tǒng)間的數(shù)據(jù)格式的不同性； 指定獨(dú)立結(jié)構(gòu)的數(shù)據(jù)傳輸格式； 數(shù)據(jù)的編碼和解碼；加密和解密；壓縮和 解壓縮?
第五層：會(huì)話(huà)層：?????管理用戶(hù)會(huì)話(huà)和對(duì)話(huà)； 控制用戶(hù)間邏輯連接的建立和掛斷；報(bào)告上一層發(fā)生的錯(cuò)誤?
第四層：傳輸層：?????管理網(wǎng)絡(luò)中端到端的信息傳送； 通過(guò)錯(cuò)誤糾正和流控制機(jī)制提供可靠且有序的數(shù)據(jù)包傳送； 提供面向無(wú)連接的數(shù) 據(jù)包的傳送；?
第三層：網(wǎng)絡(luò)層：?????定義網(wǎng)絡(luò)設(shè)備間如何傳輸數(shù)據(jù)； 根據(jù)唯一的網(wǎng)絡(luò)設(shè)備地址路由數(shù)據(jù)包；提供流和擁塞控制以防止網(wǎng)絡(luò)資源的損耗?
第二層：數(shù)據(jù)鏈路層：?????定義操作通信連接的程序； 封裝數(shù)據(jù)包為數(shù)據(jù)幀； 監(jiān)測(cè)和糾正數(shù)據(jù)包傳輸錯(cuò)誤?
第一層：物理層：??????定義通過(guò)網(wǎng)絡(luò)設(shè)備發(fā)送數(shù)據(jù)的物理方式； 作為網(wǎng)絡(luò)媒介和設(shè)備間的接口；定義光學(xué)、電氣以及機(jī)械特性。

RPC是一種概念，http也是rpc實(shí)現(xiàn)的一種方式。論復(fù)雜度，dubbo/hessian用起來(lái)是超級(jí)簡(jiǎn)單的。最近用dubbo和hessian比較多，http的幾乎都被廢棄了。

至于為什么用，其實(shí)很簡(jiǎn)單，業(yè)務(wù)場(chǎng)景不一樣。我最早的單位所有的代碼都在一個(gè)工程里，一次要發(fā)布幾百m的代碼。這種架構(gòu)是非常有利于小程序的。但是我們?yōu)槭裁匆獞?yīng)用rpc層呢，一個(gè)功能，一套代碼下來(lái)不就解決了么？我覺(jué)得有幾個(gè)好處：

靈活部署
解耦

系統(tǒng)做大了，肯定是需要做微服務(wù)的。 現(xiàn)在我們做電商就是這樣，多帶帶有一個(gè)訂單系統(tǒng)，支付系統(tǒng)，商品系統(tǒng)，用戶(hù)系統(tǒng)。都是分開(kāi)部署，多帶帶上線的。 但我們交互是用HTTP接口來(lái)交互的，我想轉(zhuǎn)用RPC，但問(wèn)題是我現(xiàn)在還沒(méi)發(fā)現(xiàn)為什么需要用RPC，我還沒(méi)能理解它的作用和意義。
用http交互其實(shí)就已經(jīng)屬于rpc了。

不知道大家看到這里有沒(méi)有解決掉文章開(kāi)頭的那個(gè)問(wèn)題呢？看似普普通通的一個(gè)問(wèn)題，實(shí)際上暗藏了很多玄機(jī)，只有從頭到尾都完完整整的了解過(guò)一遍之后才能真正地得到想要的答案。大部分程序員應(yīng)該都有在工作過(guò)程中碰到各式各樣的問(wèn)題，那是否都深入去追究過(guò)問(wèn)題的本質(zhì)呢？如果有機(jī)會(huì)不妨去試一試，你會(huì)發(fā)現(xiàn)海面下隱藏的“冰山”是表面上的許多倍。

為什么面試官問(wèn)的都是同樣的問(wèn)題，有的人覺(jué)得沒(méi)什么太多能回答的點(diǎn)，有的人卻能滔滔不絕？我想每個(gè)人思維的深度面試官一眼就能看出來(lái)，正好就印證了那句話(huà)：架構(gòu)是一種思想，技術(shù)只是外殼。技術(shù)可能淘汰，思想才能長(zhǎng)存。

人因?yàn)橛辛怂枷耄艣](méi)有成為野獸。
在這里推薦一個(gè)架構(gòu)群895244712，除了分布式、微服務(wù)、性能優(yōu)化等技術(shù)點(diǎn)的技術(shù)分享，更重要的是架構(gòu)思想的形成。

這邊不再糾結(jié)，詳細(xì)理解一下RPC的相關(guān)問(wèn)題。

廣義的遠(yuǎn)程通訊技術(shù)包括:RPC , WebService , RMI , JMS , EJB , JNDI .

CORBA:面向?qū)ο蟮木幊腆w系規(guī)范,分布式系統(tǒng),跨語(yǔ)言,對(duì)標(biāo)RMI(競(jìng)爭(zhēng)關(guān)系)。

SOAP:簡(jiǎn)單對(duì)象訪問(wèn)協(xié)議,微軟聯(lián)合廠商對(duì)xml-rpc標(biāo)準(zhǔn)化,soap協(xié)議就是聯(lián)合標(biāo)準(zhǔn)化的結(jié)果,而且微軟搶先完善了soap協(xié)議,推出了webservice。對(duì)象訪問(wèn)協(xié)議指的是使用XML描述web service的信息(URI/類(lèi)/參數(shù)/返回值),理論上SOAP就是一段xml

WebService:屬于廣義rpc的一種(常見(jiàn)的廣義rpc實(shí)現(xiàn)還有xml-rpc和json-rpc),支持異構(gòu)系統(tǒng)間的交互, 支持不同語(yǔ)言的通信,使用http通信,通過(guò)serlvet提供XML格式的數(shù)據(jù),是SOAP協(xié)議的封裝,WSDL是它的描述方式。

WSDL:webservice描述語(yǔ)言,描述SOAP協(xié)議的,也是段XML

RMI:遠(yuǎn)程調(diào)用對(duì)象,其實(shí)是java實(shí)現(xiàn)了RPC的一組接口

JMS:MQ

EJB:大型分布式,rmi-iiop協(xié)議

由于目前跨內(nèi)存調(diào)用的普遍性,RPC往往代稱(chēng)更加具體的基于底層協(xié)議二進(jìn)制流的RPC框架,與WebService最大的不同就是: 狹義的RPC基于二進(jìn)制流的序列化和反序列化,故不能夠提供跨語(yǔ)言的服務(wù),但是比基于文本解析的WebService更加高效。

狹義RPC框架一般需要高性能的網(wǎng)絡(luò)框架,如Netty,Mina,高性能的序列化反序列化框架,尋址方式,如果是帶會(huì)話(huà)的RPC,還要有會(huì)話(huà)和狀態(tài)保持功能。

冗余數(shù)據(jù)太多,處理速度太慢。?
RPC 風(fēng)格的 Web Service 跨語(yǔ)言性不佳,而 Document 風(fēng)格的 Web Service 又太過(guò)難用。?
Web Service 沒(méi)有解決用戶(hù)的真正問(wèn)題,只是把一個(gè)問(wèn)題變成了另一個(gè)問(wèn)題。?
Web Service 的規(guī)范太過(guò)復(fù)雜,以至于在 .NET 和 Java 平臺(tái)以外沒(méi)有真正好用的實(shí)現(xiàn),甚至沒(méi)有可用的實(shí)現(xiàn)。?
跨語(yǔ)言跨平臺(tái)只是 Web Service 的一個(gè)口號(hào),雖然很多人迷信這一點(diǎn),但事實(shí)上它并沒(méi)有真正實(shí)現(xiàn)。?

遠(yuǎn)程提供者需要以某種形式提供服務(wù)調(diào)用相關(guān)的信息，包括但不限于服務(wù)接口定義、數(shù)據(jù)結(jié)構(gòu)、或者中間態(tài)的服務(wù)定義文件。例如Facebook的 Thrift的IDL文件，Web service的WSDL文件；服務(wù)的調(diào)用者需要通過(guò)一定的圖景獲取遠(yuǎn)程服務(wù)調(diào)用相關(guān)的信息。
遠(yuǎn)程代理對(duì)象：服務(wù)調(diào)用者用的服務(wù)實(shí)際是遠(yuǎn)程服務(wù)的本地代理。說(shuō)白了就是通過(guò)動(dòng)態(tài)代理來(lái)實(shí)現(xiàn)。
通信：RPC框架與具體的協(xié)議無(wú)關(guān)。
序列化：畢竟是遠(yuǎn)程通信，需要將對(duì)象轉(zhuǎn)化成二進(jìn)制流進(jìn)行傳輸。不同的RPC框架應(yīng)用的場(chǎng)景不同，在序列化上也會(huì)采取不同的技術(shù)

在大規(guī)模服務(wù)化之前，應(yīng)用可能只是通過(guò)RPC框架，簡(jiǎn)單的暴露和引用遠(yuǎn)程服務(wù)，通過(guò)配置URL地址進(jìn)行遠(yuǎn)程服務(wù)調(diào)用，路由則通過(guò)F5負(fù)載均衡器等進(jìn)行簡(jiǎn)單的負(fù)載均衡。

當(dāng)服務(wù)越來(lái)越多的時(shí)候，服務(wù)的URL配置管理變得更加困難。單純的使用RPC就有點(diǎn)吃不消。所以在大規(guī)模分布式集群中，RPC只是作為集群的一個(gè)方法調(diào)用手段。例如在Hadoop的進(jìn)程間交互都是通過(guò)RPC來(lái)進(jìn)行的，比如Namenode與Datanode直接，Jobtracker與Tasktracker之間等。

MVC架構(gòu)：當(dāng)業(yè)務(wù)規(guī)模很小時(shí)，將所有功能都不熟在同一個(gè)進(jìn)程中，通過(guò)雙機(jī)或者負(fù)載均衡器實(shí)現(xiàn)負(fù)債分流；此時(shí)，分離前后臺(tái)邏輯的MVC架構(gòu)是關(guān)鍵。

PRC架構(gòu)：當(dāng)垂直應(yīng)用越來(lái)越多，應(yīng)用之間交互不可避免，將核心和公共業(yè)務(wù)抽取出來(lái)，作為獨(dú)立的服務(wù)，實(shí)現(xiàn)前后臺(tái)邏輯分離。此時(shí)，用于提高業(yè)務(wù)復(fù)用及拆分的RPC框架是關(guān)鍵。

SOA架構(gòu)：隨著業(yè)務(wù)發(fā)展，服務(wù)數(shù)量越來(lái)越多，服務(wù)生命周期管控和運(yùn)行態(tài)的治理成為瓶頸，此時(shí)用于提升服務(wù)質(zhì)量的SOA服務(wù)治理是關(guān)鍵。

微服務(wù)架構(gòu)：通過(guò)服務(wù)的原子化拆分，以及微服務(wù)的獨(dú)立打包、部署和升級(jí)，小團(tuán)隊(duì)的交付周期將縮短，運(yùn)維成本也將大幅度下降。