关于架构:Serverless-架构模式及演进

一、什么是 Serverless 架构

依照 CNCF 对 Serverless 计算的定义，Serverless 架构应该是采纳 FaaS（函数即服务）和 BaaS（后端服务）服务来解决问题的一种设计，这个定义让咱们对 Serverless 的了解略微分明了一些，然而可能也造成了一些争执。

1. 随着需要和技术的倒退，业界呈现了一些 FaaS 以外的其它状态的 Serverless 计算服务，比方 Google CloudRun，阿里云推出了面向利用的 Serverless 利用引擎服务，这些服务也提供了弹性伸缩能力和按应用计费的免费模式，具备 Serverless 服务的状态，能够说进一步扩充了 Serverless 计算的营垒。
2. 为了解决冷启动影响，FaaS 类如阿里云的函数计算和 AWS 的 Lambda 也相继推出了预留性能。
3. 另外一些基于服务器（Serverful）的后端服务也推出了 Serverless 状态产品，比方 AWS Serverless Aurora，阿里云 Serverless HBase 服务。

因而，Serverless 的界限是有些含糊，然而云服务是在 Serverless 方向上一直演进的。一个含糊的货色如何领导咱们解决业务问题呢？Serverless 有一个最基本的理念是：让用户最大化的专一业务逻辑。其它的特色如不关怀服务器，主动弹性，按应用计费等等都是为了实现这个理念而服务。Serverless 的理念能够让咱们更好地用无限的资源解决真正须要解决的问题，正是因为咱们少做了一些事件，转而让他人做这些事件，咱们才能够在业务上做的更多。

驰名的 Serverless 实践者 Ben Kehoe 这样形容 Serverless 原生心智：

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

在实际 Serverless 架构时，最重要的心智不是抉择哪些风行服务和技术，攻克哪些技术难题，而是时刻铭记在心专一业务逻辑，这样更容易让咱们抉择适合的技术和服务，明确如何设计利用架构。

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

二、动态站点

动态站点的业务需要是比较简单的，它相当于一个信息展现的站点。比方晚期网站都是动态展现，如图是 1997 年的中国黄页，它其实就是一个单层的页面。其特色能够分为三点：

1、它的页面是偏动态的展现信息。
2、其页面更新并不频繁。
3、不确定访问量。

架构的演进

图中所展现出的由云下到云上，由治理服务器到无需治理服务器（即 Serverless）的转变给开发者带来了微小的受害。如前两种计划须要估算，扩大，实现高可用，自行监控等，而当年中国黄页开发者的业务逻辑只是想单纯的展现信息，让世界理解中国。正好与 Serverless 原生心智相吻合，即让开发者最大化的去专一业务逻辑。
​

1. 买台服务器放在 IDC 机房里托管，运行站点。
2. 为了解决高可用的问题又买了负载平衡服务和多个服务器。
3. 采纳动态站点形式，站长间接将站点由对象存储服务（如 OSS）反对，并应用 CDN 做缓存。

传统架构模式下开发网站，会把网站部署在服务器上，随后再把这个服务器托管到机房，而后用户或者客户端用电脑浏览器去拜访这个网站。它所存在弊病就是：如果这个网站呈现问题，服务器不再可用，为了保护这个网站的高可用性，会再挂一个负载平衡和两个储备服务器，这就是 serverful 服务的架构。Serverless 架构对于开发人员来说，它只须要把它的动态页面间接公布到对象存储，而对象存储自身就是一个 serverless 的文件存储服务，它能够存储动态页页面、图片、音频、视频等等，并且做到有限扩大。

Serverless 架构有着其它计划无法比拟的劣势：

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

动态是个好货色，缓存也是软件开发常常用到的技术，尽管有句玩笑是说计算机技术只有两个最难的事件，让缓存生效和命名。然而这也体现了缓存的重要性，只有使用切当，能大大晋升零碎的性能。

