Serverless ：让「前端开发者」走向「应用研发者」

最新推荐文章于 2024-05-07 06:35:44 发布

lzz丶忠不悔

最新推荐文章于 2024-05-07 06:35:44 发布

阅读量759

点赞数 7

分类专栏：程序员文章标签： serverless java 前端

本文链接：https://blog.csdn.net/rt3Dmax9/article/details/137984936

版权

程序员专栏收录该内容

175 篇文章 0 订阅

订阅专栏

让基础设施变厚，提升稳定性。

Serverless 云研发平台架构图

Serverless 方案定制能力来完善云端一体研发者市场，提供开发者更多选择、打造云端一体的研发集成闭环来提供业务更快的交付速度、以及业务低成本的使用基础 BaaS 服务能力以及业务 BaaS 成为研发平台的核心抓手。

===

Serverless 研发平台

===================

▐ Serverless 业务解决方案

我们定义的解决方案：即解决某一横向或纵向领域的，贯穿创建、研发、交付、运维阶段的一系列能力的集合。为什么当时需要定义解决方案的定制能力，核心原因是面向今天云端一体化的场景，不同事业部的业务同学有着不同的定制需求。

我们调研了几个事业部，包含 AE 、考拉、淘系等，起初的 Serverless 云研发平台的定制开发能力偏弱，无法很好的承接业务诉求，我们需要让平台有一定的开放定制能力，例如淘系面向研发面板的 low code 的定制能力，考拉面向函数的资损风险等级和应用风险等级录入等需求。

但是开放能力会涉及创建、研发、交付、运维这几个阶段，每个过程能提供什么定制能力、开放到什么程度是要由平台根据收集到的需求和平台自身管控要求去综合考虑的，所谓「人挪活，树挪死」，结构化了几个关键能力之后 Serverless 云研发平台开放解决方案的定制能力在当时多个租户的调研下产生了。

上图为结构化几个可定制节点以及多个场景的调研情况

通过上图结构化的信息，我们定义了解决方案元数据相关信息，示例为中后台一体化解决方案相关元数据信息。

