閱讀目錄
一：什么是serverless無服務？
serverless中文的含義是 "無服務器"，但是它真正的含義是開發者再也不用過多考慮服務器的問題，但是並不代表完全去除服務器，而是我們依靠第三方資源服務器后端，比如使用 Amazon Web Services(AWS) Lambda. 計算服務來執行代碼，那么Serverless架構分為 Backend as a Service(BaaS) 和 Functions as a Service(FaaS) 兩種技術，Serverless 它是由開發者實現的服務端邏輯運行在無狀態的計算容器中，它是由事件觸發，完全被第三方管理的。
什么是BaaS?
Baas 的英文翻譯成中文的含義：后端即服務，它的應用架構由大量第三方雲服務器和API組成的，使應用中關於服務器的邏輯和狀態都由服務提供方來管理的。比如我們的典型的單頁應用SPA和移動APP富客戶端應用，前后端交互主要是以RestAPI調用為主。只需要調用服務提供方的API即可完成相應的功能，比如常見的身份驗證，雲端數據/文件存儲，消息推送，應用數據分析等。
什么是FaaS?
FaaS可以被叫做：函數即服務。開發者可以直接將服務業務邏輯代碼部署，運行在第三方提供的無狀態計算容器中，開發者只需要編寫業務代碼即可，無需關注服務器，並且代碼的執行它是由事件觸發的。其中AWS Lambda是目前最佳的FaaS實現之一。
Serverless的應用架構是將BaaS和FaaS組合在一起的應用，用戶只需要關注應用的業務邏輯代碼，編寫函數為粒度將其運行在FaaS平台上，並且和BaaS第三方服務整合在一起，最后就搭建了一個完整的系統。整個系統過程中完全無需關注服務器。
二：與傳統模式架構區別？
傳統的架構模式是使用C/S架構的，在典型的web應用程序中，服務器接收前端的HTTP請求處理，在保存或查詢數據庫之前，數據可能會經過多個應用層，最終后端會返回一個響應。比如它可以是JSON形式或其他格式等。然后他會將響應返回給客戶端，比如如下圖所示：
在傳統開發模式中，開發流程：設計師設計頁面 -> 服務端開發 和 前端分別開發，服務器開發完成后，-> 服務部署 ->服務部署完成后，就是前后端聯調 -> 前后端聯調 -> 前后端聯調完成后就是測試了，-> 測試， 測試完成需要上線，因此 -> 上線，上線完成后，需要運維維護，因此 -> 運維。在傳統開發模式中，開發一個應用程序，從開始到上線需要不同的角色來做不同的事情，溝通成本非常大，並且運維過程中需要考慮到 服務器的負載均衡、事務、集群、緩存、
消息傳遞和數據冗余等等這些事情，在目前傳統模式中存在如上問題。可以使用如下示意圖來看下如上流程。如下圖所示：
在Serverless架構中，應用業務邏輯是基於FaaS架構形成多個相互獨立的功能組件的。並且以API服務的形式向外提供服務，在FaaS中，后端的應用被拆分成為一個個函數，我們只需要編寫完成函數后部署到serverless服務即可。后續我們也不用關心任何服務器的操作。那么整個流程就只需要我們一個前端工程師的角色來完成所有的開發工作，那么溝通成本降低了。因此我們可以使用如下示意圖來表示項目流程，如下所示：
前端工程師是居於serverless去寫后端服務的，典型的就是居於 AWS Lambda 中編寫代碼，AWS中支持不同的語言。
Lambda計算服務它能夠以大規模並行的方式執行代碼來響應事件。通過使用Lambda以及使用各種功能強大的API和Web服務，開發者可以快速的構建松耦合，可擴展性及高效的架構體系。
注意：Lambda是什么？它是一種計算服務，它在AWS基礎上執行用javascript、node.js、Python、C#或java編寫的代碼，源代碼將被打包並部署到孤立的容器中，該容器有單獨分配的內存、磁盤空間和處理器。代碼、配置和依賴項的組合被稱作為Lambda函數。
三：serverless優缺點？
優點有如下：
1. 降低創業公司啟動成本
當一家創業公司的時候，在開發web的時候，我們需要版本管理服務器、持續集成服務器、測試服務器、應用版本管理倉庫等作為基礎服務。
線上運行的時候，為了應對大量的請求，我們還需要一個好的數據庫服務器。當我們應用面向普通的用戶時，我們需要：
1.1 郵件服務，用於發送提醒，注冊等服務。
1.2 短信服務，用於注冊，登錄等用戶授權操作。
如上一些對於大公司來講，都有現成的基礎設施。可是對於創業公司來講。這都需要一些啟動成本。但是如果我們使用serverless就可以降低這些成本。
2. 減少運營成本
對於創業公司來講，他們沒有基礎設施，沒有財力，也可能沒有能力去建設基礎設施，采用雲服務是最好的選擇，可以為他們節省大量的資金。
他們只要將精力放在對用戶價值的產品之上即可，他們不需要自己去搭建服務器，因此會有更多的時間去開發業務功能。而采用函數計算的serverless與雲服務器最大的區別是：雲服務器需要一直運行，比如說月費或年費要多少錢租，但是serverless是按需計費的，如果有請求到來的時候，才運行函數，否則的話，是不需要錢的。
3. 降低開發成本
serverless會提供一系列的配套服務，比如 我們只需要在配置文件上寫下數據庫的表名，那么數據就會存儲到對應的數據庫里面，並且會提供一系列的函數計算模板，我們只需要寫好我們的配置即可，那么這一系列的東西都可以自動，高效的完成任務。
4. 實現快速上線
對於一些傳統項目來講，我們在本地開發需要部署環境，到開發環境或測試環境，我們還是需要部署環境。但是serverless可以在部署上有優勢，並且很輕松的實現上線。因為serverless內部相當於有 內建自動化部署功能，並且在該里面都是由供應商提供的功能，每次我們寫完業務代碼后，我們只需要運行下即可，在AWS Lambda 函數計算里面，函數一般在上傳后幾秒鍾內，就能做好調用准備。
5. 系統安全性更高。
要保持服務器一直運行不是件容易的事情，並且還需要考慮黑客不同類型的攻擊，但是有serverless后，我們不需要考慮這些問題了，這些問題第三方供應商已經會幫我解決這些問題的。
6. 能適應微服務架構和擴展性能力強
Serverless 的背后是 諸如 AWS Lambda 這樣的 FaaS（Function as a Services）。
對於傳統應用來說，要應對更多的請求的方式，就是部署更多的實例。然而，這個時候往往已經來不及了。而對於 FaaS 來說，我們並不需要這么做，FaaS 會自動的擴展。它可以在需要時盡可能多地啟動實例副本，而不會發生冗長的部署和配置延遲。
以亞馬遜的AWS Lambda為案例，Lambda能讓我們不用思考任何服務器，也就是說，不用我們處理服務器上的部署，服務器的容量和服務器的擴展和失敗容錯，還有服務器上選擇什么OS操作系統，語言的更新，日志等等問題。你的應用程序只需要和多個第三方的API或服務打交道，也可以自我創建一個無服務器的
API。
缺點有如下：
1. 不適合長時間運行應用
serverless 在請求到來的時候才運行，當應用不運行的時候會進入 "休眠狀態"，下次當請求來臨時，應用將會需要一個啟動時間，可以叫 冷啟動，如果我們的應用需要一直長期不間斷的運行，處理大量的請求，那么可能就不適合使用serverless來架構了，如果這種情況下，我們需要使用像EC2這樣的雲服務器會是一個更好的選擇。
EC2相當於我們自己買了一輛車，在Lambda 相當於我們租了一輛車。如果我們長期租車的話，那么肯定比買車更貴，但是租車可以減少一部分車維護成本。
2. 完全會依賴於第三方服務
如果我們所有和應用相關的服務放在第三方服務上的話，就可能會涉及到安全性問題，因此我們可以將不重要的API或服務放在serverless上。
當然如果我們自己有服務設施的話，那肯定使用自己的設施服務的，當我們自己使用serverless架構的時候，那么我們就已經和供應商綁定了。
如果這個時候我們將服務遷到別的雲服務商上就沒有那么容易了。
3. 缺乏調式和開發工具，排查問題困難。
4. 無法用於高並發運用。
為每個請求啟動一個進程開銷太高，流量瞬間爆發容易超時。比如淘寶的雙十一支付寶高峰期，每秒處理交易筆數8萬多筆，也就意味着我們的系統內每秒有8萬多個進程創建又被銷毀。那么這樣就會造成系統開銷很大。解釋和第一點一樣的原理。
四：使用serverless的應用場景有哪些？
Serverless 適合構建比較簡單的應用，比如上傳一張圖片，對一段音頻/視頻進行編碼或解碼，對請求返回一小段數據等。
Serverless架構主要有以下特點：
1. 實現了細粒度的計算資源分配。
2. 不需要預分配資源。
3. 具備真正意義上的高度擴容和彈性。
4. 按需使用，按需計費。
因此以下應用將可能使用serverless架構：
1. 靜態網站的管理。
2. 替代WordPress(Serverless Blog Project)
3. 個人媒體服務器(less!)
4. 物聯網Iot或家庭自動框架或項目 (使用 AWS IoT)
具體的應用基本如下：
發送通知：
諸如 PUSH Notification、郵件通知接口、短信，這一類服務來說，他們都需要基礎設施來搭建。並且，他們對實時性的要求相對沒有那么高。
即使在時間上晚來幾秒鍾，用戶還是能接受的。在我們所見到的短信發送的例子里，一般都會假設用戶能在 60 秒內收到短信。因此，在這種時間 1s 的誤差，用戶也不會惱火的。而對於 APP 的消息推送而言，這種要求就更低了，用戶反而不太希望能收到這樣的推送。
WebHook
當我們沒有服務器，又想要一個 Webhook 來觸發我們一系列的操作的時候。我們就可以考慮使用 Serverless，我們不需要一直就這么支付一個服務器的費用。通過 Serverless，我們就可以輕松完成這樣的工作，並且節省大量的費用。
數據統計分析
數據統計本身只需要很少的計算量，但是生成圖表，則可以定期生成。
在接收數據的時候，我們不需要考慮任何延時帶來的問題。50~200 ms 的延時，並不會對我們的系統造成什么影響。
Trigger 及定時任務
對於哪些需要爬蟲來抓取和生成的程序來說，Serverless 可能是一個不錯的舞台。
盡管，這樣的工作也可以由雲服務器來做，我們只需要定時的啟動一下服務器。通過服務器中的自啟動腳本來做相應的事，但是當我們完成了一系列的工作之后。我們需要將數據存儲在一個遠程的服務器上。而為了讓系統中的其它應用，也能直接訪問這些數據。那么，我們可能會考慮使用一個雲數據庫。這個時候，Serverless 應用看上去更具有吸引力。
Chat 機器人
聊天機器人，也是一個相當好的應用場景。
But，由於國內的條件限制（信息監管），這並不是一件容易的事。因此，從渠道（如微信、blabla）上，都在盡可能地降低這方面的可能性。
但是，我們還可以做一個微信公眾號的服務。當用戶輸入一個關鍵詞時，做出相應的回復，這實質上和聊天機器人是差不多的。