比如说目前很多安卓利用，要公布到如小米利用商店、华为利用商店等各种渠道商，开发者更心愿的是打包好一个母包，放在对象存储里，而不是重复做打渠道包保护等反复工作。对用户来说，只须要保护一个母包，而后再保护一个简略的动静计算即可。其实 CDN 不只能够回源到对象存储，还能够回源到动静后端，如 API 网关，函数计算，负载均衡器等，也不止有 CDN 能够这种类型的缓存，还能够应用 Redis，以及过程内的缓存。

三、单体和微服务

为何会有单体和微服务，因为动态站点的话，它可能只是解决一些展现信息的需要，然而随着业务需要复杂程度减少，就须要动静站点了。比方：

• 淘宝的商品页面，采纳动态页面形式治理商品信息是不事实的。商品数量泛滥，商品上架下架信息更新频繁，商品页面简单。
• 网易、新浪门户网站，实时新闻不断更新，评论、点赞，转发等

动态页面和站点适宜用于内容少更新频率低的场景，反之，比方像图中淘宝的一个商品详情页，应用动态站点的页面是不太事实的，起因有下：

1、商品是海量的。
2、更新频繁
3、动静信息起源宽泛，如根本信息、价格、运费、销量、库存、评论等是实时变动的。

下面提到的 Serverless 原生心智有助于咱们专一业务。比方：

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

对于架构的演进，经验了 Serverful 单体架构到 Serverful 微服务架构再到 Serverless 微服务架构过程。随着业务的倒退，组织规模的一直增大，这时候个别就须要将单体利用中的逻辑拆分成多个执行单元，比方商品页面上的评论信息，售卖信息，配送信息等都能够对应一个独自的微服务；而右图的架构引入了 API 网关、函数计算或 SAE 来实现计算层，将大量工作替换云服务实现。Serverless 这种微服务架构的益处是每个单元都能高度自治，单元之间松耦合，易于开发（比方应用不同技术）、部署和扩大。

然而这种架构也引入了分布式系统的一些问题，如服务间通信的负载平衡，失败解决，分布式事务等。处在不同阶段不同规模的组织能够抉择适宜的形式，能解决它面临的首要的业务问题。

其实这里的商品页面尽管信息繁多，然而相对来说仍旧比较简单，次要是因为这里只是波及到了读操作。这种图显示了零碎外部多个微服务的交互。通过提供一个商品聚合服务，将外部的多个微服务对立的出现给内部。这里的微服务能够通过 SAE 或者函数实现。

另一个延长是，咱们开始的业务需要没有提到须要反对不同客户端的拜访，事实中这种需要是常见的，不同的客户端须要的信息可能是不同的。比方手机能够依据地位信息做相干举荐。如何让手机客户端和不同浏览器都能受害于 Serverless 架构呢？

这又牵扯出了另一个词，BFF，backend for fronted，即为前端定做的后端，这受到了前端开发工程师的推崇，Serverless 技术让这个架构宽泛风行，因为前端工程师能够从业务角度登程间接编写 BFF，而无需治理服务器相干的让前端工程师更加头疼的事件。

四、事件触发

本节通过介绍一个具体的业务场景：对于事件触发类的场景，论述 Serverless 架构是怎么解决问题的。后面提到的动静页面生成是同步申请实现的，还有一类常见场景，其中申请解决通常须要较长时间或者较多资源，比方用户评论中的图片和视频内容治理，波及到如何上传图片和解决图片（缩略图，水印，审核等），视频解决以适应不同客户端播放需要等。比方该图中业务场景是一个买家秀，当买家实现了交易，想要发表图片或者视频的评论，买家实现后，后端的服务要对这个图片加水印，而后缩放并且审核；视频也须要做多种格局的转换和审核，因为要适配各种不同的终端。

这种业务特色实际上是十分耗 CPU 的，每次工作执行的工夫个别比拟长，因而针对于这种业务，咱们可能会有一些技术架构的演进。

