Qzone

微博

微信

都在提“Serverless First” ，可你真的看懂 Serverless 了吗？

资讯 TOM 2021-09-30 16:11

2012年，Iron.io公司提出了一个名叫“Serverless”的概念，认为未来的软件和应用都应该是无服务器的；2019年，伯克利发表论文《A Berkeley View on Serverless Computing，2019 FEB》，对于云计算未来十年作出预测，认为 Serverless 是云时代的主宰。

而到了今天，人们在讨论的已不仅仅是Serverless ，而是“Serverless First” —— 也就是说，讨论话题从“要不要用”，变成了“怎么用”。它到底是云厂商的宣传噱头，前端开发者的专属方案，还是真的会改变整个研发现状呢？

要切实回答这个问题，我们来深度了解一下Serverless面临的误解、挑战与机遇。同时，我们也联系获取了华为应用市场AppGallery Connect（简称AGC）在Serverless领域的一手实践资料，希望能带给你启发。

Serverless 和微服务，并非替换关系

Serverless = FaaS（函数即服务） + BaaS（后端即服务），这是目前接受度最高的Serverless定义。Serverless 和微服务的关系，却很少有人能说得明白，甚至很多人都觉得：Serverless和微服务是替换关系，只能选一个。

然而Serverless 和微服务在不同场景下，其实各有优点。以华为AppGallery ConnectServerless为例，Serverless的特点是：

1.成本低，开发者仅对实际使用的资源付费，无需为空闲资源付费，显著降低运维与使用成本；

2.免运维，开发者无需关注后端服务的运维，自动弹性伸缩等传统云服务时代的复杂运维动作都由Serverless服务自动完成；

3.上线快，在Serverless架构中，函数粒度的开发/部署单元，以及事件触发的运行机制，可以大幅简化代码逻辑，提升业务的上线速度；

4.跨平台，AGC平台还提供了服务的跨平台支撑，帮助开发者实现不同平台上的用户互通，进一步提升开发效率。

因此，在实时计算、并行任务处理、边缘计算等计算密集型场景下，Serverless往往更合适。而微服务的特点是服务简单、灵活扩展、便于维护、独立演进、混合开发、持续交付，更适合大型复杂业务系统。

不过，微服务架构对研发团队的技术能力是个考验，单是颗粒度划分，就已经成为了各个技术大会的热门话题。如果将目光转向整个架构层面，在框架选型、服务治理、弹性伸缩等层面的挑战会更大，需要团队有非常丰富的服务化经验。

实际上，当下最新颖的服务模式是Serverless 微服务。相比于传统微服务架构，Serverless 微服务有两个特点：

1.应用全托管能力：Serverless 微服务提供从微服务代码打包、部署、监控、调用链、服务治理、弹性伸缩、版本升级回滚的全生命周期管理能力。

2.按业务运行时间收费的计费模式：按照业务微服务使用的CPU 资源使用量以及内存资源使用量进行计费，当没有访问请求的空闲期，微服务运行实例自动缩容到 1 或者 0 ，节约资源使用量，节省资源成本，做到资源最优化。

总体上，我们可以认为Serverless 微服务=CI/CD流水线+微服务框架（含注册中心和微服务治理框架）+Kubernetes/容器 + 云运维（含调用链、日志、告警、性能监控等） +弹性伸缩服务+流量治理服务。

Serverless 落地关键：不能一刀切

如果Serverless 微服务这么好，各个团队内部，是不是应该立刻推动落地Serverless 微服务？通过对华为应用市场AppGallery ConnectServerless的案例分析，我们得出的结论是，要重视并认真规划，但不能一刀切。

首先我们简单介绍下案例背景。华为应用市场AppGallery Connect平台致力于为应用的创意、开发、分发、运营、分析各环节提供全生命周期服务，提升应用的开发和运营效率，加快应用的创新与商业成功。AppGallery Connect深度整合华为内部各项优质服务，将华为在技术研发、全球化运营、质量、安全、工程管理等领域长期积累的能力开放给开发者，大幅降低应用开发与运维难度，提高应用质量，开放分发和运营服务。架构如下所示：

