Serverless 服务选型
_本文原始标题：Serverless服务选型
综述
近两年来 ， Serverless概念在开发者中交流的越来越多 ， 实践、服务、产品层出不穷 。
Serverless的主题分享呈现爆发趋势 ， 如在云原生领域颇具影响力的KubeCon&CloudNativeCon会议中 ， 关于Serverless的主题 ， 2018年有20个 ， 到2019年增长至35个 。
产品层面 ， 从最早的AWSLambda ， 到AzureFunctions、GoolgeFunctions、GoogleCloudRun ， 再到国内阿里云ServerlessKubernetes、Serverless应用引擎、函数计算等 ， 面向计算的Serverless云上基础设施越来越丰富 。
新概念、新产品的产生不是凭空出现 ， 它们诞生之初要解决的是当前问题 。 随着实践者对问题域的理解越来越清晰和深刻 ， 会逐步迭代问题的处理方法 ， 提供更接近问题本质的解决方案 。
若不从问题域出发来理解解决方案 ， 容易陷入两个极端 ， 即「它能解决一切问题」「它太超前了 ， 理解不了」 。
本篇文章尝试以日常开发流程为起点 ， 分析每个阶段面对的问题 ， 然后组合解决方案 ， 提炼面向Serverless的开发模型 ， 并与业界提出的Serverless产品形态做对应 ， 为开发者采用Serverless架构和服务提供参考 。
迭代模型
从项目整体视角来看：
文章图片
这个模型的目标是满足客户需求 。 通过被动迭代满足客户提出的需求 ， 同时逐步深刻理解客户需求的本质 ， 通过主动迭代和客户一起采用更好的方案或从根源解决面对的问题 。
每次的需求反馈会加深对客户需求的理解 ， 提供更满足需求的服务 。 每次的bug反馈会加深对处理方案的理解 ， 提供更稳定的服务 。
在模型启动后 ， 日常的核心问题就集中在了如何加速迭代 。
为了解决迭代加速的问题 ， 需要了解有哪些制约因素 ， 有的放矢 。 下述是从开发视角看到的开发模型：
文章图片
虽然会有不同的开发语言和架构 ， 但在每个阶段均有通用的问题 ， 如：
文章图片
除了要解决上述通用问题 ， 还需要提供标准化的方案 ， 降低开发者的学习和使用成本 ， 缩短从想法到上线的时间 。
若将上述过程中不同阶段花费的时间做个分析 ， 在项目整个生命周期中会发现：
部署&运维占用的时间和精力 ， 会远大于开发&测试通用逻辑占用的时间和精力 ， 会接近甚至超过业务逻辑为了加速迭代 ， 需要依次解决占用时间和精力多的部分 ， 如图1：
文章图片
从左至右 ， 通过下放不同层次的运维工作 ， 降低「部署&运维」成本 。 在降低了运维工作成本后 ， 在「通用逻辑」层面降低成本 。 二者结合起来 ， 在迭代过程中更深入聚焦业务 。
该过程也是从CloudHosting到CloudNative的过程 ， 充分享受云原生带来的技术红利 。
由于软件设计架构和部署架构与当时环境耦合度高 ， 面对新的理念和服务、产品 ， 存量应用迭代过程中采用的技术需要有相应调整 ， 即开发和部署方式需要有一定的改造 。 新应用的开发和部署应用新的理念时 ， 有一定的学习和实践成本 。
故上述过程不能一蹴而就 ， 需要根据业务当前的痛点优先级来选择匹配的服务和产品 ， 并根据未来的规划提前进行技术预研 ， 在不同的阶段选择适合的服务和产品 。
Serverless简介
维基百科对于Serverless有较为完备的定义[1]:
Serverlesscomputingisacloudcomputingexecutionmodelinwhichthecloudproviderrunstheserver,anddynamicallymanagestheallocationofmachineresources.Pricingisbasedontheactualamountofresourcesconsumedbyanapplication,ratherthanonpre-purchasedunitsofcapacity.Itcanbeaformofutilitycomputing.在这种计算模型下 ， 给用户会带来如下收益：
Serverlesscomputingcansimplifytheprocessofdeployingcodeintoproduction.Scaling,capacityplanningandmaintenanceoperationsmaybehiddenfromthedeveloperoroperator.Serverlesscodecanbeusedinconjunctionwithcodedeployedintraditionalstyles,suchasmicroservices.Alternatively,applicationscanbewrittentobepurelyserverlessandusenoprovisionedserversatall.概念本质上是对问题域的抽象 ， 是对问题域特征的总结 。 通过特征来理解概念 ， 可以避免注意力集中在文字描述而非概念的价值本身 。
站在用户角度 ， 我们可以抽象出Serverless的如下特征：
免运维(服务器运维、容量管理、弹性伸缩等)按资源的使用量付费在一定规模的公司中 ， 若严格区分开发和运维的角色 ， 这种计算形态其实是已经存在的 ， 并非全新的事物 。 但目前的技术趋势 ， 是期望借助云的规模和技术红利优势 ， 通过上云来降低业务在技术侧的成本 ， 并通过技术红利反哺业务 。 故业界对于Serverless的讨论 ， 注意力是集中在云上的服务和产品所体现的Serverless能力 。
Serverless开发模型
MartinFowler的这篇文章[2]站在架构的角度 ， 对Serverless开发模型做了充分的阐述 ， 这里做个简单的总结 ， 核心围绕三点：
Event-driven开发模型自动弹性伸缩OpenAPIServerless开发采用Event-driven模型[3] ， 围绕HTTP/HTTPS请求、时间、消息等Event的生产和响应进行架构设计 。 在这样的模型中 ， Event的生产、处理流程是核心 ， 通过Event驱动整个服务流程 ， 注意力集中在整个处理流程 。 对业务理解越深刻 ， Event类型和业务会越匹配 ， 技术和业务的相互促进作用会越有效 。
Event-driven模型 ， 使得服务常驻这种理念从必选项转变为可选项 ， 可以更好应对业务请求量的变化 ， 如自动弹性伸缩 。 同时服务非常驻 ， 可以降低所需的资源成本和维护成本 ， 加速项目迭代 。
通过文章[2]的两幅图可以更直观理解：
图2
上述云产品分类可以清晰和图1的模型对应起来 ， 用户在进行选择时 ， 先整理当前业务技术所处的阶段和痛点 ， 确定对云上方案的需求 ， 然后再根据云厂商的产品形态做对应 ， 选择适合当前阶段的服务和云产品 。
该对应关系重点是了解云产品定位是否可以长期满足业务需求 ， 如：
业务技术目前所处的阶段是否有对应的Serverless产品形态业务快速迭代是否会受限于云产品自身的发展云产品的稳定如何云产品是否可以持续为业务带来技术红利同时还需要了解云产品是否可以伴随业务发展 ， 重点是业务对技术的需求中 ， 哪些是云产品层面由于定位带来的限制 ， 哪些是当前云产品的技术实现带来的限制 。
若是云产品定位带来的限制 ， 那么就需要考虑使用和业务需求定位更匹配的云产品 。 若是当前技术实现的限制 ， 那么有机会和云产品共同成长 ， 及时给云产品反馈 ， 使得云产品可以更好满足自身的业务需求 。
除此之外 ， 业务层面还需关注云厂商自身服务类型的丰富性 ， 云厂商自身服务越丰富 ， 规模越大 ， 越会产生规模效应 ， 进而给业务带来更丰富的技术红利和成本优势 。
幸运的是 ， 云产品通常都会有丰富的文档 ， 也有相应的用户群 ， 可以直面产品PD和研发 。 云产品的PD和研发也很期望直面用户 ， 聆听用户的反馈和需求 ， 和用户一起共建 。
下面简单介绍下阿里云Serverless产品和用户钉钉群 。
阿里云ECI产品[6]是Serverless和容器化的弹性计算服务 ， 用户无需管理底层服务器 ， 只需要提供打包好的镜像 ， 即可运行容器 ， 并仅为容器实际运行消耗的资源付费 。
阿里云ServerlessKubernetes(简称ASK)是阿里云容器服务产品[7]家族中的一种形态 ， 托管KubernetesMaster组件 ， 依托阿里云ECI产品提供Pod实例 ， 用户无需运维KubernetesMaster和Agent节点即可使用Kubernetes调度能力 ， 详情可参见产品文档[8] 。
阿里云Serverless应用引擎(简称SAE)[9]是面向应用的ServerlessPaaS平台 ， 帮助PaaS层用户免运维IaaS ， 按需使用 ， 按量计费 ， 实现低门槛微服务应用上云 ， 有效解决成本及效率问题 。 支持SpringCloud、Dubbo和HSF等流行的开发框架 ， 真正实现了Serverless架构和微服务架构的完美融合 。 除了微服务应用外 ， 用户还能通过Docker镜像部署任何语言的应用 。
阿里云函数计算有两款产品 ， 函数计算[10]是一个事件驱动的全托管Serverless计算服务 ， 用户无需管理服务器等基础设施 ， 只需编写代码并上传 ， 函数计算会为用户准备好计算资源 ， 并以弹性、可靠的方式运行用户代码 。 Serverless工作流[11]是一个用来协调多个分布式任务执行的全托管Serverless云服务 ， 致力于简化开发和运行业务流程所需要的任务协调、状态管理以及错误处理等繁琐工作 ， 让用户聚焦业务逻辑开发 。 用户可以用顺序、分支、并行等方式来编排分布式任务 ， 服务会按照设定好的顺序可靠地协调任务执行 ， 跟踪每个任务的状态转换 ， 并在必要时执行用户定义的重试逻辑 ， 以确保工作流顺利完成 。
用户钉钉群：
文章图片
小结
Serverless本质上是一个问题域 ， 将研发流程中非业务核心却影响业务迭代的问题抽象化 ， 并提出相应的解决方案 。 该概念不是突然产生的 ， 大家或多或少已经将其理念应用到日常的工作中 ， 只是伴随着云计算浪潮 ， 云上的Serverless服务和产品更系统、更具有竞争力 ， 可以基于规模优势和丰富的产品线 ， 面对问题域持续提供更满足业务需求的服务 。
Serverless理念不仅在中心化的云端蓬勃发展 ， 目前也逐步在边缘端发展 ， 使得服务的运行更加广泛化 ， 更好满足业务自身的客户 ， 提供更低延时、稳定的服务 。
本篇文章尝试从项目、开发的日常流程出发 ， 协助读者从日常实践角度来理解Serverless概念 ， 根据所处的阶段选择适合的Serverless服务和产品 。 并尝试从云产品内部的视角 ， 传递云产品和用户共建的观念 ， 通过不同的分工更好传递和创造价值 。
【Serverless 服务选型】References
[1]wikipedia:Serverlesscomputing[2]MartinFowler:ServerlessArchitectures[3]wikipedia:Event-drivenarchitecture[4]wikipedia:Mobilebackendasaservice[5]从DevOps到NoOps ， Serverless技术的落地方式探讨[6]阿里云ECI产品主页[7]阿里云容器服务[8]阿里云ServerlessKubernetes产品文档[9]阿里云Serverless应用引擎[10]阿里云函数计算[11]阿里云Serverless工作流CloudProgrammingSimplified:ABerkeleyViewonServerlessComputing
推荐阅读
- 稳就业保民生：为高校毕业生提供不断线就业服务
- 安徽省2020年4月份“月评十佳”学雷锋志愿服务典型评选揭晓，池州一社区入选
- 一张警民联系卡 打通服务通道“零距离”
- 互联网+政务服务更便捷！柯桥入选国家电子证照应用试点
- 全国人大代表蔡丽新：服务企业也可以网格化
- 社区养老北京将建1200家社区养老服务驿站
- 吉林省首家社区营养厨房示范基地建成，落户长春市桂林社区卫生服务中心
- 周末去哪里 一起做公益 长安区积极开展志愿服务活动
- 保时捷推出全新客户服务项目，让客户全程监控爱车生产过程
- 海沧一支平均年龄60岁的志愿服务队 一年多来风雨无阻接盲人兄弟下班