我正在寻找一些资源来获取现有的单体 Rails 3.0 应用程序 (35K LOC) 并将其分解为 SOA 设计。任何书籍、博客、截屏视频或示例应用程序都会很棒。
我希望回答的主要问题是：
我见过的一些资源，但不完全确定它们是否是正确的起点：
SOA 是否是正确的设计？
这取决于。你不讨厌这样的答案吗？根据定义，使用消息传递或 API 调用将您的应用程序分解为松散耦合的服务将实现 SOA。
它的美妙之处在于您可以在不更改其接口的情况下交换服务实现，并允许独立部署而无需关闭整个应用程序。此外，我将通过专门的 API 控制器来实现 SOA，这些 API 控制器是版本化的并公开自定义状态，而不是您为经过身份验证的用户或基于角色的会话保留的整个状态。
根据我的经验，困境在于是实现同步调用还是异步调用。同步调用显然更容易编程，但可能会让您的用户在执行时挂起，并且您必须为长时间运行的查询处理超时。注意数据库和 Web 服务器超时。
如果你实现异步调用，比如说通过 ActiveMessaging 或类似方法，你必须处理回调或某种通知才能冒泡给你的用户。它还需要设置主要和辅助消息代理，可能还有一些 JavaScript 或轮询器来检查状态。不过这一切都很有趣！
我从哪说起呢？
我会先看看它是否“值得”：毕竟，SOA 很酷，但确实引入了您目前没有的多个故障点。如果您认为分解的应用程序会产生 HA 的离散服务并将为其他项目提供服务，那么我将从您提到的“druby 书”和“面向服务”开始。
我可以避免哪些常见的陷阱？
我认为最大的担忧是跨多个服务的事务以及在远程服务失败时回滚整个操作的能力。如果您在某些操作中调用 A 并且它调用 B 并且 B 调用 C 并且 C 失败，那么问题就开始了。谁知道C失败了？你将如何告诉 B 和 A 回滚？他们可以吗？他们保存状态吗？前期设计的棘手问题。
另一个问题是，当您将工作流置于 SOA 之上时，生活会变得复杂：谁是业务流程的守护者？集中式还是分布式？这一切又是绝对酷的东西，但沉重的东西悄悄蔓延，不是吗？但是，如果您必须迁移到 SOA，这就是生活。
我现在应该考虑什么与以后可以做什么？（即性能）
我会考虑现在可以在其他应用程序中使用的明显通用服务。我不会过度 SOA 您的环境以避免增加故障点并将 SOA 引入的故障点保持在最低限度。
这是 Crowdtap 的 CTO 朋友提供的绝佳资源。他们做了同样的事情，这确实帮助他们极大地提高了产品开发的速度，并为他们提供了更好的测试覆盖率。希望它有帮助https://www.youtube.com/watch?v=KsiQXAXsQDQ