摘要：連接性，傳輸?shù)臄?shù)據(jù)，安全，延遲與性能，客戶端與服務(wù)器間的狀態(tài)同步成為管理系統(tǒng)時(shí)需要考慮的問題。每次進(jìn)化都需要我們打造與管理所需的技術(shù)需要的技術(shù)，系統(tǒng)，技能變化。

By James TurnbullInes Sombra March 20, 2018
https://www.oreilly.com/ideas...

在過去的幾周，我們一直在反饋從我們第一次站在職場時(shí)就在變化的工業(yè)技術(shù)。我們在尋找在兩個(gè)不同的但是重疊領(lǐng)域的變化：技術(shù)的變化與方法學(xué)的變化。我們大部分人第一次接觸的系統(tǒng)是第一代的CS應(yīng)用。它與它的上一代系統(tǒng)有很大不同：其通過控制臺(tái)連接到一個(gè)運(yùn)行在大型機(jī)或中型機(jī)的中心化應(yīng)用。工程師像增強(qiáng)服務(wù)器一樣學(xué)習(xí)它的客戶端邏輯。連接性，傳輸?shù)臄?shù)據(jù)，安全，延遲與性能，客戶端與服務(wù)器間的狀態(tài)同步成為管理系統(tǒng)時(shí)需要考慮的問題。

復(fù)雜性的提高需要其對應(yīng)的管理這些系統(tǒng)的方法與技能的提高。新類型的系統(tǒng)意味著新技能，理解新工具，框架，與編程語言。我們可以發(fā)現(xiàn)現(xiàn)在很多以前集中在一個(gè)角色的技能開始分散：前端工程師，后端工程師，數(shù)據(jù)科學(xué)家，設(shè)計(jì)師，UX/UI專家，還有其他專家。我們可以發(fā)現(xiàn)這個(gè)階段建立了很多孤島功能并且在轉(zhuǎn)換這些孤島間的復(fù)雜性。DevOps與SRE社區(qū)在試圖消滅以上的孤島。

從第一代CS系統(tǒng)，我們可以看到很大的變化。大部分是由于技術(shù)對于做生意至關(guān)重要-對所有行業(yè)的任何生意都是這樣。這與客戶要求快速在不同地理區(qū)域的設(shè)備上部署結(jié)合。舉個(gè)例子，從街角錄像帶店租賃錄像進(jìn)化為在Netflix與Hulu上的流媒體。我們期望分發(fā)內(nèi)容的延遲從小時(shí)或分鐘降低到秒。我們期望內(nèi)容分發(fā)可以24 7 365 天在我們所有地區(qū)的設(shè)備上：從我們的家和辦公室到移動(dòng)中。我們作為客戶，不需要關(guān)心基礎(chǔ)設(shè)施或系統(tǒng)達(dá)到此目的的復(fù)雜性：我們只想看新賽季的比賽。

每次進(jìn)化都需要我們打造與管理所需的技術(shù)需要的技術(shù)，系統(tǒng)，技能變化。在大多數(shù)時(shí)候，這些變化引入了更多的復(fù)雜性：我們曾經(jīng)管理CS系統(tǒng)需要的技能與知識(shí)與現(xiàn)代分布式系統(tǒng)需要的彈性，低延遲，高可用的需求有很大不同。所以，我們需要知道哪些我們之前不知道的呢？

作為從業(yè)者，我們要做得更好。由于可用性與彈性已經(jīng)是主要考慮的問題，應(yīng)用程序的最小可用產(chǎn)品需要被重定義。好的設(shè)計(jì)目標(biāo)現(xiàn)在需要把包括基本的對于運(yùn)維性，安全，性能與可觀察性的架構(gòu)目標(biāo)。每個(gè)工程師，從在React組件上工作的前端工程師到在構(gòu)建一個(gè)分布式數(shù)據(jù)集的后端工程師，需要考慮他們系統(tǒng)的小部分是如何影響整個(gè)系統(tǒng)的。

