深入浅出Serverless：1 Serverless基础

介绍

• 容器技术是这几年IT界的热门话题，各行各业都在研究如何通过容器提升企业软件开发、交付和管理的效率。Docker和Kubernetes的成功使得仅凭几个人也可以轻易管理一个包含上千台机器的庞大的计算集群，并且在这个庞大的集群上部署各种各样的应用。云计算催生了容器技术，而容器技术也改变了云计算
• 我在Red Hat参与了各种类型的容器项目，见证了客户使用容器平台满足其各种各样的需求。容器技术的应用可谓百花齐放，范围涉及微服务、DevOps到最近的人工智能和深度学习
• 过去十多年的云计算的历程，其实是一个“去基础架构”的过程。这个过程让用户可以更快速、更简单、更高效地将想法变成应用，变成在线的服务
• Serverless符合云计算发展的方向，让用户可以将关注点放到具体的业务功能上，而不是底层的计算资源上。Serverless特有的模式存在着潜在的巨大价值。那么，Serverless会取代容器吗？我相信不会。虽然Serverless架构在一些特定的领域会大放异彩，但是容器在未来仍然会是一种重要的应用分发和部署格式。此外容器也将成为许多Serverless平台的基础技术，成为Serverless实现的基石
• 虽然Serverless架构在一些特定的领域会大放异彩，但是容器在未来仍然会是一种重要的应用分发和部署格式。此外容器也将成为许多Serverless平台的基础技术，成为Serverless实现的基石
• Serverless架构即“无服务器”架构，它是一种全新的架构方式，是云计算时代一种革命性的架构模式

什么是Serverless

• 技术圈中的人们一般称呼Serverless为“无服务器架构”。Serverless不是具体的一个编程框架、类库或者工具。简单来说，Serverless是一种软件系统架构思想和方法，它的核心思想是用户无须关注支撑应用服务运行的底层主机。这种架构的思想和方法将对未来软件应用的设计、开发和运营产生深远的影响。
• 所谓“无服务器”，并不是说基于Serverless架构的软件应用不需要服务器就可以运行，其指的是用户无须关心软件应用运行涉及的底层服务器的状态、资源（比如CPU、内存、磁盘及网络）及数量。软件应用正常运行所需要的计算资源由底层的云计算平台动态提供。
• Serverless与传统架构区别
  • 在传统的场景里，当用户完成了应用开发后，软件应用将被部署到指定的运行环境，用户会申请一定数量、一定规格（包含一定数量的CPU、内存及存储空间）的服务器以满足该应用的正常运行。当应用上线后，根据实际的运营情况，用户可能会申请更多的服务器资源进行扩容，以应对更高的访问量
  • 在Serverless架构下，情况则截然不同。当用户完成应用开发后，软件应用将被部署到指定的运行环境，这个运行环境不再是具体的一台或多台服务器，而是支持Serverless的云计算平台。有客户端请求到达或特定事件发生时，云计算平台负责将应用部署到某台Serverless云计算平台的主机中。Serverless云计算平台保证该主机提供应用正常运行所需的计算资源。在访问量升高时，云计算平台动态地增加应用的部署实例。当应用空闲一段时间后，云计算平台自动将应用从主机中卸载，并回收资源
• 结论
  • 在Serverless架构中并不是不存在服务器，而是服务器对用户而言是透明的，不再是用户所操心的资源对象
  • Serverless的实现和软件应用所在的Serverless云计算平台有着很大的关系。用户之所以不用再关注服务器是因为底层的云计算平台完成了大量的自动化工作。这个云计算平台可以是公有云，如Amazon Web Services（AWS）、Microsoft Azure、阿里云或腾讯云，也可以是私有云，如通过OpenStack、Kubernetes结合一些Serverless框架实现

Serverless带来的价值

• 一项技术被广泛认可和采纳的原因往往不是因为这项技术有多新鲜或多酷，最重要的推动力是其能为业务带来巨大的商业或经济价值

• 1.降低运营复杂度

  • Serverless架构使软件应用和服务器实现了解耦，服务器不再是用户开发和运营应用的焦点。在应用上线前，用户无须再提前规划服务器的数量和规格。在运维过程中，用户无须再持续监控和维护具体服务器的状态，只需要关心应用的整体状态

• 2.降低运营成本

  • Serverless的应用是按需执行的。应用只在有请求需要处理或者事件触发时才会被加载运行，在空闲状态下Serverless架构的应用本身并不占用计算资源
  • 在Serverless架构下，用户只需要为处理请求的计算资源付费，而无须为应用空闲时段的资源占用付费。这个特点将为大规模使用公有云服务的用户节省一笔可观的开销

• 3.缩短产品的上市时间

  • 在Serverless架构下，应用的功能被解构成若干个细颗粒度的无状态函数，功能与功能之间的边界变得更加清晰，功能模块之间的耦合度大大减小。这使得软件应用的开发效率更高，应用开发的迭代周期更短

