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