# 理解Serverless No silver bullet. - The Mythical Man-Month 許多年前，我們開發的軟件還是C/S（客戶端/服務器）和MVC（模型-試圖-控制器）的形式，再后來有了SOA，最近幾年又出現了微服務架構，更新一點的有Cloud Native（云原生）應用，企業應用從單體架構，到服務化，再到更細粒度的微服務化，應用開發之初就是為了應對互聯網的特有的高并發、不間斷的特性，需要很高的性能和可擴展性，人們對軟件開發的追求孜孜不倦，希望力求在軟件開發的復雜度和效率之間達到一個平衡。但可惜的是，NO SILVER BULLET！幾十年前（1975年）Fred Brooks就在The Mythical Man-Month中就寫到了這句話。那么Serverlss會是那顆銀彈嗎？ 云改變了我們對操作系統的認知，原來一個系統的計算資源、存儲和網絡是可以分離配置的，而且還可以彈性擴展，但是長久以來，我們在開發應用時始終沒有擺脫的服務器的束縛（或者說認知），應用必須運行在不論是實體還是虛擬的服務器上，必須經過部署、配置、初始化才可以運行，還需要對服務器和應用進行監控和管理，還需要保證數據的安全性，這些云能夠幫我們簡化嗎？**讓我們只要關注自己代碼的邏輯就好了，其它的東西讓云幫我實現就好了。** ## Serverless介紹 Serverless架構是云的自然延伸，為了理解serverless，我們有必要回顧一下云計算的發展。 ### IaaS 2006年AWS推出EC2（Elastic Compute Cloud），作為第一代IaaS（Infrastructure as a Service），用戶可以通過AWS快速的申請到計算資源，并在上面部署自己的互聯網服務。IaaS從本質上講是服務器租賃并提供基礎設施外包服務。就比如我們用的水和電一樣，我們不會自己去引入自來水和發電，而是直接從自來水公司和電網公司購入，并根據實際使用付費。 EC2真正對IT的改變是硬件的虛擬化（更細粒度的虛擬化），而EC2給用戶帶來了以下五個好處： - 降低勞動力成本：減少了企業本身雇傭IT人員的成本 - 降低風險：不用再像自己運維物理機那樣，擔心各種意外風險，EC2有主機損壞，再申請一個就好了。 - 降低基礎設施成本：可以按小時、周、月或者年為周期租用EC2。 - 擴展性：不必過早的預期基礎設施采購，因為通過云廠商可以很快的獲取。 - 節約時間成本：快速的獲取資源開展業務實驗。 以上說了是IaaS或者說基礎設施外包的好處，當然其中也有弊端，我們將在后面討論。 以上是AWS為代表的公有云IaaS，還有使用[OpenStack](https://www.openstack.org/)構建的私有云也能夠提供IaaS能力。 ### PaaS PaaS（Platform as a Service）是構建在IaaS之上的一種平臺服務，提供操作系統安裝、監控和服務發現等功能，用戶只需要部署自己的應用即可，最早的一代是Heroku。Heroko是商業的PaaS，還有一個開源的PaaS——[Cloud Foundry](https://www.cloudfoundry.org/)，用戶可以基于它來構建私有PaaS，如果同時使用公有云和私有云，如果能在兩者之間構建一個統一的PaaS，那就是“混合云”了。 在PaaS上最廣泛使用的技術就要數[docker](https://www.docker.com/)了，因為使用容器可以很清晰的描述應用程序，并保證環境一致性。管理云上的容器，可以稱為是CaaS（Container as a Service），如[GCE（Google Container Engine）](https://cloud.google.com/container-engine/)。也可以基于[Kubernetes](https://kubernetes.io)、[Mesos](http://mesos.apache.org/)這類開源軟件構件自己的CaaS，不論是直接在IaaS構建還是基于PaaS。 PaaS是對軟件的一個更高的抽象層次，已經接觸到應用程序的運行環境本身，可以由開發者自定義，而不必接觸更底層的操作系統。 ## Serverless的定義 Serverless不如IaaS和PaaS那么好理解，因為它通常包含了兩個領域BaaS（Backend as a Service）和FaaS（Function as a Service）。 ### BaaS BaaS（Backend as a Service）后端即服務，一般是一個個的API調用后端或別人已經實現好的程序邏輯，比如身份驗證服務Auth0，這些BaaS通常會用來管理數據，還有很多公有云上提供的我們常用的開源軟件的商用服務，比如亞馬遜的RDS可以替代我們自己部署的MySQL，還有各種其它數據庫和存儲服務。 ### FaaS FaaS（Functions as a Service）函數即服務，FaaS是無服務器計算的一種形式，當前使用最廣泛的是AWS的Lambada。 現在當大家討論Serverless的時候首先想到的就是FaaS，有點甚囂塵上了。FaaS本質上是一種事件驅動的由消息觸發的服務，FaaS供應商一般會集成各種同步和異步的事件源，通過訂閱這些事件源，可以突發或者定期的觸發函數運行。  傳統的服務器端軟件不同是經應用程序部署到擁有操作系統的虛擬機或者容器中，一般需要長時間駐留在操作系統中運行，而FaaS是直接將程序部署上到平臺上即可，當有事件到來時觸發執行，執行完了就可以卸載掉。  ### 總結 兩者都為我們的計算資源提供了彈性的保障，BaaS其實依然是服務外包，而FaaS使我們更加關注應用程序的邏輯，兩者使我們不需要關注應用程序所在的服務器，但實際上服務器依然是客觀存在的。 當我們將應用程序遷移到容器和虛擬機中時，其實對于應用程序本身的體系結構并沒有多少改變，只不過有些流程和規定需要遵守，比如12因素應用守則，但是serverlss對應用程序的體系結構來說就是一次顛覆了，通常我們需要考慮事件驅動模型，更加細化的不熟形式，以及在FaaS組件之外保持狀態的需求。 ## Serverless應用 我們以一個游戲應用為例，來說明什么是serverless應用。 一款移動端游戲至少包含如下幾個特性： - 移動端友好的用戶體驗 - 用戶管理和權限認證 - 關卡、升級等游戲邏輯，游戲排行，玩家的等級、任務等信息 傳統的應用程序架構可能是這樣的：  - 一個app前端，iOS后者安卓 - 用Java寫的后端，使用JBoss或者Tomcat做server運行 - 使用關系型數據庫存儲用戶數據，如MySQL 這樣的架構可以讓前端十分輕便，不需要做什么應用邏輯，只是負責渲染用戶界面，將請求通過HTTP發送給后端，而所有的數據操作都是有由后端的Java程序來完成的。 這樣的架構開發起來比較容易，但是維護起來確十分復雜，前端開發、后端的開發都需要十分專業的人員、環境的配置，還要有人專門維護數據庫、應用的更新和升級。  而在serverless架構中，我們不再需要在服務器端代碼中存儲任何會話狀態，而是直接將它們存儲在NoSQL中，這樣將使應用程序無狀態，有助于彈性擴展。前端可以直接利用BaaS而減少后端的編碼需求，這樣架構的本質上是減少了應用程序開發的人力成本，降低了自己維護基礎設施的風險，而且利用云的能力更便于擴展和快速迭代。 ## Serverless的優勢 在最前面我們提到了使用IaaS給我們帶來了五點好處，FaaS當然也包括了這些好處，但是它給我們帶來的最大的好處就是**多快好省**。減少從概念原型到實施的等待時間，比自己維護服務更省錢。 **降低人力成本** 不需要再自己維護服務器，操心服務器的各種性能指標和資源利用率，而是關心應用程序本身的狀態和邏輯。而且serverless應用本身的部署也十分容易，我們只要上傳基本的代碼但愿，例如Javascript或Python的源代碼的zip文件，以及基于JVM的語言的純JAR文件。不需使用Puppet、Chef、Ansible或Docker來進行配置管理，降低了運維成本。同時，對于運維來說，也不再需要監控那些更底層的如磁盤使用量、CPU使用率等底層和長期的指標信息，而是監控應用程序本身的度量，這將更加直觀和有效。 在此看來有人可能會提出“NoOps”的說法，其實這是不存在的，只要有應用存在的一天就會有Ops，只是人員的角色會有所轉變，部署將變得更加自動化，監控將更加面向應用程序本身，更底層的運維依然需要專業的人員去做。 **降低風險** 對于組件越多越復雜的系統，出故障的風險就越大。我們使用BaaS或FaaS將它們外包出去，讓專業人員來處理這些故障，有時候比我們自己來修復更可靠，利用專業人員的知識來降低停機的風險，縮短故障修復的時間，讓我們的系統穩定性更高。 **減少資源開銷** 我們在申請主機資源一般會評估一個峰值最大開銷來申請資源，往往導致過度的配置，這意味著即使在主機閑置的狀態下也要始終支付峰值容量的開銷。對于某些應用來說這是不得已的做法，比如數據庫這種很難擴展的應用，而對于普通應用這就顯得不太合理了，雖然我們都覺得即使浪費了資源也比當峰值到來時應用程序因為資源不足而掛掉好。 解決這個問題最好的辦法就是，不計劃到底需要使用多少資源，而是根據實際需要來請求資源，當然前提必須是整個資源池是充足的（公有云顯然更適合）。根據使用時間來付費，根據每次申請的計算資源來付費，讓計費的粒度更小，將更有利于降低資源的開銷。這是對應用程序本身的優化，例如讓每次請求耗時更短，讓每次消耗的資源更少將能夠顯著節省成本。 **增加縮放的靈活性** 以AWS Lamba為例，當平臺接收到第一個觸發函數的事件時，它將啟動一個容器來運行你的代碼。如果此時收到了新的事件，而第一個容器仍在處理上一個事件，平臺將啟動第二個代碼實例來處理第二個事件。AWS lambad的這種自動的零管理水平縮放，將持續到有足夠的代碼實例來處理所有的工作負載。 但是，AWS仍然只會向您收取代碼的執行時間，無論它需要啟動多少個容器實例要滿足你的負載請求。例如，假設所有事件的總執行時間是相同的，在一個容器中按順序調用Lambda 100次與在100個不同容器中同時調用100次Lambda的成本是 一樣的。當然AWS Lambada也不會無限制的擴展實例個數，如果有人對你發起了DDos攻擊怎么辦，那么不就會產生高昂的成本嗎？AWS是有默認限制的，默認執行Lambada函數最大并發數是1000。 **縮短創新周期** 小團隊的開發人員正可以在幾天之內從頭開始開發應用程序并部署到生產。使用短而簡單的函數和事件來粘合強大的驅動數據存儲和服務的API。完成的應用程序具有高度可用性和可擴展性，利用率高，成本低，部署速度快。 以docker為代表的容器技術僅僅是縮短了應用程序的迭代周期，而serverless技術是直接縮短了創新周期，從概念到最小可行性部署的時間，讓初級開發人員也能在很短的時間內完成以前通常要經驗豐富的工程師才能完成的項目。 ## Serverless的劣勢 我們知道沒有十全十美的技術，在說了serverless的那么多優勢之后，我們再來探討以下serverless的劣勢，或者說局限性和適用場景。 **狀態管理** 要想實現自由的縮放，無狀態是必須的，而對于有狀態的服務，使用serverless這就喪失了靈活性，有狀態服務需要與存儲交互就不可避免的增加了延遲和復雜性。 **延遲** 應用程序中不同組件的訪問延遲是一個大問題，我們可以通過使用專有的網絡協議、RPC調用、數據格式來優化，或者是將實例放在同一個機架內或同一個主機實例上來優化以減少延遲。 而serverless應用程序是高度分布式、低耦合的，這就意味著延遲將始終是一個問題，單純使用serverless的應用程序是不太現實的。 **本地測試** Serverless應用的本地測試困難是一個很棘手的問題。雖然可以在測試環境下使用各種數據庫和消息隊列來模擬生產環境，但是對于無服務應用的集成或者端到端測試尤其困難，很難在本地模擬應用程序的各種連接，并與性能和縮放的特性結合起來測試，并且serverless應用本身也是分布式的，簡單的將無數的FaaS和BaaS組件粘合起來也是有挑戰性的。