Distributed Systems笔记－Web Service Design Patterns
CMU 95702 Distributed Systems 筆記。簡單介紹 XML-RPC、SOAP、REST 三種 web 服務(wù)實現(xiàn)方案以及 RPC、Message、Resource 三種 patterns。
Web 服務(wù)實現(xiàn)方案
主流的 Web 服務(wù)實現(xiàn)方案有以下三種，因為 XML-RPC 逐漸被 SOAP 取代，所以也可以說，主流的 Web 服務(wù)實現(xiàn)方案只有 REST 和 SOAP 兩種。
- REST：表征狀態(tài)轉(zhuǎn)移（Representational State Transfer
- SOAP：簡單對象訪問協(xié)議（Simple Object Access Protocol）
- XML-RPC：遠(yuǎn)程過程調(diào)用（Remote procedure call，RPC)
XML-RPC
XML-RPC 是一個遠(yuǎn)程過程調(diào)用（remote procedure call，RPC)的分布式計算協(xié)議，通過XML將調(diào)用函數(shù)封裝，并使用 HTTP 協(xié)議作為傳送機(jī)制。后來在新的功能不斷被引入下，這個標(biāo)準(zhǔn)慢慢演變成為今日的 SOAP 協(xié)定。XML-RPC 協(xié)定是已登記的專利項目。XML-RPC 透過向裝置了這個協(xié)定的服務(wù)器發(fā)出HTTP請求。發(fā)出請求的用戶端一般都是需要向遠(yuǎn)端系統(tǒng)要求呼叫的軟件。
eg. Long-lived image
如果需要經(jīng)常把大的圖片傳到前端，那么可以把圖片的 cache-control 設(shè)置的大一些，如 30 天，如果需要更新圖片，那么上傳一張新的圖片到新的 URI，然后再改變 HTML，指向新的 URI。
HTML
| 1 | <img src='/image/big-image.jpg'\> |
Server
| 12345 | HTTP/1.1 200 OkDate: Thu, 15 Aug 2008 23:26:31 GMTServer: ApacheContent-Length: 50753Cache-Control: max-age=259200 |
HTML
| 1 | <img src='/image/big-image2.jpg'></pre> |
SOAP
SOAP(Simple Object Access Protocol) 是一套完整的實現(xiàn) Web 服務(wù)的解決方案。
SOAP 方式的 Web 服務(wù)中的 Web 服務(wù)描述語言（WSDL）和簡單對象訪問協(xié)議（SOAP）一起構(gòu)成了 SOAP 方式下的 Web 服務(wù)的結(jié)構(gòu)單元。客戶端通過 WSDL 可以了解 Web 服務(wù)公開了那些可以被執(zhí)行的方法以及 Web 服務(wù)可以發(fā)送或接收的消息格式（解決了公布訪問資源方法的問題）。客戶端按照 SOAP 將調(diào)用位于遠(yuǎn)程系統(tǒng)上的服務(wù)所需信息序列化為消息（解決了如何調(diào)用遠(yuǎn)程方法的問題）。注意 WSDL 描述的服務(wù)以及SOAP消息都是符合統(tǒng)一標(biāo)準(zhǔn)的，都是機(jī)器可讀的.
WSDL 基于 XML 格式，用來描述 Web 服務(wù)。WSDL 文檔可以看成是客戶端和服務(wù)器之間的一個協(xié)約。使用 WSDL 工具，你可以自動處理這個過程，幾乎不用手工編寫代碼就能夠讓應(yīng)用程序整合新的服務(wù)。因此 WSDL 是 Web 服務(wù)體系結(jié)構(gòu)的基礎(chǔ)，因為它提供了一個通用語言，用來描述服務(wù)和整合這些服務(wù)的平臺。
SOAP 本身提供了與 Web 服務(wù)交換信息的方法。SOAP 是序列化調(diào)用位于遠(yuǎn)程系統(tǒng)上的服務(wù)所需信息的標(biāo)準(zhǔn)方法，這些信息可以使用一種遠(yuǎn)程系統(tǒng)能夠讀懂的格式通過網(wǎng)絡(luò)發(fā)送到遠(yuǎn)程系統(tǒng)，而不必關(guān)心遠(yuǎn)程系統(tǒng)運行于何種平臺或者使用何種語言編寫。SOAP 以 XML 格式提供了一個簡單、輕量的用于在分散或分布環(huán)境中交換結(jié)構(gòu)化和類型信息的機(jī)制。實際上它通過提供一個有標(biāo)準(zhǔn)組件的包模型和在模塊中編碼數(shù)據(jù)的機(jī)制，定義了一個簡單的表示應(yīng)用程序語義的機(jī)制。
用一個簡單的例子來說明 SOAP 使用過程，一個 SOAP 消息可以發(fā)送到一個具有 Web Service 功能的 Web 站點，例如，一個含有房價信息的數(shù)據(jù)庫，消息的參數(shù)中標(biāo)明這是一個查詢消息，此站點將返回一個 XML 格式的信息，其中包含了查詢結(jié)果（價格，位置，特點，或者其他信息）。由于數(shù)據(jù)是用一種標(biāo)準(zhǔn)化的可分析的結(jié)構(gòu)來傳遞的，所以可以直接被第三方站點所利用。
REST
表征狀態(tài)轉(zhuǎn)移（Representional State Transfer），是 Roy Fielding（ HTTP規(guī)范的主要編寫者之一）博士在2000年他的博士論文中提出來的一種軟件架構(gòu)風(fēng)格。它并不是一個標(biāo)準(zhǔn)，而是通過表征（Representional）來描述傳輸狀態(tài)的一種原則。其宗旨是從資源的角度來觀察整個網(wǎng)絡(luò)，分布在各處的資源由URI確定，而客戶端的應(yīng)用通過 URI 來獲取資源的表征。獲得這些表征致使這些應(yīng)用程序轉(zhuǎn)變了其狀態(tài)。隨著不斷獲取資源的表征，客戶端應(yīng)用不斷地在轉(zhuǎn)變著其狀態(tài)。
REST 中沒有用于描述資源（服務(wù)）列表，資源元數(shù)據(jù)的類似于WSDL的東西。所以我們需要其他策略去代替 WSDL 實現(xiàn)“公布訪問資源方法的問題”。
由于沒有類似于 SOAP 的權(quán)威性協(xié)議作為規(guī)范，因此各個網(wǎng)站的REST實現(xiàn)都自有一套，也正是因為這種各自實現(xiàn)的情況，在性能和可用性上會大大高于 SOAP 發(fā)布的 web service，但細(xì)節(jié)方面有太多沒有約束的地方，其統(tǒng)一通用方面遠(yuǎn)遠(yuǎn)不及 SOAP。
舉個例子：假設(shè)A組織，B組織都實現(xiàn)了Restful API來通過工號查詢?nèi)藛T信息，因為沒有統(tǒng)一的規(guī)范。
A的API 可能是這樣：
| 1 | http://A/api/person/001 |
B的API 可能是這樣：
| 1 | http://A/api/person/id=001 |
第三方客戶端在實現(xiàn)遠(yuǎn)程調(diào)用的時候就必須考慮這些API的差異，分別查看A，B的API文檔。
如果有個權(quán)威性協(xié)議作為規(guī)范做指導(dǎo)，規(guī)定這個API應(yīng)該實現(xiàn)成下面這樣，那么第三方客戶端也只需按照這個標(biāo)準(zhǔn)去調(diào)用遠(yuǎn)程API，而不用查看A，B的API文檔：
| 1 | http://A/api/person/{001} |
而 OData 就是這樣的一個設(shè)計和使用 Restful API 的權(quán)威性協(xié)議. OData 定義了一些標(biāo)準(zhǔn)規(guī)則（像一個接口定義一堆方法一樣），實現(xiàn) Restful API 時候，必須實現(xiàn)這些標(biāo)準(zhǔn)規(guī)則（就像實現(xiàn)一個接口必須實現(xiàn)其所有方法一樣）。第三方就可以根據(jù) Odata 協(xié)議定義的規(guī)則去訪問 Restful API。
特性
Resources
- URI
REST 的一個重要原則是 Addressability，每一個資源都有一個 URI。格式為 scheme://host:port/path?queryString#fragment。scheme 可以是 http、ftp、https 等。 - Uniform Interface
methods，用 http 的若干方法來操作資源。
representation，提供了多種 formats 來表述網(wǎng)頁，如 xml, json 等。http 用 content-type header 來定義格式。
Protocol
- client-server
客戶和服務(wù)器之間通過一個統(tǒng)一的接口來互相通訊。 - stateless
每一個 request 都是獨立的，每次發(fā)送請求時客戶端都需要提供足夠的信息，服務(wù)端并不會保存有關(guān)客戶的任何狀態(tài)。 - cacheable
REST 的系統(tǒng)能恰當(dāng)對請求進(jìn)行緩存，盡量減少服務(wù)器和客戶端之間的信息傳輸來提高性能 - layered(intermediaries)
客戶端并不會固定和一個服務(wù)器打交道
HTTP method 的補(bǔ)充：
- GET - safe, idempotent, cacheable
- PUT - idempotent
- DELETE - idempotent
- HEAD - safe, idempotent
- POST
cacheable：response 可以被緩存
idempotent：該操作可以被執(zhí)行多次
safe：該操作并沒有副作用（不會影響別的操作）
HATEOAS
REST 另一個主要內(nèi)容是 HATEOAS。HATEOS 用中文解釋就是?超文本作為狀態(tài)轉(zhuǎn)移的引擎，這是一個 late binding 的例子。用戶在瀏覽器輸入 URL 向該資源發(fā)起一個 HTTP GET 請求，服務(wù)器會返回 response，在這個 response 中包含了下一步你該去哪里的信息，你可以在這個 response 中找到對其它資源的引用：鏈接、圖片、腳本等。也就是說，一個典型的REST服務(wù)不需要額外的文檔標(biāo)示通過哪些URL訪問特定類型的資源，而是通過服務(wù)端返回的響應(yīng)來標(biāo)示到底能在該資源上執(zhí)行什么樣的操作。一個REST服務(wù)的客戶端也不需要知道任何有關(guān)哪里有什么樣的資源這種信息。
舉例來說，一個客戶端可能會接收一個我們上面所描述的用于報表服務(wù)的主RESTful服務(wù)的引用：
http://company1.com/report/如果是通過瀏覽器發(fā)出的請求，可能會返回一個包含如下引用的HTML文檔：
http://company1.com/report/sales用戶可以點擊進(jìn)入并找到可瀏覽的年份列表。要說明的是瀏覽器對于URL的結(jié)構(gòu)并沒有特別的認(rèn)知，但它知道如何分析結(jié)果并以用戶可以瀏覽的結(jié)果返回內(nèi)容。
對于其它的MIME類型道理也是一樣，比如以XML的格式請求2009年的季度報表：
http://company1.com/reports/sales/2009/qtr可能得到：
| 123456 | <reports><description>2009 Quarterly Reports</description><report name="First Quarter" src="http://company1.com/reports/sales/2009/qtr/1"/><report name="Second Quarter" src="http://company1.com/reports/sales/2009/qtr/2"/><report name="Third Quarter" src="http://company1.com/reports/sales/2009/qtr/3"/> </reports> |
可以將 URL 想成是貫穿信息空間的向量。每一個層次都進(jìn)一步的將你指向最終的資源。不同的路徑可能產(chǎn)生同樣的結(jié)果。客戶端需要知道如何分析這些結(jié)果，但通過對響應(yīng)給出可識別的類型，我們可以觸發(fā)合適的分析器。這一結(jié)構(gòu)可通過爬蟲降序的從引用來抓取，或者以某種接口展現(xiàn)給用戶瀏覽。一個 RESTful 接口成為了客戶端通過基于已知來請求信息的方式。它們以一個已知或者已發(fā)現(xiàn)的點作為開始，就像你瀏覽web一樣來瀏覽信息。
這就是 HATEOS 所指代的。應(yīng)用的狀態(tài)在超文本響應(yīng)中被轉(zhuǎn)移和發(fā)現(xiàn)。就像瀏覽器需要知道HTML、圖片、聲音文件等等一樣，一個RESTful客戶端也需要知道如何分析解析資源引用的結(jié)果。然而，整個過程是簡單、受約束、可伸縮并且靈活的——這正是我們所期望的網(wǎng)絡(luò)軟件系統(tǒng)的屬性。
許多人搭建的”RESTful”系統(tǒng)都要求客戶端事先知道URL的每一層次的意義。如果服務(wù)端將信息重組了，這些系統(tǒng)的客戶端就會崩潰。真正體現(xiàn)了HATEOS的客戶端與它們所通訊的服務(wù)器之間才更加能做到松耦合。
更多見面向資源的架構(gòu)：REST的另一面
Linked Services Pattern
是 HATEOAS 的核心。只發(fā)布一部分 root web services 的地址，在每個 response 中返回相關(guān)服務(wù)的地址，讓客戶端通過這種 response 來發(fā)現(xiàn)之后的 URI。
Only publish the addresses of a few root web services. Include the addresses of related services in each response. Let clients parse responses to discover subsequent service URIs.
Network performance
客戶端 -> 服務(wù)端。
client - proxy - gateways - origin serverREST 的優(yōu)勢。
- Efficiency
緩存可以提高效率，并不需要到達(dá) gateways 和 origin server；data control 意味著我們可以壓縮數(shù)據(jù)來提高效率。 - Scalability
緩存：理由同上。
無狀態(tài)：如果服務(wù)器記錄用戶相關(guān)的狀態(tài)，那么集群擴(kuò)展時用戶相關(guān)的狀態(tài)就要及時地在集群中的各個服務(wù)器之間同步，對用戶狀態(tài)的同步將會是一個非常棘手的問題，當(dāng)一個用戶的相關(guān)狀態(tài)在一個服務(wù)器上發(fā)生了更改，那么在什么時候，什么情況下對這些狀態(tài)進(jìn)行同步？如果該狀態(tài)同步是同步進(jìn)行的，那么同時刷新多個服務(wù)器上的用戶狀態(tài)將導(dǎo)致對用戶請求的處理變得異常緩慢。如果該同步是異步的，那么用戶在發(fā)送下一個請求時，其它服務(wù)器將可能由于用戶狀態(tài)不同步的原因無法正確地處理用戶的請求。除此之外，如果集群進(jìn)行了不停機(jī)的橫向擴(kuò)展，那么用戶狀態(tài)的同步需要如何完成？
不同的 gateways，增加 intermediaries 非常方便。 - User Perceived Performance
通過 reduce media types，緩存等方式實現(xiàn)。 - simplicity/evolvability/extensibility/customizability/configuration/reusability/visibility/portability/reliability
三種方案簡單比較
XML-RPC已慢慢的被SOAP所取代，現(xiàn)在很少采用了，但它還是有版權(quán)的。
- 成熟度上：SOAP在成熟度上優(yōu)于REST
- 效率和易用性上：REST更勝一籌
- 安全性上：SOAP安全性高于REST，因為 REST 更關(guān)注的是效率和性能問題
總體上，因為 REST 模式的 Web 服務(wù)與復(fù)雜的 SOAP 和 XML-RPC 對比來講明顯的更加簡潔，越來越多的 web 服務(wù)開始采用 REST 風(fēng)格設(shè)計和實現(xiàn)。例如，Amazon.com 提供接近 REST 風(fēng)格的 Web 服務(wù)進(jìn)行圖書查找；雅虎提供的 Web 服務(wù)也是REST風(fēng)格的。REST 對于資源型服務(wù)接口來說很合適，同時特別適合對于效率要求很高，但是對于安全要求不高的場景。而 SOAP 的成熟性可以給需要提供給多開發(fā)語言的，對于安全性要求較高的接口設(shè)計帶來便利。所以我覺得純粹說什么設(shè)計模式將會占據(jù)主導(dǎo)地位沒有什么意義，關(guān)鍵還是看應(yīng)用場景，正是那句老話：適合的才是最好的
同時很重要一點就是不要扭曲了REST現(xiàn)在很多網(wǎng)站都跟風(fēng)去開發(fā) REST 風(fēng)格的接口，其實都是在學(xué)其形，不知其心，最后弄得不倫不類，性能上不去，安全又保證不了，徒有一個看似象摸象樣的皮囊。
三種主流的Web服務(wù)實現(xiàn)方案（REST+SOAP+XML-RPC）簡述及比較
API styles
RPC
RPC 是指遠(yuǎn)程過程調(diào)用，也就是說兩臺服務(wù)器A、B，一個應(yīng)用部署在A服務(wù)器上，想要調(diào)用 B 服務(wù)器上應(yīng)用提供的函數(shù)/方法，需要通過網(wǎng)絡(luò)來表達(dá)調(diào)用的語義和傳達(dá)調(diào)用的數(shù)據(jù)。
這時候的 message 包括 procedure name 和 parameter list，service descriptor 通常是 WSDL 和 XSDL 或者 non-XML approach(JSON-RPC)，作用是生成一個在 client 上的 service connector(proxy)。
Framework: SOAP, JAX-WS(java), WCF(Microsoft)
RPC 模型是 tightly copuled system，如果 parameter list 改變了，那么 client 將會 break。如果 descriptor 改變了，那么必須重新生成 connector 來連接 client。
request/response 是 RPC 的默認(rèn)模式，request/acknowlege 會 less coupled(seperation of concerns)，request 可以在隊列中等待，之后再進(jìn)行處理，這樣可以提高 scalability。如果 client 不想再等待的時候 block，那么可以用 asynchronous response handler。
Why
通過 http 調(diào)用別的機(jī)器上的進(jìn)程／方法
為什么 RPC 呢？就是無法在一個進(jìn)程內(nèi)，甚至一個計算機(jī)內(nèi)通過本地調(diào)用的方式完成的需求，比如不同的系統(tǒng)間的通訊，甚至不同的組織間的通訊。由于計算能力需要橫向擴(kuò)展，需要在多臺機(jī)器組成的集群上部署應(yīng)用.
RPC 的協(xié)議有很多，比如最早的 CORBA，Java RMI，Web Service的 RPC 風(fēng)格，Hessian，Thrift，甚至 Rest API。
通信細(xì)節(jié)
RPC的目標(biāo)就是要2~8這些步驟都封裝起來，讓用戶對這些細(xì)節(jié)透明。
Message
通過 http 給別的機(jī)器發(fā)送 command 命令、通知、其它信息，不用和別的進(jìn)程 direct coupling，也不用知道別的機(jī)器的方法的簽名。message 只包含一個參數(shù)。
這時候的 message 不包括 procedure name 和 parameter list，service descriptor 通常是 WSDL 和 XSDL，作用是生成一個 service connector(proxy)，service 的主要任務(wù)是分發(fā)，要求 service 更加的聰明，能夠評估消息內(nèi)容并決定去執(zhí)行哪個進(jìn)程調(diào)用哪個方法。
response 包括了相關(guān) service 的地址（url）。
Framework: SOAP, WS-Policy, WS-Security
默認(rèn)是 request/acknowledge 模式而不是 request/response。
追加一條新的 message type 很簡單。
Resource
操作另一臺機(jī)器上的數(shù)據(jù)，不用和別的進(jìn)程 direct coupling，最小化 the need for domain specific api’s。
消息內(nèi)容是一個 http 方法，一個 uri，一個 media type。
Resource API 可能是 Restful 的。
request/acknowledge 或者 request/response。
會產(chǎn)生 Security risk 因為 uri is hackable
總結(jié)
如果要建一個分布式系統(tǒng)，high performance(speed) 是最主要的要求，那么以下選項選哪個？
- REST sytle web service
- JAVA RMI
- SOAP based web service
- Javascript using JSON
- Plain old XML(POX) over HTTP
選 JAVA RMI，因為 java RMI 把 message 都編碼成 binary 的形式，減少了在各終端的 conversion time。
Postel’s Law
最后加一條 Postel’s Law。簡單來說就是?對自己嚴(yán)格，對他人寬容。“發(fā)送時保守”是告誡 web 開發(fā)人員的，HTML代碼應(yīng)該寫的盡可能符合標(biāo)準(zhǔn)，能夠方便別人（瀏覽器）去解析。“接收時開放”主要是說對一個不遵循固定標(biāo)準(zhǔn)（如不遵循HTML標(biāo)準(zhǔn)）的網(wǎng)頁，或者說網(wǎng)站中出現(xiàn)的一個或多個錯誤，瀏覽器仍能夠盡可能的解析并呈現(xiàn)。另外，瀏覽器必須向后兼容也是“接收時開放”的一個典型例子，不能因為大家都用 HTML5 編寫網(wǎng)站瀏覽器就不再支持之前的 HTML 版本。
參考鏈接：
你應(yīng)該知道的RPC原理
REST簡介
WebService的兩種方式SOAP和REST比較 (轉(zhuǎn))
三種主流的Web服務(wù)實現(xiàn)方案（REST+SOAP+XML-RPC）簡述及比較
原文地址：http://www.shuang0420.com/2016/11/02/Web-Service-Design-Patterns/
總結(jié)
以上是生活随笔為你收集整理的Distributed Systems笔记－Web Service Design Patterns的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 推荐系统--用户行为和实验设计
- 下一篇： Distributed Systems笔