作者 | 刘金龙(福辰) 高德团队
引言
“后方事变多发地段, 请留神放弃车距 …”
“您已疲劳驾驶，请留神劳动 …”
“后方通过泰山游览景区，中国 5 A 级景区，是第一批国家级风光名胜区 ….”
......
这是高德出行的导航场景，像这样暖心的语音提醒，在春节期间的每天都会有上百亿次，以保障您的出行平安。然而这背地，任何零碎抖动或者故障，都会影响到用户的出行平安，所以在节日期间整个团队会壁垒森严并去现场值班，以保障系统的稳定性。
在过来的 2021 年，高德地图提出了新的品牌主张：在 “高德地图，哪儿都熟” 的背景下，高德出行 App 削减了更多的用户应用场景，随之而来业务零碎也变得更为简单。为了保障系统的稳定性，每一个节日大促期间，都会有共事去现场值班。
为了解决这一窘境，咱们对系统架构进行了更深的思考，并统一认同 Serverless 会是将来的技术趋势，所以在过来的一年中，咱们对 Serverless 技术做了很多的摸索，并实现了局部外围业务的 Serverless 化。利用 Serverless：低成本，免运维，高弹性等劣势，达成了上述提及业务，节假日无需共事再去现场值班的指标，让团队成员能够在家过一个安心团圆年。
本文会分享过来的一年，高德地图在 Serverless 畛域做过哪些摸索？如何与业务相结合，实现了一个低成本，低代码，免运维的现代化的 Serverless 研发平台。
业务背景
自 2021 年 7 月，高德地图发表品牌履新：整体向“出门好生存凋谢服务平台”降级，同时提出了“高德地图，哪儿都熟”的新品牌主张。高德地图从导航工具降级为出行服务平台、生存信息服务入口；为了更好地服务用户，拓展和出行相干的生存信息服务场景：高德地图主图、我的页面、行前行后场景以业务卡片的形式，透出了业务举荐信息。下图是高德 App 中呈现的几个典型卡片举荐场景：
款式多变
高德地图的业务特点之一是：高频率的款式变动。节日氛围的烘托、假期游览的疏导、交通信息的揭示等等多变不同的需要下，亟需一种可能疾速迭代的研发模式。而传统的研发模式是：每一个变动都是在 App 客户端上研发，而后随着 App 版本的公布进行款式再更新。（这种发版效率很慢，并且要思考到稳定性；每月一个版本，如果仍应用这种研发模式，其实是很难满足业务需要的。）
策略多变
卡片业务背地的后端代码，会随着业务类型的一直减少，因而相应的业务策略越来越多，如果不及时与零碎功能模块进行抽离，就像生命力倔强的爬山虎一样，零碎代码一直无序减少，越来越臃肿，复杂性也越来越高。而多变的策略，会要求在零碎架构上做出扭转，达到策略的疾速减少与删除，以及实时的失效。
客户端瘦身
过多的业务逻辑糅合到客户端，尽管能够肯定水平上进步性能，然而如果客户端过大，也会导致用户不愿更新。其实动辄几百兆的更新，不仅会减少咱们的带宽老本，也占用了用户的数据流量。此外因为代码多，相应的波及业务也多，如果每一个业务都有疾速迭代的要求，这就须要 App 客户端领有可能快频率的更新的能力。
两者形成了恶性的循环，不利于 App 的长期倒退，所以客户端瘦身势在必行。
早晚峰值
下班早顶峰，上班晚顶峰，置信大家都有过统一的体验：堵！！同样地图导航类利用，早晚峰值时间段十分的显著，且峰值和低谷的波谷差距十分大，如果所有的机器资源依照峰值去筹备，这老本无疑是十分高的，在低峰期，会造成极大的资源节约。所以咱们须要可能按需应用的弹性资源技术，去升高咱们的机器资源老本。
技术选型
通过架构组的多轮探讨，最终咱们并达成达成统一指标：全面拥抱 Serverless。因为 Serverless 的劣势特点，恰好解决了咱们的业务痛点需要。咱们也置信将来肯定是属于 Serverless 的时代。
Serverless for frontend
不必多说，当下前端最热的技术趋势就是：云端一体化研发模式，它实际上是以 Serverless 技术作为技术底座去构建的现代化利用研发模式；不仅升高了“全栈开发工程师”的技术门槛，还大幅提高了研发效率，阿里外部多个大型 App 都已全量应用，比方淘宝，天猫，飞猪等等。通过严格的数据统计，Serverless 在研发提效上能进步 38%，这也是咱们抉择 Serverless 最重要的数据根据。除此以外，基于 Serverless 实现的 CSR/SSR 首屏提速技术计划，目前也曾经十分的成熟，简直笼罩了阿里外部的 App 利用。
疾速迭代
工程卓越始终是咱们的谋求指标，然而因为各大技术产品关注重点不同，所以对于“研发最初一公里”的相干事项并没有做太多关注，这就导致了技术产品的性能与用户体验呈现割裂感，很多业务方放弃应用。
Serverless 的指标就是让你尽可能多的专一本人的业务逻辑，可能少关注或者疏忽非业务外围的运维工作；减速开发工夫，升高线上资源的冗余老本，所以 Serverless 无疑是扛得起降本提效的大旗的。
齐全弹性
申请毫秒级的调度是 Serverless 的外围竞争力，相比传统的分钟级弹性扩容，Serverless 技术存在微小的老本劣势，扩容所消耗的工夫越少，预留的机器资源就会更低，如果到了毫秒级别，就无需预留任何资源，这样老本可能大大的升高，资源利用率能够达到 100%。
低成本迁徙利器 – Runtime/Container
做过程序员的同学都晓得最苦楚的事件是“改他人的代码”，因而，尽管 Serverless 技术非常迷人，然而对于存量的利用如何迁徙到 Serverless 架构上，也始终困扰着咱们。
咱们应如何以低代码的形式解决传统架构潮汐流量对资源应用不合理的问题，于是咱们跟 Serverless 团队同和合作开发 Runtime。因为高德的服务均以 C++、Go、Rust 的语言设计，于是咱们开发出 C++、Go、Rust 的 Runtime。Runtime 集成了团体内的中间件，使得 Serverless 架构能够满足咱们之前服务的整个生命周期。让咱们能够疾速的切换服务到 Serverless 平台上。
然而随着咱们应用质变大，业务场景比较复杂，一些对外的服务是无奈应用外部 Runtime 的，这个重大的问题始终掣肘着咱们，使原有的架构由简略又变得复杂起来。直到阿里云 Serverless 团队的同学，推出了 Custom Runimte/Container 性能，彻底解决了咱们后顾之忧。咱们只需改几行启动命令，就能够轻松迁徙存量的利用。Serverless 团队也针对镜像的疾速散发做了大量的翻新优化工作，如应用四级缓存，P2P 技术，按需下载等形式，提供了秒级别下载 3G 大小镜像的能力。
得益于 Serverless 技术加持，无人值守的指标也就很容易达成，所有的运维操作，都通过 Serverless 的弱小调度能力去解决，比方峰值高峰期，零碎会主动毫秒级别进行扩容，低峰期同样也会 Graceful 的进行缩容，不波及任何人为操作运维，所以这也解决了咱们在节日大促期间过多人现场值班的窘境。
Serverless 技术落地
架构设计
在零碎设计上，咱们引入了两层 FaaS (Function as a Serverles)，端 FaaS 和业务 FaaS，其中：
- 端 FaaS，也就是 SFF（Serverless for frontend)，基于 Node.js，实现了端云一体化开发，将本来客户端的逻辑移到 FaaS 服务端来。这里在传统的 Frontend 和 Backend 之间形象出了 SFF，用来实现数据和调用逻辑封装，疾速开发、公布。
- 在后端，引入业务 FaaS，基于 Java/Go 实现, 用来封装举荐策略逻辑和数据转换代码，能够进步策略迭代效率，同时缩小策略迭代对主工程的影响。
从整体上看，将函数计算和容器化微服务整合在一起，综合利用函数计算的高效和传统微服务的灵便，是一种实用高效的架构设计思路。
疾速迭代
作为外围的利用，须要一套齐备的 CI/CD 流程去保障利用的品质，针对函数的品质，咱们基于了 Serverless Devs 工具链同样实现了一套研发全流程计划:。不仅具备函数多环境，函数灰度切流，函数可观测等能力，而且通过这套 Serverless 研发体系，咱们实现了 1 分钟开始进入开发，5 分钟实现上线的能力，同时默认具备异地多活的能力。
限流降级，异地多活
对于大流量利用的稳定性，限流爱护，降级预案，异地多活是三大必备性能。特地是大促的时候，非预期的流量都可能引起零碎雪崩，在咱们的 Serverless 研发平台上，集成了阿里云函数计算的并发度流控，QPS 流控的能力，做到了函数粒度的流控。
另外一个亮点是，FaaS 的容灾计划与传统利用的容灾计划相比，有着微小的劣势。在传统利用的容灾计划中，异地多活须要在备机房中筹备冗余的机器资源，这些资源也就是老本，然而在 Serverless 场景下的计划中，因为是疾速弹性，秒级别就能实现资源的筹备，所以无需进行资源冗余筹备，这就大大节俭了老本。尽管是三单元，然而老本依然是一个单元的费用，目前所有外围的函数利用，咱们都默认实现了三单元容灾。
冷启动优化
如果你的业务对于冷启动十分的敏感，比方 50 ~ 100 毫秒的提早减少，你都无奈承受的话，不要放心，咱们仍能够通过扩容策略进行补救：预留资源来消减冷启动对业务的影响。
- 预留实例，依据产品流量曲线，很容易得出固定流量是多少。这部分流量用“预留模式”，适宜冷启动敏感的业务；
- 按量扩容模式，按用户设置的并发度或者 CPU 利用率阈值进行扩容，扩容中的实例，不会立刻接管流量，而是实例 Ready 后再进行服务。所以扩容中新增的流量会依然派发到“正在服务中”的实例，并不会触发冷启动。
瞻望
在过来的 2021 年，高德在 Serverless 畛域中，做了很多方向的摸索，也实现了局部外围业务的 Serverless 化。单在 Serverless 的业务 QPS 峰值就曾经超过 40W QPS，然而这不是起点，只是刚刚开始，后续咱们会全面转向 Serverless 化。比方，地图数据的解决，图片的栽剪，音讯的生产等等这些离线的非在线利用，它们同样也是 Serverless 的最佳实用场景，咱们冀望今后有更多的场景去应用 Serverless，享受 Serverless 给咱们带来的技术红利！
更多内容关注 Serverless 微信公众号（ID：serverlessdevs），会集 Serverless 技术最全内容，定期举办 Serverless 流动、直播，用户最佳实际。