簡介,網站介紹,開發計畫,第一階段,第二階段,第三階段,產品特色,運營經驗,綜合性內容建設,成功的關鍵,目前暴露的問題,相關新聞,網站被封,相關新聞補充,改名ItEye,
簡介
JavaEye(現更名為ITEye)是在2003年9月創辦的，緣起是創始人范凱自己在學習和研究java的開源框架卻發現沒有一個討論的地方，於是自己就辦一個。如今，已經是國內專業性內容社區網站的佼佼者。
javaeye技術網站
javaeye技術網站經過幾年的持續不斷的開發和完善，JavaEye網站已經發展成為了一個內容齊全，功能豐富的中文IT技術門戶和社區網站。但是現在的JavaEye網站距離一個理想的智慧型化IT技術社區還有很大的差距，需要我們長期不懈的改進和完善。
JavaEye是一個以討論Java技術和Hibernate技術開始的技術論壇，已經成為一個涵蓋整個軟體開發領域的綜合性網站，2005年被選為中國十佳技術網站之一，受到廣大軟體開發者的好評。
但是，2010年11月22日，國內知名Java編程網站JavaEye被關閉，訪問網站被提示：“網站因有違規內容而被關閉，具體事宜請聯繫您的接入商”。JavaEye網站應該是在下午時間（1點10分左右）被關閉。截止當日晚間尚不知網站具體違規內容。網站域名沒有跳轉直接顯示該內容，有部分網友質疑是被黑了。
創始人范凱在微博中稱：JavaEye被封是因為寫的動態防火牆代碼太智慧型，把電信負責內容監控的爬蟲給封了，導致被封。把監控爬蟲加入白名單了，爭取下午恢復網站訪問。並非由於是網站含有違法內容導致。
據此前訊息，JavaEye已被CSDN收購，不過CSDN 和JavaEye 均未對此事發表任何說明，收購的細節也無從得知。
網站介紹
CSDN(創新樂知)是一家服務於中國IT專業人士學習與成長需要的領先綜合社區服務平台。CSDN以旗下全球知名中文IT技術社區為基礎，通過網站·雜誌、教育·培訓、人才·交易三大業務群形成從知識傳播、技術教育到職業成長的完整知識傳播與服務鏈。 JavaEye是一個軟體開發人員的深度交流社區。JavaEye創建於2003年9月9日，JavaEye一直致力於為中國的軟體開發人員提供一個良好的有深度交流的社區。 JavaEye是一個以討論Java技術和Hibernate技術開始的技術論壇，現在已經成為一個涵蓋整個軟體開發領域的綜合性網站，2005年被選為中國十佳技術網站之一，受到廣大軟體開發者的好評。
javaeye技術網站
javaeye技術網站開發計畫
JavaEye網站2010年的開發計畫將分為三個階段來進行：
第一階段
全面完善網站各個頻道的功能、根據全站內容分類推出個性化的定製內容，強化個人訊息輸出功能，改進網站開放API等等。
javaeye技術
javaeye技術1、根據全站內容分類推出垂直頻道，以及根據用戶興趣，推出個性化定製門戶
JavaEye從2009年開始就一直悄悄的不停改版和底層內容的打通，通過新聞頻道改版，問答頻道改進，專欄頻道改版，部落格頻道改版，圈子頻道改版，以及新推出的文摘頻道，進行全站所有頻道和所有內容的統一分類，這個工作現在已經完成了。大家可以注意到頻道左側的兩級內容分類導航，現在無論是新聞文章，論壇帖子，部落格還是提問，抑或圈子討論和專欄文章都被歸類到某一個分類下面了。JavaEye網站的全站內容一級分類有20大類，和論壇的版面對應，內容二級分類有120小類，和論壇的tag也是對應的，因此根據任何一個大類或者小類，都可以立刻抓取出來該分類下面所屬的任何網站內容，組裝成為一個特定分類的垂直入口網站。
這意味著，JavaEye可以立刻切分出來一百多個小網站，例如那些對Android感興趣的開發人員，以後可以直接通過域名進入這個更加細分的垂直社區，JavaEye全站所有關於Android的內容可以盡在掌握了。
更進一步，有了詳細的內容分類，我們可以給用戶提供定製化功能，讓用戶挑選自己感興趣的內容組裝成個人門戶，例如用戶關心Ruby，Python和iPhone方面的內容，那么用戶挑選Ruby和Python一級分類和iPhone二級分類，然後就可以通過我的套用進入個性化門戶，其他所有無關內容全部過濾，只訂閱和瀏覽自己感興趣的內容，是不是很酷。
2、改進網站的全文檢索，提供動態的內容分類和提取，實現任意熱門內容的垂直門戶
全站內容分類還不夠靈活，但是有了內容分類作為訓練材料，我們可以更好的改進全文檢索，從全站所有內容當中迅速提取出來熱門內容，組裝一個垂直入口網站出來。
例如最近雲計算很熱門，但是雲計算涉及很多跨分類的技術，可能涉及網際網路，web前端，移動編程，企業套用等很多領域，用戶發表文章也往往根據自己用到的技術門類去發表，因此JavaEye沒有辦法專門為了雲計算開分類或者版面。但是有了更加強大的全文檢索，結合全站內容分類，我們可以瞬間從全站內容當中提取所有和雲計算相關的內容，組裝一個的垂直社區出來，是不是很爽？有了這種神器，BD廠商客戶將變得易如反掌！
javaeye聊天客戶端
javaeye聊天客戶端3、PDF電子書下載頻道
早在2008年我們實現了部落格電子書功能的時候，就構想了要做電子書下載頻道，如今全站內容分類全部做好，而且新聞頻道，部落格，專欄頻道，文摘頻道都已經全部支持製作PDF。接下來我們要做的就是提供各種頻道分類，各種內容分類的PDF電子書下載頻道了。這個下載頻道可是絕對正版噢！另外我們也將有可能加大專欄內容的建設，為大家提供更多更好的技術專欄PDF下載。
4、網站內容的相關文章最佳化
利用全文檢索技術，JavaEye所有內容都有相關內容的推薦，無論新聞、論壇還是部落格都有相關文章，我們將加強相關文章的推薦，更合理的提取和最佳化相關文章，提升頁面的SEO效果。這將帶來更多的SEO流量，以及更高的用戶點擊率。
5、招聘頻道建設好企業會員服務
招聘頻道在2009年也進行了徹底的改版，如今我們已經實現了對招聘信息的分類廣告投放功能，例如一個Android程式設計師的招聘信息，我們可以精確的投放到全站任何出現Android分類的文章，比方說Android新聞，Android部落格，Android討論等等，當然這也得益於全站內容分類的前期工作。在有了這些強大功能的基礎之上，我們會專門為企業會員開發和提供更多更好的服務，爭取做好專業技術領域的線上人才服務。
6、改進和最佳化個人套用的各項服務
目前JavaEye網站所有內容都是對匿名用戶公開的，所以註冊會員訪問比例遠低於匿名會員訪問比例。個人套用是2009年初推出的針對註冊登錄用戶的個性化服務，但是一直沒有正式發布和推廣，個人套用的各項功能和界面也一直沒有進行改進，在解決上述問題之後，我們將重點建設和推廣個人套用，力爭將網站的註冊會員訪問比例提高5-10%。
此外，還計畫改進JavaEye OpenAPI，重寫和升級Firefox外掛程式，推廣Android客戶端，力爭將個人套用功能激活，讓更多會員即使不上JavaEye，仍然可以隨時隨地訪問JavaEye的數據。
第一階段計畫用2－3個月的時間來完成。
第二階段：使用MongoDB詳細記錄網站的每個訪問請求，研發網站用戶行為跟蹤和分析系統
專業網站的用戶規模永遠不可能超越大眾網站，但是專業網站的價值在於精準定位的高端的用戶群體。儘管行業廠商很多還習慣於粗放型的首頁Banner廣告，但是更多廠商已經把目光轉移到精準的用戶行銷上來了。廠商更加關心的是自身產品的實際到達率是什麼，究竟有哪些用戶在關注他們的產品，對他們的產品的評價是什麼，哪些用戶可能成為潛在的客戶，這些用戶都是什麼行業，什麼收入水平等等。
所有的這些精準用戶行銷需求現在沒有一個網站可以滿足，而這正是JavaEye想做到的功能。JavaEye通過內容分類，通過用戶資料、用戶發帖和用戶定製內容，還加上用戶訪問JavaEye的所有軌跡，點擊了哪些帖子，經常訪問哪種類型的內容，關注了哪些用戶等等信息，有望對用戶身份進行精準的識別。分析出來用戶從事什麼行業，職位高低，收入水平，技術水準，對哪些領域的產品和技術感興趣等等。
javaeye技術網站
javaeye技術網站有了精準的用戶識別，我們可以為廠商提供ROI最好的媒體服務，甚至是可以及時得到用戶的反饋，例如SOA廠商的新產品，如果亂打廣告，可能很多人罵，但是如果把這些產品信息精準的推薦給那些真正正在從事SOA領域開發的顧問和專家，那么廣告本身就是有價值的，他們會感興趣的信息。並且還可以立刻得到用戶對產品的反饋和評價，而這些反饋和評價都是來自真實的行業專家，對廠商的價值不言而喻。精準的行銷對網站用戶也會帶來更好的用戶體驗，因為帶干擾性的通欄廣告更少了，而那些精準的產品推薦剛好是用戶正在關注或者正希望去了解的信息。
但是要研發這樣一個用戶行為跟蹤和分析系統，在技術上有很大的挑戰性，一方面我們需要新的NoSQLDB技術引入，例如用MongoDB存儲和分析海量的用戶訪問記錄；另一方面需要用全文檢索對海量信息進行分析和提取，此外還需要設計良好的公式評價系統和降低噪音的功能。不過由於JavaEye已經對全站內容進行了統一的分類，因此在用戶識別和內容識別方面難度會降低很多。如果說有一個網站能夠率先做到這一點的話，肯定非JavaEye莫屬了。
第二階段
預計需要2-3個月時間來開發和實現。
第三階段
基於真實用戶關係的SNS
從2007年就開始關注SNS，08年對SNS寫了很多文章下了很多論斷，現在看來都一一驗證了。一個以內容為核心的社區，特別是專業性質的行業社區是不適合直接用SNS的，這也是為什麼JavaEye遲遲不做SNS的原因。JavaEye的研發重點還是應該放在加強內容核心這一點上，因此在過去的兩年當中，我們的研發全部放在了全站內容分類上。但在做好和加強內容核心的基礎之上，SNS的需求仍然揮之不去，因此如果我們能夠順利實現前面兩個階段的工作，將嘗試開發和運營SNS。
JavaEye的SNS需求針對的用戶群體是什麼？
1、一些軟體公司的整個研發部門都上JavaEye，同事之間的交流需求
2、一些通過JavaEye認識，見過面的朋友，他們之間的線上交流
3、同一個學校同學們畢業以後在JavaEye上的線上交流
交流的方式應該不是發帖，也不應該是social game，具體什麼樣的交流方式我還沒有想得很清楚，但是感覺上必須符合如下的條件：
1、必須是實名註冊的用戶，才開放SNS。實名註冊，和真實的用戶關係（生活當中認識的人）很重要。如果不滿足這兩個條件，就根本沒有必要用SNS。JavaEye現有的服務都可以滿足了。
2、不必提供內容交流功能，現在的JavaEye在內容交流方面已經做到的極致；但也不能做social game，否則JavaEye會被軟體公司封殺。應該是一些輕量級的互動性展示和評價：例如用戶的個人履歷（非簡歷），生活近況，對同事同學的評價，工作上的互相推薦和交流。應該有點類似linkedin，但不能那么死板。
總之還需要大家多提建議，集思廣益。如果能夠做一個很成功的SNS出來的話，對JavaEye本身和用戶都有很多益處。例如對網站來說，用戶規模更大，用戶活躍度更高，基於用戶識別的精準的行銷和人才服務都將更加準確，獵頭服務做起來就很容易了。而對於用戶來說，可以加強和同事，同學，朋友之間的技術和生活交流。
第三階段希望下半年開始摸索著去嘗試，在年底能夠小有成績。展望2010年，JavaEye要做的事情還是很多的，希望年終可以按計畫順利實現目標，完成計畫就是勝利。
產品特色
一、滿足極高讀寫性能需求的Key-Value資料庫：Redis，Tokyo Cabinet， Flare
高性能Key-Value資料庫的主要特點就是具有極高的並發讀寫性能，Redis，Tokyo Cabinet， Flare，這3個Key-Value DB都是用C編寫的，他們的性能都相當出色，但出了出色的性能，他們還有自己獨特的功能：
1、Redis
Redis是一個很新的項目，剛剛發布了1.0版本。Redis本質上是一個Key-Value類型的記憶體資料庫，很像memcached，整個資料庫統統載入在記憶體當中進行操作，定期通過異步操作把資料庫數據flush到硬碟上進行保存。因為是純記憶體操作，Redis的性能非常出色，每秒可以處理超過10萬次讀寫操作，是我知道的性能最快的Key-Value DB。
Redis的出色之處不僅僅是性能，Redis最大的魅力是支持保存List鍊表和Set集合的數據結構，而且還支持對List進行各種操作，例如從List兩端push和pop數據，取List區間，排序等等，對Set支持各種集合的並集交集操作，此外單個value的最大限制是1GB，不像memcached只能保存1MB的數據，因此Redis可以用來實現很多有用的功能，比方說用他的List來做FIFO雙向鍊表，實現一個輕量級的高性能訊息佇列服務，用他的Set可以做高性能的tag系統等等。另外Redis也可以對存入的Key-Value設定expire時間，因此也可以被當作一個功能加強版的memcached來用。
Redis的主要缺點是資料庫容量受到物理記憶體的限制，不能用作海量數據的高性能讀寫，並且它沒有原生的可擴展機制，不具有scale（可擴展）能力，要依賴客戶端來實現分散式讀寫，因此Redis適合的場景主要局限在較小數據量的高性能操作和運算上。目前使用Redis的網站有github，Engine Yard。
2、Tokyo Cabinet和Tokoy Tyrant
TC除了支持Key-Value存儲之外，還支持保存Hashtable數據類型，因此很像一個簡單的資料庫表，並且還支持基於column的條件查詢，分頁查詢和排序功能，基本上相當於支持單表的基礎查詢功能了，所以可以簡單的替代關係資料庫的很多操作，這也是TC受到大家歡迎的主要原因之一，有一個Ruby的項目miyazakiresistance將TT的hashtable的操作封裝成和ActiveRecord一樣的操作，用起來非常爽。
TC/TT在mixi的實際套用當中，存儲了2000萬條以上的數據，同時支撐了上萬個並發連線，是一個久經考驗的項目。TC在保證了極高的並發讀寫性能的同時，具有可靠的數據持久化機制，同時還支持類似關係資料庫表結構的hashtable以及簡單的條件，分頁和排序操作，是一個很棒的NoSQL資料庫。
TC的主要缺點是在數據量達到上億級別以後，並發寫數據性能會大幅度下降，NoSQL: If Only It Was That Easy提到，他們發現在TC裡面插入1.6億條2-20KB數據的時候，寫入性能開始急劇下降。看來是當數據量上億條的時候，TC性能開始大幅度下降，從TC作者自己提供的mixi數據來看，至少上千萬條數據量的時候還沒有遇到這么明顯的寫入性能瓶頸。這個是Tim Yang做的一個Memcached，Redis和Tokyo Tyrant的簡單的性能評測，僅供參考
3. Flare
TC是日本第一大SNS網站mixi開發的，而Flare是日本第二大SNS網站開發的，有意思吧。Flare簡單的說就是給TC添加了scale功能。他替換掉了TT部分，自己另外給TC寫了網路伺服器，Flare的主要特點就是支持scale能力，他在網路服務端之前添加了一個node server，來管理後端的多個伺服器節點，因此可以動態添加資料庫服務節點，刪除伺服器節點，也支持failover。如果你的使用場景必須要讓TC可以scale，那么可以考慮flare。
flare唯一的缺點就是他只支持memcached協定，因此當你使用flare的時候，就不能使用TC的table數據結構了，只能使用TC的key-value數據結構存儲。
二、滿足海量存儲需求和訪問的面向文檔的資料庫：MongoDB，CouchDB
面向文檔的非關係資料庫主要解決的問題不是高性能的並發讀寫，而是保證海量數據存儲的同時，具有良好的查詢性能。MongoDB是用C++開發的，而CouchDB則是Erlang開發的：
1. MongoDB
MongoDB是一個介於關係資料庫和非關係資料庫之間的產品，是非關係資料庫當中功能最豐富，最像關係資料庫的。他支持的數據結構非常鬆散，是類似json的bjson格式，因此可以存儲比較複雜的數據類型。Mongo最大的特點是他支持的查詢語言非常強大，其語法有點類似於面向對象的查詢語言，幾乎可以實現類似關係資料庫單表查詢的絕大部分功能，而且還支持對數據建立索引。
Mongo主要解決的是海量數據的訪問效率問題，根據官方的文檔，當數據量達到50GB以上的時候，Mongo的資料庫訪問速度是MySQL的10倍以上。Mongo的並發讀寫效率不是特別出色，根據官方提供的性能測試表明，大約每秒可以處理0.5萬－1.5次讀寫請求。對於Mongo的並發讀寫性能，我（robbin）也打算有空的時候好好測試一下。
因為Mongo主要是支持海量數據存儲的，所以Mongo還自帶了一個出色的分散式檔案系統GridFS，可以支持海量的數據存儲，但我也看到有些評論認為GridFS性能不佳，這一點還是有待親自做點測試來驗證了。
最後由於Mongo可以支持複雜的數據結構，而且帶有強大的數據查詢功能，因此非常受到歡迎，很多項目都考慮用MongoDB來替代MySQL來實現不是特別複雜的Web套用，比方說why we migrated from MySQL to MongoDB就是一個真實的從MySQL遷移到MongoDB的案例，由於數據量實在太大，所以遷移到了Mongo上面，數據查詢的速度得到了非常顯著的提升。
MongoDB也有一個ruby的項目MongoMapper，是模仿Merb的DataMapper編寫的MongoDB的接口，使用起來非常簡單，幾乎和DataMapper一模一樣，功能非常強大易用。
2. CouchDB
CouchDB現在是一個非常有名氣的項目，似乎不用多介紹了。但是我卻對CouchDB沒有什麼興趣，主要是因為CouchDB僅僅提供了基於HTTP REST的接口，因此CouchDB單純從並發讀寫性能來說，是非常糟糕的，這讓我立刻拋棄了對CouchDB的興趣。
三、滿足高可擴展性和可用性的面向分散式計算的資料庫：Cassandra，Voldemort
面向scale能力的資料庫其實主要解決的問題領域和上述兩類資料庫還不太一樣，它首先必須是一個分散式的資料庫系統，由分布在不同節點上面的資料庫共同構成一個資料庫服務系統，並且根據這種分散式架構來提供online的，具有彈性的可擴展能力，例如可以不停機的添加更多數據節點，刪除數據節點等等。因此像Cassandra常常被看成是一個開源版本的Google BigTable的替代品。Cassandra和Voldemort都是用Java開發的：
1. Cassandra
Cassandra項目是Facebook在2008年開源出來的，隨後Facebook自己使用Cassandra的另外一個不開源的分支，而開源出來的Cassandra主要被Amazon的Dynamite團隊來維護，並且Cassandra被認為是Dynamite2.0版本。目前除了Facebook之外，twitter都在使用Cassandra。
Cassandra的主要特點就是它不是一個資料庫，而是由一堆資料庫節點共同構成的一個分散式網路服務，對Cassandra的一個寫操作，會被複製到其他節點上去，對Cassandra的讀操作，也會被路由到某個節點上面去讀取。對於一個Cassandra群集來說，擴展性能是比較簡單的事情，只管在群集裡面添加節點就可以了。我看到有文章說Facebook的Cassandra群集有超過100台伺服器構成的資料庫群集。
Cassandra也支持比較豐富的數據結構和功能強大的查詢語言，和MongoDB比較類似，查詢功能比MongoDB稍弱一些，twitter的平台架構部門領導Evan Weaver寫了一篇文章介紹Cassandra，有非常詳細的介紹。
Cassandra以單個節點來衡量，其節點的並發讀寫性能不是特別好，有文章說評測下來Cassandra每秒大約不到1萬次讀寫請求，我也看到一些對這個問題進行質疑的評論，但是評價Cassandra單個節點的性能是沒有意義的，真實的分散式資料庫訪問系統必然是n多個節點構成的系統，其並發性能取決於整個系統的節點數量，路由效率，而不僅僅是單節點的並發負載能力。
2. Voldemort
Voldemort是個和Cassandra類似的面向解決scale問題的分散式資料庫系統，Cassandra來自於Facebook這個SNS網站，而Voldemort則來自於Linkedin這個SNS網站。說起來SNS網站為我們貢獻了n多的NoSQL資料庫，例如Cassandar，Voldemort，Tokyo Cabinet，Flare等等。Voldemort的資料不是很多，因此我沒有特別仔細去鑽研，Voldemort官方給出Voldemort的並發讀寫性能也很不錯，每秒超過了1.5萬次讀寫。
從Facebook開發Cassandra，Linkedin開發Voldemort，我們也可以大致看出國外大型SNS網站對於分散式資料庫，特別是對資料庫的scale能力方面的需求是多么殷切。前面我（robbin）提到，web套用的架構當中，web層和app層相對來說都很容易橫向擴展，唯有資料庫是單點的，極難scale，現在Facebook和Linkedin在非關係型資料庫的分散式方面探索了一條很好的方向，這也是為什麼現在Cassandra這么熱門的主要原因。
如今，NoSQL資料庫是個令人很興奮的領域，總是不斷有新的技術新的產品冒出來，改變我們已經形成的固有的技術觀念，我自己（robbin）稍微了解了一些，就感覺自己深深的沉迷進去了，可以說NoSQL資料庫領域也是博大精深的。
運營經驗
草根創業者的固執與執著：確立網站核心價值
JavaEye是在2003年9月創辦的，緣起是創始人范凱自己在學習和研究java的開源框架卻發現沒有一個討論的地方，於是自己就辦一個。如今，已經是國內專業性內容社區網站的佼佼者。范凱對於早期網站的運營描述為：一天10幾個小時趴在自己的網站上玩，除了睡覺就是泡在BBS上。慢慢地人氣就來了。
但BBS各種弊病也不期而遇：跪求、裸求、留爪、接分、mark、標題黨等。范凱拋給網站運營者們的第一個問題就是“什麼才是網站的核心價值”。他反覆在問自己“烏煙瘴氣、八卦、互相攻擊的氣氛是我想要的嗎？”范凱執著的認為自己要的就是一個深度交流技術、心平氣和學習的地方。為了營造一個比較乾淨、安靜交流技術的地方，從在2003年12月范凱開始採取比較嚴格的管理制度。這些管理制度大多數網站都有，但真正執行起來沒幾家沒有比的上JavaEye。“其他站長害怕得罪用戶，怕別人不來了。我不怕，我甚至不希望有這種沒質量的流量，首先你要認同這種價值觀才是 JavaEye的會員。”
JavaEye的新用戶註冊時需要強制做題。做13道有關論壇規則的選擇題，做不對就不予審核通過。范凱舉了個例子：有個用戶看到一個帖很好，想回復，一點，要註冊，註冊就註冊吧，要信箱激活，激活就激活吧，然後呢，回來發帖，還不行，要做題，做對了題居然還不行，說新註冊的用戶要3天后才能發帖。於是這個用戶把javaeye大罵一頓，說很不友好。
對於javaEye來說，對於有序討論的保證才是核心用戶的最好用戶體驗。一個網站的核心價值的確立，就是問自己的內心：“你想做一個什麼樣的網站”，然後檢視“這個網站對其他人來說有沒有價值”。如果這兩點都有了明確的答案，那么就記住這句話：走自己的路，讓別人說去吧。許多朋友力勸、許多網友詛咒，請不為所動。請執著，不要再被別人影響了。
專業型BBS的品牌樹立：“良幣驅逐劣幣”
2003年12月范凱決定實施嚴格的論壇管理制度，很多人質疑。但事實上，網站在2004年年初居然得到飛速發展，而且口碑一下就傳開了。
雖然清洗了1萬名非目標用戶，卻留住了100個核心用戶。並且這100個核心用戶產生的內容吸引了10萬個會員。因為這100個用戶是能創造大量有價值的內容，並且彼此有很好的互動。看似自殺的管理制度，其實帶來了論壇的核心競爭力。BBS的魅力和缺陷都來自於“頂帖制度”。有最新回復的帖子就放在最上面，於是這些帖子會被更多人關注，獲得更多評論，能很快把一個話題炒起來。可以說，BBS相比於SNS、部落格、百度問答等更容易繁榮起來。回帖就像平等的投票權，新手和老用戶一樣有這個權利通過回帖把一個帖子頂到最前面。在網站運營初期，這種機制能快速幫助BBS聚集人氣，達到用戶互動的高潮。但是回復灌水和標題黨也成了這種頂貼制度不可避免的產物。但這對於專業型 BBS來說很糟糕，會破壞專業性、高質量的討論。
因此，BBS一般都會有一個相似的曲線：很快地崛起，會有一個很繁榮的時期；但是隨著會員越來越多，核心用戶就被稀釋掉了；有信用度的老用戶的很多權利得不到體現，便會出現“劣幣驅逐良幣”的效應；當核心用戶都走光了，這個BBS就被新的BBS所替代，其自身就會面臨消亡。
對於JavaEye這個專用型BBS的嚴厲管理制則堅定地擯棄非目標用戶，用核心用戶吸引更多會員。除了上文提到的給新註冊用戶設下的考驗，還可以舉個例子如何吸引核心用戶。在BBS，經常可以看到“跪求”、“弱弱的問”等重複的入門提問帖，但是這會讓核心會員疲憊，所以范凱索性開了一個問答的頻道，分流提問解答的需求，而論壇僅僅定位在“交流”、“分享”，不允許出現提問。
產品創新：從依賴明星會員到社區整體競爭力提升
到了2006年，在Java領域的創新銳減，因此可供討論的話題少了，再加上嚴厲的管理制度內容產生不足，社區開始沉寂。
但是，內容不多本身不是個問題。問題反而出現在曾經仰賴的“明星會員”身上。老會員彼此很熟了，開始形成了一股內部政治勢力，霸占論壇話語權，排斥新會員。明星會員一呼百應，甚至能製造不利於論壇的輿論，網站和他們的矛盾便不可避免了。
明星會員是雙刃劍，一方面能吸引了很多人，是一個網站的核心競爭力之一。但是如果他們過於強勢，又會阻礙新人進入，心態膨脹，唯我獨尊，成了網站惹不起的主，甚至搞分裂、拉走用戶。
2008年1月網站第二次重寫，逐步轉型為綜合性社區門戶。一方面做BBS產品的創新，另一方面開闢了新聞頻道、部落格、文集、圈子等板塊，逐漸減低BBS流量的比重，現在BBS的流量大約只占全站的25%。帶來的影響就不是那么大。
綜合性內容建設
編輯主導：新聞、專欄
用戶自主：論壇、問答
用戶完全自主：部落格、圈子
成功的關鍵
1、價值觀：
堅定不移為目標用戶群體服務；冷酷無情的拋棄非目標用戶
2、以技術作為核心驅動力
3、敏捷的產品設計和網站運營
設計開發上線，最多2~3周就上線了。上線運營後才是關鍵，產品完善至少2~3個月。部落格產品經過了1年的修改。上線後的修改比之前的閉門造車重要的多。
比如，部落格留言是用倒序的。大多數用戶的需求建議都是偽需求，他不是站在你的高度去看的。用戶為什麼要來你這裡開部落格？部落格社區為他的文章做很好的推廣、社區氛圍很好等等。絕不是為了一大堆功能，因為你做了再多功能也拼不過wordpress。追求功能的用戶還是對你不滿意。還不如把部落格seo做好，把社區做好。勿以善小而不為：深入網站內部，了解每個細節。
目前暴露的問題
1、High performance——對資料庫高並發讀寫的需求
Web2.0網站要根據用戶個性化信息來實時生成動態頁面和提供動態信息，所以基本上無法使用動態頁面靜態化技術，因此資料庫並發負載非常高，往往要達到每秒上萬次讀寫請求。關係資料庫應付上萬次SQL查詢還勉強頂得住，但是應付上萬次SQL寫數據請求，硬碟IO就已經無法承受了。其實對於普通的BBS網站，往往也存在對高並發寫請求的需求，例如像JavaEye網站的實時統計線上用戶狀態，記錄熱門帖子的點擊次數，投票計數等，因此這是一個相當普遍的需求。
2、Huge Storage——對海量數據的高效率存儲和訪問的需求
類似Facebook，twitter，Friendfeed這樣的SNS網站，每天用戶產生海量的用戶動態，以Friendfeed為例，一個月就達到了2.5億條用戶動態，對於關係資料庫來說，在一張2.5億條記錄的表裡面進行SQL查詢，效率是極其低下乃至不可忍受的。再例如大型web網站的用戶登錄系統，例如騰訊，盛大，動輒數以億計的帳號，關係資料庫也很難應付。
3、High Scalability && High Availability——對資料庫的高可擴展性和高可用性的需求
在基於web的架構當中，資料庫是最難進行橫向擴展的，當一個套用系統的用戶量和訪問量與日俱增的時候，你的資料庫卻沒有辦法像web server和app server那樣簡單的通過添加更多的硬體和服務節點來擴展性能和負載能力。對於很多需要提供24小時不間斷服務的網站來說，對資料庫系統進行升級和擴展是非常痛苦的事情，往往需要停機維護和數據遷移，為什麼資料庫不能通過不斷的添加伺服器節點來實現擴展呢？
在上面提到的“三高”需求面前，關係資料庫遇到了難以克服的障礙，而對於web2.0網站來說，關係資料庫的很多主要特性卻往往無用武之地，例如：
1、資料庫事務一致性需求
很多web實時系統並不要求嚴格的資料庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此資料庫事務管理成了資料庫高負載下一個沉重的負擔。
2、資料庫的寫實時性和讀實時性需求
對關係資料庫來說，插入一條數據之後立刻查詢，是肯定可以讀出來這條數據的，但是對於很多web套用來說，並不要求這么高的實時性，比方說我（JavaEye的robbin）發一條訊息之後，過幾秒乃至十幾秒之後，我的訂閱者才看到這條動態是完全可以接受的。
3、對複雜的SQL查詢，特別是多表關聯查詢的需求
任何大數據量的web系統，都非常忌諱多個大表的關聯查詢，以及複雜的數據分析類型的複雜SQL報表查詢，特別是SNS類型的網站，從需求以及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大的弱化了。
因此，關係資料庫在這些越來越多的套用場景下顯得不那么合適了，為了解決這類問題的非關係資料庫應運而生，現在這兩年，各種各樣非關係資料庫，特別是鍵值資料庫(Key-Value Store DB)風起雲湧，多得讓人眼花繚亂。前不久國外剛剛舉辦了NoSQL Conference，各路NoSQL資料庫紛紛亮相，加上未亮相但是名聲在外的，起碼有超過10個開源的NoSQLDB，例如：Redis，Tokyo Cabinet，Cassandra，Voldemort，MongoDB，Dynomite，HBase，CouchDB，Hypertable， Riak，Tin， Flare， Lightcloud， KiokuDB，Scalaris， Kai， ThruDB
相關新聞
網站被封
2010年11月22日訊息，國內知名Java編程網站JavaEye被關閉，訪問網站被提示：“網站因有違規內容而被關閉，具體事宜請聯繫您的接入商”。JavaEye創始人、CSDN 產品總監Robbin(范凱)在twitter公開對“關站”一事作出回應是動態防火牆禁止了電信監控爬蟲所致。
今日14時10分左右，有網友向科技訊反映JavaEye網站被關閉，訪問時提示：“網站因有違規內容而被關閉，具體事宜請聯繫您的接入商”網站域名沒有跳轉直接顯示該內容。
JavaEye創始人、CSDN 產品總監Robbin(范凱)在twitter公開對“關站”一事作出回應，“我寫的動態防火牆代碼太智慧型了，把電信負責內容監控的爬蟲給封了，結果我就被封了”。Robbin(范凱)透露，網站下午有望恢復訪問，並解釋了被“封”的原因，是由於代碼輸入問題，把電信負責內容監控的爬蟲給封了，所以導致電信採取“關站”舉動。
相關新聞補充
據IT業人士透露，現在的ID C(接入服務商)或者電信部門，都會要求虛擬主機安裝主動式監控軟體，同時還會有一些掃描工具“用來做內容監控”，這些軟體會自動掃描所有網頁和連結，國外稱為“機器人”，國內稱為“爬蟲”。范凱編寫的防火牆正是為了針對這種內容監控掃描。范凱還公布了自己的防火牆技術原理，在這篇文章中他稱編寫此防火牆的原因是因為爬蟲“會導致網站訪問速度緩慢，甚至無法訪問，而且侵犯了網站的著作權”。
在微博中，范凱還透露了JavaEye被關的細節，他說他的防火牆封爬蟲時會要求填註冊碼，如果不填註冊碼才封。“剛才查了一下日誌，發現網段被封之後，該網段都有IP登錄上來填註冊碼解封、被封，然後填註冊碼解封、再被封，幾次三番下來，把監管人員逗急了，就下手了。”
22日下午，范凱曾表示“把監控爬蟲加入白名單了，爭取下午恢復網站訪問”，並一度宣布下午6—7點可恢復訪問，晚上7點11分又宣布23日上午可恢復訪問，但直到23日晚，JavaEye依然無法訪問。
改名ItEye
JavaEye網站從2011年4月1日起，正式更名為ItEye技術網站，同時網站域名從javaeye重定向到iteye。原因是Oracle公司不準其網站使用JAVA字樣，並提出了苛刻條件。JavaEye網站在交涉無效後，不得不做出更名的決定。
