知乎網站構架變遷

知乎是一個真實的網路問答社區，社區氛圍友善與理性，連結各行各業的精英。使用者分享彼此的專業知識、經驗和見解，為中文網路源源不絕地提供高品質的資訊。

也許很多人還不知道，知乎在規模上是僅次於百度貼吧和豆瓣的中文互聯網最大的UGC(用戶生成內容)社群。知乎創業三年來，從0開始，到現在已經有了100多台伺服器。目前知乎的註冊用戶超過了1100萬，每個月有超過8000萬人使用；網站每個月的PV超過2.2億，差不多每秒鐘的動態請求超過2500。

在ArchSummit北京2014大會上，知乎聯合創始人兼 CTO 李申申帶來了知乎創業三年多來的首次全面技術分享。

初期架構選型

在2010年10月真正開始動手做知乎這個產品時，包含李申申在內，最初只有兩位工程師；到2010年12月份上線時，工程師是四個。

知乎的主力開發語言是Python。因為Python簡單且強大，能夠快速上手，開發效率高，而且社群活躍，團隊成員也比較喜歡。

知乎使用的是Tornado框架。因為它支援異步，很適合做即時comet應用，而且簡單輕量，學習成本低，再就是有FriendFeed 的成熟案例，Facebook 的社群支援。知乎的產品有個特性，就是希望跟瀏覽器端建立一個長連接，方便即時推送Feed和通知，所以Tornado比較適合。

最初整個團隊的精力全部放在產品功能的開發上，而其他方面，基本上能節約時間、能省的都用最簡單的方法來解決，當然這在後期也帶來了一些問題。

最初的想法是用雲端主機，節省成本。知乎的第一台伺服器是512MB記憶體的Linode主機。但是網站上線後，內測受歡迎程度超乎預期，很多用戶回饋網站都很慢。跨國網路延遲比想像的要大，特別是國內的網路不均衡，全國各地用戶存取的情況都不太一樣。這個問題，再加上當時要做網域備案，知乎又回到了自己買機器找機房的老路上。

買了機器、找了機房之後又遇到了新的問題，服務常常宕掉。當時服務商的機器記憶體總是出問題，動不動就重啟。終於有一次機器宕掉起不來了，這時知乎就做了Web和資料庫的高可用。創業就是這樣一個情況，永遠不知道明早醒來的時候會面臨什麼樣的問題。

這是當時那個階段的架構圖，Web和資料庫都做了主從。當時的圖片服務託管在又拍雲上。 除了主從，為了效能更好還做了讀寫分離。為解決同步問題，又新增了一個伺服器來跑離線腳本，避免對線上服務造成回應延遲。另外，為改善內網的吞吐量延遲， 也更換了設備，讓整個內網的吞吐量翻了20倍。

在2011年上半年時，知乎對Redis已經很依賴。除了最開始的佇列、搜尋在用，後來像Cache也開始使用，單機儲存成為瓶頸，所以引入了分片，同時做了一致性。

知乎團隊是一個很相信工具的團隊，相信工具可以提升效率。工具其實是一個過程，工具並沒有所謂的最好的工具，只有最適合的工具。而且它是在整個過程中，隨著整個狀態的變化、環境的變化而不斷變化的。知乎自己開發或使用過的工具包括Profiling（函數級追蹤請求，分析調優）、Werkzeug（方便調試的工具）、Puppet（配置管理）和Shipit（一鍵上線或回滾）等。

日誌系統

知乎最初是邀請制的，2011年下半年，知乎上線了申請註冊，沒有邀請碼的用戶也可以透過填寫一些資料申請註冊知乎。用戶量又上了一個台階，這時就有了一些發廣告的帳戶，需要掃除廣告。日誌系統的需求提上日程。

這個日誌系統必須支援分散式收集、集中儲存、即時、可訂閱和簡單等特性。當時研究了一些開源系統，像是Scribe整體不錯，但不支援訂閱。 Kafka是Scala開發的，但是團隊在Scala方面累積較少，Flume也是類似，而且比較重。所以開發團隊選擇了自己開發一個日誌系統－Kids（Kids Is Data Stream）。顧名思義，Kids是用來匯集各種資料流的。

