美团是如何解决落地Serverless的五大难题的

转载赞收藏评论

举报 2022-05-09

扫描,分享朋友圈

近年来，在容器、Kubernetes、云原生等技术推动下，Serverless 技术也迎来了迅速发展，国内各大厂都在积极建设 Serverless 相关产品，美团也于 2019 年初开始了 Serverless 平台的建设。Serverless 平台的建设挑战较多，例如技术选型、冷启动优化、高可用保障、容器稳定性提升、研发体系建设等。

在 QCon 全球软件开发大会（2021）北京站上，美团基础技术部技术专家殷琦分享了美团面对 Serverless 平台落地的探索与实践。我们整理了他的演讲，以期解决您在 Serverless 落地时可能遭遇的某些类似问题。（下文以殷琦老师第一人称叙述）

美团之所以选择建设 Serverless，是因为现阶段业务遇到资源利用率低、研发成本高、运维成本高三类问题，具体来说：

第一，公司大部分业务流量存在明显波峰、波谷现象，另外还存在大量低频业务。为了保证业务 SLA 和容灾要求需要进行冗余部署，这就导致服务的资源利用率较低。

第二，在研发方面：a. 运维流程繁琐（如申请机器、构建或发布配置、申请域名等）；b. 组件平台不统一，建设一个服务需熟悉并使用多个组件平台（如日志中心、网关等）；c. 各个中间件开发模型不统一（如 RPC 和 MQ 组件开发模型差异大），学习使用成本高；d. 发布、回滚慢，影响迭代速度。

第三，公司在节点异常、机房级别容灾、安全风险组件升级时均需要人工处理，存在大量运维和运营成本。这点对 Node.js 开发同学来说痛点尤为突出，因为 Node.js 不太熟悉后端的运维和运营动作。

Serverless 在产品形态上分为 3 种：FaaS（Function as a Service）、BaaS（Backend as a Service）和面向应用的 Serverless 服务。FaaS 即函数服务，如 AWS 的 Lambda，BaaS 即云上 PaaS 组件，如 DB、消息队列等；近几年新提出来的面向应用的 Serverless 服务，即阿里云的 SAE（Serverless 应用引擎）、谷歌开源的 Knative 等。

Serverless 运行架构比较简单：触发源触发 FaaS 平台，FaaS 平台内部会去执行包含业务逻辑的函数，函数内部逻辑可以调用各种 BaaS 组件。

Serverless 具有以下特点：弹性伸缩、按需付费、事件驱动、无需运维。其中，弹性伸缩和按需付费可解决资源利用率低，成本高的问题；事件驱动可统一编程模型，降低研发成本；无需运维可以降低运维成本。

公司内部 Serverless 产品为 Nest，这个项目是 19 年初开始立项，主要经过了三个阶段演进：第一，快速落地，上线试点；第二，优化技术，提升稳定性；第三，完善生态，提升效能。具体里程碑如下图所示：

选型与实现原理

技术选型

技术选型需要关注三点：演进路线、基础设施、开发语言。

演进路线上，我们主要权衡当前的三种 Serverless 形态（FaaS、BaaS 和面向应用的 Serverless 服务）。首先考虑到私有云上的 BaaS 实为中间件及其他 PaaS 产品，这方面美团已相对比较成熟，可建设的空间不大。其次考虑到面向应用的 Serverless 服务还不太成熟，尤其是冷启动问题暂时还没有较好的解决办法。因此，我们决定先做 FaaS。

公司内部基础设施为自研Hulk。Hulk 本身基于 Kubernetes，但考虑到落地推进的阻碍，主力集群未完全应用 Kubernetes 的能力。我们考虑业界注重 Kubernetes 原生能力的未来趋势，Nest 选用了原生 Kubernetes（由 Hulk 团队提供的原生的 Kubernetes 形态的产品 MKE）。

开发语言和基础设施相关。Kubernetes 主流开发语言为 Go，但公司内部 Java 研发生态更加完善且应用广泛，因此考虑再三我们选择了 Java 语言。Java 语言的 Kubernetes 客户端，虽然当时不是很完备，但随着这两年的发展，目前应对基础开发已绰绰有余。

本文系作者授权数英发表，内容为作者独立观点，不代表数英立场。
转载请在文章开头和结尾显眼处标注：作者、出处和链接。不按规范转载侵权必究。