Pet*_*own 24 ruby soa ruby-on-rails
我正在寻找一些资源来获取现有的单片Rails 3.0应用程序(35K LOC)并将其分解为SOA设计.任何书籍,博客,截屏或示例应用程序都会很棒.
我想回答的主要问题是:
我见过的一些资源,但不完全确定它们是否适合开始:
dyn*_*nex 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引入的内容保持在最低限度.