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 都是很不錯的東西。 值得去思考。