Serverless是目前比拟热门的技术话题，各大云平台以及互联网大厂外部都在踊跃建设Serverless产品。本文将介绍美团Serverless产品在落地过程中的一些实践经验，其中包含技术选型的考量、零碎的具体设计、零碎稳定性优化、产品的周边生态建设以及在美团的落地状况。尽管各个公司的背景不尽相同，但总有一些能够互相借鉴的思路或办法，心愿能给大家带来一些启发或者帮忙。

1 背景

Serverless一词于2012年被提出，2014年因为亚马逊的AWS Lambda无服务器计算服务的衰亡，而被大家宽泛认知。Serverless通常被直译成“无服务器”，无服务器计算是能够让用户在不思考服务器的状况下构建并运行应用程序。应用无服务器计算，应用程序仍在服务器上运行，但所有服务器管理工作均由Serverless平台负责。如机器申请、代码公布、机器宕机、实例扩缩容、机房容灾等都由平台帮忙主动实现，业务开发只需思考业务逻辑的实现即可。

回顾计算行业的倒退历程，基础设施从物理机到虚拟机，再从虚拟机到容器；服务架构从传统单体利用架构到SOA架构，再从SOA架构到微服务架构。从基础设施和服务架构两条主线来看整体技术发展趋势，大家可能会发现，不论是基础设施还是服务架构，都是从大往小或者由巨到微的方向上演进，这种演变的实质准则无非是解决资源老本或者研发效率的问题。当然，Serverless也不例外，它也是用来解决这两个方面的问题：

  • 资源利用率：Serverless产品反对疾速弹性伸缩能力，可能帮忙业务晋升资源利用率，在业务流量顶峰时，业务的计算能力、容量主动扩容，承载更多的用户申请，而在业务流量下降时，所应用的资源也会同时膨胀，防止资源节约。
  • 研发运维效率：在Serverless上开发人员个别只须要填写代码门路或者上传代码包，平台可能帮忙实现构建、部署的工作。开发人员不间接面对机器，对于机器的治理，机器是否失常以及流量高下峰的是否须要扩缩容等问题，这些通通不须要去思考，由Serverless产品帮忙研发人员去实现。这样就能使他们从繁琐的运维工作中解放出来，从DevOps转向NoOps，更加专一于业务逻辑的实现。

尽管AWS在2014年就推出了第一个Serverless产品Lambda，但Serverless技术在国内的利用始终不温不火。不过近两三年，在容器、Kubernetes以及云原生等技术的推动下，Serverless技术迅速倒退，国内各大互联网公司都在踊跃建设Serverless相干产品，摸索Serverless技术的落地。在这种背景下，美团也于2019年初开始了Serverless平台的建设，外部项目名称为Nest。

截止到目前，Nest平台曾经过两年的建设，回顾整体的建设过程，次要经验了以下三个阶段：

  • 疾速验证，落地MVP版本：咱们通过技术选型、产品与架构设计、开发迭代，疾速落地了Serverless产品的根本的能力，如构建、公布、弹性伸缩、对接触发祥、执行函数等。上线后，咱们推动了一些业务的试点接入，帮忙验证打磨产品。
  • 优化核心技术，保障业务稳定性：有了后期的试点业务验证，咱们很快发现产品的存在的一些稳定性相干的问题，次要有弹性伸缩的稳定性、冷启动的速度、零碎与业务的可用性、容器的稳定性。针对这些问题咱们对各个问题波及的技术点做了专项的优化改良。
  • 欠缺技术生态，落实收益：优化了核心技术点后，产品逐步成熟稳固，但仍然面临生态性问题，如研发工具欠缺，上下游产品没有买通、平台凋谢能力有余等问题，影响或妨碍了产品的推广应用。因而，咱们持续欠缺产品的技术生态，扫清业务接入应用阻碍，落实产品的业务收益。

2 疾速验证，落地MVP版本

2.1 技术选型

