Dev和Ops所面臨的挑戰(zhàn)

在現(xiàn)實(shí)中，雖然很多企業(yè)都用上了新技術(shù)高科技，但很多時候，開發(fā)團(tuán)隊(duì)和營運(yùn)團(tuán)隊(duì)總不免或多或少出現(xiàn)貌合神離的情況。盡管商業(yè)目標(biāo)的實(shí)現(xiàn)與否是兩個團(tuán)隊(duì)最大的驅(qū)動力，但說到底術(shù)業(yè)有專攻，雙方有側(cè)重。特別是在當(dāng)今這個軟件為王的世界。

開發(fā)團(tuán)隊(duì)面對的挑戰(zhàn)：

• 延展性：我該如何進(jìn)行系統(tǒng)架構(gòu)，來保證在100臺機(jī)器上的運(yùn)作表現(xiàn)等同于僅1臺機(jī)器上運(yùn)作？
• 性能表現(xiàn)：我該如何做才能確保系統(tǒng)表現(xiàn)與既定的服務(wù)級別協(xié)議相一致。
• 性能測試：我該如何設(shè)計(jì)，才能使得開發(fā)者能更輕松地進(jìn)行單元測試，同時與QA環(huán)節(jié)無縫接合？
• 外延性：我該如何選擇設(shè)計(jì)模式使得系統(tǒng)能滿足不斷變化的商業(yè)目標(biāo)？
• 問題診斷：怎么做才能快速進(jìn)行問題定位，找出根本原因并進(jìn)行有效處理？
• 發(fā)布環(huán)節(jié)：怎么做才能快速進(jìn)行程序的更新?lián)Q代并最終成功發(fā)布？
• 代碼質(zhì)量：該如何進(jìn)行開發(fā)和測試把代碼缺漏的影響降到最低？

營運(yùn)團(tuán)隊(duì)面對的挑戰(zhàn)：

• 可靠性：所有應(yīng)用都運(yùn)作正常嗎？應(yīng)該采取何種戰(zhàn)略把運(yùn)行中斷的影響降到最低？
• 壓力管理：如何合理分配資源來滿足當(dāng)前的營運(yùn)負(fù)荷？又該如何動態(tài)變更環(huán)境配置來處理峰值滿載情況？
• 系統(tǒng)診斷：當(dāng)多個虛擬機(jī)運(yùn)行在同一機(jī)器上，一旦出現(xiàn)問題，該如何進(jìn)行處理？
• 監(jiān)控：我需要時刻關(guān)注系統(tǒng)運(yùn)作良好與否。
• 成本管理：我們在盡量降低成本的同時還要保證營運(yùn)質(zhì)量。
• 服務(wù)級別協(xié)議：對協(xié)議里面的各項(xiàng)指標(biāo)，我們必須進(jìn)行監(jiān)控，管理和維護(hù)。

不難看出，開發(fā)部和營運(yùn)部其實(shí)有著共同的目標(biāo)：不斷進(jìn)行改良，使企業(yè)效益最大化。但誠如現(xiàn)實(shí)中的一個段子：當(dāng)來自金星的開發(fā)部碰上來自火星的營運(yùn)部，會經(jīng)常發(fā)現(xiàn)大家都不在服務(wù)區(qū)，無法溝通。那么該如何做，才能使這兩個企業(yè)的左膀右臂得以和諧共存？

程序延展性 ― 這是每個開發(fā)者都盼望營運(yùn)者所應(yīng)該了解的

開發(fā)者心聲：

我們需要花費(fèi)好幾個月甚至好幾年的功夫才能開發(fā)出一個完整程序。我們費(fèi)盡心思地去選擇正確的設(shè)計(jì)模式，不厭其煩地優(yōu)化自己的代碼，盡最大努力保證質(zhì)量。當(dāng)我們再次回到代碼行間中奮筆疾書前，衷心希望營運(yùn)部能從以下幾方面來好好對待我們的杰作。

首先，希望營運(yùn)部能站在我們的角度來考慮問題。這次要談的是程序延展性問題。

系統(tǒng)性能與延展性：恰如硬幣的正反面

有時候人們會把性能和延展性混為一談，但實(shí)際上兩者是如正負(fù)極那樣有所區(qū)別的。系統(tǒng)性能所關(guān)心的是：例如，程序的響應(yīng)時間是多少？要花費(fèi)多少CPU開銷來進(jìn)行一次請求應(yīng)答？

