SOA/ESB 困境
很抱歉这个非常复杂的问题，但这是我已经研究了一段时间的东西，这真的让我很沮丧。我觉得在当今时代，我们有一百万零一种方法来实现跨平台 (SOAP) 且易于构建的服务（感谢 .NET、java 和其他框架）。然而，这些技术已经在社区出现了 5-10 年，但我们（或者至少我）不断地受到同样问题的困扰：
- 身份识别（跟踪服务）- UDDI；例如，本月必须 3 次提醒同事某项服务的位置，尽管事实上有一个 wiki 讨论该服务，并且同一文档的 PDF 版本位于我们保存服务文档的存储库中。
- 可扩展性——开箱即用的集群；作为组织，我们花费大量金钱向管理员付费，只是为了观察我们服务的利用率并做出决策，例如该服务是否需要更多 RAM、更多 CPU、更多接口？我如何对此进行负载平衡？
- 监控——错误记录等；我无法计算有多少次我必须在服务上设置跟踪才能了解为什么会发生似乎只影响一个客户的错误，或者必须将逻辑编码到服务中以序列化异常，将异常记录到数据库，部署
- - 易于部署；这些问题都不需要将 DLL 部署到 5 个负载平衡服务器。
这些问题中的每一个问题都需要组织实施某种类型的自定义解决方案。 #1 的文档和 UDDI。虚拟化和负载平衡硬件/软件#2。 #3 的跟踪、将异常写入数据库/日志等。 #4 的定制部署软件。我在一家中型组织工作。我什至无法想象像 Sun、Google 或 Microsoft 这样规模的公司将如何解决这些困境。
也许我的愿景不切实际，但我梦想拥有一个框架本身，它位于管理上述所有内容的服务器集群之上。我欣喜若狂地阅读了 Microsoft 的 AppFabric，因为它似乎确实将 BizTalk 的一些功能扩展到了 WCF 服务实现者：缓存、托管、监控等。但是，从我所看到的情况来看，我仍然觉得它还没有存在。实现我的梦想，即提供一种一体化解决方案，帮助开发人员和组织编写可轻松跨集群扩展、轻松部署到集群中、可识别、甚至可版本化的服务。
所以，我并不是说这篇文章是关于我的梦想的。我确实有一个问题。首先，我的梦想/想要完全不现实吗？此外，有哪些可用的解决方案可以尝试解决这些问题，而不会将我们限制在开发服务的新的且更专有的方式（BizTalk）中？最后，对于完整的 SOA/ESB 解决方案，我们认为现在或未来市场上最有潜力的地方在哪里？
Sorry for the very involved question, but this is something I've been researching for a while now and it is really frustrating me. I feel like in today's age we have a million and one ways to implement services tat are cross-platform (SOAP) and easy to build (thanks to .NET, java, and other frameworks). However, these technologies have been in the community for 5-10 years, but we are (or at least I am) constantly plagued with the same issues:
- 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?
- 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
Each one of these problems requires some type of custom solution implemented by the organization. Documentation and UDDIs for #1. Virtualization and load balancing hardware / software for #2. Tracing, writing exceptions to databases / logs, etc for #3. Custom deployment software for #4. I work for a mid-sized organization. I can't even imagine how a company the size of Sun, Google, or Microsoft would tackle these dilemmas.
Maybe my vision is unrealistic, but I dream of having a Framework per se that lives on top of a server cluster that manages all of the above. I was ecstatic to read about Microsoft's AppFabric since it really seems to extend some of the functionality of BizTalk to WCF service implementors: Caching, Hosting, Monitoring, etc. However, from what I've seen, I still don't feel it lives up to my dream for an all-in-one solution that assists the developer and organization in writing services that are scaled across clusters easily, deployed into the cluster easily, and identifiable, possibly even version-able.
So, I don't mean this post to be about my dream. I do actually have a question. For starters, is my dream / want completely unrealistic? Furthermore, what solutions are there available that attempt to solve these problems without confining us to a new and more proprietary way (BizTalk) of developing services? An lastly, in concern to a complete SOA / ESB solution, where do we see the most potential in the market right now or in the future?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这是我的两分钱。
我曾在一家错误使用 SOA 的公司担任开发人员。他们实施的最糟糕的解决方案是使用 SOA 对桌面应用程序上的表单元素进行现场级验证。为了获得可接受的性能，这些需要非常低的延迟。切换到新字段需要 2-4 秒的等待时间很快就会过时。该服务通过网络在 biztalk 服务器上运行。每个人都讨厌它。
如果您打算这样做，您确实需要花费大量时间处理网络延迟、服务故障、计时和超时问题。
不要得意忘形并认为 SOA 是所有问题的解决方案。在高级别使用它很棒，在低级别使用它会使您的应用程序脆弱、缓慢且无法调试。
Here's my two cents.
I've been a developer at a company that used SOA incorrectly. The worst solution they implemented was field level validation of form elements on a desktop app using SOA. To perform acceptably these require very low latency. A 2-4 second wait to change to a new field gets old fast. The service ran over the network on a biztalk server. Everyone hated it.
If you're going to do this you really need to spend a lot of time dealing with network latency, service failure, timing, and timeout issues.
Don't get carried away and think SOA is the solution to every problem. Used at a high level it's great, used at a low level it makes your applications fragile, slow, and impossible to debug.
如果您与 IBM 或大型 SOA 供应商之一交谈，他们会得到涵盖每种场景的产品。
注册表和存储库服务器。好处是它可以进行治理（升级、降级、版本控制、批准），并且您的 ESB 通常会针对注册服务器“查找”最新和最好的内容。
事务监控软件，例如 IBM Tivoli Composite Application Manager for SOA。基本上，它从水平角度跟踪事物，并从最终用户/最终应用程序的角度查看是否存在服务中断。
就你的集群而言......你必须选择好的中间件和架构。就我个人而言，准备好“云”的东西。通过 MOM 连接的具有 NoSQL 的应用程序服务器。
面向您的开发人员和供应商的企业标准。将所有业务和系统事件集成到单个仪表板中。 （大多数公司都泄露了它们）。大多数企业商店已经这样做了。
啊.. Microsoft IIS Web 部署工具 2.0。只需更新主服务器即可同步数百台 MS 服务器。这真的很容易。
If you talk to IBM or one of the big SOA vendors, they got a products that cover each scenario.
Registry and Repository server. Nice thing is that it does governance (promotion, demotion, versioning, approval) and your ESB typically does a "lookup" for the latest and greatest against the register server.
Transaction monitoring software like IBM Tivoli Composite Application Manager for SOA. Basically, it tracks things from a horizontal point of view and to see if there is a service disruption from a end user/end app point of view.
As far as your clustering.... you have to pick good middleware and architecture. Personally speaking, get stuff that is "cloud" ready. App Servers with NoSQL connected by MOM.
Enterprise standards for your developers and for your vendors. Integration of all business and system events into a single dashboard. (Most companies spilt them). This is done already at most enterprise shops.
Ahh.. Microsoft IIS Web Deployment Tool 2.0. You can sync 100s of MS servers by just updating the master. It's really easy.
我认为您在这里讨论的是不同类型的问题。
1）。不阅读文档的开发人员。这是一个普遍存在的问题，不仅限于 SOA——只需看看 StackOverflow 上的一些问题即可。至少开发人员会询问您是否有服务，而不是只是在自己的代码中重复逻辑。我没有看到此类问题的任何技术解决方案，您已经提供了良好的注册表和文档，但有些开发人员更喜欢与人交谈。甚至，也许这实际上是一件好事——人机交互的价值高于交互的技术内容。或者，也许，你太好了：“不，我不会回答这个问题，你自己查一下。”
2）。缩放。有一些技术可以解决这个问题。 （免责声明，我为 IBM 工作，他们销售一些产品，因此我将引用这些内容 - 我无意暗示 IBM 是该领域唯一提供解决方案的供应商。）有一些产品，例如 this 可以配置新机器、安装软件堆栈并将其添加到集群以解决工作负载变化。然后，在 Java EE 世界中进行更细粒度的控制，应用程序服务器可以动态调整流量并调整集群。请参阅 WebSphere Virtual Enterprise
3)。监控。我在这里不“明白”你的期望。很可能这种棘手的错误将需要应用程序级别的跟踪。对于某些问题，例如查找内存泄漏和性能瓶颈，有非常好的工具，至少在 Java EE 领域是这样。
4）。我无法谈论 .Net 世界，但我想说 Java EE 应用程序服务器在跨集群顺利部署应用程序方面做得相当合理，并且在我们使用 JNI 并需要部署 DLL 的情况下，我们可以使用产品例如我提到的 Tivoli 堆栈来管理这个。
因此，总而言之，我确实认为供应商正在努力解决这些问题。我认为如果没有 SOA，您的生活不会变得更简单。想象一下同样的问题也适用于无数独立的应用程序。
I think that you are talking about different kinds of problems here.
1). Developers who don't read documentation. This is an endemic problem, not limited to SOA - just look at some questions on StackOverflow. At least the developer is asking you whether there is a service, rather then just duplicating logic in their own code. I don't see any technical solution to these kinds of problems, you've already provided good registries and documentation, but some developers prefer to talk to people. Maybe, even, this is actually a good thing - human interaction has value above the technical content of the interaction. Or maybe, you're too nice: "No, I won't answer that question, look it up."
2). Scaling. There are technologies addressing this issue. (Disclaimer I work for IBM, who sell some, so I'll reference these - I'm not intending to imply that IBM are the only vendor with solutions in this space.) There are products such as this that can provision a new machine, install a software stack and add it to a cluster to address workload changes. Then at a finer grained level of control in the Java EE world the Application Server can dynamically shape traffic and adjust clusters. See WebSphere Virtual Enterprise
3). Monitoring. I don't "get" what you expect here. In all likelyhood such tricky bugs will require application level trace. For some problems such as finding memory leaks and performance bottlenecks there are very good tools, at least in the Java EE world.
4). I can't speak to the .Net world, but I'd say that Java EE app servers do a reasonable job of deploying the apps across clusters smoothly, and in the cases where we use JNI and need DLLs deploying then we can use products such as the Tivoli stack I mention to manage this.
So, in summary, I do think that vendors are trying to address these issues. And I don't think your life would be simpler without SOA. Imagine instead the same problems applied to myriad separate, independent applications.