# Serverless 体系建设 S1
> 飞猪 Serverless 技术体系建设从去年 4 月份立项到现在已经快 1 年，期间经历过集团基设施调研和多 BU 沟通，围绕飞猪前后端合作开发的痛点制定解决目标，到空岛研发平台和网关的建设，试点业务的上线跑通，再到空岛、Lander、DEF 合并共建统一 FaaS 研发平台，以及围绕各种开发体验、稳定性的建设，再到现在 14 个业务场景 Serverless 化，完成现在的一个初步阶段
- 发布日期: 2020-03-15
- Author: Tw93
- HTML: https://tw93.fun/2020-03-15/serverless-one.html
- English translation: https://tw93.fun/en/2019-12-30/serverless-one.md
- 全部文章: https://tw93.fun/posts.md
---
飞猪 Serverless 技术体系建设从去年 4 月份立项到现在已经快 1 年，期间经历过集团基设施调研和多 BU 沟通，围绕飞猪前后端合作开发的痛点制定解决目标，到空岛研发平台和网关的建设，试点业务的上线跑通，再到空岛、Lander、DEF 合并共建统一 FaaS 研发平台，以及围绕各种开发体验、稳定性的建设，再到现在 14 个业务场景 Serverless 化，完成现在的一个初步阶段。
**有幸经历之前 Serverless 的喧哗到现在的平稳进行，在多阿里多部门的共建参与下，慢慢让阿里 Serverless 朝着一个方向在奔跑，致力于前端研发模式新升级，想通过此文给大家介绍一下飞猪现有建设情况，希望可以给有观望状态的同学以及目前正打算进行 Serverless 业务化的同学提供一些参考建议**，有理解偏差或者没有说明白的地方，欢迎大伙指出。
## 历史的发展
12~13 年，飞猪核心业务主要基于 PC 平台，前后端研发协作核心痛点在于动态模板的编写，不同团队前后端常围绕 “套模板” 工作的归属引发矛盾。
到 14、15 年 All in 无线的过程中，为了解决从 PC 时代复杂行业数据到无线网关 Mtop 的快速转换，飞猪成立了无线服务端团队来完成数据到端侧的胶水层工作，可很好解决系列问题，但是持续重复的包接口也让无线服务端面临的成长和沉淀问题，不太可持续的。
16、17 年无线服务端技术建设稳定后，也由于上述问题，Mtop 接口封装的工作逐步由下放到行业后端同学，随着 H5/Weex/iOS/Android 多端发展，各自对接口的诉求难以一致，出现通过 Node BFF 层来承接胶水问题，但前端运维能力不强、长尾机器的浪费导致很难全量 BFF 化。
到 18 年飞猪平台化改造完成，业务由纵向行业变成横向平台承接，需求的落地需要经过多方的协作和排期，中间层的碎片化也更加严重，对前后端协作成本带来了更大的挑战，同时不能通过单领域问题的解决方案(如下单页解决方案)来解决其他业务层问题，**急需一轻量通用的方案来解决日益严重的胶水层的协作**。
## 契机的出现
随着 Serverless 在业界各云平台的落地，通过 FaaS 这一种“碎片化”函数方案可以很好解决上述那些很前后端协助碎片化问题；在财年初，在中间件团队做的 Serverless 容器基础建设加上研发部门 FaaS 平台侧、Midway Runtime 支持，让 Serverless 在集团可落地变有可能。
在此契机下，我们启动了《天空之城 - Serverless 技术体系建设专项》，通过集团底层设施建设上层 Serverless 技术体系来解决在飞猪导购、互动、中后台领域碰到的系列问题，并借此推动现有前后端协作模式向下阶段迈一步。
## 天空之城建设
### 方案图
通过集团各方基础设施团队交流请教，我们围绕飞猪当前痛点形成如下 Serverless 建设图
其中蓝色为重点建设部分，绿色为集团侧依赖，共建并推动发展，红色部分为行业/平台已有能力；在半年的建设过程中，随着集团 Serverless 共建的发展推动，以及业务试点过程中诉求的逐步清晰，技术方向上主要围绕如下 4 点进行：
### FaaS 研发平台建设
半年内，FaaS 研发平台建设累次经过 4 期，从最开始一期自建空岛到后面 3 期和多 BU 同学共建统一研发平台满足可迁移使用，宗旨一直都是 <借力集团底层能力，构建上层 Serverless 上层统一平台，满足业务场景 Serverless 化的使用>
**一期 自建空岛满足飞猪试点使用**：在去年 6 月份，我们完成了飞猪 FaaS 统一管理平台空岛的建设，底层对 Aone 基础 API 高度封装，打通函数开发、服务调用、部署、runtime 全流程，从租户管理、业务场景再到函数组管理，打通 WebIDE，更加符合飞猪上层业务开发同学的使用习惯；在此基础上，我们完成了 3 个业务场景试点使用，对研发资源投入、运行时性能、稳定性等指标形成部分定量及定性结论。
与此同时，Lancer 平台也开始赋能淘宝导购业务的使用，人工智能的 YaaS 平台在满足中后台场景的使用，但缺少一个阿里前端统一的 Serverless 研发平台，经过和阿里不少团队多次讨论和对焦，有了接来下的共建研发平台的规划落地。
**二期 参与集团共建完成多方合并，支持飞猪、手淘可跑通**：主要是前期合并和产品方案的梳理，一起制定解决方案，完成飞猪空岛、手淘 Lancer、Def 的三方融合，同时在底层数据库结构上和 Api 上面的统一打通，功能上支持非覆盖发布和灰度切流方案，这个阶段基本完成 FaaS 函数的可跑通，但是在易用性上还需改善；
**三期 统一平台功能丰富，支持飞猪侧好用可迁移**：此期工作覆盖现有空岛能力，也即现在上图看到的 DEF 2.0，在之前基础上支持 BU、产品场景的聚合能力、研发闭环测试监控体验、Http 通用网关支持中后台场景；完成统一对外 Open-Api 的梳理规范制定工作，提供轻量级的 Pipeline 发布流程给服务编排系统的使用；让 Sandbox 以及服务市场对飞猪侧的良好支持，共建产出 Rax + FaaS 一体化解决方案，满足飞猪侧在统一研发平台的使用
**四期 使用痛点优化，满足 930 前可切流工作**：在上期功能满足使用后，此阶段建设重点解决手淘、飞猪侧用户使用过程中的痛点，补充操作手册，pipeline 发布管控流程增强；同时支持了中后台 FaaS 一体化场景的使用，以及在**函数详情页新增了函数测试、快速调用、Debug 3 合一功能让大家方便使用**；
### 空岛网关建设
在 FaaS 函数被端侧使用起来前，还需要网关来将下层 HSF 服务访问转成通用 Mtop/HTTP 来可访问，并通过统一网关入口来为飞猪侧所有 FaaS 函数提供鉴权、限流、容灾、日志、监控的作用，目前建设进行到了第三期，后续重点以能力增强为主。
**第一期**：主要是用于和空岛平台的对接，通过规范约定，**提供基础能力满足业务侧试点的使用**，当时是通过访问空岛数据库方式获取到函数对应的 FaaS 触发信息的方式来进行连接
**第二期**：恰逢研发平台在和集团共建，为了对接新平台的使用，我们在原来基础上和业务平台还有淘宝等同学网关层配置标准，**可满足非覆盖式发布和灰度切流的使用**，在函数发布时候，将信息推送到对应远端分组，网关侧监控，在满足标准的基础上也解决了和平台数据耦合的问题
**第三期**：更多聚焦在**可适配性参数规范、稳定性、能力扩充**3 方面，目前规范、稳定性全完成，全链路日志、网关监控报警、防爬、钉钉定制报警接入，后续重心放到能力扩充上，解决部分由于地层 BaaS 能力不足的问题
### 基础支持
在满足研发平台和网关侧可被业务开发通过正常稳定支持业务外，对外需要和集团共同一起弄好上下游的一些基础设施支持，飞猪侧在里面像一个帮忙写部分代码以及提需求的”业务方“角色；对内做对应的稳定性保障以及一些优化让业务开发同学更舒服的开发；对于新着手的 BU，可能也需要在 midway-faas runtime、Ginkgo 机器、稳定性、一体化上花上时间来支持防止出现遗漏；
- **FaaS Runtime**：这一块是函数运行时很关键一趴，由集团 Node 团队小伙伴这边提供，目前版本可很好满足业务使用；期间主要帮忙提供中间件调用案例 demo，提升工具链路体验，以及文档补充的工作；包括在运行时的一些 Bug 排查通知沟通的工作，让底层是可靠的防止对业务产生影响。
- **稳定性事项**：目前对于 Serverless 最重要的一趴就是稳定性保障，不产生线上问题也是建设的底线(防止出现线上问题->Serverless 现在不稳定->重要业务不使用连环反应)；包括在上线大业务前的压测工作（惊讶一单 Pod 可承受 300qps 的访问！）、前期合作方的准备工作(扩容、评估)、代码自身容灾检查、网关层面容灾配置、监控接入等事项；由于目前飞猪侧只在张北有部署，后续需推动上云业务必须多单元部署来提升稳定性；
- **函数迁移上云**：和函数运行容器相关的就是我们的中间件团队了，目前云上集群可用，逐步下线原有老机房，期间完成飞猪侧函迁移事项，包括白名单函数梳理、迁移、检查、订正、验证、全部迁移，有趣的是通过此推动集团监控完成监控以及 Debug 能力互通；
- **Rax + FaaS 一体化研发**：属于未来云端一体化中比较重要的一环，目前多方制定了 client、cloud 的目录结构，完成飞猪网关模拟 SDK、前端请求 SDK 打通网关开发和合并到主干，在脚手架中加入对飞猪 Rax+Faas 一体创建支持，满足全流程可跑通本地调试调用和统一研发平台的发布工作；目前正在和飞猪侧工程体系 Clam 打通对应流程，期待可让业务侧真正可友好上线一体化项目
## 业务场景 Serverless 化支持
说起 Serverless 技术建设，其中很大一趴是技术可以满足业务的诉求，让其在业务场景落地的过程中探索一种新的研发方式；
目前累计完成完成高铁游、发布器、签证 wifi、门票、任意门、周边游、收藏、poi、发现、找相似、泰坦超管、资源位管理(中后台一体化)、交通侧搜索(开发完成待上线)等业务近 22 个函数的 FaaS 化支持，14 个业务试点场景，同时在导购域内每天产生 1000W+ 次函数调用\*\*;
通过 Serverless 前端同学具备了服务开发能力，可以比较好解决在接口开发、分工上面边界问题，同时可释放一定 java 和人力资源，节约机器运维人力。
从试点效果上来说，目前判断 Serverless 体系适宜数据源合并、数据协议转换、中间层及数据透传的业务场景，能够以更优雅的方式承接胶水层逻辑抹平云与端之间的鸿沟，但同时目前在开发体验、稳定性方面还需加强协作方的合作，共同推动基础设施往前走。
## 后续规划
## 展望
很庆幸目前 Serverless 建设在跟着阿里共建发展以及业务试点推动下，逐步由当时的喧嚣变得现在的稳定进行，同时目前可以做的事情还很多，欢迎进入 Serverless 的世界，同时更好的促进她的发展！
其中蓝色为重点建设部分，绿色为集团侧依赖，共建并推动发展，红色部分为行业/平台已有能力；在半年的建设过程中，随着集团 Serverless 共建的发展推动，以及业务试点过程中诉求的逐步清晰，技术方向上主要围绕如下 4 点进行：
### FaaS 研发平台建设
半年内，FaaS 研发平台建设累次经过 4 期，从最开始一期自建空岛到后面 3 期和多 BU 同学共建统一研发平台满足可迁移使用，宗旨一直都是 <借力集团底层能力，构建上层 Serverless 上层统一平台，满足业务场景 Serverless 化的使用>
**一期 自建空岛满足飞猪试点使用**：在去年 6 月份，我们完成了飞猪 FaaS 统一管理平台空岛的建设，底层对 Aone 基础 API 高度封装，打通函数开发、服务调用、部署、runtime 全流程，从租户管理、业务场景再到函数组管理，打通 WebIDE，更加符合飞猪上层业务开发同学的使用习惯；在此基础上，我们完成了 3 个业务场景试点使用，对研发资源投入、运行时性能、稳定性等指标形成部分定量及定性结论。
与此同时，Lancer 平台也开始赋能淘宝导购业务的使用，人工智能的 YaaS 平台在满足中后台场景的使用，但缺少一个阿里前端统一的 Serverless 研发平台，经过和阿里不少团队多次讨论和对焦，有了接来下的共建研发平台的规划落地。
**四期 使用痛点优化，满足 930 前可切流工作**：在上期功能满足使用后，此阶段建设重点解决手淘、飞猪侧用户使用过程中的痛点，补充操作手册，pipeline 发布管控流程增强；同时支持了中后台 FaaS 一体化场景的使用，以及在**函数详情页新增了函数测试、快速调用、Debug 3 合一功能让大家方便使用**；
**第一期**：主要是用于和空岛平台的对接，通过规范约定，**提供基础能力满足业务侧试点的使用**，当时是通过访问空岛数据库方式获取到函数对应的 FaaS 触发信息的方式来进行连接
**第二期**：恰逢研发平台在和集团共建，为了对接新平台的使用，我们在原来基础上和业务平台还有淘宝等同学网关层配置标准，**可满足非覆盖式发布和灰度切流的使用**，在函数发布时候，将信息推送到对应远端分组，网关侧监控，在满足标准的基础上也解决了和平台数据耦合的问题
**第三期**：更多聚焦在**可适配性参数规范、稳定性、能力扩充**3 方面，目前规范、稳定性全完成，全链路日志、网关监控报警、防爬、钉钉定制报警接入，后续重心放到能力扩充上，解决部分由于地层 BaaS 能力不足的问题
### 基础支持
在满足研发平台和网关侧可被业务开发通过正常稳定支持业务外，对外需要和集团共同一起弄好上下游的一些基础设施支持，飞猪侧在里面像一个帮忙写部分代码以及提需求的”业务方“角色；对内做对应的稳定性保障以及一些优化让业务开发同学更舒服的开发；对于新着手的 BU，可能也需要在 midway-faas runtime、Ginkgo 机器、稳定性、一体化上花上时间来支持防止出现遗漏；
- **FaaS Runtime**：这一块是函数运行时很关键一趴，由集团 Node 团队小伙伴这边提供，目前版本可很好满足业务使用；期间主要帮忙提供中间件调用案例 demo，提升工具链路体验，以及文档补充的工作；包括在运行时的一些 Bug 排查通知沟通的工作，让底层是可靠的防止对业务产生影响。
- **稳定性事项**：目前对于 Serverless 最重要的一趴就是稳定性保障，不产生线上问题也是建设的底线(防止出现线上问题->Serverless 现在不稳定->重要业务不使用连环反应)；包括在上线大业务前的压测工作（惊讶一单 Pod 可承受 300qps 的访问！）、前期合作方的准备工作(扩容、评估)、代码自身容灾检查、网关层面容灾配置、监控接入等事项；由于目前飞猪侧只在张北有部署，后续需推动上云业务必须多单元部署来提升稳定性；
- **函数迁移上云**：和函数运行容器相关的就是我们的中间件团队了，目前云上集群可用，逐步下线原有老机房，期间完成飞猪侧函迁移事项，包括白名单函数梳理、迁移、检查、订正、验证、全部迁移，有趣的是通过此推动集团监控完成监控以及 Debug 能力互通；
- **Rax + FaaS 一体化研发**：属于未来云端一体化中比较重要的一环，目前多方制定了 client、cloud 的目录结构，完成飞猪网关模拟 SDK、前端请求 SDK 打通网关开发和合并到主干，在脚手架中加入对飞猪 Rax+Faas 一体创建支持，满足全流程可跑通本地调试调用和统一研发平台的发布工作；目前正在和飞猪侧工程体系 Clam 打通对应流程，期待可让业务侧真正可友好上线一体化项目
## 业务场景 Serverless 化支持
说起 Serverless 技术建设，其中很大一趴是技术可以满足业务的诉求，让其在业务场景落地的过程中探索一种新的研发方式；
目前累计完成完成高铁游、发布器、签证 wifi、门票、任意门、周边游、收藏、poi、发现、找相似、泰坦超管、资源位管理(中后台一体化)、交通侧搜索(开发完成待上线)等业务近 22 个函数的 FaaS 化支持，14 个业务试点场景，同时在导购域内每天产生 1000W+ 次函数调用\*\*;
通过 Serverless 前端同学具备了服务开发能力，可以比较好解决在接口开发、分工上面边界问题，同时可释放一定 java 和人力资源，节约机器运维人力。
从试点效果上来说，目前判断 Serverless 体系适宜数据源合并、数据协议转换、中间层及数据透传的业务场景，能够以更优雅的方式承接胶水层逻辑抹平云与端之间的鸿沟，但同时目前在开发体验、稳定性方面还需加强协作方的合作，共同推动基础设施往前走。
## 后续规划
## 展望
很庆幸目前 Serverless 建设在跟着阿里共建发展以及业务试点推动下，逐步由当时的喧嚣变得现在的稳定进行，同时目前可以做的事情还很多，欢迎进入 Serverless 的世界，同时更好的促进她的发展！