摘要：傳輸協(xié)議問題我們先解決第一個(gè)，傳輸協(xié)議的問題。信封里面的信分抬頭和正文板栗燜雞協(xié)議我們學(xué)過，這個(gè)請(qǐng)求使用方法，發(fā)送一個(gè)格式為的正文給，從而下一個(gè)單，這個(gè)訂單封裝在的信封里面，并且表明這是一筆交易，而且訂單的詳情都已經(jīng)寫明了。
【前五篇】系列文章傳送門：
網(wǎng)絡(luò)協(xié)議 15 - P2P 協(xié)議：小種子大學(xué)問
網(wǎng)絡(luò)協(xié)議 16 - DNS 協(xié)議：網(wǎng)絡(luò)世界的地址簿
網(wǎng)絡(luò)協(xié)議 17 - HTTPDNS：私人定制的 DNS 服務(wù)
網(wǎng)絡(luò)協(xié)議 18 - CDN：家門口的小賣鋪
網(wǎng)絡(luò)協(xié)議 19 - RPC 協(xié)議綜述：遠(yuǎn)在天邊，近在眼前
????上一節(jié)我們了解 RPC 的經(jīng)典模型和設(shè)計(jì)要點(diǎn)，并用最早期的 ONC RPC 為例子，詳述了具體的實(shí)現(xiàn)。而時(shí)代在進(jìn)步，ONC RPC 逐漸因?yàn)楦鞣N問題被替代，SOAP 協(xié)議就是替代者之一。
ONC RPC 存在的問題
????ONC RPC 將客戶端要發(fā)送的參數(shù)，以及服務(wù)端要發(fā)送的回復(fù)，都?jí)嚎s為一個(gè)二進(jìn)制串，這樣固然能夠解決雙方的協(xié)議約定問題，但是存在一定的不方便。
????首先，需要雙方的壓縮格式完全一致，一點(diǎn)都不能差。一旦有少許的差錯(cuò)，多一位，少一位或者錯(cuò)一位，都可能造成無法解壓縮。當(dāng)然，我們可以用傳輸層的可靠性以及加入校驗(yàn)值等方式，來減少傳輸過程中的差錯(cuò)。
????其次，協(xié)議修改不靈活。如果不是傳輸過程中造成的差錯(cuò)，而是客戶端因?yàn)闃I(yè)務(wù)邏輯的改變，添加或者刪除了字段，或者服務(wù)端添加或者刪除了字段，而雙方?jīng)]有及時(shí)通知，或者線上系統(tǒng)沒有及時(shí)升級(jí)，就會(huì)造成解壓縮不成功。
????因而，當(dāng)業(yè)務(wù)發(fā)生改變，需要多傳輸一些參數(shù)或者少傳輸一些參數(shù)的時(shí)候，都需要及時(shí)通知對(duì)方，并且根據(jù)約定好的協(xié)議文件重新生成雙方的 Stub 程序。自然，這樣靈活性比較差。
????如果僅僅是溝通的問題也還好解決，其實(shí)更難弄的還有版本的問題。比如在服務(wù)端提供一個(gè)服務(wù)，參數(shù)的格式是版本一的，已經(jīng)有 50 個(gè)客戶端在線上調(diào)用了?，F(xiàn)在有一個(gè)客戶端有個(gè)需求，要加一個(gè)字段，怎么辦呢？這可是一個(gè)大工程，所有的客戶端都要適配這個(gè)，需要重新寫程序，加上這個(gè)字段，但是傳輸值是 0，不需要這個(gè)字段的客戶端很“冤”，本來沒我啥事兒，為啥讓我也忙活？
????最后，ONC RPC 的設(shè)計(jì)明顯是面向函數(shù)的，而非面向?qū)ο?/strong>。而當(dāng)前面向?qū)ο蟮臉I(yè)務(wù)邏輯設(shè)計(jì)與實(shí)現(xiàn)方式已經(jīng)成為主流。
????這一切的根源就在于壓縮。這就像平時(shí)我們愛用縮略語。如果是籃球愛好者，你直接說 NBA，他馬上就知道什么意思，但是如果你給一個(gè)大媽說 NBA，她可能就不知所云。
????所以，這種 RPC 框架只能用于客戶端和服務(wù)端全由一撥人開發(fā)的場(chǎng)景，或者至少客戶端和服務(wù)端的開發(fā)人員要密切溝通，相互合作，有大量的共同語言，才能按照既定的協(xié)議順暢地進(jìn)行工作。
XML 與 SOAP
????但是，一般情況下，我們做一個(gè)服務(wù)，都是要提供給陌生人用的，你和客戶不會(huì)經(jīng)常溝通，也沒有什么共同語言。就像你給別人介紹 NBA，你要說美國職業(yè)籃球賽，這樣不管他是干啥的，都能聽得懂。
????放到我們的場(chǎng)景中，對(duì)應(yīng)的就是用文本類的方式進(jìn)行傳輸。無論哪個(gè)客戶端獲得這個(gè)文本，都能夠知道它的意義。
????一種常見的文本類格式是 XML。我們這里舉個(gè)例子來看。
2019-01-08
板栗燜雞
58
????我這里不準(zhǔn)備詳細(xì)講述 XML 的語法規(guī)則，但是你相信我，看完下面的內(nèi)容，即便你沒有學(xué)過 XML，也能一看就懂，這段 XML 描述的是什么，不像全面的二進(jìn)制，你看到的都是 010101，不知所云。
????有了這個(gè)，剛才我們說的那幾個(gè)問題就都不是問題了。
????首先，格式?jīng)]必要完全一致。比如如果我們把 price 和 author 換個(gè)位置，并不影響客戶端和服務(wù)端解析這個(gè)文本，也根本不會(huì)誤會(huì)，說這個(gè)作者的名字叫 68。
????如果有的客戶端想增加一個(gè)字段，例如添加一個(gè)推薦人字段，只需要在上面的文件中加一行：
Gary
????對(duì)于不需要這個(gè)字段的客戶端，只要不解析這一行就是了。只要用簡單的處理，就不會(huì)出現(xiàn)錯(cuò)誤。
????另外，這種表述方式顯然是描述一個(gè)訂單對(duì)象的，是一種面向?qū)ο蟮?、更加接近用戶?chǎng)景的表示方式。
????既然 XML 這么好，接下來我們來看看怎么把它用在 RPC 中。
傳輸協(xié)議問題
????我們先解決第一個(gè)，傳輸協(xié)議的問題。
????基于 XML 的最著名的通信協(xié)議就是SOAP了，全稱簡單對(duì)象訪問協(xié)議（Simple Object Access Protocol）。它使用 XML 編寫簡單的請(qǐng)求和回復(fù)消息，并用 HTTP 協(xié)議進(jìn)行傳輸。
????SOAP 將請(qǐng)求和回復(fù)放在一個(gè)信封里面，就像傳遞一個(gè)郵件一樣。信封里面的信分抬頭和正文
POST /purchaseOrder HTTP/1.1
Host: www.cnblog.com
Content-Type: application/soap+xml; charset=utf-8
Content-Length: nnn
1234
2019-01-08
板栗燜雞
88
????HTTP 協(xié)議我們學(xué)過，這個(gè)請(qǐng)求使用 POST 方法，發(fā)送一個(gè)格式為 application/soap + xml 的 XML 正文給 www.geektime.com ，從而下一個(gè)單，這個(gè)訂單封裝在 SOAP 的信封里面，并且表明這是一筆交易（transaction），而且訂單的詳情都已經(jīng)寫明了。
協(xié)議約定問題
????接下來我們解決第二個(gè)問題，就是雙方的協(xié)議約定是什么樣的？
????因?yàn)榉?wù)開發(fā)出來是給陌生人用的，就像上面下單的那個(gè) XML 文件，對(duì)于客戶端來說，它如何知道應(yīng)該拼裝成上面的格式呢？這就需要對(duì)于服務(wù)進(jìn)行描述，因?yàn)檎{(diào)用的人不認(rèn)識(shí)你，所以沒辦法找到你，問你的服務(wù)應(yīng)該如何調(diào)用。
????當(dāng)然你可以寫文檔，然后放在官方網(wǎng)站上，但是你的文檔不一定更新得那么及時(shí)，而且你也寫的文檔也不一定那么嚴(yán)謹(jǐn)，所以常常會(huì)有調(diào)試不成功的情況。因而，我們需要一種相對(duì)比較嚴(yán)謹(jǐn)?shù)?strong>Web 服務(wù)描述語言，WSDL（Web Service Description Languages）。它也是一個(gè) XML 文件。
????在這個(gè)文件中，要定義一個(gè)類型 order，與上面的 XML 對(duì)應(yīng)起來。
????接下來，需要定義一個(gè) message 的結(jié)構(gòu)。
????接下來，應(yīng)該暴露一個(gè)端口。
????然后，我們來編寫一個(gè) binding，將上面定義的信息綁定到 SOAP 請(qǐng)求的 body 里面。
????最后，我們需要編寫 service。
????WSDL 還是有些復(fù)雜的，不過好在有工具可以生成。
????對(duì)于某個(gè)服務(wù)，哪怕是一個(gè)陌生人，都可以通過在服務(wù)地址后面加上“?wsdl”來獲取到這個(gè)文件，但是這個(gè)文件還是比較復(fù)雜，比較難以看懂。不過好在也有工具可以根據(jù) WSDL 生成客戶端 Stub，讓客戶端通過 Stub 進(jìn)行遠(yuǎn)程調(diào)用，就跟調(diào)用本地的方法一樣。
服務(wù)發(fā)現(xiàn)問題
????最后解決第三個(gè)問題，服務(wù)發(fā)現(xiàn)問題。
????這里有一個(gè)UDDI（Universal Description, Discovery, and Integration），也即統(tǒng)一描述、發(fā)現(xiàn)和集成協(xié)議。它其實(shí)是一個(gè)注冊(cè)中心，服務(wù)提供方可以將上面的 WSDL 描述文件，發(fā)布到這個(gè)注冊(cè)中心，注冊(cè)完畢后，服務(wù)使用方可以查找到服務(wù)的描述，封裝為本地的客戶端進(jìn)行調(diào)用。
小結(jié)
原來的二進(jìn)制 RPC 有很多缺點(diǎn)，格式要求嚴(yán)格，修改過于復(fù)雜，不面向?qū)ο螅谑钱a(chǎn)生了基于文本的調(diào)用方式——基于 XML 的 SOAP；
SOAP 有三大要素：協(xié)議約定用 WSDL、傳輸協(xié)議用 HTTP、服務(wù)發(fā)現(xiàn)用 UDDL。
文章版權(quán)歸作者所有，未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為，您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址：http://systransis.cn/yun/29925.html
