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