建设Nest平台，首要解决的就是技术选型问题，Nest次要波及三个关键点的选型：演进路线、基础设施、开发语言。

2.1.1 演进路线

起初Serverless服务次要蕴含FaaS（Function as a Service）和BaaS（Backend as a Service），近几年Serverless的产品畛域有所扩张，它还蕴含面向利用的Serverless服务。

  • FaaS：是运行在一个无状态的计算容器中的函数服务，函数通常是事件驱动、生命周期很短（甚至只有一次调用）、齐全由第三方治理的。业界相干FaaS产品有AWS的Lambda、阿里云的函数计算等。
  • BaaS：是建设在云服务生态之上的后端服务。业界相干BaaS产品包含AWS的S3、DynamoDB等。

面向利用的Serverless服务：如Knative，它提供了从代码包到镜像的构建、部署，以及弹性伸缩等全面的服务托管能力，私有云产品有Google Cloud Run（基于Knative）、阿里云的SAE（Serverless Application Engine）。

在美团外部，BaaS产品其实就是外部的中间件以及底层服务等，它们通过多年的倒退，曾经十分丰盛且成熟了。因而，在美团的Serverless产品演进次要在函数计算服务和面向利用的Serverless服务两个方向上。那到底该如何演进呢？过后次要思考到在业界FaaS函数计算服务绝对于面向利用的Serverless服务来说，更加成熟且确定。因而，咱们决定“先建设FaaS函数计算服务，再建设面向利用的Serverless服务”这样一条演进路线。

2.1.2 基础设施

因为弹性伸缩是Serverless平台必备的能力，因而Serverless必然波及到底层资源的调度和治理。这也是为什么以后业界有很多开源的Serverless产品（如OpenFaaS、Fission、Nuclio、Knative等）是基于Kubernetes来实现的，因为这种选型可能充分利用Kubernetes的基础设施的治理能力。在美团外部基础设施产品是Hulk，尽管Hulk是基于Kubernetes封装后的产品，但Hulk在落地之初思考到落地难度以及各种起因，最终未依照原生的形式来应用Kubernetes，并且在容器层采纳的也是富容器模式。

在这种历史背景下，咱们在做基础设施选型时就面临两种选项：一是应用公司的Hulk来作为Nest的基础设施（非原生Kubernetes），二是采纳原生Kubernetes基础设施。咱们思考到以后业界应用原生Kubernetes是支流趋势并且应用原生Kubernetes还能充分利用Kubernetes原生能力，能够缩小反复开发。因而，最终考量的后果是咱们采纳了原生Kubernetes作为咱们的基础设施。

2.1.3 开发语言

因为在云原生畛域的支流语言是Golang，并且Kubernetes的生态中，Golang是相对的主导语言。但在美团，Java才是应用最宽泛的语言，相比Golang，Java在公司外部生态比拟好。因而，在语言的选型上咱们抉择了Java语言。在Nest产品开发之初，Kubernetes社区的Java客户端还不够欠缺，但随着我的项目的推动，社区的Java客户端也逐步丰盛了起来，目前曾经齐全够用了。另外，咱们也在应用过程中，也奉献了一些Pull Request，反哺了社区。

2.2 架构设计

基于以上的演进路线、基础设施、开发语言的选型，咱们进行了Nest产品的架构设计。

在整体的架构上，流量由EventTrigger（事件触发源，如Nginx、利用网关、定时工作、音讯队列、RPC调用等）触发到Nest平台，Nest平台内会依据流量的特色路由到具体函数实例，触发函数执行，而函数外部代码逻辑能够调用公司内的各个BaaS服务，最终实现函数的执行，返回后果。

