Web 应用的一些趋势技术

    语言不是因素, Java能做的, 已经能做到大部分的事情。 经常被人询问, 这样的应用能使用Java么。 我的回答是架构决定性能, 可什么是架构呢, 小到一个一个API的实现的技巧, 大到技术级别上的框架和整个业务的流程。不过, 架构有个定义, 是一组可以被回调(callback)的代码实现。  什么是callback呢, 请不要拘泥于他一定是一组代码, 应该理解成输入一个资源, 架构能够知道如何去处理。说远了, 以后再谈。
   今天想说是, Java  业务的各个环节, 我所倾向采取的细节技术:
   1.  前端架构方面, 我不是专家, 很想去深入研究,但是没有时间。 Ajax/Json是我们目前使用的比较的多的一些技术。 至少, 他能减少一些开发的复杂程度, 还有多个系统间为了展现内容, 不需要直接相互交互, 能够起到decouple的作用。
   2. 页面的渲染, 目前的技术特别多, xml/xlst, webmacro, servlet/jsp, jsf等等, 这些东西都比较复杂。 对于做产品, 我个人觉得他们是可取的, 当时, 对于一些高速发展的电子商务类网站, 比如taobao.com 这样, 很多的动态page, 版面设计人员会在模版上作大量的修改。 如果一堆的jsp代码放在里面, 简直会要了他们的命, 太过于技术化了。 经过很多权衡, 我们选择使用了velocity.
  3. web框架方面, 我没有什么好说的, 我们公司有自己的框架, 虽然用起来复杂了点了, 当时还算是不错。 代码也写的非常严谨, 可扩展方面也作的相当不错。等有时间介绍吧。
  4. 持久层, 也许大家都很关心。 在业务压力比较多的网站, 我们是绝对不会采用hibernate,这块的东西一定要能掌握在手里。 说实话hibernate 跟 ejb真的没有区别, 黑黑的盒子, 出了问题很难查找。在有DBA和开发写作的团队, ibatis是值得使用的工具。 这世界上, 如果真的想hibernate那么理想的工具, 也就是说, 今后的世界不需要有程序员这样的职业了, 当然我不是歧视hibernate, 在小型应用的领域, hibernate是一个伟大的发明。
  5. 关于超大规模的表。 如果一个数据库表, 记录到了5000W记录以后, 就是使用小机作数据库服务器, 性能也会越越差的, 所以, 把这个表按用户拆分开来是最适合的选择。
  6. 关于站内的搜索, lucene是你的选择, 甚至你可以选择nutch. 不是每个公司都能力开发搜索引擎的。 选择这个并不会带来新性能问题。
  7. 大规模的群集? 群集, 架构师的责任是做到无状态群集服务, 如果一个50个以上节点组成的群集, 那么光是状态维护就会吧整个系统的性能吃的差不多。 记住,避免任何群集的状态性。 关于如何保存服务器的状态有很多技术解决, 比如使用cookie based session, 把所有的会话都序列话到客户机。 不过, 对于很多应用的环境, 这个想法有点天真。 会导致客户端有太多的COOKIE。 另外的最做法是把会话保存到数据库里去。 或者把会话保存一个独立的数据服务的环境这中。
  8. 如何缓冲高度频繁访问数据库的数据。 目前有很多CACHE产品。 比如jboss cache, oscache, 等等很多的选择余地。 不过, 话说回来, 我尽管是个想整个系统是Pure Java, 不过, 有时候, 还是要低头的。 请想想一下, 如果的你JAVA作的CACHE系统里有1000W个对象,我们作过测试, 开了1G的内存给Java, 没有别的内存参数的情况下, 1000W对象的full gc 的时间可能会有大于10秒。 那就意味着可能导致系统会被突然被卡住。 当然Java有些内存调解的参数可以缓解这一情况, 当是, 总是不爽的。 Web 应用的体验会大打折扣。 经过很多对比以后, 我们发现 Memcached 是一个C写的cache系统是一个非常不错的选择。 目前他的Java client也写的非常不错。 已经用上nio了。
  本来想写很多, 突然没有话了。 罪过。
  还有一些技术,比如hadoop.  nutch, mina 都是很不错的东西。 值得去思考。



 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章