公司内部系统的后端变得越来越复杂，我想探索做SOA风格架构而不是沉重的单片系统的想法。我应该从哪里开始？
我是SOA的新手。这是指个人CF实例，它们通过远程Web服务调用相互通信？如何处理诸如错误处理和服务器中断之类的事情？如果ESB的每个部分都在ColdFusion中，ESB是否会对架构有益？
数据库层怎么样？他们应该共享一个巨大的数据库，还是应该自己以自己的方式存储？
谢谢
答案 0 :(得分：1)
首先，你想要完成什么？ SOA对于需要相对容易更改并且可供新程序员访问的系统非常有用。另一方面，您倾向于进行性能权衡，因为您最终会隔离持久性 - 因此它的交互发生在应用程序服务器而不是数据库中。通常这种性能权衡是一个非问题，但如果你正在开发一个高通量事务系统，你可能需要通过在数据库中放入一些算法并使这些算法破坏你的服务而妥协。
因此，如果您想要专业人士而不是特别关注利弊，请首先阅读一些关于该主题的适用书籍：
您想要趋向的是具有高级服务对象的设计，其关系通过dependency injection通过service locator容器进行管理。在ColdFusion中，ColdSpring就是一个例子。然后允许object mocking，这样您就可以轻松进行单元测试。例如，如果服务存在于其他服务器上，那么本地具有代理的服务对象将作为依赖项传递。为了测试，这些代理被模拟，因此他们不必与远程服务器通信。
关于错误处理和服务器中断。我假设你主要关心处理本地服务器控制之外的问题。这是使用服务代理对象的另一个原因。让这个对象负责处理超时，错误的响应值等 - 实际上是anti corruption layer。
对于数据库共享，我将构建表关系以反映我的服务对象关系。因此，如果有问题的表具有仅通过服务相关的数据，我将不会强制执行任何外键约束。因此，尽管它们可能位于同一个数据库中，但这并不重要。这使您可以将这些服务和数据库表移动到其他位置，而对代码的更改相对较少。
答案 1 :(得分：0)
我听说SOA用来描述很多不同的设置，所以我不确定是否有“正确”的答案，但核心概念是服务层。最大的好处是你对DB层的最后一个问题的答案是 - 以上所有。一旦处理存储/持久性的逻辑在服务层中被隔离，并且应用程序只是调用到该层，就可以更容易地将某些数据移动到其他服务器或在需要时将它们合并为一个。您甚至可能最终只会调用其他服务，这些服务通常被称为service facade。
对于“现实生活”的例子。假设您有一些存储名称，地址，电子邮件等的客户数据库。您可以将其公开为Web服务，您可以在其中获取有关某人的信息。在某些时候，你会扩大这个家庭酿造系统，并决定许可一个完整的CRM系统。由于您已在Web服务中隔离了所有与客户相关的事务，因此您只需更新该服务即可从CRM软件而非数据库中获取信息。这真的是服务架构真正发挥作用的地方。
就错误处理而言，如果您的应用程序和服务都是用CF编写的，那么您将在两个（或所有）层上进行日志记录和错误处理。显然，服务服务器上的服务器中断将非常严重，因为它会影响它上面的所有内容。我们使用监视器，如果有任何超时或开始向南发送电子邮件到服务台。在客户端应用程序上，我找到的密钥是为Web服务调用设置合理的超时。我从未见过使用ESB，但我猜它会给你另一层抽象来管理实际的调用。这可能有助于超时等，但我真的不能说。