用戶對性能的需要已經(jīng)對計(jì)算模型與狀態(tài)管理策略產(chǎn)生了新的限制。計(jì)算模型開始轉(zhuǎn)向Serverless與邊緣計(jì)算架構(gòu)，期望能降低用戶延遲。這是我們學(xué)到的新一課：計(jì)算節(jié)點(diǎn)越靠近用戶越有效率。

對于狀態(tài)管理也是這樣。應(yīng)用正在從最開始的分布式狀態(tài)，共享存儲(chǔ)，甚至數(shù)據(jù)遷移從中心存儲(chǔ)向邊緣或云計(jì)算升級。接近最終用戶可以保證更快速的決策，但大大增加我們應(yīng)用的復(fù)雜性。

每一處約束都代表工程師需要理解他們自己維護(hù)的部分與其他部分的變化可能對宏觀系統(tǒng)造成的影響。當(dāng)這些內(nèi)容由于復(fù)雜性或缺乏對系統(tǒng)的深刻理解不能在心里建模掌握時(shí)，就需要用程序的方式來建模，如觀察，插樁，追蹤，測試。

我們現(xiàn)在已經(jīng)不能使用簡單的方式來監(jiān)測故障或使用簡單的方式來調(diào)試故障。復(fù)雜架構(gòu)與分布式的應(yīng)用，看起來很適合用探針，但可能對終端用戶無法實(shí)現(xiàn)良好的性能。就算在觀測事件與指標(biāo)，由于不同系統(tǒng)間的相關(guān)性與平衡性，而且計(jì)算延遲在分布式系統(tǒng)中也不夠精確，我們很難用傳統(tǒng)方式獲得一張全圖。

應(yīng)用的instrumentation在開發(fā)過程中已經(jīng)是一個(gè)必選項(xiàng)而不是一種事后行為了。每個(gè)工程師都需要考慮如何清楚的表示他們系統(tǒng)的狀態(tài)，性能與可觀測性。這需要工程師學(xué)習(xí)與適應(yīng)新技術(shù)來交付這些新的能力。

新的框架，架構(gòu)，過程，一個(gè)成長的工具生態(tài)幫我們完成這些挑戰(zhàn)。他們有些還處于孵化階段，但會(huì)快速變成熟。我們已經(jīng)看到了這種變革：只花了四年容器已經(jīng)成為了主流技術(shù)，并且我們正在致力于使用類似kubernetes工具來支持復(fù)雜應(yīng)用級別的抽象。部署上也有類似的變更正在發(fā)生，serverless，邊緣計(jì)算技術(shù)，安全，性能與系統(tǒng)可觀測性。

最后，沒有變化能存在在人與組織之外。我們需要開發(fā)必須的領(lǐng)導(dǎo)技能去構(gòu)建跨功能團(tuán)隊(duì)，并保證夠構(gòu)建這些系統(tǒng)所需的快速迭代。我們需要繼續(xù)投入在DevOps與SRE社區(qū)來打破估到，無縫改造團(tuán)隊(duì)并提高開發(fā)效率。圍繞快速交付高質(zhì)量，安全與高性能應(yīng)用的團(tuán)隊(duì)組織可以創(chuàng)造高創(chuàng)新性的產(chǎn)品與組織。

對于剛開始或正在路上的組織和行業(yè)從業(yè)者， O"Reilly"s Velocity會(huì)議有一系列計(jì)劃來幫助公司處理這些現(xiàn)代復(fù)雜性。來自于Google，Netflix，Microsoft，Amazon，Twitter，Nordstorm，Slack，F(xiàn)astly的開發(fā)者與工程師會(huì)來分享他們的在構(gòu)建，伸縮，加固分布式系統(tǒng)的成功與失敗的經(jīng)驗(yàn)。你會(huì)有機(jī)會(huì)學(xué)習(xí)，社交，歡笑，并與觀眾和行業(yè)領(lǐng)袖進(jìn)行分享。

本文來自微信公眾號「麥芽面包，id「darkjune_think」
轉(zhuǎn)載請注明。微信掃一掃關(guān)注公眾號。
交流Email: zhukunrong@yeah.net