2010-06-09 25 views
5

我们有我们推/拉数据从一个应用程序到另一个以下系统(及以上):你怎么建筑师复杂的Rails系统

  • 托管型CRM(InsideSales.com)
  • 的Asterisk电话系统(内部)
  • 横幅广告系统(OpenX的,我们举办)
  • 线索生成系统(自产自销)
  • 电子商务商店(大礼包,我们托管)
  • 一个作业b OARD(自产自销)
  • 一些招聘网站的擦伤+入站作业提要
  • 的电子邮件传输系统(如Mailchimp,自产自销)
  • 事件管理系统(如Eventbrite在线上售票,自产自销)
  • 仪表板系统(大量的图表和报告甩开所有其他系统信息)

使用Rails 3在即,我真要追究了一个微型应用策略,但我试图决定我是否应该有说话的应用程序通过REST HTTP API或因为我控制了它们,我应该做一些类似于共享模型的东西代码简化,但也允许东西泄漏跨越边界更容易...

我听说37signals有很多小应用程序,我很好奇这些应用程序如何相互沟通......或者,如果你有来自您自己的多应用体验的任何建议。

谢谢!我试着在我的博客http://rywalker.com/chaos-2010上问这个问题。

回答

4

上次我不得不疯狂地将一堆小应用程序粘在一起,我使用了一个简单的REST API。

奖励要点:它允许与用其他语言编写的服务/应用程序集成。

如果你有一个疯狂的热衷于喜欢在没有任何警告的情况下转动技术的爱好经理的话,这也有帮助。

3

我和一个加号一样:我不得不和一些不完全是HTTP准备好的守护进程交谈。所以我遵循以下模式: REST API使用XML/JSON交换数据并使用memcache交换短消息。 (你定义了一些你将在memcache和另一个软件中更新的密钥,只需要拔下memcache来寻找那些密钥)

作为安全措施,我使用数字证书添加了API KEY或HTTP客户端身份验证。

5

事实上,我从DHH的电子邮件回复...

我们使用两者的结合,但我们默认接轨。我们使用直接数据库集成的唯一地方是37signals ID用户数据库。因为它需要这么快。 REST更加理智。从那里开始,然后根据需要进行优化。

0

另一种选择是AMQP消息(通过rabbitmq或其他方式)。