华为Serverless核心技术与实践摘录
1. Serverless综述
微服务面临的挑战
- 微服务的粒度仍然比较大
- 微服务开发仍有较高门槛
- 微服务基础设施管理、高可用和弹性仍然很难保证
- 基础设施的成本仍然较高
Serverless的定义
维基百科将Serverless定义为一种云计算执行模型。
-
云服务按需分配计算资源,开发者无需运维这些资源,不用关心容器、虚拟机或物理服务器的容量规划、配置、管理、维护、操作和扩展。
-
Serverless计算无状态,可在短时间内完成计算,其结果保存在外部存储中。
-
当不使用某个应用时,不向其分配计算资源。
-
计费基于应用消耗的实际资源度量。
CFCN认为Serverless旨在构建和运行不需要服务器管理的应用程序,二者的不同之处在于它描述了一个更细粒度的部署模型,能够以一个或多个函数的形式将应用打包上传到平台执行,并且按需执行、自动扩展和计费。
Serverless服务主要分为FaaS和BaaS
-
函数即服务(Function as a Service,FaaS):开发者实现的服务器端应用逻辑(微服务甚至粒度更小的服务)以事件驱动的方式运行在无状态的临时容器中,这些容器和计算资源完全由云提供商管理。
-
后端即服务(Backend as a Service,BaaS):基于API的三方服务,用来取代应用程序中功能的核心子集。
Serverless关键技术
-
事件源(Event Sources):事件的生产者,可能是HTTP请求、消息队列的事件等,通过同步或异步的方式去出发函数。
-
触发器(Trigger):函数的REST呈现,通常是RESTful URL。
-
FaaS控制器(FaaS Controller):FaaS平台的核心组件,管理函数的生命周期、扩容和缩容等。
-
函数实例(Function Instance):执行函数的环境,包含函数代码、函数运行环境(如JRE、Node.js)、上下文信息(如函数运行的配置,通常以环境变量注入)。
-
函数编程模型(Programming Model):通常表现为函数的编程规范,如签名、入口的方法名等。
-
BaaS平台:函数通常是无状态的,其状态一般存在在BaaS服务中,如NoSQL数据库等。
Serverless和微服务的差异
从设计、开发、上线到持续服务,Serverless相比微服务在开发难度及工作量上大幅降低,最终体现为更少的业务上线时间和更稳定的运行质量。
Serverless生态现状
-
平台
-
框架
-
事件总线
-
函数工作流
-
工具
AWS Lamda
当时的AWS Lamda应用场景是图片上传、应用内事件、网站单击或连接设备的输出事件等,其目标是在这些事件发生后的1毫秒内开始自动启动代码运行并处理事件。
2. 新一代Serverless技术
华为元戎核心技术创新点
-
在编程模型方面,华为元戎实现了内置状态的处理,实现了有状态函数编程;
-
在性能方面,华为元戎的运行时系统实现了冷启动、弹性伸缩、调度等诸多创新技术;
-
在服务框架方面,华为元戎实现了Event Bridge和Service Bridge系统以对接各种云服务。
3. 有状态函数编程模型
4. 高性能函数运行时
5. 高效对接BaaS服务
6. 云数据库服务
7. 云存储服务
8. 云托管服务
9. 翻译服务的Serverless架构设计
9.1 Serverless平台和翻译服务
翻译服务包含三类角色:开发者、翻译服务商和平台管理员
开发者涉及的主要业务流程如下:
-
开发者询价流程
-
开发者下单流程
-
开发者订单管理流程
-
开发者翻译任务管理流程
-
开发者下载翻译稿件流程
翻译服务商涉及的主要流程如下:
-
服务商接单
-
服务商订单管理
-
服务商交付翻译稿件
平台管理员涉及的主要流程如下:
-
质量管理流程
9.2 翻译服务架构技术选型
在进行架构技术选型时,可以参考团队过去或周边一些业务的经验,但是影响架构选型的因素非常多,包括业务特点、技术特点、团队特点等,业务团队需要针对自身的这些特点选择最适合的自己的架构技术。
业务特点
团队特点
技术需求
成本需求
-
资源成本
-
研发成本
-
运维成本
9.2.5 架构选型
微服务架构
将业务系统按领域建模后拆分成多个微服务,每个微服务有自己的独立数据库,由微服务后台将翻译素材和回稿存储到OBS服务,面向开发者和翻译服务商的Portal通过API网关调用后端开放的微服务接口,不同领域的微服务之间采用API或DMQ消息的方式进行交互。
Serverless架构
将业务系统按领域模型和业务功能拆成多个函数,每个函数负责单一的功能,函数可以直接调用云数据库、云存储等服务来进行数据存储,也可以由前端集成对应的SDK后直接出发调用后端的服务,基于函数的各种触发器也使系统转变为基于事件的数据处理流程,例如,翻译完成并上传译稿后触发函数给开发者发送消息。API网关作为Serverless服务的重要一环,承接的是RESTful风格的HTTP请求并拉起对应函数执行的逻辑。另外,由于架构本身是前后端解耦的,前端只涉及相关的静态资源,可以直接将其托管到云托管服务中。
相比微服务架构,基于Serverless的架构有如下改进。
-
函数可以采用Node.js语言开发
-
Serverless架构实现了对开发者的免运维
-
Serverless服务按需使用
-
Serverless架构本身支持弹性伸缩
技术选型结果
选择Serverless架构来构建翻译服务。
-
Serverless 服务免运维,云函数的部署和升级灵活方法方便,对开发人员的技能要求低,可以充分满足业务快速发布和上线的需求。
-
屏蔽了前端和后端的架构差异,前端和后端可以由同一个人采用自己熟悉的语言进行端到端开发,团队已有的前端人员可以快速上手开发后端服务,使项目能够立即启动。
-
利用Serverless架构的弹性伸缩特性,翻译团队可以轻松应对流量波动和业务增长,不需要寻找高水平的架构师,也不需要在业务上线之后因为性能不足而不断重构优化架构性能。
-
函数按需运行、服务按使用量计费,对于像翻译服务这种不需要实时在线运行的业务,可以极大降低资源使用成本。
采用Serverless技术来构建翻译服务,可以兼顾业务变化快、团队开发和运维经验不足等诉求,同时兼顾技术架构的先进性和可演进性。
9.3 翻译服务Serverless架构
9.3.1 功能架构
一个完整的功能架构通常包括:架构上下文、架构的功能视图和模块划分。
-
零层架构主要描述服务的系统上下文,以及翻译服务与周边系统的交互关系
-
一层架构主要描述翻译服务的功能划分
9.3.2 函数划分策略
9.3.3 技术架构
9.3.4 关键架构质量属性设计
-
性能设计准则
-
可靠性设计准则
-
安全性设计准则
10. 翻译服务实战开发
10.1 基于Serverless技术的翻译服务开发
10.1.1 翻译服务网站托管
10.1.2 基于云函数开发后台逻辑
10.1.3 翻译稿件存储
10.1.4 使用云数据库管理数据
10.1.5 翻译服务上线效果
10.2 传统开发模式与Serverless模式对比
10.2.1 研发角色和职责变化
10.2.2 不同开发模式对比
10.2.3 研发效率对比
10.3 Serverless技术演进
10.3.1 传统中间件的Serverless化
10.3.2 Serverless模型化
10.3.3 与遗留系统的对接
10.3.4 关键技术瓶颈的突破
10.3.5 Serverless低代码平台
Serverless无服务器技术小结
-
Serverless主要优点
-
免运维:完全自动、一键部署、高度可扩展
-
按需运行:请求到来时启动函数实例,一段时间没有请求后销毁函数实例
-
按量计费:按照使用资源量计费
-
-
主要使用场景
-
轻量级的应用
-
事件驱动的异步应用
-
弹性伸缩要求高的应用
-
-
主要缺点
-
以函数/应用为粒度,没有完善的治理系统,构建大型应用服务比较困难
-
测试、调试与问题定位工具较传统应用并不完善
-
太过黑盒,需完善可观测性
-
-
FaaS与PaaS比较
-
粒度不同:FaaS粒度更细
-
启动时间:FaaS启动时间非常快
-
扩容管理:FaaS自动进行扩容,较PaaS更简单
-
-
FaaS与容器比较
-
无服务器架构 FaaS和容器在管理和扩容方面的差异非常小
-
对于事件驱动的异步应用,并且每个应用组件只有很少的几种事件类型,这种应用看上去更适合用FaaS。
-
而对于有很多触发点的同步请求驱动的组件,则使用使用容器。
-
参考
-
华为Serverless核心技术与实践