開幕地址：

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

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

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

從滿到少

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

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

兩個角色的簡單介紹

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

運維工程師肖磊頭腦很硬。他不僅要負責甩鍋，還要負責重啟。他只關心應用服務器的運維。它還負責在服務器宕機時重新啟動服務器。

史前時代

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

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

農業(yè)時代

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

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

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

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

工業(yè)時代

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

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

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

未來并不遙遠

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

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

先看一張圖：

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

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

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

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

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

前端工程師：放棄與后端工程師聯調開發(fā)到BaaS，轉入下層服務，專門支持FaaS進行開發(fā)

運維工程師：容器和基礎架構

有了這樣一個名詞，我突然覺得有些不知所措了，因為我只是一個后端工程師，所以只能簡單談談我對FaaS的理解。

FaaS

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

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

1、用戶通過互聯網訪問地址，觸發(fā)觸發(fā)器

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

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

4、運行函數

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

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

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

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

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

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

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

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

總結

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

核心理論：增值編程

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

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