在技术实现上，Nest平台应用Kubernetes作为根底底座并适当参考了一些Knative的优良设计，在其架构外部次要由以下几个外围局部组成：

  • 事件网关：外围能力是负责对接内部事件源的流量，而后路由到函数实例上；另外，网关还负责统计各个函数的进出流量信息，为弹性伸缩模块提供伸缩决策的数据撑持。
  • 弹性伸缩：外围能力是负责函数实例的弹性伸缩，伸缩次要依据函数运行的流量数据以及实例阈值配置计算函数指标实例个数，而后借助Kubernetes的资源控制能力，调整函数实例的个数。
  • 控制器：外围能力是负责Kubernetes CRD（Custom Resource Definition）的管制逻辑实现。
  • 函数实例：函数的运行实例。当事件网关流量触发过去，会在函数实例内执行相应的函数代码逻辑。
  • 治理平台：面向用户应用的平台，负责函数的构建、版本、公布以及一些函数元信息的治理等。

2.3 流程设计

在具体的CI/CD流程上，Nest又与传统的模式有何区别呢？为了阐明这个问题，咱们先来看一看在Nest平台上函数的整体生命周期怎么的？具体有以下四个阶段：构建、版本、部署、伸缩。

  • 构建：开发的代码和配置通过构建生成镜像或可执行文件。
  • 版本：构建生成的镜像或可执行文件加上公布配置造成一个不可变的版本。
  • 部署：将版本公布，即实现部署。
  • 伸缩：依据函数实例的流量以及负载等信息，来进行实例的弹性扩缩容。

就这四个阶段来看，Nest与传统的CI/CD流程本质区别在于部署和伸缩：传统的部署是感知机器的，个别是将代码包公布到确定的机器上，但Serverless是要向用户屏蔽机器的（在部署时，可能函数的实例数还是0）；另外，传统的模式个别是不具备动静扩缩容的，而Serverless则不同，Serverless平台会依据业务的本身流量须要，进行动静扩缩容。后续章节会具体解说弹性伸缩，因而这里咱们只探讨部署的设计。

部署的外围点在于如何向用户屏蔽机器？对于这个问题，咱们形象了机器，提出了分组的概念，分组是由SET（单元化架构的标识，机器上会带有该标识）、泳道（测试环境隔离标识，机器上会带有该标识）、区域（上海、北京等）三个信息组成。用户部署只需在相应的分组上进行操作，而不必波及到具体机器。可能做到这些的背地，是由Nest平台帮忙用户治理了机器资源，每次部署会依据分组信息来实时初始化相应的机器实例。

2.4 函数触发

函数的执行是由事件触发的。实现函数的触发，须要实现以下四个流程：

  • 流量引入：向事件源注册事件网关的信息，将流量引入到事件网关。如针对MQ事件源，通过注册MQ的生产组，引入MQ的流量到事件网关。
  • 流量适配：事件网关对事件源进入的流量进行适配对接。
  • 函数发现：对函数元数据（函数实例信息、配置信息等）的获取过程，相似微服务的服务发现过程。事件网关承受的事件流量须要发送到具体的函数实例，这就须要对函数进行发现。这里发现本质是获取Kubernetes中的内置资源或者CRD资源中存储的信息。
  • 函数路由：事件流量的路由过程，路由到特定的函数实例上。这里为了反对传统路由逻辑（如SET、泳道、区域路由等）以及版本路由能力，咱们采纳了多层路由，第一层路由到分组（SET、泳道、区域路由），第二层路由到具体版本。同版本内的实例，通过负载均衡器抉择出具体实例。另外，通过该版本路由，咱们很轻松的反对了金丝雀、蓝绿公布。

2.5 函数执行

函数不同于传统的服务，传统的服务是个可执行的程序，但函数不同，函数是代码片段，本身是不能独自执行的。那流量触发到函数实例后，函数是如何执行的呢？

函数的执行的首要问题是函数的运行环境：因为Nest平台是基于Kubernetes实现的，因而函数肯定是运行在Kubernetes的Pod（实例）内，Pod外部是容器，容器的外部是运行时，运行时是函数流量接管的入口，最终也是由运行时来触发函数的执行。所有看起来是那么的顺利成章，但咱们在落地时是还是遇到了一些艰难，最次要的艰难是让开发同学能够在函数内无缝的应用公司内的组件，如OCTO（服务框架）、Celler（缓存零碎）、DB等。

