搭配在一起其實就是「更少在意服務端」。
web 應用開發：
在個人pc啟動乙個埠，瀏覽器訪問即可除錯**，但要將應用部署到網際網路，還需運維。
部署運維應用時，要考慮容災容錯，都要保障異地多活，部署多個應用例項。每個應用例項跟我們在本地開發時一樣，只是ip改為私有網路ip。
隨雲服務商興起，鮮有網際網路企業自己維護物理機。雲服務的運維體系中各個環節都已有成熟的雲服務產品或解決方案。
為使多個應用例項在容災容錯場景下穩定切換流量，就需負載均衡和反向**服務：
服務端的邊界，就是上圖中的整個藍色部分，它是負責應用或**的線上運維。serverless解決問題的邊界，就是服務端的邊界，即服務端運維。
以前服務端運維全由自己負責，而serverless則是我們較少負責服務端運維，大多運維操作交給自動化工具。
研發無需關心任何部署運維操作。研發每次發布新應用，都要**運維，讓運維部署上線最新**。運維要管理好迭代版本的發布，分支合併，將應用上線，遇到遇到問題時回滾。如果線上出故障，還要抓取線上日誌發給研發解決。
這樣的職責分工
研發和運維隔離，服務端運維都交給運維且純人工操作。
但仔細想想，發布版本和處理線上故障這種工作應該是研發的職責，卻都要運維協助，是不是無益增加人力成本呢？
運維的很多任務作都是重複性勞動，尤其是發布新版本，與其每次都等研發**，線上故障後還要自己查日誌發過去，效率很低，不如自己做個運維控制台opsconsole，將部署上線和日誌抓取工作交由研發自己處理。
opsconsole上線後：
這就是devops，研發兼任部分運維工作，運維將部分服務端運維操作工具自動化，解放自己去做更專業工作。看起來研發負責的事情更多了？
但其實版本控制、線上故障都應該是研發處理，且運維已將這部分人力操作工具化了，更加高效，實際上還降低了研發負擔。
如何更高效，連opsconsole平台都不需要用呢？
運維發現資源優化和擴縮容方案還可利用效能監控+流量估算解決。於是運維又基於研發的開發流程，opsconsole系統再幫研發做了一套**自動化發布流水線：
**掃瞄 =》測試 =》灰度驗證 =》上線。
現在研發連opsconsole都無需登入，只要將最新**合進git倉庫指定的develop分支，剩下就都由流水線自動化處理發布上線。
此時研發已無需運維了，踏入免運維noops時代。運維的服務端運維工作全部自動化，研發也回到最初，只需關心業務實現。
可見，隨服務端運維發展，對研發來說，運維存在感越來越弱，都有自動化工具替代，這就是「serverless」。
那運維豈不是把自己玩失業了？
並不，而是
免運維noops並不是說服務端運維不存在了，而是通過全知全能的服務，覆蓋研發部署的所有需求。
noops是理想狀態，所以只能無限逼近noops，單詞也是less，而非noserver或server0。
當下大多公司都還在devops時代，但serverless的概念已然提出，noops時代正在到來。
所以serverless應該叫服務端免運維，要解決的就是將運維工作徹底透明化，研發只關心業務，不用關心部署運維和線上各種問題。
狹義serverless：
廣義serverless：
廣義serverless包含的東西更多，適用範圍更廣，但我們經常在工作中提到的serverless一般都是指狹義serverless，這是歷史原因。
2014 年11月份，亞馬遜推出真正意義上的第一款serverless faas服務：lambda。serverless的概念才進入了大多數人的視野，也因此serverless曾經一度就等於faas。
用faas+baas這種serverless架構開發的應用。
xaas(x as a service)，x即服務，雲服務商愛用的一種命名，比如saas、paas、iaas。
函式即服務，也叫serverless computing，可讓我們隨時隨地建立、使用、銷毀乙個函式。
通常函式的使用過程：需先從**載入到記憶體，即例項化，然後被其它函式呼叫時執行。faas中也一樣，函式需例項化，然後被觸發器trigger或被其他函式呼叫。二者最大的區別就是在runtime，也就是函式的上下文，函式執行時的語境。
faas的runtime是預先設定好的，runtime裡面載入的函式和資源都是雲服務商提供的，我們可以使用卻無法控制。可理解為faas的runtime是臨時的，函式呼叫完後，這個臨時runtime和函式一起銷毀。
faas的函式呼叫完後，雲服務商會銷毀例項，**資源，所以faas推薦無狀態的函式。如果你是前端，可能好理解，就是函式不可改變immutable，乙個函式只要引數固定，返回的結果也必須固定。
比如mvc架構的web應用，view層是客戶端展現的內容，通常無需函式算力；control就是函式的典型使用場景。乙個http資料請求，就會對應乙個control函式，我們完全可用faas函式代替control函式。
http資料請求量
既然runtime不可控，faas函式無狀態，函式例項又不停擴容縮容，那我需要持久化儲存一些資料怎麼辦，mvc裡面的model層怎麼解決？
後端即服務。baas是乙個集合，是指具備高可用性和彈性，而且免運維的後端服務。說簡單點，就是專門支撐faas的服務。faas就像高鐵的車頭，如果我們的後端服務還是老舊的綠皮火車車廂，那肯定是要散架的，而baas就是專門為faas準備的高鐵車廂。
mvc架構中的model層，就需要用baas。model層以mysql為例，後端服務最好將faas操作的資料庫的命令，封裝成http的openapi，提供給faas呼叫，自己控制這個api的請求頻率以及限流降級。這個後端服務本身可通過連線池、mysql集群等方式去優化。各大雲服務商自身也在改造自己的後端服務，baas也在日漸壯大。
baas主要是解決「狀態」的問題，因為faas是無狀態的。與雲上現有的rds不同是，baas需要提供快速接入，快速鏈結，免運維。對於雲廠商，要提供這種服務，以為著要對現有的rds等服務做很大的改造：多使用者多連線，還有計費模型。對於企業來說，現有的產品如何baas化封裝，提供給faas使用，借助faas的優勢降低服務端成本。前幾年市場上做的是面向移動端的baas，因為瀏覽器前端無法encrypt，不過faas的出現才改變了市場。長時間執行的服務，考慮容器方案。
基於serverless架構，完全可以把傳統mvc架構轉換為baas+view+faas的組合，重構或實現。
狹義serverless（最常見）= serverless computing架構 = faas架構 = trigger（事件驅動）+ faas（函式即服務）+ baas（後端即服務，持久化或第三方服務）= faas + baas
serverless毋庸置疑正是因為faas架構才流行起來，進入大家認知的。所以我們最常見的serverless都是指serverless computing架構，也就是由trigger、faas和baas架構組成的應用。這也是我給出的狹義serverless的定義。
廣義serverless則是具備serverless特性的雲服務。現在的雲服務商，正在積極地將自己提供的各種雲服務serverless化
將狹義的serverless推公升至廣義，具備以下特性的，就是serverless服務。要達成noops，都應該具備什麼條件？
運維的職責：
廣義serverless，其實就是指服務端免運維，當下趨勢。
參考
Redis 開發運維問題 持久化
1.同步操作 記憶體頁的拷貝，本身速度非常快，不會阻塞主線程 2.與記憶體量有關 記憶體越大，耗時越長 3.info latest fork usec fork 所需時間 4.改善fork 1 有限使用物理機 2 控制redis 例項最大可用記憶體 3 linux記憶體分配策略 4 降低fork 頻...
Redis 常見的持久化開發運維問題
1.同步操作 記憶體頁的拷貝，本身速度非常快，不會阻塞主線程 2.與記憶體量有關 記憶體越大，耗時越長 3.info latest fork usec fork fork的執行時間 4.改善fork 1 有限使用物理機或者高效支援fork操作的虛擬化技術 2 控制redis 例項最大可用記憶體 ma...
Redis 學習（八） 開發運維的「陷阱」
本篇文章來講一講開發運維中的 陷阱 thpoom killer ntp 同步不同節點的時間 ulimit 單個使用者同時開啟的檔案數 tcp backlog 以持久化檔案作為恢復資料的媒介。rdb 變化 從節點變化 和主節點沒有區別 筆者曾經就被攻擊過，心塞 具體攻擊的細節可以問度娘，這裡不贅述。下...