具有会话和数据库的AWS lambda和Web应用程序

Question

我们正处于开发新Web应用程序的初始阶段,并希望利用Amazon云平台.但是,我们可以选择使用Java spring框架或任何其他编程语言/框架来开发Web应用程序.多页面应用程序不是无状态的,即应用程序需要在登录后跟踪事务的用户会话.一旦通过多个页面从用户捕获所有所需信息,就会将事务提交给数据库.

但是,我们可能会将AWS lambda服务用于此应用程序.使用AWS Lambda(知道Lambda服务是无会话的)开发具有上述要求的Web应用程序是否正确？

Answer 1

在决定无服务器架构是否适合您的应用程序时，需要考虑很多因素。我认为这个问题没有“一刀切”的答案。

使用 Lambda 而不是 servlet 容器，确实会在会话持久性方面引入一些开发开销。但是，我认为在问自己无服务器架构是否适合您的应用程序时，这不一定是主要考虑因素。在担心会话将如何工作之前，我会问自己：

• 我是否愿意并能够将应用程序编写为一组微服务，并接受该方法带来的额外操作和开发复杂性？
• 我是否愿意对我的 UI 使用客户端渲染方法？如果没有，我选择的服务器端渲染技术是否可以轻松与 Lambda 集成？
• 我可以（安全地）在客户端嵌入多少业务逻辑？
• 我的流量模式是什么（以及扩展性需求）？我的流量稳定吗？尖尖的？我有很长的休眠期吗？
• 与 EC2相比，无服务器可能具有成本优势吗？
• Lambda 冷启动对您的用户体验有多大危害？
• 最后，关于会话，会话中的数据有多敏感？使用 JWT 的“无状态”会话是一种选择吗？

如果您的应用程序确实非常适合无服务器架构，那么弄清楚如何保持会话的开销可能不会像交易破坏者那样昂贵。

根据我的经验，开发人员（包括我自己）在向微服务和（通常）客户端渲染的范式转变上挣扎得更多，而不是在会话实现或持久化的特殊性上挣扎。

Answer 2

您的问题并非仅针对Lambda。会话管理容易（例如可以通过基于内存或基于文件的存储解决）的唯一情况是在单个服务器环境上。那可能就是你来自哪里。

开始水平扩展时（将更多服务器加入混合，而不是将更多RAM / CPU放入服务器），您需要一个用于会话（以及缓存）的中央存储。如果您在负载均衡器后面选择docker，EC2或什至金属服务器，则情况相同。

这是因为您永远无法确定来自同一用户的下一个请求是否将落在相同的环境上。对于lambda当然也是如此。不过，有一种解决方法：即，如果您使用负载平衡器来使用“粘性会话”：这会将同一用户的每个请求路由到同一台机器，请参阅会话管理上的AWS文档。但是粘性会话总是次优的（例如，缩小会破坏会话），对于lambda，粘性会话不可能实现。

真正的解决方案（如此处其他答案所示）包括通过Elasticache的中央会话存储。来自以上链接的报价：

为了解决可伸缩性并为可从任何单个Web服务器访问的会话提供共享数据存储，可以从Web服务器本身提取HTTP会话。一个常见的解决方案是利用内存中的键/值存储，例如Redis和Memcached。