关于云计算:5-大场景深度探讨何为-Serverless-架构模式

40次阅读

共计 5381 个字符,预计需要花费 14 分钟才能阅读完成。

作者 | Hongqi 阿里云高级技术专家

到底什么是 Serverless 架构?

什么是 Serverless 架构?依照 CNCF 对 Serverless 计算的定义,Serverless 架构应该是采纳 FaaS(函数即服务)和 BaaS(后端服务)服务来解决问题的一种设计。这个定义让咱们对 Serverless 的了解稍显清晰,同时可能也造成了一些困扰和争执。

  • 随着需要和技术的倒退,业界呈现了一些 FaaS 以外的其它状态的 Serverless 计算服务,比方 Google Cloud Run,阿里云推出的面向利用的 Serverless 利用引擎服务以及 Serverless K8s,这些服务也提供了弹性伸缩能力和按应用计费的免费模式,具备 Serverless 服务的状态,能够说进一步扩充了 Serverless 计算的营垒;
  • 为了打消冷启动影响,FaaS 类服务如阿里云的函数计算和 AWS 的 Lambda 相继推出了预留性能,变得不那么“按应用付费”了;
  • 一些基于服务器(Serverful)的后端服务也推出了 Serverless 状态产品,比方 AWS Serverless Aurora,阿里云 Serverless HBase 服务。

这样看来,Serverless 的界限是有些含糊的,诸多云服务都向着 Serverless 方向演进。一个含糊的货色如何领导咱们解决业务问题呢?Serverless 有一个基本的理念是始终没有扭转的,即让用户最大化地专一业务逻辑,其它的特色如不关怀服务器、主动弹性、按应用计费等,都是为了实现这个理念而服务。

驰名的 Serverless 实践者 Ben Kehoe 这样形容 Serverless 原生心智,当咱们在业务中思考做什么时能够领会一下这种心智:

  • 我的业务是什么?
  • 做这件事件能不能让我的业务超群绝伦?
  • 如果不能,我为什么要做这件事件而不是让他人来解决这个问题?
  • 在解决业务问题之前没有必要解决技术问题。

在实际 Serverless 架构时,最重要的心智不是抉择哪些风行服务和技术,攻克哪些技术难题,而是时刻将专一业务逻辑铭记在心,这样更容易让咱们抉择适合的技术和服务,明确如何设计利用架构。人的精力是无限的,组织的资源是无限的,Serverless 的理念能够让咱们更好地用无限的资源解决真正须要解决的问题,正是因为咱们少做了一些事件,转而让他人做这些事件,咱们才能够在业务上做的更多。

接下来咱们介绍一些常见的场景,并探讨如何应用 Serverless 架构反对这些场景。咱们次要会采纳计算、存储和音讯通信等技术来设计架构,从可运维性、安全性、可靠性、可扩展性、老本几个角度来掂量架构的优劣。为了让这种探讨不过于形象,咱们会用一些具体的服务作为参考,然而这些架构的思维是通用的,能够用其它相似产品实现。

场景 1: 动态 Web 站点

如果咱们要做一个信息展现的网站,需要很简略,就像早年的中国黄页那样,信息更新很少,大略有以下几种次要抉择:

  • 买台服务器放在 IDC 机房里托管,运行站点;
  • 去云厂商上买台云服务器运行站点,为了解决高可用的问题又买了负载平衡服务和多个服务器;
  • 采纳动态站点形式,间接由对象存储服务(如 OSS)反对,并应用 CDN 回源 OSS。

这三种形式由云下到云上,由治理服务器到无需治理服务器,即 Serverless。这一系列的转变给使用者带来了什么变动呢?前两种计划须要估算,须要扩大,须要实现高可用,须要自行监控等,这些都不是马老师当年想要的,他只想去展现信息,让世界理解中国,这是他的业务逻辑。Serverless 正是这样一种理念,最大化地让人去专一业务逻辑。第三种形式就是采纳了 Serverless 架构去构建一个动态站点,它有其它计划无法比拟的劣势,比方:

  • 可运维性:无需治理服务器,比方操作系统的安全补丁降级、故障降级、高可用性,这些云服务(OSS,CDN)都帮着做了;
  • 可扩展性:无需对资源做预估和思考将来的扩大,因为 OSS 自身是弹性的,应用 CDN 使得零碎提早更小、费用更低、可用性更高;
  • 老本:按理论应用的资源付费,包含存储费用和申请费用,没有申请时不收取申请费用;
  • 安全性:这样一个零碎甚至看不到服务器,不须要通过 SSH 登录,DDoS 攻打也交给云服务来解决。

场景 2: 单体和微服务利用

