914
采用Serverless架構搭建Web應用
本文會向你介紹一種新的可能，一種無服務器的方案來搭建Web應用。使用這個方案大部分運維方麵的問題就不需要你自己操心了，而且也省去運行服務器的費用。本文從無服務的優勢與限製兩方麵帶您初識Serverless設計。
在傳統Web應用中，服務器是係統不可缺少的組成部分。盡管有時候服務器的前麵還有負載均衡器或者專用Web服務器，但完成大部分工作的還是應用服務器。它完成一個應用所有的必要功能，包括存儲用戶數據、進行安全認證、控製流程等。應用的頁麵大部分僅僅隻是為後端提供界麵而已，盡管也會涉及一些控製導航的功能。使用這種許多人稱之為多層架構的傳統方式，係統一般會由瀏覽器、應用服務器和多個後端服務構成（見下圖）。
使用Serverless（無服）的方式，可以移除所有這些層次架構，達到更直接的實現。與其僅僅把網頁客戶端當作應用服務器的界麵展示，不如構建一個單頁Web應用在瀏覽器中實現應用邏輯。這意味著你隻需要一個簡單的靜態網頁服務器，所有的交互都隻不過是應用內容的傳輸而已，瀏覽器就像是一個應用容器。這樣，最終的設計就是移除傳統Web應用架構中所有的中間層次，允許瀏覽器直接連接到它所需要的服務上。
使用Facebook、Google和Twitter之類的OAuth 2.0身份認證服務商提供的服務，無須保存用戶密碼就可以創建用戶身份。如果要存儲數據，你可以在瀏覽器端直接使用Amazon DynamoDB之類的服務。在瀏覽器中無法執行的函數都可以使用Amazon Lambda微服務或者其他專門的Web服務來處理。除了能夠簡化架構，這種切換到Web服務作為後端的方式，還能讓應用獲得這些服務與生俱來的可用性和可擴展性優勢。
你可能會好奇到底發生了什麼，使這種方式成為可能。為什麼現在在一個Web應用中，中間層的應用服務器變得可有可無呢？答案是，自從2015年以來，類似Amazon這樣的雲服務提供商開始對外提供服務的API，這使得無服務器的方式成為可能，Amazon本身也為如何使用他們的工具和基礎設施提供了最好的示範。
基於Web標準搭建一個單頁Web應用，而不是使用服務器端Web框架來完成，我們可以快速應用一些新興技術。例如，我們不再需要將應用的數據模型綁定到任何一個對象層級或者數據同步機製上，因而能更方便地集成不同服務。既然我們所有的工作都倚賴於Web，就不必拘泥於以前搭建Web應用的成見，可以用目前最新的技術來搭建應用（見下圖）。
無服設計的好處
如果你在尋找一種快速搭建低成本Web應用的方法，無服Web應用很可能就是一個解決方案。不需要花費時間和精力了解傳統Web應用技術棧的各個層級，采用這種方式你能更專注於實現業務功能，有人會為你操心運行維護和可擴展性的問題。接下來讓我們深入探討無服設計的好處，幫助你在考慮下一個項目中是否使用這種方式時做出更明智的決定。
１. 零服務器
無服設計最明顯的好處就是不需要維護服務器（不管是物理的還是虛擬的）。你不需要擔心打安全補丁、監控CPU和內存使用情況、回滾日誌、磁盤空間不足或者其他在維護自有服務器時經常碰到的運維問題。和大多數平台即服務（PaaS）方式一樣，無服設計能讓你專注於應用開發，而無須擔心基礎設施的問題。
２. 易擴展
這種設計方式的另一大好處是，你可以依靠雲服務供應商來擴展自己的應用。在做水平擴容時，不需要忙不顛地在幾個負載均衡應用服務器之間保持數據的一致性，你可以直接連接Web服務，而它們已經解決了數據一致性的問題。這意味著不管你的應用有幾個用戶、幾百個用戶，還是幾十萬個用戶，隻需要修改Amazon Web Services控製台的一些設置就可以保證完美的運行。
３. 高可用
另外，使用這種設計能輕鬆實現高可用性。你不必為了升級而關閉應用服務器，或者為了實現“熱”部署而擴建基礎設施。不再會有服務的重啟或者部署包在服務器間的拷貝。最妙的是，Amazon有一群訓練有素的員工7×24小時守護著你的基礎設施，一旦發現問題隨時能夠響應。
４. 低成本
這些服務的成本可以非常低。使用無服的方式以及利用Amazon的免費套餐（Free Tier），一個月支付幾美分就可以運行你的應用。一旦超過了免費額度，其費用經常也是隨著你的用戶量線性增長的（考慮費用最高的情況）。我們在這本書裏構建的應用就算擴展到100萬的用戶，一天也隻需要花費一杯咖啡的錢。
５. （微）服務友好
這種方式可以輕鬆適應微服務或者其他的麵向服務架構。你可以在係統中引入特定的服務以實現自定義身份認證、驗證或者異步數據處理。如果有必要，你甚至可以重新引入應用服務器，漸進式地重構應用。反之，如果一開始就使用一個中間層來控製所有的安全證書，就很難切換到需要認證的Web服務上。這些應用服務器沒辦法像無服應用一樣，在應用層管理身份信息。
６. 代碼更少
在傳統Web應用裏，一些操作（比如導航）在Web客戶端和服務器端都需要執行，造成了代碼的重複。有時候，這種重複工作並不明顯，尤其當服務器代碼是用不同的語言寫時。而在無服應用中，應用邏輯都移到了客戶端，很容易保證應用內不再有重複的代碼。將應用邏輯代碼放在一個位置（以及用一種語言實現）幫助我們解決了這個問題。
此外，無服的方式更便於構建和排錯，因為係統的組成部分變得更少了。Web應用天生就是分布式的，也就是說，正如CAP理論所述 ，它們在同一個網絡的節點間傳遞消息（一般是以請求和響應的形式），限製它們的是實現方式。
有些應用會比其他應用更分散（more distributed）。一個係統越分散，就越難排錯。移除應用中的中間層能減少其分散的程度。在我們這個簡單的應用中，如果一個客戶端需要從一個數據庫中獲取數據，就會直接連接數據庫，而不是通過中間層連接。這就意味著係統中的網絡節點更少，也意味著如果出現問題，需要定位的地方更少。
如上所述，構建一個無服應用的理由有很多。學完本書，你就會明白為什麼這種方式如此強大。了解了無服應用的這些優點，我們再來看看它有哪些限製。
無服設計的限製
盡管無服架構有許多優點，但它也不是適用於所有類型的應用。為了享受這種設計帶來的益處，你必須接受一係列的限製。如果你的應用不能適應這些限製，那麼它很可能不是最合適的構建方式。所以在搭建應用之前，讓我們一起看看這些限製。
１. 供應商鎖定
首先最大的限製就是你使用的Web服務必須支持第三方身份認證服務商，這樣在雲服務提供商的選擇上就受到了限製。所以如果使用無服的方式，你就會依賴於第三方服務，供應商鎖定也就成了一個問題。構建一個基於其他公司服務的係統，意味著這個應用的命運和供應商公司的命運綁在了一起。如果供應商公司被收購、破產或者改變商業模式，你的應用不下大力氣修改就很難在其他地方運行。所以，評估服務提供商的業務目標和長期穩定性與技術選型是同樣重要的。
２. 奇怪的日誌
所有運維關注的事情，比如應用日誌，在你使用無服設計之後會呈現新的形態。當你把所有請求都通過一台服務器路由時，記錄下所有信息以查看用戶正在做什麼是非常簡單的事情。沒有了這種中心化設計，日誌的記錄必須由每個支撐應用的不同Web服務來實現。這些日誌格式跟大部分應用服務器日誌都不同，記錄的數據也很可能是你不熟悉的。
３. 不一樣的安全模型
對於無服應用，有些常見的安全隱患不複存在，但你將會遇到一些不熟悉的新問題。比如，為了安全而驗證用戶數據，結果不能在瀏覽器中安全地實現。你需要假設有些惡意用戶可能會在瀏覽器中劫持證書而使用該證書授權的Web服務。使用無服的方式，意味著你不能把瀏覽器中的應用驗證邏輯和安全驗證邏輯放在一起，必須分開實現。
Amazon提供的許多Web服務都能驗證請求。然而，對於有些應用來說，很難隻用Web服務提供的工具來實現充分的有效性約束。比如，在瀏覽器中直接編寫文本時，你不可能放心地將寫入的數據編碼後存到數據庫中，保證不會有跨站腳本攻擊發生。因為攻擊者不使用應用就能直接將這個數據添加到數據庫。
這種情況下，你有（至少）兩個選擇。第一，可以假設某些用戶可編輯的表可能包含未經驗證的數據，然後針對性地設計係統的其他部分。比如，用戶隻能寫入他們自己可讀取的數據，這是可行的方式。第二，可以將某些寫操作委托給自定義Web服務，比如可以使用Lambda函數來進行驗證，並且以一種安全的方式寫入數據。我們將會在第6章的“使用Lambda構建微服務”中詳細介紹。
４. 不一樣的身份模型
外部身份管理是我們這本書構建的應用中的一個獨特功能。使用Web服務來管理身份信息有很多好處，但對你來說這種機製可能有點陌生。與將用戶信息和其他數據保存在一起的傳統方式不同，這些用戶資料會保存在一個獨立訪問的數據存儲服務中。如果使用這種方式構建無服應用，一些在數據庫中處理用戶數據的方法（比如用一個ID關聯一張User表）就沒辦法實現。
５. 失去控製
此外，將所有請求路由到統一的中間層可以實現某種程度的控製，這在某些情況下是非常有用的。比如，拒絕訪問攻擊和其他一些攻擊有時候可以在應用服務器上進行阻截。對你而言，放棄對身份認證的直接控製可能想一想都覺得可怕。我們後麵在第7章會用一整章來專門探討這些安全問題。
６. 規模與成本的關係
最後，你需要了解這些服務的開銷。雖然能夠自動擴展應用這一點非常厲害，但易於擴展同時也意味著花錢更容易。你需要了解這些服務的定價策略以及當用戶增加時這些價格的變化。
既然你已經了解了無服Web應用的代價，我們可以開啟這本教程，探索一下無服Web應用是如何實現的。在教程中，你可能會發現這種設計方式為你開發的Web應用帶來的其他好處和限製。一旦知曉了無服應用的全貌，就可以判斷下一個項目是否適合這種方式了。
本文選自《Serverless架構：無服務器單頁應用開發》，點此鏈接可在博文視點官網查看此書。
想及時獲得更多精彩文章，可在微信中搜索“博文視點”或者掃描下方二維碼並關注。
最後更新：2017-08-13 22:35:20