2015-06-24 66 views
2

TL:DR;對於主從模式,使用RESTful API而不是TCP/Socket連接有什麼缺點/缺陷?使用web api而不是主/從通信使用tcp套接字是不是一個好主意?


我正在寫從第三方API獲取數據的Web應用程序,計算統計(及以上),並呈現它。獲取的數據存儲在數據庫中。

我正在用NodeJS和AngularJS編寫這個Web應用程序。

因此,有2個基本opertions應用程序將做到:

  1. 從前端
  2. 更新數據庫回答的HTTP請求。這包括:獲取數據,將數據保存到數據庫以及在內存數據庫(如redis)中每隔5分鐘緩存一些大量查詢的結果。

我想在兩個應用程序中分離這些操作。 HTTP服務器應該是主服務器。第二個應用程序只是一個奴隸,其中可以產生許多實例。

大師將執行某種任務處理器,它只是將任務分配給空閒的從站。奴隸非常愚蠢。它可以報告其狀態(空閒/繁忙以及一些細節,如當前負載等)。你可以在一個奴隸上開始任務。主人將負責排隊任務等等。

我想這是常見的服務器/代理模式。

所以我已經開始實現一個TCP服務器和客戶端,但它只是覺得這麼多開銷。有點像重新發明輪子。所以我想我只是我的客戶剛剛在這裏有正確的軌道上的兩個端點就像

[GET] /status 
[POST] /execute/:task 

上午我上使用HTTP服務器?

+0

A 「下行」 一個REST FUL [ HTTP] API是開銷。有關係嗎?那麼,這取決於 - *對於手頭的任務*重要嗎?手工編寫TCP處理程序(或發送的消息)*可以大大地重新發明輪子;這是許多不同實現/方法解決的問題。當然,也有基本的差異,比如TCP [通常]用作長流連接,而HTTP請求通常是短時間的。 (然後輸入長輪詢,WebSockets等。) – user2864740

回答

4

TL; DR;爲主從架構滾動您自己的REST API有一些缺點。

您的服務器/代理模式通常被稱爲microservices

滾動您自己的REST API可能會起作用,但可能不是最佳選擇。處理delivery semantics(例如,at most once vs at least once),瞬態故障,輪詢等可能會導致很多痛苦,然後才能做出正確的決定。

有庫/服務來提供方便不同水平:的

  1. Seneca - http://senecajs.org
  2. Pigato - http://prdn.github.io/pigato/
  3. Kong by Mashape - http://getkong.org
  4. Webtask by Auth0 (paid) - https://webtask.io
相關問題