如果说云计算是过去、现在和未来，那么Serverless就是云计算的未来。Gartner报告中表明，2020年全球将有20%的企业部署Serverless。Serverless以其学习成本低、运维友好、灵活性高的特点为开发、运维团队所喜爱，在国内外也开始走上了大规模考察乃至实践的应用之路。

但不可否认的是，Serverless还没有出现最佳实践，国内国外也都处在探索的过程中。3月21日，腾讯云TVP技术闭门会请来了国内外Serverless技术的佼佼者、使用者坐而论道，共话Serverless从概念到实践的发展之路。

Serverless是未来的云

“我们相信，未来Serverless应用开发者将聚焦在各种解决方案的开发上，利用Serverless基础设置提供各种应用方案，而不用去特别地关注底层的复杂基础架构，Serverless公司将和腾讯云一起建立起中国的Serverless开发者社区。”

Serverless.com CEO Austen Collins做了题为《Innovate More, Manage Less With Serverless》的演讲。Austen是Serverless Framework的原作者，目前这个开源框架有超过3.5万的star，下载次数超过200万，用户包括可口可乐、摩根大通等知名企业。去年底Serverless与腾讯云达成深度合作，将Serverless在北美的成功经验带到中国，并给开发者带来体验极佳的Serverless工具。

Austen提到，当我们说Serverless时，我们经常提到的是易扩展性，自动扩容，低成本，容易开发，聚焦在应用的输出淡化基础设施。现阶段Serverless的几个典型场景包含：REST API、流数据处理、GraphQL API、时间驱动的工作流、边缘计算及部署。而随着Serverless的发展，未来它还会与Webassembly擦出新的火花。

在Austen的演讲中，提到了几个值得关注的实践案例。一个北美百货零售商，通过使用Serverless的技术方案，目前已有4000个基于Serverless的应用，用例包含构建API、处理数据等，页面上的每一次按钮交互背后都可能是访问某个Serverless云函数。该公司技术团队只有70个开发者，负责开发各种基于Serverless的应用、API等。以前很难想象70个开发者可以开发和维护超过4000个应用，而使用Serverless以后，他们不再需要特别关注如何扩容应用，将精力花费在关键的业务开发上。

Austen同样指出，Serverless并不完美，也绝不是银弹。它并不适合所有的应用案例，你需要完全基于云设施进行开发，传统的数据库并不能利用到Serverless易扩容的特点。在Serverless的使用中，Austen也看到了很多创新的用例，企业可以聚焦在适合Serverless的业务点上，不用一开始就选择全面迁移。

硬核的Austen在分享过程中手写了两个Demo，演示了在数秒内将应用部署到基于Serverless的各种云基础设施上，整个过程不会看到任何云端设施创建的细节。Serverless提供了一种完全基于云端的开发体验，你可以像本地开发一样编辑你的代码，代码将自动同步到云端基础设置，并且所有的日志将会输出回你的本地终端中。

在提问环节中，Austen对开发者关心的Serverless问题做了解答。他认为Serverless的产生不会像云那样对运维团队造成大的冲击，恰恰相反的是，他看到运维团队对Serverless格外欢迎。

“Serverless是云的未来形式，它将成为未来开发者们的超能力！”Austen最后总结道。

Serverless：低成本、无范式的技术方案

“Serverless的价值是什么？低成本和无范式。在低成本和无范式的基础上，它的主要价值就在于它的灵活性。现在行业里更多还是照搬MVC框架，很少把复杂业务放在Serverless上运行，没有发挥出其灵活性特点。”

上海婓鸿网络科技有限公司技术经理朱峰老师接触Serverless的时间并不长，2018年下半年入“坑”的他，选择了腾讯云的云函数产品。他介绍道，最开始的尝试是从边缘的简单功能例如数据处理用起，体验了Serverless的用法以后，最后才决定将公司核心业务全部迁移到Serverless上。

“任何技术都是为了解决具体的问题，不同的问题场景里面其实是有不同的资源和不同的优先级，技术本身并不存在优劣之分。但Serverless具备的特性，却让它的使用场景变得十分可观。”

朱峰老师指出，Serverless的低成本不仅体现在学习成本低，而且在开发、运维迭代甚至包括费用成本方面都非常低。尤其是在费用成本方面，腾讯云云函数最低支持64M内存，以毫秒方式计费，对开发者十分友好。

业内对Serverless的顾虑在于，目前还没有看到核心业务场景跑在Serverless上的最佳实践。对此朱峰老师也分享了自己是如何把核心业务放在Serverless上，以什么样的方式管理Serverless。

