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