【博客411】serverless概念学习

内容：记录对serverless概念的学习

云时代的变化：

云计算类型：

公有云 Public Cloud：由某一机构，公司管理并对公众开放使用的云计算

私有云 Private Cloud：在单个的机构中通过虚拟化共享出来的IT基础设施

混合云 Hybird Cloud：公有云和私有云的混合

云计算服务类型：

传统：

IaaS：Infrastructure as a Service
基础设施即服务–提供计算，存储，网络等功能的基本资源

PaaS：Platform as a Service
平台即服务–提供将定制的应用部署到云上的平台

SaaS：Software as a Service
软件即服务–结合了基础设施和软件并且运行在云端

新兴：

FaaS：Function as a Service
函数即服务–基于FaaS的应用将会以“无服务器（serverless）的形式部署，这些代码会完全在云计算提供商的平台计算设施上运行。
使用FaaS平台，无需管理任何服务器基础设施，只需支付执行函数所需的计算周期。

CaaS：Container as a Service
容器即服务–使用容器即服务模型，开发人员将微服务作为便携式虚拟容器（如Docker或rkt）进行构建并部署到云供应商的云计算平台。
与IaaS模型不同，使用IaaS的开发人员必须管理部署容器的虚拟机，而CaaS则是将服务部署在轻量级的虚拟容器中。
云供应商会提供运行容器的虚拟服务器，以及用于构建，部署，监控和伸缩容器的综合工具。

serverless：

Serverless是一种构建和管理基于微服务架构的完整流程，允许你在服务部署级别而不是服务器部署级别来
管理你的应用部署。它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态（Stateless）、暂存
（可能只存在于一次调用的过程中）计算容器内。构建无服务器应用程序意味着开发者可以专注在产品代码上，而无须管理
和操作云端或本地的服务器或运行时。Serverless真正做到了部署应用无需涉及基础设施的建设，自动构建、部署和启动服务。

serverless与faas，baas：

Serverless由开发者实现的服务端逻辑运行在无状态的计算容器中，它由事件触发， 完全被第三方管理，其业务层面的状态
则被开发者使用的数据库和存储资源所记录。Serverless涵盖了很多技术，分为两类：FaaS和BaaS。

1、FaaS（Function as a Service，函数即服务）
FaaS意在无须自行管理服务器系统或自己的服务器应用程序，即可直接运行后端代码。

FaaS可以取代一些服务处理服务器（可能是物理计算机，但绝对需要运行某种应用程序），这样不仅不需要自行供应服务器，
也不需要全时运行应用程序。

FaaS产品不要求必须使用特定框架或库进行开发。在语言和环境方面，FaaS函数就是常规的应用程序。
因此可以使用任何语言，只要能编译为Unix进程即可。FaaS函数在架构方面确实存在一定的局限，尤其是在状态和执行时间方面。

在迁往FaaS的过程中，唯一需要修改的代码是“主方法/启动”代码，其中可能需要删除顶级消息处理程序的相关代码
（“消息监听器接口”的实现），但这可能只需要更改方法签名即可。
在FaaS的世界中，代码的其余所有部分（例如向数据库执行写入的代码）无须任何变化。

相比传统系统，部署方法会有较大变化 – 将代码上传至FaaS供应商，其他事情均可由供应商完成。
目前这种方式通常意味着需要上传代码的全新定义（例如上传zip或JAR文件），随后调用一个专有API发起更新过程。

FaaS中的函数可以通过供应商定义的事件类型触发。对于亚马逊AWS，此类触发事件可以包括S3（文件）更新、
时间（计划任务），以及加入消息总线的消息（例如Kinesis）。通常你的函数需要通过参数指定自己需要绑定到的事件源。

大部分供应商还允许函数作为对传入Http请求的响应来触发，通常这类请求来自某种该类型的API网关（例如AWS API网关、Webtask）。

2、BaaS（Backend as a Service，后端即服务）
BaaS（Backend as a Service，后端即服务）是指我们不再编写或管理所有服务端组件，可以使用领域通用的远程组件
（而不是进程内的库）来提供服务。

首先BaaS并非PaaS，它们的区别在于：PaaS需要参与应用的生命周期管理，BaaS则仅仅提供应用依赖的第三方服务。
典型的PaaS平台需要提供手段让开发者部署和配置应用，例如自动将应用部署到Tomcat容器中，并管理应用的生命周期。
BaaS不包含这些内容，BaaS只以API的方式提供应用依赖的后端服务，例如数据库和对象存储。
BaaS可以是公共云服务商提供的，也可以是第三方厂商提供的。

BaaS服务还允许我们依赖其他人已经实现的应用逻辑。对于这点，认证就是一个很好的例子。
很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码，而对于不同的应用这些代码往往大同小异。
完全可以把这些重复性的工作提取出来，再做成外部服务。它们能实现全面的认证和用户管理，开发团队再也
不用自己编写或者管理实现这些功能的代码。

