【轉(zhuǎn)】王速瑜和我參加架構(gòu)師接龍的對話

          架構(gòu)師接龍是《程序員》雜志最近推出的一個活動,活動方式為:每期一個提問嘉賓,一個回答嘉賓,并由回答嘉賓提出新的問題給下期的架構(gòu)師,形成接龍,之前第一期是支付寶的馮大輝提問,騰訊的研發(fā)總監(jiān)王速瑜回答,我參與的是第二期,這期會登在《程序員》0909期上,內(nèi)容轉(zhuǎn)帖如下,原帖為程序員官方上的:http://www.programmer.com.cn/727/,呵呵,都只是個人的片面理解做出的回答,也歡迎大家在此帖中繼續(xù)討論,:)

          王速瑜:數(shù)據(jù)集群問題:當(dāng)數(shù)據(jù)增長到一定的數(shù)量級,必須要進(jìn)行分布部署、備份、容災(zāi)、切割擴(kuò)容等工作。請問什么程度的數(shù)量級需要分布部署,如何合理分布部署,需要考慮哪些情況?

          林昊:一般來說,也沒有固定的數(shù)量級,通常是根據(jù)硬件資源的狀況以及所能接受的性能狀況(例如一次查詢必須在3ms內(nèi)完成)來決定。當(dāng)達(dá)到性能瓶頸時,通常需要進(jìn)行數(shù)據(jù)的拆分或備份等策略,在這個過程中最需要考慮的,就是對應(yīng)用的影響程度,因此通常會需要一個強(qiáng)大、透明的數(shù)據(jù)層,以屏蔽數(shù)據(jù)的拆分或備份、遷移操作給應(yīng)用帶來的影響,另外一方面就是應(yīng)盡量能做到不停機(jī)完成。當(dāng)然,這很難,因?yàn)樾枰鎸Χ嗵讛?shù)據(jù)結(jié)構(gòu)并存、數(shù)據(jù)冗余和同步等問題。

          王速瑜:數(shù)據(jù)備份問題:對于大容量的數(shù)據(jù)備份,技術(shù)上如何做到不影響正常的服務(wù)?如何合理制定冷備、熱備的實(shí)施策略、方式、時間段?在數(shù)據(jù)損壞、主服務(wù)器硬件損壞等故障情況下,如何最短時間內(nèi)監(jiān)控到故障并調(diào)度請求到備份服務(wù)器等容災(zāi)措施?

          林昊:對于大容量的數(shù)據(jù)備份,技術(shù)上來說:多數(shù)情況下比較好的是選擇異步消息通知實(shí)現(xiàn)數(shù)據(jù)備份,或基于高端數(shù)據(jù)庫的特性(例如Oracle的Standby)。對于冷備、熱備的實(shí)施,原則要求均為不影響正常業(yè)務(wù)功能,因此可選的時段只能是系統(tǒng)訪問量較低的時段。方式則需要根據(jù)數(shù)據(jù)量以及備份的速度來決定,多數(shù)均為采取相對高頻率的進(jìn)行熱備,低頻率的進(jìn)行冷備;在數(shù)據(jù)損壞、主服務(wù)器硬件損壞等故障時,要做到盡快切換,就必須依賴強(qiáng)大的及時監(jiān)控系統(tǒng),在主服務(wù)器不可用時能夠做到迅速報警。最理想狀況就是能夠有一種機(jī)制,自動切換備庫為主庫,并通知所有應(yīng)用轉(zhuǎn)換為連接和使用新的主庫,如果做不到自動的話,這個過程就仍然得基于“人肉”來進(jìn)行操作了。

          王速瑜:開放平臺設(shè)計(jì)問題:開放平臺API設(shè)計(jì)中,調(diào)用協(xié)議設(shè)計(jì)時有哪些考慮要求?對于請求類的調(diào)用協(xié)議設(shè)計(jì),傾向于call?A=a&B=b這種方式(這種方式對調(diào)用者比較方便,但對二進(jìn)制的傳輸有一定限制,比如上傳圖片等),還是基于純文本的方式,比如WSDL、XML等?對用戶鑒權(quán)的Token機(jī)制是怎樣的?有沒有對接入方進(jìn)行QoS的考慮,是怎么做的?

          林昊:對于開放平臺而言,基本上目前Facebook引領(lǐng)了開放平臺的技術(shù),因此在協(xié)議上多數(shù)都采用Http,接口的設(shè)計(jì)上則都傾向于REST風(fēng)格;對于用戶鑒權(quán)的Token機(jī)制上通常都是采用一個公私鑰的匹配方式,并且此Token一定是由開放平臺公司所提供;開放平臺中是肯定會對接入方的QoS有限制的,并且這通常也影響到了開放平臺的收費(fèi)標(biāo)準(zhǔn),在實(shí)現(xiàn)時多數(shù)采用基于緩存進(jìn)行實(shí)時費(fèi)用計(jì)算,這點(diǎn)更強(qiáng)的應(yīng)該是電信行業(yè)。

          王速瑜:跨IDC部署程序模塊在業(yè)務(wù)發(fā)展到一定階段后在所難免,跨IDC的專線資源相對有限。架構(gòu)師該如何合理規(guī)劃和使用同城、跨城的專線進(jìn)行傳輸數(shù)據(jù),以及專線意外中斷的容災(zāi)措施?

          林昊:跨IDC部署確實(shí)會存在很高的技術(shù)難度,部署結(jié)果的驗(yàn)證是最為關(guān)鍵的地方,其次是部署所耗費(fèi)的帶寬成本和時間成本,對于部署結(jié)果驗(yàn)證而言,通??刹捎玫姆椒闃I(yè)務(wù)腳本的測試;對于部署所耗費(fèi)的帶寬成本而言,通常需要借助多播技術(shù),對于時間成本而言,通常需要借助自動化的部署系統(tǒng)。

          王速瑜:Web2.0網(wǎng)站的海量小文件的存儲,如用戶頭像、相冊微縮圖等文件,這些文件的特點(diǎn)是尺寸小(100KB以內(nèi)),數(shù)量巨大(數(shù)以百萬計(jì)),這些文件的存儲、讀取、備份都是問題,請問您是如何提供具體解決方案的?

          林昊:目前互聯(lián)網(wǎng)公司,例如Google、優(yōu)酷等,對于小文件或大文件的存儲都有自己的一套解決方案,而并不會去依賴高端的存儲設(shè)備來解決。一方面是成本問題,另外一方面是伸縮問題,因此對于這些文件的存儲、讀取和備份多數(shù)都采用了類似GFS的方案或直接采用Hadoop提供的HDFS方案。

          王速瑜:互聯(lián)網(wǎng)產(chǎn)品部署是一個很關(guān)鍵的環(huán)節(jié),很多互聯(lián)網(wǎng)公司依然采取手工部署發(fā)布產(chǎn)品版本的方式,但是這種方式比較復(fù)雜而且低效,往往很容易出錯,如果同時發(fā)布幾個產(chǎn)品時,如果產(chǎn)品之間關(guān)聯(lián)比較緊密,其中一個發(fā)布出錯就會影響到其他的發(fā)布,請問作為架構(gòu)師,您在日常工作中是如何解決這樣的問題?您的團(tuán)隊(duì)中是否考慮自動化動態(tài)部署,具體方案是怎么樣的?

          林昊:在部署這個問題上,目前好像只有國外的幾家互聯(lián)網(wǎng)公司做的不錯,其中最典型的是eBay。eBay在很多年前就已經(jīng)做了一套自動化部署系統(tǒng),在這套系統(tǒng)中,eBay可以將一次發(fā)布中的幾個產(chǎn)品進(jìn)行依賴關(guān)系的分析,從而決定其發(fā)布順序,并可實(shí)現(xiàn)自動的發(fā)布、校驗(yàn)和回滾,這套系統(tǒng)相信也是現(xiàn)在中國幾家互聯(lián)網(wǎng)公司都在追求的目標(biāo)。

          王速瑜:作為互聯(lián)網(wǎng)技術(shù)架構(gòu)師,您能簡單總結(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)能自動就自動,就像自動化的部署系統(tǒng);

          (4)記住所有失敗的事情,這點(diǎn)非常重要;

          (5)容忍不一致性,這句話的含義是盡量少用強(qiáng)事務(wù),而是采用最終一致性這類方案。

          當(dāng)然,除了上面這五點(diǎn)之外,還有像多用緩存、自行實(shí)現(xiàn)關(guān)鍵技術(shù)(以控制穩(wěn)定性、性能和做到及時響應(yīng))等。

          王速瑜:有很多優(yōu)秀的軟件架構(gòu)師能力很強(qiáng),但是由于缺乏海量服務(wù)技術(shù)應(yīng)用和實(shí)踐的機(jī)會,不能很好地進(jìn)行海量服務(wù)應(yīng)用的架構(gòu)設(shè)計(jì),您能給他們一些寶貴建議,分享一下您是如何不斷學(xué)習(xí)成長起來的?您有哪些提高技術(shù)視野的方法和途徑,比如有哪些書籍可以推薦,哪些優(yōu)秀的網(wǎng)站可以推薦?

          林昊:這個問題提到點(diǎn)子上了,很多架構(gòu)師不知道如何應(yīng)對大型、高并發(fā)的場景,最主要的原因是沒有這樣的實(shí)踐的機(jī)會,畢竟目前只有在大型企業(yè)系統(tǒng)或互聯(lián)網(wǎng)才能獲得這類難得的實(shí)踐機(jī)會,通常在沒有實(shí)踐機(jī)會的情況下是很難完全理解這些技術(shù)的。多數(shù)情況下,互聯(lián)網(wǎng)中的技術(shù)方案都是在多次血淚宕機(jī)下成長起來的,建議只能是多看各種互聯(lián)網(wǎng)技術(shù)介紹的文章,例如Google共享了很多,還有網(wǎng)上也有很多各家互聯(lián)網(wǎng)公司技術(shù)架構(gòu)文章的介紹,尤其是那類技術(shù)發(fā)展歷程的介紹,可以設(shè)想下如果自己碰到這樣的問題,會如何去解決,也許這樣能慢慢掌握和理解大型、高并發(fā)系統(tǒng)的解決方案。書籍方面目前國內(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í)的;另外要知道:如果想做到高性能,通常意味著要對軟件(包括OS等)以及硬件技術(shù)都有充分的掌握,因此像《深入理解JDK》、《深入理解Linux內(nèi)核》、《深入理解計(jì)算機(jī)系統(tǒng)》這些書也是非常值得一看的。至于網(wǎng)站方面,像http://highscalability.com/、http://www.javaperformancetuning.com/這些都是非常不錯的網(wǎng)站。

          posted on 2009-09-06 11:52 BlueDavy 閱讀(6460) 評論(6)  編輯  收藏 所屬分類: Internet

          評論

          # re: 【轉(zhuǎn)】王速瑜和我參加架構(gòu)師接龍的對話 2009-09-06 16:59 zhong

          不愧是架構(gòu)師,領(lǐng)域知識很全面
          對于小文件存儲的解決方案一直很好奇,用gfs肯定不行的  回復(fù)  更多評論   

          # re: 【轉(zhuǎn)】王速瑜和我參加架構(gòu)師接龍的對話 2009-09-09 09:19 xiaoleigood

          在網(wǎng)上 搜索了一陣子 也沒有搜到 <深入理解JDK> 這本書 是英文書么 lz 介紹一下
            回復(fù)  更多評論   

          # re: 【轉(zhuǎn)】王速瑜和我參加架構(gòu)師接龍的對話 2009-09-09 09:22 xiaoleigood

          《深入理解Linux內(nèi)核》、《深入理解計(jì)算機(jī)系統(tǒng)》 這2本書都找到了 唯獨(dú)沒有找到 <深入理解JDK> 這本書 是英文書么

          一直想更深入的了解 這方面的知識 請樓主指點(diǎn)一下 如何找到這本書

          謝了 先   回復(fù)  更多評論   

          # re: 【轉(zhuǎn)】王速瑜和我參加架構(gòu)師接龍的對話 2009-09-09 09:33 BlueDavy

          @xiaoleigood
          ...寫錯了,有《深入淺出JDK》這樣的書,還有就是《深入Java虛擬機(jī)》
            回復(fù)  更多評論   

          # re: 【轉(zhuǎn)】王速瑜和我參加架構(gòu)師接龍的對話 2009-09-09 10:26 xiaoleigood

          謝謝

            回復(fù)  更多評論   

          # re: 【轉(zhuǎn)】王速瑜和我參加架構(gòu)師接龍的對話 2010-08-08 00:19 wzju64676266

          @zhong
          這個當(dāng)然不會局限于用GFS,公司也可以針對小圖片、海量存儲設(shè)計(jì)出一種方案,HDFS GFS只是一種思想  回復(fù)  更多評論   

          公告

           









          feedsky
          抓蝦
          google reader
          鮮果

          導(dǎo)航

          <2009年9月>
          303112345
          6789101112
          13141516171819
          20212223242526
          27282930123
          45678910

          統(tǒng)計(jì)

          隨筆分類

          隨筆檔案

          文章檔案

          Blogger's

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 陆河县| 体育| 朝阳区| 建昌县| 赤城县| 离岛区| 北流市| 墨玉县| 当涂县| 青川县| 台东县| 达拉特旗| 五大连池市| 杨浦区| 汨罗市| 毕节市| 南澳县| 沂水县| 沭阳县| 虎林市| 福安市| 莱阳市| 馆陶县| 加查县| 鹤岗市| 涞水县| 五莲县| 门源| 娄底市| 定日县| 安庆市| 江北区| 台南县| 安仁县| 五峰| 邢台县| 孙吴县| 大同市| 翁源县| 宜州市| 宾阳县|