這是來自martinfowler.com的Serverless架構一文的大意翻譯。
什么是Serverless?
Serverless首先是用於描述我們的應用程序是明顯或充分地依賴第三方應用或服務來管理服務器端邏輯和狀態，這些應用是典型的富客戶端應用，比如單頁Web應用或移動應用，它們使用基於雲可訪問的數據庫比如Parse或Firebase，還有授權服務比如Auth0AWS Cognito等，這些服務類型之前曾經被描述為后端服務，下面使用Baas這一簡稱代表后端服務(Backend as a Service)。
其次，Serverless也意味着應用會有一些服務器端邏輯，但是不像傳統架構是運行在無態容器中，通過事件觸發，它是瞬間的，可能只使用一次，完全由第三方管理，一種思想認為這是“Functions as service函數服務”簡稱Faas，AWS Lambda就是一種流行的Faas實現，當然還有其他。
當開發Baas shaped應用，特別當開發一個富Web應用，而不是移動應用時，你會需要一些服務器端定制功能，Faas功能也許對於這種情況是一種好的解決方案，特別是如果他們和你使用的BaaS服務集成到一定程度時，這樣功能案例包括數據校驗和計算敏感的處理，比如圖片和視頻的制作。
下面是一些案例應用：
UI驅動應用：讓我們看看帶有服務器端邏輯的傳統三層面向客戶端系統，比如電子商務應用，傳統的架構是看上去像下面：
客戶端(瀏覽器) ---> 寵物店服務器 ---->數據庫
這種架構的客戶端相對不會太智能，系統中有太多邏輯：授權，分頁，搜索和事務等都是由服務器應用實現。
而使用Serverless架構則會如下面：
下面是兩者區別：
1.刪除了原來在應用中的授權邏輯，使用地反復BaaS服務來替代
2.允許客戶端直接訪問數據庫，比如產品列表等，數據庫是第三方主機上比如AWS Dynamo，這樣，我們訪問數據庫的安全策略就和訪問服務器資源不同。
3.前面兩點意味着非常重要的第三點，原來在寵物店的邏輯現在遷移到客戶端了，比如跟蹤用戶會話，理解應用的UX用戶體驗結構比如分頁，從數據庫中讀取和轉為可用的視圖等等，客戶端其實這時已經變成了一個單頁應用。
4.一些UX相關功能可能會要保留在服務器端，比如計算敏感或需要訪問大量數據，比如搜索功能，對於這種功能我們不總是讓其運行在服務器端，而是實現一個FaaS函數方式來響應http請求，客戶端通過API網關來訪問這個FaaS函數。
5.我們也許使用FaaS函數來替代購買功能，讓其還是放在服務器端是因為安全原因，不需要在客戶端再實現一遍，這也是通過API網關調用。
消息驅動應用
一個不同的案例是后端數據處理服務，假設你正在編寫一個用戶中心的應用，需要快速響應 UI請求，但是其次你需要截獲所有發生活動類型，讓我們看看一個在線系統：當用戶點擊一個廣告你要快速導向點擊到廣告目標網址，但是同時你需要收集剛剛發生的點擊事件與信息，這樣才是對廣告主負責的做法。
傳統架構如下，廣告服務器同步響應用戶，同時會發送一個消息給一個可以異步處理的通道，稱為“點擊處理器”，應用然后更新數據庫等等做其他動作。
而在Serverless架構下，會有多個“點擊處理器”作為點擊事件的消費者，這些消費應用也是作為FaaS功能運行在第三方提供的事件驅動上下文場景下的。注意，第三方提供消息系統Broker和FaaS環境，這兩個系統會彼此緊密聯系在一起。
FaaS環境可以並行處理幾個點擊事件，只要將函數代碼實例化多個即可。
解密“函數作為服務”
為了解密FaaS，我們看看Amazon的Lambda產品：
AWS Lambda讓你無需任何配置或管理服務器的代價下運行你的代碼： (1) Lambda可以運行你的幾乎所有類型的應用或后端服務的代碼 (2) 因為零管理，只要上傳你的代碼和lambda會照顧運行等一切 (3) 並以高可用性擴展 (4) 你代碼的運行性能. 你能設置你的代碼自動從AWS服務觸發 (5) 或者直接從任何web或移動應用直接調用你的代碼 (6) (此處略去關於上述6點AWS詳細說明…………)
狀態
在本地狀態方面FaaS功能有顯著的約束，你能假設任何函數的調用創造的狀態，無論是同一個進程或同一個主機內的狀態，都不適用於下次調用了，RAM中狀態需要寫到本地磁盤，也就是說，FaaS是無態的。
這對應用程序體系結構產生了巨大的影響。這意味着FaaS是自然地無態，提供純輸入的函數轉換，如果需要存儲狀態，使用數據庫或跨應用的緩存或網絡文件存儲等等，實現跨請求的狀態存儲，為下一個請求訪問上個請求的狀態。
執行時間
FaaS是典型限制每次長調用，AWS Lambda函數不允許調用超過5分鍾，超過就會中斷。
這意味着長任務運行不適合PaaS，因此你可能需要重新架構：比如創建幾個不同的協調的FaaS函數，而在傳統環境中，你只需要一個這樣的任務，既做協調又做執行。
啟動延遲
FaaS函數響應一個請求會有延遲，其延遲有多長取決於很多情況，也許會從10ms到2分鍾，讓我們使用AWS lambda作為一個案例：
如果你的函數是使用Javascript或Python或少於一千行代碼，應該不會運行超過10-100ms，更大的函數也許偶爾會發生長時間運行的情況。
如果你的Lambda函數使用JVM實現，偶爾會看到超過10秒的響應時間，只會在下面情況發生：
1.你的函數處理事件不頻繁，兩次調用之間長於10分鍾
2.你在流量上有突然峰涌，原來每秒處理10個請求突然在10秒內上升到每秒100個請求。
這些情況可以通過這個丑陋方式避免：每隔5分鍾ping一下函數的方式確認它是活着。
也就是說， 延遲時間會依賴你的應用風格和流量情況，曾經有一個團隊使用異步消息處理Lambda的Java應用實現每天處理幾百萬的消息，根本不關心啟動延遲，如果你編寫一個低延遲交易應用，可能就無法使用FaaS系統，不管你使用什么語言實現。
API網關(Gateway)
它是一個HTTP服務器，通過配置實現路由和REST端點服務，每個路由URI都和相應的FaaS函數對應，當API網關接收到一個請求，會通過路由配置匹配到哦相應的FaaS函數。也就是說，API網關是將FaaS函數調用結果轉化為Http響應然后返回調用者。
除了純粹的路由請求以外，API網關也可以執行身份驗證，輸入驗證，響應代碼的映射等功能。
我們有一個API網關 + FaaS案例是以Serverless方式創建一個http前端的微服務，從而獲得了FaaS函數的擴展性、可管理性和其他好處。
開源
因為Serverless的FaaS應用能夠提供生產運行環節的質量要求，而開源項目比如Docker等容器則不屬於這個范疇，
Apex開源項目能提供易於構建 部署和管理AWS Lambda函數，能讓你用語言方式開發Lamda函數，而不是直接使用Amazon支持的Lambda。
與PaaS比較
如果PaaS能夠在20ms內啟動實例運行半秒，那么可以稱它為serverless。
PaaS並不是將整個應用只為每個請求啟動使用的，而FaaS平台恰好是這么做的。
NoOps
Serverless不意味着無運營"No Ops"，只是意味着沒有內部系統管理。
存儲過程作為服務
一些FaaS函數除了訪問數據庫的語句以外只有很少的代碼，因此這樣的FaaS函數也被稱為存儲過程的服務。但也有些問題，比如會需要使用具體廠商的語言，難以測試和進行版本控制等時比較棘手。Mike Roberts對這些問題都進行了認真討論。
后記：
什么是Serverless無服務器架構？
Serverless不代表再也不需要服務器了，而是說：開發者再也不用過多考慮服務器的問題，計算資源作為服務而不是服務器的概念出現。Serverless是一種構建和管理基於微服務架構的完整流程，允許你在服務部署級別而不是服務器部署級別來管理你的應用部署，你甚至可以管理某個具體功能或端口的部署，這就能讓開發者快速迭代，更快速地開發軟件。
以AWS Lambda為案例，Lambda能讓不用思考任何服務器，也就是說，不用你處理服務器上的部署、服務器容量和服務器的擴展和失敗容錯，還有服務器上選擇什么OS操作系統，語言的更新，日志等等問題。你的應用程序只需要和多個第三方的API或服務打交道，也可以自我創建一個無服務器的API。
Serverless有以下幾個特點：
Serverless意味無維護，Serverless不代表完全去除服務器，而是代表去除有關對服務器運行狀態的關心和擔心，它們是否在工作，應用是否跑起來正常運行等等。Serverless代表的是你不要關心運營維護問題。有了Serverless，可以幾乎無需Devops了。
Serverless不代表某個具體技術，有些人會給他們的語言框架取名為Serverless，Serverless其實去除維護的擔心，如果你了解某個具體服務器技術當然有幫助，但不是必須的。
Serverless中的服務或功能代表的只是微功能或微服務，Serverless是思維方式的轉變，從過去：“構建一個框架運行在一台服務器上，對多個事件進行響應。”變為：“構建或使用一個微服務或微功能來響應一個事件。”，你可以使用 django or node.js 和express等實現，但是serverless本身超越這些框架概念。框架變得也不那么重要了。
Serverless規模擴展性方面由於充分利用雲計算的特點，因此其擴展是平滑的，同時由於Serverless是基於微服務的，而一些微功能微服務的雲計算是零收費，這樣有助於降低整體運營費用。
++補充：
++Serverless代表着未來雲服務正在走向越來越分離關注點的趨勢，業務系統不直接與硬件、操作系統和一般容器打交道而是通過一個更高級的容器運行業務系統，業務系統會向容器的管理中心申請各種資源。部署和運維業務不再過多關心具體硬件與其他細節，而是關心自身業務與需要的各種資源調配的設置與應用。以后幾乎所有的部署與運維都是針對業務本身，所以以后感覺不到服務器的這個具體的硬件實施的存在。這就是亞馬遜定義的“無服務器”架構。
Serverless的架構圖
