内容介绍：

一、SERVERLESS 发展历程

二、SAE产品介绍

三、SAE是怎么收费的？

四、SAE典型使用案例

 

 

 

 

1.SERVERLESS 发展历程

首先先了解serverless的发展历程以及什么是serverless。

1.1 serverless的发展历程

Serverless是云计算发展的一个阶段。无论是自己在家在公司部署还是租电信的机房，最开始使用服务器都是通过物理机的方式。后来出现了虚拟机例如阿里云的ECS、AWS等等都属于云主机虚拟机形式，这种类似于IDC使用方式，只不过是云上的机器。后来docker、k8s出现，这种容器化方式成为主流。整个计算进入容器化时代。Serverless是容器后的一个阶段。

此时可以将云计算分为两个阶段：开始属于1.0，到了容器和serverless属于2.0，serverless是容器的进阶。Serverless与容器的最大区别是使用serverless后对于用户不需要关系下面的底层，具体形式后续讲解。总之serverless是云计算的一个发展历程，现在已经逐渐从一个小众新鲜的概念成为一个主流的应用方式。

1.2 什么是serverless

最开始是由berkeley博士提出的概念，后续经过各种云厂商和研究院进行总结，有一个形象的比喻。

如果把物理机形容成私家车，serverless就是打网约车。使用物理机相当于该台机器一次性付费购买后，机器就属于自己，但是在使用这台服务器的同时还需要为油、保养、维修负责。所以这辆车所有东西都需要关心。到了虚拟机阶段，类似于租车，租车每月花费一千租后，不需要关心这台车的维修和保养。只需要为租车的钱进行付费即可。到了serverless阶段，形容为网约车。可以在打网约车的时间内完成目的行程后放弃使用该车。

计算资源类似，运行一个程序或网站、任务，需要时间为十分钟或一个小时，运行完该资源。目的达到后就可以释放资源，不需要进行付费。

所以serverless有四个特点。

第一不需要管理资源，资源由平台进行负责。第二自动弹性，在需要时弹出资源，不需要时自动缩资源，只需要为自己使用的资源付费，无需为空余闲置的资源进行买单。第三聚焦业务价值，结合前面的能力后，对于用户不需要再关心基础设施，只需要关心自己的业务代码。

1.3典型serverless高可用架构

前面通过负载均衡ALB与公网进行联通。下面是serverless的实例，其中的数量都根据自己的业务来定。PolarDB所有的数据库和计算资源都根据业务当前的流量和负载自动进行弹性伸缩。为了保证一些可靠性，采用了多可用区的部署。这是一个简单的serverless架构。在该架构中，中间的计算由原来的云主机换成了ICE，数据库从原来的买断制的数据库换成了serverless数据库，架构上差别不大。

1.4传统架构和serverless架构对比

serverless架构的优势是资源高效利用，如果是unioncs为了保证高可用，至少需要两台服务器，只需要一个serverless实例即可。因为根据流量和使用负载来弹，所以能保证非常高的资源利用率，不需要运维机器，不需要为机器做一些复杂的调度或定义一些复杂的规则，全由平台复杂，这就是serverless架构相对于传统架构的优势。

 

2.SAE产品介绍

在该架构下介绍一个产品SAE。这是serverless计算的一个产品。上述的架构图中可以看到有一个polardb serverless数据库的产品，本节主要讲SAE的产品。

2.1serverless平台

传统的IaaS层上有我们自己做的k8s群以及一些微服务、应用监控、全套的应用生命周期管理、自动伸缩、日志等等。与传统架构相比，如果使用传统的云主机只有该层，在该层网上都需要用户自己搭建k8s集群，做自己的日志、监控、CICD。现在使用SAE，该层都由平台提供，只需要关注自己的业务进行部署即可。

 

2.2SAE优势

通过几个图来看，例如云主机包了一年，这一年是方的，是需要付的钱，每天每小时都需要付费。虽然是提前付过钱，但是流量、资源的消耗都有周期和波动，在不需要时还需要付费，这就是云主机。到了k8s后有弹性，但是弹性较复杂，弹性的颗粒度不低，相对较粗。虽然资源利用率提高，但是还不够。到了serverless阶段，资源的曲线与实际业务的曲线基本贴合，资源利用率最高。

甚至在一些web应用上，还可以做到：正常只有一个实例在运行，但是此时没有流量，可以不需要为cpu付费，只需要为内存付费，进一步节省了用户的费用。如果将最小实例设为0，在长期没有请求的情况下，整个实例都不计费，在这段时间内都不付费。但是当流量进入后会自动抬起实例。这就是极致的弹性和极致的省钱，这就是serverless在弹性方面的一些能力。

如果使用ECS来建一套自己的项目或应用，需要先购买ECS，创建自己的集群做初始化，部署环境、部署代码、搭建监控、做日志等等，之后还需要进行运维。整体是从一个零到整体业务上线需要花费很多时间和能力。如果使用SAE，资源方面可以节省，所有资源由平台提供，只需要将代码部署在SAE上，运维阶段也由平台进行解决。七步直接缩减到一步。在SAE上部署一个应用，熟练的用户可以达到分钟级。

很多用户在云上使用或在SAE上跑自己的业务，那如何将业务迁移呢？举例ECS。如果在ECS上，用传统的ECS架构，用OSS、MQ、日志等等。在迁移时只需要将应用在SAE上重新部署，其它挂在ECS上的产品现在挂到SAE上，迁移非常平滑，不需要修改代码。

下面介绍一个实用的功能，能够直接节省成本和费用。

