使用无服务器体系结构-不是全部还是没有。
无服务器是一个特别热门的话题,去年引起了很多炒作。 大型的“四个”云托管公司各自提供自己的解决方案: Azure Function , AWS Lambda , 阿里云功能计算和Google Functions 。 有许多会议开始比较和讨论使用Serverless优于传统架构的好处。
通过使用无服务器,我们可以执行事件触发的定义明确的功能,而无需管理和扩展任何基础架构。
自从我开始在一些副项目中采用无服务器体系结构以来,我发现我们肯定可以从中受益。
在无服务器上,我们不必全力以赴。
好处
降低运营成本-我们无需雇用人员来管理服务器,而是将其“外包”给专家。 开发人员可以专注于编写代码并使用许多其他人已经在使用的预定义服务。 其次,我们只为运行功能花费的时间付费,而不是为24/7的服务器付费。
降低缩放成本-不必缩放所有内容或投入更多硬件,我们可以选择缩放重要的部分。 大多数情况下,峰值会出现在应用程序的特定部分,通常会持续一段时间。 例如,在电子商务站点的销售期间。 如果我们使用无服务器架构与Stripe进行付款集成,则只需在高峰期支付额外的计算能力。
降低开发成本-与其他服务提供商相比,实际上有很多现成的组件,而不是总在重新发明轮子。 例如,身份验证服务(如Firebase , Auth0) ,付款服务(如Stripe和Braintree) 。 与我们自己开发所有组件相比,这些现成的组件将为我们节省大量时间和开发成本。
现有项目的可能用例
我们可以通过迁移特别适合无服务器的应用程序的一部分来利用所有这些优势。 如上所述,我认为身份验证和支付集成将是一个不错的开始,它只是执行某些事件的应用程序的一部分。 几乎没有需要状态的业务逻辑。
身份验证/注册-我们甚至不必迁移整个身份验证或注册过程。 如果您的团队希望添加其他形式的身份验证(例如SMS验证)或改进密码重置功能,我绝对会考虑使用无服务器。
图像处理-具有用户帐户的大多数应用程序还为每个用户处理某种形式的头像图像。 如果您处理某种形式的照片编辑/调整大小并将其保存到S3
类的存储中,那么将该部分更新为无服务器无疑是很有意义的。 这样,您可以减少正在运行的线程或额外的工作程序,而仅需为特定功能支付计算时间。
事件驱动功能-如果您的应用程序在每月的某个特定时间生成某种形式的发票并向特定用户发送电子邮件,那么这也是无服务器的好用例。 将发票保存到S3
,您可以触发Lambda
运行并使用SNS
发送电子邮件。 我更新了自己的应用程序的一部分,其中将新的APP_VERSION.zip
保存到S3
,它将向应用程序的用户推送特定的通知,以请求更新许可。
加快开发速度的框架
随着无服务器架构的成熟,许多优秀的工程师开始创建框架以帮助他们简化工作。 以下是在开始无服务器架构之旅时我比较的一些库。
AWS的Chalice —一个Python框架,可让我们使用AWS Lambda,API Gateway和CloudWatch快速创建和部署应用程序。
Zappa — Python框架,允许我们使用AWS部署任何与WSGI兼容的应用程序。 可以使用Zappa轻松配置基于Flask,Bottle或Django构建的应用程序。
Claudia.js —轻松地将任何Node.js项目部署到AWS Lambda和API Gateway。 仅专注于Node.js应用程序,会自动安装模板以将参数和结果转换为Javascript可以轻松使用的对象。
Apex-主要在Go上构建,但通过使用注入到构建中的Node.js填充程序,支持AWS Lambda本身不支持的许多其他语言。 目前支持Node.js,Golang,Python,Java,Rust和Clojure。
结论
用最简单的术语来说,无服务器在执行单一目的无状态功能时效果最好。 我们并不一定总是选择一种服务器架构而不是另一种。 有时,混合架构使我们能够利用不同的优势。
我希望我能说服你。 如果要构建新功能或尝试改进现有功能,请考虑使用无服务器体系结构。 如果适合以上情况,请放手去做。 您可能会解锁某些东西并学习新东西。
谢谢阅读! 如果喜欢,请按????????????
我喜欢阅读与写作有关技术和产品的文章,尤其是与提高开发人员的生产力有关的文章。 您可以在我的Twitter或博客上向我问好。
From: https://hackernoon.com/using-serverless-archiecture-is-not-all-or-nothing-7697af85286