2

很抱歉这个非常复杂的问题，但这是我已经研究了一段时间的东西，这真的让我很沮丧。我觉得在当今时代，我们拥有一百万零一种实现服务的方法，即跨平台 (SOAP) 且易于构建（感谢 .NET、java 和其他框架）。然而，这些技术已经在社区中存在了 5-10 年，但我们（或者至少我是）不断地困扰着同样的问题：

  1. 识别（跟踪服务）——UDDI；例如，本月不得不提醒同事 3 次服务所在的位置，尽管事实上有一个讨论该服务的 wiki 和一个相同文档的 PDF 版本，该文档位于我们保存服务文档的存储库中.
  2. 可扩展性——开箱即用的集群；作为组织，我们花很多钱来支付我们的管理员，只是为了观察我们服务的使用情况并做出决策，比如，这个服务是否需要更多的 RAM、更多的 CPU、更多的接口？我如何对此进行负载平衡？
  3. 监控 - 错误记录等；我数不清有多少次我必须在服务上设置跟踪才能了解为什么会发生似乎只影响一个客户的错误，或者必须将逻辑编码到服务中以序列化异常，将异常记录到 dbs，优雅地失败等等。
  4. 部署——易于部署；这些都没有将 DLL 部署到 5 个负载平衡服务器

这些问题中的每一个都需要组织实施某种类型的定制解决方案。#1 的文档和 UDDI。#2 的虚拟化和负载平衡硬件/软件。#3 的跟踪、向数据库/日志等写入异常。＃4的自定义部署软件。我为一个中型组织工作。我什至无法想象像 Sun、Google 或 Microsoft 这样规模的公司会如何解决这些困境。

也许我的愿景是不切实际的，但我梦想拥有一个框架本身，它位于管理上述所有内容的服务器集群之上。读到微软的 AppFabric 让我欣喜若狂，因为它似乎真的将 BizTalk 的一些功能扩展到了 WCF 服务实现者：缓存、托管、监控等。但是，从我所见，我仍然觉得它不存在实现我对一体化解决方案的梦想，该解决方案可帮助开发人员和组织编写可轻松跨集群扩展、轻松部署到集群中、可识别、甚至可能版本化的服务。

所以，我并不是说这篇文章是关于我的梦想的。我确实有一个问题。首先，我的梦想/想要完全不切实际吗？此外，有哪些可用的解决方案试图解决这些问题，而不将我们限制在开发服务的新的和更专有的方式（BizTalk）上？最后，关于完整的 SOA/ESB 解决方案，我们现在或未来在哪里看到了市场上的最大潜力？

4

3 回答 3

2

我认为您在这里谈论的是不同类型的问题。

1）。不阅读文档的开发人员。这是一个地方性问题，不仅限于 SOA - 只需查看 StackOverflow 上的一些问题。至少开发人员是在问你是否有服务，而不是在他们自己的代码中复制逻辑。我没有看到针对此类问题的任何技术解决方案，您已经提供了良好的注册表和文档，但一些开发人员更喜欢与人交谈。也许，甚至，这实际上是一件好事——人类交互的价值高于交互的技术内容。或者，你太好了：“不，我不会回答这个问题，你查一下。”

2）。缩放。有一些技术可以解决这个问题。（免责声明我为 IBM 工作，他们出售一些产品，所以我将参考这些 - 我并不是要暗示 IBM 是该领域唯一提供解决方案的供应商。）有这样的产品可以配置新机器，安装软件堆栈并将其添加到集群以解决工作负载变化。然后在 Java EE 世界中更细粒度的控制级别，应用程序服务器可以动态地调整流量和调整集群。请参阅WebSphere 虚拟企业

3）。监测。我没有“得到”你在这里的期望。这些棘手的错误很可能需要应用程序级别的跟踪。对于查找内存泄漏和性能瓶颈等问题，有非常好的工具，至少在 Java EE 世界中是这样。

4）。我无法与 .Net 世界交流，但我会说 Java EE 应用程序服务器在跨集群顺利部署应用程序方面做得很合理，并且在我们使用 JNI 并需要部署 DLL 的情况下，我们可以使用产品例如我提到的 Tivoli 堆栈来管理它。

因此，总而言之，我确实认为供应商正在尝试解决这些问题。而且我认为如果没有 SOA，您的生活不会更简单。想象一下，同样的问题适用于无数独立的应用程序。

于 2010-08-14T06:37:48.840 回答
1

这是我的两分钱。

我曾在一家错误地使用 SOA 的公司担任开发人员。他们实施的最糟糕的解决方案是使用 SOA 在桌面应用程序上对表单元素进行字段级验证。为了以可接受的方式执行，这些需要非常低的延迟。2-4 秒等待更改到新字段很快就会变老。该服务在 biztalk 服务器上通过网络运行。每个人都讨厌它。

如果您要这样做，您确实需要花费大量时间来处理网络延迟、服务故障、计时和超时问题。

不要得意忘形，认为 SOA 是所有问题的解决方案。在高级别使用它很棒，在低级别使用它会使您的应用程序变得脆弱、缓慢且无法调试。

于 2010-08-13T21:50:23.390 回答
0

如果您与 IBM 或大型 SOA 供应商之一交谈，他们会得到涵盖每种场景的产品。

Identification (Tracking services) - UDDI; e.g., had to remind a co-worker the 3 times this month where a service is at, despite the fact there is a wiki that discusses the service and a PDF version of the same documentation that lives in a repository where we keep our service docs.

注册表和存储库服务器。好消息是它会进行治理（升级、降级、版本控制、批准），并且您的 ESB 通常会针对注册服务器执行“查找”最新和最优秀的内容。

Scalability - Out of the box clustering; As organizations, we spend a lot of money on paying our admins just to watch the utilization of our services and make decisions like, does this service need more RAM, more CPU, more interfaces? How do I load balance this?

事务监控软件，例如用于 SOA 的 IBM Tivoli Composite Application Manager。基本上，它从水平的角度跟踪事物，并从最终用户/终端应用程序的角度查看是否存在服务中断。

至于你的集群......你必须选择好的中间件和架构。就个人而言，准备好“云”的东西。由 MOM 连接的带有 NoSQL 的应用服务器。

Monitoring - error logging, etc; I can't count how many times I have to set up tracing on services in order to see why a bug is happening that only seems to affect one customer, or have to code logic into the service to serialize exceptions, log exceptions to dbs, fail gracefully, etc.

适用于您的开发人员和供应商的企业标准。将所有业务和系统事件集成到一个仪表板中。（大多数公司都泄露了它们）。大多数企业商店已经这样做了。

Deployment - easy to deploy; none of this deploying DLLs to 5 load balanced servers

啊.. Microsoft IIS Web 部署工具 2.0。您只需更新主服务器即可同步 100 台 MS 服务器。这真的很容易。

于 2011-04-14T20:15:00.167 回答