知名網(wǎng)站的技術(shù)實(shí)現(2)

　　除了避免單點(diǎn)外，降低耦合也是設計高可用性系統時(shí)應考慮的重點(diǎn)，通?？梢圆扇‘惒交瘉?lái)降低耦合，將非關(guān)鍵邏輯和關(guān)鍵邏輯隔離開(kāi)，例如在淘寶上買(mǎi)一件商品，確認購買(mǎi)了后，需要旺旺通知賣(mài)家，如果旺旺通知賣(mài)家這個(gè)過(guò)程是同步通知的話(huà)，對于系統來(lái)說(shuō)無(wú)疑增加了一個(gè)風(fēng)險點(diǎn)，因此可以將旺旺通知賣(mài)家的步驟變?yōu)楫惒降姆绞絹?lái)做，這種場(chǎng)景的異步通常又采用消息中間件來(lái)實(shí)現;還有另外一種場(chǎng)景也經(jīng)常采用異步化的方式來(lái)降低耦合，例如打開(kāi)天貓的商品詳情時(shí)，都會(huì )有相關(guān)商品的推薦，如果這個(gè)推薦系統出問(wèn)題的話(huà)，就會(huì )導致商品詳情也看不到了，因此這里也可以采用異步化來(lái)加載推薦系統，在這種場(chǎng)景中通常采用Ajax帶超時(shí)的方式來(lái)實(shí)現。

　　各網(wǎng)站在總結多年的可用性系統設計的經(jīng)驗時(shí)，有一個(gè)設計原則被所有網(wǎng)站列入：保持簡(jiǎn)單，簡(jiǎn)單的方案意味著(zhù)容易掌控，而復雜的方案一方面意味著(zhù)實(shí)現難度大，另一方面意味著(zhù)出現問(wèn)題時(shí)很難排查。

　　可控性也是各網(wǎng)站強調的重點(diǎn)，可控性就意味著(zhù)一切的代碼都在掌握下，并且最好是每個(gè)使用到的部分都有專(zhuān)業(yè)的人士(對可用性要求越高，在這點(diǎn)上要求也就越高)，這樣才能清楚在出現問(wèn)題的時(shí)候是哪個(gè)地方造成的，并且可以自行排查和解決，如不可控，則意味著(zhù)一旦出現問(wèn)題，就得依賴(lài)第三方來(lái)排查，那這個(gè)時(shí)間就非常不可控了，這也是網(wǎng)站不采用商用軟件的重要原因。

　　編寫(xiě)高質(zhì)量軟件是保障系統高可用性的重要一環(huán)(可控性也是編寫(xiě)高質(zhì)量軟件的基礎)，但軟件幾乎不可能做到0 bug，各網(wǎng)站在總結自己保障高可用的經(jīng)驗中提到了一些策略用于保障系統的高可用，這些策略主要包括：監控/報警、容錯、自我保護、隔離、和降級，需要做到高可用的軟件在交付時(shí)都應具備這些特性。

　　監控/報警是軟件自身能夠保障高可用的重要策略，就像是汽車(chē)的儀表盤(pán)一樣，可以告訴你油還剩多少，速度是多少，胎壓是否正常等重要信息，對于軟件而言，同樣需要讓外部可以獲取到其運行的狀況，例如Google的軟件都會(huì )提供一個(gè)html的頁(yè)面供使用者或開(kāi)發(fā)人員訪(fǎng)問(wèn)(用過(guò)Hadoop的人也會(huì )發(fā)現這個(gè)特征)，在這個(gè)頁(yè)面上可通過(guò)key/value的方式來(lái)獲取系統的一些運行指標，對外RPC的系統Google會(huì )采集所有的正常請求、錯誤請求以及其消耗時(shí)間的分布狀況(>0.05s的，>0.1s等)，除了監控系統的運行狀況外，也需要提供一些方式以便外部能簡(jiǎn)單判斷系統運行是否正常，例如curl某頁(yè)面等，對于不正常的現象要進(jìn)行即時(shí)的報警，以盡可能做到在故障尚未影響到用戶(hù)時(shí)進(jìn)行解決。

　　軟件會(huì )依賴(lài)很多外部的因素，例如機房、硬件、數據庫、服務(wù)等，而所有依賴(lài)的部分都是有可能出現故障的(要堅信這點(diǎn)，互聯(lián)網(wǎng)的特色是所有小概率事件都會(huì )發(fā)生)，在設計軟件時(shí)需要考慮當依賴(lài)方出問(wèn)題時(shí)，如何能保障軟件本身的可用性，因此一定要做一些容錯的處理，例如對于機房故障，各網(wǎng)站通常都會(huì )租用或建設多機房來(lái)避免;又例如Google采用IDE硬盤(pán)來(lái)存儲文件，不做Raid，于是采用了復制三份的策略來(lái)避免硬盤(pán)故障導致數據丟失。

