在這里跟大家聊的是另一個值得關注的未來新趨勢技術-- 無服務器架構（Serverless Architectures） 。這里借用ThoughtWorks公司的首席科學家Martin Fowler對無服務器架構的定義： 無服務器架構是指大量依賴第三方服務（也叫做后端即服務，即“BaaS”）或暫存容器中運行的自定義代碼（函數(shù)即服務，即“FaaS”）的應用程序。下面分別講述一下BaaS和FaaS。BaaS（后端即服務）一個移動互聯(lián)網(wǎng)產(chǎn)品分為兩個部分，一個是前端，就是用戶所看到的界面；一個是后端，用于對用戶交互行為進行支撐的服務，包括了應用程序和數(shù)據(jù)庫等服務，還包括了對應用程序和數(shù)據(jù)庫等服務的運行環(huán)境IaaS，PaaS。如下圖所示：
那么要提供一個移動互聯(lián)網(wǎng)產(chǎn)品也需要完成兩個部分的工作：一個是功能的開發(fā)，一個是運行環(huán)境的構建與維護。主要需要做以下的成本投入：| 成本項 | 具體的內(nèi)容 |
硬件成本 | 機房 |
服務器 |
網(wǎng)絡設備 |
存儲設備 |
人員成本 | 前端開發(fā)人員 |
后端開發(fā)人員 |
運維人員 |
| 時間成本 | 環(huán)境的搭建 |
| 前端的開發(fā) |
| 后端的開發(fā) |
從上面這個表格我們可以看到，如果所有內(nèi)容都由自己構建，那么一個是產(chǎn)品的上線周期會時間很長，還有就是投入的成本會很大，并且風險全部在自己手中?；谶@種市場需求，開始出現(xiàn)了云服務商來幫助開發(fā)者達到簡化過程，快速上線的需求。最早形式的云服務商主要還是云主機的方式，這樣開發(fā)者就不需要搭建和維護運行環(huán)境，
只需要做功能的開發(fā)，再部署到云主機上。并且購買云主機的成本也會相對比自己購買的成本要低，還可以進行一個按需的伸縮，不會有閑置的資源浪費。主要需要做以下的成本投入：| 成本項 | 具體的內(nèi)容 |
| 硬件成本 | 云主機 |
| 人員成本 | 前端開發(fā)人員 |
| 后端開發(fā)人員 |
| 運維人員 |
| 時間成本 | 前端的開發(fā) |
| 后端的開發(fā) |
雖然這種模式相對原來的模式在成本和效率上已經(jīng)有了很大的提升了，但是作為一個為快不破的互聯(lián)網(wǎng)時代，這種效率依然不夠快速。如所有的功能都需要自己開發(fā)，對云主機的伸縮和資源的利用還是需要自己來管理?；谶@種市場需求，又提出了一種新的服務—BaaS，后端即服務。即后端服務由第三方云服務提供，而自身只需專注于具體業(yè)務和邏輯的實現(xiàn)，以及前端的設計與開發(fā)，提高用戶體驗。在這模式下，不需要為后端服務買服務器，也不需要編后端的代碼。主要需要做以下的成本投入：| 成本項 | 具體的內(nèi)容 |
| 人員成本 | 前端開發(fā)人員 |
| 時間成本 | 前端的開發(fā) |
我們可以看到，在這種模式下，對一個產(chǎn)品來言就只需要前端開發(fā)，免除了后端系統(tǒng)的負擔，簡化了整個產(chǎn)品的構建，可以快速實現(xiàn)產(chǎn)品化與上線?？梢钥吹竭@種后端即服務的模式下，對開發(fā)者而言是不需要維護服務器的，在產(chǎn)品的生命周期里都沒有出現(xiàn)服務器，這就是一種無服務器架構。無服務器架構不是沒有服務器，而是開發(fā)者無需關心服務器，只需要關注代碼的實現(xiàn)。這些后端的服務器被平臺服務商隱藏起來，由第三方服務商負責基礎設施管理的基本細節(jié)，包括應用運行時的計算資源的分配和可用性。服務器對開發(fā)者而言透明的，開發(fā)者也無法調(diào)整或修改任何與服務器相應的內(nèi)容。BaaS的價值降低成本：按傳統(tǒng)的模式還沒有上市已經(jīng)為后端投入了很多的成本。而目前BaaS服務商都會有一定的免費額度，那么在驗證市場前的投入就可以相對降低很多，風險也降低了很多。提高產(chǎn)品質(zhì)量：減少了后端的開發(fā)，只關注前端開發(fā)，可以提高研發(fā)的效率和產(chǎn)品質(zhì)量。快速上市：簡單化了整個產(chǎn)品的研發(fā)過程，可以縮短想法到產(chǎn)品的距離。豐富的API資源：BaaS將常用和必要的第三方API資源匯總，免除了選擇多個廠商的局面。移動互聯(lián)網(wǎng)產(chǎn)品的開發(fā)者使用 BaaS 模式，只需一個極小team，極短的時間，就可以快速上線一個產(chǎn)品。目前比較知名的BaaS服務提供商包括國外 Parse，Kinvey，國內(nèi)的LeanCloud，Bomb和MaxLeap，APICloud 、友盟。為移動應用開發(fā)者提供的后端服務包括結構化的數(shù)據(jù)存儲、用戶和權限管理、文件存儲、支付、實時通信等。FaaS（函數(shù)即服務）在BaaS模式下，對開發(fā)者而言是沒有服務器的，但是對BaaS服務提供商來說還有是服務器的。通常他們也會對選擇其他的云服務商，如云存儲，云主機。比如七牛云存儲是 LeanCloud 在國內(nèi)節(jié)點選用的非結構化數(shù)據(jù)托管方。而FaaS模式的Serverless 則是改變服務器資源的提供方式，計算資源不再是服務器，而是一個封裝了待執(zhí)行代碼的函數(shù)，計算資源作為服務而不是服務器的概念出現(xiàn)。以傳統(tǒng)的云主機服務為對比。購買一個云主機之后就會擁有這臺主機的獨占資源，改變的只是由本地物理機變成了云上虛擬機，可以免去部分主機層的運維。但是在這個主機上還是需要安裝一些軟件，配置一些信息，部署一些應用，還有一些應用級別的運維操作，比如應用的監(jiān)控，安全，伸縮等。更重要的是，云主機是以月的方式購買，一但購買，無論是否使用，這個服務器都是收費的。而Serverless提供方式是根據(jù)函數(shù)的調(diào)用次數(shù)來收費，只要這個服務沒有人調(diào)用就不需要為計算資源付費。并且在使用上也非常簡單，只需把函數(shù)代碼上傳到平臺上，分鐘級別函數(shù)就可以對外提供服務了。沒有復雜的部署過程，沒有復雜的配置過程，沒有等待時間，并且不需要運行。那么這種Serverless的原理是什么呢？首先是它只支持無狀態(tài)的單一職責的函數(shù)應用，并不支持有狀態(tài)的多職責的應用，這樣應用在啟動時不需要過多的加載，能毫秒級的啟動。其次它是冷啟動的模式，也就是說后端的服務在沒有調(diào)用的情況下并不運行，而是只當有調(diào)用時才會啟動，處理完請求后就會立馬釋放資源，應用不再是“”始終運行“”，這樣資源就可以得到充分的利用。第三就是按調(diào)用次數(shù)進行自動的彈性擴縮容，并不需要人為去管理伸縮問題。這樣對用戶來說，購買的不再是一臺服務器，而是部署的函數(shù)的調(diào)用次數(shù)，這就是函數(shù)即服務。傳統(tǒng)的模式下，無論是使用的計算資源是物理機，虛擬機，容器還是云主機，都是需要人去維護和部署，開發(fā)者面對的計算資源都是服務器。而在無服務器計算架構下，所有與服務器關系的問題都交由服務提供商解決。Serverless中的服務或功能代表的只能是函數(shù)級別的微功能或微服務，這種模式不再是基礎設施即代碼的架構，而是代碼即基礎設施的架構。能幫助開發(fā)者擺脫運行后端應用程序所需的服務器設備的設置和管理工作，讓開發(fā)人員可以主要專注于代碼，更快速地開發(fā)軟件。通過下面的圖可以對比一下傳統(tǒng)的服務器模式與無服務器模式的區(qū)別：在傳統(tǒng)的服務器模式下，對應用進行開發(fā)后首先要構建一個運行環(huán)境，包括購買主機，在主機上安裝相關的軟件，配置環(huán)境，再進行應用的部署，部署成功后還需要對應用的運行進行運維管理，確保高可用。而在無服務器模式下，開發(fā)面對的只有代碼，在無服務器服務提供商的界面將代碼上傳，簡單的配置一下，也不需要選擇資源，只需定義運行時的編譯環(huán)境，如是java，nodejs還是python等。在選擇部署的那一刻就可以對這個函數(shù)進行訪問了，并且部署后并不需要維護。對于沒有轉(zhuǎn)過思維的同學可能還在想，我怎么看函數(shù)的運行狀態(tài)，怎么看啟動了多少個實例，怎么看資源的消耗情況。STOP!這些都沒有，只需要關心函數(shù)是否能正常的訪問。那么什么樣的應用適合運行在這種Serverless模式下呢？比如七牛的圖片處理服務非常適用FaaS模式，每個圖片處理的命令就是一個簡單的Function。以構建一個計算文件hash值服務為例，這個函數(shù)只需獲取到要處理的數(shù)據(jù)，再在函數(shù)中執(zhí)行數(shù)據(jù)處理的算法，幾十行代碼，計算邏輯簡單，無狀態(tài)，處理時間短，毫秒級的響應， 這樣的應用就非常適合Serverless模式。如果需要調(diào)用多個函數(shù)時應該怎么處理？分兩種情況，對于并行的情況，比如需要同時獲取多個函數(shù)的處理結果來做一個響應，可以使用APIGateway 。API Gateway負責請求轉(zhuǎn)發(fā)、合成和協(xié)議轉(zhuǎn)換。所有來自客戶端的請求都要先經(jīng)過API Gateway，然后路由這些請求到對應的函數(shù)服務。API Gateway將通過調(diào)用多個函數(shù)服務來處理一個請求以及聚合多個服務的結果。另一個是串行的情況。比如七牛的圖片處理，每一個函數(shù)服務的輸出都是下一個處理函數(shù)的輸入，直到最后一個函數(shù)服務執(zhí)行結束才是最終數(shù)據(jù)處理的內(nèi)容，比如先裁剪后加水印，必須按序執(zhí)行。那么在這種串行處理的情況下，可以選擇使用管道（pipeline）進行串行的處理 。下面使用以使用serverless構建一個FaaS為例，展示什么是無服務器架構。如上圖所示，在本地環(huán)境安裝一個serverless后，首先使用serverless根據(jù)模板創(chuàng)建一個aws-nodejs的服務，這里會在當前目錄下產(chǎn)生兩個文件， serverless.yml和handler.js。serverless.yml文件用于聲明一個Serverless服務，而handler.js里則是具體的函數(shù)代碼。第二步，使用serverless deploy將當前的serverless服務進行部署，服務部署成功后用戶可通過 HTTP API 訪問部署的服務。在整個部署過程中，只需寫好代碼和服務聲明，而并沒有進行服務器的環(huán)境配置，也沒有任何類型軟件的安裝，也沒有配置運行所需的資源，整個部署過程開發(fā)者不用考慮服務器的問題，這就是無服務器計算。Serverless的特點1. 無狀態(tài)FaaS函數(shù)是無狀態(tài)的，只提供單純的調(diào)用，對輸入的函數(shù)轉(zhuǎn)換。這也是微服務要求的特性。2.單一原則函數(shù)需滿足單一職責原則（SRP）。只處理某一項簡單任務的函數(shù)更容易測試、運行穩(wěn)定，而且?guī)淼腻e誤和意外的副作用比較少。3. 執(zhí)行時間FaaS函數(shù)通常會對每次調(diào)用可以執(zhí)行的時間長度有所限制。對超過一段時長的請求將被終止。4.事件驅(qū)動傳統(tǒng)的服務器端需長期維持業(yè)務進程來處理客戶端請求，而在Serverless架構中，業(yè)務代碼僅在調(diào)用時才激活運行，當響應結束占用資源便會釋放。比如在夜間有些服務根本沒人調(diào)用，那么這些服務也不會運行。Serverless 帶來的價值低成本服務只在被調(diào)用時才會運行，執(zhí)行完畢后，承擔這些功能的容器會立刻停用，這樣在idle狀態(tài)下就不會占用的資源，可以更好的提高資源的利用率，而用戶則只需為運行代碼過程中所消耗的資源付費。某些服務可能一個月中只有某一天或只有白天才會有請求量，其他時間都是空閑的。在傳統(tǒng)的模式是申請一臺云主機后，按月付費，無論是否使用。而在無服務器模式下，可以按函數(shù)調(diào)用次數(shù)付費，無請求不運行無資源占用不收費，不會因配置過多造成資源浪費，也不會因為配置過少造成性能問題。這種按調(diào)用次數(shù)付費的方式可以很大程度上降低成本。快速擴展在傳統(tǒng)的模式下，為了應對業(yè)務高峰，即使這個高峰時間只是當天的某一個瞬間，都需要準備好足夠的云主機資源來應對高峰。而在Serverless架構下，可以利用快速擴展特性，快速構建新的計算能力來滿足當前需求，而無需關心服務器資源是否足夠，是否能夠進行擴展。敏捷性首先因為函數(shù)只是實現(xiàn)單一的職責，是微功能的微服務，代碼的數(shù)量并不會很多，而且AWS lambda還提供各種代碼模板，只需在模板中修改核心代碼就可快速完成代碼的開發(fā)。代碼發(fā)開發(fā)之后，也沒有復雜的服務器配置工作，只需要將代碼上傳到平臺，秒級完成部署，實現(xiàn)了快速上線。易調(diào)試代碼的簡單以及部署的敏捷性，同時也帶來了調(diào)試的簡單性。對代碼的修改可以秒級的線上驗證，也可以秒級的回退，沒有復雜的調(diào)試過程。免運維免運維指的是指無須內(nèi)部的運維，不同于傳統(tǒng)的部署方法，serverless模式只需將代碼上傳至FaaS供應商，其他事情均可由供應商完成。相當于運維的工作外包給了無服務器技術供應商，包括服務器本身的管理，監(jiān)控、安全、伸縮等。Severless 適用場景的實踐1）快速上線需求在非serverless模式下，如果開發(fā)一個API要上線，需要先購買服務器，再部署環(huán)境，然后再上線提供服務，還有一些和運維相關的事情需要處理?；蛟S開發(fā)一個API只用了1小時，但其他的事情卻占用了七八個小時，還有很多對開發(fā)人員來說不熟悉的運維操作，降低了上線的速度。如果使用serverles模式，只需要把代碼開發(fā)完成，就能在幾分鐘之內(nèi)完成部署上線，非常適合快速上線的場景。2）不想為空閑資源付費的需求以云主機的使用為例，購買一個云主機部署業(yè)務后，這個業(yè)務可能在一天中的請求量分布不均，在某些時段非常低或空閑，而在某些時段峰值很高，但是為了滿足在業(yè)務高峰期的需求，在購買云主機時會將資源配置最大化，并留有一定的冗余。在這種場景下，如果使用serverless模式，則可以根據(jù)一天中不同時間段的請求情況按需付費，不而需要為沒有請求量情況下的資源付費。3）流量突發(fā)場景下的需求在移動互聯(lián)網(wǎng)的業(yè)務中經(jīng)常會遇到突發(fā)流量的場景，雖然現(xiàn)在的PaaS云平臺基本也都具備了彈性伸縮的能力，但能做到自動擴容的還是很少。而在serverless模式下則可以靈活應對突發(fā)流量，快速響應，快速擴縮容。Serverless 的劣勢和現(xiàn)在所有的技術一樣，無服務器方法解決不了所有問題，在解決一些問題的同時也會帶來一些問題。這就取決的開發(fā)者的選擇。1.容易失控除了代碼功能由自身實現(xiàn)，其他的所有都完全依賴服務提供商，但服務提供商本身提供的服務功能的完整性和可靠性還有待驗證。而且如果是一個有些復雜的系統(tǒng)，這意味著圍繞系統(tǒng)實現(xiàn)的所有服務都需要使用這個平臺的，如數(shù)據(jù)庫等，那么很容易出現(xiàn)失控的局面。2.部署的復雜性從整個應用的部署到微服務的部署再到函數(shù)的部署，把一個部署動作變成了無數(shù)多個的部署動作。對于一個應用程序中的每個一函數(shù)都需要單獨部署一個FaaS，如果有30個函數(shù)就需要部署30次。還需要能像容器編排工具一樣對一組函數(shù)進行統(tǒng)一的部署。3.啟動延遲區(qū)別于傳統(tǒng)的服務器持久在線的運行模式，函數(shù)采用的是冷啟動，也不是只有調(diào)用觸發(fā)才會啟動，也就是說要求服務在調(diào)用觸發(fā)的瞬間啟動，毫秒別，至少也需要是秒級。那么調(diào)用一個函數(shù)時多久能獲得響應也是一個問題。除非能做到毫秒級的啟動，否則不適用于高并發(fā)、低延遲的場合。4.集成測試單個的函數(shù)比較簡單，調(diào)試起來也比較簡單，但是要把很多個函數(shù)做集成測試就會變得復雜。目前大部分的提供商未向用戶提供可用的本地實現(xiàn)，在做集成測試時也不能使用本地的環(huán)境，而只能使用生產(chǎn)測試，這也會帶來一些復雜度和風險。Serverless的技術實現(xiàn)如何構建一個Serverless的平臺呢？前面講過，函數(shù)是一個比較極端情況的微服務，而基于容器的PaaS平臺是對微服務的最合適的落地方案。那么如果想做一個Serverless的平臺，也可以在容器平臺上進行一個優(yōu)化。主要是四個方面的技術實現(xiàn)，第一個是運行環(huán)境的自動構建，二個是事件驅(qū)動的部分，三是基于調(diào)用次數(shù)的自動化伸縮，最后是容器的啟動速度。如果解決了這四個問題，那么這樣的容器平臺對使用者來說也是Serverless的。
目前Amazon Lambda、Google Cloud Functions、Microsoft Azure Functions、IBM OpenWhisk，以及Iron.io和Webtask 都提供了基于FaaS 的Serverless服務。AWS Lambda支持Node.js，Java和Python。Google Cloud Functions只支持Node.js，不過預計在將來會添加更多的語言。 IBM OpenWhisk支持Node.js，Swift 。Serverless Framework作為node.js NPM模塊來提供，填補了AWS Lambda存在的許多缺口。它提供了多個樣板模板，可以迅速啟動AWS Lambda的開發(fā)。Iron.io的serverless computing平臺其代號為Project Kratos，旨在將AWS Lambda引入到企業(yè)。無服務器技術的未來就像容器技術和微服務技術最初提出來時不完善一樣，Serverless模式也存在很多不完善的部分，無論是BaaS模式還是FaaS模式，都沒有完全解決產(chǎn)品，效率，成本之間的問題。但是相信通過不斷的實踐和迭代，未來會發(fā)展的更好，從而帶來一個新的技術變革熱潮，也期待新模式的Serverless的產(chǎn)生。擴展閱讀
