[[344105]]

【51CTO.com快譯】近期嚴重的系統(tǒng)故障使系統(tǒng)彈性和冗余架構(gòu)的重要性成了業(yè)界熱議的話題。雖然業(yè)務連續(xù)性方面的考量不是什么新鮮事，但采用的技術(shù)有所發(fā)展。企業(yè)一度主要配置備用數(shù)據(jù)中心，如今為彈性應用程序和基礎(chǔ)架構(gòu)設(shè)計結(jié)構(gòu)時，它們需要考慮多層。

應用程序和網(wǎng)站不可用時，收入和聲譽將遭殃。但是我們對數(shù)字系統(tǒng)的日益依賴將彈性的定義擴展到了故障和服務中斷之外，還包括性能和應用程序交付——這些同樣重要。如今，最終用戶要求他們使用的應用程序和服務能迅即響應。連延遲數(shù)秒都嫌太久。

希望構(gòu)建并維護彈性應用程序和基礎(chǔ)架構(gòu)的企業(yè)應考慮這七個建議。

基礎(chǔ)架構(gòu)多樣化

雖然一些人可能忍不住想“全力”支持某個云或CDN提供商，但如果該提供商宕機或遇到其他性能問題，這種做法會導致代價高昂的停運。使用兩家或多家供應商實現(xiàn)基礎(chǔ)架構(gòu)多樣化的公司可以使內(nèi)容和處理更接近用戶，從而大幅縮短延遲。如果一家提供商遇到網(wǎng)絡(luò)擁塞、地理限制、資源可用性或其他問題引起的問題，自動故障切換系統(tǒng)可以確保對用戶的影響最小。

考慮實施微服務

微服務和容器等新技術(shù)的出現(xiàn)確保了彈性對于應用程序開發(fā)者來說最重要。由于企業(yè)從物理數(shù)據(jù)中心中運行的整體式應用程序改為廣泛分布的微服務和單個應用程序，它們須盡早解決這些系統(tǒng)彼此如何交互的問題。而冗余性是在微服務的設(shè)計階段內(nèi)置的。這就是為什么已經(jīng)在進行數(shù)字化轉(zhuǎn)型或竭力升級系統(tǒng)的企業(yè)應考慮采用微服務方法。

隨著組織發(fā)展壯大，它們會看到系統(tǒng)的不同部分更早面臨壓力。微服務和整體式應用程序使組織能夠獨立擴展那些特定組件。使用微服務時，由于系統(tǒng)的某些組件，組織可能會看到局部故障，但整體故障很罕見。

將冗余性做入到代碼庫中

企業(yè)可以通過將冗余性做入到代碼中，從軟件開發(fā)的角度做好彈性。一家全球流媒體提供商就使用該方法，如果其中一家云提供商出故障，可以激活自行開發(fā)的系統(tǒng)，以保持在線狀態(tài)。電子商務公司常常采用類似的策略;對這類公司而言，即使停運幾分鐘，也可能導致利潤嚴重損失。Gremlin的混沌工程專家估計，亞馬遜停運10分鐘將使這家電子商務巨頭損失200萬美元的收入。因而，許多電子商務公司常常以這種方式編寫代碼：應用程序在數(shù)據(jù)中心中運行，作為備用/冗余策略的一部分。購物車應用程序在這種環(huán)境下運行起來可能較慢，但速度慢的購物車總比沒有購物車好。

將混沌工程引入實踐

混沌工程是指有意引入問題以識別系統(tǒng)故障點的做法，已成為交付高性能彈性企業(yè)應用程序的一個重要部分。有意將“混沌”引入到受控的生產(chǎn)環(huán)境中可以暴露系統(tǒng)的弱點，并使工程團隊能夠更好地預測并主動緩解問題，以免造成重大的業(yè)務影響。進行計劃中的混沌工程試驗可以提供企業(yè)在系統(tǒng)彈性方面進行戰(zhàn)略性投入所需要的信息。

調(diào)整流量路由策略

公司可以盡量減小停運和延遲的風險，只需實施流量路由策略，將有關(guān)網(wǎng)絡(luò)情況和資源可用性的實時數(shù)據(jù)與真實的用戶測量數(shù)據(jù)結(jié)合起來。這使IT團隊能夠部署新的基礎(chǔ)架構(gòu)，管理資源的使用，以規(guī)避問題或解決意外的流量高峰。比如說，企業(yè)可以結(jié)合流量引導功能，確保始終將用戶引導到擁有足夠容量的附近節(jié)點。因而，保護用戶免受故障和局部網(wǎng)絡(luò)事件的影響，否則這些事件會擾亂業(yè)務運營。流量引導還可以快速啟動新的云實例，在互聯(lián)網(wǎng)長期速度緩慢或無法預測的戰(zhàn)略性地理位置增加容量。另外，團隊可以設(shè)置控制措施，以便在流量激增期間將流量引到低成本資源，或者在持續(xù)大量使用期間以經(jīng)濟有效的方式讓資源在工作負載之間得到均衡使用。

定義SLA并持續(xù)監(jiān)測系統(tǒng)性能

企業(yè)應監(jiān)測其應用程序和系統(tǒng)，事先防范性能波動、故障或其他問題。監(jiān)測應用程序每個部分的運行狀況和響應時間是系統(tǒng)彈性的一個關(guān)鍵方面。比如說，衡量應用程序的API調(diào)用所花的時間或核心數(shù)據(jù)庫的響應時間，可以早早表明即將發(fā)生的情況，并使IT團隊可以事先防范這些障礙。該方法還包括為不同的子應用程序和系統(tǒng)創(chuàng)建服務級別協(xié)議(SLA)，然后監(jiān)測那些 SLA，確保合規(guī)。

從新的系統(tǒng)和應用程序入手

希望為IT堆棧添加彈性的企業(yè)應該在實施對業(yè)務影響不大的新應用程序或服務時開始入手。雖然一些企業(yè)可能忍不住先為核心服務或應用程序添加彈性，但萬一出了岔子，這種做法會導致代價高昂的、破壞性更大的停運。IT員工可以先學習做好新系統(tǒng)的彈性。也許組織在啟動一個新的支持門戶網(wǎng)站。針對該服務測試確保彈性的新方法風險較低，允許出現(xiàn)一些小問題。以后，IT團隊可以將經(jīng)驗運用到其他關(guān)鍵業(yè)務系統(tǒng)和服務。

組織更仔細地研究彈性方法時，必須考慮每種策略的成本與效益。這七個建議需要投入于另外的服務和架構(gòu)，還需要IT團隊投入時間，公司在確定最佳行動方案之前應考慮清楚。不管怎樣，它們應重視彈性，將其視作一個最佳實踐，為其數(shù)字應用程序和服務確保高可用性和最佳性能。這對于確保業(yè)務向前發(fā)展并保持競爭優(yōu)勢很有必要。

原文標題：7 Best Practices to Build and Maintain Resilient Applications and Infrastructure，作者：Kris Beevers

【51CTO譯稿，合作站點轉(zhuǎn)載請注明原文譯者和出處為51CTO.com】