l第一，App还是Function？这不是二选一的问题，应该两者根据业务的情况去做。我的建议就是简单的功能尽量用Function，之后牵涉到多个mode交互可以使用微型的GraphQL的app实现；

l第二，如何管理环境？腾讯云中Namespace可以区分测试环境、生产环境，Version每次部署都会生成一个版本，Alias（别名）指向某个版本号。利用好三者可以有效管理环境；

l第三，如何管理密匙？将密钥文件存放在特定的对象存储里，通过严格的权限管理和指定云函数的运行角色，使得特定的云函数可以读取特定的密钥。

“Serverless的最佳应用场景是快速迭代的业务场景而不是稳定的业务场景。因为其无范式的特点可以完全按照业务的类型，抛开之前的MVC或者别的常规范式去探索自己真正适合自己业务的特性。对企业、业务部门来说，更多情况下面对的是一个未知的市场和业务，这个时候如果能抛开旧的思维定式完全根据新的业务开发适合自己的业务架构，会更有帮助。而Serverless的灵活性和特性从底层上就支持你去这么做。”

腾讯云将提供一整套Serverless解决方案

“Serverless是一套完整的解决方案，涉及到软件开发的全生命周期，从开发部署到运维等等。从Serverless的角度看，现在仍旧缺少成熟的产品，很多厂商都在提供一套偏基础的服务，比如说函数计算、API网关、无服务等等。腾讯内部支持微信小程序等核心应用的Serverless技术已对所有用户开放。腾讯云将提供一站式开发、部署、运维Serverless解决方案。”

腾讯云中间件总经理兼首席架构师Yunong Xiao在圆桌环节分享了腾讯云与Serverless.com的合作。腾讯云期望做好开发体验，寻求与Serverless.com产品的合作，而后者同样希望能通过腾讯云改进云上服务，让产品更完善。两家企业的强强联合可以说是一拍即合，在中国做一个针对开发者的最领先的全套解决方案。

今年二月份国外机构也给出了全球Serverless厂商的整体评测，腾讯仅次于亚马逊和微软，位列第三。Yunong Xiao指出，这背后一方面是因为腾讯云在底层的性能、功能、稳定性上具备技术优势；另一方面在Serverless架构的运维层面，腾讯云也提供了全套的解决方案，后续还将发布更为优秀、智能的产品帮助Serverless做到运维无忧。

“腾讯云Serverless团队今年将在可用性、性能方面持续加码，同时聚焦开发者层面，将Serverless产品推荐给更多开发者使用，持续提升流程、工具、使用体验。”

为什么前端开发都爱Serverless？

“我认为Serverless更好的应用场景是面对前端的开发者，从前端的需求来讲，对无服务器的概念更感兴趣，而且痛点比较深。如果我们找准大前端的定位，让前端能形成一个全栈的开发，能满足他们的需求，这也是很好的Serverless发展需求。”

李明老师是游戏引擎研发与技术服务商Layabox的合伙人，超90%的3D微信小游戏都采用Layabox旗下的LayaAir引擎研发，从他的角度看Serverless，这是一个跟前端开发结合更加紧密的技术方向。事实上，Serverless在前端领域的应用势头也明显优于后端开发。

李明老师指出，Serverless更好地解决了前端开发的痛点，其易用性，无需部署维护服务器，也会极大地解放了前端开发的生产力。一方面，一些弱联网的单机游戏，也存在数据存储，活动验证等较为简单的服务端需求。另一方面，联机对战的需求也在不断增加。不仅是云函数、数据存储这种基础需求，甚至封装好的对战匹配与房间管理等，这些通用的游戏功能需求也是Serverless要走的方向，是小型游戏前端开发者降低成本，增强开发效率的需求。另外，5G时代的来临，对云计算的需求也会越来越大，把云计算与游戏通用功能结合封装好，或者通过Serverless让前端游戏的部分功能也具有云算力，也是一种方向。结合大前端的潮流，其实Serverless的前景非常乐观。

李明老师也分享了他们公司内部业务对Serverless的尝试：

“2018年七月份，我们公司内部有一个业务要上线，周期比较着急，业务的特点就是峰谷差距非常明显，流量的增减也不确定。在经过一系列选型和讨论后，最终选择了腾讯云的云函数，当时考虑的是弹性的伸缩和按使用量付费，还有稳定性和安全性的特点。另一方面，我们公司是做前端技术研发与服务的，绝大多数开发人员都是前端开发人员，这种情况下选择云函数的方式，非常快捷也比较高效。最终在我们选定这种方式并运营以后，发现性价比确实比较高，负载、扩容都挺好。”

谈到内部业务最初技术选型为何要用Serverless，李明老师指出了几个考虑因素：