　　軟件通常會(huì )接受外部的輸入，而有些時(shí)候輸入條件的不符合預期可能會(huì )導致軟件的故障，在我們的系統中曾經(jīng)出現的一個(gè)故障案例：某系統對外提供了批量查詢(xún)的功能，結果有一次客戶(hù)端提交了一個(gè)查找10000個(gè)用戶(hù)的批量查詢(xún)，導致系統由于內存不夠出現了故障，因此在設計軟件時(shí)需要保障處理自己能力范圍的請求，對于超出能力的請求可以考慮直接拋錯，還有一種常見(jiàn)的是后端處理變慢導致雪崩效應的故障，這種在軟件上通常會(huì )采用超時(shí)、限流等方式來(lái)避免，對于這些可能出現的故障在設計軟件時(shí)都應考慮采取一些保護的措施來(lái)保護自身的可用性。

　　軟件通常提供了多種功能，這些功能會(huì )有重要的和不重要的，如果由于不重要的功能異常導致重要的功能出現問(wèn)題，顯然是不合算的，因此在設計軟件時(shí)需要充分的考慮異常的隔離，不互相影響，例如在Google的系統設計中會(huì )采用Prioritized Request等策略。

　　降級即為James Hamilton的那篇著(zhù)名的《On Designing and Deploying Internet-Scale Services》論文中提到的Graceful Degradation，降級通常采用的方法是在故障將要出現或出現后，通過(guò)關(guān)閉系統的一些功能來(lái)降低故障產(chǎn)生的影響，例如網(wǎng)站上有些操作可能是特別耗資源的，而這些資源的消耗又可能會(huì )導致影響到核心功能，一旦出現影響時(shí)，就可以通過(guò)關(guān)閉這些功能保障核心功能的可用，降級通常用于臨時(shí)的繞開(kāi)故障，故障的原因則事后排查。

　　交付具備高可用特征的軟件是開(kāi)發(fā)人員的重要職責，而對于一個(gè)網(wǎng)站而言，軟件不是一次性交付的，也不是好幾年才升級一次的，而是頻繁交付的，因此對軟件本身的維護也是保障高可用的重要環(huán)節。

　　通常，系統的不可用是變更造成的，如何降低變更對系統可用性造成的影響，是各網(wǎng)站都關(guān)注的重點(diǎn)，Google在發(fā)布時(shí)通常采取“滾木移石”的方法、Facebook則通常采用Dark launch的方法，以降低變更帶來(lái)的影響。

　　人工來(lái)操作系統的變更是故障產(chǎn)生的隱患，因此各網(wǎng)站基本都會(huì )推薦多種工具來(lái)實(shí)現系統變更的自動(dòng)化，例如采用puppet來(lái)實(shí)現自動(dòng)化的部署。

　　除了發(fā)布這個(gè)重要環(huán)節外，處理故障也是維護的重要工作，系統總是會(huì )有出現故障的時(shí)候的，出現故障時(shí)如何快速的處理來(lái)降低對可用性的影響也成為了網(wǎng)站一直關(guān)注的重點(diǎn)，前文已經(jīng)說(shuō)到可控性對解決故障的幫助，除了可控外，各網(wǎng)站也會(huì )研究一些其他的方法，Facebook就采用了FBAR來(lái)自動(dòng)處理部分故障，這顯然可以一定程度降低故障產(chǎn)生的影響。

　　性能

　　在前文中提到的可控性同樣也是保證性能的重點(diǎn)，只有明確的知道調用的每個(gè)API，依賴(lài)的環(huán)境(包括軟硬件)的細節原理，才能編寫(xiě)出高性能的軟件。

　　從系統結構上來(lái)看，我們可以看到各大網(wǎng)站在發(fā)展到今天的時(shí)候，為了保障高性能都采用了類(lèi)似的方法，首先是前端Web系統這塊，都采用了可編譯為機器碼的方式，例如即使是Facebook采用php，其仍然研發(fā)了一個(gè)可自動(dòng)轉化為C++代碼的產(chǎn)品來(lái)提升運行效率。

　　設計系統時(shí)應考慮將沒(méi)有前后依賴(lài)的邏輯并行化處理，，或者將大的請求進(jìn)行拆分，例如在Google上進(jìn)行搜索，Google會(huì )進(jìn)行分詞，然后并行的進(jìn)行索引的查詢(xún)，從而提高響應速度。

　　基本上各大網(wǎng)站都極度依賴(lài)Cache，這原因很明顯，內存的訪(fǎng)問(wèn)速度遠快于磁盤(pán)，依賴(lài)Cache的場(chǎng)景中最需要做到的是數據一致性的合理保障，一個(gè)典型的場(chǎng)景是數據更新時(shí)保障Cache一致性的策略，Cache的更新和數據的更新如果要做成一個(gè)事務(wù)顯然有不小的難度，此時(shí)網(wǎng)站常采用一個(gè)簡(jiǎn)單策略來(lái)保障，就是先失效Cache，再更新數據，等到下次系統去訪(fǎng)問(wèn)此數據時(shí)，才更新到內存。

原文轉自：http://bluedavy.me/?p=396