還記得在十多年前，SaaS鼻祖SalesForce喊出的口號『No Software』嗎？SalesForce在這個口號聲中開創了SaaS行業，併成爲當今市值520億美元的SaaS之王。今天談談『No Server』有關的事， 繼OpenStack、Docker 、MiscroService、Unikernel、Kubernetes和Mesos之後，ServerLess正成爲Google、AWS乃至創業公司暗戰的新戰場，它能否成爲雲計算領域的顛覆性趨勢？
我相信大家也會存在一些疑問： Serverless到底是什麼鬼？Serverless架構有啥優點，竟然讓IT界巨頭紛紛佈局？業界有哪些已經成功的產品使用了Serverless架構？我們的項目是否適合使用Serverless架構？Martin Fowler在2016.6.17號發表了一篇博客： 《Serverless Architectures》，引起業界的關注，同時Serverless與我們目前研發的產品相關，也進行一些研究與實踐。下面我將會從以下幾點進行分享：
Serverless的背景以及概念
Serverless與傳統架構比較
Serverless架構適合那些業務場景以及競品分析
Serverless理解容易存在誤區
一．Serverless的背景以及概念
1.1 Serverless的背景
當我們還在容器的浪潮中前行時，已經有一些革命先驅悄然佈局另外一個雲計算戰場：Serverless。
2014年11月14日，亞馬遜AWS發佈了新產品Lambda。當時Lambda被描述爲：一種計算服務，根據時間運行用戶的代碼，無需關心底層的計算資源。從某種意義上來說，Lambda姍姍來遲，它更像S3，更像雲計算的PaaS理念：客戶只管業務，無需擔心存儲和計算資源。而在此之前不久，2014年10月22日，谷歌今天收購了實時後端數據庫創業公司Firebase。Firebase聲稱開發者只需引用一個API庫文件就可以使用標準REST API的各種接口對數據進行讀寫操作，只需編寫 HTML＋CSS＋JavaScrip前端代碼，不需要服務器端代碼（如需整合，也極其簡單）。
相對於上兩者，Facebook 在2014年二月收購的 Parse，則側重於提供一個通用的後臺服務。不過這些服務被稱爲Serverless或no sever。想到PaaS了是嗎？很像，用戶不需要關心基礎設施，只需要關心業務，這是遲到的PaaS，也是更實用的PaaS。這很有可能將會變革整個開發過程和傳統的應用生命週期，一旦開發者們習慣了這種全自動的雲上資源的創建和分配，或許就再也回不到那些需要微應用配置資源的時代裏去了。
1.2 Serverless的概念
提到Serverless，大家都想到一張經典圖描述傳統的互聯應用架構圖與Serverless architactures的不同點，Serverless架構能夠讓開發者在構建應用的過程中無需關注計算資源的獲取和運維，由平臺來按需分配計算資源並保證應用執行的SLA，按照調用次數進行計費，有效的節省應用成本，如下所示:
Serverless是最新興起的架構模式，中文意思是“無服務器”架構。目前，業界並沒有給出明確的定義，把其分成兩種類型，分別爲“Backend as a Service” 和 “Functions as a Service”。
“Backend as a Service”即BaaS，是一種新型的雲服務，旨在爲移動和Web應用提供後端雲服務，實現對邏輯和狀態進行管理，包括雲端數據/文件存儲（例如Parse、Firebase）、消息推送（例如極光推送、個推）、應用數據分析等等。可以說BaaS是誕生於移動互聯網，爲了加速移動應用開發和降低成本而形成的開發架構。BaaS可以帶來後端能力的服務化，服務化也爲後端能力優化管理帶來了可能，這些能力通過服務開發者而誕生，重複的建設和規劃會在初期就得到避免。
開發者通過使用這些服務，實現自己的業務功能的同時，也會對服務的能力進一步提出要求，促進後端服務的發展。BaaS是在PaaS和SaaS之間，爲了滿足移動互聯網快速發展的需要，將後端的能力以服務形式提供，是在PaaS平臺開發能力的基礎上，用SaaS的思路，將後端能力服務化，讓開發者在此基礎上開發自己的Software解決方案。
“Functions as a Service”即FaaS，指這樣的應用，一部分服務邏輯由應用實現，但是跟傳統架構不同在於，他們運行於無狀態的容器中，可以由事件觸發，短暫的，完全被第三方管理，功能上FaaS就是不需要關心後臺服務器或者應用服務，只需關心自己的代碼即可。其中AWS Lambda是目前最佳的FaaS實現之一。
二．Serverless與傳統架構比較
傳統的互聯網APP主要採用C/S架構，服務器端需長期維持業務進程來處理客戶端請求，並調用代碼邏輯完成請求響應流程。而在Serverless架構中，應用業務邏輯將基於FAAS架構形成獨立爲多個相互獨立功能組件，並以API服務的形式向外提供服務；同時，不同功能組件間的邏輯組織代碼將存儲在Amazon Lambda，Azure Function，Google Cloud Functions等產品上，業務代碼僅在調用時才激活運行，當響應結束佔用資源便會釋放。
2.1 Serverless架構的優勢
低運營成本
在業務突發性極高的場景下，系統爲了應對業務高峯，必須構建能夠應對峯值需求的系統，這個系統在大部分時間是空閒的，這就導致了嚴重的資源浪費和成本上升。在微服務架構中，服務需要一直運行，實際上在高負載情況下每個服務都不止一個實例，這樣才能完成高可用性；在Serverless架構下，服務將根據用戶的調用次數進行計費，按照雲計算pay-as-you-go原則，如果沒有東西運行，你就不必付款，節省了使用成本。同時，用戶能夠通過共享網絡、硬盤、CPU等計算資源，在業務高峯期通過彈性擴容方式有效的應對業務峯值，在業務波谷期將資源分享給其他用戶，有效的節約了成本。
簡化設備運維
在原有的IT體系中，開發團隊即需要維護應用程序，同時還要維護硬件基礎設施；Serverless架構中，開發人員面對的將是第三方開發或自定義的API 和URL，底層硬件對於開發人員透明化了，技術團隊無需再關注運維工作，能夠更加專注於應用系統開發。
提升可維護性
Serverless架構中，應用程序將調用多種第三方功能服務，組成最終的應用邏輯。目前，例如登陸鑑權服務，雲數據庫服務等第三方服務在安全性、可用性、性能方面都進行了大量優化，開發團隊直接集成第三方的服務，能夠有效的降低開發成本，同時使得應用的運維過程變得更加清晰，有效的提升了應用的可維護性。
更快的開發速度
這一點在現在互聯網創業公司得到很好的體現，創業公司往往開始由於人員與資金等問題，不可能每個產品線都同時進行，這時候就可以考慮第三方的Baas平臺，比如使用阿里雲提供的RDS，極光推送的消息推送，Bmob支付以及地理位置等等，能夠很快進行產品開發的速度，把工作重點放在業務實現上，把產品更快的推向市場。
2.2 Serverless架構的缺點
廠商平臺綁定
平臺會提供Serverless架構給大玩家，比如AWS Lambda，運行它需要使用AWS指定的服務，比如API網關，DynamoDB，S3等等，一旦你在這些服務上開發一個複雜系統，你會粘牢AWS，以後只好任由他們漲價定價或者下架等操作，個性化需求很難滿足，不能進行隨意的遷移或者遷移的成本比較大，同時不可避免帶來一些損失。Baas行業內一個比較典型的事件，2016年1月19日Facebook關閉曾經花鉅額資金收購的Parse，造成用戶不得不遷移在這個平臺中產生一年多的數據，無疑需要花費比較大的人力和時間成本。
成功案例比較少，沒有行業標準
目前的情況也只適合簡單的應用開發，缺乏大型成功案例的推動。對於Serverless缺乏統一的認知以及相應的標準，無法適應所有的雲平臺。
三．Serverless架構適合
哪些業務場景以及競品分析
3.1 Serverless架構適合哪些業務場景
低頻請求場景
物聯網行業中，由於物聯網設備傳輸數據量小，且往往是固定時間間隔進行數據傳輸，因此經常涉及低頻請求場景。例如：物聯網應用程序每分鐘僅運行一次，每次運行50ms，這意味着CPU的使用率爲0.1%/小時，這也意味着其實有1000個相同的應用可以共享計算資源。而Serverless架構下，用戶可以購買每分鐘100ms的資源來滿足計算需求，通過這種方式就能夠有效解決效率問題，降低使用成本。
流量突發場景
移動互聯網應用經常會面對突發流量場景，例如：移動應用的通常流量情況是QPS 20，但每隔五分鐘會有一個持續10s的QPS 200流量（10倍於通常流量），傳統架構下企業必須擴展QPS 200的硬件能力來應對業務高峯，即使高峯時間僅佔整個運行時間的4%；而在Serverless架構下，用戶可以利用彈性擴展特性，快速構建新的計算能力來滿足當前需求，當業務高峯後，資源能夠自動釋放，有效節省成本。
3.2 Serverless架構業界競品分析
AWS Lamdba
提到Serverless的業界競品，我們第一個會想到AWS Lamdba，通過 AWS Lambda，無需配置或管理服務器即可運行代碼。您只需按消耗的計算時間付費 – 代碼未運行時不產生費用。藉助 Lambda，您幾乎可以爲任何類型的應用程序或後端服務運行代碼，而且全部無需管理。只需上傳您的代碼，Lambda 會處理運行和擴展高可用性代碼所需的一切工作。您可以將您的代碼設置爲自動從其他 AWS 服務觸發，或者直接從任何 Web 或移動應用程序調用，關於Lambda的優勢如下圖所示：
FaceBook Parse
Parse是一個完整的 iOS,android 後端支持平臺，它可以讓開發者完成忘掉服務器端的事情，包含了 schema free 的數據存儲和雲代碼（CloudCode）。其數據存儲服務涵蓋了結構化的對象存儲和非結構化的文件存儲（也包括 CDN），並且，Parse 提供了完善的賬戶系統和數據訪問控制，而且提供了強大的數據關聯（一對一、一對多、多對多等）和查詢能力。除此之外，由於定位於通用的後臺服務，所以在標準化 API 之外，Parse 也提供了方法讓開發者可以定製自己的商業邏輯。他們的做法是建立一個 node.js 容器，讓開發者使用 javascript 這種廣爲人知的前端語言來完成數據整合、計算，再將結果返回給客戶端。具體如下圖所示：
Bmob
國內最近幾年BaaS的發展也很迅速，可以說目前國內的創業環境和這些BaaS服務的發展相輔相成。目前國內在BaaS中除了互聯網巨頭外，領頭的公司有Leancloud，Bmob等。Bmob是我曾經在一家創業公司使用過的產品，當時使用了它的移動支付和推送服務的功能，做的類似最近比較火的“在行”和“分答”（知識經濟共享），對於初期想把產品推向市場檢驗自己的Idea來說是不錯的，既節約人力與維護成本，也加快了開發速度。該平臺爲移動應用提供了一個完整的後端解決方案，讓開發者以最小的配置和最簡單的方式使用Bmob平臺提供的服務，進而完全消除開發者編寫服務器代碼以及維護服務器的操作。主要功能有：
（1）數據服務：可視化的雲端NoSQL數據庫設計，支持豐富的數據類型，靈活方便的增刪改查，可視化的數據操作，安全的角色和ACL管理，數據的批量處理，本地數據緩存，讓開發者們可以不需要關注服務器後端的事情。
（2）移動支付：無需第三方申請審覈，不論個人開發者還是企業都可快速接入移動支付功能，接入渠道現支持支付寶支付和微信支付。
（3）推送服務：提供了Android和iOS兩個版本的推送服務，採用Websocket保持長連接，穩定性更好，目前，64GB的單機能夠支撐600萬的用戶長連接;
（4）擴展服務：容器服務、定時任務、地理位置、雲端邏輯等擴展服務，確保您的個性化業務邏輯能夠在雲端更好的運轉。
四．Serverless理解容易存在誤區
4.1 不能簡單理解爲PaaS
對於Serverless的理解，Adrian Cockcroft曾經這樣說過“如果你的PaaS可以將以前半秒啓動的應用在20ms內啓動，就叫它Serverless”，換句話說，許多PaaS應用不會每次請求來了啓動，請求結束則關閉，可以認爲FaaS是一種特殊化的PaaS。但是又存在一些不同點，FaaS讓用戶更加註重自己的業務，不需要關注代碼部署以及部署到那個服務器，甚至不需要考慮可擴展性（scaling），而PaaS平臺會考慮這些因素。
4.2 NoOps並不意味着“免運維”
Serverless並不意味着“免維護”，應該意味着“不需定時維護“。Serverless不代表完全去除服務器，而是代表去除有關對服務器運行狀態的關心和擔心，以及透明化基礎設施。首先“Ops”意味着比服務器維護更多的內容，Serverless不要關注基礎設施以及服務器，但是針對應用還是存在監控、網絡、安全，以及產品排錯等問題，這些問題對於Serverless應用來說仍然還在，需要一種策略來處理。
總結
本文從業內發展趨勢引出Serverless架構，然後分成幾大模塊進行講解：
第一部分，Serverless背景來源以及其概念定義，Serverless代表無服務器計算技術崛起， 是新一代雲服務和開發架構的實踐，主要分爲BaaS和FaaS兩部分；
第二部分，Serverless架構與傳統架構比較的優缺點，Serverless架構低運營成本、簡單化運維與高效開發速度等優點，同時也帶來平臺商的綁架以及目前技術不夠成熟等問題存在；
第三部分，Serverless架構適合那些業務場景以及競品分析；
第四部分，主要講解對於Serverless架構，一些大家容易出現偏差的概念。
Serverless代表無服務器計算技術崛起， 是微服務的一種表現形式，是新一代雲服務和開發架構的實踐，是雲計算髮展重點方向之一。Serverless架構是BaaS實現的精髓，是BaaS進一步的解讀，FaaS（Function as a service)是BaaS中雲代碼的實現方式。作爲使用方我們不僅熟悉業內Serverless架構的經典產品，而且需要進行學習進而開發屬於自己Serverless產品，或者能夠很好的進行選型爲自己產品快速的開發與運營提供基礎條件。
普元雲計算專區：http://primeton.csdn.net/m/zone/primeton/index#
普元公衆號：
