基于WEB服务器导致消息中心各组件之间无法正常工作的问题分析与解决

核心提示： 当存在多网络用户访问时，可能因消息中心存贮的WEBService连接并不是其用户所使用的那个网络的WEBService服务地址，基于WEB服务器导致消息中心各组件之间无法正常工作的问题分析与解决(4)，此时，消息肯定是无法送达至此用户所需要的目标的，及时开发与之配套的检测和使用工具，是一件必不可

当存在多网络用户访问时，可能因消息中心存贮的WEBService连接并不是其用户所使用的那个网络的WEBService服务地址，此时，消息肯定是无法送达至此用户所需要的目标的。因此，报”connect time out”错误就成必然的了。

既然已找到问题的可能原因，我们立即进行着手分析和解决：根据部署要求，我们对对消息服务连接服务进行了升级，即将服务请求进行分类处理和实现，并在消息配置中对所使用的部署方式、代理实现后，交由测试人员进行部署和测试。

测试结果：令人失望的是，此问题依然存在！在通过外网WEB服务器访问的系统，其消息还是无法发送至消息总线。由此得知，此种分析方向是错误的！

至此，好像已经走入了死区,能想到的方式都已经想到了，但问题到底出在哪呢？

问题解决

在一次与同事聊天的过程中，忽然想到一个问题，那就是：我们的消息的产生和应用都是由应用系统和与之集成在一起的消息客户端自动产生和处理的，此过程中完全不受人工干预和影响。而应用系统是部署在应用服务器中，WEB服务器仅是用来处理用户的HTTP请求à将此请求转发至对应的应用服务器后à将应用服务器的响应返回给用户。

在此过程中WEB服务器并未对用户业的http请求进行过任何业务上的处理！那么，问题会不会出在WEB服务器端呢？检查一下消息中心的配置不管是使用ServerName还是写死IP和域名，我们的消息中心配置的地址都是指向WEB服务器。而在应用系统发现消息时，其所在位置是应用服务器。而应用服务器是无法直接访问部署于外网IP中的WEB服务器的，当然，消息无法发送至目标就成为必然了。

图片看不清楚？请点击这里查看原图（大图）。

既然已经找到问题，那就动手，将消息中心的配置信息指向应用服务器后，重启应用系统后测试，问题果然解决！

通过应用服务器进行后台自动处理的，进行HTTP或WEBService活动，其目标必需是它能够访问的有效地址！这个问题在以前也曾经碰到过，只是由于时间隔得太久，且这些场景应用出现太少，而导致再次发生。

补充与心得

1、　　　 基于应用系统或后台自动触发的一些业务逻辑，如其中存在着系统间相互访问或远程调用等，必需以应用系统自身为根，进行连接测试；通过外层包装或其它代理，进行访问时，必需先剥离过外层包装或其它代理后，再进行连接测试，并以测试结果，作为决策的依据！此举适用于各类系统的架构设计和逻辑实现过程中。

2、　　　 基于中间件产品应用，及时开发与之配套的检测和使用工具，是一件必不可少的工作，此举将为后期的实施和问题分析节省大量的工作量。