無服務(wù)器架構(gòu)的最佳實(shí)踐

無服務(wù)器架構(gòu)的最佳實(shí)踐無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第1頁。無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第1頁。無服務(wù)器架構(gòu)的最佳實(shí)踐

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第2頁。無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第2頁。目錄1. 拋棄Python 32. 推翻掉之前的架構(gòu) 63. 盡情享受Vue 74. 愛上DynamoDB 95. 無服務(wù)器框架 116. 認(rèn)證授權(quán) 127. 規(guī)劃與展望 14

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第3頁。公司決定走向無服務(wù)器架構(gòu)。最初我花了幾個月時(shí)間來嘗試將PythonFlask應(yīng)用程序[1]遷移到Lambda，這些經(jīng)歷幫助我后來找到更好的方法。

在六個月之后，我們已在無服務(wù)化地部署我們的第四個主要項(xiàng)目。以下將講述我們在此過程中學(xué)習(xí)到的經(jīng)驗(yàn)以及對此的一些強(qiáng)烈建議。無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第3頁。拋棄PythonFlask是一個挺不錯的小框架，用于由服務(wù)器管理會話的站點(diǎn)，使用舊式的請求-響應(yīng)方式。在交互式網(wǎng)絡(luò)的新世界中，這就像是用橡皮筋和橡皮刮板來試圖建造一個房子一樣，非常古怪。

舊式的部署架構(gòu)

當(dāng)你開始將更多工作轉(zhuǎn)移到客戶端這邊以支持交互時(shí)，你沒有其他選擇只能選擇JavaScript。這通常會導(dǎo)致（很多奇怪的東西）內(nèi)嵌到Python模板里，而技術(shù)債務(wù)則越積累越多。

Flask的解決方案逐漸成為不同語言的集合體。很快我就得出結(jié)論，這種方法將會造成一些可怕的混亂，導(dǎo)致我開始懷疑我為何要再使用Python了。

在切換到Node之后，很多東西都變得可維護(hù)且合理，并且也不再需要使用多種語言。通過Webpack上簡單的Node/Express配置，你還可以使用ES6來消除Python開發(fā)者帶來的糟無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第4頁。糕的JavaScript的代碼結(jié)構(gòu)。

在Zapppa/Flask嘗試做同樣的事情簡直比登記納稅更不友好。在5分鐘內(nèi)，你可以構(gòu)建一個可以在Lambda上運(yùn)行的完全成熟的Node/Express應(yīng)用程序，就像1040EZ那樣，這非常簡單。所以我們放棄了Python并加入了JavaScript的陣營。

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第4頁。將Lambda函數(shù)作為整體

為此我們放棄了什么呢？Python支持者們會聲情并茂地向你推薦所有酷炫的語言特性，但與JavaScript的實(shí)際異步魅力相比，這些僅僅只是玩具。而且我們現(xiàn)在也不需要再擔(dān)心使用Python2還是Python3了（也不知我們到底有沒有升級過……）。至少在我們的項(xiàng)目上，我們很容易就完成了轉(zhuǎn)換。

當(dāng)然，BenKehoe還拋出了一項(xiàng)引人注目但同時(shí)令人震驚的[2]觀點(diǎn)：在無服務(wù)器架構(gòu)中利用Python替代Node。

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第5頁。無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第5頁。

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第6頁。推翻掉之前的架構(gòu)無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第6頁。我們花費(fèi)了大量的時(shí)間才意識到無服務(wù)器架構(gòu)的明顯好處，可能是因?yàn)槲覀円恢笔窃跇?gòu)建Web應(yīng)用程序（閉門造車），或者也有可能只是因?yàn)槲依狭恕?/p>

我們最初的一些Web應(yīng)用程序仍然有一個NodeExpress層來記住會話狀態(tài)，（1）希望用戶能總是請求到同一個Lambda容器，（2）悲劇的是在設(shè)計(jì)中也濫用了DynamoDB來保持會話ID。我們到底在做什么？！

在過渡時(shí)期的第一階段，我們做了錯誤且可怕的就是我們的中間層跟Lambda上的Web服務(wù)器一樣，導(dǎo)致我們最終得到了到處是JavaScript去調(diào)用RESTAPI的html頁面。這種做法非常原始，極度難以維護(hù)，并且很快就變得脆弱，但我們已經(jīng)移除了中間層。在無服務(wù)器架構(gòu)中，中間層必須去除。

應(yīng)用狀態(tài)移到客戶端，業(yè)務(wù)邏輯遷去Lamdba

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第7頁。盡情享受Vue無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第7頁。能夠?qū)⑺袞|西都塞進(jìn)前端感覺非常棒，但它很快就發(fā)展成一個令人震驚的混亂局面。你最終停止代碼審查，因?yàn)槟阌X得分享你一直在開發(fā)的那些華而不實(shí)的機(jī)器語言黑魔法太尷尬了。并且“不審查代碼”對開發(fā)人員來說不是一個很好的工作目標(biāo)。

