5、对外网用户消息产生和发送的过程和逻辑实现进行分析：我们发现，为了 满足应用系统外网访问的需要，我们对消息系统配置信息中服务地址的 ServerName进行了伪处理，即在运行时，根据用户浏览器的请求头来判断用户使 用的是哪一个WEB服务器地址，并将此地址动态的代替消息配置中的各 ServerName信息，从而保证各使用用户只能够访问其指定的WEB服务器，从而避 免因WEB服务器的不匹配而影响其访问速度、处理效率等故障的发生。此方式已 在我部门多套同时服务于内外网络的系统中得到可靠的验证。

那么，会不会因为ServerName在动态解释过程中，因多并发情况下，因后访 问者将前访问者的ServerName改写而导致错误的解释，即将不同网络用户的消息 地址进行张冠李戴而导致消息无法正常发送呢？

分析消息中心各部分WEBService生成和使用机制：因系统的并发性要求较高 ，在高峰期其在线用户可达3000人，并发用户在300以上，且系统稳定性要求极 高。为提高系统的性能和稳定性，在系统启动时即将消息中心各部的WEBService 连接进行创建和缓存，以提升消息中心资源利用率，并提升其访问性能。

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

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

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

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

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

问题解决

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

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

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

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

补充与心得

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

凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢!