飞猪 Serverless 体系建设 S2

Categories: Share 2020-03-30

本文已经脱敏审批发表到飞猪前端团队公众号

历史的发展

12~13 年，飞猪核心业务主要基于 PC 平台，前后端研发协作核心痛点在于动态模板的编写，不同团队前后端常围绕 “套模板” 工作的归属引发矛盾。

到 14、15 年 All in 无线的过程中，为了解决从 PC 时代复杂行业数据到无线网关的快速转换，飞猪成立了无线服务端团队来完成数据到端侧的胶水层工作，可很好解决系列问题，但是持续重复的包接口也让无线服务端面临的成长和沉淀问题，不太可持续的。

16、17 年无线服务端技术建设稳定后，也由于上述问题，接口封装的工作逐步由下放到行业后端同学，随着 H5/Weex/iOS/Android 多端发展，各自对接口的诉求难以一致，出现通过 Node BFF 层来承接胶水问题，但前端运维能力不强、长尾机器的浪费导致很难全量 BFF 化。

到 18 年飞猪平台化改造完成，业务由纵向行业变成横向平台承接，需求的落地需要经过多方的协作和排期，中间层的碎片化也更加严重，对前后端协作成本带来了更大的挑战，同时不能通过单领域问题的解决方案(如下单页解决方案)来解决其他业务层问题，急需一轻量通用的方案来解决日益严重的胶水层的协作。

建设目标

基于以上背景与问题分析，飞猪去年5月份启动了 「天空之城」- Serverless 技术体系建设专项，项目总体目标：

构建飞猪 Serverless 研发基础设施，赋能上层产品/平台，推动前端/后端、业务/平台、领域间研发协同向更高效、职能聚焦的模式演进，缩短创新业务研发落地周期，提高研发资源投入产出比。

• 中短期：清晰职能边界（前端/后端、业务/平台）、创新业务孵化（misc 类服务、平台能力补缺）
• 中长期：降成本（研发、机器）、免运维（降低大促场景压测等运维投入）、存量长尾迁移（建设 CaaS 能力）

最近半年

上半年完成了系列的基础设施建设，经历过集团基设施调研和多 BU 沟通，围绕飞猪前后端合作开发以及业务的痛点制定解决目标，到空岛研发平台和网关的建设，和集团深度共建统一 FaaS 研发平台，以及围绕各种开发体验、稳定性的建设，让整体 Serverless 达到可用状态。

但是当时整体距离飞猪 Serverless 体系基建完善度以及好用还存在一段距离，面临着稳定性需强保障、BaaS 能力不全、工程链路不便捷、业务试点节奏感差这 4 个急需解决的问题。

在这个情况下，我们下半年【启动飞猪 Serverless 体系二期】，在夯实 Serverless 技术体系建设上，寻找到前端研发体系升级和 Serverless 结合的突破口，围绕推进 Serverless 基础设施升级、监控稳定性增强、研发体验和工程化升级、前后端一体化业务最佳实践 4 方面进行。

现阶段完成多业务场景试点探索，同时 Serverless 技术建设满足业务的使用，完成试探期 -> 可用期阶段，下一个主要目标为业务场景的范围铺开，用于产生更大的价值。

想借此总结给大家同步我们这最近半年的一些技术建设成果，可能有一些你需要的能力正好解你之急。很欢迎一起讨论，如有理解偏差或者描述不清晰的点，欢迎大伙直接指出或者提出建议。

先说落地

谈到技术体系，首先需要考虑到她对业务的价值体现，包括如何衡量其带来的差异化价值。

首先给大伙同步 Serverless 在飞猪业务场景的落地效果，目前一年飞猪 Serverless 累计在高铁游、交通搜索、飞猪发布评论器、资源位管理平台、签证、WIFI、周边游、旅行任意门、旅行购、超级新发现、门票、POI、发现视频、新人专区、找相似、泰坦、小程序 URL 管理、收藏/行程、船票、德铁、PC 内容详情全切 FaaS SSR、直播、统一目的地、投放平台发券/圈人/发布活动等 25 个场景使用探通，其中 S2 上线 10 个函数组，主要聚集在新业务新类型场景上面的落地工作，包括飞猪侧各前端团队也均使用中，同时也有不少“特别代表性”的场景业务：

