infoq：我們在qzone中經常了解到的乙個名詞就是set，能夠為我們介紹一下set是怎樣乙個形式？
孫超：說到set，我先說乙個比較簡單的比喻：你可以把它理解成乙個貨櫃，乙個set是乙個殼子，它裡面裝著很多貨物；拿到qzone這來說，其實set就是把qzone的某些服務放到乙個小的盒子裡面，這樣來進行分布部署。
當時為什麼要有這個set，當時存在乙個背景，就是qzone從05年誕生，後面到06年、07年快速的發展，機器的整個規模從原來的一二百臺快速的膨脹到了上千臺，機房的建設其實對於業務的發展是有點滯後的，所以當時存在這種情況，比如說我們乙個服務，從邏輯層到資料層可能分布在深圳的幾個機房，這樣的話，我們就會存在大量的穿越。當網路之間的專線，不管是因為變更也好，還有意外也好——比如挖斷的專線等等這種情況，導致了我們整個的服務受到非常大的波動。
所以我們經過分析這些原因之後，就針對於這樣的乙個背景，來做了一次大的部署優化。其實set可以認為是乙個部署優化，我們的目的就是減少對專線的各種依賴，來保證在我們的核心服務當進入這樣的乙個set之後，可以完整的來啟用整個的功能。可以認為這個貨櫃，就在這樣的乙個部署之後，所有的請求不需要去貨櫃外面來訪問了。
我剛才介紹了整個的乙個背景，和當時的乙個目的，set其實我們在當時建設的時候，其實要把它建設好，要考慮比較多的因素。比如說對乙個set，我們要覆蓋多大的範圍，因為qzone整個業務是非常大的，包括裡面的一些基礎功能，日誌相簿，然後還有一些平台級的服務。最終，我們經過這種圈定，當時把整個的qzone set定義成空間的首屏。因為空間的首屏——就是進入空間之後第一屏看到的一些業務，它這裡的訪問量是非常大的。而且，為了當時做整個qzone的平台化，我們還有乙個使用者必須要先進入這樣乙個首屏才能去玩其他的一些業務的設定。既然有這樣乙個非常關鍵的點，所以我們必須要保證使用者的第一跳是成功的，所以我們把所有的精力都聚焦在一定要把首屏的可用性和質量提上去。所以我們當時的set，圈定的就是空間的整個首屏業務，它包括，比如說你有沒有qq空間，你的關係鏈，你的許可權，你的一些底層資料等等。
還有，首屏當時在07年的時候，我們的那個空間做了乙個大的改版，從原來乙個主要以裝扮為主的、面向客人的模式，轉向了乙個以好友動態為主的、個人中心的模式，所以裡面又會把好友的feeds當成了資料，核心資料，統一的都放到了這個set裡面去。
而後面的話，就是考慮一些容錯容災，部署的情況來建立這樣乙個set。
所以剛才提到那個set的概念，主要是當時的乙個思考過程，包括上述這幾點。
infoq：我聽說還有一些去set化的過程？
孫超：是這樣，去set化，首先是set比較多了，就有乙個去set化的問題。隨著我們當時從08年開始做了set化，這樣的方式不管是擴容還是運營成本都大幅下降，而且服務質量也提公升非常快，所以在整個的業務中開始大量的採用這種模式，最多的時候我們的set有30多個。
30多個set存在乙個問題：當時這個30多個set包括後面的idc分布之後，存在著三地，每個地方都有幾個set，合起來有30多個，這30多個裡面就存在著一些配置管理，因為相當於乙份資料我在三十多個set裡邊都同時存在，而我訪問的路由肯定是不一樣的，這樣路由管理的成本就變得非常的大。為了解決路由管理的問題，我們希望用去set化的方式，讓
前端在使用服務的時候，不需要區分它到底是在**，他只需要調乙個統一名字的服務，我們會根據它就近的部署的情況，自動的給他去路由到那裡。
所以，這就是後面的去set化，相當於前面使用方不用關心set這個概念了。
infoq：能不能介紹一下，承載這些set的idc這些是怎麼來做的？因為這些set全都是在idc中來做承載的，來部署在idc中，我們了解到現在是一點寫多點讀的方式，全國有多個idc機房，能不能介紹一下這塊的詳細情況？
孫超：這個問題很好，是這樣，set承載方式其實跟我們部署的考慮關係非常大的，首先，在乙個set中，其實核心是解決容災問題，而容災的話，比如說像現在的機房的故障非常的，就是多種多樣，包括機架交電、交換機故障，所以我們乙個set情況下，其實是在交換機是雙倍的，在機架上是盡量的在，因為我們要解決set內的容災，就是乙個資料總共有兩份資料分別存在兩個機架上，往再大里來看，它還是在乙個機房，所以我們像深圳的話，之前qzone是從深圳的這裡發展出去的，所以它很多的服務都是在深圳，而且它跟qq的依賴非常的多，所以qq上也會調qzone的一些服務，而qq當時主機也是在深圳，所以我們在深圳這邊，為了解決這樣的乙個單機房的風險，在深圳我們部署多個機房，多個機房就形成了乙個相互之間，既使有乙個故障，我們把它去來排程走就好，但是隨著後面的發展， qzone又要走出去，因為要解決北方使用者的使用體驗，包括華東地區，所以我們也是採用了三點分布，像北方、華東，還有那個華南用深圳來覆蓋，每個地區也都有這樣的一些情況，所以我們後面就產生了多個set多個idc。
infoq：然後因為你是多個set跟idc這樣的分布最主要面臨的乙個問題，就是資料同步的問題，然後現在我們的qzone是怎麼來解決這個問題的？
孫超：不管是set也好，還是idc分布也好，其實都是把乙個資料分布到多地，它必然存在的資料一致性、效率和最終一致性這樣的乙個問題，其實用那個cap理論來說，的確想滿足三個是做不到的。
所以剛才說的挺好的，就是我們採用的一點寫多點讀，但是這樣的話，使用者會有一些滯後感，所以我們在過程中是通過這種方式來解決：
第一是我們在所有的定義好的主寫點，因為要分布的資料，我們是知道的，所以把他所有的寫點集中在乙個set，我們稱之為資料來源set，然後當產生資料來源之後，他又會把這個資料的操作指令，或者最終的資料，通過我們做的分發系統（我們叫做同步中心），把它同步到全國的各個機房，然後重新再執行一次，就相當於把使用者的行為重錄了一次，當時的這個系統，這樣就把那多個拷貝的資料變成最新的。
但這裡的確存在乙個延時和網路抖動的情況，所以我們這個同步中心裡面做了很多的一些工作，比如說我們雖然公司裡面有很多專線，但是這個專線的確有一些流量限制，比如說他的整個頻寬因為公司全在用，也不可能乙個業務全佔掉，所以我們還是採用了大量的寬頻業務，比如說像feeds，這種富**的是採用外網傳輸，緊急情況下可能會切到內網，像一些底層的基礎資料資料量非常小，又非常重要，比如說我加了乙個好友，這樣的情況下，就採用了公司的專線來做，當異常情況下，就會排程到外網去，這樣就形成多個的傳輸通道。
然後對於時延，的確在
網際網路上來說，我看我好友的feeds，雖然說他對時間性的要求不是那麼高，比如說我的好友發了乙個feed，我可能不會馬上就能收到，但是隨著我們對使用者的觸達的方式越來越多，的確希望使用者能快速的得到，這樣跟我們的分布，其實是有一定的衝突的，但是過程中，我們做了很多的一些工作，比如說，我們剛完成了乙個操作之後，會把使用者重新定向他的資料來源，來讀取資料，這樣就避免了他的資料是不完整的，而且在傳輸的過程中，我們保證了傳輸的時間都是在毫秒級的，這樣使用者就不會有太多的一些感知，當網路傳輸比如出現擁塞的情況，我們也會幫使用者再重新去執行，保證資料不會丟失，等等的一些策略來，比說流量控制，soa的一些服務質量的保證，包括網屏對我們的一些支援來保證了我們整個傳輸過程中的質量，還是現在做的是非常可控的。
因為外部的話，會有一些虛擬化的一些考慮，而內部的，都是訪問量非常大的業務，所以應該說是在原來外部雲的一些基礎積累之上，針對雲內部的這種使用者專門做了更多的一些定製，然後把一些對內部需要不到的一些情況把它去掉，所以其實我們，空間來說，應該是90%的功能，其實都是在內部的這種儲存雲、計算雲之上，還有一些少部分呢，是因為那個是老的一些系統，還沒有往上來去搬遷，所以應該是乙個往內部來轉換的乙個過程，因為對於我們的運營效率和質量其實幫助是非常大的。
infoq：qzone經過好幾次改版，每次改版我相信後台的架構也會有相應的變化，您也負責整個soa的整個系統的乙個架構建設，能不能和我們分享一下，整個qzone、soa它是怎麼來做得，有沒有哪些新的體驗，因為soa它這個歷史也比較久了嗎。
所以在這個乙個背景下，當時想就是我們一定要把空間的平台的這個服務，因為我們雲做成平台了，外面支撐了非常多的一些業務，我們一定要這塊一些質量和管理做好，所以當時啟動了乙個qzone，soa的乙個優化專案。其實這個優化專案呢，我們當時考慮，第一，我們對外提供了哪些核心的服務，第二是我們這些服務有沒有一些共性，還有呢，就是當前我們遇到了哪些一些問題，經過這幾方面呢，我們梳理完之後發現其實我們整個的服務還是有很多的共性的。
通過這種抽象，我們就把原來的上百個模組減少到了幾十個模組，這樣就大大減少了我們整個乙個維護成本，其實我們的soa的建設呢，雖然名字叫soa，其實不完全等同於拍拍，類似跟亞馬遜一樣的，這是比較有空間自己特色的，就是把我們的更多的服務、更多的一些功能抽象服務化，在上乙個新功能的時候，能通過快速搭建，像搭建積木一樣，而不是再多的，從原始的組建上，比如說我們有網路框架、有儲存服務，如果從那上面再重新建設，其實成本還是蠻高的，所以經過這種服務化，建設之後，我們再做乙個功能，時間就大大減少了，所以呢，我們整個的soa，其實是為了解決效率和對外的平台服務的問題來產生的。
infoq：最後乙個問題就是下一步會做哪些工作來做優化？
孫超：這個問題其實也是我們最近一直在思索，也是想到了幾個點，現在已經有一部分在實施了。
第一是剛才提到了像我們已經做完的工作，像我們qzone平台級的一些基礎資料的一些服務化，而現在，像qzone的核心的動態像feeds其實它跟業務之間，像多個業務都在接入空間，他很多的方式採用了qzone的feeds這種暴光展示的方式來介入的，而不僅僅是接入乙個入口，而是更多的參與到使用者內容裡去，而feeds這個平台涉及到的服務非常多，所以第一步，我們會把這個更核心的業務feeds做成乙個服務化的乙個模式。
第二，像使用者，我們之前，空間可能針對於不同的使用者，他看到東西其實一樣的，現在呢，我們也正在做這種精細化的運營，尤其是像不同的使用者，他可能有不同的一些喜好特點，然後他可能進來之後我們給他推薦不同的一些內容，像熱點的一些feeds，就是挖掘出來的，然後呢，像那個feeds的一些排序，facebook很早就已經做了，然後我們也正在做這方面的事情，第二點，就是我們正在做這種智慧型feeds，這種精細化運營的一些事情。
第三，我覺得還是回到我們qzone一定要解決使用者的基本的整個服務質量的問題，像qzone的盤子也是非常大，功能也非常多，我們要壓縮成本，解決使用者的那個速度，因為在不同的環境裡面，訪問空間的速度雖然有很多優化，但是還是有使用者訪問慢，所以我們還重點解決這個慢的問題，還有這個如何能把這個內部的所有的這種情況更好的能完全監控到，等等的一些情況，能做到，盡量的能發現使用者使用服務中的存在的一些體驗的一些問題，而不等使用者來投訴，我們及時通過這種問題發現之後快速去解決它，所以大概也就這三部分的事情。
軟體架構設計 二 系統總體架構設計
系統總體架構非常重要，但在表達上都不盡相同，下面介紹幾種常用的系統架構模式，供參考 assf access service biz standard fundation 模式 訪問 服務 業務功能 標準 基礎，對系統架構各個層次均有表達，但部署應用模式需要有單獨說明，如下圖方式組織系統總體架構 lo...
軟體架構設計 二 系統總體架構設計
系統總體架構非常重要，但在表達上都不盡相同，下面介紹幾種常用的系統架構模式，供參考 assf access service biz standard fundation 模式 訪問 服務 業務功能 標準 基礎，對系統架構各個層次均有表達，但部署應用模式需要有單獨說明，如下圖方式組織系統總體架構 lo...
軟體架構設計 二 系統總體架構設計
系統總體架構非常重要，但在表達上都不盡相同，下面介紹幾種常用的系統架構模式，供參考 assf access service biz standard fundation 模式 訪問 服務 業務功能 標準 基礎，對系統架構各個層次均有表達，但部署應用模式需要有單獨說明，如下圖方式組織系統總體架構 lo...