都在提“Serverless First” ，可你真的看懂 Serverless 了吗？

它以Serverless为底座，通过跨端SDK（AppGallery Connect Kit）、AppGallery ConnectPortal和RESTful API向移动开发者提供应用创意、开发、分发、运营和分析相关的全生命周期服务。

AppGallery Connect Serverless解决方案更聚焦于解决移动应用研发的效率问题，具体有如下几个技术特点：

1.数据安全：云数据库采用了独创的端云全密态加密技术，实现端侧和云侧数据协同加密，将基于用户口令加密的密钥云端备份，全面保障用户数据安全。

2.高性能：针对函数的冷启动在代码的传输、加载等方面做了大幅优化，利用资源池化、代码缓存、调用链预测等技术，在不改动操作系统的情况下使得函数的冷启动时延最低可达10~20ms；云数据库通过网络优化、协议优化等，实现了端云数据同步 < 120毫秒（业界通常200毫秒+）。

3.数据库的弹性伸缩：构建Serverless化的云数据库CloudDB，解决端云数据同步、多端数据同步，以及海量数据的存储问题。与传统的数据库服务相比，面向端侧的数据库服务提供了客户端与云端、客户端与客户端之间的实时数据同步机制，移动端离线可用等面向移动端的特性。底层的数据库引擎采用存算分离的分布式架构，可以按照移动端的需求自动扩展存储容量或者计算节点，向开发者屏蔽分库分表和数据库扩容迁移等问题。

4.节省人力成本：AGC云托管免去开发者应用网站的CDN、域名管理、SSL证书管理等工作，且内置全球CDN加速和全球域名管理服务，节约开发者的运维人力与成本。

目前AppGallery ConnectServerless解决方案在华为内部已经用于AppGallery Connect APP、华为快应用、翻译服务、应用市场联运活动秒杀系统等多个项目中，相比于之前的微服务架构，研发效率得到极大提升。

以华为应用市场AppGallery Connect Serverless 对翻译服务的支持为例，据 InfoQ 了解，开发团队通过使用Serverless云函数+云存储+云数据库服务，高效构建具备高可用和按需扩缩容的翻译服务，与传统架构模式相比，人力降低45%，研发周期缩短50%。

在分工方面，Serverless 方案也与传统的组织方式有所不同。架构师主要负责整体架构设计、领域模型设计、数据模型设计、函数划分。而研发工程师的角色会细分成两类，一类是功能开发，一类是业务上线。

负责功能开发的工程师职责是函数开发、单元测试、联调测试；负责业务上线的工程师，职责颇有Serverless 特色，要自助开通云函数、云存储、云数据库等服务，此外需要负责函数的上传、发布，以及设置触发器。

触发器是基于云函数的事件驱动编程的核心。这个项目涉及HTTP、CloudDB（云数据库）、CloudStorage（云存储）等多个触发器，需要以往适应串行 API 调用编程的工程师做思维和习惯上的转变，快速上手基于事件触发的异步编程。有一张对比图很形象地说明了两种编程思维模型的差异：

不可否认的是，由于大家对微服务架构熟悉度高，对Serverless 架构熟悉度相对较低，推广 Serverless 落地也可能会面临一些组织层面的阻力。对于主导人而言，落地的关键在于技术上不能一刀切，不能为了用 Serverless 而用。主导人需要深入下去熟悉业务的处理流程和技术痛点，结合 Serverless 的优势进行适配和推广落地。

AGC翻译服务最终实现的技术架构图示意如下：

落地Serverless 的技术障碍：无状态函数、限时计费、冷启动时间

说了这么多Serverless 的优势，但 Serverless 架构仍然存在一些问题，我们只列举其中最重要的三类问题供你参考，笃定 “Serverless First” 之前，还是要对此有清晰的认知。

