从 DevOps 到 NoOps，Serverless 技术的落地方式探讨
Serverless 技术正以一种全新的方式，帮助云上客户进一步节省云的使用成本，实践 NoOps 理念，同时，他也正深刻变革着开发者们的编程模式，所谓“Write locally, compile to the cloud”。
本文将介绍 Serverless 技术来降低云的使用成本和提升运维效率的业务背景和由来，并结合 Serverless 应用引擎(SAE)这款产品来呈现 Serverless 技术的落地方式。
云上业务开发和运维现状
目前，很多客户的上云仍处于资源云化的阶段，以降低资源购置成本为主要驱动力，应用运行在到虚拟化环境中，应用的开发和运维还需要消耗大量的人力。
如上图，在这种模式下，客户除了要完成业务逻辑开发外，还需要完成以下工作：
- 评估系统容量：包括系统总访问量、平均访问量、压测找出单机 QPS、线上冗余情况等等，整个容量评估工作是一个十分复杂的过程；
- 准备基础设施：包括网络拓扑规划，以及ECS 虚拟机资源、外网访问入口SLB、存储资源RDS、NAT等云产品的购买；
- 应用部署：对虚拟机资源进行初始化，需要手动或自建自动化部署流程完成应用部署；如果是微服务形态的应用，还需要考虑注册中心和服务之间的依赖关系管理；
- 系统运维：需要进行系统监控、应用监控，并对异常情况报警，并自建运维体系和运维工具。
痛点分析
系统上线后，随着用户越来越多，系统承载的流量也会越来越大。流量可能会出现规律性的波峰和波谷，也有可能会出现突发大流量的场景，当流量陡增将要或已经超出系统承受能力时，需要系统扩容，而扩容是需要按照容量评估、准备云上资源、应用部署几个流程重新操作一遍，效率较低，可能扩容完成时流量波峰已经过去了，还有可能出现因系统资源不足而造成的系统不可用。当系统流量再正常到正常水位，又会出现资源利用率低的问题，再相应的进行缩容，但缩容的时机很难把握，势必会造成一定的闲置资源的浪费。
那我们期望的系统反馈是什么样的呢？
如上图，我们期望的是，资源需求和实际的资源使用量走势能有一个很好的拟合，能够从容应对突发流量，并且能够有效降低闲置资源成本。为了达到这个目标，系统需要具备哪些能力呢？
- 实时监控和数据分析：做到按需弹性，首先需要对把系统运行和应用运行状态监控起来，并具备监控数据的分析能力；
- 弹性策略设置：提供可配置的弹性策略，并根据应用运行情况设置进行合理的设置；
- 秒级弹性：基于监控数据分析和弹性策略设置，系统可以实现自动弹性的能力，弹性能力越强越好，能达到秒级弹性；
- 细粒度计量：上云的目标是降成本、提效率，因此需要配置细颗粒度的计量计费能力，支持小规格的计算资源配置才能真正达到降本的目的；
- 应用实例能够自动水平扩缩：上面介绍的几种能力都是基于一个前提，应用实例能够自动水平扩缩，这需要应用实例是无状态的或者系统自动维护应用的状态。
上面的几点分析可以提取几个关键词：按需弹性、细粒度计费、实时监控，这正是我们今天需要讨论的 serverless 技术所需要解决的问题，接下来我们看下阿里云现有的4个 serverless 产品形态。
阿里云的 Serverless 产品形态
ECI/Serverless Kubernetes：是面向容器的 Serverless Container，应用的载体是容器镜像，灵活性好，配合调度系统可以支持各种类型应用，无需管理底层基础架构。
函数计算：是面向函数的 Function as a Service，提供了事件驱动的编程方式，用户只需实现函数的处理逻辑，开发效率很高；按照调用量计费，可以根据业务流量平滑调整计算资源，采用 FaaS 最大的挑战是需要改变应用架构和开发交付模型。
Serverless 应用引擎(SAE)：是面向应用的 Serverless 产品，用户不需要要改变应用架构和开发交付模型，只需提供应用实现，无需管理底层计算资源。SAE 提供了优化的弹性策略、支持秒级计费，并且提供了丰富的服务治理能力，可以方便地实现服务的灰度发布、熔断、降级，并与现有CI/CD系统集成。
什么是阿里云Serverless 应用引擎(SAE)
Serverless 应用引擎(SAE)基于神龙裸金属服务器和 ECI 计算资源构建 Kubernetes 集群平台，并实现了多租户管理，在 Runtime 层实现了应用生命周期管理、发布策略管理、弹性伸缩、微服务管理等能力。简单讲，就是面向微服务和其他在线负载提供 Serverless 技术的落地方案。
如上图，SAE 为主流的微服务框架的应用提供了 Serverless 应用托管能力，包括 Spring Cloud、Apache Dubbo 或者阿里云 HSF 框架等，支持多种部署渠道，包括UI、云效、插件等，支持多种部署方式，包括WAR、JAR、镜像等。对于单体应用和采用 Spring Cloud、Dubbo、HSF框架开发的 Java 应用，SAE 支持零代码改造，即可完成迁移。
多租户应用托管能力实现
SAE 基于 Kubetnetes 集群对多用户提供应用托管能力，那 SAE 如何实现多租管理的呢？对于租户的隔离，主要有4个方面，包括系统隔离、数据隔离、服务隔离和网络隔离：
- 系统隔离：基于安全沙箱容器技术的应用运行时环境，拥有独立的内核，能够提供多租户环境下对系统调用、内核的隔离能力；
- 数据隔离：安全容器启动时，通过 devicemapper 在宿主机上提供一个独占的存储空间作为 rootfs；
- 服务隔离：SAE 命名空间是逻辑隔离环境，和微服务级别租户信息（例如T1、T2、T3）绑定，与 K8S 中 namesapce 一一对应，微服务租户信息下发到 K8S Secret 中保存；
- 网络隔离：SAE 命名空间和唯一的 VPC 绑定，底层通过 ENI 网卡打通同一个VPC 网络，实现不同用户的 POD 属于不同网络平台，并且 POD 和宿主机属于不同网络平面，VPC 实现用户专属网络隔离。
核心优势-免IaaS运维
用户只需对网络进行规划，无需管理底层计算资源，完成业务开发后，可以直接通过程序包或者镜像部署应用，极大提高用户开发和运维效率；SAE 对接了多个云产品，如SLB、SLS、NAT等，在应用部署时可以选择使用，可以一站式支持流量访问、日志收集、存储等能力。
核心优势-弹性能力
SAE 支持定时弹性和指标弹性功能，定时弹性适用于资源画像有周期性的应用场景，多用于证券、医疗、政府、教育等行业；指标弹性目前支持 CPU 和内存指标弹性，适用于有突发流量或典型脉冲的应用场景，多用于互联网、游戏、社交平台等行业。
核心优势-一键启停开发测试环境
企业开发测试环境一般晚上不使用，但需要长期保有应用实例，闲置资源成本高。使用 SAE 一键启停功能能够高效管理开发测试环境，按需释放闲置资源，做到节省成本。
产品数据
- 容器启动时长为20s：支持突发场景快速扩容，启动时长指的是 100M 大小的镜像从Pull image 到容器正常启动的耗时，不含应用启动时间。
- 最小实例规格为0.5C1G：支持细粒度资源诉求，0.5C1G 建议用在开发测试环境中；
- 多套环境按需启停，成本可以节省47%~57%：按一套环境 5 台 ECS 每天使用 8 小时，分别针对 ECS 按量付费和包年包月两种情况计算来对比资源成本，方案详情可以查看。
运维体验
ECS 应用部署方案和使用 SAE 进行应用托管方案在运维方面的对比如下：
