你怎麼建築師複雜的Rails系統

Question

我們有我們推/拉數據從一個應用程序到另一個以下系統（及以上）：

• 託管型CRM（InsideSales.com）
• 的Asterisk電話系統（內部）
• 橫幅廣告系統（OpenX的，我們舉辦）
• 線索生成系統（自產自銷）
• 電子商務商店（大禮包，我們託管）
• 一個作業b OARD（自產自銷）
• 一些招聘網站的擦傷+入站作業提要
• 的電子郵件傳輸系統（如Mailchimp，自產自銷）
• 事件管理系統（如Eventbrite在線上售票，自產自銷）
• 儀表板系統（大量的圖表和報告甩開所有其他系統信息）

使用Rails 3在即，我真要追究了一個微型應用策略，但我試圖決定我是否應該有說話的應用程序通過REST HTTP API或因爲我控制了它們，我應該做一些類似於共享模型的東西代碼簡化，但也允許東西泄漏跨越邊界更容易...

我聽說37signals有很多小應用程序，我很好奇這些應用程序如何相互溝通......或者，如果你有來自您自己的多應用體驗的任何建議。

謝謝！我試着在我的博客http://rywalker.com/chaos-2010上問這個問題。

Answer 1

上次我不得不瘋狂地將一堆小應用程序粘在一起，我使用了一個簡單的REST API。

獎勵要點：它允許與用其他語言編寫的服務/應用程序集成。

如果你有一個瘋狂的熱衷於喜歡在沒有任何警告的情況下轉動技術的愛好經理的話，這也有幫助。

Answer 2

我和一個加號一樣：我不得不和一些不完全是HTTP準備好的守護進程交談。所以我遵循以下模式： REST API使用XML/JSON交換數據並使用memcache交換短消息。 （你定義了一些你將在memcache和另一個軟件中更新的密鑰，只需要拔下memcache來尋找那些密鑰）

作爲安全措施，我使用數字證書添加了API KEY或HTTP客戶端身份驗證。

Answer 3

事實上，我從DHH的電子郵件回覆...

我們使用兩者的結合，但我們默認接軌。我們使用直接數據庫集成的唯一地方是37signals ID用戶數據庫。因爲它需要這麼快。 REST更加理智。從那裏開始，然後根據需要進行優化。

Answer 4

另一種選擇是AMQP消息（通過rabbitmq或其他方式）。