Kids參考了Scribe的想法。 Kdis在每台伺服器上可以設定成Agent或 Server。 Agent直接接受來自應用程式的訊息，把訊息匯集之後，可以打給下一個Agent或直接打給中心Server。訂閱日誌時，可以從 Server取得，也可以從中心節點的某些Agent取得。

具體細節如下圖：

知乎還基於Kids做了一個Web小工具（Kids Explorer），支援即時看線上日誌，現在已經成為調試線上問題最主要的工具。

Kids已經開源，放到了Github上。

事件驅動的架構

知乎這個產品有一個特點，最早在加入一個答案後，後續的操作其實只有更新通知、更新動 態。但隨著整個功能的增加，又多出了一些更新索引、更新計數、內容審查等操作，後續操作五花八門。如果按照傳統方式，維護邏輯會越來越龐大，維護性也會 非常差。這種場景很適合事件驅動方式，所以開發團隊對整個架構做了調整，做了事件驅動的架構。

這時首先需要的是一個訊息佇列，它應該可以取得到各種各樣的事件，而且對一致性有很高的 要求。針對這個需求，知乎開發了一個叫Sink的小工具。它拿到訊息後，先做本地的保存、持久化，然後再把訊息分發出去。如果那台機器掛掉了，重新啟動時可以 完整恢復，確保訊息不會遺失。然後它透過Miller開發框架，把訊息放到任務隊列。 Sink更像是串列訊息訂閱服務，但任務需要並行化處理， Beanstalkd就派上了用場，由其對任務進行全週期管理。架構如下圖：

舉例而言，如果現在有用戶回答了問題，首先系統會把問題寫到MySQL裡面，把訊息塞到Sink，然後把問題回傳給用戶。 Sink透過Miller把任務寄給 Beanstalkd，Worker自己可以找到任務並處理。

一開始上線時，每秒鐘有10個訊息，然後有70個任務產生。現在每秒鐘有100個事件，有1500個任務產生，就是透過現在的事件驅動架構來支撐的。

頁面渲染優化

知乎在2013年時每天有上百萬的PV，頁面渲染其實是計算密集型的，另外因為要獲取數據，所以也有IO密集型的特點。這時開發團隊就對頁面進行了元件化，也升級了資料取得機制。知乎依照整個頁面組件樹的結構，自上而下分層地獲取數據，當上 層的數據已經獲取了，下層的數據就不需要再下去了，有幾層基本上就有幾次數據獲取。

結合這個思路，知乎自己做了一套模板渲染開發框架－ZhihuNode。

經歷了一系列改進之後，頁面的效能大幅提升。問題頁面從500ms 減少到150ms，Feed頁面從1s減少到600ms。

服務導向的架構（SOA）

隨著知乎的功能越來越龐雜，整個系統也越來越大。知乎怎麼做的服務化呢？

首先需要一個最基本的RPC框架，RPC框架也經歷了好幾版演進。

第一版是Wish，它是一個嚴格定義序列化的模型。傳輸層用到了STP，這是自己寫的很 簡單的傳輸協議，跑在TCP上。一開始用的還不錯，因為一開始只寫了一兩個服務。但隨著服務增多，有些問題開始出現，首先是 ProtocolBuffer會 產生一些描述程式碼，很冗長，放到整個函式庫裡顯得很醜陋。另外嚴格的定義使其不便使用。這時有位工程師開發了新的RPC架構—Snow。它使用簡單的 JSON做資料序列化。但是鬆散的資料定義面對的問題是，比如說服務要去升級，要改寫資料結構，很難知道有哪幾個服務在使用，也很難通知它們，往往錯誤就 發生了。於是又出了第三個RPC框架，寫出RPC框架的工程師，希望結合前面兩個框架的特點，首先保持Snow簡單，其次需要相對嚴格的序列化協議。這一版 本引進了 Apache Avro。同時加入了特別的機制，在傳輸層和序列化協定這一層都做成了可插拔的方式，既可以用JSON，也可以用Avro，傳輸層可以用STP，也可以用 二進位協定。

再來就是搭了一個服務註冊發現，只需要簡單的定義服務的名字就可以找到服務在哪台機器上。同時，知乎也有相應的調優的工具，基於Zipkin開發了自己的 Tracing系統。

