開幕地址：

2018年就職于某國企云估算公司。雖然項目在疫情期間被公司隱瞞，但憑借3年的云估算經(jīng)驗，我也學(xué)到了很多關(guān)于云估算的知識。

云計算的愿景——隨著互聯(lián)網(wǎng)的發(fā)展，未來云計算必將成為整個社會和商業(yè)的基礎(chǔ)設(shè)施。那時，使用云計算應(yīng)該像我們今天使用水、電和煤一樣簡單，不知道它們來自哪里。來，不需要關(guān)注運維等相關(guān)知識，用戶只需要關(guān)心業(yè)務(wù)邏輯即可。

這個愿景提到運維，接下來我會講一下服務(wù)器端運維的發(fā)展歷程。

從滿到少

full表示運維都是我們自己負(fù)責(zé)，less表示服務(wù)器端運維少由我負(fù)責(zé)，大部分操作交給手動工具，所以比較具體，我會以一個實際的例子來說明運維從full到less的過程。

如果（別問我是誰~）有一家互聯(lián)網(wǎng)公司，做一個在線筆記項目是很有必要的。為了方便，我將兩個核心職位簡化為兩個角色：研發(fā)工程師肖拓，運維工程師肖磊。

兩個角色的簡單介紹

開發(fā)工程師肖拓是技術(shù)大鱷，精通前后端的全棧工程師。他只需要關(guān)心應(yīng)用程序的業(yè)務(wù)邏輯。在整個MVC架構(gòu)中，從服務(wù)端的View到業(yè)務(wù)邏輯層，再到數(shù)據(jù)存儲的Model層，包括代碼版本管理、bug修復(fù)，都由小程來管理。

運維工程師肖磊頭腦很硬。他不僅要負(fù)責(zé)甩鍋，還要負(fù)責(zé)重啟。他只關(guān)心應(yīng)用服務(wù)器的運維。它還負(fù)責(zé)在服務(wù)器宕機(jī)時重新啟動服務(wù)器。

史前時代

項目跌跌撞撞，終于啟動了。小雷承諾運維包羅萬象。小拓不需要關(guān)心任何部署。小拓每次上線，都要通知小雷最新的代碼。至于小頭，做個版本備份，有問題回滾，也抓個在線日志給小頭解決。

這看起來很棒。業(yè)務(wù)的開發(fā)和運維是完全分離的。一切似乎都是那么美好，但缺點是小雷變成了一個工具人，被各種復(fù)雜的事物所困。自拔不僅沒有提升個人能力，也沒有時間讓小雷深入研究提高運維效率。

農(nóng)業(yè)時代

為了逃避這種重復(fù)性的工作，小雷深思熟慮，每次出現(xiàn)bug，都要給小拓提供日志。我只是一個工具人，為什么不做一個工具，讓他手動刮日志呢？

于是小雷做了一個（操作臺，云廠商有對應(yīng)的產(chǎn)品如Log Easy、Log 等），讓小拓自己讀取日志。小雷的功能上線后，小拓在處理產(chǎn)生bug的時候，就不用讓小雷幫忙拉日志了，小雷的工作就輕松多了。

看來小拓的工作量減少了。雖然想想那些原本是肖拓的工作，但肖磊以前只是個工具人。

嘗過甜頭的小雷，再次陷入了沉思。這提高了效率。是否可以部署、擴(kuò)容、減容、關(guān)機(jī)后重啟？手動？

工業(yè)時代

此時，我們已經(jīng)來到了當(dāng)下的主流時代。現(xiàn)在很多大廠都在這個時代。右圖是我之前監(jiān)督過的天貓后端工程系統(tǒng)DEF。經(jīng)過不斷優(yōu)化，小雷在這個時代，項目應(yīng)該優(yōu)化成什么？

上線前除了對代碼進(jìn)行檢查和預(yù)測試外，還在發(fā)布時做了灰度發(fā)布和手動回滾。一切都是手動的。

可能有人會問，小雷的一連串革命似乎讓他失業(yè)了？

未來并不遙遠(yuǎn)

目前的發(fā)展趨勢，雖然他已經(jīng)做了一些免費的運維工作，小雷并沒有丟掉性命，但他想往下層的方向轉(zhuǎn)變，如何越來越節(jié)省資源？開發(fā)朋友只專注于業(yè)務(wù)，不被運維所迷惑服務(wù)器運維技術(shù)，這將是小雷未來的??方向。

你如何定義你說了多少？在新的less框架模型下，之前的工作職能必須做哪些改變？

先看一張圖：

