SOA 简介：什么是面向服务的体系结构？

有些人在听到 soa（面向服务的体系结构）时感到害怕，他们认为这是一件非常复杂的事情，他们不想深入其中。实际上，soa 很容易理解，但实现起来有点困难。

我们将看看 soa 及其相关的东西。本专题分为四个主要部分。首先，总体架构及其与 soa 的关系。第二，代码开发以及如何创建适合soa模型的应用程序。第三，soa 相关技术，如：web 服务、wsdl、esb 等。最后我们将讨论 soa 的商业利益以及企业应该如何看待和采用这种技术用于他们的企业应用程序。

我们首先讨论字母“a”（架构）的含义，以及它在过去几年中是如何演变的。什么是架构？

建筑：1960 年代 - 1970 年代

让我们回到 60 年代和 70 年代，当时的主要架构恰恰是在谈论如何布局应用程序。在那个时期，事情很简单，只有一种架构，如下图所示：

该架构由两部分组成：主机和转储终端。用户可以通过转储终端访问主机。实际上，转储终端之所以称为“转储”，是因为它本身不做任何处理，只是在用户与其交互时接收来自应用程序的请求。然后它将信息发送到主机，主机完成所有需要的处理，并将信息发回转储终端。因此，如前所述，转储终端中实际上没有发生任何事情。

优点缺点：

让我们谈谈这种模式的优缺点。这里的优点是这个模型相对容易。当你创建一个应用程序时，你知道他们将在哪里生活，你知道你将要部署你的应用程序的环境。此外，您知道如何访问它（通过哑终端）。该模型的缺点基本上在于可扩展性级别。可伸缩性是指应用程序将如何处理的事实：更多用户加入以及何时开发更多应用程序功能。这里的主框架真的在做一切。所以，我们这里没有太多的可扩展性。主框架将保存数据、业务逻辑和任何类型的 pf 表示逻辑。

架构：1980年代

通过移动到 80 年代，我们可以看到这种模型发生了什么，以及为使其更适应新的变化和规模而进行的修改。我们开始看到很多用户使用个人电脑访问信息。所以，我们仍然有主框架。但是，主框架正在做的很多工作现在可以卸载到 pc 上。诸如表示逻辑之类的东西已移至个人电脑。因此，如果我们必须以不同的方式绘制图表或查找数据，PC 可以处理所有这些事情。主框架可以被隔离来保存数据。我们还可以将业务逻辑和诸如验证之类的东西分发给个人电脑。

结果，我们现在可以看到，不再让转储终端什么也不做，每次它都应该转到主机，现在 pc 可以处理大部分这些处理。所以，这里的主机可以充当数据服务器。实际上并不是所有的业务逻辑都存在于 pc 中，我们仍然有业务逻辑存在于主机中。这种模型称为客户端/服务器模型。这里的服务器是主机，客户端是个人电脑，如下图所示：

优点缺点：

这里的优点可能是显着提高的可扩展性级别。个人电脑现在可以执行更多任务，因此更容易添加更多用户和更多业务逻辑。这里最重要的缺点是维护。实际上这是这一关最大的问题；假设我们有 5000 个用户正在运行一些应用程序，当需要更新应用程序时，无论我们是否修复错误，处理应用程序内部的更多功能，我们都必须去 5000 个并更新他们的所有应用程序这些不同的电脑。经常做这样的过程真的很麻烦。我们遇到的另一个问题是所有个人电脑都有不同的配置，如果您在大型组织中工作，您可能有用户运行 windows 95、windows 98、windows 98 se、windows 2000、windows 2000 sp1、windows xp、windows xp sp1、windows xp sp2、.. 等让所有这些 pc 与您正在使用的应用程序一起工作可能是一个真正的挑战，而且您知道这对许多组织来说将是一场真正的噩梦。

建筑：1990 - 2005

在 90 年代末和 00 年代初，我们有了所谓的 3 层架构，我们可以用 n 代替“3”，因为我们可能有一大堆层。这里的主要 3 层是什么？我们有一个主服务器，它可能包含数据库和最重要的业务逻辑，然后我们在中间有一个应用程序服务器和客户端（通常是运行浏览器的电脑）。我们有可扩展性吗？绝对我们有很大的可扩展性，因为我们可以在这个级别添加更多的应用程序服务器，我们可以将其中的一些集群化，或者我们可以有一个负载平衡器来处理所有要从服务器访问信息的不同 pc。下图显示了模型部件之间的连接：

优点缺点：

让我们来看看维护，这是客户端/服务器架构中最大的问题。而不是去整堆 pc 和更新应用程序，我们只更新它的一侧，我们更新应用程序服务器。所以，当我们想要推出一些功能或修复错误时，我们只需推出到应用服务器，pc 访问应用服务器并获取新应用，应用服务器与数据服务器交互并执行适当的业务逻辑。因此，可扩展性和维护性是该模型最重要的优点。正如我们在这里看到的，该模型已经过改进，但实际上它具有很高的复杂性。我们在这里寻找一个真正的分布式系统，在这些大型应用程序的很多情况下很难弄清楚代码在哪里。那么，如果我们有一些验证代码，它是否存在于 jsp（个人电脑中的浏览器）中？验证是否在应用程序服务器上进行？验证是在服务器的数据库级别还是在业务逻辑中进行？尽管我们拥有真正的可扩展性并消除了很多维护问题，但是就我们构建应用程序的方式或换句话说，我们将如何构建所有这些系统而言，这变得非常复杂。

架构：2000年代后期

在 00 年代后期，我们有了 soa 的概念。我们已经看到了 3 层模型的分布式应用程序的复杂性。我们将隔离 3 层架构中的每个单独部分，如下图所示：

现在，我们有一个非常复杂的应用程序，如 erp，我们有 oracle e-business suites r12 和 sap。这些应用程序有：应收账款 (ar)、应付账款 (ap)、总账 (gl)、采购订单 (po)、库存管理 (im)、信用检查等。如果我们可以将这些部分分离出来并称为他们的网络服务。 Web 服务就像一个黑盒子，可以访问它以提供系统内的特定功能。所以，这里我们有一个用于 ar、ap、gl、po、im 和信用检查的 Web 服务。

假设我们要开发一个用于信用检查的网络服务。信用检查实际上就像它听起来的那样，可能会在其中放入一些供应商信息，我们希望给他们多少钱，并对他们如何支付账单进行一些分析，..等等。我们现在有另一个级别的灵活性，可以灵活地隔离和理解每个 Web 服务的功能。我们可以在我们组织内的所有不同应用程序中使用此 Web 服务。我们还可以一遍又一遍地重复使用网络服务的代码。