依照呼叫關係，知乎的服務分成了3層：聚合層、內容層、基礎層。依屬性又可以分成3類：資料服務、邏輯服務和通道服務。資料服務主要是一些要做特殊資料類型的存儲，例如圖片服務。邏輯服務更多的是CPU密集、運算密集的操作，例如答案格式的定義、解析等。通道服務的特點是沒有存儲，更多是做一個轉發，比如說Sink。

這是引入服務化之後整體的架構。

產品服務

知乎首頁，大致上有四個功能區。在左側，是“最新動態”，大約占到首頁70%版面，主要呈現用戶所關注人的最新提問及回答等資訊。用戶在這一版塊，除了查看最新問題及回答之外，還

可以透過「設定」、「關注問題」、「新增評論」「分享」、「感謝」和「收藏」等功能參與自己感興趣的問題。如利用「設定」功能，使用者可以選擇屏蔽話題。在所關注用戶關注問題下，也可以對此問題添加關注、添加評論等行為。

在首頁右上方版面，是使用者在知乎網路相關行為管理資訊。有「我的草稿」、「我的收藏」、「所有問題」、「我關注的問題」和「邀請我回答的問題」。 在右側中間位置，是網外邀請功能－「邀請好友加入知乎」。在這個版塊中，使用者可以透過電子郵件和新浪微博邀請自己朋友加入到知乎社群中。 在右側中下方，為用戶追蹤或感興趣主題或用戶推薦板塊。在話題和用戶推薦上，知乎運營方一方面可能根據用戶關注話題資訊匯總，一方面可能透過用戶在知乎網絡相關行為數據記錄統計，達到相當準確推薦和匯總。同時，特別一提的是，右下方的「話題廣場」板塊中，知乎網將所有話題分類標籤呈現，為用戶除搜尋和導航之外，有一種不錯的獲取資訊方式。

知乎話題頁，可分為兩個板塊，如圖2所示，一個是“話題動態”，一個是“常去話題”。在左側為「話題動態」訊息，佔版面約70%。在這一板塊中，使用者可以對所關注話題下問題（按時間順序呈現）點擊查看，也可以對所關注主題進行「固定」和「取消關注」操作。

在右下方，是「常去話題」版面。在這一版面中，用戶可以了解所關注話題具體諸如子話題、關注人數和動態等資訊。

知乎通知頁，可分為四個版面，如圖3所示。左側「全部通知」為使用者關注問題為其他使用者回答資訊（以時間先後順序呈現）。右側，使用者行為資料彙總、「邀請好友加入知乎」、話題及話題推薦版面等，和首頁介紹一樣，這裡不再贅述。

知乎個人主頁大致分為5個版面：「個人資料」、「個人回答」、「個人主頁」、「搜尋用戶問題和答案」、「追蹤人和被關注資訊」和「關注主題」。具體如圖4所示。

在「個人資料」版面，用戶可以點擊「查看詳細資料」查看用戶「個人成就」（包括獲得「贊同」數量、「感謝」數量、「收藏」數量和「分享」數量）、「職業經歷“ 、」居住資訊「、」教育經驗「、」擅長技能「5個面向資訊。如果是知乎用戶，可以透過點擊」編輯我的資料「完善以上5個面向資訊。

左下方，為「個人回答「版面，是使用者對相關問題回答資訊（依照贊同數量降序排列或依照回答時間順序從近到遠排列）。以上」個人資料「和」個人回答「兩個版面能佔整個70%位置。

在右上方，為「個人主頁「版面，是對知乎最新動態，用戶提的問題、答案、收藏和日誌資訊匯總。

右側中間位置，是一個搜尋框。使用者可以透過這個搜尋框查詢具體使用者的問題和回答內容。

右側中下方，分別是用戶個人關注人或被關注和關注話題資訊。使用者可以點選相關圖標，一鍵連接具體板塊中。

知乎問題頁面－是知乎最主要的頁面。在這裡用戶可以了解、編輯、回答具體問題和信息，

知乎此版面，依照功能大致可分為六個部分，分別為「問題回答」、「關注功能」、「邀請功能」、「相關問題連結」、「分享功能」和「問題狀態」。

