工作那些事儿（9）- 架构

    要开工了，这时整个系统的大概架构我已经想得七七八八了，我打算做一个重前端的single page web app，区别于传统动态网页的方式（服务器端生成网页），整个page的生成将在浏览器完成；而后台则负责数据集成和个性化订阅的持久化，前端和后台通过json格式数据进行沟通。

    这个想法，我跟老H说了一通，他最后问我，什么是JSON，显然，他还没ready，他还活着上世纪。不过，那时候是两年前，那时候，互联网上这样的做法，也不是非常普遍，我毫不谦虚地讲，这设计是足够前沿的。我用这样的架构设计的另一个出发点是，希望减低前后端耦合，并实现后台数据集成的集群化，简单地讲就是由前端（浏览器端）决定向后台哪一台服务器来发起数据请求，那么后台就变得可扩展的集群。而页面内容又是由浏览器来生成，相当于减轻了部分服务器的计算压力。

    而这种前端做负载均衡的做法，首先就遇到跨越的问题，于是找到了JSONP的方法，虽然有点风险，但在企业内部相当于没风险了。又跟老H说了一通，他说没明白什么是JSONP，晕，百度啊老大。

    其实回头看一下，虽然这样的架构设计很有意思，但其实在企业内部环境，基本上是起不到应有的效果。

    （1） 前后台彻底分离并通过json通信，实质是最大限度减低网络流量的一种做法，因为不用因为页面跳转而重新下载一堆html和各种资源了，页面生成后就是数据的交互，只有数据会被传输，理论上，这样是会比传统动态网页来得快。但实际上，企业内网下，网速压根不是道关。

    （2）由于前端重了，对浏览器要求就高了。企业里，基本是IE的天下，chrome， ff这些只有我们开发部屌丝才会用的，这实在太考验IE了。幸好的是，咱H总，高瞻远瞩，一道令下，全部升级到IE8，那个豁然开朗啊，那个海阔天空啊。

    （3）企业级的并发访问，真没想象中高，而且企业级就喜欢买强力的服务器，不喜欢分布式的多台PC server的模式，因为他们总觉得买一台的维护成本要比买多台的成本要低很多……当然会有一些例外，后话。企业级的并发去不到互联网的一个零头，像EIP这种使用面已经属于很高的应用系统，高峰的并发也就一两百，实质一般j2ee server都是可以承受的。这样集群的效果，就不明显了。当然，后来随着推广，集群的效果总算出来了，只是来得晚一点罢。

    说到这来，我再说一次，我真不是前端工程师，更不是美工撒~