serverless 框架_阿里巴巴 ICBU 跨境供应链前端架构演进与 Serverless 实践

最新推荐文章于 2024-07-11 15:47:53 发布

weixin_39611769

最新推荐文章于 2024-07-11 15:47:53 发布

阅读量356

点赞数

文章标签： serverless 框架

作者：樵枫阿里巴巴国际技术，ICBU 正在招聘前端/后端/产品/UED，Base 深圳、杭州。欢迎扫个人WX咨询。

本文在 GMTC 分享内容的基础上，介绍一下 ICBU 跨境供应链的 Web 架构演进过程和 Serverless 实践。分享比较简单，总的来说就是一个段子 + 一个故事。任何看上去高大上技术，回归到业务，一定是解决具体问题的，否则就是耍流氓，Serverless 也是。
分享有几个部分：

一、Serverless 技术浪潮
Serverless 这几年很火，下面这张是谷歌热词趋势图，正如毕玄所言，Serverless 是不亚于后端 SOA 微服务这样量级的技术变革。但是火的背后有一个比较有意思的现象，如下图，如许晓斌所言，Serverless 就像一堆十几岁的小男孩在谈性爱，所有人都在讲这个事情，但是并没有人真正知道怎么去做这个事情，于是所有人都认为其他人都在做这个事情，结果所有人都声称自己也在做这个事情。过去的很长一段时间，确实就是这样的一种状态。

所以，Serverless 到底是啥、价值在哪里呢。在 CNCF 的定义里面，Serverless = FaaS + BaaS。这里我加一个前缀，Serverless = 广义 FaaS + BaaS，Serverless 的落地形态是可以有很多的，在我的实践中，除了标准 FaaS 外，更多的是在 FaaS 的基础设施上跑 Egg 微应用，也就是 EaaS。Serverless的优势体现在几个方面，1、更高效：免去了很多流程消耗、更高效的工程链路；2、更实惠：按请求量和请求时长付费；3、免运维：平台提供稳定高性能的服务，动态扩缩容，免去运维细节。在我的业务领域，可以用一句话来概括：聚焦业务逻辑，减少工程链路消耗和运维成本，用最小的成本透出业务领域能力，赋能业务增值。怎么理解呢，接下来看一下 ICBU 跨境供应链的 Web 架构演进过程来进一步解释。

二、ICBU 跨境供应链的 Web 架构演进2.1、业务简介http://Alibaba.com 大家应该比较清楚，阿里最古老的一块业务，正在从原来解决 B2B 跨境贸易的信息不对称问题，升级提供交易和跨境履约服务，下图的跨境供应链协同平台作为 ICBU下半身，为 B2B 跨境贸易中小企业提供跨境履约过程中的通关、外汇、退税、物流、金融等系列外贸领域的专业服务，沉淀真实外贸交易数据反哺 http://Alibaba.com。此外，目前跨境供应链正在引入大量外贸行业玩家比如货代、报关行等，来打通外贸履约链路的任督二脉，打造高效的履约服务，赋能外贸行业数字化升级，也就是我们所说的‘外贸大协同’愿景。

简单来说，这个业务可以用下面的几个关键词来概述。从前端视角看，我们要面对的是大量的中后台系统。在这种业务形态下，很多传统前端的玩法施展不开。所以我们一直在琢磨，中后台业务下，前端赋能业务这个命题怎么破，这里尝试从架构视角做部分阐述。

2.2、青铜时代
下面这张是最早的架构简图。

这是非常典型的以 Webx 为 Web 层的架构，其痛点主要表现在：1、前后端在 Webx 的耦合带来的协作、效率和质量问题；2、陈旧的技术栈严重限制的团队发展和开发幸福感，前端能掌控的东西太少了，赋能业务的抓手太弱。一句话来描述当时的状态就是：吾日三省吾身：表单做好了吗？列表做好了吗？详情做好了吗？每天都在做表单，每天都在做列表，但是很少去思考这些表单列表背后的领域模型、业务价值。很多时候，有些不错的业务上的想法，推动起来却很费劲。

2.3、白银时代
在这样的困局下，引入了 Egg 作为中间层，就是 BFF 架构。这次的架构升级在集团范围内不算早，但是赶得巧，当时 Egg 生态已经比较成熟（感谢 Egg 和集团 Node 生态的前辈们多年的积累）。当然，挑战还是很大的，一方面是整个团队没有 Node 经验，虽然底层框架比较成熟，但是要搞定业务层的事情还是费了好大劲，另一方面要搞定人的事情，毕竟是涉及到前后端协作模式的变化（感谢后端老铁们的大力配合）。

BFF 架构升级给团队带来了很多变化，除了说有更高效的协同效能、更好的研发体验和开发幸福感，更重要的是终于有能力做更多的事情，有更强的赋能业务抓手，我们惊奇的发现，在很多项目下，前端可以作为 PM，甚至自发发起商业项目。
但是伴随着爽，也有痛。毕竟我们是前端，还要去管像运维这种事情，另外 Node 作为胶水层逻辑很薄，却要占用大量的机器，非常浪费，当然 Node 侧的开发，尤其是环境部署等研发流程的事情也带来了一定工作量。

