Serverless探秘

概念

Serverless 圈内俗称为“无服务器架构”，它是一种软件系统架构思想和方法，它的核心思想是用户无须关注支撑应用服务运行的底层主机。

所谓“无服务器”，并不是说基于 Serverless 架构的软件应用不需要服务器就可以运行，其指的是用户无须关心软件应用运行涉及的底层服务器的状态、资源（比如 CPU、内存、磁盘及网络）及数量。软件应用正常运行所需要的计算资源由底层的云计算平台动态提供。

 

演化

基础架构即服务（Infrastructure as a Service， IaaS）

↓

容器即服务（Container as a Service，CaaS）

↓

平台即服务（Platform as a Service，PaaS）

↓

软件即服务（Software as a Service，SaaS）

↓

函数即服务（Function as a Service，FaaS）+ 后台即服务（Backend as a Service，BaaS）

↓

Serverless 无服务化

 

业务开发的本质是交付服务和功能——七念。

 

业界进展

 

Top Growing Cloud Services

Place	Service	Growth Rate	2017 Use	2018 Use
#1	Serverless	75%	12%	21%
#2	Container-as-a-service	38%	14%	19%
#3	DBaaS SQL	26%	35%	44%
#4	DBaaS NoSQL	22%	23%	28%

 

大公司

• AWS Lambda，最早被大众所认可的 Serverless 实现。
• Function Compute，阿里云自研的Serverless平台
• Azure Functions，来自微软公有云的 Serverless 实现。
• OpenWhisk，Apache 社区的开源 Serverless 框架。
• Kubeless，基于 Kubernetes 架构实现的开源 Serverless 框架。
• Fission，Platform9 推出的开源 Serverless 框架。
• OpenFaaS，以容器技术为核心的开源 Serverless 框架。
• Fn，来自 Oracle 的开源 Serverless 框架，由原 Iron Functions 团队开发。

 

必要性

诉求

• API
• 调试
• 监控
• 排查
• 性能优化

 

• 数据源合并：接口合并与数据补全
• 数据协议转换
• 中间层：平台间对接差异性磨平
• 数据透传：端侧脏逻辑下沉

 

成本

• 服务器成本

• • 部署策略（多机房）
  • 部署模型（流量均衡）
  • 机器、带宽等成本

• 运维成本

• • 缩扩容（估不准）
  • 治理成本

• • • 机房搬迁
    • OS、基础镜像升级
    • 框架升级
    • 中间件、依赖成绩

• 人力成本
• 机会成本
• ……

服务器成本

现状

68%的应用qpm<50

阿里Node.js应用1600+，BFF应用占约70%，常年水位在10%以下

预期降低成本

按照网上 Serverless 的降低成本率能达到 90% 以上，不过导购业务比较特殊，流量比较大，不像那些需要弹性的应用，根据测算，单进程下函数的性能非常不错，但是由于大促要提前预留一些资源，整体机器成本只降低到了平时的 70%，而在非大促期间，不需要预留这些资源，就能更低，降到 40% 以下。

人力成本&机会成本

 

技术特点

按需加载

在 Serverless 架构下，应用的加载（load）和卸载（unload）由 Serverless 云计算平台控制。这意味着应用不总是一直在线的。只有当有请求到达或者有事件发生时才会被部署和启动。当应用空闲至一定时长时，应用会到达或者有事件发生时才会被部署和启动。当应用空闲至一定时长时，应用会被自动停止和卸载。因此应用并不会持续在线，不会持续占用计算资源。

事件驱动

Serverless 架构的应用并不总是一直在线，而是按需加载执行。应用的加载和执行由事件驱动，比如HTTP请求到达、消息队列接收到新的信息或存储服务的文件被修改了等。通过将不同事件来源（Event Source）的事件（Event）与特定的函数进行关联，实现对不同事件采取不同的反应动作，这样可以非常容易地实现事件驱动（Event Driven）架构。

状态非本地持久化

云计算平台自动控制应用实例的加载和卸载，且应用和服务器完全解耦，应用不再与特定的服务器关联。因此应用的状态不能，也不会保存在其运行的服务器之上，不能做到传统意义上的状态本地持久化。

非会话保持

应用不再与特定的服务器关联。每次处理请求的应用实例可能是相同服务器上的应用实例，也可能是新生成的服务器上的应用实例。因此，用户无法保证同一客户端的两次请求由同一个服务器上的同一个应用实例来处理。也就是说，无法做到传统意义上的会话保持（Sticky Session）。因此，Serverless架构更适合无状态的应用。

自动弹性伸缩

Serverless 应用原生可以支持高可用，可以应对突发的高访问量。应用实例数量根据实际的访问量由云计算平台进行弹性的自动扩展或收缩，云计算平台动态地保证有足够的计算资源和足够数量的应用实例对请求进行处理。

应用函数化

每一个调用完成一个业务动作，应用会被分解成多个细颗粒度的操作。由于状态无法本地持久化，这些细颗粒度的操作是无状态的，类似于传统编程里无状态的函数。Serverless 架构下的应用会被函数化，但不能说 Serverless 就是 Function as a Service（FaaS）。Serverless 涵盖了 FaaS 的一些特性，可以说 FaaS 是 Serverless 架构实现的一个重要手段。

隔离/沙箱

每个应用都在一个独立的沙箱中运行，应用的运行状态不会影响其他应用。

 

局限性

控制力

Serverless 的一个突出优点是用户无须关注底层的计算资源，但是这个优点的反面是用户对底层的计算资源没有控制力。对于一些希望掌控底层计算资源的应用场景，Serverless 架构并不是最合适的选择。

可移植性

Serverless 应用的实现在很大程度上依赖于 Serverless 平台及该平台上的 FaaS 和 BaaS 服务。不同IT厂商的 Serverless 平台和解决方案的具体实现并不相同。而且，目前 Serverless 领域尚没有形成有关的行业标准，这意味着用户将一个平台上的 Serverless 应用移植到另一个平台时所需要付出的成本会比较高。较低的可移植性将造成厂商锁定（Vendor Lock-in）。这对希望发展 Serverless 技术，但是又不希望过度依赖特定供应商的企业而言是一个挑战。

管理

FaaS函数过于分散，不易进行管理，随着应用越来越多，这个现象会越来越严重。

并且不利于集成测试

安全性

在 Serverless 架构下，用户不能直接控制应用实际所运行的主机。不同用户的应用，或者同一用户的不同应用在运行时可能共用底层的主机资源。对于一些安全性要求较高的应用，这将带来潜在的安全风险。

性能

当一个 Serverless 应用长时间空闲时将会被从主机上卸载。当请求再次到达时，平台需要重新加载应用。应用的首次加载及重新加载的过程将产生一定的延时。对于一些对延时敏感的应用，需要通过预先加载或延长空闲超时时间等手段进行处理。（尤其是深度学习算法相关的初始化过程）

执行时长

Serverless 的一个重要特点是应用按需加载执行，而不是长时间持续部署在主机上。目前，大部分 Serverless 平台对 FaaS 函数的执行时长存在限制。因此 Serverless 应用更适合一些执行时长较短的作业。

技术成熟度

虽然 Serverless 技术的发展很快，但是毕竟它还是一门起步时间不长的新兴技术。因此，目前 Serverless 相关平台、工具和框架还处在一个不断变化和演进的阶段，开发和调试的用户体验还需要进一步提升。Serverless 相关的文档和资料相对比较少，深入了解 Serverless 架构的架构师、开发人员和运维人员也相对较少。

 

难点

监控

监控应用的运行状态，调用次数、运行时长、占用资源等

调度

动态伸缩

冷启动