如果这个问题很密集，请原谅我。
背景：我们有几个集成在数据库中的内部应用程序。我们正在研究如何将其分解，似乎转向一种架构，其中每个应用程序通过服务公开其功能，而不是调用其他应用程序的数据库，这是最有意义的。对我来说，这似乎是一个面向服务的架构。当我四处寻找有关开始使用面向服务架构的信息时，我看到很多关于这篇文章的讨论：SOA 已死；万岁服务。我还从 Martin Fowler 和 Jim Webber 那里看到了这一点：我的巴士在这看起来很大吗？.
问题：
SOA 是一个聪明的想法，但围绕它的巨大炒作使人们写下“SOA 现已死”。这不是真的，就像句子“结构化编程已经死了，现在每个人都在做 OOP！” 也不总是正确的：有时结构代码是唯一的选择，但应该根据评估而不是炒作做出决定。谈到 SOA 时也是如此：有时您需要 SOA，有时您需要服务。
我对 SOA 一无所知，但我通常会看到这些技术经历一个循环：
我的猜测是 SOA 只是这些技术中的另一种。
SOA 并没有消亡。就像每一个好主意一样，它成为我们景观的一部分。电子商务这个词在早期是一个伟大的想法，现在我们甚至不再使用这个词了。我什至不再使用术语面向对象了，这几乎是假设的。
当前的炒作是云计算。把所有东西都放在云端。
SOA 的最佳实践是在需要的地方编写好的服务。过度使用 SOA 会增加您的延迟。如果您需要有效地执行代码，请在数据库中使用存储过程。如果它也能完成这项工作，你也无法击败一个好的本地服务。
我会说它并没有死，但它现在已落入架构师的工具集中，因为它现在知道它可以在哪里提供帮助，如果它可能没有帮助。
使用 SOA 与您的数据库对话是没有意义的，因为您希望该集成是紧密且高性能的。但是在正确的位置使用它可以让您在组织的不同部分之间拥有干净整洁的界面，并且可能允许您升级每个系统而不管其他系统。
但是在现实生活中，如果您的工资系统出现故障，每个人都会非常不高兴，仅仅因为您的应用程序可能会在没有它的任何一个组件的情况下跛行并不意味着它不会影响您的系统。
不可能创建只了解接口但不了解底层系统的系统（我将用以下语句警告该声明：“运行良好且性能良好”）。以网络浏览器为例，每个好的网站都以“他们使用什么浏览器并修复我的网站并利用 xyz 功能”开头。
SOA 是一个典型的例子，说明当一种有用的模式（甚至不是特别新的模式）作为架构的基础出售时会发生什么。如“集成企业的核心设计”。
中间件公司特别容易受到这些概念的影响，因为他们自己在尝试将他们的产品和服务联系在一起时面临挑战，而且他们需要具有潜在大预算的大创意。
一个单一的架构可以包含企业中所有软件的所有集成需求，从表面上看，这不是很可疑吗？
大多数 SOA 都试图简化一个由较少使用的 SOA 子集（称为事件驱动架构 (EDA)）更好地服务的流程。
问题在于，SOA 是作为从 Web 服务构建的东西而普及的，首先要选择底层技术来实现 SOA，这可能是一个艰难的选择。SOAP 不是必须的，但通常用作紧密耦合的 RPC 机制。即使在内部系统中，这也不能很好地扩展，更不用说跨系统或更糟糕的企业了。
您可以在 SOAP 之上构建 EDA，但通常您最终会在此之上获得一些即席技术。异步操作和 Web 服务涉及一些可能的黑客攻击。
即使您已经了解了 RPC Web 服务的紧密耦合特性，您仍然会遇到合作伙伴之间紧密绑定和 WSDL 版本控制的问题。
您仍然可以使用 XML 有效负载和模式，但 SOAP 本身会退化为一个相当愚蠢的传输包装器，该包装器围绕完全在 WSDL 之外定义的有效负载“blob”。
StackOverflow 是一个非常独立的 Web 应用程序。最接近 SOAish 的可能是它使用的 OpenId 机制。它是简单的客户端-服务器，而不是 SOA。你想的太小了。
是的，SOA 已经死了，但它已经复活成为短暂的东西，参见 - http://www.soa-manifesto.org/。现在每个人仍然可以说他们在做 SOA，不管他们做什么，只要他们能宣称遵循 6 条诫命（或原则）：
这对我来说更像是在说，任何花费更多时间和金钱来制造“面向未来”的 IT 解决方案的公司都可以宣称正在做 SOA。这真的是一件好事。
为什么不采用通过接口公开功能的模块化设计，而不是 SOA？
这是同样的事情，只是不那么令人反感。
SOA 的“最佳”示例是 SAP 的 BusinessByDesign 冒险。花费了大量的时间和资源，甚至在使其正常工作之前就开始出售它，然后尝试修复/关闭它。
我建议您不要让这些文章吓跑您或以任何其他方式影响您。考虑你的特殊情况：它是否给你带来了服务的好处？如果是，那就去吧。如果不是，那么行动的过程是显而易见的。
我相信 SOA 背后的思想基本上有一个乌托邦的想法——创建各种服务的世界，这些服务相互发现并互操作，以某种方式自动为您提供高级服务。但那是他在人工智能/科幻小说的方向上的东西。您只能在非常具体的场景中实现接近的目标，您可以使用算法方法进行编程。不仅如此......好吧，不是在这个世纪......
如果您正在使用内部企业范围的应用程序，则可以使用 SOA 来实现它们。如果您正在创建一个面向 Web 的应用程序（我的意思是一个与新的开放堆栈 oAuth、OpenID 等兼容的应用程序），那么将 SOA 替换为 WOA。Stackoverflow.com 就是这种野兽的一个例子。
只要企业存在，就会有集成需求，系统总是要说话的。SOA 似乎是解决此类分布式问题的明智方法。但不幸的是，它忽略了性能问题。为了提出一种可能的解决方案，我发表了一篇关于“流体服务”的文章，通过使用面向流的通信作为面向消息的通信的替代方案来利用客户端和服务器之间的并行性。
SOA Maganizine 上的这篇文章描述了这个概念： http: //www.soamag.com/I41/0710-2.php 这是一篇更实用的文章，其中还包括 CodeProject 上的示例 WCF 代码：'An Experiment on Fluid Services for High Responsive , Scalable and Reusable SOA Services'（抱歉，放不下链接）
SOA 适用于本质上是“分布式”的架构。如果您只是在谈论基于接口的编程方法，那么您正在走向“基于组件”的技术，例如 COM+、CORBA。或类似 .NET Remoting 的东西。但是，如果您谈论的是在随时间演变并由多个独立组开发的分布式环境上的基于合同的开发，那么您就是在 SOA 范式上。必须分发这些服务。但我并不是说 SOA 概念不能用于本地处理。我是说，这才是它真正针对的地方，其他人都没有。但是，不幸的是，SOA 并不关心性能之类的事情。因为那是它惨败的地方。