faas特征：

1、FaaS运行的是后端代码而不是整个后端程序

2、代码通过事件触发：
由于不再有一个长期运行的进程等待或轮询用户请求，代码只能通过特殊的事件触发。
这些事件由FaaS框架定义，例如上传文件到对象存储、消息队列收到一条新的消息、API Gateway收到一个新的API请求等。

3、代码的生命周期需要很短：
例如我们的AI应用，从收到事件后Function Handler被调用开始，到调用返回结束，不会有常驻内存的进程运行。
此外公共云提供商还会限制代码执行的时间，超出时间后执行代码的进程会被强行销毁。例如AWS的Lambda可执行的最长时间为5分钟。

4、代码必须做到彻底无状态：
两次调用间不能共享内存状态。我们的AI应用最早使用了一个全局变量统计处理的图片数，
每处理完一张图片该计数器就加一。使用FaaS后我们不能再用任何全局变量或内存数据结构（例如Hashmap）在调用间共享数据，
因为代码运行在独立的进程中，无法访问对方的内存地址空间。
可以对代码进行了改造，将全局计数器放到了公共云的Redis服务中，这为代码增加了额外的复杂性。

5、出色的水平扩展能力：
aaS会为每个事件和请求运行一份新的代码。
应用的部署方式从上传、配置整个程序变成上传一份打包代码的文件（例如Jar文件或一个Zip文件）

serverless应用场景：

场景一：应用负载有显著的波峰波谷

一个公司的业务负载具有波峰波谷时，机器资源要按照峰值需求预估；
而在波谷时期机器利用率则明显下降，因为不能进行资源复用而导致浪费。

当自有机器的利用率低时，使用 Serverless 后会有显著的效率和性价比提升。对于云服务厂商，在具备了足够多的用户之后，
各种波峰波谷叠加后平稳化，聚合之后资源复用性更高。

比如，外卖企业负载高峰是在用餐时期，安防行业的负载高峰则是夜间，这是受各个企业业务定位所限的；
而对于一个成熟的云服务厂商，如果其平台足够大，用户足够多，是不应该有明显的波峰波谷现象的。

场景二：典型用例 - 基于事件的数据处理

视频处理的后端系统，常见功能需求如下：视频转码、抽取数据、人脸识别等，这些均为通用计算任务，可由函数计算执行。

开发者需要自己写出实现逻辑，再将任务按照控制流连接起来，每个任务的具体执行由云厂商来负责。如此，开发变得更便捷，并且构建的系统天然高可用、实时弹性伸缩，用户不需要关心机器层面问题。

Serverless 的优缺点：

# 优点：
对于企业来说，支持Serverless计算的平台可以节省大量时间和成本，同时可以释放员工，让开发者得以开展更有价值的工作，
而不是管理基础设施。另一方面可以提高敏捷度，更快速地推出新应用和新服务，进而提高客户满意度。

# 缺点：

1、不适合长时间运行应用
Serverless 在请求到来时才运行。这意味着，当应用不运行的时候就会进入 “休眠状态”，下次当请求来临时，
应用将会需要一个启动时间，即冷启动时间。如果你的应用需要一直长期不间断的运行、处理大量的请求，
那么你可能就不适合采用 Serverless 架构。如果你通过 CRON 的方式或者 CloudWatch 来定期唤醒应用，
又会比较消耗资源。这就需要我们对它做优化，如果频繁调用，这个资源将会常驻内存，第一次冷启之后，
就可以一直服务，直到一段时间内没有新的调用请求进来，则会转入“休眠”状态，甚至被回收，从而不消耗任何资源。

2、完全依赖于第三方服务
当你所在的企业云环境已经有大量的基础设施的时候，Serverless 对于你来说，并不是一个好东西。
当我们采用某云服务厂商的 Serverless 架构时，我们就和该服务供应商绑定了，那么我们再将服务迁到别的云服务商上就没有那么容易了。

我们需要修改一下系列的底层代码，能采取的应对方案，便是建立隔离层。这意味着，在设计应用的时候，就需要隔离 API 网关、
隔离数据库层，考虑到市面上还没有成熟的 ORM 工具，让你既支持Firebase，又支持 DynamoDB等等。
这些也将带给我们一些额外的成本，可能带来的问题会比解决的问题多。

3、缺乏调试和开发工具

每次你调试的时候，你需要一遍又一遍地上传代码。而每次上传的时候，你就好像是在部署服务器，并不能总是快速地定位出问题在哪。

4、构建复杂
Serverless 很便宜，但是这并不意味着它很简单。他的构建过程需要完善的配置项目非常多

Serverless为我们带来了什么：

1、让我们可以专注于核心业务：
对比传统架构，用Serverless架构改写的AI应用具有显著的优势。我们不再运维任何云主机和操作系统，甚至不再运维Tomcat这样的Web容器，
只需要专注于代码本身，所有配置、应用生命周期管理的工作都由FaaS框架负责。
公共云的出现让我们从物理硬件管理中解放出来，Serverless架构让我们进一步从操作系统管理中解放出来，第一次真正专注于核心业务。