动态页面和站点适宜用于内容少、更新频率低的场景,反之,就须要动静站点了。比方淘宝的商品页面,采纳动态页面形式治理商品信息是不事实的。如何依据用户申请动静地返回后果呢?咱们来看两种常见的解决方案:

  • Web 单体利用:所有的应用逻辑都在一个利用中实现,联合数据库,这种分层架构能够疾速实现一些复杂度较低的利用;
  • 微服务利用:随着业务倒退,性能多了,访问量高了,团队大了,这时候个别就须要将单体利用中的逻辑拆分成多个执行单元,比方商品页面上的评论信息、售卖信息、配送信息等,都能够对应一个独自的微服务。这种架构的益处是每个单元是高度自治的,易于开发(比方应用不同技术)、部署和扩大。然而这种架构也引入了分布式系统的一些问题,如服务间通信的负载平衡、失败解决等。

处在不同阶段不同规模的组织能够抉择适宜本身的形式,来解决它面临的首要业务问题,淘宝最后被人们承受肯定不是因为它应用了哪种技术架构。然而无论抉择哪种架构,下面提到的 Serverless 原生心智都有助于咱们专一业务。比方:

  • 是否须要本人购买服务器装置数据库,实现高可用、治理备份、降级版本等,还是能够把这些事件交给托管的服务如 RDS;是否能够应用表格存储、Serverless HBase 等 Serverless 数据库服务,实现按应用的弹性扩容缩容和付费;
  • 单体利用是须要本人购买服务器运行,还是能够交给托管服务,如函数计算和 Serverless 利用引擎;
  • 是否能够通过函数来实现轻量级微服务,依赖函数计算提供的负载平衡、主动伸缩、按需付费、日志采集、系统监控等能力;
  • 基于 Spring Cloud、Dubbo、HSF 等实现的微服务利用是否须要本人购买服务器部署利用,治理服务发现,负载平衡,弹性伸缩,熔断,系统监控等,还是能够将这些工作交给诸如 Serverless 利用引擎服务。

上图右侧的架构引入了 API 网关、函数计算或者 Serverless 利用引擎来实现计算层,将大量的工作交给了云服务实现,让用户最大水平上专一实现业务逻辑。其中零碎外部多个微服务的交互如下图所示,通过提供一个商品聚合服务,将外部的多个微服务对立出现给内部。这里的微服务能够通过 SAE 或者函数实现。

这样的架构还能够持续扩大,比方如何反对不同客户端的拜访,如上图右侧所示。事实中这种需要是常见的,不同的客户端须要的信息可能是不同的,手机能够依据地位信息做相干举荐。如何让手机客户端和不同浏览器都能受害于 Serverless 架构呢?这又牵扯出了另一个词——Backend for fronted(BFF),即为前端定做的后端,这受到了前端开发工程师的推崇,Serverless 技术让这个架构宽泛风行,因为前端工程师能够从业务角度登程间接编写 BFF,而无需治理服务器相干的令前端工程师更加头疼的事件。更多实际能够参见:基于函数计算的 BFF 架构。

场景 3: 事件触发

后面提到的动静页面生成是同步申请实现的,还有一类常见场景,其中申请解决通常须要较长时间或者较多资源,比方用户评论中的图片和视频内容治理,波及到如何上传图片和解决图片(缩略图、水印、审核等)及视频,以适应不同客户端的播放需要。

如何对上传多媒体文件实时处理呢?这个场景的技术架构大体经验了以下演变:

  • 基于服务器的单体架构:多媒体文件被上传到服务器,由服务器解决,对多媒体的显示申请也由服务器实现;
  • 基于服务器的微服务架构:多媒体文件被上传到服务器,服务器解决转存到 OSS,而后将文件地址退出音讯队列,由另一组服务器解决文件,将处理结果保留到 OSS,对多媒体的显示申请由 OSS 和 CDN 实现;
  • Serverless 架构:多媒体间接上传到 OSS,由 OSS 的事件触发能力间接触发函数,函数处理结果保留到 OSS,对多媒体的显示申请由 OSS 和 CDN 实现。

基于服务器的单体架构面临以下问题:

  • 如何解决海量文件?单台服务器空间无限,购买更多的服务器;
  • 如何扩大 Web 应用服务器?Web 应用服务器是否适宜 CPU 密集型工作?
  • 如何解决上传申请的高可用?
  • 如果解决显示申请的高可用?
  • 如何应答申请负载的波峰波谷?

基于服务器的微服务架构很好地解决了上述的大部分问题,然而依然面临一些问题:

  • 治理应用服务器的高可用性和弹性;
  • 管理文件解决服务器的弹性;
  • 治理音讯队列的弹性。

而第三种 Serverless 架构很好地解决了上述所有问题。开发人员原来须要做的负载平衡、服务器的高可用和弹性伸缩、音讯队列都转移到了服务外部。咱们能够看到随着架构的演进,开发人员做的事件越来越少,零碎更加成熟,业务上更加聚焦,大大晋升了交付速度。