我在了解單頁應(yīng)用（SPA）領(lǐng)域時(shí)接觸到了React，它是當(dāng)前最流行的構(gòu)建用戶界面的方案。React很棒，但是它的學(xué)習(xí)曲線陡峭，有很多Webpack/Babel相關(guān)的設(shè)置，并且引入了JSX。雖然它可能是我們最終使用的東西，但它對于我們的當(dāng)前需求來說太重了，所以需要調(diào)研其他替代方案。

幸運(yùn)的是我很快就發(fā)現(xiàn)了Vue.js，我的無服務(wù)器生活開始走向極樂。事情是這樣的：你甚至可以在一天內(nèi)就學(xué)完Vue！

Vue的設(shè)計(jì)方法非常適合我們的設(shè)計(jì)模型，一切都是能自管理內(nèi)容，設(shè)計(jì)和代碼的組件。這使得管理我們的多個客戶端項(xiàng)目和分散的團(tuán)隊(duì)變得非常容易，并且非常適合無服務(wù)器的思維模式。

這個開源的JavaScript框架為你提供強(qiáng)大的調(diào)試工具，出色的組織以及能為你節(jié)省數(shù)小時(shí)的開箱即用的Webpack構(gòu)建。尤其是路由和商店管理插件，你可以像Facebook工程師那樣制作實(shí)時(shí)有趣的應(yīng)用。誰能想到制作單頁應(yīng)用可以這么簡單？

從無服務(wù)器的角度來看，Vue將你的所有實(shí)現(xiàn)代碼編譯成index.html和bundle.js文件，并可上傳到S3。新的編譯命令僅需簡單運(yùn)行npmrunbuild。

仔細(xì)想想，在以前，我們通過ElasticBeanstalk部署應(yīng)用并監(jiān)控利用率，在需要時(shí)進(jìn)行自動擴(kuò)展以及還需要管理合理的基礎(chǔ)架構(gòu)。

SPA真正的神奇之處在于，當(dāng)你部署應(yīng)用程序時(shí)，你只需將index.html，bundle.js和少量文件依賴項(xiàng)復(fù)制到由CloudFront分發(fā)前端的S3存儲塊中。這為你提供了穩(wěn)定的分布式和加載行無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第8頁。為，并且還支持多版本管理以及任何你想要的部署方法，可能只需管理文本文件。

理論上來說我們能將規(guī)模擴(kuò)展到無限，同時(shí)只對我們已使用的服務(wù)付費(fèi)，其中完全沒有應(yīng)用程序基礎(chǔ)設(shè)施管理成本。

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第8頁。

Vue本質(zhì)上允許你在瀏覽器中構(gòu)建桌面應(yīng)用程序，這意味著你可以顯著改善用戶體驗(yàn)。所有狀態(tài)都可以在這里進(jìn)行管理而無需無休止的請求/響應(yīng)，你可以使用標(biāo)準(zhǔn)UI技巧（如過渡效果）來隱藏延遲，并且整個應(yīng)用程序仍可以正常運(yùn)行。

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第9頁。愛上DynamoDB無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第9頁。從很多方面來看，實(shí)現(xiàn)無服務(wù)器最難的部分是真正掌握DynamoDB。你肯定會在前幾次迭代中犯一些錯誤，且會很輕易放棄所有并重新回到RDS，畢竟曾經(jīng)在這個舒適圈里都很熟悉這些。

SQL在很長一段時(shí)間都是我所依賴的，我承認(rèn)我將過多的業(yè)務(wù)邏輯放入數(shù)據(jù)庫中。但RDMS系統(tǒng)只是另一個整體，它無法很好地?cái)U(kuò)展且不能支持有機(jī)發(fā)展敏捷系統(tǒng)的需求。

DynamoDB是一種完全不同的類型。當(dāng)你找對正確的實(shí)施方案，NoSQL數(shù)據(jù)庫能提供了極高的性能，又能大規(guī)模，并且?guī)缀鯖]有管理開銷。但是你真正需要的是花時(shí)間探索它是如何工作的，還有在初始階段將會有各種各樣的問題。

Dynamo表字段不能包含空字符串。備份時(shí)間點(diǎn)不是自動的。如果分區(qū)和排序鍵錯誤，則必須從頭開始使用表。如果你嘗試過于密切地模擬SQL查詢，你的表可能會越來越多。從RDS轉(zhuǎn)換過來會讓你感覺截然不同。

