作者 | 竞霄

Serverless 作为云计算的最佳实践和未来演进趋势，其全托管免运维的使用体验和按量付费的成本优势使得它在云原生时代备受推崇。Serverless 的使用场景也由事件驱动，数据处理等部分特定场景转向更为广泛通用化的 WEB，微服务，AI，进而在电商，互娱，出行，乃至传统行业都有渗透。

在 Serverless 的普及与推广过程中，开发运维人员虽然认同其降本提效的核心价值，但同时被诸如厂商锁定，黑盒化，全屏蔽等一系列 Serverless 全包的特性所困扰;进而所引发的迁移成本高，问题排查难度大，根因定界分析困难等痛点亟需解决。

所谓开放，是指用户可以摆脱心智负担的，在不变更语言应用的前提下从任意平台迁移至 Serverless，是指用户可以即开即用的获取 Serverless 应用的全生命周期核心数据，更是指用户可以将其原有的架构与 Serverless 架构进行融合，实现云上云下云间的互通与混部。拥抱开放后 Serverless 将不会是需要改造以适配兼容的，可望而不可即的技术试验品，也不是一座独立出来的，与原有技术体系割裂的数据孤岛，而是承载技术开发者们理想与现实的，能够让技术变得更加普惠、通用、共享的最短路径之一。

阿里云坚持在 Serverless 领域持续投入并在技术竞争力上维持领先地位, SAE(Serveless 应用引擎)作为业界首款面向应用的 Serverless PaaS，能够提供成本更优、效率更高的一站式应用托管方案。SAE 在 2018 年内部孵化之初就秉持着零门槛，零改造的宗旨进行应用(任务)的 Serverless 改造和落地实践，并且在产品的发展历程中不断积极寻求被集成，增进 DevOps 全流程体验，三年内助力千余家客户实现应用的云原生 Serverless 化。SAE 目前已有和即将推出的功能均围绕着“拥抱开放”展开，下面我们一起看看 SAE 目前所提供的产品功能特性以及它背后的思考逻辑。

一、Serverless 部署架构的开放性

许多用户的应用其实并不是从零便开始使用 Serverless，而是出于对 Serverless 理念的认同，基于架构升级演进的诉求，期望将原有的部署环境如物理机，云主机，Kubernetes 进行迁移或者是混部于 Serverless 之中。那么在此场景下，应用迁移改造的成本显得尤为重要，然而 Serverless 陡峭的学习曲线和厂商生态锁定的刻板印象，令诸多开发者望而却步。正如先前所述，SAE 主打零门槛，零改造迁移，应用其实无需修改任何代码逻辑，便可直接部署在 SAE 当中，而对于非容器类的应用，SAE 也提供内置的镜像构建能力，并借助发布单使得全 CICD 变得流程化、自动化、可视化。下面我们重点介绍一下跨平台的使用场景。

1.SAE 与云主机混部

SAE 支持与云主机(ECS)实例进行混部，以便于在存量迁移的场景下实现快速弹性，发挥 SAE 的优势，整个过程无需任何开发改造。具体的方式为，将存量 ECS 实例加入到 SAE 实例声明使用的 SLB 后端虚拟服务器组中，SAE 应用在部署、扩缩容、停止、启动、重启、垂直扩缩容等场景中，会自动动态维护 SLB 后端的实例，统一对外提供服务。

2.SAE 与 Kubernetes 的流量互访

SAE 支持与 Kubernetes(ACK) 进行流量互访，借助公网 SLB/Ingress ，或者相同 VPC 下私网 SLB 协同 PrivateZone 内网域名解析的能力，暴露应用服务地址;亦或在微服务场景下采用同一注册中心，均可实现在不变更原有架构的基础上，进行 SAE 实例与 Kubernetes pod 的通信与交互。

二、Serverless 指标数据的开放性

Prometheus 是一套开源的监控报警系统。主要特点包括多维数据模型、灵活查询语句 PromQL 以及数据可视化展示等，其已经成为了云原生监控体系的事实标准。SAE 提供了开箱即用的可观测能力，同时全面对接并兼容 Prometheus 生态，开放核心指标数据，以满足用户们在监控领域灵活配置、可定制、可扩展的诉求。

