淘寶平臺架構師談海量互聯網服務技術架構（轉載）

林昊，網名BlueDavy，China OSGi User Group Director，淘寶網平臺架構部架構師，我的的研究方向主要爲 Java模塊化、動態化系統的構建以及高性能的大型分佈式Java系統的構建。曾編寫《OSGi實戰》和《OSGi進階》兩篇Opendoc，爲OSGi 在中國的推廣起到了很大的做用。1 U: @% ~8 @* M2 \7 @4 L7 G
王速瑜：數據集羣問題：當數據增加到必定的數量級，必需要進行分佈部署、備份、容災、切割擴容等工做。請問什麼程度的數量級須要分佈部署，如何合理分佈部署，須要考慮哪些狀況？
$ n9 c1 m0 H: y" `0 A  I5 b; G4 E# J0 k林昊：通常來講，也沒有固定的數量級，一般是根據硬件資源的情況以及所能接受的性能情況（例如一次查詢必須在 3ms內完成）來決定。當達到性能瓶頸時，一般須要進行數據的拆分或備份等策略，在這個過程當中最須要考慮的，就是對應用的影響程度，所以一般會須要一個強 大、透明的數據層，以屏蔽數據的拆分或備份、遷移操做給應用帶來的影響，另一方面就是應儘可能能作到不停機完成。固然，這很難，由於須要面對多套數據結構 並存、數據冗餘和同步等問題。
; v4 W8 Q. G% t: {王速瑜：數據備份問題：對於大容量的數據備份，技術上如何作到不影響正常的服務？如何合理制定冷備、熱備的實施策略、方式、時間段？在數據損壞、主服務器硬件損壞等故障狀況下，如何最短期內監控到故障並調度請求到備份服務器等容災措施？
  W- x. E0 b+ h; \: D林昊：對於大容量的數據備份，技術上來講：多數狀況下比較好的是選擇異步消息通知實現數據備份，或基於高端數據 庫的特性（例如Oracle的Standby）。對於冷備、熱備的實施，原則要求均爲不影響正常業務功能，所以可選的時段只能是系統訪問量較低的時段。方 式則須要根據數據量以及備份的速度來決定，多數均爲採起相對高頻率的進行熱備，低頻率的進行冷備；在數據損壞、主服務器硬件損壞等故障時，要作到儘快切 換，就必須依賴強大的及時監控系統，在主服務器不可用時可以作到迅速報警。最理想情況就是可以有一種機制，自動切換備庫爲主庫，並通知全部應用轉換爲鏈接 和使用新的主庫，若是作不到自動的話，這個過程就仍然得基於「人肉」來進行操做了。
2 N- C/ U0 O' ?$ `) j1 K9 P王速瑜：開放平臺設計問題：開放平臺API設計中，調用協議設計時有哪些考慮要求？對於請求類的調用協議設計， 傾向於call?A=a&B=b這種方式（這種方式對調用者比較方便，但對二進制的傳輸有必定限制，好比上傳圖片等），仍是基於純文本的方式，比 如WSDL、XML等？對用戶鑑權的Token機制是怎樣的？有沒有對接入方進行QoS的考慮，是怎麼作的?
% {1 U7 m6 p( `8 ^; D林昊：對於開放平臺而言，基本上目前Facebook引領了開放平臺的技術，所以在協議上多數都採用Http， 接口的設計上則都傾向於REST風格；對於用戶鑑權的Token機制上一般都是採用一個公私鑰的匹配方式，而且此Token必定是由開放平臺公司所提供； 開放平臺中是確定會對接入方的QoS有限制的，而且這一般也影響到了開放平臺的收費標準，在實現時多數採用基於緩存進行實時費用計算，這點更強的應該是電 信行業。0 p9 ~  T! _/ l7 E/ `$ p: m( a
王速瑜：跨IDC部署程序模塊在業務發展到必定階段後在所不免，跨IDC的專線資源相對有限。架構師該如何合理規劃和使用同城、跨城的專線進行傳輸數據，以及專線意外中斷的容災措施？& d) L) s1 W9 v! |
林昊：跨IDC部署確實會存在很高的技術難度，部署結果的驗證是最爲關鍵的地方，其次是部署所耗費的帶寬成本和 時間成本，對於部署結果驗證而言，一般可採用的方法爲業務腳本的測試；對於部署所耗費的帶寬成本而言，一般須要藉助多播技術，對於時間成本而言，一般須要 藉助自動化的部署系統。
0 i4 j+ M  D. C' D0 o王速瑜：Web2.0網站的海量小文件的存儲，如用戶頭像、相冊微縮圖等文件，這些文件的特色是尺寸小（100KB之內），數量巨大（數以百萬計），這些文件的存儲、讀取、備份都是問題，請問您是如何提供具體解決方案的？
0 v" }9 R$ U1 \" w8 h( ?7 P林昊：目前互聯網公司，例如Google、優酷等，對於小文件或大文件的存儲都有本身的一套解決方案，而並不會 去依賴高端的存儲設備來解決。一方面是成本問題，另一方面是伸縮問題，所以對於這些文件的存儲、讀取和備份多數都採用了相似GFS的方案或直接採用 Hadoop提供的HDFS方案。
0 {5 I4 y6 Y0 G/ x9 s王速瑜：互聯網產品部署是一個很關鍵的環節，不少互聯網公司依然採起手工部署發佈產品版本的方式，可是這種方式 比較複雜並且低效，每每很容易出錯，若是同時發佈幾個產品時，若是產品之間關聯比較緊密，其中一個發佈出錯就會影響到其餘的發佈，請問做爲架構師，您在日 常工做中是如何解決這樣的問題？您的團隊中是否考慮自動化動態部署，具體方案是怎麼樣的？
+ I0 \  B% e8 ^# u, n4 `林昊：在部署這個問題上，目前好像只有國外的幾家互聯網公司作的不錯，其中最典型的是eBay。eBay在不少 年前就已經作了一套自動化部署系統，在這套系統中，eBay能夠將一次發佈中的幾個產品進行依賴關係的分析，從而決定其發佈順序，並可實現自動的發佈、校 驗和回滾，這套系統相信也是如今中國幾家互聯網公司都在追求的目標。
$ Z) Q5 R! S; g6 M王速瑜：做爲互聯網技術架構師，您能簡單總結一下海里互聯網服務技術架構方面的理念、原則，方法嗎？
4 o; _4 ]9 X  C' L0 u7 }8 h; u林昊：我以爲eBay的五點總結基本已經夠全面：
( g6 e- k. B4 ~（1）「 拆分」，數據庫的拆分以及應用的拆分，固然這須要強大的技術的支撐，這點要作到的目標一般是便於應用的無限水平伸縮；7 u( r( S, K  k; [
（2）能異步就異步，這須要業務的容許；/ M! \; h) G0 G8 U& T* k3 Q
（3）能自動就自動，就像自動化的部署系統；8 L0 X# q: d* T/ v
（4）記住全部失敗的事情，這點很是重要；
: h, H/ U8 A# q( x: ]( }" P( d8 w（5）容忍不一致性，這句話的含義是儘可能少用強事務，而是採用最終一致性這類方案。3 x1 R. ^# z( C: {, C
固然，除了上面這五點以外，還有像多用緩存、自行實現關鍵技術（以控制穩定性、性能和作到及時響應）等。1 d. ~" x. ?4 g2 ~# t+ c9 |
王速瑜：有不少優秀的軟件架構師能力很強，可是因爲缺少海量服務技術應用和實踐的機會，不能很好地進行海量服務應用的架構設計，您能給他們一些寶貴建議，分享一下您是如何不斷學習成長起來的？您有哪些提升技術視野的方法和途徑，好比有哪些書籍能夠推薦，哪些優秀的網站能夠推薦？, o) H9 ^! S/ g1 G9 _8 y
林昊：這個問題提到點子上了，不少架構師不知道如何應對大型、高併發的場景，最主要的緣由是沒有這樣的實踐的機 會，畢竟目前只有在大型企業系統或互聯網才能得到這類可貴的實踐機會，一般在沒有實踐機會的狀況下是很難徹底理解這些技術的。多數狀況下，互聯網中的技術 方案都是在屢次血淚宕機下成長起來的，建議只能是多看各類互聯網技術介紹的文章，例如Google共享了不少，還有網上也有不少各家互聯網公司技術架構文 章的介紹，尤爲是那類技術發展歷程的介紹，能夠設想下若是本身碰到這樣的問題，會如何去解決，也許這樣能慢慢掌握和理解大型、高併發系統的解決方案。書籍 方面目前國內各類高性能方面的書也開始不斷冒出了，例若有《MySQL性能調優與架構設計》、《構建高性能的Web站點》、《構建Oracle高可用環 境》等，這些高性能的書一般都來源於做者親身的經驗，是很是值得學習的；另外要知道：若是想作到高性能，一般意味着要對軟件（包括OS等）以及硬件技術都 有充分的掌握，所以像《深刻理解JDK》、《深刻理解Linux內核》、《深刻理解計算機系統》這些書也是很是值得一看的。至於網站方面，像http://highscalability.com/、http://www.javaperformancetuning.com/這些都是很是不錯的網站。
* I5 N' _$ R' N1 a! n