代码之家 › 专栏 › 技术社区 › regex

SOA/ESB困境

esb n-tier-architecture soa web-services

2

regex · 技术社区 · 14 年前

很抱歉,这个问题很复杂,但这是我已经研究了一段时间了,它真的让我很沮丧。我觉得在当今时代,实现服务的方法有很多种,其中之一就是跨平台(SOAP)和易于构建(多亏了.NET、java和其他框架)。然而,这些技术已经在社区中使用了5-10年,但我们(或至少我)经常遇到同样的问题:

识别(跟踪服务)-例如,UDDI必须提醒一位同事这个月有3次服务在哪里,尽管事实上有一个讨论服务的wiki和保存服务文档的存储库中的同一文档的PDF版本。
可伸缩性—开箱即用的集群;作为一个组织,我们花了很多钱支付给管理员,只是为了观察我们服务的利用率,并做出这样的决定:这个服务是否需要更多的RAM、更多的CPU和更多的接口?如何进行负载平衡?
监控-错误记录等;我不知道有多少次我必须在服务上设置跟踪,以便了解为什么一个bug正在发生,似乎只影响一个客户,或者必须将逻辑编码到服务中以序列化异常、将异常记录到dbs、优雅地失败等等。

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

也许我的设想是不切实际的,但我梦想拥有一个框架,它本身位于管理上述所有内容的服务器集群之上。看到微软的AppFabric,我欣喜若狂,因为它似乎真的将BizTalk的一些功能扩展到了WCF服务的实现者:缓存、托管、监视等。然而,从我所看到的情况来看,我仍然觉得它没有实现我的梦想:一个能帮助开发人员和组织编写服务的一体化解决方案它们可以很容易地跨集群扩展,很容易部署到集群中,并且可以识别,甚至可以是可版本的。

所以,我不是说这篇文章是关于我的梦想。我确实有个问题。首先,我的梦想/愿望是否完全不现实?此外,有哪些解决方案可以解决这些问题而不限制我们使用新的、更专有的方式(BizTalk)开发服务?最后,关于一个完整的SOA/ESB解决方案,我们认为现在或将来市场上最有潜力的地方在哪里?

3 回复 | 直到 14 年前

1

2

Arjan Tijms Mike Van 12 年前

我认为你在谈论各种各样的问题。

1). 不阅读文档的开发人员。这是一个普遍存在的问题,不仅仅局限于SOA—只要看看有关StackOverflow的一些问题。至少开发人员会问您是否有服务,而不是在自己的代码中复制逻辑。我没有看到任何技术上的解决方案来解决这类问题,您已经提供了很好的注册表和文档,但是一些开发人员更喜欢与人交谈。也许,甚至,这实际上是一件好事-人类交互的价值高于交互的技术内容。或者,你太好了:“不,我不回答这个问题,查一查。”

this 它可以配置一台新机器,安装一个软件堆栈,并将其添加到集群中以解决工作负载的变化。然后,在javaee世界中的细粒度控制级别上,应用服务器可以动态地塑造流量和调整集群。看到了吗 WebSphere Virtual Enterprise

3). 监测。我不明白你在这里所期望的。这些棘手的bug很可能需要应用程序级的跟踪。对于一些问题,如查找内存泄漏和性能瓶颈,有非常好的工具,至少在javaee世界是这样。

4). 我不能告诉.Net世界,但我要说的是JavaEE应用服务器在跨集群顺利部署应用方面做得很好,在我们使用JNI并需要部署DLL的情况下,我们可以使用我提到的Tivoli堆栈之类的产品来管理这一点。

2

1

Jay 14 年前

这是我的两分钱。

我在一家错误使用SOA的公司做过开发人员。他们实现的最糟糕的解决方案是使用SOA对桌面应用程序上的表单元素进行字段级验证。要执行这些操作,需要非常低的延迟。2-4秒的等待换到一个新的领域会很快变老。该服务在biztalk server上通过网络运行。每个人都讨厌它。

如果你要这样做,你真的需要花很多时间来处理网络延迟,服务故障,时间和超时问题。

3

0

Albert T. Wong 14 年前

如果您与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.

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?

事务监控软件,如ibmtivolicompositeapplicationmanagerforsoa。基本上,它从一个水平的角度跟踪事情,并从最终用户/最终应用程序的角度查看是否有服务中断。

至于你的群集。。。。您必须选择好的中间件和体系结构。就个人而言,准备好“云”的东西。应用服务器与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