在美团的技术体系中，因为多年的技术积淀，很难在一个纯正的容器（没有任何其余依赖）中运行公司的业务逻辑。因为公司的容器中积淀了很多环境或服务治理等能力，如服务治理的Agent服务以及实例环境配置、网络配置等。

因而，为了业务在函数内无缝的应用公司内的组件，咱们复用公司的容器体系来升高业务编写函数的老本。但复用公司的容器体系也没那么简略，因为在公司内没有人试过这条路，Nest是公司第一个基于原生Kubernetes建设的平台，“第一个吃螃蟹的人”总会遇到一些坑。对于这些坑，咱们只能在推动过程中“逢山开路，遇水搭桥”，遇到一个解决一个。总结下来，其中最外围的是在容器的启动环节买通的CMDB等技术体系，让运行函数的容器与开发同学平时申请的机器用起来没有任何区别。

2.6 弹性伸缩

弹性伸缩的外围问题次要有三个：什么时候伸缩，伸缩多少，伸缩的速度快不快？也就是伸缩机会、伸缩算法、伸缩速度的问题。

  • 伸缩机会：依据流量Metrics实时计算函数冀望实例数，进⾏扩缩。流量的Metrics数据来自于事件网关，这里次要统计函数的并发度指标，弹性伸缩组件每秒中会被动从事件网关获取一次Metrics数据。
  • 伸缩算法：并发度/单实例阈值=冀望实例数。依据收集的Metrics数据以及业务配置的阈值，通过算法计算出冀望的实例数，而后通过Kubernetes接口设置具体实例数。整个算法看起来尽管简略，但十分稳固、鲁棒性好。
  • 伸缩速度：次要取决于冷启动工夫，在下个章节会具体解说这块内容。

除了根本的扩缩容能力，咱们还反对了伸缩到0，反对配置最大、最小实例数（最小实例即预留实例）。伸缩到0的具体实现是，咱们在事件网关外部减少了激活器模块，当函数无实例时，会将函数的申请流量缓存在激活器外部，而后立刻通过流量的Metrics去驱动弹性伸缩组件进行扩容，等扩容的实例启动实现后，激活器再将缓存的申请重试到扩容的实例上触发函数执行。

3 优化核心技术，保障业务稳定性

3.1 弹性伸缩优化

下面提到的伸缩机会、伸缩算法、伸缩速度这三要素都是现实状况下的模型，尤其是伸缩速度，以后技术基本做不到毫秒级别的扩缩容。因而，在线上理论场景中，弹性伸缩会存在一些不合乎预期的状况，比方实例伸缩比拟频繁或者扩容来不及，导致服务不太稳固的问题。

  • 针对实例伸缩比拟频繁问题，咱们在弹性伸缩组件内保护了统计数据的滑动窗⼝，通过计算均值来平滑指标，还通过延时缩容，实时扩容来缓解频繁扩缩问题。另外，咱们减少了基于QPS指标的伸缩策略，因为QPS指标绝对并发度指标会更加稳固。
  • 针对扩容来不及问题，咱们采取提前扩容的伎俩，当达到实例阈值的70%就扩容，可能比拟好的缓解这个问题。除此之外，咱们还反对了多指标混合伸缩（并发度、QPS、CPU、Memory），定时伸缩等策略，满足各种业务需要。

下图展现的是线上弹性伸缩的实在案例（其配置的最小实例数为4，单实例阈值100，阈值使用率0.7），其中上半局部是业务每秒的申请数，下半局部是扩缩实例的决策图，能够看到在成功率100%的状况下，业务完满应答流量顶峰。

3.2 冷启动优化

冷启动是指在函数调用链路中蕴含了资源调度、镜像/代码下载、启动容器、运行时初始化、用户代码初始化等环节。当冷启动实现后，函数实例就绪，后续申请就能间接被函数执行。冷启动在Serverless畛域至关重要，它的耗时决定了弹性伸缩的速度。

