Serverless 学习笔记 (2): 阿里跨境供应链前端架构演进与 Serverless 实践
阿里跨境供应链前端架构演进与 Serverless 实践
Serverless 价值
Serverless = 广义 FaaS(Function as a service) + BaaS(Backend as a Service)
Serverless 能够使开发聚焦业务逻辑，减少工程链路消耗和运维成本，用最小的成本透出业务领域能力。其主要价值可总结为以下3点：
- 高效
- 按量付费
- 免运维
Serverless 演进之路
1. 青铜时代
阿里在 2016 年前还是使用的基于 HSF 的传统微服务架构，存在以下痛点：
(A) VM 层的耦合带来协作、效率、质量问题
所谓 VM 层的耦合，是指 FE(Front-End) 和 BE(Back-End) 之间存在的耦合内容，这种耦合会带来以下问题：
- 前后端职责不清，容易扯皮，不利专业发展；
- 前端重度依赖后端环境，开发、联调成本高，效率低；
- 浏览器端和 Web 层采用不同技术栈，组件无法复用；
- 前后端耦合暴露了很多质量问题。
(B) 技术栈严重限制了团队发展和开发幸福感
2. 白银时代
阿里在 2016 年 - 2018 年期间，在网关和后端微服务间引入了一层基于 Node.js 开发的 BFF(Backend For Frontend) 应用，JAVA 开发人员则专注于后端微服务业务逻辑的实现。BFF 应用主要进行聚合和裁剪的逻辑，减少客户端重复劳动，方便客户端统一接入和访问，同时降低了前端与后端微服务之间的耦合。这带来以下价值：
- 高效协同
- 提升研发体验
- 技术赋能业务
然而同时也带来了一些问题，阿里集团约有 Node.js 应用 1600+，BFF 应用数量约占 70%，且常年水位在 10% 以下： - 机器成本高
- 运维成本高
- 流程负担重
BFF 应用该何去何从？
3. 黄金时代
阿里从 2018 年至今，将 BFF 层改为基于 Ginkgo 和 Node Runtime 的 Serverless 解决方案，并在上层构建了陆游平台（逻辑编排）、扁鹊平台（链路诊断）。利用一种 Sidecar 的模式，把所有的流量都通过 Broker 来代理，无论是它的流量从接入层导入到函数内部，还是函数内部要去调用到第三方服务到外部，整个流量在函数之间的流动，都是通过这种 Broker 的模式来实现的。总体来讲实现了以下目标：
- 降本提效：研发提效、机器成本降低、运维成本降低
- 稳定性提升：灵活灰度、1分钟发现问题、秒级回滚
再谈 Serverless 价值
前端价值 = （ 对业务认知 + 对用户理解 ）+ （ 前端角色的优势 + 前端技术优势 ）
而 Serverless 将是撬起前端价值的重要支点。
Midway-FaaS 开源项目
阿里开源了 Midway-FaaS 项目，具备多云部署、灵活扩展、生命周期可扩展等能力，非常值得学习与研究。
本文地址：https://blog.csdn.net/sept_soyi/article/details/107307731