因為認(rèn)知錯誤，很難看清很多人的大致情況。有這么一句話，當(dāng)你認(rèn)為對方的行為很瘋狂的時候，很可能大家掌握的信息信息很差，我也是。在檢查之前，我仍然無法理解No 是如何成功運行該項目的，真是太神奇了。根本原因是我們用俠義的認(rèn)知來試圖解釋概括。針對這個問題，我也給出兩個推論：俠義和泛化：

第一種：窄（最常見）=架構(gòu)=FaaS架構(gòu)=（風(fēng)暴驅(qū)動）+FaaS（功能即服務(wù)）+BaaS（前端即服務(wù)，持久化或第三方服務(wù)）=FaaS+ BaaS之二：通用化=服務(wù)器端免費運維=有特色的云服務(wù)

把這兩個定義和上圖結(jié)合起來，很容易切入正題，大家可以仔細(xì)看看。

基于新模型，每個位置會發(fā)生哪些變化？

后端工程師：不僅是現(xiàn)有頁面開發(fā)，也是FaaS開發(fā)

前端工程師：放棄與后端工程師聯(lián)調(diào)開發(fā)到BaaS，轉(zhuǎn)入下層服務(wù)，專門支持FaaS進(jìn)行開發(fā)

運維工程師：容器和基礎(chǔ)架構(gòu)

有了這樣一個名詞，我突然覺得有些不知所措了，因為我只是一個后端工程師，所以只能簡單談?wù)勎覍aaS的理解。

FaaS

全名是asa。也就是說，這是云廠商常用的命名方式。 被稱為 XaaS。

該功能由云廠商提供的觸發(fā)器觸發(fā)，它會根據(jù)語言啟動相應(yīng)的環(huán)境，并提供一定的標(biāo)準(zhǔn)上下文，每個觸發(fā)器，提供的上下文都不一樣，我們需要做什么不同的觸發(fā)器下的業(yè)務(wù)邏輯也不同。常見的觸發(fā)器包括http觸發(fā)器、api調(diào)用觸發(fā)器、定時器觸發(fā)器等。FaaS的生命周期如下。

1、用戶通過互聯(lián)網(wǎng)訪問地址，觸發(fā)觸發(fā)器

2、啟動云廠商預(yù)設(shè)的環(huán)境，即函數(shù)執(zhí)行容器

3、初始化運行環(huán)境

4、運行函數(shù)

5、操作結(jié)束后等待一段時間（3-5分鐘），如果期間有電話，返回第4步，但沒有進(jìn)入第6步

6、破壞環(huán)境和函數(shù)。

從這一步可以看出，無論什么函數(shù)和環(huán)境最終都會被破壞，所以FaaS是一個無狀態(tài)函數(shù)，對于后端朋友來說很容易理解，因為我們寫的大部分函數(shù)都是它是無狀態(tài)的，前端的朋友會害怕，沒有感覺缺的數(shù)據(jù)庫。

如果你想存儲數(shù)據(jù)怎么辦？這是 BaaS 層應(yīng)該處理的問題，超出了我們討論的范圍。

為什么 Node 在 FaaS 中如此受歡迎？

本題需要講JIT，JIT即時編譯（英文：Just-in-time），詳情可以看

這有點困難。一般的意思是JS同時編譯和執(zhí)行。與java不同的是，它會在編譯后執(zhí)行。這個特性讓代碼在冷啟動階段跑得更快，但我的理解也有限。這個JIT問題還是比較深的，知乎有對應(yīng)的題目，有興趣的朋友可以去看看。

由于對速度的要求，node 脫穎而出，成為 FaaS 的流行語言。

總結(jié)

說到這里，你應(yīng)該有點了解了。作為后端工程師服務(wù)器運維技術(shù)，我們現(xiàn)在應(yīng)該怎么做？學(xué)習(xí) node 并在 FaaS 環(huán)境中開發(fā)！ ！ ！

核心理論：增值編程

目前的狀態(tài)與三年前一樣，當(dāng)時后端工程被提上日程。去年，在緊迫的招聘市場中，懂工程和工程框架的后端已經(jīng)脫穎而出，擺脫了內(nèi)卷化，拿到了更高的薪水。但是，按照目前的發(fā)展速度，工程相關(guān)的內(nèi)容很快就會被困在內(nèi)卷中。下一個目標(biāo)是什么？就是節(jié)點的學(xué)習(xí)。其實單純使用是不夠的，還要學(xué)會調(diào)整最好的方法，看看一些優(yōu)秀框架的源碼，學(xué)習(xí)FaaS的原理等等。

最后，持續(xù)學(xué)習(xí)是我們降低自身價值的一種手段，我們必須順勢而為才能成功。技術(shù)紅利的機(jī)會不多。如果不抓住之前的工程紅利，那么接下來的 FaaS 技術(shù)紅利就用不上。在錯過之前，花點時間增加價值。