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