如果你曾經想過“應該有一個實現這種功能的應用”，并憧憬有誰能夠為你開發一個就好了，現在我們有一個好消息，那個人找到了，就是你自己。

　　Web應用可以是非常強大、高效和易擴展的，但卻不應該是復雜的。簡單就是Web應用的一大優勢。你可以利用這種優勢來搭建自己的解決方案，實現自己的創意。一旦了解所有模塊是如何搭建到一起的，你就能開發出想要的應用了。

　　本書是一本實用教程，將會演示一種無服務器的方案來搭建Web應用。使用這個方案，大部分運維方面的問題就不需要你自己操心了，而且也省去運行服務器的費用。你能集中時間和精力開發想要的應用，而讓其他人去考慮業務發展帶來的應用上線、配置、升級、擴展服務器等問題。使用多層Web框架、自動生成的代碼或者拷貝模板，這些方法并不會帶來這樣的好處。等我們一起學完本書，你就會知道如何通過移除部分代碼和消除中間層來交付更好的應用。

　　為了能夠快速演示開發過程，我們將使用一個預設好的工作空間，里面加載了搭建完整Web應用必需的所有模塊。首先，我們會完成一個單頁應用，用Java、HTML和CSS代碼來實現原來在服務器端實現的邏輯。我們將根據Web標準，深入挖掘單頁Web應用的必要功能，從零開始搭建，從而了解它們的運行機制，保證這種設計能符合我們應用的要求。當僅憑Web標準不能完全實現需求時，我們會使用jQuery來填補差距。最后，我們會使用測試優先的方法來漸進式開發，以保證單頁應用的可測試性。

　　為了降低中間層成本并確保我們的應用能供上百萬的用戶使用，我們使用Amazon Web Services（AWS）作為無服應用的后端。你將看到如何使用高可用、高可擴展、更便宜、更易維護的云服務來替換掉傳統Web應用的服務器、數據庫和負載均衡器。我們將討論在開發此類應用時會碰到的一些安全性問題，并會介紹隨著應用業務的擴展可能會用到的其他技術和工具。

　　我希望能夠讓你看到新的可能性。以前非常費時費錢的應用開發或許能變成一個人在一兩天內就可以完成的事情。隨著技術進步和個人能力的提升，更多的夢想將會實現。一旦理解了這些技術的發展，你就會發現從前因為太難而幾乎無法實現的目標，現在可以借由新途徑來達成。讀完本書，你將學會將創意變成真實應用所需的技能。

　　無服Web應用

　　在傳統Web應用中，服務器是系統不可缺少的組成部分。盡管有時候服務器的前面還有負載均衡器或者專用Web服務器，但完成大部分工作的還是應用服務器。它完成一個應用所有的必要功能，包括存儲用戶數據、進行安全認證、控制流程等。應用的頁面大部分僅僅只是為后端提供界面而已，盡管也會涉及一些控制導航的功能。使用這種許多人稱之為多層架構的傳統方式，系統一般會由瀏覽器、應用服務器和多個后端服務構成（見下圖）。

　　使用無服的方式，可以移除所有這些層次架構，達到更直接的實現。與其僅僅把網頁客戶端當作應用服務器的界面展示，不如構建一個單頁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萬的用戶，一天也只需要花費一杯咖啡的錢。

　?。ㄎⅲ┓沼押?/p>

　　這種方式可以輕松適應微服務或者其他的面向服務架構。你可以在系統中引入特定的服務以實現自定義身份認證、驗證或者異步數據處理。如果有必要，你甚至可以重新引入應用服務器，漸進式地重構應用。反之，如果一開始就使用一個中間層來控制所有的安全證書，就很難切換到需要認證的Web服務上。這些應用服務器沒辦法像無服應用一樣，在應用層管理身份信息。

　　代碼更少

　　在傳統Web應用里，一些操作（比如導航）在Web客戶端和服務器端都需要執行，造成了代碼的重復。有時候，這種重復工作并不明顯，尤其當服務器代碼是用不同的語言寫時。而在無服應用中，應用邏輯都移到了客戶端，很容易保證應用內不再有重復的代碼。將應用邏輯代碼放在一個位置（以及用一種語言實現）幫助我們解決了這個問題。

　　此外，無服的方式更便于構建和排錯，因為系統的組成部分變得更少了。Web應用天生就是分布式的，也就是說，正如CAP理論所述 ，它們在同一個網絡的節點間傳遞消息（一般是以請求和響應的形式），限制它們的是實現方式。

