Serverless 服务选型

综述

近两年来，Serverless 概念在开发者中交流的越来越多，实践、服务、产品层出不穷。
Serverless 的主题分享呈现爆发趋势，如在云原生领域颇具影响力的 KubeCon&CloudNativeCon 会议中，关于 Serverless 的主题，2018 年有 20 个，到 2019 年增长至 35 个。
产品层面，从最早的 AWS Lambda，到 Azure Functions、Goolge Functions、Google CloudRun，再到国内阿里云 Serverless Kubernetes、Serverless 应用引擎、函数计算等，面向计算的 Serverless 云上基础设施越来越丰富。

新概念、新产品的产生不是凭空出现，它们诞生之初要解决的是当前问题。随着实践者对问题域的理解越来越清晰和深刻，会逐步迭代问题的处理方法，提供更接近问题本质的解决方案。
若不从问题域出发来理解解决方案，容易陷入两个极端，即「它能解决一切问题」「它太超前了，理解不了」。

本篇文章尝试以日常开发流程为起点，分析每个阶段面对的问题，然后组合解决方案，提炼面向 Serverless 的开发模型，并与业界提出的 Serverless 产品形态做对应，为开发者采用 Serverless 架构和服务提供参考。

迭代模型

从项目整体视角来看：

这个模型的目标是满足客户需求。通过 被动迭代 满足客户提出的需求，同时逐步深刻理解客户需求的本质，通过 主动迭代 和客户一起采用更好的方案或从根源解决面对的问题。
每次的需求反馈会加深对客户需求的理解，提供更满足需求的服务。每次的 bug 反馈会加深对处理方案的理解，提供更稳定的服务。
在模型启动后，日常的核心问题就集中在了 如何加速迭代。

为了解决迭代加速的问题，需要了解有哪些制约因素，有的放矢。下述是从开发视角看到的开发模型：

虽然会有不同的开发语言和架构，但在每个阶段均有通用的问题，如：

除了要解决上述通用问题，还需要提供标准化的方案，降低开发者的学习和使用成本，缩短从想法到上线的时间。

若将上述过程中不同阶段花费的时间做个分析，在项目整个生命周期中会发现：

部署&运维占用的时间和精力，会远大于开发&测试
通用逻辑占用的时间和精力，会接近甚至超过业务逻辑

为了加速迭代，需要依次解决占用时间和精力多的部分，如图 1：

从左至右，通过下放不同层次的运维工作，降低「部署&运维」成本。在降低了运维工作成本后，在「通用逻辑」层面降低成本。二者结合起来，在迭代过程中更深入聚焦业务。
该过程也是从 Cloud Hosting 到 Cloud Native 的过程，充分享受云原生带来的技术红利。

由于软件设计架构和部署架构与当时环境耦合度高，面对新的理念和服务、产品，存量应用迭代过程中采用的技术需要有相应调整，即开发和部署方式需要有一定的改造。新应用的开发和部署应用新的理念时，有一定的学习和实践成本。
故上述过程不能一蹴而就，需要根据业务当前的痛点优先级来选择匹配的服务和产品，并根据未来的规划提前进行技术预研，在不同的阶段选择适合的服务和产品。

Serverless 简介

维基百科对于 Serverless 有较为完备的定义 [1]:

Serverless computing is a cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity. It can be a form of utility computing.

在这种计算模型下，给用户会带来如下收益：

Serverless computing can simplify the process of deploying code into production. Scaling, capacity planning and maintenance operations may be hidden from the developer or operator. Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all.

概念本质上是对问题域的抽象，是对问题域特征的总结。通过特征来理解概念，可以避免注意力集中在文字描述而非概念的价值本身。
站在用户角度，我们可以抽象出 Serverless 的如下特征：

免运维 (服务器运维、容量管理、弹性伸缩等)
按资源的使用量付费

在一定规模的公司中，若严格区分开发和运维的角色，这种计算形态其实是已经存在的，并非全新的事物。但目前的技术趋势，是期望借助云的规模和技术红利优势，通过上云来降低业务在技术侧的成本，并通过技术红利反哺业务。故业界对于 Serverless 的讨论，注意力是集中在云上的服务和产品所体现的 Serverless 能力。

