架構師接龍是《程序員》雜志最近推出的一個活動，活動方式為：每期一個提問嘉賓，一個回答嘉賓，并由回答嘉賓提出新的問題給下期的架構師，形成接龍，之前第一期是支付寶的馮大輝提問，騰訊的研發(fā)總監(jiān)王速瑜回答，我參與的是第二期，這期會登在《程序員》0909期上，內容轉帖如下，原帖為程序員官方上的：
http://www.programmer.com.cn/727/，呵呵，都只是個人的片面理解做出的回答，也歡迎大家在此帖中繼續(xù)討論，:)
王速瑜：數(shù)據(jù)集群問題：當數(shù)據(jù)增長到一定的數(shù)量級，必須要進行分布部署、備份、容災、切割擴容等工作。請問什么程度的數(shù)量級需要分布部署，如何合理分布部署，需要考慮哪些情況？
林昊：一般來說，也沒有固定的數(shù)量級，通常是根據(jù)硬件資源的狀況以及所能接受的性能狀況（例如一次查詢必須在3ms內完成）來決定。當達到性能瓶頸時，通常需要進行數(shù)據(jù)的拆分或備份等策略，在這個過程中最需要考慮的，就是對應用的影響程度，因此通常會需要一個強大、透明的數(shù)據(jù)層，以屏蔽數(shù)據(jù)的拆分或備份、遷移操作給應用帶來的影響，另外一方面就是應盡量能做到不停機完成。當然，這很難，因為需要面對多套數(shù)據(jù)結構并存、數(shù)據(jù)冗余和同步等問題。
王速瑜：數(shù)據(jù)備份問題：對于大容量的數(shù)據(jù)備份，技術上如何做到不影響正常的服務？如何合理制定冷備、熱備的實施策略、方式、時間段？在數(shù)據(jù)損壞、主服務器硬件損壞等故障情況下，如何最短時間內監(jiān)控到故障并調度請求到備份服務器等容災措施？
林昊：對于大容量的數(shù)據(jù)備份，技術上來說：多數(shù)情況下比較好的是選擇異步消息通知實現(xiàn)數(shù)據(jù)備份，或基于高端數(shù)據(jù)庫的特性（例如Oracle的Standby）。對于冷備、熱備的實施，原則要求均為不影響正常業(yè)務功能，因此可選的時段只能是系統(tǒng)訪問量較低的時段。方式則需要根據(jù)數(shù)據(jù)量以及備份的速度來決定，多數(shù)均為采取相對高頻率的進行熱備，低頻率的進行冷備；在數(shù)據(jù)損壞、主服務器硬件損壞等故障時，要做到盡快切換，就必須依賴強大的及時監(jiān)控系統(tǒng)，在主服務器不可用時能夠做到迅速報警。最理想狀況就是能夠有一種機制，自動切換備庫為主庫，并通知所有應用轉換為連接和使用新的主庫，如果做不到自動的話，這個過程就仍然得基于“人肉”來進行操作了。
王速瑜：開放平臺設計問題：開放平臺API設計中，調用協(xié)議設計時有哪些考慮要求？對于請求類的調用協(xié)議設計，傾向于call?A=a&B=b這種方式（這種方式對調用者比較方便，但對二進制的傳輸有一定限制，比如上傳圖片等），還是基于純文本的方式，比如WSDL、XML等？對用戶鑒權的Token機制是怎樣的？有沒有對接入方進行QoS的考慮，是怎么做的?
林昊：對于開放平臺而言，基本上目前Facebook引領了開放平臺的技術，因此在協(xié)議上多數(shù)都采用Http，接口的設計上則都傾向于REST風格；對于用戶鑒權的Token機制上通常都是采用一個公私鑰的匹配方式，并且此Token一定是由開放平臺公司所提供；開放平臺中是肯定會對接入方的QoS有限制的，并且這通常也影響到了開放平臺的收費標準，在實現(xiàn)時多數(shù)采用基于緩存進行實時費用計算，這點更強的應該是電信行業(yè)。
王速瑜：跨IDC部署程序模塊在業(yè)務發(fā)展到一定階段后在所難免，跨IDC的專線資源相對有限。架構師該如何合理規(guī)劃和使用同城、跨城的專線進行傳輸數(shù)據(jù)，以及專線意外中斷的容災措施？
林昊：跨IDC部署確實會存在很高的技術難度，部署結果的驗證是最為關鍵的地方，其次是部署所耗費的帶寬成本和時間成本，對于部署結果驗證而言，通常可采用的方法為業(yè)務腳本的測試；對于部署所耗費的帶寬成本而言，通常需要借助多播技術，對于時間成本而言，通常需要借助自動化的部署系統(tǒng)。
王速瑜：Web2.0網站的海量小文件的存儲，如用戶頭像、相冊微縮圖等文件，這些文件的特點是尺寸小（100KB以內），數(shù)量巨大（數(shù)以百萬計），這些文件的存儲、讀取、備份都是問題，請問您是如何提供具體解決方案的？
林昊：目前互聯(lián)網公司，例如Google、優(yōu)酷等，對于小文件或大文件的存儲都有自己的一套解決方案，而并不會去依賴高端的存儲設備來解決。一方面是成本問題，另外一方面是伸縮問題，因此對于這些文件的存儲、讀取和備份多數(shù)都采用了類似GFS的方案或直接采用Hadoop提供的HDFS方案。
王速瑜：互聯(lián)網產品部署是一個很關鍵的環(huán)節(jié)，很多互聯(lián)網公司依然采取手工部署發(fā)布產品版本的方式，但是這種方式比較復雜而且低效，往往很容易出錯，如果同時發(fā)布幾個產品時，如果產品之間關聯(lián)比較緊密，其中一個發(fā)布出錯就會影響到其他的發(fā)布，請問作為架構師，您在日常工作中是如何解決這樣的問題？您的團隊中是否考慮自動化動態(tài)部署，具體方案是怎么樣的？
林昊：在部署這個問題上，目前好像只有國外的幾家互聯(lián)網公司做的不錯，其中最典型的是eBay。eBay在很多年前就已經做了一套自動化部署系統(tǒng)，在這套系統(tǒng)中，eBay可以將一次發(fā)布中的幾個產品進行依賴關系的分析，從而決定其發(fā)布順序，并可實現(xiàn)自動的發(fā)布、校驗和回滾，這套系統(tǒng)相信也是現(xiàn)在中國幾家互聯(lián)網公司都在追求的目標。
王速瑜：作為互聯(lián)網技術架構師，您能簡單總結一下海里互聯(lián)網服務技術架構方面的理念、原則，方法嗎？
林昊：我覺得eBay的五點總結基本已經夠全面：
（1）“ 拆分”，數(shù)據(jù)庫的拆分以及應用的拆分，當然這需要強大的技術的支撐，這點要做到的目標通常是便于應用的無限水平伸縮；
（2）能異步就異步，這需要業(yè)務的允許；
（3）能自動就自動，就像自動化的部署系統(tǒng)；
（4）記住所有失敗的事情，這點非常重要；
（5）容忍不一致性，這句話的含義是盡量少用強事務，而是采用最終一致性這類方案。
當然，除了上面這五點之外，還有像多用緩存、自行實現(xiàn)關鍵技術（以控制穩(wěn)定性、性能和做到及時響應）等。
王速瑜：有很多優(yōu)秀的軟件架構師能力很強，但是由于缺乏海量服務技術應用和實踐的機會，不能很好地進行海量服務應用的架構設計，您能給他們一些寶貴建議，分享一下您是如何不斷學習成長起來的？您有哪些提高技術視野的方法和途徑，比如有哪些書籍可以推薦，哪些優(yōu)秀的網站可以推薦？
林昊：這個問題提到點子上了，很多架構師不知道如何應對大型、高并發(fā)的場景，最主要的原因是沒有這樣的實踐的機會，畢竟目前只有在大型企業(yè)系統(tǒng)或互聯(lián)網才能獲得這類難得的實踐機會，通常在沒有實踐機會的情況下是很難完全理解這些技術的。多數(shù)情況下，互聯(lián)網中的技術方案都是在多次血淚宕機下成長起來的，建議只能是多看各種互聯(lián)網技術介紹的文章，例如Google共享了很多，還有網上也有很多各家互聯(lián)網公司技術架構文章的介紹，尤其是那類技術發(fā)展歷程的介紹，可以設想下如果自己碰到這樣的問題，會如何去解決，也許這樣能慢慢掌握和理解大型、高并發(fā)系統(tǒng)的解決方案。書籍方面目前國內各種高性能方面的書也開始不斷冒出了，例如有《MySQL性能調優(yōu)與架構設計》、《構建高性能的Web站點》、《構建Oracle高可用環(huán)境》等，這些高性能的書通常都來源于作者親身的經驗，是非常值得學習的；另外要知道：如果想做到高性能，通常意味著要對軟件（包括OS等）以及硬件技術都有充分的掌握，因此像《深入理解JDK》、《深入理解Linux內核》、《深入理解計算機系統(tǒng)》這些書也是非常值得一看的。至于網站方面，像http://highscalability.com/、http://www.javaperformancetuning.com/這些都是非常不錯的網站。