再看看集团Node.js 应用，BFF 数量约占 70%，常年水位在 10% 以下。这是一个通病，得治。
所以在这样的背景下，开始不断思考 BFF Next 路在何方，有没有更轻量的研发模式，可以让我们用最小的代价触达集团集团中间件体系，掌控 Web 层的所有事情。经过大量调研，认定 Serverless 是未来，从此开始了 Serverless 探索之路，和集团中台团队一起把 FaaS 体系搭建起来。（此处省略一万字）
故事到这先告一段落，讲了这么久，到底 FaaS 是个啥？三、Serverless 实践与配套工程、监控能力
先用一个视频，给大家一个体感。这里是和传统 Node 应用做一个对比。用传统的 Node 应用开发一个 Http 接口，从申请应用、申请机器、搭框架一堆破事搞下来，3、5 天过去了，而在 FaaS 下呢，不到 1 分钟就可以上线，上线之后还不需要关心运维的事情，是不是很爽。当然一个实际的函数上线流程还有灰度等流程，这里不做演示。3.1、FaaS基本原理
支撑这种高效模式的背后，是什么样的体系和原理呢。下面这张是FaaS 的架构简图。左半部分是开发态，右半部分是运行态。开发态和传统应用比，比较核心的区别是，传统应用发布需要打、推、拉镜像，而这里发布的是代码片段，代码片段的压缩包经过控制台发布后被上传到 OSS，Runtime 启动的时候从 OSS 拉取，并且和 Runtime 中的函数框架一起启动。由于代码片段天然很轻量，所以整个部署过程非常快。右边运行态，整体是跑在 K8S上，函数在运行过程中产生 CPU/内存内存等各种 Metrics，被采集并通过 Faas Controller 控制自动扩缩容。

3.2、Nodejs函数规范& Runtime
回到前端视角，我们需要关注 Js 函数规范、Runtime 设计、研发链路闭环、监控体系，以及基于 FaaS 上的生态比如 SSR。

一个最简单的标准函数，强依赖两个文件：函数入口 Js（函数业务逻辑）和函数配置 f.yml（函数用了哪个 Runtime，暴露成 Http/HSF 等等）。

3.3、Layer机制 & EaaS
上图中，除了常规配置外，还有一个特殊配置，Layer。Layer 是用来扩展 Runtime 能力的一种机制。Runtime 在启动和接收请求的时候，会在不同时间节点暴露一些钩子，方便 Layer 扩展标准函数所没有的能力。比如可以在 Runtime 启动的时候，在启动钩子中启动 Egg/Koa/Express，然后在请求钩子做一些处理，就可以把整个传统 Node 框架跑在 FaaS 基础设施上。在我的业务场景中，主要是用 EaaS，Egg As a Service。因为线上有成千上万个接口，如果用标准 FaaS，函数打平，不管是迁移成本还是未来增量函数的维护成本都非常高。所以想了个法子，在传统 Egg 的基础上加一个 f.yml 配置，然后跑在 FaaS 上，代码可以做到 80% 兼容。

EaaS 原理：

3.4、工程闭环
函数规范和 Runtime 让一个函数可以跑起来，但是要跑的好，跑的稳，还需要整套的工程闭环。比如创建函数、拉分支、预发、灰度、回滚等。

3.5、监控体系
除了传统的 CPU/内存等监控外，FaaS体系下还需要面向函数的更丰富的维度，比如函数单进程重启告警、Broker 重连告警等。

除此之外，这里介绍一下扁鹊平台，一个面向业务的监控。Serverless 时代，理论上机器层面的指标我们不该太关心，该交给 FaaS 平台。所以，在扁鹊平台，我们更关心业务层面，什么人、在什么时间、在哪个函数、请求了什么接口、返回状态怎么样。如果出现了异常，能快速定位业务日志。

当发现异常请求的时候，点右边的诊断按钮，用 Trace Id 把整个请求链路的 HSF、业务日志串联，非常直观。另外，可以实时按用户维度做告警，1分钟发现问题。

3.6、逻辑编排
除 Procode 编写业务逻辑，还可以用陆游平台做在线逻辑编排。

四、阶段结果 & 展望
再次回到这张图，由于我们采用的 EaaS，从 BFF 过渡到 Serverless 还算比较平滑。目前已经有很大一部分微应用跑在线上。

从降本提效视角看，效果非常棒（数据脱敏啦）：

稳定性视角看：

但是，这些数字，我认为只是 Serverless 红利的冰山一角。更多的价值体现在 1、让前端尤其是 B 类偏中后台业务前端有更多赋能业务的抓手；2、Serverless 让其他的技术领域变得更简单了，门槛降低了，从而可能带来大量的创新思维引发新的变化。这就是 Serverless+ 概念，举个例子，SSR 是个好东西，但是搞一个传统的 SSR 服务门槛还是比较高，Serverless + SSR 让他触手可及；再举个例子，传统的中后台搭建解决了视图的在线编排，但是数据的聚合消费还得依赖其他服务，Serverless 可以让整个体验更加流畅，解决更长链路的问题。