Serverless 开发模型

Martin Fowler 的这篇文章 [2] 站在架构的角度，对 Serverless 开发模型做了充分的阐述，这里做个简单的总结，核心围绕三点：

Event-driven 开发模型
自动弹性伸缩
OpenAPI

Serverless 开发采用 Event-driven 模型 [3]，围绕 HTTP/HTTPS 请求、时间、消息等 Event 的生产和响应进行架构设计。在这样的模型中，Event 的生产、处理流程是核心，通过 Event 驱动整个服务流程，注意力集中在整个处理流程。对业务理解越深刻，Event 类型和业务会越匹配，技术和业务的相互促进作用会越有效。
Event-driven 模型，使得 服务常驻 这种理念从必选项转变为可选项，可以更好应对业务请求量的变化，如自动弹性伸缩。同时服务非常驻，可以降低所需的资源成本和维护成本，加速项目迭代。

通过文章 [2] 的两幅图可以更直观理解：

图 2

图 3

图 2 是当前常见的开发模型，Click Processor 服务是个常驻服务，响应来自用户的所有点击请求。生产环境中，通常会多实例部署，常驻是个关键特征，日常的运维重点在确保常驻服务的稳定性方面。
图 3 是 Event-driven 开发模型，关注重心前移，集中在 Event 的产生和响应方面，响应服务是否常驻是个可选项。

Serverless 在概念上与 PaaS (Platform as a Service)、CaaS (Container as a Service) 的区别，重点是在是否将 自动弹性伸缩 作为概念诞生之初的核心特征。
结合 Event-driven 的开发模型，Serverless 场景中自动弹性伸缩需要对开发者透明度加深，开发者开发过程对处理能力的关注重心从静态转为动态，更好应对上线后业务请求量的不确定性。

在开发方面，交付时可以采用镜像，也可以采用语言层面的打包 (如 Java 中的 war/jar) ，由平台负责运行时相关的工作。还可以更进一步，采用 FaaS 的理念，依托于平台或标准化 FaaS 解决方案，只提供业务逻辑函数，由平台负责请求入口、请求调用和自动弹性伸缩等运行时事宜。
不论哪种交付方式，在云上均可以使用 BaaS [4] 的理念，将部分逻辑通过云平台或第三方的 OpenAPI 实现，如权限管理、中间件管理等，开发过程中注意力更加聚焦在业务层面。

Serverless 服务模型

Serverless 服务模型关注云厂商对于 Serverless 计算形态的支持，不同的服务和产品形态主要差异点主要集中在对 Serverless 特征的理解和满足程度方面：

免运维 (服务器运维、容量管理、弹性伸缩等)
按资源的使用量付费

在免运维维度，最基本的是免去服务器运维成本，开发者可以按量申请资源。在容量管理、弹性伸缩、流量管理、日志/监控/告警等常规的运维层面，不同的服务和产品会根据自身定位、目标客户特征等，有侧重采用适合的方式来满足。
在计费形态方面，云厂商一方面会根据自身定位确定收费维度，如资源、请求量等，一方面也会根据当前的技术能力确定收费的粒度。

通过上述分析可知，云厂商不同 Serverless 服务模型不是静态的，会伴随产品定位、目标客户特征、技术能力等持续迭代，和客户共同成长。

Serverless 服务模型需要满足实际需求，再回到图 1，云厂商的 Serverless 服务模型可以分为如下几类：

资源实例平台
调度平台
应用管理平台
业务逻辑管理平台

综合起来，即：

阿里云 Serverless 产品

国内的云服务厂商，阿里云提供的 Serverless 服务和产品形态相对完备。这里以阿里云为例进行探讨，探讨的经验可以平滑迁移到其他云服务厂商。

从阿里云公开的资料 [5] 可以了解到几类常见的 Serverless 产品形态：

上述云产品分类可以清晰和图 1 的模型对应起来，用户在进行选择时，先整理当前业务技术所处的阶段和痛点，确定对云上方案的需求，然后再根据云厂商的产品形态做对应，选择适合当前阶段的服务和云产品。