这里的 Serverless 架构次要体现的价值是:

  • 事件触发能力:函数计算服务与事件源(OSS)的原生集成让使用者无需治理队列资源,队列主动扩大,实时处理上传的多媒体文件;
  • 高弹性和按需付费:图片和视频(不同大小的视频)须要的计算资源规格是不同的,流量的波峰波谷对资源的需要是不同的,当初这种弹性由服务提供,依照用户的实在应用去扩容缩容,让用户 100% 地利用资源,无需为闲置资源付费。

事件触发能力是 FaaS 服务的一个重要个性,这种 Pub-Sub 事件驱动模式不是一个新的概念,然而在 Serverless 风行之前,事件的生产者、消费者以及两头的连贯枢纽都是用户负责的,就像后面架构演进中的第二个架构。

Serverless 让生产者发送事件,保护连贯枢纽都从用户职责中省略了,而只需关注消费者的逻辑,这就是 Serverless 的价值所在。

函数计算服务还集成其它云服务事件源,让你更不便地在业务中应用一些常见的模式,如 Pub/Sub、事件流模式、Event Sourcing 模式。对于更多的函数组合模式能够参见:函数组合的 N 种形式。

场景 4: 服务编排

后面的商品页面尽管简单,然而所有的操作都是读操作,聚合服务 API 是无状态、同步的。咱们来看一下电商中的一个外围场景——订单流程。

这个场景波及到多个分布式写的问题,这是引入微服务架构导致的最麻烦的一个问题。单体利用在肯定水平上能够比拟容易地解决这个流程,因为应用了一个数据库,能够通过数据库事务保持数据一致性。然而事实中可能不得不去跟一些内部服务打交道,须要肯定的机制保障流程的后退和回退顺利完成,解决这个问题的一个经典模式是 Saga 模式,而实现这种模式有两种不同架构:

一种做法是采纳事件驱动模式,驱动流程实现。在这个架构里,有一个音讯总线,感兴趣的服务如库存服务监听事件,监听者能够应用服务器或者函数。借助于函数计算和音讯主题的集成,这个架构也能够齐全不应用服务器。

这个架构模块是松耦合的,职责清晰。不足之处是随着流程变得更长更加简单,这个零碎变得难以保护。比方很难直观地理解业务逻辑,执行时的状态也不宜跟踪,可运维性比拟差。

另外一种架构是基于工作流的 Saga 模式。在这个架构里,各个服务之间是独立的,也不通过事件传递信息,而是有一个集中的协调者服务来调度单个业务服务,业务逻辑和状态由集中协调者保护。而实现这个集中的协调者通常面临以下问题:

  • 编写大量代码来实现编排逻辑、状态保护和谬误重试等性能,而这些实现又很难被其它利用重用;
  • 保护运行编排利用的基础设施,以确保编排利用的高可用性和可伸缩性;
  • 思考状态持久性,以反对多步骤长时间运行流程并确保流程的事务性。

依赖于云服务,比方阿里云的 Serverless 工作流服务,这些事件都能够交给平台来做,用户又回到了只需关注业务逻辑的状态。

下图右侧是流程定义,咱们能够看到这实现了后面基于事件的 Saga 模式的成果,并且流程大大简化,晋升了可观测性。

场景 5: 数据流水线

随着业务的进一步倒退,数据变得越来越多,这时候就能够开掘数据的价值。比方,剖析用户对网站的应用行为并做相应的举荐。一个数据流水线包含数据采集、解决、剖析等多个环节。这样的服务如果从头搭建尽管是可行的,然而也是简单的,咱们这里探讨的业务是电商,而不是去提供一个数据流水线服务。有了这样一个指标,咱们做抉择时就会变得简略明确。

  • 日志服务(SLS)提供了数据采集、剖析和投递性能;
  • 函数计算(FC)能够对日志服务的数据进行实时处理,将后果写入其它服务,如日志服务、OSS;
  • Serverless 工作流服务能够定时批量解决数据,通过函数定义灵便的数据处理逻辑,构建 ETL 作业;
  • 数据湖剖析(DLA)提供了 Serverless 化的交互式查问服务,它应用规范 SQL 剖析对象存储 (OSS)、数据库(PostgreSQL / MySQL 等)、NoSQL(TableStore 等)等多个数据源的数据。

总结

限于篇幅,咱们只探讨了 Serverless 架构在几个场景中的利用,然而在实践中咱们能够看出一种共性,即如何将业务逻辑中与业务不相干的工作剥离进来,交给平台和服务实现。这种各司其职、分工协作的做法在其它场合并不生疏,然而 Serverless 的思维让这种状态更为明确。Less is more,少的不只是 Server 和围绕 Server 相干的累赘,还能够是业务以外的方方面面,多的是专一的业务和产品的外围竞争力。

正文完
 0