研发背景
spring mvcspring framework技术实现移动端后台架构。
根据技术特点和我的一些架构封装想法，给自己这次研发规定了几个指标：
l
l数据交互灵活友好；
l并发能力出众；
l开发习惯规范友好。
设计验证过程
1、
2、数据交互灵活友好
Unieap DataCenterspring json view+sojo+argumentResolver+exceptionResolver。
3、并发能力出众
spring mvcspring mvcspring mvc Controller分发机制，最大范围发挥其处理吞吐能力。
4、开发习惯规范友好
Spring mvc这种灵活的风格上手确实比较头痛，但是上手后我就喜欢上了，框架就应该这样无拘无束，开发人员就应该只关注业务，对于什么连接、认证、数据获取、数据回传、异常处理等等的都不关心，并且能按照自己已有习惯开发自己喜欢的代码。所以我不想改变什么，我只想让移动端开发完全融合到这种风格中。
除了上述这些指标外，其实移动端还有一些硬性的指标：
1、模拟长连接
2、安全
3、系统日志及异常处理
hibernate AOP实现系统请求及数据日志。
实现
处理流程描述：
实现目录结构
目录下。
——————既然大家都跑题关注扩展，我也华丽分割一下—————————-
扩展演进：
1、数据库持久方案
2、
会话内容放在内存中是单点应用特点，如果对于集群环境能统一管理并且还在内存中，整体效果肯定最理想。通过会话的独立管理，也使得业务力度级请求分发变的相当简单，但是全局缓存存在单点故障问题，分布式缓存有又存在一定的资源利用率问题，并且分布式缓存产品在当前市场中价格都较贵，所以这部分我设想了一个方案供大家参考。
环境介绍：
1、
2、
3、应用节点独立管理，应用节点间不通信。
4、
5、应用节点与分发节点和全局缓存节点双网卡全连通。
处理过程：
1、
2、
3、这样反复执行，热点会话信息会存储在‘全局缓存节点’上以提高命中率，并且也是一个副本保证不会出现单点问题。
极端情况分析：
1、程序访问过程中，一个应用节点宕机
由于登陆后会话信息会复制到‘全局分布缓存节点’，所以即使这样，新的请求还会由其他正常节点响应，不过也会有一些极端会话信息，不在全局缓存的热点缓存范围内，这些信息应该都是不频繁访问的登陆信息，针对他们就会跳转到登陆页面，这种情况应该是可接受的。
2、分发节点宕机
如果分发设备宕机，对于系统来说是一个比较严重的问题，相关请求将不能正常访问。这块可以考虑分发集群和分发分层，，不在本次考虑范围内。
3、全局缓存节点宕机
全局缓存节点缓存策略：
——————————2015年5月6日———————————
针对sojo不能做筛选转换调整原代码：ComplexBean2MapConversion.doConvert添加对注解支持。
——————————2015年5月7日———————————
整体设计和开发基本上完成了，不过开发完后也发现了一些不足之处：
1、由于BO采用了hibernate orm ，所以对象中冗余字段较多，虽然在转换时可以通过注解将不必要的字段过滤，但是毕竟带来了不少的控制成本，且这种过滤方式是全局的不能针对业务定制。
这部分我给开发人员的建议是，如果ORM内容与前台获取内容差别不大，就直接传给前台，前台根据需要筛选。如果差距较大，就在移动服务Controller层做一下过滤转换成新的BTO再传给前台。
2、技术上request和response转换采用了不同的技术sojo和jackson，整体不是太好，并且规则定义部分也无法重用，如果要是可以尽量都用jackson实现。
每一发奋努力的背后，必有加倍的赏赐。