l第一，考虑是否满足业务基础需求，能拿它干活是最基本的；

l第二，考虑到开发效率、后续迭代和维护成本、动态扩容等问题；

l第三，考虑到价格，不超过传统方案的成本。

基于以上几个考量标准，从满足基础需求到缩短研发周期、提升研发效率，最后在综合价格和效率成本等方面的因素下，Serverless是一个值得一试的技术。李明老师特别指出，对于小游戏从业者，纯前端和前端为主的技术团队比较多，能够让前端直接使用Serverless可以极大提升开发效率和成本，解决了普遍性痛点。

Serverless可以放心用在生产线上

“关于Serverless大家讨论得更多的点在云函数，但实际上Serverless真正的核心是让开发者不要去过多关注云函数、API网关或是对象存储这些基础设施，将关注点放在业务场景上。Serverless现在无论是从线上运营、稳定性扩容性还是本地的易开发性，都不会比已有的开发或者运维的方案差。每个场景下，Serverless都会有自己相应的解决方案，成为真正可以线上运行的东西。”

Serverless.com中国研发负责人黄珂对Serverless的发展趋势给出了这样掷地有声的结论。他认为，企业最擅长的是做业务场景，而学习和管理云的基础设施需要企业付出额外的成本，需要专门的运维团队，学习成本高。Serverless的价值在于，解放企业在基础设施上牵扯的精力，将目标聚焦于业务开发，用Serverless的能力实现快速迁移和部署。

据他介绍，Serverless.com这家全球唯一以Serverless为域名的公司，发轫于一个开源项目，框架作者正是现在的CEO Austen Collins。这个项目一开始就聚焦于为各种各样的Serverless场景提供统一的工具，在开源后受到来自知名企业和开发者的广泛欢迎以后，最终成立了Serverless.com这家商业化公司。

“Serverless.com在中国也希望从开源框架开始，把Serverless的概念真正落地到企业里面，同时在知名企业背书下也可以让Serverless变得越来越火，让大家逐渐迁移到Serverless的架构上来。”

国内外在Serverless的应用与关注方面有很大不同，黄珂也分享了他的观察。他表示，在北美地区，Serverless落地到企业中的应用已经比较成熟，出现了可口可乐等比较知名的Serverless应用项目。而国内接触Serverless最早的一批人可能是个人开发者、小程序开发者，这与北美早期也非常像，目前所欠缺的就是足够知名企业的实践落地案例。

“我们在中国的思路是去找到像腾讯云这样足够优秀的云厂商，进行深入合作，建立本地的研发团队，告诉企业怎么样去迁移他们的应用，帮助他们打消顾虑迁移到Serverless上，也让企业能够看到像Austen Collins演示的例子一样，能够非常简单部署一个Serverless的应用。通过跟腾讯云的合作，把北美深入到企业应用中的概念带到国内的企业中来。”

每一个开发者都应该了解Serverless

闭门会最后，腾讯云Serverless技术专家，本场主持人王俊杰也做了精彩的点评：我相信Serverless是一种未来的开发方式，它属于每一位开发者。

不难看出，国内外在Serverless的应用层面上都还处于探索期，国外相对而言领先一步，腾讯云和Serverless.com的合作，一方面将有助于北美经验在中国的落地，另一方面也有助于中国独特业务场景的应用实例给国外业界带来新的参考。Serverless已经走上了大规模实践的道路。

TVP，即腾讯云最具价值专家（Tencent Cloud Valuable Professional），是腾讯云授予云计算领域技术专家的一个奖项。TVP计划致力打造与行业技术专家的交流平台，构建云计算技术生态，实现“用科技影响世界”的美好愿景。

TVP成立之初，便秉承“用科技影响世界”的愿景，让技术普惠大家，践行科技向善的初心和本心。如今，IT技术的价值已经广泛地为普罗大众所认可，开发者的社会价值前所未有地凸现，我们希望能用这一系列高端、前沿的技术闭门会，在这个疫情发生的艰难时刻，汇聚行业专家，帮助产业找到应对之法。

当神话中的洪水天灾来临时，有的人选择造方舟求生，而我们却选择治水，从源头上用头脑、技术解决问题。这一次，也不例外。来，一起眺望光进来的地方！TVP眺望曙光线上技术闭门会系列活动3月28日最后一场聊技术创业和技术经营管理的话题。

版权声明：本文内容由网友上传(或整理自网络)，原作者已无法考证，版权归原作者所有。61k阅读网免费发布仅供学习参考，其观点不代表本站立场。

本文标题：为什么说每个开发者都应该关注Serverless？
本文地址： http://www.61k.com/1253635.html