近两年来,Serverless 概念在开发者中交流的越来越多,主题分享呈现爆发趋势,如在云原生领域颇具影响力 KubeCon&CloudNativeCon 会议中,关于 Serverless 的主题,2018 年有 20 个,到 2019 年增长至 35 个。 在 Serverless 产品层面,从最早的 AWS Lambda,到 Azure Functions、Goolge Functions、Google CloudRun,再到国内阿里云 Serverless Kubernetes、Serverless 应用引擎、函数计算等,面向计算的 Serverless 云上基础设施越来越丰富。 新概念、新产品的产生不是凭空出现,它们诞生之初要解决的是当前问题。随着实践者对问题域的理解越来越清晰和深刻,问题的处理方法也会逐步迭代,更接近问题本质的解决方案也会出现。若不从问题域出发来理解解决方案,容易陷入两个极端,即「它能解决一切问题」和「它太超前了,理解不了」。 从日常迭代看 Serverless图 1 上图是一个常用的项目迭代模型,其目标是满足客户需求。在这个模型中,项目组通过 被动迭代 满足客户提出的需求,同时逐步深刻理解客户需求的本质,通过 主动迭代 和客户一起采用更好的方案或从根源解决面对的问题。每次的需求反馈会加深对客户需求的理解,提供更满足需求的服务。每次的 bug 反馈会加深对处理方案的理解,提供更稳定的服务。 在模型启动后,日常的核心问题就集中在了 如何加速迭代。 如果想要解决迭代加速的问题,就需要了解有哪些制约因素,有的放矢。下述是从开发视角看到的开发模型: 图 2 虽然在实际应用中会采用不同的开发语言和架构,但在每个阶段均有通用的问题,如: 图3 除了要解决上述通用问题,还需要提供标准化的方案,降低开发者的学习和使用成本,缩短从想法到上线的时间。 若将上述过程中不同阶段花费的时间做个分析,在项目整个生命周期中会发现:
为了加速迭代,需要依次解决占用时间和精力多的部分,如图 4 所示: 图 4 从左至右,通过下放不同层次的运维工作,降低「部署&运维」成本。在降低了运维工作成本后,在「通用逻辑」层面降低成本。二者结合起来,在迭代过程中更深入聚焦业务。该过程也是从 Cloud Hosting 到 Cloud Native 的过程,充分享受云原生带来的技术红利。 由于软件设计架构和部署架构与当时环境耦合度高,面对新的理念和服务、产品,存量应用迭代过程中采用的技术需要有相应调整,即开发和部署方式需要有一定的改造。对于新应用进行开发和部署时,应用新的理念有一定的学习和实践成本。 故上述过程不能一蹴而就,需要根据业务当前的痛点优先级来选择匹配的服务和产品,并根据未来的规划提前进行技术预研,在不同的阶段选择适合的服务和产品。 Serverless 简介维基百科对于 Serverless 有较为完备的定义:
在这种计算模型下,会给用户带来如下收益:
概念本质上是对问题域的抽象,是对问题域特征的总结。通过特征来理解概念,可以避免注意力集中在文字描述而非概念的价值本身。 站在用户角度,我们可以抽象出 Serverless 的如下特征:
在一定规模的公司中,若严格区分开发和运维的角色,这种计算形态其实是已经存在的,并非全新的事物。但目前的技术趋势,是期望借助云的规模和技术红利优势,通过上云来降低业务在技术侧的成本,并通过技术红利反哺业务。故业界对于 Serverless 的讨论,注意力是集中在云上的服务和产品所体现的 Serverless 能力。 Serverless 开发模型Martin Fowler 的这篇文章站在架构的角度,对 Serverless 开发模型做了充分的阐述,这里做个简单的总结,核心围绕三点:
Serverless 开发采用 Event-driven 模型,围绕 HTTP/HTTPS 请求、时间、消息等 Event 的生产和响应进行架构设计。在这样的模型中,Event 的生产、处理流程是核心,通过 Event 驱动整个服务流程,注意力集中在整个处理流程。对业务理解越深刻,Event 类型和业务会越匹配,技术和业务的相互促进作用会越有效。 Event-driven 模型,使得 服务常驻 这种理念从必选项转变为可选项,可以更好应对业务请求量的变化,如自动弹性伸缩。同时服务非常驻,可以降低所需的资源成本和维护成本,加速项目迭代。 通过文章的两幅图可以更直观理解: 图 5 图 5 是当前常见的开发模型,Click Processor 服务是个常驻服务,响应来自用户的所有点击请求。生产环境中,通常会多实例部署,常驻 是个关键特征,日常的运维重点在确保常驻服务的稳定性方面。 图 6 图 6 是 Event-driven 开发模型,关注重心前移,集中在 Event 的产生和响应方面,响应服务是否常驻是个可选项。 Serverless 在概念上与 PaaS (Platform as a Service)、CaaS (Container as a Service) 的区别,重点是在是否将 自动弹性伸缩 作为概念诞生之初的核心特征。 结合 Event-driven 的开发模型,Serverless 场景中自动弹性伸缩需要对开发者透明度加深,开发者开发过程对处理能力的关注重心从静态转为动态,更好应对上线后业务请求量的不确定性。 在开发方面,交付时可以采用镜像,也可以采用语言层面的打包 (如 Java 中的 war/jar) ,由平台负责运行时相关的工作。还可以更进一步,采用 FaaS 的理念,依托于平台或标准化 FaaS 解决方案,只提供业务逻辑函数,由平台负责请求入口、请求调用和自动弹性伸缩等运行时事宜。 不论哪种交付方式,在云上均可以使用 BaaS 的理念,将部分逻辑通过云平台或第三方的 OpenAPI 实现,如权限管理、中间件管理等,开发过程中注意力更加聚焦在业务层面。 Serverless 服务模型Serverless 服务模型关注云厂商对于 Serverless 计算形态的支持,不同的服务和产品形态主要差异点主要集中在对 Serverless 特征的理解和满足程度方面:
在免运维维度,最基本的是免去服务器运维成本,开发者可以按量申请资源。在容量管理、弹性伸缩、流量管理、日志/监控/告警等常规的运维层面,不同的服务和产品会根据自身定位、目标客户特征等,有侧重采用适合的方式来满足。 在计费形态方面,云厂商一方面会根据自身定位确定收费维度,如资源、请求量等,一方面也会根据当前的技术能力确定收费的粒度。 通过上述分析可知,云厂商不同 Serverless 服务模型不是静态的,会伴随产品定位、目标客户特征、技术能力等持续迭代,和客户共同成长。 Serverless 服务模型需要满足实际需求,再回到图 4,云厂商的 Serverless 服务模型可以分为如下几类:
综合起来,即: 图7 业界 Serverless 产品目前国内外云厂商均提供有不同维度的 Serverless 产品,如下做个简单的总结: 图 8 资源实例平台国外 AWS Fargate / Azure ACI、国内阿里云 ECI / 华为 CCI 影响力较大,对用户提供容器组服务。容器组作为一个整体,提供类似 Kubernetes 中 Pod 的概念。用户可以通过 OpenAPI 调用直接创建容器组,不用在部署服务前进行服务器的购买、配置等工作,下放资源相关的容量管理运维工作。用户可以将资源实例平台作为容量足够大的资源池使用,在容器组级别进行细粒度的资源申请,配合动态扩缩容进行应用级别的容量管理。 一般在生产环境中,用户通常不会直接使用此类资源管理服务,而是借助应用编排服务,将这类服务透明化,关注重点放在应用编排维度。 调度平台Kubernetes 是容器调度的事实标准,国外 AWS EKS、国内阿里云 Serverless Kubernetes 等一方面托管 Kubernetes Master 组件,一方面借助资源管理服务,如 VirtualKubelet + AWS Fargate 或 VirtualKubelet + 阿里云 ECI,提供 Kubernetes Node 层服务。 对于期望直接使用 Kubernetes 能力,同时希望低成本运维 Kubernetes、不保有资源池的用户,此类产品比较契合需求。 应用管理平台国外 Google GAE / CloudRun、国内阿里云 Serverless 应用引擎等进一步将运维工作服务化,如发布管理 (打包/灰度/分批/回滚/版本控制等)、日志/监控/告警、流量管理、弹性伸缩等,用户可以进一步专注在业务需求,低成本运维。 对于期望零成本改造存量应用、低学习成本使用,又期望最大限度减少运维工作的用户,此类平台与需求匹配度较高。但由于应用管理层面的运维工作在业界暂无标准化方案,不同的项目会存在个性化需求,故采用此类产品过程中需要加强沟通,不断向平台反馈,通过共建的方式磨合 Serverless 平台和自身业务。 业务逻辑管理平台国外 AWS Lambda / Azure Functions / Google Functions、国内阿里云函数计算 / 腾讯云云函数 / 华为函数工作流等在应用管理的基础上,进一步将开发过程中的通用逻辑透明化,用户仅用关心业务逻辑的实现。这个过程可以类比开发过程中的单元测试编写过程,输入、输出是通用的,仅在处理逻辑存在差异。这类 Serverless 产品也是业界讨论最多的形态,代表业界对于理想的开发流程的抽象,可以进一步加快迭代流程,缩短想法到上线的时间。这类 Serverless 产品与云平台其他类型的产品集成更紧密,以 BaaS 形态使用云平台的服务实现通用逻辑,如存储、缓存等,对云平台产品丰富度有一定隐性需求。 处理过程对外部依赖较少或偏计算类的场景,如前端、多媒体处理处理等,采用此类 Serverless 产品学习和使用成本相对低,易于上手。随着服务、组件的抽象程度越来越高,会有越来越多的业务场景适用,用户的运维工作会更为透明化,同时开发过程中可以直接享受到业界的最佳实践,服务的稳定性、性能、吞吐等方面借助平台的能力做到最大化。 选型综上,用户在进行 Serverless 产品选型时,需要先整理当前业务技术所处的阶段和痛点,确定对云上方案的需求,然后再根据云厂商的产品形态做对应,选择适合当前阶段的服务和云产品。 该对应关系重点是了解云产品定位是否可以长期满足业务需求,如:
同时还需要了解云产品是否可以伴随业务发展,重点是业务对技术的需求中,哪些是云产品层面由于定位带来的限制,哪些是当前云产品的技术实现带来的限制。 若是云产品定位带来的限制,那么就需要考虑使用和业务需求定位更匹配的云产品。若是当前技术实现的限制,那么有机会和云产品共同成长,及时给云产品反馈,使得云产品可以更好满足自身的业务需求。 除此之外,业务层面还需关注云厂商自身服务类型的丰富性,云厂商自身服务越丰富,规模越大,越会产生规模效应,进而给业务带来更丰富的技术红利和成本优势。 幸运的是,云产品通常都会有丰富的文档,也有相应的用户群,可以直面产品经理和研发,及时反馈需求,以共建的理念协同发展。 小结Serverless 本质上是一个问题域,将研发流程中非业务核心却影响业务迭代的问题抽象化,并提出相应的解决方案。该概念不是突然产生的,大家或多或少已经将其理念应用到日常的工作中 ,只是伴随着云计算浪潮,云上的 Serverless 服务和产品更系统、更具有竞争力,可以基于规模优势和丰富的产品线,面对问题域持续提供更满足业务需求的服务。 Serverless 理念不仅在中心化的云端蓬勃发展,目前也逐步在边缘端发展,使得服务的运行更加广泛化,更好满足业务自身的客户,提供更低延时、稳定的服务。 本篇文章尝试从项目、开发的日常流程出发,协助读者从日常实践角度来理解 Serverless 概念,根据所处的阶段选择适合的 Serverless 服务和产品。同时作者本人在阿里云 Serverless 应用引擎中负责底层研发工作,尝试从云产品内部的视角,传递云产品和用户共建的观念,通过协同更好传递和创造价值。 References
|
|
来自: 宋志刚k5lpi995 > 《技术文章》