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