另一方面，延展性所關(guān)心的是：當(dāng)負(fù)載增加時，系統(tǒng)還能運(yùn)作正常嗎？比方說，經(jīng)測量我們知道響應(yīng)一次請求的時間是1s，延展性就需要關(guān)系當(dāng)100或1000次請求發(fā)生時，這個并發(fā)響應(yīng)時間是多少s。如果1000次的響應(yīng)時間都接近1s，那么這個系統(tǒng)的延展性是良好的；但如果響應(yīng)時間隨著請求的遞增而直線遞增，那么這樣的表現(xiàn)是……這樣的經(jīng)歷，大家應(yīng)該不會陌生吧。

要構(gòu)架一個可擴(kuò)展的程序不是件輕易的事情，但有幾個核心原則能為成功之路做好鋪墊。第一也是最重要的，盡最大努力保持程序的狀態(tài)無關(guān)性，即程序不會在各個請求切換之間進(jìn)行用戶狀態(tài)記錄。當(dāng)一個部件處于狀態(tài)無關(guān)時，無論哪一個部件實(shí)例被調(diào)用，他們的作用都是相同的。這樣的好處是不論在100臺還是僅僅在1臺機(jī)器上運(yùn)行，無需復(fù)雜的設(shè)置，程序都能運(yùn)作良好。這是個宏偉的目標(biāo)，如果你能正確解構(gòu)程序，你的程序或許就會呈現(xiàn)最大的狀態(tài)無關(guān)性。

但是，用戶狀態(tài)有時候是需要被記錄的。例如：當(dāng)你登入一個網(wǎng)站時，網(wǎng)站需要記錄你的信息來區(qū)分不同訪客。一旦你的狀態(tài)被記錄，你隨后的相關(guān)訪問信息都會被一同記錄下來。

在這種情況下，我們應(yīng)該確保“粘性會話”在負(fù)載平衡器中被開啟，意思是一旦會話被建立，所有及后的請求都應(yīng)該附著到同一臺機(jī)器中進(jìn)行記錄。這樣做的好處是后續(xù)請求能夠清楚知道用戶的狀態(tài)，他是誰和他正在做什么；反過來，倘若分而處之，那么必須把會話復(fù)寫到不同服務(wù)器，才能讓所有機(jī)器都知道用戶的狀態(tài)了。

然而，粘性有可能受制于系統(tǒng)彈性。假如負(fù)責(zé)收集請求的機(jī)器宕機(jī)了，那該怎么辦？假如這需要勞煩用戶再次登錄，那對用戶體驗(yàn)無疑是一次不小的打擊。有些策略是能夠幫助增強(qiáng)程序彈性的，不同策略對延展性的影響各有不同，有些影響是舉足輕重的。這些策略包括：

• 會話復(fù)制（主要的/次要的或者更多）；
• 數(shù)據(jù)庫搜索；
• 數(shù)據(jù)存儲共享；
• 富Cookies；
• Terracotta服務(wù)器陣列；
• 分布式緩存。

會話復(fù)制

會話復(fù)制是最常見的彈性措施。在這個模型中，當(dāng)一個用戶會話發(fā)生改變時，會話對象會被序列化，然后發(fā)送到一個或多個次服務(wù)器。一旦服務(wù)器出現(xiàn)宕機(jī)，負(fù)載平衡器會把當(dāng)前負(fù)載重定向到次服務(wù)器。在一個簡單的模型中，每個主服務(wù)器都會配備一個次服務(wù)器，這樣便可以處理更多突發(fā)中斷情況。但是一旦主次服務(wù)器同時中斷，用戶會話便也跟著丟失了。所以建議有條件的話，還是配備多個次服務(wù)器，雖然這可能會造成額外的工作量。

舉例來說，當(dāng)你把數(shù)據(jù)復(fù)制到五個服務(wù)器時，對于每一次變更，你都需要把會話序列化，然后交叉發(fā)送到這些服務(wù)器。這樣便大大降低了系統(tǒng)延展性，因?yàn)樾枰~外的資源開銷來管理復(fù)制機(jī)。在這個情況下，我們需要營運(yùn)部注意這些故障轉(zhuǎn)移規(guī)則，來協(xié)助進(jìn)行必要服務(wù)器的管理。再者，我們不希望這些服務(wù)器是可變的(動態(tài)變更規(guī)模來滿足負(fù)載要求)，因?yàn)樵谝淮尉_的戰(zhàn)略性服務(wù)器關(guān)閉措施中，需要確保會話數(shù)據(jù)不會被丟失。

下期預(yù)告：在下一篇系列文中，我們會繼續(xù)探究數(shù)據(jù)庫搜索和文件存儲會話的復(fù)制，cookies的使用以及Terracotta服務(wù)器陣列或分布式緩存。

英文出自：vmturbo

生活不易，碼農(nóng)辛苦
如果您覺得本網(wǎng)站對您的學(xué)習(xí)有所幫助,可以手機(jī)掃描二維碼進(jìn)行捐贈