在我10月份的Serverlessconf之旅之后，我决定带领我的整个公司走向无服务器。我最初花了几个月的时间尝试将PythonFlask应用程序[1]迁移到Lambda，这些经验帮助我后来找到了更好的方法。六个月后，我们将部署我们的第四个主要无服务器项目。以下是我们在此过程中学到的知识以及一些强烈的建议。#1-放弃PythonFlask是一个不错的小框架，适用于服务器管理会话的站点，使用旧式请求-响应方法。在交互式网络的新世界中，这就像试图用橡皮筋和橡皮刮板盖房子。旧式部署架构当您开始将更多工作转移到客户端以支持交互时，您别无选择，只能选择JavaScript。这通常会导致（很多奇怪的东西）被嵌入到Python模板中，并且技术债务不断累积。Flask的解决方案正在逐渐成为不同语言的集合。没过多久我就得出结论，这种方法会造成一些可怕的混乱，这让我想知道我为什么要使用Python。切换到Node之后，很多东西变得可维护和合理了，也没有必要使用多种语言了。通过在Webpack上简单的Node/Express配置，你也可以使用ES6来消除Python开发人员带来的可怕的JavaScript代码结构。尝试在Zapppa/Flask中做同样的事情比注册和纳税更不友好。在5分钟内，您可以构建一个在Lambda上运行的完全成熟的Node/Express应用程序，就像1040EZ一样，非常容易。所以我们放弃了Python，加入了JavaScript阵营。Lambda作为一个整体运行我们为此放弃了什么？Python的支持者会和你谈论所有很酷的语言特性，但与JavaScript真正的异步魅力相比，这些只是玩具。而且我们不需要担心现在是使用Python2还是Python3（我不知道我们是否已经升级......）。至少在我们的项目中，我们轻松地进行了切换。当然，BenKehoe也抛出了一个引人注目但同时又令人震惊的观点[2]：在Serverless架构中使用Python来替代Node。#2-推翻之前的架构我们花了很多时间才意识到无服务器架构的明显好处，可能是因为我们一直在构建Web应用程序（闭门造车），也可能只是因为我老了。我们的一些原始Web应用程序仍然有一个NodeExpress层来记住会话状态，(1)希望用户总是请求相同的Lambda容器，以及(2)悲惨地通过设计误用DynamoDB来持久化会话ID。我们到底在做什么？！在过渡的第一阶段，我们做错了，可怕的是我们的中间层与Lambda上的Web服务器相同，所以我们最终得到了充满调用RESTAPI的javascript的html页面。这种方法很原始，极难维护，很快就会变得脆弱，但我们已经移除了中间层。在无服务器架构中，必须删除中间层。应用程序状态移至客户端，业务逻辑移至Lamdba#3-EnjoyVue能够将所有内容塞入前端感觉很棒，但它很快就会变得令人震惊。你最终停止了代码审查，因为你觉得不好意思分享你一直在开发的所有华丽的机器语言黑魔法。而“不审查代码”对于开发人员来说并不是一个好的工作目标。我在了解单页应用程序(SPA)世界时遇到了React，这是目前最流行的构建用户界面的解决方案。React很棒，但它有一个陡峭的学习曲线，很多与Webpack/Babel相关的设置，并且引入了JSX。虽然它可能是我们最终会使用的，但它对我们当前的需求来说太重了，因此需要研究其他替代方案。幸运的是，我很快发现了Vue.js，我的无服务器生活开始变得幸福起来。事情是这样的：您甚至可以在一天内学会Vue！Vue的设计方法非常适合我们的设计模型，其中一切都是管理其自身内容、设计和代码的组件。这使得管理我们的多个客户项目和分布式团队变得非常容易，并且与无服务器思维方式完美契合。这个开源JavaScript框架为您提供了强大的调试工具、出色的组织和开箱即用的Webpack构建，可以节省您的时间。尤其是路由和店铺管理插件，可以像Facebook工程师一样做出实时有趣的应用。谁会想到制作单页应用程序会如此简单？从无服务器的角度来看，Vue将你所有的实现代码编译成index.html和bundle.js文件，这些文件可以上传到S3。新的构建命令只需要运行npmrunbuild。想一想，过去我们通过ElasticBeanstalk部署应用程序并监控利用率，在需要时自动缩放，并管理合理的基础设施。SPA的真正魔力在于，当您部署应用程序时，只需将index.html、bundle.js和少量文件依赖项复制到CloudFront分发前端的S3存储桶中。这为您提供稳定的分发和加载行为，还支持多版本管理和您想要的任何部署方法，可能只是管理文本文件。理论上，我们可以无限扩展，同时只为我们使用的服务付费，根本没有应用程序基础设施管理成本。Vue本质上允许您在浏览器中构建桌面应用程序，这意味着您可以显着改善用户体验。所有状态都可以在这里管理，而无需无休止的请求/响应，您可以使用过渡效果等标准UI技巧来隐藏延迟，整个应用程序仍然可以正常工作。#4-爱上DynamoDB在很多方面，无服务器最难的部分实际上是掌握DynamoDB。在最初的几次迭代中你肯定会犯一些错误，并且很容易放弃所有并回到RDS，毕竟你在这个舒适区对此很熟悉。SQL是我长期依赖的东西，我承认我把太多的业务逻辑放到了数据库中。但RDMS系统只是另一个单体，它不能很好地扩展，不能支持有机开发敏捷系统的需求。DynamoDB是一种完全不同的类型。当您得到正确的实施时，NoSQL数据库可以提供极高的性能、规模，并且几乎没有管理开销。但你真正需要的是花时间去探索它是如何工作的，在最初阶段会有各种各样的问题。Dynamo表字段不能包含空字符串。备份时间点不是自动的。如果分区和排序键错误，则必须从头开始使用该表。如果您尝试过于接近地模拟SQL查询，您的表可能会变得越来越大。从RDS切换过来会让你感觉很不一样。经过许多教程、尝试、失败并最终成功使用DynamoDB，我了解到以下内容：首先，您需要了解DynamoDB的工作原理，花一些时间了解索引策略以及您将如何查询数据。虽然在没有充分了解您的需求的情况下很容易上手，但许多人会感到沮丧，然后在错误的时间退回到RDMS。错误会犯，但你需要推翻它们。DynamoDB中讨论较少的功能之一是使用流将代码附加到表事件的方式，例如可以执行任何操作的SQL触发器。这些非常强大。我们使用的一个非常简单的模式是始终将表更新推送到SNS主题，这些更改将可用于其他可能尚未实现的无服务器代码。不要忘记，DynamoDB可以同时提供其他存储系统（RDMS、Redshift或只是文本文件），可用于有效消除流量高峰或保护其他数据库免受大量数据的影响。DynamoDB具有允许您设置行过期时间的TTL功能，这对于暂存要推送到其他地方的数据很有用。#5-无服务器框架我早期使用Lambda的实验很笨拙，直接在AWS控制台中编程，我开始感到沮丧，因为我需要为琐碎的事情实施大量工作和错误消息。仅仅是因为没有将IDE连接到生产环境的桥梁。在我发现无服务器框架之前，这是我多年来发现的最令人兴奋的事情。一个简单的slsdeploy命令可以将您的代码打包并直接上传到AWS。如果由于代码错误需要查看日志，只需运行slslogs-ffunctionname-t，即可像专业人士一样查看CloudWatch日志，无需通过浏览器。这改变了一切。给予无服务器维护人员很多荣誉，因为他们从第一天起就做了所有云提供商应该做的事情。这真的很酷！#6-身份验证和授权在传统应用程序中，您只需要对用户进行一次身份验证，然后通过跟踪会话ID来跟踪此用户行为。我们喜欢这样，因为艰苦的工作只需要完成一次。通过sessionID控制访问但是这种方式存在一些问题，它只适用于中间有服务器的情况。我们已经删除了中间的服务器。它还可能使您面临跨站点请求伪造(CSRF)等恶劣攻击，并且不会让您轻易地将您的身份传递给其他服务。所以这种方式基本上只支持单体应用。我们讨厌单体应用和CSRF攻击，但我们喜欢我们新引入的技术JWT令牌。当我了解到这是如何工作时，我有一种禅宗般的兴奋，我需要一张流程图来解释它。第1步，获取JWT，第2步，使用它与您编写的任何服务进行通信：授权过程获取JWT令牌Lambda函数接受并验证令牌基本核心是每个请求都经过身份验证，客户端甚至可以调用多个serverless进行通信。CSRF甚至不存在于JWT世界中。所有无服务器代码都需要使用自定义授权程序来检查标头中的JWT是否有效（请参阅示例代码）。与JWT相比，所有其他类型的用户身份验证似乎都过于复杂。我们毫不犹豫地将所有用户身份验证切换到Auth0（在某些情况下是Cognito）。无服务器身份验证简单且非常有效。进入新世界虽然我已经使用AWS很长时间了，即使在EC2场景中，我对这个组合还是比较陌生，需要很多帮助。结束无服务器会话后，感觉就像进入了一个真正未开发的领域，需要我们在黑暗中发现更多。在最初的几次实验中，我们尝试使用现有的工具和技术，但犯了一些错误，结果并不理想。经过几个月的正确积累，我们正式开始以100%Serverless的方式交付项目。我相信我们迁移的问题和早期探索是非常值得的。我们正在构建灵活的实时SPA应用程序，这些应用程序可以使用完全无服务器的基础架构轻松扩展并且成本降低70%-90%。我对这种支出减少感到高兴和震惊。我从未像现在这样坚信无服务器技术将彻底改变云中的应用程序交付。相关链接：https://read.acloud.guru/adventures-in-migrating-to-serverless-a63556b39042https://read.acloud.guru/node-is-the-wrong-runtime-for-serverless-jk-c69595f6a8eb原文链接：https://read.acloud.guru/six-months-of-serverless-lessons-learned-f6da86a73526