所谓“天下文治，无坚不破，唯快不破”，这句话在Serverless畛域也同样受用。试想如果拉起一个实例足够快，快到毫秒级别，那简直所有的函数实例都能够缩容到0，等有流量时，再扩容实例解决申请，这对于存在高下峰流量的业务将极大的节俭机器资源老本。当然，现实很饱满，事实很骨感。做到毫秒级别简直不可能。但只有冷启动工夫越来越短，老本天然就会越来越低，另外，极短的冷启动工夫对伸缩时函数的可用性以及稳定性都有莫大的益处。

冷启动优化是个循序渐进的过程，咱们对冷启动优化次要经验了三个阶段：镜像启动优化、资源池优化、外围门路优化。

  • 镜像启动优化：咱们对镜像启动过程中的耗时环节（启动容器和运行时初始化）进行了针对性优化，次要对容器IO限速、一些非凡Agent启动耗时、启动盘与数据盘数据拷贝等关键点的优化，最终将启动过程中的零碎耗时从42s优化到12s左右。

  • 资源池优化：镜像启动耗时优化到12s，根本曾经快达到瓶颈点，再持续优化空间不大。因而，咱们想是否绕开镜像启动的耗时环节？最终，咱们采纳了一个比较简单思路“空间换工夫”，用资源池计划：缓存一些已启动的实例，当须要扩容时，间接从资源池获取实例，绕开镜像启动容器的环节，最终成果很显著，将启动的零碎耗时从12s优化到3s。这里须要阐明的是资源池本身也是通过Kubernetes的Depolyment进行治理，池中实例被取走会立刻主动补充。

  • 外围门路优化：在资源池优化的根底上，咱们再次精益求精，针对启动流程中的下载与解压代码两个耗时环节进行优化，过程中咱们采纳了高性能的压缩解压算法（LZ4与Zstd）以及并行下载和解压技术，成果十分好。另外，咱们还反对了通用逻辑（中间件、依赖包等）下沉，通过预加载的形式，最终将函数端到端的启动耗时优化到2s，这就意味着扩容一个函数实例只须要2s（蕴含函数启动）。如果排除掉函数本身的初始化启动耗时，平台侧的耗时已在毫秒级别。

3.3 高可用保障

说到高可用，对于个别的平台，指的就是平台本身的高可用，但Nest平台有所不同，Nest的高可用还蕴含托管在Nest平台上的函数。因而，Nest的高可用保障须要从平台和业务函数两个方面着手。

3.3.1 平台高可用

对平台的高可用，Nest次要从架构层、服务层、监控经营层、业务视角层面都做了全面的保障。

  • 架构层：咱们针对有状态服务，如弹性伸缩模块，采纳了主从架构，当主节点异样时从节点会立刻替换。另外，咱们还实现了架构上的多层隔离。 横向地区隔离：Kubernetes两地两集群强隔离、服务（事件网关、弹性伸缩）集群内两地弱隔离（上海的弹性伸缩只负责上海Kubernetes集群内的业务伸缩，事件网关存在两地调用需要，需拜访两地Kubernetes）。纵向业务线隔离：服务业务线强隔离，不同业务线应用不同集群服务；在Kubernetes层的资源用namespace实现业务线弱隔离。

  • 服务层：次要指的是事件网关服务，因为所有的函数流量都通过事件网关，因而事件网关的可用性尤为重要，这层咱们反对了限流和异步化，保障服务的稳定性。
  • 监控经营层：次要通过欠缺系统监控告警、梳理外围链路并推动相干依赖方进行治理。另外，咱们会定期梳理SOP并通过故障演练平台施行故障注入演练，发现零碎隐患问题。
  • 业务视角层：咱们开发了在线不间断实时巡检服务，通过模仿用户函数的申请流量，实时检测零碎的外围链路是否失常。

3.3.2 业务高可用

