J2EE传统部署架构在微信内置浏览器下的问题

J2EE传统部署架构在微信内置浏览器下的问题 

最近我们这边有个项目碰到了很奇怪的一个问题，折腾了蛮久，最后终于整出了点头绪。
先说下我们这边的架构部署，系统框架是传统的j2ee框架部署，应用层面是freemarker+springmvc+hibernate+ehcache，ehcache没有做集群共享同步，每台APP应用上面是基于sessionId+random做key的方式以map形式存储,部署层面从前到后是F5(简单会话保持策略)->IHS插件分发-APP应用集群，这套系统上线蛮久了，框架一直都没发现有什么问题，后来因为业务渠道的拓展，系统需要支持微信渠道，当时考虑到工作量和复用的情况，决定在微信已有菜单页面上放一个链接，指向我们移动端的后台服务，移动端后台服务是基于jquery-mobile+freemarker+springmvc新搭建的一套web系统，后台service是复用以前系统的，链接上面当时配置的是F5的公网IP跳转，一直使用下来也没出什么问题，后面业务有需求方面的变更，IP访问需要调整为域名访问，这就要求微信的访问链接调整为域名服务，然后问题就出现了。

问题现象1：
按照上述架构,各种安卓类手机通过微信内置浏览器公网ip访问没有问题,用域名访问会出现各种随机问题,有时候能正常提交请求到后台,有时候会表现超时报错,还有时候跟踪发现会两次提交，改造过各种提交方式ajax,form表单,xmlhttprequest等均出现上述问题，感觉应该和提交方式无关，且仅在微信内置浏览器上面表现问题。另经过大量测试发现：清理微信数据以后第一次访问做业务肯定会有效，后面第N次慢慢的肯定会出现随机问题。
问题现象2：
由于是改域名访问以后才出现问题，改造成ajax的json方式提交有超时无法提交现象，换成jsonp跨域方式,会存在两次提交的现象，不过在后台获取sessionid进行ehcache操作的时候发现经常会取不到需要的数据,看了后台日志分析应该是，sessionid丢失了。根据这个现象再推论一下，应该是IHS上面请求没有正常分发,保持对应的session会话，大多浏览器都会根据cookies存储sessionid,IHS分发也是基于cookies里面存放的colneId。这个问题应该说明是cookies出现了问题，后面跟代码下来确实也发现jsonp提交的方式，cookies是确实无法带到后面去的，IHS就随机分发继而导致会话丢失。

根据这个问题，最后个人总结了下得出以下几点：

1，微信内置浏览器有cookies和普通浏览器的cookies处理应该还是很有区别的,微信内置浏览器按照微信团队的说法就是标准的 WebView（Android下）,跟普通 webAPP 本质上是一样的。当 WebView 因为内存不足、进程被杀、微信主动杀掉等原因被干掉以后,所有跟浏览器相关的信息全部灰飞烟灭,cookie、LocalStorage、SessionStorage、WebSQL 全部消失。而且微信打开的网页,是无法持久存贮 cookies 的。因此以后要基于微信内置浏览器处理cookies操作的相关系统都要小心了。

2，cookies具有不可跨域名性,微信内置浏览器通过ip和域名访问的区别，传统的普通浏览器中cookies都具有不可跨域名性,A域名下的cookies不允许提交到B域名下。目前看来微信内置浏览器虽然不算真正的浏览器，但是肯定做了跨域的限制。

3，微信浏览器和IHS结合会出现奇怪的问题还是基于微信内置浏览器的cookies问题，实际上IHS用的就是cookie的技术，was server会在http的session的cookie中设置一个colneID,以后客户端就有这个cookie了，也有colneID了，plugin也就知道他以前是请求的哪个server了，再次请求的时候会转发到具有这个colneID的server，IHS根据cookies保存的colneId找到对应的app进行会话保持，如果没有则随机访问。

4，微信中只要用域名访问就存在超时无法提交或者两次提交问题，IP则没有此限制，域名下参数少的话可以采用$.get的方式提交，如果采用其它的方式提交记得要换成IP方式，不然会有各种问题。将来如果有相应的app的系统开发，或者类似的cookies无法传递的问题，沿用这样的j2ee架构也一定要小心了。