AWS Lambda-使用.NET Core構建無服務器API

Question

最近，我一直在研究AWS Lambdas，以及如何使用.Net Core構建無服務器API。 據我了解，您可以通過2種不同的方式來做到這一點。

1）用C＃編寫多個單獨的Lambda，並將它們部署到AWS。 請求通過API網關進入，每個lambda充當端點。

2）使用.Net核心構建無服務器Web API。 創建無服務器的Web API項目時，將自動創建Lambda，它成為Web API的入口點。

是否存在1比2的局限性，或者用例中一種方法可能比其他方法更有利？ 還是只是兩種不同的方式來達成同一件事？

Answer 1

我認為您的選擇不正確。 構建Lambda支持的API的兩個選項是：

1-構建lambda，然后在一個或多個項目中將其獨立部署到AWS。 然后，手動創建指向您的一個或多個lambda的API Gateway端點。

2-使用無服務器項目將lambda組合到一個項目中。 在該項目中定義您的終結點，並讓Cloudformation創建API網關終結點，並將其掛鈎到部署時的lambda。

就利弊而言，

選項1：

優點：具有獨立部署lambda的靈活性，您也可以按照自己的方式配置API網關端點，而無需了解Cloudformation定義語法，這在我的經驗上花費了一些時間。

缺點：如果您有很多lambda，這將成為管理方面的噩夢。 此外，您的端點定義也不在源代碼中，並且不會跟蹤對端點配置的更改。

選項2：

優點：如果您了解Cloudformation或要使用默認配置來部署lambda並將其掛接到API Gateway端點，則非常簡單。 AWS將為您創建終端節點，並創建開發和生產階段，策略，IAM角色等。Cloudformation直接從Visual Studio進行部署會導致整個部署以及所有相關對象歸入AWS Cloudformation中的同一“堆棧”下可以很容易地對其進行更改，復制或刪除。 而且，您的基礎架構現在是代碼，對其更改可以在git repo中進行審核。

缺點：我認為最大的缺點是，堆棧不跨VS解決方案而是僅跨項目，因此所有lambda都必須駐留在同一個項目中，這意味着如果您擁有很多，它們最終將結束全部集成在一個整體式lambda二進制文件中。 生成的大型項目二進制文件將使您在AWS和效率問題上花費內存運行時間。 另一個缺點是，如果您要使用特定的API網關或使用普通的API網關，則需要了解Cloudformation語法才能更改serverless.template文件。

結論：我的首選解決方案是根據API對象將真實的應用程序划分為較小的相關lambda，並將這些lambda放入一些無服務器應用程序項目中。 例如，我有一個包含與訂單API相關的所有lambda的訂單項目，以及一個包含與產品API等相關的lambda的Product項目。它們都將存在於同一解決方案中，並將分別部署。 我目前正在研究一種可以立即部署整個解決方案的方法。