该对应关系重点是了解云产品定位是否可以长期满足业务需求，如：

业务技术目前所处的阶段是否有对应的 Serverless 产品形态
业务快速迭代是否会受限于云产品自身的发展
云产品的稳定如何
云产品是否可以持续为业务带来技术红利

同时还需要了解云产品是否可以伴随业务发展，重点是业务对技术的需求中，哪些是云产品层面由于定位带来的限制，哪些是当前云产品的技术实现带来的限制。
若是云产品定位带来的限制，那么就需要考虑使用和业务需求定位更匹配的云产品。若是当前技术实现的限制，那么有机会和云产品共同成长，及时给云产品反馈，使得云产品可以更好满足自身的业务需求。

除此之外，业务层面还需关注云厂商自身服务类型的丰富性，云厂商自身服务越丰富，规模越大，越会产生规模效应，进而给业务带来更丰富的技术红利和成本优势。

幸运的是，云产品通常都会有丰富的文档，也有相应的用户群，可以直面产品 PD 和研发。云产品的 PD 和研发也很期望直面用户，聆听用户的反馈和需求，和用户一起共建。

下面简单介绍下阿里云 Serverless 产品和用户钉钉群。

阿里云 ECI 产品 [6] 是 Serverless 和容器化的弹性计算服务，用户无需管理底层服务器，只需要提供打包好的镜像，即可运行容器，并仅为容器实际运行消耗的资源付费。

阿里云 Serverless Kubernetes (简称 ASK) 是阿里云容器服务产品 [7] 家族中的一种形态，托管 Kubernetes Master 组件，依托阿里云 ECI 产品提供 Pod 实例，用户无需运维 Kubernetes Master 和 Agent 节点即可使用 Kubernetes 调度能力，详情可参见产品文档 [8]。

阿里云 Serverless 应用引擎 (简称 SAE) [9] 是面向应用的 Serverless PaaS 平台，帮助 PaaS 层用户免运维 IaaS，按需使用，按量计费，实现低门槛微服务应用上云，有效解决成本及效率问题。支持 Spring Cloud、Dubbo 和 HSF 等流行的开发框架，真正实现了 Serverless 架构和微服务架构的完美融合。除了微服务应用外，用户还能通过 Docker 镜像部署任何语言的应用。

阿里云函数计算有两款产品，函数计算 [10] 是一个事件驱动的全托管 Serverless 计算服务，用户无需管理服务器等基础设施，只需编写代码并上传，函数计算会为用户准备好计算资源，并以弹性、可靠的方式运行用户代码。Serverless 工作流 [11] 是一个用来协调多个分布式任务执行的全托管 Serverless 云服务，致力于简化开发和运行业务流程所需要的任务协调、状态管理以及错误处理等繁琐工作，让用户聚焦业务逻辑开发。用户可以用顺序、分支、并行等方式来编排分布式任务，服务会按照设定好的顺序可靠地协调任务执行，跟踪每个任务的状态转换，并在必要时执行用户定义的重试逻辑，以确保工作流顺利完成。

用户钉钉群：

小结

Serverless 本质上是一个问题域，将研发流程中非业务核心却影响业务迭代的问题抽象化，并提出相应的解决方案。该概念不是突然产生的，大家或多或少已经将其理念应用到日常的工作中，只是伴随着云计算浪潮，云上的 Serverless 服务和产品更系统、更具有竞争力，可以基于规模优势和丰富的产品线，面对问题域持续提供更满足业务需求的服务。

Serverless 理念不仅在中心化的云端蓬勃发展，目前也逐步在边缘端发展，使得服务的运行更加广泛化，更好满足业务自身的客户，提供更低延时、稳定的服务。

本篇文章尝试从项目、开发的日常流程出发，协助读者从日常实践角度来理解 Serverless 概念，根据所处的阶段选择适合的 Serverless 服务和产品。并尝试从云产品内部的视角，传递云产品和用户共建的观念，通过不同的分工更好传递和创造价值。

References

来源：oschina

链接：https://my.oschina.net/u/1464083/blog/4278554

标签

Kubernetes

Amp

PaaS

Martin

Serverless