• Rax 一体化场景：我们完成了出境购 Rax + FaaS 一体化项目落地，中间有不少地方拉上集团同学一起支持完善，也是集团第一个 Weex 一体化业务的上线；

• 通用搜索能力架构：机票组同学他们利用 Serverless 来做交通线的搜索架构能力，设计好对应的搜索通用能力，赋能到后面的船票、德铁搜索的使用；

• 中后台一体化场景：利用 Ant Design Pro + Serverless 一体化能力以及数据库连接快速上线飞猪参数透传管控平台，省去了应用、域名申请复杂流程，更轻量化使用

• 飞猪 SEO SSR 能力落地：飞猪侧 SEO 平台在去年给飞猪用户拉新，搜索排名带来了很大的价值，但是想快速落地一个 SSR 页面，其实还是需要不少服务端的能力，目前跑通飞猪攻略页面的 SSR 过程，可以像开发函数一样来开发我们的 SSR，使用上也非常简单，期待后面带来更大价值

能力夯实

可以通过如下一图近半年我们的一些建设事项，通过一体化开发模式来让前端同学逐步具备产品化的开发思想，BaaS 能力的扩充将可做的事情向下再 down 一层，监控一体化建设让 serverless 全链路得到可视保障，带着业务诉求参与到集团 Serverless 共建更好促进整体的发展。

一体化研发模式升级

• Rax + FaaS 一体化能力方面：S2 我们在原有老[client/cloud]推动共建小组一起升级到前端为主 [src/apis] 的目录结构，本地开发调试 SDK 以及网关请求前端 SDK 升级兼容完成并透传 fcMtopInnerParams 参数模拟，在业务侧我们完成出境购业务的落地上线

• Ant Design Pro + FaaS 一体化中后台开发：由于目前不少飞猪小二平台不少是通过在 Aone 申请 1+3 台机器的方式来完成 Node 应用的部署，存在申请麻烦、机器浪费、上线复杂的问题，基于此我们跑通 Ant Design Pro 体系下的 FaaS 一体化的本地调试、编译、部署上线全流程，目前已沉淀到脚手架和研发平台，我们可以像开发一个普通前端页面一样上线中后台应用，无需申请机器和域名，目前飞猪渠道管理平台跑完串通数据库使用流程上线

  

• FaaS Rax SSR 一体化跑通：之前开发 SSR 的时候，需要让一个前端变成一个全栈，同时需要考虑到 Node 选型，申请、搭建、部署、保障这些过程，这也导致其很难在内部大范围使用的一原因，水澜这边 SSR 共建组同学产出通用能力，后续基于 nginx+lua+缓存 的动态代理策略，完成了飞猪侧的全链路上线跑通，目前也可投入生产使用了，可很好的用于后续飞猪 SEO 和页面性能提升场景，可见旅游攻略»

这一类型的一体化开发模式，目前在飞猪处于代表场景业务跑通上线落地流程，后续量产我们需要加油搞起来，以便实现这个技术更大的价值。

开发体验完善

说到前端开发体验，飞猪前端同学必然会想到「CLAM 工程体系」（有一种海边敲着代码 clam 的感觉），一组简单命令完成项目初始化(clan init)、新建迭代和分支(clam newbranch)、本地开发调试(clam dev)、预发(clam prepub)、上线(clam publish)的全流程工程，无缝和底层平台能力打通。

基于此，我们完成了 Clam 和 FaaS 开发体系的打通，现在飞猪开发者无需去研发平台申请对应的应用，一步一步点击迭代，直接通过clam init faas创建纯 faas 项目、clam init rax --faas创建 RAX+FaaS 一体化项目，后续流程即可保持可以之前页面开发体验一致，可降低大伙的使用成本。