　　有些應用會比其他應用更分散（more distributed）。一個系統越分散，就越難排錯。移除應用中的中間層能減少其分散的程度。在我們這個簡單的應用中，如果一個客戶端需要從一個數據庫中獲取數據，就會直接連接數據庫，而不是通過中間層連接。這就意味著系統中的網絡節點更少，也意味著如果出現問題，需要定位的地方更少。

　　如上所述，構建一個無服應用的理由有很多。學完本書，你就會明白為什么這種方式如此強大。了解了無服應用的這些優點，我們再來看看它有哪些限制。

　　無服設計的限制

　　盡管無服架構有許多優點，但它也不是適用于所有類型的應用。為了享受這種設計帶來的益處，你必須接受一系列的限制。如果你的應用不能適應這些限制，那么它很可能不是最合適的構建方式。所以在搭建應用之前，讓我們一起看看這些限制。

　　供應商鎖定

　　首先最大的限制就是你使用的Web服務必須支持第三方身份認證服務商，這樣在云服務提供商的選擇上就受到了限制。所以如果使用無服的方式，你就會依賴于第三方服務，供應商鎖定也就成了一個問題。構建一個基于其他公司服務的系統，意味著這個應用的命運和供應商公司的命運綁在了一起。如果供應商公司被收購、破產或者改變商業模式，你的應用不下大力氣修改就很難在其他地方運行。所以，評估服務提供商的業務目標和長期穩定性與技術選型是同樣重要的。

　　奇怪的日志

　　所有運維關注的事情，比如應用日志，在你使用無服設計之后會呈現新的形態。當你把所有請求都通過一臺服務器路由時，記錄下所有信息以查看用戶正在做什么是非常簡單的事情。沒有了這種中心化設計，日志的記錄必須由每個支撐應用的不同Web服務來實現。這些日志格式跟大部分應用服務器日志都不同，記錄的數據也很可能是你不熟悉的。我們在后面第8章的“分析S3日志”會深入探討Web服務日志的分析。

　　不一樣的安全模型

　　對于無服應用，有些常見的安全隱患不復存在，但你將會遇到一些不熟悉的新問題。比如，為了安全而驗證用戶數據，結果不能在瀏覽器中安全地實現。你需要假設有些惡意用戶可能會在瀏覽器中劫持證書而使用該證書授權的Web服務。使用無服的方式，意味著你不能把瀏覽器中的應用驗證邏輯和安全驗證邏輯放在一起，必須分開實現。

　　Amazon提供的許多Web服務都能驗證請求。你可以參考第5章的“數據訪問和驗證”一節內容利用DynamoDB來實現。然而，對于有些應用來說，很難只用Web服務提供的工具來實現充分的有效性約束。比如，在瀏覽器中直接編寫文本時，你不可能放心地將寫入的數據編碼后存到數據庫中，保證不會有跨站腳本攻擊發生。因為攻擊者不使用應用就能直接將這個數據添加到數據庫。

　　這種情況下，你有（至少）兩個選擇。第一，可以假設某些用戶可編輯的表可能包含未經驗證的數據，然后針對性地設計系統的其他部分。比如，用戶只能寫入他們自己可讀取的數據，這是可行的方式。第二，可以將某些寫操作委托給自定義Web服務，比如可以使用Lambda函數來進行驗證，并且以一種安全的方式寫入數據。我們將會在第6章的“使用Lambda構建微服務”中詳細介紹。

相關電子資料下載

• Serverless 冷啟動：如何讓函數計算更快更強？ 96
• 華為云 FunctionGraph 函數工作流——?“Serverless“遇見”AI，釋放 AI 生產力 215
• 全域 Serverless 化，華為云引領下一代云計算新范式 192
• 體驗華為云 Serverless?FunctionGraph，一分鐘上線應用 194
• 體驗華為云 Serverless?FunctionGraph，一分鐘上線應用 137
• Serverless冷啟動：如何讓函數計算更快更強？ 168
• 資源成本降低 70%！華為 MetaERP 資產核算的 Serverless 架構實踐 184
• Luca Mezzalira：你真的為Serverless X AI做好準備了嗎？ 169
• Serverless計算產品為什么采用并發度作為擴縮容？ 570
• 華為云 Serverless 核心技術與最佳實踐 100