用restful來架構分布式系統？

1樓：NoStar

簡單地說，REST值得考慮。

request/reply 是一種常見的系統間整合方式，主要有 RPC和REST 兩種實現風格。

RPC 是 remote procedure call 的縮寫。常見的框架有google 的gRPC。

REST 是HTTP 的一種 architectural style。

RPCREST

迭代速度

面向operation，類似面向過程程式設計，迭代速度通常更慢。例如針對乙個book service，我們可能前後需要定義如下API

1. listAllTextBooks2. getBooksByName3.

getBooksByPrice4. registerBookWithName5. deleteBookWithName7.

deleteBookWithId...

面向resource。類似於物件導向程式設計，迭代速度可以更快。針對book 我們只需要定義乙個book resource，配合HTTP GET/POST/PUT/DELETE 等verb和 query syntax，可以輕易組合出RPC中的所有operation。

整合複雜度

RPC整合更複雜。

1. RPC完全基於operation，operation和operation需要額外成本來理解它們的關係；2. RPC operation之間較難做到風格統一，特別是要考慮後向相容的情況；3.

RPC 通常需要client lib才能測試，當然有些框架有自帶的網頁版explorer方便除錯。

設計複雜度

面向過程，相對更簡單。

1. REST通常需要更長的時間來設計，對domain entity和它們之間的關係進行建模。有些場景下，需要更長時間才能抽象成entity。

2. HTTP verb數量有限，且REST 通常僅使用少數HTTP verbs (GET/POST/PUT/DELETE 等)。有些場景下會不夠用，需要額外設計。

效率可以基於HTTP （通常只使用GET, POST verb 和單一的URI）或TCP/UDP。相比於REST，可以做到更低延遲，沒有額外的HTTP overhead。

完全基於HTTP。

框架支援

RPC通常需要非常好的框架支援，來解決緊耦合、跨語言、相容性、快取等挑戰。目前開源已有很多框架，例如google的gRPC

HTTP本身有很好的系統於平台支援；REST 是stateless的，。OpenAPI/Swagger 等也提供了很好的工具支援。

隨著REST變得越來越流行，總的說，REST是一種值得考慮的整合風格。

2樓：NeoX

分布式系統的範疇太廣了，不過如果是追求效能的computation framework之類的，明顯不合適，REST比較適合做面向GUI的API.

分布式系統如果追求效能的話，一般自己寫乙個基於netty的狀態機. REST最大的問題是很難有效地實現call back.

Netty: Home

3樓：

有一定的效能損耗，但是不用太在意，這個損耗是可以接收的。但是前提是rest服務介面本身的設計質量要高。對於企業內部的資訊化系統，如果僅僅是考慮元件化，還可以參考OSGI的方式來架構，其本身也是元件化和服務化的思想。