比方大家所相熟的抖音，就是用户上传视频的业务场景。在抖音后端也是须要对视频进行对立解决的：如加水印，转码成各种不同的码率或者是长宽分辨率去配适不同的手机。这个业务落户是非常耗费 CPU 计算资源的。同时带宽的压力也很大。这个时候你只能不停地加带宽，加机器，其后果就是运维和保护老本一直减少；第二个问题就是会存在波峰波谷，比如说早上 8 点钟的地铁工夫和中午吃饭的 1 钟或者早晨 8 点钟的时候，业务量可能是十分高的，如果你的业务须要 1000 台机器，然而到了凌晨，这 1000 台机器可能就用不上，因而便会造成资源的一些节约，同时你还要解决运维监控，扩弹性，扩缩容等工作。

将架构演进再延长一下，事件触发能力是 FaaS 十分重要的个性，这种 Pub-Sub 事件驱动模式不是一个新的概念，然而在 Serverless 风行之前，事件的生产者，消费者，以及两头的连贯枢纽都是用户负责的，就像后面架构演进中的第二个架构。Serverless 让生产者发送事件，保护连贯枢纽都从用户职责中省略了，而只需关注消费者的逻辑，这是 Serverless 的价值。函数计算服务还集成其它云服务事件源，让你更不便的在业务中应用一些常见的模式，如 Pub/Sub，事件流模式，Event Sourcing 模式。

五、服务编排

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

比如说用户在淘宝外面进行了购物，或者说在饿了么下单了外卖，它都是波及到一个订单的流程。这种订单流程是比商品展现更为简单的。因为在订单流程外面，它所要保留更多的事件。比方有用户下单时，咱们第一步要查看库存，库存储量够的话，而后库存减 1，随后接通支微信或者说支付宝的服务去领取扣款，单子下来了当前，还要安顿物流去配送，同时还要查看物流的详情并进行短信告诉等等。

同时在这些代码逻辑中你要写各种重试逻辑。如果说最终失败的话，咱们便要对已实现的事件进行回滚，如若用户勾销订单，那么须要回滚的则更多。比如说这个钱要退还给用户，这个场景是是非常复杂的，咱们能够看一下这个流程怎么发起来的。比如说第一步用户下单之后，其实是走到了这个订单服务，这个订单服务会生成订单号；而后会波及到买家是谁，卖家是谁。第二步咱们会把音讯发送到音讯总线，其余的这些服务（配送服务、库存服务、领取服务）是订阅到音讯总线的。

另一方面它的可观测性、可描述性并不好，其次在编排上，它的复用性很差。如若说开发者改成了另外一个流程的服务，那么这一套就要从新改写了。

在这个 Serverless 架构里，各个服务间接是独立的，也不通过事件传递信息，而是有一个集中的协调者服务来调度单个业务服务，业务逻辑和状态由集中协调者保护。从网关层下单后，触发函数计算的一次函数执行，函数执行的逻辑会触发一个工作流的执行。就比如说左边这张图其实就是用户本人去编写的，这个流程，就是工作流。

比如说第一步下单，第二步付钱，付钱胜利了会如何，付钱失败了应该怎么。整个订单就相当于是右侧流程的执行。而每次流程的执行都是能够被追溯的。你能够了解成他就是个组织者，而后调用其余的云服务。

所以在这个架构，咱们能够看出对开发者而言，不须要去做音讯总线，从事逻辑的解决，保护数据的一致性等到。他只须要专一他的业务逻辑，把每个流程调用的服务写好，把这些编排的流程写好就能够了。

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

如果间接依赖于云上的服务，比方阿里云的 Serverless 工作流服务，这些事件都能够交给平台来做。用户又回到了只需关注业务逻辑的状态。右图是流程定义，咱们能够看到这实现了后面基于事件的 Saga 模式的成果，并且流程的复杂度大大简化。

Serverless 技术毫无疑问将会承当更多的责任，让用户更快更好的构建利用。应用 Serverless 架构能够笼罩很多场景，这里只是介绍了 Web 网站前端后端，微服务，事件触发，服务编排等几个场景的架构。Less is more 把事件交给牢靠的平台（比方云厂商）去做，让开发者能够更加聚焦本身的外围业务价值，是 Serverless 所始终推崇的理念。
​