摘要：傳輸協(xié)議問題我們先解決第一個，傳輸協(xié)議的問題。信封里面的信分抬頭和正文板栗燜雞協(xié)議我們學過，這個請求使用方法，發(fā)送一個格式為的正文給，從而下一個單，這個訂單封裝在的信封里面，并且表明這是一筆交易，而且訂單的詳情都已經(jīng)寫明了。

【前五篇】系列文章傳送門：

網(wǎng)絡協(xié)議 15 - P2P 協(xié)議：小種子大學問

網(wǎng)絡協(xié)議 16 - DNS 協(xié)議：網(wǎng)絡世界的地址簿

網(wǎng)絡協(xié)議 17 - HTTPDNS：私人定制的 DNS 服務

網(wǎng)絡協(xié)議 18 - CDN：家門口的小賣鋪

網(wǎng)絡協(xié)議 19 - RPC 協(xié)議綜述：遠在天邊，近在眼前

????上一節(jié)我們了解 RPC 的經(jīng)典模型和設計要點，并用最早期的 ONC RPC 為例子，詳述了具體的實現(xiàn)。而時代在進步，ONC RPC 逐漸因為各種問題被替代，SOAP 協(xié)議就是替代者之一。

????ONC RPC 將客戶端要發(fā)送的參數(shù)，以及服務端要發(fā)送的回復，都壓縮為一個二進制串，這樣固然能夠解決雙方的協(xié)議約定問題，但是存在一定的不方便。

????首先，需要雙方的壓縮格式完全一致，一點都不能差。一旦有少許的差錯，多一位，少一位或者錯一位，都可能造成無法解壓縮。當然，我們可以用傳輸層的可靠性以及加入校驗值等方式，來減少傳輸過程中的差錯。

????其次，協(xié)議修改不靈活。如果不是傳輸過程中造成的差錯，而是客戶端因為業(yè)務邏輯的改變，添加或者刪除了字段，或者服務端添加或者刪除了字段，而雙方?jīng)]有及時通知，或者線上系統(tǒng)沒有及時升級，就會造成解壓縮不成功。

????因而，當業(yè)務發(fā)生改變，需要多傳輸一些參數(shù)或者少傳輸一些參數(shù)的時候，都需要及時通知對方，并且根據(jù)約定好的協(xié)議文件重新生成雙方的 Stub 程序。自然，這樣靈活性比較差。

????如果僅僅是溝通的問題也還好解決，其實更難弄的還有版本的問題。比如在服務端提供一個服務，參數(shù)的格式是版本一的，已經(jīng)有 50 個客戶端在線上調用了?，F(xiàn)在有一個客戶端有個需求，要加一個字段，怎么辦呢？這可是一個大工程，所有的客戶端都要適配這個，需要重新寫程序，加上這個字段，但是傳輸值是 0，不需要這個字段的客戶端很“冤”，本來沒我啥事兒，為啥讓我也忙活？

????最后，ONC RPC 的設計明顯是面向函數(shù)的，而非面向對象。而當前面向對象的業(yè)務邏輯設計與實現(xiàn)方式已經(jīng)成為主流。

????這一切的根源就在于壓縮。這就像平時我們愛用縮略語。如果是籃球愛好者，你直接說 NBA，他馬上就知道什么意思，但是如果你給一個大媽說 NBA，她可能就不知所云。

????所以，這種 RPC 框架只能用于客戶端和服務端全由一撥人開發(fā)的場景，或者至少客戶端和服務端的開發(fā)人員要密切溝通，相互合作，有大量的共同語言，才能按照既定的協(xié)議順暢地進行工作。

????但是，一般情況下，我們做一個服務，都是要提供給陌生人用的，你和客戶不會經(jīng)常溝通，也沒有什么共同語言。就像你給別人介紹 NBA，你要說美國職業(yè)籃球賽，這樣不管他是干啥的，都能聽得懂。

????放到我們的場景中，對應的就是用文本類的方式進行傳輸。無論哪個客戶端獲得這個文本，都能夠知道它的意義。

????一種常見的文本類格式是 XML。我們這里舉個例子來看。

    
        2019-01-08
         板栗燜雞 
        58
    

