林昊，網名BlueDavy，China OSGi User Group Director，淘寶網 平台 架構部架構師，個人的研究方向主要為 Java模組化、動態化 系統 的構建以及高效能的大型分布式Java系統的構建。曾編寫《OSGi實戰》和《OSGi進階》兩篇Opendoc，為OSGi 在 中國 的推廣起到了很大的作用。 1 U: @% ~8 @* M2 \7 @4 L7 G
王速瑜： 資料 叢集問題：當資料增長到一定的數量級，必須要進行分布部署、備份、容災、切割擴容等工作。請問什麼程度的數量級需要分布部署，如何合理分布部署，需要考慮哪些情況。
林昊： 一般來說，也沒有固定的數量級，通常是根據硬體資源的狀況以及所能接受的效能狀況（例如一次查詢必須在 3ms內完成）來決定。當達到效能瓶頸時，通常需要進行資料的拆分或備份等策略，在這個過程中最需要考慮的，就是對 應用 的影響程度，因此通常會需要一個強 大、透明的資料層，以屏蔽資料的拆分或備份、遷移操作給應用帶來的影響，另外一方面就是應盡量能做到不停機完成。當然，這很難，因為需要面對多套資料結構 並存、資料冗餘和同步等問題。
王速瑜： 資料備份問題：對於大容量的資料備份， 技術 上如何做到不影響正常的 服務 。如何合理制定冷備、熱備的實施策略、方式、 時間 段。在資料損毀、主 伺服器 硬體損壞等故障情況下，如何最短時間內監控到故障並調度請求到備份伺服器等容災措施。
林昊： 對於大容量的資料備份，技術上來說：多數情況下比較好的是選擇非同步訊息通知實現資料備份，或基於高端資料 庫的特性（例如 Oracle 的Standby）。對於冷備、熱備的實施，原則要求均為不影響正常業務 功能 ，因此可選的時段只能是系統訪問量較低的時段。方 式則需要根據資料量以及備份的速度來決定，多數均為採取相對高頻率的進行熱備，低頻率的進行冷備；在資料損毀、主伺服器硬體損壞等故障時，要做到儘快切 換，就必須依賴強大的及時監控系統，在主伺服器不可用時能夠做到迅速警示。最理想狀況就是能夠有一種機制，自動切換備庫為主庫，並通知所有應用轉換為串連 和使用新的主庫，如果做不到自動的話，這個過程就仍然得基於“人肉”來進行操作了。
王速瑜： 開放平台設計問題：開放平台 API 設計中，調用協議設計時有哪些考慮要求。對於請求類的調用協議設計， 傾向於call?A=a&B=b這種方式（這種方式對調用者比較方便，但對二進位的傳輸有一定限制，比如上傳圖片等），還是基於純文字的方式，比 如WSDL、XML等。對使用者鑒權的Token機制是怎樣的。有沒有對接入方進行QoS的考慮，是怎麼做的?
林昊： 對於開放平台而言，基本上目前Facebook引領了開放平台的技術，因此在協議上多數都採用Http， 介面的設計上則都傾向於REST風格；對於使用者鑒權的Token機制上通常都是採用一個公私密金鑰的匹配方式，並且此Token一定是由開放平台公司所提供； 開放平台中是肯定會對接入方的QoS有限制的，並且這通常也影響到了開放平台的收費標準，在實現時多數採用基於緩衝進行即時費用計算，這點更強的應該是電 信行業。 0 p9 ~ T! _/ l7 E/ `$ p: m( a
王速瑜： 跨 IDC 部署 程式 模組在業務發展到一定階段後在所難免，跨IDC的專線資源相對有限。架構師該如何合理規劃和使用同城、跨城的專線進行傳輸資料，以及專線意外中斷的容災措施。 & d) L) s1 W9 v! |
林昊： 跨IDC部署確實會存在很高的技術難度，部署結果的驗證是最為關鍵的地方，其次是部署所耗費的頻寬成本和 時間成本，對於部署結果驗證而言，通常可採用的方法為業務指令碼的測試；對於部署所耗費的頻寬成本而言，通常需要藉助多播技術，對於時間成本而言，通常需要 藉助自動化的部署系統。
王速瑜： Web2.0網站的海量小 檔案 的儲存，如帳戶圖片、相簿微縮圖等檔案，這些檔案的特點是尺寸小（100KB以內），數量巨大（數以百萬計），這些檔案的儲存、讀取、備份都是問題，請問您是如何提供具體 解決 方案 的。
林昊： 目前 互連網 公司，例如Google、優酷等，對於小檔案或大檔案的儲存都有自己的一套解決方案，而並不會 去依賴高端的存放裝置來解決。一方面是成本問題，另外一方面是伸縮問題，因此對於這些檔案的儲存、讀取和備份多數都採用了類似GFS的方案或直接採用 Hadoop提供的HDFS方案。
王速瑜： 互連網產品部署是一個很關鍵的環節，很多互連網公司依然採取手工部署發布產品版本的方式，但是這種方式 比較複雜而且低效，往往很容易出錯，如果同時發布幾個產品時，如果產品之間關聯比較緊密，其中一個發布出錯就會影響到其他的發布，請問作為架構師，您在日 常工作中是如何解決這樣的問題。您的團隊中是否考慮自動化動態部署，具體方案是怎麼樣的。
林昊： 在部署這個問題上，目前好像只有國外的幾家互連網公司做的不錯，其中最典型的是eBay。eBay在很多 年前就已經做了一套自動化部署系統，在這套系統中，eBay可以將一次發布中的幾個產品進行依賴關係的分析，從而決定其發布順序，並可實現自動的發布、校 驗和復原，這套系統相信也是現在中國幾家互連網公司都在追求的目標。
王速瑜： 作為互連網技術架構師，您能簡單總結一下海裡互連網服務技術架構方面的理念、原則，方法嗎。
林昊： 我覺得eBay的五點總結基本已經夠全面：
（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）記住所有失敗的事情，這點非常重要；
（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/這些都是非常不錯的網站。
該博文轉載自http://my.oschina.net/cuilk/blog/13675