2、业务也变得更加敏捷:
我们只需要编写核心业务相关的代码，例如AI应用中图像识别的部分。无需编写任何加载、部署、配置应用的代码，
例如不再需要配置systemd在系统启动时加载应用。

3、水平扩展也不是问题：
FaaS框架会为每一个事件、每一个API请求都启动一份新的进程执行代码。这跟传统应用的线程池方式类似，
每个请求都在一个单独的线程中执行，区别在于线程之间共享同一内存地址空间，FaaS的进程间不共享任何内存。
与线程池有最大线程数限制类似，FaaS框架通常也限制了最大进程数，也就是说我们的AI应用最多能在我们规定的数量的进程中同时执行。

4、Serverless架构为我们节省了大量开支：
我们只需为AI应用运行的时间付钱，无需为应用等待请求的时间付钱。水平扩展的粒度从原来的云主机细化到进程，节省了额外的开支，
不用再购买闲置的云主机来抵消Auto-Scaling的配置不精确带来的影响。业务的敏捷性提高也降低了营运成本，我们不再需要精通
操作系统配置和管理的营运人员，不仅节省了人力成本，也节省了应用从开发到上线的时间。

Serverless的局限及适用场景：

为每个事件/请求启动一个全新的进程运行代码是FaaS的核心，进程的启动延时是Serverless面临的第一个问题。
取决于编写应用的语言，启动延时可以是10毫秒（如简单的Python应用），也可以是1分钟（复杂的Java应用）。
这样的延时对于realtime的程序是难以接受的。

目前Serverless应用通常运行在公共云的多租户环境中，启动延时还受系统负载影响，很难保证应用在规定时间内被运行。
公共云提供商目前没有对Serverless提供相应的SLA保证。

Serverless无法用于高并发应用，为每个请求启动一个进程开销太高。例如双十一支付宝高峰期每秒处理的交易数为8.59万笔，
如果使用Serverless架构，意味着我们的系统内每秒有8.59万个进程被创建又被销毁，这是难以负担的开销。

Serverless应用无法常驻内存，运行的时间是受限的。如果你的应用无法在数分钟内完成的工作，那Serverless不是你的选择。
这对程序设计提出了挑战，例如我们的AI应用必须优化到在5分钟内完成复杂图像的识别。我们也不能编写执行长时间IO操作的应用

Serverless调用之间不能共享状态让编写复杂程序变得极度困难。但Serverless将无状态进行的更加彻底，在不同的调用之间无法
共享内存状态，例如使用hashmap。我们的AI应用中统计已处理图片总数的全局计数器在传统架构中只是一个全局变量，
但在Serverless架构中它变成存储在内存数据库（Redis）中的一条记录，更新成本、保证原子性等因素让我们的编码变得数倍复杂。
对于大多云原生的互联网应用来说，这种彻底的无状态架构是一个巨大的挑战，而对于动辄有几十万、上百万行代码的、
充满了状态的企业应用来说，Serverless的无状态改造几乎是一个无法完成的任务。

业务拆分问题。熟练的微服务的架构师，对将业务拆分成一个个单独的服务非常熟悉，也有不少的经典书籍
（例如《Building Microservices: Designing Fine-Grained Systems》）指导我们如何做。但即使是他们，
在面对Serverless架构时也会感到头痛，如何将业务拆分成成百上千个运行在独立进程、运行时间受限的函数是巨大的挑战。
而是否需要如此细粒度的拆分是需要回答的第一个问题。有些问题或许变成无解难题又或成本极高，例如分布式数据库事务。


由于一些局限性，Serverless架构不会成为复杂应用的架构首选，相反，它应该是云端小程序的未来。

云端的应用有大量的小程序场景，例如识别一张图片、对一段音频/视频进行编解码、对IOT设备的请求返回一小段数据、
将客户提交的工单通过邮件通知客服人员等等。这些基于事件触发的小程序在传统架构中实现起来是相对复杂的，
你往往需要为20%的核心业务运营80%的支撑业务。Serverless完美的解决了这些问题。
我们可以将无状态的、事件触发的业务拆分成Serverless应用，让整个架构变得更加的简洁和高效。

Serverless不是传统的PaaS：

Serverless由BaaS和FaaS两部分构成，BaaS负责提供业务的依赖服务，FaaS负责业务的部署和生命周期管理

传统PaaS是以程序为粒度管理应用的生命周期，而Serverless是以函数粒度管理应用生命周期

传统PaaS中的应用为常驻内存的进程，而Serverless应用运行完即销毁

传统PaaS，用户仍需要关心水平扩展，但Serverless没有这个问题，水平扩展是serverless架构天然自带的功能。

serverless与faas，baas示意图：

serverless与k8s示意图：

serverless与faas，baas，k8s示例图：