在查看 SOA(面向服务的架构)时,主要问题似乎是在多个主机之间分配服务负载,然后管理这些主机(使主机脱机或添加新主机)
当一个服务与另一个服务对话时,它不需要知道任何主机信息(在应用程序级别)。相反,SOA 环境应该能够根据主机当前负载特征将服务请求路由到特定主机(因此它必须知道服务正在运行的所有热点及其相对负载)。
是否有任何现有的服务开放协议来报告它们的存在和负载到 SOA 环境。
在查看 SOA(面向服务的架构)时,主要问题似乎是在多个主机之间分配服务负载,然后管理这些主机(使主机脱机或添加新主机)
当一个服务与另一个服务对话时,它不需要知道任何主机信息(在应用程序级别)。相反,SOA 环境应该能够根据主机当前负载特征将服务请求路由到特定主机(因此它必须知道服务正在运行的所有热点及其相对负载)。
是否有任何现有的服务开放协议来报告它们的存在和负载到 SOA 环境。
SOA 是一组高级软件架构指南。它不是技术标准或建议,与技术实现细节(如负载平衡)无关。
负载均衡是基于寻址的,它依赖于服务访问技术。以“SOA 方式”构建的系统可能使用不同的服务访问技术,如 SOAP(通过 HTTP、JMS 等)、REST、通过 JMS 的异步 XML 消息等。
使用 SOAP,服务消费者可以查找 UDDI 注册中心来定位服务提供者。一些最新的 UDDI 注册软件提供简单的(例如循环)负载平衡。另一个 SOAP 想法是使用 WS-Addressing,但它并不是真正用于负载平衡。
我认为目前负载平衡的最佳位置是底层网络传输层。使用 HTTP 传输,您可以选择硬件或软件(例如 Apache HTTPD 模块)负载平衡器,这些负载平衡器可以根据响应时间和超时来调整分布。通过 JMS 传输,最流行的 JMS 服务器提供了某种形式的负载平衡。其他协议(如 CORBA 或 Rendezvous)通常需要自定义解决方案。
您还可以使用 ESB 软件,例如 Oracle Service Bus 或 TIBCO AMX Service Bus。使用 ESB,您可以轻松地为您的服务实例创建负载平衡代理。可以通过一些逻辑来增强代理,例如查找数据库表以获取指导。
如您所见,对于服务负载平衡,没有一种万能的解决方案。最佳解决方案将基于实际的实施架构和供应商的建议。
在阅读了很多之后,我真正想要的概念是Enterprise Service Bus ESP。
尽管它没有明确定义明确的协议,但它定义了一种架构风格,可以解决我上面提到的问题。