????我這里不準備詳細講述 XML 的語法規(guī)則，但是你相信我，看完下面的內容，即便你沒有學過 XML，也能一看就懂，這段 XML 描述的是什么，不像全面的二進制，你看到的都是 010101，不知所云。

????有了這個，剛才我們說的那幾個問題就都不是問題了。

????首先，格式?jīng)]必要完全一致。比如如果我們把 price 和 author 換個位置，并不影響客戶端和服務端解析這個文本，也根本不會誤會，說這個作者的名字叫 68。

????如果有的客戶端想增加一個字段，例如添加一個推薦人字段，只需要在上面的文件中加一行：

 Gary  

????對于不需要這個字段的客戶端，只要不解析這一行就是了。只要用簡單的處理，就不會出現(xiàn)錯誤。

????另外，這種表述方式顯然是描述一個訂單對象的，是一種面向對象的、更加接近用戶場景的表示方式。

????既然 XML 這么好，接下來我們來看看怎么把它用在 RPC 中。

????我們先解決第一個，傳輸協(xié)議的問題。

????基于 XML 的最著名的通信協(xié)議就是SOAP了，全稱簡單對象訪問協(xié)議（Simple Object Access Protocol）。它使用 XML 編寫簡單的請求和回復消息，并用 HTTP 協(xié)議進行傳輸。

????SOAP 將請求和回復放在一個信封里面，就像傳遞一個郵件一樣。信封里面的信分抬頭和正文

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é)議我們學過，這個請求使用 POST 方法，發(fā)送一個格式為 application/soap + xml 的 XML 正文給 www.geektime.com ，從而下一個單，這個訂單封裝在 SOAP 的信封里面，并且表明這是一筆交易（transaction），而且訂單的詳情都已經(jīng)寫明了。

????接下來我們解決第二個問題，就是雙方的協(xié)議約定是什么樣的？

????因為服務開發(fā)出來是給陌生人用的，就像上面下單的那個 XML 文件，對于客戶端來說，它如何知道應該拼裝成上面的格式呢？這就需要對于服務進行描述，因為調用的人不認識你，所以沒辦法找到你，問你的服務應該如何調用。

????當然你可以寫文檔，然后放在官方網(wǎng)站上，但是你的文檔不一定更新得那么及時，而且你也寫的文檔也不一定那么嚴謹，所以常常會有調試不成功的情況。因而，我們需要一種相對比較嚴謹?shù)?strong>Web 服務描述語言，WSDL（Web Service Description Languages）。它也是一個 XML 文件。

????在這個文件中，要定義一個類型 order，與上面的 XML 對應起來。

????接下來，需要定義一個 message 的結構。

????接下來，應該暴露一個端口。

????然后，我們來編寫一個 binding，將上面定義的信息綁定到 SOAP 請求的 body 里面。

????最后，我們需要編寫 service。

????WSDL 還是有些復雜的，不過好在有工具可以生成。

????對于某個服務，哪怕是一個陌生人，都可以通過在服務地址后面加上“?wsdl”來獲取到這個文件，但是這個文件還是比較復雜，比較難以看懂。不過好在也有工具可以根據(jù) WSDL 生成客戶端 Stub，讓客戶端通過 Stub 進行遠程調用，就跟調用本地的方法一樣。

????最后解決第三個問題，服務發(fā)現(xiàn)問題。

????這里有一個UDDI（Universal Description, Discovery, and Integration），也即統(tǒng)一描述、發(fā)現(xiàn)和集成協(xié)議。它其實是一個注冊中心，服務提供方可以將上面的 WSDL 描述文件，發(fā)布到這個注冊中心，注冊完畢后，服務使用方可以查找到服務的描述，封裝為本地的客戶端進行調用。

原來的二進制 RPC 有很多缺點，格式要求嚴格，修改過于復雜，不面向對象，于是產(chǎn)生了基于文本的調用方式——基于 XML 的 SOAP；

SOAP 有三大要素：協(xié)議約定用 WSDL、傳輸協(xié)議用 HTTP、服務發(fā)現(xiàn)用 UDDL。