1.基础监控数据

SAE 对应用所运行实例的 CPU、负载、内存、网络和磁盘进行数据采集与分析，并能够以动态图的方式展示，方便用户实时、且直观地了解到应用运行设备的状态。采集的数据会预制在 Prometheus 中，并配置集成可视化大盘。用户可以通过 Grafana 进行自定义大盘的配置。

2.应用监控数据

针对于 Java、Php 语言的应用，SAE 可以通过 agent 技术对其接口 RED 等数据进行埋点采集。同时，其数据也已预制在 Prometheus 中，并集成可视化大盘，用户可以通过 Grafana 进行自定义大盘的配置。

对于其他的多语言应用，SAE 将采用 EBPF 技术，进行无入侵的七层监控数据的获取，并提供全流程无感的使用体验。多语言监控数据同样会预制在 Prometheus 中，用户可以通过 Grafana 进行自定义大盘的配置。

3.自定义监控数据

SAE 应用可以根据其自定义业务，手动埋点暴露自定义指标数据，并借助 VPC 内服务发现能力，接入Prometheus，保证在实例不断变化的环境下，整个采集链路的可用性。

三、Serverless 通用运维的开放性

随着产品不断发展演进，我们深刻的意识到 Serverless 并不意味着像愿望般美好的将服务器完全黑盒化，用户完全信赖产品的内部操作，同时不断教育用户要采用符合 Serverless 的心智和行为方式进行开发运维，这样既与用户已有的知识体系和传统运维习惯相冲突，又不利于各类问题的及时排查与根因定界。而用户真正需要的是享有知情权的同时，借助全方位运维能力的提升来更加高效，自动的实现运维操作，降低运维复杂度，提升运维幸福感。SAE 结合用户常见诉求和使用痛点推出了多项解决方案和最佳实践来不断优化和提升 Serverless 运维能力。

1.Webshell 与工具一键安装

登录实例进行信息收集和问题排查，在传统运维中是必不可少的一环。在 Linux 环境下已经有诸多成熟的问题诊断工具去供用户使用，SAE 深知不应该全然被动地将整个应用以及环境交付于第三方供应商，真正了解企业场景和业务逻辑的是用户需要掌控力。SAE 在暴露应用实例的基础上，提供了 Webshell 功能，用户可以像访问本地主机一样访问 Serverless 实例进行运维操作。同时为了更加高效地进行问题排查，SAE 提供了工具一键安装的功能，解决了自定义镜像中命令阉割的情况，并适配各种操作系统，可以在私网环境下下载并更新工具。

2.文件双向传输

如何高效运维，一直是 SAE 专注的重点。用户在日常开发部署测试的过程中，经常提到，期望将本地文件或者配置上传至云端应用用于临时调试，或者将云上应用的日志，配置，Java dump,core dump下载至本机。作为运维领域的刚需，SAE 推出 Serverless 场景下文件双向传输功能，在无软件依赖，应用无入侵的前提下实现上传下载的功能。

3.跳板机与端云联调

在开发联调测试的过程中，受限于对应用本身环境的依赖，考虑到启动部署速度和效率，开发者往往不愿意重新在本地启动云上应用，模拟云端执行环境进行本地调试。这其实也是 Serverless 场景下面临的一大难题，SAE 借助内置跳板机，实现本地服务与云端 SAE 应用间的互调，同时支持 Java/php remote debug 和实例的远程访问，真正的将本地和云端环境融为一体。

四、总结

拥抱开放，Serverless 时代的下一征程，这既是 SAE 在云原生浪潮下的愿景，也是 SAE 持续专注并将继续坚持的方向。未来 SAE 将致力于以用户最小的改造和认知成本来提供产品更为强大的技术支持和体验，将在部署架构，指标数据，通用运维乃至各个方面以拥抱开放的理念持续打磨深造，推进 Serverless 时代的发展进程。

关键词： 双向传输 的基础上 的前提下 发现能力 数据采集