对于业务高可用，Nest次要从服务层、平台层两个层面做了相干的保障。

  • 服务层：反对了业务降级、限流能力：当后端函数故障时，可通过降级配置，返回降级后果。针对异样的函数流量，平台反对限度其流量，避免后端函数实例的被异样流量打垮。
  • 平台层：反对了实例保活、多层级容灾以及丰盛的监控告警能力：当函数实例异样时，平台会主动隔离该实例并立刻扩容新实例。平台反对业务多地区部署，在同地区将函数实例尽可能打散不同机房。当宿主机、机房、地区故障时，会立刻在可用宿主机、可用机房或可用区重建新实例。另外，平台主动帮业务提供了函数在时延、成功率、实例伸缩、申请数等多种指标的监控，当在这些指标不合乎预期时，主动触发告警，告诉业务开发和管理员。

3.4 容器稳定性优化

前文已提到，Serverless与传统模式在CI/CD流程上是不同的，传统模式都是当时筹备好机器而后部署程序，而Serverless则是依据流量的高下峰实时弹性扩缩容实例。当新实例扩容进去后，会立刻解决业务流量。这听起来貌似没什么故障，但在富容器生态下是存在一些问题的：咱们发现刚扩容的机器负载十分高，导致一些业务申请执行失败，影响业务可用性。

剖析后发现次要是因为容器启动后，运维工具会进行Agent降级、配置批改等操作，这些操作十分耗CPU。同在一个富容器中，天然就抢占了函数过程的资源，导致用户过程不稳固。另外，函数实例的资源配置个别比传统服务的机器要小很多，这也加剧了该问题的严重性。基于此，咱们参考业界，联结容器设施团队，落地了轻量级容器，将运维的所有Agent放到Sidecar容器中，而业务的过程独自放到App容器中。采纳这种容器的隔离机制，保障业务的稳定性。同时，咱们也推动了容器裁剪打算，去掉一些不必要的Agent。

4 欠缺生态，落实收益

Serverless是个系统工程，在技术上波及到Kubernetes、容器、操作系统、JVM、运行时等各种技术，在平台能力上波及到CI/CD各个流程的方方面面。

为了给用户提供极致的开发体验，咱们为用户提供了开发工具的反对，如CLI（Command Line Interface）、WebIDE等。为了解决现有上下游技术产品的交互的问题，咱们与公司现有的技术生态做了交融买通，不便开发同学应用。为了不便上游的集成平台对接，咱们凋谢了平台的API，实现Nest赋能各上游平台。针对容器过重，零碎开销大，导致低频业务函数本身资源利用率不高的问题，咱们反对了函数合并部署，成倍晋升资源利用率。

4.1 提供研发工具

开发工具可能升高平台的应用老本，帮忙开发同学疾速的进行CI/CD流程。目前Nest提供了CLI工具，帮忙开发同学疾速实现创立利用、本地构建、本地测试、Debug、近程公布等操作。Nest还提供了WebIDE，反对在线一站式实现代码的批改、构建、公布、测试。

4.2 交融技术生态

仅反对这些研发工具还是不够的，我的项目推广应用后，咱们很快就发现开发同学对平台有了新的需要，如无奈在Pipeline流水线、线下服务实例编排平台上实现对函数的操作，这对咱们我的项目的推广也造成了一些妨碍。因而，咱们交融这些公司的成熟技术生态，买通了Pipeline流水线等平台，融入到现有的上下游技术体系内，解决用户的后顾之忧。

4.3 开放平台能力

有很多Nest的上游解决方案平台，如SSR（Server Side Render）、服务编排平台等，通过对接Nest的OpenAPI，实现了生产力的进一步解放。例如，不必让开发同学本人去申请、治理和运维机器资源，就可能让用户十分疾速的实现一个SSR我的项目或者编排程序从0到1的创立、公布与托管。

Nest除了凋谢了平台的API，还对用户提供了自定义资源池的能力，领有了该项能力，开发同学能够定制本人的资源池，定制本人的机器环境，甚至能够下沉一些通用的逻辑，实现冷启动的进一步优化。