• Serverless架构应用的上市时间（Time To Market，TTM）将大大减少

• 4.增强创新能力

  • 应用的开发和部署效率的提升，使得用户可以用更短的时间、更少的投入尝试新的想法和创意

Serverless的技术实现

• 理念与实现

  • 首先要明确的一点是，Serverless是一种软件的架构理念。它的核心思想是让作为计算资源的服务器不再成为用户所关注的一种资源。其目的是提高应用交付的效率，降低应用运营的工作量和成本。但是，要实现Serverless架构的落地，需要一些实实在在的工具和框架作为有力的技术支撑和基础
  • 目前比较流行的Serverless工具、框架和平台
    • AWS Lambda，最早被大众所认可的Serverless实现
    • Azure Functions，来自微软公有云的Serverless实现
    • OpenWhisk，Apache社区的开源Serverless框架
    • Kubeless，基于Kubernetes架构实现的开源Serverless框架
    • Fission，Platform9推出的开源Serverless框架
    • OpenFaaS，以容器技术为核心的开源Serverless框架
    • Fn，来自Oracle的开源Serverless框架，由原Iron Functions团队开发。

• FaaS与BaaS

  • 目前业界的各类Serverless实现按功能而言，主要为应用服务提供了两个方面的支持：函数即服务（Function as a Service，FaaS）以及后台即服务（Backend as a Service，BaaS）。

• FaaS

  • FaaS提供了一个计算平台，在这个平台上，应用以一个或多个函数的形式开发、运行和管理。
  • 等。FaaS可以根据实际的访问量进行应用的自动化动态加载和资源的自动化动态分配。大多数FaaS平台基于事件驱动（Event Driven）的思想，可以根据预定义的事件触发指定的函数应用逻辑

  • 

    Serverless实现构成

  • FaaS是目前Serverless架构实现的一个重要手段。FaaS平台的特点在很大程度上影响了目前Serverless应用的架构和实现方式。因此，有一部分人认为FaaS等同于Serverless，
  • 目前业界主流的观点是Serverless和FaaS并不是等同关系，FaaS平台是一个完整的Serverless实现的重要组成部分，仅仅通过FaaS平台并不能完全实现Serverless架构的落地。
  • FaaS为应用的开发、运行和管理提供良好的Serverless基础。但是对应用整体系统而言，并没有完全实现Serverless化。因此，在实现应用架构Serverless化时，也应该实现应用所依赖的服务的Serverless化。

• BaaS

  • 为了实现应用后台服务的Serverless化，BaaS（后台即服务）也应该被纳入一个完整的Serverless实现的范畴内。

  • BaaS涵盖的范围很广泛，包含任何应用所依赖的服务。AWS的DynamoDB数据库就是DBaaS的一个例子。用户按需申请使用数据库服务，而无须关注数据库的运维和缩扩容。数据库的运维完全由服务提供方AWS负责。

  • 要实现完整的Serverless架构，用户必须结合FaaS和BaaS的功能，使得应用整体的系统架构实现Serverless化，最大化地实现Serverless架构所承诺带来的价值。因此，一个完整的Serverless实现，必须同时提供FaaS和BaaS两个方面的功能。

Serverless应用架构

• 下面我们通过一个简单的例子观察Serverless架构下的应用与传统架构下的应用的异同
• 传统架构

  • 

    传统应用架构

  • 这是一个常见的传统应用设计和部署架构
• Serverless应用架构
  • Serverless架构下的应用架构图。这个应用实现的功能和前文的应用一样，即为用户提供订单的增删查改服务。应用被部署在Serverless平台之上。应用的功能点变成若干个函数定义，部署于FaaS之中。

  • 

    Serverless应用架构图

• 两种架构的比较
  • 传统架构的应用部署在主机之上，而Serverless架构的应用部署于Serverless平台之上，由Serverless平台提供运行所需的计算资源
  • 传统架构的应用里，所有的逻辑都集中在同一个部署交付件中。Serverless应用的逻辑层部署运行在Serverless平台的FaaS服务之上。因此，应用的逻辑被打散成多个独立的细颗粒度的函数逻辑。因为业务逻辑运行在FaaS服务之上，所以相关的业务逻辑拥有事件驱动、资源自动弹性扩展、高可用等特性。用户也无须运维业务逻辑所消耗的计算资源
  • Serverless架构的应用所依赖的数据库从具体的特定数据库实例，变成了数据库服务。用户无须关注数据库所消耗的计算资源的运维
  • 在Serverless架构下，由于应用的逻辑分散成了若干个函数，推荐通过API网关对这些函数逻辑进行统一的管控（如流量控制、安全管控、版本管理等）。在完备的Serverless平台上，API网关也会作为一种用户可以快速消费的服务而存在
  • 在Serverless架构下，具体的主机资源不再是用户关注的对象，不存于应用架构图中。取而代之的是Serverless平台及其子服务，如FaaS和各类BaaS服务。