第一类是无状态函数问题。为了更好地进行水平扩展和故障恢复，云函数是无状态的，不提供缓存能力。但大家一实践才发现，云函数虽然无状态，但业务流程通常是有状态的。一般的解决方案只能是，工程师自己操作一块外置存储保存状态，并做好读写锁。

这就导致整个开发工作比较复杂，而且天然不适合低延时场景。

但这个问题也正在被解决。还是以前文提到的华为应用市场AppGallery Connect Serverless为例，InfoQ 了解到，华为AGC正在研发有状态函数编程模型和多函数访问并发一致性模型，解决状态数据并发访问导致的死锁和状态不一致、状态数据高效读写等问题。有一个简单的示意方便你理解：

第二类是运行时间限制。Serverless 是按使用时长计费的，运行完的函数实例会被销毁，所以通常都会有运行时长的限制，避免因为同步等待、业务阻塞等问题，导致云函数长时间被挂起消耗资源。这就对一些强状态依赖的服务造成了影响。

虽然云厂商一般都会允许开发者对云函数的默认运行时长进行调整，但依然不能彻底解决这个问题。

要想治本，开发者应该尽量避免出现让函数长时间等待获取状态数据的场景，一种可行的解决方案是：可以采用有状态的函数，尽量不要把状态数据外置到第三方系统中，例如通过REST 接口从三方获取状态数据。因为一旦状态数据依赖于第三方系统时，时延、性能等指标就很难得到保证了。另一方面，通过动态计价等新技术手段，来降低函数长时间运行的费用，逐步做到按需配置运行时长，也是未来的一种技术探索方向。

第三类是云函数冷启动问题。如果函数常驻内存，会导致资源浪费，增加成本。如果每次调用都冷启动，耗时约在200毫秒左右（不同编程语言数据存在较大差异，该数据仅作参考举例），对于一些时延敏感型的业务无法接受。如何解决函数冷启动问题，是个巨大的技术挑战，也是云函数必须要攻克的难题。

反过来看，冷启动问题对于Serverless 而言，既是挑战，也是机遇。一旦加快了云函数的冷启动速度，Serverless 的适用领域将迎来大幅扩张，彻底革新主流业务架构。AppGallery ConnectServerless通过函数冷启动优化、智能化函数调度策略，流量快速感知和实例快速启动等方式来不断提升函数的启动和伸缩效率。

中间件、模型化、低代码，是Serverless 的进阶方向

当然，除了云函数的冷启动问题，中间件、模型化、低代码，也是Serverless 下一阶段比较核心的发展和进化方向。

中间件

未来Serverless 发展的一个重要趋势是，会有越来越多的中间件 Serverless 化。传统采用 SpringMVC、SpringCloud 或者微服务框架开发的业务，如果全部使用函数重写，成本会非常高。

但如果有一个Serverless 微服务，只需要做一些小的适配性修改，就可以将已有的业务代码直接 Serverless 化，享受 Serverless 带来的免运维、弹性伸缩等能力，那么任何一个架构师都会开始慎重考虑，从现有架构迁移到 Serverless 架构的可行性。

模型化

当业务依赖的Serverless 服务比较少时，尚可以按照服务的开发和部署规则，通过服务的管理控制台或者命令行 CLI 工具来进行部署。

但对于较复杂的业务，涉及同时使用多个Serverless 服务，如果没有统一的应用描述和部署工具，那么每次部署和升级的成本都会很高。

如果能将Serverless 模型化、规范化，把依赖的服务都自动开通，实现一键式自动化部署，将节省研发同学非常多的精力。

低代码平台

随着企业数字化转型的加速，传统软件开发模式的交付效率已经无法满足业务需求，企业的数字化建设滞后于业务需求，亟需提升开发效率，低代码平台逐渐成为一个技术热点。

利用低代码平台，通过图形化、拖拽、配置化和脚本化的方式即可完成应用的构建，相比于传统的开发模式，开发难度和成本都大幅下降。