4.4 反对合并部署

合并部署指的是将多个函数部署在一个机器实例内。合并部署的背景次要有两个：

  • 以后的容器较重，容器本身的零碎开销较大，导致业务过程资源利用率不高（尤其是低频业务）。
  • 在冷启动耗时不能满足业务对时延的要求的状况下，咱们通过预留实例来解决业务的需要。

基于这两个背景，咱们思考反对合并部署，将一些低频的函数部署到同一个机器实例内，来晋升预留实例中业务过程的资源利用率。

在具体实现上，咱们参考Kubernetes的设计方案，设计了一套基于Sandbox的函数合并部署体系（每个Sandbox就是一个函数资源），将Pod类比成Kubernetes的Node资源，Sandbox类比成Kubernetes的Pod资源，Nest Sidecar类比成Kubelet。为了实现Sandbox特有的部署、调度等能力，咱们还自定义了一些Kubernetes资源（如SandboxDeployment、SandboxReplicaSet、SandboxEndpoints等）来反对函数动静插拔到具体的Pod实例上。

除此之外，在合并部署的状态下，函数之间的隔离性也是不可回避的问题。为了尽可能的解决函数（合并在同一个实例中）之间的相互烦扰问题，在Runtime的实现上，咱们针对Node.js和Java语言的特点采取了不同的策略：Node.js语言的函数应用不同的过程来实现隔离，而Java语言的函数，咱们采纳类加载隔离。采纳这种策略的次要起因是因为Java过程占用内存空间相较于Node.js过程会大很多。

5 落地场景、收益

目前Nest产品在美团前端Node.js畛域十分受欢迎，也是落地最宽泛的技术栈。以后Nest产品在美团前端已实现了规模化落地，简直涵盖了所有业务线，接入了大量的B/C端的外围流量。

5.1 落地场景

具体的落地前端场景有：BFF（Backend For Frontend）、CSR（Client Side Render）/SSR（Server Side Render）、后盾治理平台场景、定时工作、数据处理等。

  • BFF场景：BFF层次要为前端页面提供数据，采纳Serverless模式，前端同学不须要思考不善于的运维环节，轻松实现了BFF向SFF（Serverless For Frontend）模式的转变。
  • CSR/SSR场景：CSR/SSR指的是客户端渲染和服务端渲染，有了Serverless平台，不必思考运维环节，更多的前端业务来尝试应用SSR来实现前端首屏的疾速展示。
  • 后盾治理平台场景：公司有很多的后盾治理平台的Web服务，它们尽管相较于函数是比拟重的，但齐全能够间接托管Serverless平台，充沛享受Serverless平台极致的公布和运维效率。
  • 定时工作场景：公司存在很多周期性工作，如每隔几秒拉取数据，每天0点清理日志，每小时收集全量数据并生成报表等，Serverless平台间接与任务调度零碎买通，只需写好工作的解决逻辑并在平台上配置定时触发器，即实现定时工作的接入，齐全不必治理机器资源。
  • 数据处理场景：将MQ Topic作为事件源接入Serverless平台，平台会主动订阅Topic的音讯，当有音讯生产时，触发函数执行，相似定时工作场景，作为用户也只需写好数据处理的逻辑并在平台上配置好MQ触发器，即实现MQ生产端的接入，齐全不必治理机器资源。

5.2 落地收益

Serverless的收益是非常明显的，尤其在前端畛域，大量的业务接入已是最好的阐明。具体收益，从以下两个方面别离来看：

  • 降老本：通过Serverless的弹性伸缩能力，高频业务资源利用率能晋升到40%～50%；低频业务函数通过合并部署，也能极大升高函数运行老本。

  • 提效率：整体研发研发效率晋升约40%。

    • 从代码开发来看，提供齐备的CLI、WebIDE等研发工具，可能帮忙开发同学生成代码脚手架，聚焦编写业务逻辑，疾速实现本地测试；另外，让业务服务零老本具备在线查看日志与监控的能力。
    • 从公布来看，通过云原生的模式，业务无需申请机器，公布、回滚都是秒级别的体验。另外，还能利用平台人造能力，配合事件网关，实现切流、实现金丝雀测试等。
    • 从日常运维来看，业务无需关注机器故障、资源有余、机房容灾等传统模式该思考的问题，另外，当业务过程异样时，Nest可能主动实现异样实例的隔离，迅速拉起新实例实现替换，升高业务影响。