无论做什么业务都有自己的一套测试环境，有的企业会有预发的多套的测试环境，这些测试环境和生产环境的不同在于：下班时间没有人使用。如果将机器保留，这部分资源会被浪费，如果使用SAE，可以一键开启或关闭测试环境。通过这种简单的操作，可以节省测试部分的成本，在晚上或下班时间不需要付费。

原来使用CICD方案，现在迁移到SAE上需要怎么做？SAE提供了完善的持续集成解决方案，例如jenkins或云效、Gitlab等。迁移到SAE上后与原来的使用方式相同，对于工具链的支持很丰富，不会影响到工作习惯。

基于一些公司自己的生产实践，做了一些SAE的应用托管功能，例如灰度发布、金丝雀发布、流量发布等等，都可以SAE控制台上进行操作。不需要关心，只需要配置好自己的配置就能自动执行。

弹性策略是SAE的核心。SAE支持很多丰富的弹性策略，例如指标，可以根据自己的CPU内存、QPS、RT等指标做自己的弹性策略，适用于突发流量场景。事先不会预知流量的脉冲和高峰，所以通过指标进行。如果业务比较规律，在几点到几点会有用户，就可以用定时来提前拉取资源。对于一些复杂的情况也可以将指标弹性和定时弹性结合，称为混合弹性，可以解决绝大部分的用户场景。

可观测方面也做了一些应用监控、基础的监控能力，在SAE上都支持，也不需要付费。如果对于应用或容器的监控有较深需求，可以开通arms高级版。由arms提供能力，与arms进行对接，在SAE控制台上就可以进行操作。

一些企业配套的能力也很丰富，例如企业分账。在公司中有不同的团队来用一个账号，需要量化区分每个团队花费的金额和资源。可以用到企业分账的能力，将不同部门的账单费用进行区分。

 

3.SAE是怎么收费的？

SAE有四个收费项，两个是主要的，两个是次要的。

主要是CPU和内存，对应ECS。如果购买4核16g，在SAE上是根据消耗的内存和cpu来计算费用。例如一个4核16g的实例运行了2秒，就计算2s内跑的资源。请求数和流量是次要收费项。针对于web应用，如果使用SAE2.0拓宽应用，会收取请求数和流量的费用。如果是微服务则不需要付费。请求是根据请求数，流量是根据公网的出流量。

四个计费项上提供了两种计费方式，一种是后付费，完全按量计费，使用多少出账单付费。一种是预付费，提前买好资源包，当使用时优先抵扣资源包中的资源，抵扣完后再去按量收费，折扣更低。资源包越大，时间越长，折扣越低。

那么ECS和SAE如何选择呢？价格如何比对？

SAE这种serverless形态的产品，需要结合弹性使用。如果业务是24小时都跑满，ECS更便宜。

如果有弹性，不需要时刻都跑，一天只用几个小时，使用SAE更便宜。如果使用按量计费，每天跑16个小时或小于16个小时，使用SAE更划算。

如果使用资源包，单价更低，范围更大，每天需要跑20个小时，每天空余时间大于4个小时，那么使用SAE会更便宜。实际操作中需要根据自己的业务判断。在ECS上跑一个大的机器，在SAE上跑同规格价钱会高。

在实际操作中可以拆分成更多的小时进行跑，按小规格实例进行跑业务。

 

4.SAE典型使用案例

下面介绍SAE使用的案例。

4.1极氪商业智能平台server less实践效果

极氪汽车有一套大数据的商业智能平台。该平台支撑了整个极氪的商业业务和重要决策，将BI的应用跑在SAE上，后端与数仓和实时计算等连接。在SAE上加了应用监控、日志服务、微服务的治理等等，结合这些产品后，形成了一套完整的云原生架构，帮助实现了以下几方面。

一是分钟级业务的接入。极氪团队内部经常会有新业务和新应用继续上线，如果使用SAE就可以利用简单的CICD能力以及应用部署过程，几分钟内接入上线新业务或发布服务。在serverless弹性架构中，帮助它们实现了整个系统的SLA达到了99.99%。

4.2互娱行业-南瓜电影7天内server less化

南瓜电影是会员制的网站。客户原来使用的是ECS，后续采用SAE。SAE可以帮助该公司在7天之内将业务全部迁移。

 

4.3金融服务-视野数科SAE+jenkins打造云原生devops

视野数科将自己的一些BI平台跑在SAE上，再通过SAE为用户提供服务。该客户的特点是不需要24小时流量平均，平常流量很小，所以SAE帮助解决该问题。视野数科是一家金融公司，所以技术人员更多是金融背景。在IT或云计算领域没有人力，无法投入很大人力维持一个IT团队，所以SAE平台可以很好解决基础设施的运维和建设问题。

4.4消费电子：SKG基于SAE建构敏捷、弹性云原生系统架构

SKG将自己的渠道中台跑在SAE上。该用户更多需要提升自己的开发效率，内部有一套自身的devops系统，与SAE做对接后可以显著提升开发效率。测算大概能够帮助SKG提升70%，成本也能够降低60%。

可以看到，用SAE的客户大部分基于三个考虑：

一是弹性，它们的业务上有突发或周期性的流量或负载区别，SAE可以显著降本。

二是经常会有一些不可预知的极高流量的冲击，SAE的弹性能够保证业务的可用。

三是在应用的生命周期管理和CICD、应用监控上的一些能力能够帮助用户显著提升研发效率，不需要再关心基础设施，只需要做自己的业务即可。

以上介绍了SAE产品以及serverless的解决方案。