在左側位置，為「問題回答」版面，占到這一板塊大約70%位置。在這一板塊的版面中，使用者可以對相關問題進行修改、評論、舉報和管理投票。 使用者可以對自己覺得不合適問題、問題標籤和問題補充進行修改。同時，如果發現不合適或自己感興趣問題，用戶也可以評論或舉報。在問題回答上，使用者可以按照相當適合自己方式對問題回答進

行排序操作（知乎提供依投票排序、依時間排序及依使用者追蹤者顯示三種內容呈現方式）。

除此，值得一提的是每個回答左側有分別代表贊同和反對一上一下兩個三角形，如圖6所示。使用者可以根據自己知識理解角度或興趣對問題回答進行個人化管理。

在這一板塊右側，從上到下首先是「關注」功能。在這一功能板塊中，用戶可以對問題進行關注，這有點像新浪微博關注功能，不同的是，知乎關注主要針對具體問題，而新浪微博主要針對具體用戶。

右側再向下，是「邀請別人回答問題」版面。這和前面「知乎首頁」和「知乎通知」板塊介紹功能一樣，這裡不再贅述。

再向下，是與問題相關各個問題。這也是大多數網站系統推薦方式的一種。雖然這一種推薦方式在技術和經驗上相對較成熟，但效果上並不是達到毫無挑剔程度。知乎在問題相關問題連結方面，主要是針對具體問題特點，透過對應演算法進行機器推薦，並沒有做到針對不同使用者愛好個性推薦效果(這也是未來網路發展趨勢，電子商務平台更為關注這一技術)。

再向下，便是問題分享功能。使用者可以將知乎問題透過「微博「和」郵件「進行站外分享和透過「站內私訊」進行站內分享。

在右側最下方位置，便是問題狀態。在這一版面中，用戶可以了解問題最近活動發生時間，被瀏覽次數、相關話題追蹤者人數和該問題關注人數資訊。

使用者體驗

1. 準確地講，知乎更像一個論壇：使用者圍繞著某一感興趣的話題進行相關的討論，同時你可以關注和你興趣一致的人。對於概念性的解釋，網路百科幾乎涵蓋了你所有的疑問；但是對於發散性思考的整合，卻是知乎的一大特色。知乎鼓勵在問答過程中進行討論，以拓寬問題的發散性。鼓勵答案的非針對性，鼓勵答案的Wiki可參考性。

2.比論壇更有排他性，在知乎的每​​一個註冊用戶都有一個PR（Person Rank），你的每一個操作都會直接影響你個人的PR 值。在回答的時候，答案順序按讚同票數排序，在讚同票數相同的情況下按個人PR值排序，同時隱藏被認為無效的答案。這在一定程度上過濾了相當的垃圾訊息。

3.知乎曾經堅持嚴格的邀請制度，一來是為了確保使用者準實名身分的真實性，二來避免產生過多的垃圾訊息。準實名可以方便用戶有的放矢的向你感興趣的人提出疑問，這是當初韓寒流產的《獨唱團》中有一個相當有意思的欄目，“所有人問所有人”，換句話說，這就是現實版的知乎。同時，知乎嚴格的邀請制度也使知乎籠罩著濃鬱的嚴謹氛圍，以keso為代表，不言則已，一言服人。

自2013年3月起，知乎開放民眾報名。

4、以信用為基礎的SNS關係。可能單純作為SNS與問答的整合，國內人人網應該更能快速發展；但是正如前文所說，嚴格的邀請制度，排斥了相當一部分無效信息；如果人人網亦推出社會化問答，那必然會整合你原先的好友，而這部分好友顯然不可能都是對你的關注點感興趣的人。這也幾乎否定了任何大型網路公司進軍Quora類問答的可能性。

因為大型網路公司受眾普遍廣泛，而Quora類問答並不是單純以人氣為基礎的，而是價值資訊比（價值資訊/總資訊量），也就是菁英資訊產生量。

不過千橡旗下低調推出經緯網，作為垂直SNS聚集了相當數目的職業人，倘若千橡以此為契合點，整合類Quora問答，還是相當有潛力的。

5.與Quora相比，知乎以藍色為基調。相較於與Quora，知乎功能還是有待完善，例如某一話題下最佳話題。