6 将来布局

  • 场景化解决方案：接入Serverless的场景泛滥，如SSR、后盾治理端、BFF等，不同的场景有不同的我的项目模板、场景配置，如伸缩配置、触发器配置等，另外，不同的语言，配置也有所不同。这无形中减少了业务的应用老本，给新业务的接入带来了妨碍。因而，咱们思考场景化的思路来建设平台，将平台的能力与场景强关联起来，平台深度积淀各场景的根本配置和资源，这样不同的场景，业务只须要简略的配置就能够将Serverless玩转起来。
  • 传统微服务Serverless化：传统微服务的Serverless化即是路线选型中提到的面向利用的Serverless服务。在美团应用最广的开发语言是Java，公司外部存在大量的传统的微服务项目，这些我的项目如果都迁徙到函数模式，显然是不事实的。试想如果这些传统的微服务项目不必革新，也能间接享受Serverless的技术红利，其业务价值显而易见。因而，传统微服务的Serverless化是咱们将来拓展业务的一个重要方向。在施行门路上，咱们会思考将服务治理体系（如ServiceMesh）与Serverless做技术交融，服务治理组件为Serverless提供伸缩指标反对并在伸缩过程中实现精准的流量调配。
  • 冷启动优化：以后尽管函数的冷启动优化曾经获得了较好的问题，尤其是平台侧的系统启动耗时，晋升空间曾经十分无限，但业务代码本身的启动耗时还是十分突出，尤其是传统Java微服务，根本是分钟级别的启动耗时。因而，后续咱们的冷启动优化会重点关注业务本身的启动耗时，争取极大升高业务本身的启动工夫。在具体优化办法上，咱们会思考采纳AppCDS、GraalVM等技术，升高业务本身启动耗时。

  • 其余布局

    • 丰盛欠缺研发工具，晋升研发效率，如IDE插件等。
    • 买通上下游技术生态，深度融入公司现有技术体系，缩小因上下游平台带来应用阻碍。
    • 容器轻量化，轻量化的容器可能带来更优的启动耗时以及更佳的资源利用率，因而，容器轻量化始终是Serverless的不懈谋求。在具体落地上，筹备联结容器设施团队一起推动容器中的一些Agent采纳DaemonSet形式部署，下沉到宿主机，晋升容器的有效载荷。

作者简介

  • 殷琦、华珅、飞飞、志洋、奕锟等，来自基础架构部利用中间件团队。
  • 佳文、凯鑫，亚辉等，来自金融技术平台大前端团队。

招聘信息

美团基础架构团队诚招高级、资深技术专家，Base北京、上海。咱们致力于建设美团全公司对立的高并发高性能分布式基础架构平台，涵盖数据库、分布式监控、服务治理、高性能通信、消息中间件、根底存储、容器化、集群调度等基础架构次要的技术畛域。欢送有趣味的同学投送简历到：tech@meituan.com。

浏览美团技术团队更多技术文章合集

前端 | 算法 | 后端 | 数据 | 平安 | 运维 | iOS | Android | 测试

| 在公众号菜单栏对话框回复【2020年货】、【2019年货】、【2018年货】、【2017年货】等关键词，可查看美团技术团队历年技术文章合集。

| 本文系美团技术团队出品，著作权归属美团。欢送出于分享和交换等非商业目标转载或应用本文内容，敬请注明“内容转载自美团技术团队”。本文未经许可，不得进行商业性转载或者应用。任何商用行为，请发送邮件至tech@meituan.com申请受权。