非常大的單片Django應用程序。所有組件都使用相同的數據庫。我們需要分離服務，以便我們可以獨立升級系統的某些部分而不影響其餘部分。
我們使用RabbitMQ作爲Celery的經紀商。
現在我們有兩種選擇：使用REST接口
我的團隊朝着HTTP傾斜，因爲這是他們所熟悉的，但我認爲使用RPC over AMQP的優點遠大於它。
AMQP爲我們提供了輕鬆添加負載均衡和高可用性的功能，並保證消息傳遞。
而使用HTTP，我們要創建客戶端的HTTP包裝與REST接口的工作，我們必須把在一個負載平衡器，爲了有HA等
隨着AMQP我可以建立基礎設施剛產生服務的另一個實例，它將連接到與其他實例相同的隊列，以及bam，HA和負載平衡。
我錯過了我對AMQP的想法嗎？
起初，
pickle，它應該比JSON或任何其他格式更快。所以：HTTP + REST或AMQP + RPC，答案是真的受基礎設施複雜性和資源使用。沒有任何特定的要求，兩種解決方案都可以正常工作，但我寧願做一些抽象以便能夠透明地在它們之間切換。
你告訴你的團隊熟悉HTTP但不熟悉AMQP。如果開發時間是你獲得答案的重要時間。
如果你想以最小的複雜度構建高可用性基礎架構，我想AMQP協議就是你想要的。
我曾與他們兩個和RESTful服務優勢的經驗是：
優點：
請注意，您可以在基於AMQP的API上爲RESTful API提供第三方服務，而REST不是協議而是範例，但您應該考慮構建您的AQMP RPC api。我這樣做是爲了向外部第三方服務提供API，併爲那些在舊代碼庫上運行的基礎架構部分或無法添加AMQP支持的部分提供API訪問。
如果我是對的，你的問題是關於如何更好地組織軟件不同部分之間的通信，而不是如何爲最終用戶提供API。
如果你有一個高負荷的項目RabbitMQ是一個很好的軟件，你可以很容易地添加任何數量的工人在不同的機器上運行。它也具有鏡像和集羣功能。還有一點，RabbitMQ建立在Erlang OTP的基礎之上，這是一個高可靠性，穩定的平臺...（bla-bla-bla），不僅適用於市場營銷，也適用於工程師。當nginx日誌將所有磁盤空間放在RabbitMQ運行的同一分區上時，我只有一次RabbitMQ的問題。
解決方案OP不得不接受的一個諷刺是，AMQP或其他MQ解決方案通常用於隔離呼叫者與純HTTP服務固有的不可靠性 - 提供某種程度的超時&重試邏輯和消息持久性調用者不必實現它自己的HTTP絕緣代碼。通過可靠的AMQP核心的非常薄的HTTP網關或適配器層，可以選擇使用更可靠的客戶端協議（如JSONRPC）直接訪問AMQP，這通常是此場景的最佳解決方案。
我們結束了HTTP/REST。我真的很想去AMQP路線，因爲它非常適合我們的建築，但我的團隊不想嘗試新的東西，這是一個無賴。 使用HTTP代替AMQP和RPC開發Redudant和高度可用的SOA系統需要做很多工作。 – jreid42
@pinepain我認爲有一件事要提及（如果Iam錯誤，請糾正我），如果使用AMQP，您可以將消息推送到目標位置，就像您不能使用HTTP一樣（使用請求響應方法） – rayman
@rayman HTTP和AMQP是不同的概念，所以我不希望使用這些標準進行比較。 – pinepain