Serverless的技术特点

• 按需加载

  • 在Serverless架构下，应用的加载（load）和卸载（unload）由Serverless云计算平台控制。这意味着应用不总是一直在线的。只有当有请求到达或者有事件发生时才会被部署和启动。

• 事件驱动

  • Serverless架构的应用并不总是一直在线，而是按需加载执行。

  • 通过将不同事件来源（Event Source）的事件（Event）与特定的函数进行关联，实现对不同事件采取不同的反应动作，这样可以非常容易地实现事件驱动（Event Driven）架构。

• 状态非本地持久化

  • 应用不再与特定的服务器关联。因此应用的状态不能，也不会保存在其运行的服务器之上，

• 非会话保持

  • 应用不再与特定的服务器关联。每次处理请求的应用实例可能是相同服务器上的应用实例，也可能是新生成的服务器上的应用实例。因此，Serverless架构更适合无状态的应用。

• 自动弹性伸缩

  • Serverless应用原生可以支持高可用，可以应对突发的高访问量。应用实例数量根据实际的访问量由云计算平台进行弹性的自动扩展或收缩，云

• 应用函数化

  • Serverless架构下的应用会被函数化，但不能说Serverless就是Function as a Service（FaaS）。

• 依赖服务化

  • 在Server-less架构下的应用的依赖应该服务化和无服务器化，也就是实现Backend as a Service（BaaS）。所有应用依赖的服务都是一个个后台服务（Backend Service），应用通过BaaS方便获取，而无须关心底层细节。和FaaS一样，BaaS是Serverless架构实现的另一个重要组件。

Serverless的应用场景

• Web应用

  • Serverless架构可以很好地支持各类静态和动态Web应用。

  • 通过FaaS的自动弹性扩展功能，Serverless Web应用可以很快速地构建出能承载高访问量的站点。

  • 举一个有意思的例子，为了应对每5年一次的人口普查，澳大利亚政府耗资近1000万美元构建了一套在线普查系统。但是由于访问量过大，这个系统不堪重负而崩溃了。在一次编程比赛中，两个澳大利亚的大学生用了两天的时间和不到500美元的成本在公有云上构建了一套类似的系统。在压力测试中，这两个大学生的系统顶住了类似的压力。

• 移动互联网

  • Serverless应用通过BaaS对接后端不同的服务而满足业务需求，提高应用开发的效率。

  • 开发者可以通过函数快速地实现业务逻辑，而无须耗费时间和精力开发整个服务端应用。

• 物联网

  • 物联网（Internet of Things，IoT）应用需要对接各种不同的数量庞大的设备。不同的设备需要持续采集并传送数据至服务端。Serverless架构可以帮助物联网应用对接不同的数据输入源。

• 多媒体处理

  • 视频和图片网站需要对用户上传的图片和视频信息进行加工和转换。但是这种多媒体转换的工作并不是无时无刻都在进行的，只有在一些特定事件发生时才需要被执行，比如用户上传或编辑图片和视频时。通过Serverless的事件驱动机制，用户可以在特定事件发生时触发处理逻辑，从而节省了空闲时段计算资源的开销，

• 数据及事件流处理

  • Serverless可以用于对一些持续不断的事件流和数据流进行实时分析和处理，对事件和数据进行实时的过滤、转换和分析，进而触发下一步的处理。比如，对各类系统的日志或社交媒体信息进行实时分析，针对符合特定特征的关键信息进行记录和告警。

• 系统集成

  • Serverless应用的函数式架构非常适合用于实现系统集成。用户无须像过去一样为了某些简单的集成逻辑而开发和运维一个完整的应用，用户可以更专注于所需的集成逻辑，只编写和集成相关的代码逻辑，而不是一个完整的应用。

Serverless的局限

• 控制力

  • 对于一些希望掌控底层计算资源的应用场景，Serverless架构并不是最合适的选择。

• 可移植性

  • Serverless应用的实现在很大程度上依赖于Serverless平台及该平台上的FaaS和BaaS服务。不同IT厂商的Serverless平台和解决方案的具体实现并不相同。

• 安全性

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

• 性能

  • 应用的首次加载及重新加载的过程将产生一定的延时。对于一些对延时敏感的应用，需要通过预先加载或延长空闲超时时间等手段进行处理。

• 执行时长

  • 大部分Serverless平台对FaaS函数的执行时长存在限制。因此Serverless应用更适合一些执行时长较短的作业。

• 技术成熟度

  • 目前Serverless相关平台、工具和框架还处在一个不断变化和演进的阶段，开发和调试的用户体验还需要进一步提升。Serverless相关的文档和资料相对比较少，深入了解Serverless架构的架构师、开发人员和运维人员也相对较少

作者：yeedom
链接：https://www.jianshu.com/p/d7c139144b58
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。