如网站性质为公司 请以企业备案,开发工程师网站开发工程师招聘,网站如何屏蔽ip,网页设计与制作轮播图教程译者 | 王欢来源 | 分布式实验室头图 | 下载于ICphoto最近#xff0c;我在YouTube上看了一个非常出色的开发人员的视频。它的标题是“无服务器毫无意义”。虽然我非常喜欢该视频#xff0c;但也不敢确定作者关于无服务器的观点是否完全正确#xff0c;因此我想在本文中进行讨… 译者 | 王欢来源 | 分布式实验室头图 | 下载于ICphoto最近我在YouTube上看了一个非常出色的开发人员的视频。它的标题是“无服务器毫无意义”。虽然我非常喜欢该视频但也不敢确定作者关于无服务器的观点是否完全正确因此我想在本文中进行讨论。在引言中作者开了个玩笑“这个世界上有两件事我不明白——女生和无服务器。”我不知道他与女生的关系但是对于无服务器的观点他是对的吗让我们看看他的批评并讨论潜在的对立论点。剧透我认为无服务器确实有意义前提是你知道何时以及如何使用它。无服务器的批判YouTube视频上提到的最主要争论是速度问题。更具体地说从作者的角度来看无服务器应用程序的主要缺点是众所周知的冷启动问题——增加的延迟你的代码只有在底层云服务完成分配计算资源拉取代码或容器镜像安装额外的程序包并配置环境之后才能开始执行。优先考虑执行速度的工程师给人的印象是整个应用程序生命周期管理的最终成功指标是我们的代码完成所需执行任务的速度。作为一个在IT行业工作多年的人我看到的实际问题却是更多关注维护性以及利用技术来快速可靠的提供商业价值的能力我不确定这种指标是否正确地衡量了最重要的因素——评估时间 开发周期的速度易于维护为最终用户降低成本通过促进无缝的IT运营来降低运营中的风险最后分配我们的大部分工程时间来正确解决实际业务问题而不是在配置和管理服务器上。一些工程师错过了什么无服务器的真正好处如果你对执行速度这点特别关心并且偶尔的200毫秒在AWS[2]上能达到一秒的延迟在你的工作负载中是不可接受的那么无服务器确实不是你的选择这点完全可以接受。但是我们不能因为无服务器的延迟就说它毫无用处。每个人都需要自己决定用例中可接受的延迟时间。无服务器是管理IT基础架构的一种极具成本效益和高效的方式对于可能没有很多钱用于闲置资源的IT部门以及一支专门7×24小时的支持工程师的维护团队特别有利。无服务器的低成本可能胜过任何弊端在我看到的大多数用例中仅在考虑实际计算成本的情况下无服务器就比自托管资源便宜几个数量级。如果再考虑无服务器显着减少了操作扩展和维护基础架构所需的时间总拥有成本简称TCO[3]那么这时你才真正认识到成本的节省。事实上维护基础架构的全职工程师团队比任何无服务器资源的成本都要高得多。我并不是说对于所有用例无服务器选项总是更便宜。如果你持续收到数亿个请求如果你的工作负载非常稳定并且如果你有足够的工程师可以监控和扩展所有这些资源那么使用自托管的基础架构确实可能会更好。冷启动是配置和预算的问题回到成本问题上来冷启动问题在很大程度上取决于你愿意花费多少以及如何配置无服务器资源。如果你愿意支付额外的费用那么有许多缓解冷启动的方法例如利用预热的实例提供并发性或故意发出更多的请求虚假请求[4]以确保你的环境保持在线。通过使用诸如Dashbird的监控平台你甚至可以收到发生在函数中的任何冷启动的通知从而帮助你优化无服务器资源。在下图中你可以看到在29个调用中我们可以观察到一个冷启动这使总执行时间增加了大约180毫秒的延迟。Dashbird的可观察性功能有助于识别和防止冷启动作者提供的图片你可以为任何冷启动配置Slack或电子邮件警报以了解它们发生的频率。在Dashbird中设置冷启动警报作者提供改善Lambda函数延迟的技术你可以通过适当利用上下文重用功能来减少无服务器函数的延迟。AWS冻结并存储Lambda的执行上下文即在函数处理程序handler之外发生的所有事情。如果在相同的15分钟内执行了另一个函数则可以重用冻结的环境。这意味着如果你做了耗时的操作例如连接到Lambda处理程序外的关系数据库那么能够获得明显更好的性能。 这篇文章[5]非常详细地解释了该主题。有许多精彩的文章讨论如何缓解甚至完全消除冷启动问题例如这篇[6]还有这篇[7]。Dashbird已开源名为xlambda[8]的Python库该库可以让基于Python的Lambda函数保持在线状态warm。同样杰里米·戴尔Jeremy Dale为JavaScript开源了一个类似的Lambda加热器程序包[9]。最后这个无服务器框架[10]也包括了提供相同功能的插件[11]。你的工作负载可接受多少延迟最终还是要问问自己用例可接受的延迟时间是多少。当谈到冷启动引起的延迟时我们通常争论的是毫秒。在我作为数据工程师的工作中遇到的所有用例也构建后端API中日常业务中的延迟都不明显。最后诸如AWS的无服务器Kubernetes服务在Fargate上也称为EKS之类的平台使你可以在单个Kubernetes集群中混合无服务器和非无服务器数据层。这种混合使你能够在非无服务器EC2数据层上运行关键任务的低延迟工作负载而其他工作负载例如批处理可以由无服务器数据层处理从而获得这两个不同数据层的最佳性能。你可以在这篇文章[12]中找到有关此内容的更多信息。无服务器是关于“无运维”和可扩展性无服务器可以让你更专注业务因为云提供商会帮你处理IT运维例如配置和扩展计算集群安装安全补丁和升级以及解决硬件崩溃和内存问题。这会让你有更多的时间用来为终端客户提供服务。为客户提供更好的服务不就是我们的最终目的吗无服务器背后的自动化节省了高技能工程师的时间因此他们可以专注于解决业务问题而不是管理集群。它允许将IT运维的工作分担给AWS的DevOps专家他们可能比该星球上的其他任何公司都拥有更多的管理计算相关的知识。从无服务器中受益匪浅的案例想象一下你刚刚成立了一家初创公司。最初你可能不需要大量的资源并且可能只有一个开发人员。无服务器模式允许你从小规模开始并且可以使用按需付费模式自动扩展资源。同样可以从无服务器中受益的另一个群体是可能没有大型IT部门的小型企业。只需一名专业的DevOps工程师而不是整个DevOps团队就可以管理整个应用程序生命周期这是无服务器的巨大优势。如果你的工作量天然具有季节性那么无服务器也是一个很好的选择。例如如果你经营一家电子商务公司则可能会在黑色星期五和圣诞节期间遇到季节性高峰。无服务器基础架构可以让你在这种情况下适应相应的工作量。另外某些事件是无法预测的。想象一下你一直在网上商店出售洗手液消毒剂口罩以及类似物品。然后发生了全球性流行病现在每个人都需要你的产品。无服务器基础架构可以在任何情况下为你提供任何规模的扩展。代码速度vs开发周期速度除了代码执行速度外我们还应该考虑开发速度。在许多情况下无服务器微服务模式可以加快开发周期因为从设计上讲它鼓励使用更小的单个组件并让你能够彼此独立地部署每个服务。如果无服务器能够让你快速的向利益相关者stakeholders交付应用程序的第一个版本并在开发周期中加快迭代速度同时降低成本那么由于偶尔的冷启动而导致的几毫秒的延迟增加似乎是一个很小的问题。与其他云服务的无缝集成以AWS为例每个无服务器服务都与CloudWatch集成在一起以进行日志记录与IAM集成以管理访问权限并与CloudTrail集成以收集度量指标和跟踪等等。除此之外无服务器平台通常为你提供基本的构建块以构建更大的解耦的微服务体系结构例如与无服务器消息队列SQS无服务器发布-订阅消息总线SNS无服务器NoSQL数据存储DynamoDB以及对象存储S3集成。YouTube视频中未考虑到的无服务器弊端视频中还存在一些未提及的缺点我想列出来以便给你提供完整的认识而无需添加任何糖衣。即使在许多用例中无服务器在成本可伸缩性和维护方面似乎都像是一个天堂但这并不是每个用例的银弹。面临供应商锁定的风险云提供商使他们的服务使用起来非常方便并且具有成本效益以至于你天然的面临被锁定在其特定平台中的风险。从某种程度上看无服务器资源相比较自托管资源你能够对计算资源的控制会比较弱一些。例如你不能通过SSH到底层的计算实例上手动执行某些配置并且在实例类型方面你的自由度也较小。例如你无法在具有GPU的计算实例上运行无服务器函数或容器目前。如果你有一些特定的合规性要求让你无法在云上的共享租户上处理数据那么无服务器可能不是你的选择。尽管将你的IT基础架构拆分为独立的微服务有助于管理依赖并能够加快发布周期但这也带来了对于独立服务管理方面的挑战。尽管监控解决方案例如Dashbird在很大程度上解决了此特定问题但你也需要意识到这些。无服务器批判的总结总体而言当我们想要像建立自托管的本地技术一样使用无服务器或云服务之类的新模式时常常会遇到问题。这根本不是使用它的最佳方法。在将工作负载移至云上时如果直接迁移那么你将失去云服务的许多好处甚至会误解其目的。没有一个万能的解决方案因为我们不能期望任何技术都能在所有用例中使用成为世界上最快的技术并且在没有任何不利方面例如偶尔的冷启动的情况下几乎还没有额外的成本。从我的角度来看在谈论无服务器坦率地说是与IT相关的任何内容时我们不应只考虑一个方面而不检查其他关键方面尤其是那些在各自技术的设计中至关重要的方面。从这个意义上说无服务器确实有其存在的道理前提是你知道何时以及如何使用它。参考链接https://www.youtube.com/watch?vAuMeockiuLst4shttps://youtu.be/EML6FKBdsNU?t229https://en.wikipedia.org/wiki/Total_cost_of_ownership#Computer_and_software_industrieshttps://github.com/juanjoDiaz/serverless-plugin-warmuphttps://medium.com/capital-one-tech/best-practices-for-aws-lambda-container-reuse-6ec45c74b67ehttps://dashbird.io/blog/can-we-solve-serverless-cold-starts/https://dashbird.io/blog/cold-starts-impact/https://github.com/dashbird/xlambda/https://github.com/jeremydaly/lambda-warmerhttps://www.serverless.com/https://www.npmjs.com/package/serverless-plugin-warmuphttps://medium.com/better-programming/serverless-kubernetes-cluster-on-aws-with-eks-on-fargate-a7545cf179be原文链接https://betterprogramming.pub/why-many-engineers-dont-understand-the-real-use-of-serverless-df2300766aa960专家13个技术领域CSDN 《IT 人才成长路线图》重磅来袭直接扫码或微信搜索「CSDN」公众号后台回复关键词「路线图」即可获取完整路线图更多精彩推荐
☞5G、射频、奥特曼这仨有联系吗☞再见 Nacos我要玩 Service Mesh 了☞急CPU 被挖矿该怎么找进程点分享点收藏点点赞点在看
