在十月份的Serverlessconf巡講之後，我決定領導整個公司走向無伺服器架構。最初我花了幾個月時間來嘗試將Python Flask應用程式[1]遷移到Lambda，這些經歷幫助我後來找到更好的方法。
在六個月之後，我們已在無服務化地部署我們的第四個主要專案。以下將講述我們在此過程中學習到的經驗以及對此的一些強烈建議。
Flask是一個挺不錯的小框架，用於由伺服器管理會話的站點，使用舊式的請求-響應方式。在互動式網路的新世界中，這就像是用橡皮筋和橡皮刮板來試圖建造一個房子一樣，非常古怪。
當你開始將更多工作轉移到客戶端這邊以支援互動時，你沒有其他選擇只能選擇JavaScript。這通常會導致（很多奇怪的東西）內嵌到Python模板裡，而技術債務則越積累越多。
Flask的解決方案逐漸成為不同語言的集合體。很快我就得出結論，這種方法將會造成一些可怕的混亂，導致我開始懷疑我為何要再使用Python了。
在切換到Node之後，很多東西都變得可維護且合理，並且也不再需要使用多種語言。透過Webpack上簡單的Node/Express配置，你還可以使用ES6來消除Python開發者帶來的糟糕的JavaScript的程式碼結構。
在Zapppa/Flask嘗試做同樣的事情簡直比登記納稅更不友好。在5分鐘內，你可以構建一個可以在Lambda上執行的完全成熟的Node/Express應用程式，就像1040EZ那樣，這非常簡單。所以我們放棄了Python並加入了JavaScript的陣營。
為此我們放棄了什麼呢？Python支持者們會聲情並茂地向你推薦所有酷炫的語言特性，但與JavaScript的實際非同步魅力相比，這些僅僅只是玩具。而且我們現在也不需要再擔心使用Python 2還是Python 3了（也不知我們到底有沒有升級過……）。至少在我們的專案上，我們很容易就完成了轉換。
當然，Ben Kehoe還丟擲了一項引人註目但同時令人震驚的[2]觀點：在無伺服器架構中利用Python替代Node。
我們花費了大量的時間才意識到無伺服器架構的明顯好處，可能是因為我們一直是在構建Web應用程式（閉門造車），或者也有可能只是因為我老了。
我們最初的一些Web應用程式仍然有一個Node Express層來記住會話狀態，（1）希望使用者能總是請求到同一個Lambda容器，（2）悲劇的是在設計中也濫用了DynamoDB來保持會話ID。我們到底在做什麼？！
在過渡時期的第一階段，我們做了錯誤且可怕的就是我們的中間層跟Lambda上的Web伺服器一樣，導致我們最終得到了到處是JavaScript去呼叫REST API的html頁面。這種做法非常原始，極度難以維護，並且很快就變得脆弱，但我們已經移除了中間層。在無伺服器架構中，中間層必須去除。
能夠將所有東西都塞進前端感覺非常棒，但它很快就發展成一個令人震驚的混亂局面。你最終停止程式碼審查，因為你覺得分享你一直在開發的那些華而不實的機器語言黑魔法太尷尬了。並且“不審查程式碼”對開發人員來說不是一個很好的工作標的。
我在瞭解單頁應用（SPA）領域時接觸到了React，它是當前最流行的構建使用者介面的方案。React很棒，但是它的學習曲線陡峭，有很多Webpack/Babel相關的設定，並且引入了JSX。雖然它可能是我們最終使用的東西，但它對於我們的當前需求來說太重了，所以需要調研其他替代方案。
幸運的是我很快就發現了Vue.js，我的無伺服器生活開始走向極樂。事情是這樣的：你甚至可以在一天內就學完Vue！
Vue的設計方法非常適合我們的設計模型，一切都是能自管理內容，設計和程式碼的元件。這使得管理我們的多個客戶端專案和分散的團隊變得非常容易，並且非常適合無伺服器的思維樣式。
這個開源的JavaScript框架為你提供強大的除錯工具，出色的組織以及能為你節省數小時的開箱即用的Webpack構建。尤其是路由和商店管理外掛，你可以像Facebook工程師那樣製作實時有趣的應用。誰能想到製作單頁應用可以這麼簡單？
從無伺服器的角度來看，Vue將你的所有實現程式碼編譯成index.html和bundle.js檔案，並可上傳到S3。新的編譯命令僅需簡單執行npm run build。
仔細想想，在以前，我們透過Elastic Beanstalk部署應用並監控利用率，在需要時進行自動擴充套件以及還需要管理合理的基礎架構。
SPA真正的神奇之處在於，當你部署應用程式時，你只需將index.html，bundle.js和少量檔案依賴項複製到由CloudFront分發前端的S3儲存塊中。這為你提供了穩定的分散式和載入行為，並且還支援多版本管理以及任何你想要的部署方法，可能只需管理文字檔案。
理論上來說我們能將規模擴充套件到無限，同時只對我們已使用的服務付費，其中完全沒有應用程式基礎設施管理成本。
Vue本質上允許你在瀏覽器中構建桌面應用程式，這意味著你可以顯著改善使用者體驗。所有狀態都可以在這裡進行管理而無需無休止的請求/響應，你可以使用標準UI技巧（如過渡效果）來隱藏延遲，並且整個應用程式仍可以正常執行。
從很多方面來看，實現無伺服器最難的部分是真正掌握DynamoDB。你肯定會在前幾次迭代中犯一些錯誤，且會很輕易放棄所有並重新回到RDS，畢竟曾經在這個舒適圈裡都很熟悉這些。
SQL在很長一段時間都是我所依賴的，我承認我將過多的業務邏輯放入資料庫中。但RDMS系統只是另一個整體，它無法很好地擴充套件且不能支援有機發展敏捷系統的需求。
DynamoDB是一種完全不同的型別。當你找對正確的實施方案，NoSQL資料庫能提供了極高的效能，又能大規模，並且幾乎沒有管理開銷。但是你真正需要的是花時間探索它是如何工作的，還有在初始階段將會有各種各樣的問題。
Dynamo表欄位不能包含空字串。備份時間點不是自動的。如果分割槽和排序鍵錯誤，則必須從頭開始使用表。如果你嘗試過於密切地模擬SQL查詢，你的表可能會越來越多。從RDS轉換過來會讓你感覺截然不同。
經過許多教程，嘗試，失敗並最終成功使用DynamoDB，我學到了以下：
-
首先你需要瞭解DynamoDB是如何工作的，花一些時間來瞭解索引策略以及你將打算如何查詢資料。在沒有充分瞭解所需知識的情況下雖然很容易開始使用，但也因此會有很多人在使用過程中備受打擊，然後在錯誤的時間回退到RDMS。會犯錯，但你需要推翻它們。
-
DynamoDB中很少被討論到的特性之一是使用流將程式碼附加到表事件的方式，就像可以執行任何操作的SQL觸發器一樣。這些都非常強大。我們使用到的一個非常簡單的樣式是始終將表更新推送到SNS主題中，這些更改將可以被那些可能尚未實現的其他無伺服器程式碼使用。
-
不要忘記，DynamoDB同時可以提供其他儲存系統（RDMS，Redshift或僅文字檔案），可用於有效消除流量峰值或保護其他資料庫免受大量資料的影響。DynamoDB具有TTL功能，允許你設定行過期，這對於暫存你想推送到其他地方的資料非常有用。
我早期對Lambda進行的實驗很笨拙，是直接程式設計寫入到AWS控制臺中，後來開始感到詛喪，因為我需要實施大量的工作和錯誤資訊來處理一些微不足道的事情。僅僅是因為沒有一條將IDE連線到生產環境的橋梁。
直到我發現無伺服器框架，多年來發現的最令人興奮的事情非它莫屬了。
一個簡單的sls deploy命令就能將你的程式碼直接打包上傳到AWS上。如果你因程式碼錯誤需要檢查日誌，那麼你僅需簡單執行sls logs -f functionname -t，你可以像專業人士一樣檢視CloudWatch的日誌而無需透過瀏覽器。
這改變了以往的一切。請大力贊美無伺服器的維護者們吧，因為他們做了所有雲服務商從第一天就應該提供的服務。這真的是太棒了！
在傳統應用程式中，你只需對使用者進行一次身份驗證，然後透過跟蹤會話ID來跟蹤此使用者行為。我們喜歡這樣做是因為艱難的工作僅需完成一次。
但這種方法存在一些問題，它只適用於在這中間存在伺服器的情況。我們已將該中間的伺服器去除掉了。它還可能讓你暴露給一些令人討厭的攻擊行為，比如跨站點請求偽造（CSRF），並且不能讓你輕易地將身份傳遞給其他服務。所以這種方法基本上僅支援單體應用。
我們討厭單體服務以及CSRF攻擊，但我們確實喜歡我們新引入的技術，即JWT令牌。當我瞭解到這是如何工作的時候，我有一種類似禪的興奮感，我需要一張流程圖來好好解釋明白。
步驟1，獲取JWT，第2步，使用它與你編寫的任何服務進行通訊：
基本的核心是每個請求都經過身份驗證，客戶端甚至可以呼叫多個無伺服器進行通訊。在JWT的世界裡甚至不存在CSRF。無伺服器程式碼所需要的就是使用自定義授權程式來檢查標頭中的JWT是否有效（可參考實體程式碼）。
與JWT對比起來，所有其他型別的使用者驗證看起來都過於複雜。我們毫不猶豫將所有使用者驗證都切換為Auth0（在某些情況下為Cognito）。無伺服器身份驗證既簡單又非常有效。
雖然我已經使用了AWS很長一段時間，即使是在EC2的場景下，因為我參與的時間相對較晚所以也會需要很多幫助。在結束無伺服器會議之後，這感覺就像進入一個真正未開發的領域，需要我們在黑暗中去發現更多。
在我們的前幾個實驗中，我們嘗試使用現有的工具和技術但發生了一些失誤，結果並不是很好。經過幾個月的正確積累，我們已經正式開始以100％無伺服器方式交付專案。我相信我們遷移過程中的問題和早期的探索非常值得。
我們正在構建靈活的實時SPA應用程式，這些應用程式使用完全無伺服器的基礎架構，可以毫不費力地擴充套件，並且成本降低了70%-90％。我對這個支出減少感到高興以及震驚。我從未如此確信無伺服器技術將徹底改變雲服務下的應用交付。
-
https://read.acloud.guru/adventures-in-migrating-to-serverless-a63556b39042
-
https://read.acloud.guru/node-is-the-wrong-runtime-for-serverless-jk-c69595f6a8eb
原文連結：https://read.acloud.guru/six-months-of-serverless-lessons-learned-f6da86a73526
Kubernetes應用實戰培訓將於2018年10月12日在深圳開課，3天時間帶你係統學習Kubernetes。本次培訓包括：容器基礎、Docker基礎、Docker進階、Kubernetes架構及部署、Kubernetes常用物件、Kubernetes網路、儲存、服務發現、Kubernetes的排程和服務質量保證、監控和日誌、Helm、專案實踐等，點選下方圖片檢視詳情。
長按二維碼向我轉賬
受蘋果公司新規定影響，微信 iOS 版的贊賞功能被關閉，可透過二維碼轉賬支援公眾號。
![]()
微信掃一掃
使用小程式
知識星球
