最近刚到一家新公司，开始时候做了一点移动应用和LBS相关服务器端开发。该项目架构是用Spring+mybatis+mysql，实现与手机端各种交互对应服务器端的Servlet去接收和返回response。 我个人认为这样做最大隐患就是到后期Servlet会越来越庞大，而且对外的接口太多，安全性也无法保证。如果让我设计，是不是可以只提供一个对外接口，所有与手机交互只用一个Servlet，只需定义好应用层协议即可？
我个人认为这样第一是好维护好管理；第二是方便加入安全策略；第三点扩展性强。请各位发表下建议！谢谢！
相对于维护多个Servlet，是不是维护一个Servlet更好？就好像我们如果做过监控软件，原来要几台或十几台监控屏幕显示的监控现象在改进后变成一台显示器就可以显示了，是不是更易维护？
扩展性强不敢苟同，这实际是facade模式和command模式的区别，面向对象方法让我们细分，每个业务应用一个对象servlet去处理，或者说是REST方式比较好。
将所有应用打包在协议里，这是过去很多人的思路，是一种归纳法，归纳法一般很难得到真理，灵活性不够，最后协议中充满冗余的各种字段，因为对于每个小应用，用比较复杂协议去协调很重。
至于“Servlet会越来越庞大，而且对外的接口太多，安全性也无法保证。”接口很多是正常，分析细化的结果，但不能推算出安全性没有保障，因为现在软件组件化技术已经做到运行时组装，可以为每个servlet增加安全插件比如servlet filter，或者Acegi这样专门安全组件，甚至Web容器本身都提供了安全机制。无论什么样监控，都是对事件的拦截，现在有基于事件的架构EDA，可以让我们很好监控事件。
过去我们对安全的朴素思路是设定一个总出入口，这样安全容易把握(现实中会诞生统一监管的社会制度)，这是一种静态思路，忘记了软件是动态运行特点(不只是软件是动态，社会也是动态，是失控的)。
以上只是个人建议。 [该贴被banq于2011-08-20 09:25修改过]
谢谢banq老师回复。很有启发！我现在还是以静态思路去思考问题，看来过时了。我在想是不是用统一对外接口也会增加服务器端拆分字节数组的负担呢？我的这种归纳法的思路可能做C++比较好接受，因为客户端就是C++的同事。但这种方式让做Java客户端的很难接受，他们更倾向多Servlet处理方式。 请问banq老师，如果客户端是非浏览器的客户端，也支持Servlet filter或者Acegi等这些安全组件吗？还是需要自己实现？
与客户端无关，这些都是服务器端组件，比如新浪微博的OAuth也是一样的，建议你去参考一下：http://open.weibo.com/wiki/index.php/OAuth
访问新浪所有API之前，都需要经过OAuth认证。
与客户端无关，这些都是服务器端组件 真实孤陋寡闻了！呵呵。 banq老师介绍的OAuth最大应用场景我理解应该是这样： 用户A分别在网站A和网站B上注册，并获得网站A的Service1服务和网站B的Service2服务。用户A想要在网站A上使用Service2服务怎么办？OAuth授权机制很好解决这个问题。还有网站B需要得到用户A在网站A上一些信息，需要用户A授权，也是一种场景。 这种机制确实很不错！不知道自己对OAuth授权机制有没有理解错？ 还有就是对应用层数据用协议封装主要还考虑到我们会推联机游戏，就是会用到HTTP长连接和WebService方式。 假如我们用WebService方式，那么我们直接通过统一协议方式生成WSDL即可，如果是很多Servlet方式，方便开发、维护吗？是不是WebService接口和Servlet是一对一关系呢？
这都是服务器端事情，SSO单点登录，分布式系统对于客户端来说如同一台服务器，任何一个服务器登录后的权限都是一样，如果做不到这点，能叫权限和业务分离吗？具体还是多参考参考相关文章，比如jivejdon源码看看等等，时间长了会明白的。