{

“name”: “ICE-FaaS”,

“display_name”: “Web 端一体化”,

“description”: “传统 Web 一体化解决方案，解决中后台开发需求（ICE、React等），同时支撑中后台前端页面和 FaaS 的研发”,

“owner”: “*”,

“generator”: {

“id”: 30

“depserver”: [],

“page”: {},

“widget”: {},

“baas”: {},

“ide_plugin”: [“midway-helper”],

“checkConfig”: {

“cf”: true,

“cr”: true,

“fone”: true

“flow”: {

“id”: 1

“ops”: {

“resource”: [{

“type”: “faas”

}, {

“type”: “assets”

}]

}

‍

截止目前，Serverless 云研发平台通过共建一共沉淀了 14 个解决方案，包括 5 个通用解决方案和 9 个面向不同租户的定制化解决方案。

接下去介绍 3 个典型的解决方案。

一体化解决方案

一体化应用解决方案是基于 Midway Hooks 提供的上层业务云端一体解决方案，借助 Serverless + Hooks + “零” API 调用的特性，开发者在研发流程中仅需关注业务逻辑，即可高效完成应用的交付。

一体化应用在使用时，具有诸多的优势：

易于开发，前后端同仓库，无缝融合一体开发
易于部署，前后端一同发布与部署
易于维护，后端代码使用Serverless 部署，运维难度低

而在开发时，我们也提供了诸多的功能来帮助开发者加速研发。

“零 API 调用”

Hooks 支持

在阿里内部，我们提供了中后台一体化与搭建模块一体化两种解决方案。其中，中后台一体化应用在内部已经落地了 300+ 应用，快速且高效的支撑了各个 BU 的中后台需求。

淘系模型驱动解决方案

模型驱动是淘宝导购业务开发过程中沉淀的一种开发方式，面向导购大量的召回补全展现需求。通过配置面板，将模型、数据来源、插件配置组合，最终生成业务逻辑代码，供业务消费。

整个操作面板的核心关注点在右侧的流程画布上，我们希望使用固定的流程来解决这一类业务问题，这些逻辑遵从预定义的操作路径。在云市场轻应用外包介入开发的模式中，由内部同学生成物料，外包同学开发模块和选择业务字段并串联流程，帮助内部同学节省了大量流程串联和模块联调成本，相比传统的开发方式整体提效10%左右。这也是一种创新的协同模式，物料丰富后会有更大的提升空间。

数据源（召回） --> 模型（补全） --> 扩展逻辑（插件）

模型驱动解决方案在淘宝很好的解决了业务问题，但是面临更多的场景需要的是更加灵活的模板定制能力，因此未来模型驱动会在灵活的模板配置化上发力、对节点物料的沉淀上建立更加完善的机制、支持Web IDE等插件，并在更多的场景上支持业务的落地，让不同的业务场景可以更加便利的建立自己的“三板斧”。

考拉 Dart 一体化解决方案

考拉大前端自 2020 年 3 月份开始尝试 Flutter 的应用，部分客户端和前端同学均参与进 Flutter 的开发，对于 Dart 相对熟悉，所以 Dart 一体化解决方案最初目的主要是考虑帮客户端同学解决开发提效的问题。考拉之前主要在使 Node.js Runtime 的 Serverless 方案，相比于 Java Script，Dart 对于客户端同学也更友好一些，同时也不断有客户端同学提出 Dart Serverless 的诉求。

在函数计算 FC 研发团队的帮助下，考拉基于 Dart Runtime 的前期测试版本，快速完成了考拉 App 今日活动 Tab 的改造重构，并已于 9 月底灰度上线。10 月中下旬，基于 Dart Runtime 开始和 DEF 平台对接，最终 DEF Serverless 创建面板，会透出 Dart 纯函数解决方案，目前和 FC 侧基本流程已调通，即将上线 Dart 的纯函数解决方案。

除了已上线的 Dart Ast 生成服务，考拉将基于 Dart Serverless 方案推出更多的业务场景，如 App 端数据模型的动态下发、业务逻辑的动态配置、Flutter 动态化尝试，以及 App 跨端搭建能力等。

除了以上 3 个解决方案，ICBU 团队研发的 EaaS 微应用级别的解决方案，天猫行业团队研发的面向轻店场景的原生小程序一体化解决方案等，这里不展开一一介绍了。

▐ 函数稳定性保障

最开始的时候，我们关注的重点是如何用 Node 完成业务逻辑，比如数据怎么组织、 Java 二方包怎么调用、怎么结合阿拉丁链路、线上 bug 怎么快速修复。现在有了这么多线上运行的业务，我们关注的重点已经从怎么完成业务需求，转变成如何高效地、稳定地完成业务需求。

线上稳定性，本质上是对问题的治理。从问题出发，可以分为以下几个主要环节：预防问题、发现问题、定位问题和解决问题。

在预防问题上，要尽可能降低问题发生的概率和缩小影响面，做好上线卡口，以及做好对应的预案。发现问题上要尽可能实现全链路监控，以及实现合理有效的报警分发机制。定位问题上，要尽可能缩短问题的定位时间，在报警元信息的基础上，做一些机器的辅助分析，关联上下文，从而做到半自动定位或提供更多有逻辑的上下文，来缩短人为定位问题的时间。在解决问题上，要保证解决方案的有效，安全以及快速。

大促稳定性保障手段

大促场景下， C 端场景需要重保，以下的稳定性保障手段经历数次大促压测，同时越是大促态，整个稳定性保障也愈发紧张。

稳定性是保障了，但是在之前我们是对照上述的文档完成上线流程的，流程冗长无比，最终并沉淀成一个作战手册，同时这些内容无法和应用关联，离散在文档角落，整个过程「又臭又长」。

上线流程 -> 作战手册一体化

因此，Serverless 研发平台上希望规范化整个流程，从从强弱依赖梳理 -> 预案配置 -> 监控报警订阅 -> 单链路压测 -> 作战手册生成，记录所有函数上线过程，流程可追溯，文档可沉淀；另外预案、压测、监控等流程做到半自动化，减少上线时间。我们将每个流程节点定义成一个 SOP 单元，这样根据业务特性可以进行 SOP 流程的随意组装。

发布SOP流程

通过半自动化流程生产的作战手册，函数和作战手册关联的硬盘化记录方式，并结合自动限流和下游依赖分析以及预案生产，例如：通过预发流量录制的回放，自动分析出函数下游的强弱依赖，并录入强依赖负责人，方便出现线上问题的时候可以第一时间找到负责人排查问题；根据不同租户对单元化的需求，平台可以帮助用户进行多机房、多单元部署实现异地多活。这些都能够让业务的大促态变得更轻松一些。

淘系业务作战手册

专家应急响应

为解决线上问题定位慢的痛点，平台还提供了应急响应系统，当函数成功率降低触发报警时，平台会自动拉取函数以及下游多项数据信息，进行错误分析，快速产出错误报告推送给函数开发者。并引导开发者回到研发平台进行切流、执行预案等止血操作。例如，下游服务强依赖服务A成功率下降，导致函数自身成功率下降，需要联系服务A负责同学。