Rails设计资源和示例

Question

我正在寻找一些关于如何将现有的单块Rails 3.0应用程序(35KLOC)分解为SOA设计的一些资源。任何书籍、博客、屏幕或示例应用程序都会非常棒。

我想回答的主要问题是：

• SOA是否是正确的设计？
• 我从哪里开始？
• 我能避免哪些常见的陷阱？
• 现在我该怎么想?以后我能做些什么？(综合表现)

我看到了一些资源，但并不完全确定它们是否是正确的起点：

• 面向服务的Rails设计
• RESTful网络服务
• 企业钢轨 (不确定这本书是否还相关)
• SOA设计模式 (也许太“进取”了？)

Answer 1

SOA是否是正确的设计？

那得看情况。你不讨厌这种答案吗？按照定义，使用消息传递或API调用将应用程序分解为松散耦合的服务将实现SOA。

它的美妙之处在于，您可以在不改变其接口的情况下交换服务实现，并允许独立部署，而不必中断整个应用程序。另外，我会通过专门的API控制器实现SOA，这些控制器是版本化的，并公开了自定义状态，而不是您为经过身份验证的用户或基于角色的会话保留的全部状态。

根据我的经验，两难的是是实现同步调用还是异步调用。同步调用显然更容易编程，但在执行时可能会让用户挂起，而且您必须处理长时间运行的查询的超时。注意数据库和web服务器超时。

如果您实现异步调用，比方说通过ActiveMessaging或类似的调用，您必须处理回调或某种通知才能向用户发出气泡。它还需要设置主消息代理和辅助消息代理，并可能设置一些JavaScript或计票器来检查状态。不过，一切都很有趣！

我从哪里开始？

我首先要看看它是否“值得”：毕竟，SOA很酷，但是确实引入了当前还没有的多个故障点。如果您认为您的分解应用程序将导致离散的服务，即HA，并将服务其他项目，我会从“德鲁比书”和“面向服务的”，正如你提到的。

我能避免哪些常见的陷阱？

我认为最大的担忧将是跨多个服务的事务，以及在远程服务失败时回滚整个操作的能力。如果在调用A的某个操作中调用B和B调用C和C失败，那么问题就开始了。谁知道C失败了？你将如何告诉B和A回滚？他们能吗？他们能拯救国家吗？预先设计的棘手问题。

另一个问题是，当您将工作流抛到SOA之上时，生活会变得复杂:谁是业务流程的管理员？集中还是分散？这一切都是绝对酷的东西，但沉重的爬进来，不是吗？但是，如果您必须迁移到SOA，这就是生活。

现在我该怎么想?以后我能做些什么？(综合表现)

我想找出目前可以在其他应用程序中使用的明显的通用服务。我不会过度使用SOA -您的环境，以避免添加故障点，并将SOA引入的故障保持在最低限度。

Answer 2

这是我的朋友Crowdtap的一个极好的资源。他们也做了同样的事情，这确实帮助他们极大地提高了产品开发的速度，给了他们更好的测试覆盖率。希望它能帮助https://www.youtube.com/watch?v=KsiQXAXsQDQ