同时为了减少初步使用 FaaS 同学的上手成本，完成飞猪侧 Serverless 使用文档整理归纳，包含新手教程、框架介绍、常用服务调用、BaaS 能力、一体化开发、运维排查开发全流程的使用文档»>

BaaS 能力建设

依稀记得当时上半年由于不少 BaaS 能力不好支持，特别是数据库的使用，导致有一些场景只能望而却步，这一块也是我们推动集团共建同学需要强力支持的一块，在下半年我们一起折腾出如下方案来满足现有业务诉求：

代理方式连接数据库（过渡方案，已存场景使用）：我们开始时候跑通了利用 baas-sdk 的方式连接中心应用实现代理到数据库的增删改查操作，当做当时的一个不能使用数据库的过渡方式使用，但是由于中心化的代理不敢强保障 C 端应用稳定性，更多推荐内部应用使用。

FaaS 直连数据库(推荐方案，较安全)：加上 C 端业务侧有强诉求，需要使用数据库能力，我们和 midway runtime 的同学跑通了在 FaaS 函数 LifeCycle 生命周期启动的时候，实现了对数据库的直连，让每个函数可以读取到 Configuration 配置，同时也沉淀了一套我们认为的最佳的 FaaS 数据库增删改查建表的使方式，填补了集团在 FaaS 使用数据库这一块的空白，目前此类使用已在飞猪 C 端城市目的地统一以及内部中后台渠道管理中使用跑通。

内网登录能力调用：我们中后台体系的第一个中间件的能力，使用方式和原有 midway 的方式很像，可以借助此插件快速实现内网登录能力的接入，可以让我们快速上手使用。

稳定性和运维能力

稳定性一直在 Serverless 体系中最需要关注的一趴，由于属于新兴事物，更需要尽可能保障稳定性，让新同学觉得这个体系是靠谱的，他的业务可以来生产使用，这样方可促进其更好融合发展。

Serverless 监控一体化平台：为了更好发现和排查问题，我们拉上原来 Node 监控同学一起弄了一个 Serverless 监控一体化的平台，目前 1.0 版本已经发布发布，加上函数监控信息，引入健康分的概念，也加入重要功能全链路监控，通过流程图的方式可一眼看到问题所在，加上了快速止血的入口，同时整体能力已经接入到统一 FaaS 研发平台。目前我们正在弄函数监控关注部分，同时在着手弄自定义日志统计的能力，期待后续在监控侧给大家带来更大的价值

除了监控部分，让函数如何在低运维成本下也是需要重点考虑的地方，基于此 Serverless 共建组推动 Serverless 机器同学一起上线了函数动态缩扩容的能力，同时也建立起 函数租户管控平台，便于后续函数容量、租户、上线等管控工作。

与此，还有一个重要的飞猪 serverless 支持多单元化事项也一直在推动中，以便出现紧急问题可以实现单元逃逸。

网关侧增强

在 上半年我们网关侧的能力可满足现有 C 端业务侧使用，在 S2 我们做了部分增强工作，如网关前端 SDK 支持 H5 和 Rax1.0 网关信息的透传，同时将飞猪侧网关埋点数据和全链路监控实行了规范打通，满足 serverless 全链路监控的使用

集团共建

以上的大部分能力都是和集团 Serverless 共建侧的能力一起去落地弄的，特别感谢兄弟团队的合作和支持，如 FaaS 研发平台、一体化方案、监控一体化、BaaS 能力这些建设都是强依赖大伙一起配合来弄方可被落地使用。

展望

在下一年我们将更加聚焦在业务侧铺开使用中，同时需要验证 Serverless 对业务的真正差异化价值，对机器节省的证明；也很欢迎更多同学参考进来，把阿里 Serverless 体系价值再往前推一步！

技术侧在下一年会更加聚焦在稳定性、以及底层 BaaS 能力，周边监控体系的建设上面，业务侧更多会以多场景业务铺开，更深一步来探通 Serverless 可带来的业务价值！