簡單協議（如twisted.pb）與消息傳遞（AMQP/JMS）與Web服務（REST/SOAP）

Question

我目前在python上使用了扭曲的透視代理，而且我曾考慮切換到RabbitMQ之類的東西，我不確定它可以取代pb--我覺得我可能會在這裏比較蘋果和橘子。 最近我一直在閱讀很多關於REST的文章，並且與SOAP進行了不可避免的爭論，這讓我讀到了像SOA這樣的「企業級」web服務。

我有一個項目即將到來，我需要在Web和桌面上實現一些類似於erp的功能，所以我正在考慮使用哪種方法/技術來在服務器和客戶端之間進行通信。但我也想盡可能多地學習所有這些，所以我不想僅僅解決這個特定的問題。

你對服務器和客戶端之間的通信有什麼用？

我知道像透視經紀人這樣的python特定協議會限制我的互操作性，但我是否有權假定某些AMQP協議可以取代它？

如果我沒有弄錯，twisted.pb和amqp都使用一個永遠在線的連接和一個非常低的開銷協議。但一方面，保持大量客戶端連接始終可能成爲問題，另一方面，即使使用http保持活動，以及使用序列化部分的任何技巧仍然是Web服務的問題。

如果我在我的任何假設中錯了，我會很感激，如果有人能指出我在正確的方向瞭解更多。

Answer 1

一如既往，「它取決於」。首先，讓我們澄清術語。

Twisted的視角經紀人基本上是一個系統，您可以使用時，您可以控制分佈式操作（客戶端和服務器端）的兩端。它提供了一種將對象從一端複製到另一端並調用遠程對象上的方法的方法。複製涉及將對象序列化爲適合網絡傳輸的格式，然後使用Twisted自己的傳輸協議傳輸它。這在兩端都可以使用Twisted時非常有用，而且您不需要與非Twisted系統進行交互。

一般來說，Web服務是依賴HTTP進行通信的客戶端服務器應用程序。客戶端使用HTTP向服務器發出請求，返回結果。參數可以編碼在例如。 GET或POST請求或使用POST請求中的數據部分發送描述要採取的操作的XML格式的文檔。

REST是一種架構思想，系統所暴露資源的所有資源和操作都應該是可直接尋址的。簡而言之，這意味着用於訪問或操作資源的URI包含資源名稱和對其執行的操作。 REST可以並且通常作爲使用HTTP的Web服務來實現。

SOAP是用於消息交換的協議。它由兩部分組成：幾種傳輸方法的選擇和一種基於XML的消息格式。傳輸方法可以是例如HTTP，這使得SOAP成爲實現Wed服務的候選者。消息格式指定了有關請求的操作和操作結果的所有細節。

JMS是基於Java的消息傳遞系統的API標準。它定義了消息的一些語義（如一對一或一對多），並且包括尋址，創建消息，使用參數和數據填充它們，發送它們以及接收和解碼它們的方法。該API確保理論上可以更改底層的消息傳遞系統實現，而無需重寫所有代碼。但是，消息系統實現不需要與另一個啓用JMS的消息傳遞系統協議兼容。因此，擁有一個JMS系統並不意味着您可以與另一個JMS系統交換消息。您可能需要爲此開展某種橋樑服務工作，特別是在解決問題時，這將是一項重大挑戰。

AMQP嘗試通過定義消息系統必須遵守的有線協議來改善情況。這意味着來自不同供應商的消息系統可以交換消息。

最後，SOA是一種架構概念，應用程序被分解爲可重用的服務。然後將這些服務組合（「編排」）以實施該應用程序。每次創建新應用程序時，都有可能重用現有服務。 SOA也是需要非技術支持活動的事情，以便真正實現重用並且服務設計得足夠通用。此外，SOA是開始將遺留系統中的功能打包成一個有意義的整體的一種方式，然後可以使用更現代的技術進一步擴展和開發。可以使用各種技術實現SOA，例如Web服務，消息傳遞系統或企業服務總線。

您考慮了每個請求的一個連接與多個請求的連接保持打開的權衡。這取決於可用資源，消息傳遞模式和數據大小。如果傳入的消息流持續不變，那麼讓連接保持開放狀態可能沒有問題，因爲它們的數量不會有太大變化。另一方面，如果有來自多個系統的消息的突發，則釋放資源並且不會讓連接持續太久會很有用。而且，如果每個連接傳輸大量數據，則與總事務長度相比，打開和關閉連接的開銷較小。另一方面，如果你傳輸很多非常小的消息，那麼保持連接打開可能是有益的。使用您的特定參數進行基準對比是唯一確定的方法。

AMQP確實可以替代Twisted特定的協議。這將允許與非Twisted系統進行交互。

我希望這證明對您有用。如果你還在想某些事情（我認爲你是，因爲這是一個很大的領域），那麼我會建議將事情分解成更小的問題並單獨發佈。答案可以更精確。