經(jīng)過許多教程，嘗試，失敗并最終成功使用DynamoDB，我學(xué)到了以下：

首先你需要了解DynamoDB是如何工作的，花一些時(shí)間來了解索引策略以及你將打算如何查詢數(shù)據(jù)。在沒有充分了解所需知識的情況下雖然很容易開始使用，但也因此會有很多人在使用過程中備受打擊，然后在錯誤的時(shí)間回退到RDMS。會犯錯，但你需要推翻它們。DynamoDB中很少被討論到的特性之一是使用流將代碼附加到表事件的方式，就像可以執(zhí)行任何操作的SQL觸發(fā)器一樣。這些都非常強(qiáng)大。我們使用到的一個非常簡單的模式是始終將表更新推送到SNS主題中，這些更改將可以被那些可能尚未實(shí)現(xiàn)的其他無服務(wù)器代碼使用。無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第10頁。不要忘記，DynamoDB同時(shí)可以提供其他存儲系統(tǒng)（RDMS，Redshift或僅文本文件），可用于有效消除流量峰值或保護(hù)其他數(shù)據(jù)庫免受大量數(shù)據(jù)的影響。DynamoDB具有TTL功能，允許你設(shè)置行過期，這對于暫存你想推送到其他地方的數(shù)據(jù)非常有用。無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第10頁。

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第11頁。無服務(wù)器框架無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第11頁。我早期對Lambda進(jìn)行的實(shí)驗(yàn)很笨拙，是直接編程寫入到AWS控制臺中，后來開始感到詛喪，因?yàn)槲倚枰獙?shí)施大量的工作和錯誤信息來處理一些微不足道的事情。僅僅是因?yàn)闆]有一條將IDE連接到生產(chǎn)環(huán)境的橋梁。

直到我發(fā)現(xiàn)無服務(wù)器框架，多年來發(fā)現(xiàn)的最令人興奮的事情非它莫屬了。

一個簡單的slsdeploy命令就能將你的代碼直接打包上傳到AWS上。如果你因代碼錯誤需要檢查日志，那么你僅需簡單運(yùn)行slslogs-ffunctionname-t，你可以像專業(yè)人士一樣查看CloudWatch的日志而無需通過瀏覽器。

這改變了以往的一切。請大力贊美無服務(wù)器的維護(hù)者們吧，因?yàn)樗麄冏隽怂性品?wù)商從第一天就應(yīng)該提供的服務(wù)。這真的是太棒了！

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第12頁。認(rèn)證授權(quán)無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第12頁。在傳統(tǒng)應(yīng)用程序中，你只需對用戶進(jìn)行一次身份驗(yàn)證，然后通過跟蹤會話ID來跟蹤此用戶行為。我們喜歡這樣做是因?yàn)槠D難的工作僅需完成一次。

通過sessionID控制訪問權(quán)限

但這種方法存在一些問題，它只適用于在這中間存在服務(wù)器的情況。我們已將該中間的服務(wù)器去除掉了。它還可能讓你暴露給一些令人討厭的攻擊行為，比如跨站點(diǎn)請求偽造（CSRF），并且不能讓你輕易地將身份傳遞給其他服務(wù)。所以這種方法基本上僅支持單體應(yīng)用。

我們討厭單體服務(wù)以及CSRF攻擊，但我們確實(shí)喜歡我們新引入的技術(shù)，即JWT令牌。當(dāng)我了解到這是如何工作的時(shí)候，我有一種類似禪的興奮感，我需要一張流程圖來好好解釋明白。

步驟1，獲取JWT，第2步，使用它與你編寫的任何服務(wù)進(jìn)行通信：

授權(quán)過程獲取JWT令牌

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第13頁。無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第13頁。Lambda函數(shù)接受并驗(yàn)證令牌

基本的核心是每個請求都經(jīng)過身份驗(yàn)證，客戶端甚至可以調(diào)用多個無服務(wù)器進(jìn)行通信。在JWT的世界里甚至不存在CSRF。無服務(wù)器代碼所需要的就是使用自定義授權(quán)程序來檢查標(biāo)頭中的JWT是否有效（可參考實(shí)例代碼）。

與JWT對比起來，所有其他類型的用戶驗(yàn)證看起來都過于復(fù)雜。我們毫不猶豫將所有用戶驗(yàn)證都切換為Auth0（在某些情況下為Cognito）。無服務(wù)器身份驗(yàn)證既簡單又非常有效。

無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第14頁。規(guī)劃與展望無服務(wù)器架構(gòu)的最佳實(shí)踐全文共14頁，當(dāng)前為第14頁。雖然我已經(jīng)使用了AWS很長一段時(shí)間，即使是在EC2的場景下，因?yàn)槲覅⑴c的時(shí)間相對較