浅析无服务器的微服务架构与实践

Posted 2021-04-14 中生代技术

本文是中生代技术社群第44期分享，也是第1期美女大咖作分享，分享者是陈爱珍，著名的七牛云布道师，全文共5826字，建议阅读时间6分钟

大家好，我是七牛云布道师陈爱珍，今天给大家带来的主题：浅析无服务器的微服务架构与实践；

近年来产生了很多改变传统开发和运维的新型技术，比如容器，微服务等。这些新的技术都在解决传统开发运维的复杂度问题，也都奔着提高效率，降低成本的方向在发展。

在这里跟大家聊的是另一个值得关注的未来新趋势技术--   无服务器架构（Serverless     Architectures）   。这里借用ThoughtWorks公司的首席科学家Martin   Fowler对无服务器架构的定义：   无服务器架构是指大量依赖第三方服务（也叫做后端即服务，即“BaaS”）或暂存容器中运行的自定义代码（函数即服务，即“FaaS”）的应用程序。下面分别讲述一下BaaS和FaaS。 BaaS（后端即服务） 一个移动互联网产品分为两个部分，一个是前端，就是用户所看到的界面；一个是后端，用于对用户交互行为进行支撑的服务，包括了应用程序和数据库等服务，还包括了对应用程序和数据库等服务的运行环境IaaS，PaaS。如下图所示：

那么要提供一个移动互联网产品也需要完成两个部分的工作：一个是功能的开发，一个是运行环境的构建与维护。主要需要做以下的成本投入：

成本项	具体的内容
硬件成本	机房
	服务器
	网络设备
	存储设备
人员成本	前端开发人员
	后端开发人员
	运维人员
时间成本	环境的搭建
	前端的开发
	后端的开发

从上面这个表格我们可以看到，如果所有内容都由自己构建，那么一个是产品的上线周期会时间很长，还有就是投入的成本会很大，并且风险全部在自己手中。基于这种市场需求，开始出现了云服务商来帮助开发者达到简化过程，快速上线的需求。最早形式的云服务商主要还是云主机的方式，这样开发者就不需要搭建和维护运行环境，
只需要做功能的开发，再部署到云主机上。并且购买云主机的成本也会相对比自己购买的成本要低，还可以进行一个按需的伸缩，不会有闲置的资源浪费。主要需要做以下的成本投入：

成本项	具体的内容
硬件成本	云主机
人员成本	前端开发人员
	后端开发人员
	运维人员
时间成本	前端的开发
	后端的开发

虽然这种模式相对原来的模式在成本和效率上已经有了很大的提升了，但是作为一个为快不破的互联网时代，这种效率依然不够快速。如所有的功能都需要自己开发，对云主机的伸缩和资源的利用还是需要自己来管理。基于这种市场需求，又提出了一种新的服务—BaaS，后端即服务。即后端服务由第三方云服务提供，而自身只需专注于具体业务和逻辑的实现，以及前端的设计与开发，提高用户体验。在这模式下，不需要为后端服务买服务器，也不需要编后端的代码。主要需要做以下的成本投入：

成本项	具体的内容
人员成本	前端开发人员
时间成本	前端的开发

我们可以看到，在这种模式下，对一个产品来言就只需要前端开发，免除了后端系统的负担，简化了整个产品的构建，可以快速实现产品化与上线。可以看到这种后端即服务的模式下，对开发者而言是不需要维护服务器的，在产品的生命周期里都没有出现服务器，这就是一种无服务器架构。无服务器架构不是没有服务器，而是开发者无需关心服务器，只需要关注代码的实现。这些后端的服务器被平台服务商隐藏起来，由第三方服务商负责基础设施管理的基本细节，包括应用运行时的计算资源的分配和可用性。服务器对开发者而言透明的，开发者也无法调整或修改任何与服务器相应的内容。 BaaS的价值 降低成本：按传统的模式还没有上市已经为后端投入了很多的成本。而目前BaaS服务商都会有一定的免费额度，那么在验证市场前的投入就可以相对降低很多，风险也降低了很多。 提高产品质量：减少了后端的开发，只关注前端开发，可以提高研发的效率和产品质量。 快速上市：简单化了整个产品的研发过程，可以缩短想法到产品的距离。 丰富的API资源：BaaS将常用和必要的第三方API资源汇总，免除了选择多个厂商的局面。 移动互联网产品的开发者使用   BaaS   模式，只需一个极小team，极短的时间，就可以快速上线一个产品。目前比较知名的BaaS服务提供商包括国外   Parse，Kinvey，国内的LeanCloud，Bomb和MaxLeap，APICloud   、友盟。为移动应用开发者提供的后端服务包括结构化的数据存储、用户和权限管理、文件存储、支付、实时通信等。 FaaS（函数即服务） 在BaaS模式下，对开发者而言是没有服务器的，但是对BaaS服务提供商来说还有是服务器的。通常他们也会对选择其他的云服务商，如云存储，云主机。比如七牛云存储是   LeanCloud   在国内节点选用的非结构化数据托管方。而FaaS模式的Serverless   则是改变服务器资源的提供方式，计算资源不再是服务器，而是一个封装了待执行代码的函数，计算资源作为服务而不是服务器的概念出现。 以传统的云主机服务为对比。购买一个云主机之后就会拥有这台主机的独占资源，改变的只是由本地物理机变成了云上虚拟机，可以免去部分主机层的运维。但是在这个主机上还是需要安装一些软件，配置一些信息，部署一些应用，还有一些应用级别的运维操作，比如应用的监控，安全，伸缩等。更重要的是，云主机是以月的方式购买，一但购买，无论是否使用，这个服务器都是收费的。而Serverless提供方式是根据函数的调用次数来收费，只要这个服务没有人调用就不需要为计算资源付费。并且在使用上也非常简单，只需把函数代码上传到平台上，分钟级别函数就可以对外提供服务了。没有复杂的部署过程，没有复杂的配置过程，没有等待时间，并且不需要运行。 那么这种Serverless的原理是什么呢？ 首先是它只支持无状态的单一职责的函数应用，并不支持有状态的多职责的应用，这样应用在启动时不需要过多的加载，能毫秒级的启动。 其次它是冷启动的模式，也就是说后端的服务在没有调用的情况下并不运行，而是只当有调用时才会启动，处理完请求后就会立马释放资源，应用不再是“”始终运行“”，这样资源就可以得到充分的利用。 第三就是按调用次数进行自动的弹性扩缩容，并不需要人为去管理伸缩问题。这样对用户来说，购买的不再是一台服务器，而是部署的函数的调用次数，这就是函数即服务。 传统的模式下，无论是使用的计算资源是物理机，虚拟机，容器还是云主机，都是需要人去维护和部署，开发者面对的计算资源都是服务器。而在无服务器计算架构下，所有与服务器关系的问题都交由服务提供商解决。Serverless中的服务或功能代表的只能是函数级别的微功能或微服务，这种模式不再是基础设施即代码的架构，而是代码即基础设施的架构。能帮助开发者摆脱运行后端应用程序所需的服务器设备的设置和管理工作，让开发人员可以主要专注于代码，更快速地开发软件。 通过下面的图可以对比一下传统的服务器模式与无服务器模式的区别：

在传统的服务器模式下，对应用进行开发后首先要构建一个运行环境，包括购买主机，在主机上安装相关的软件，配置环境，再进行应用的部署，部署成功后还需要对应用的运行进行运维管理，确保高可用。 而在无服务器模式下，开发面对的只有代码，在无服务器服务提供商的界面将代码上传，简单的配置一下，也不需要选择资源，只需定义运行时的编译环境，如是java，nodejs还是python等。在选择部署的那一刻就可以对这个函数进行访问了，并且部署后并不需要维护。对于没有转过思维的同学可能还在想，我怎么看函数的运行状态，怎么看启动了多少个实例，怎么看资源的消耗情况。STOP!这些都没有，只需要关心函数是否能正常的访问。 那么什么样的应用适合运行在这种Serverless模式下呢？比如七牛的图片处理服务非常适用FaaS模式，每个图片处理的命令就是一个简单的Function。

以构建一个计算文件hash值服务为例，这个函数只需获取到要处理的数据，再在函数中执行数据处理的算法，几十行代码，计算逻辑简单，无状态，处理时间短，毫秒级的响应，   这样的应用就非常适合Serverless模式。 如果需要调用多个函数时应该怎么处理？分两种情况，对于并行的情况，比如需要同时获取多个函数的处理结果来做一个响应，可以使用APIGateway   。API   Gateway负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过API   Gateway，然后路由这些请求到对应的函数服务。API   Gateway将通过调用多个函数服务来处理一个请求以及聚合多个服务的结果。另一个是串行的情况。比如七牛的图片处理，每一个函数服务的输出都是下一个处理函数的输入，直到最后一个函数服务执行结束才是最终数据处理的内容，比如先裁剪后加水印，必须按序执行。那么在这种串行处理的情况下，可以选择使用管道（pipeline）进行串行的处理   。 下面使用以使用serverless构建一个FaaS为例，展示什么是无服务器架构。

如上图所示，在本地环境安装一个serverless后，首先使用serverless根据模板创建一个aws-nodejs的服务，这里会在当前目录下产生两个文件，   serverless.yml和handler.js。serverless.yml文件用于声明一个Serverless服务，而handler.js里则是具体的函数代码。第二步，使用serverless   deploy将当前的serverless服务进行部署，服务部署成功后用户可通过   HTTP   API   访问部署的服务。在整个部署过程中，只需写好代码和服务声明，而并没有进行服务器的环境配置，也没有任何类型软件的安装，也没有配置运行所需的资源，整个部署过程开发者不用考虑服务器的问题，这就是无服务器计算。 Serverless的特点 1.   无状态 FaaS函数是无状态的，只提供单纯的调用，对输入的函数转换。这也是微服务要求的特性。 2.单一原则 函数需满足单一职责原则（SRP）。只处理某一项简单任务的函数更容易测试、运行稳定，而且带来的错误和意外的副作用比较少。 3.   执行时间 FaaS函数通常会对每次调用可以执行的时间长度有所限制。对超过一段时长的请求将被终止。 4.事件驱动 传统的服务器端需长期维持业务进程来处理客户端请求，而在Serverless架构中，业务代码仅在调用时才激活运行，当响应结束占用资源便会释放。比如在夜间有些服务根本没人调用，那么这些服务也不会运行。 Serverless   带来的价值 低成本 服务只在被调用时才会运行，执行完毕后，承担这些功能的容器会立刻停用，这样在idle状态下就不会占用的资源，可以更好的提高资源的利用率，而用户则只需为运行代码过程中所消耗的资源付费。某些服务可能一个月中只有某一天或只有白天才会有请求量，其他时间都是空闲的。在传统的模式是申请一台云主机后，按月付费，无论是否使用。而在无服务器模式下，可以按函数调用次数付费，无请求不运行无资源占用不收费，不会因配置过多造成资源浪费，也不会因为配置过少造成性能问题。这种按调用次数付费的方式可以很大程度上降低成本。 快速扩展 在传统的模式下，为了应对业务高峰，即使这个高峰时间只是当天的某一个瞬间，都需要准备好足够的云主机资源来应对高峰。而在Serverless架构下，可以利用快速扩展特性，快速构建新的计算能力来满足当前需求，而无需关心服务器资源是否足够，是否能够进行扩展。 敏捷性 首先因为函数只是实现单一的职责，是微功能的微服务，代码的数量并不会很多，而且AWS   lambda还提供各种代码模板，只需在模板中修改核心代码就可快速完成代码的开发。代码发开发之后，也没有复杂的服务器配置工作，只需要将代码上传到平台，秒级完成部署，实现了快速上线。 易调试 代码的简单以及部署的敏捷性，同时也带来了调试的简单性。对代码的修改可以秒级的线上验证，也可以秒级的回退，没有复杂的调试过程。 免运维 免运维指的是指无须内部的运维，不同于传统的部署方法，serverless模式只需将代码上传至FaaS供应商，其他事情均可由供应商完成。相当于运维的工作外包给了无服务器技术供应商，包括服务器本身的管理，监控、安全、伸缩等。 Severless   适用场景的实践 1）快速上线需求 在非serverless模式下，如果开发一个API要上线，需要先购买服务器，再部署环境，然后再上线提供服务，还有一些和运维相关的事情需要处理。或许开发一个API只用了1小时，但其他的事情却占用了七八个小时，还有很多对开发人员来说不熟悉的运维操作，降低了上线的速度。如果使用serverles模式，只需要把代码开发完成，就能在几分钟之内完成部署上线，非常适合快速上线的场景。 2）不想为空闲资源付费的需求 以云主机的使用为例，购买一个云主机部署业务后，这个业务可能在一天中的请求量分布不均，在某些时段非常低或空闲，而在某些时段峰值很高，但是为了满足在业务高峰期的需求，在购买云主机时会将资源配置最大化，并留有一定的冗余。在这种场景下，如果使用serverless模式，则可以根据一天中不同时间段的请求情况按需付费，不而需要为没有请求量情况下的资源付费。 3）流量突发场景下的需求 在移动互联网的业务中经常会遇到突发流量的场景，虽然现在的PaaS云平台基本也都具备了弹性伸缩的能力，但能做到自动扩容的还是很少。而在serverless模式下则可以灵活应对突发流量，快速响应，快速扩缩容。 Serverless   的劣势 和现在所有的技术一样，无服务器方法解决不了所有问题，在解决一些问题的同时也会带来一些问题。这就取决的开发者的选择。 1.容易失控 除了代码功能由自身实现，其他的所有都完全依赖服务提供商，但服务提供商本身提供的服务功能的完整性和可靠性还有待验证。而且如果是一个有些复杂的系统，这意味着围绕系统实现的所有服务都需要使用这个平台的，如数据库等，那么很容易出现失控的局面。 2.部署的复杂性 从整个应用的部署到微服务的部署再到函数的部署，把一个部署动作变成了无数多个的部署动作。对于一个应用程序中的每个一函数都需要单独部署一个FaaS，如果有30个函数就需要部署30次。还需要能像容器编排工具一样对一组函数进行统一的部署。 3.启动延迟 区别于传统的服务器持久在线的运行模式，函数采用的是冷启动，也不是只有调用触发才会启动，也就是说要求服务在调用触发的瞬间启动，毫秒别，至少也需要是秒级。那么调用一个函数时多久能获得响应也是一个问题。除非能做到毫秒级的启动，否则不适用于高并发、低延迟的场合。 4.集成测试 单个的函数比较简单，调试起来也比较简单，但是要把很多个函数做集成测试就会变得复杂。目前大部分的提供商未向用户提供可用的本地实现，在做集成测试时也不能使用本地的环境，而只能使用生产测试，这也会带来一些复杂度和风险。 Serverless的技术实现 如何构建一个Serverless的平台呢？前面讲过，函数是一个比较极端情况的微服务，而基于容器的PaaS平台是对微服务的最合适的落地方案。那么如果想做一个Serverless的平台，也可以在容器平台上进行一个优化。主要是四个方面的技术实现，第一个是运行环境的自动构建，二个是事件驱动的部分，三是基于调用次数的自动化伸缩，最后是容器的启动速度。如果解决了这四个问题，那么这样的容器平台对使用者来说也是Serverless的。

目前Amazon   Lambda、 、 、 ，以及 和   都提供了基于FaaS   的Serverless服务。AWS   Lambda支持Node.js，Java和Python。Google   Cloud   Functions只支持Node.js，不过预计在将来会添加更多的语言。   IBM   OpenWhisk支持Node.js，Swift   。Serverless   Framework作为node.js   NPM模块来提供，填补了AWS   Lambda存在的许多缺口。它提供了多个样板模板，可以迅速启动AWS   Lambda的开发。Iron.io的serverless   computing平台其代号为Project   Kratos，旨在将AWS   Lambda引入到企业。 无服务器技术的未来 就像容器技术和微服务技术最初提出来时不完善一样，Serverless模式也存在很多不完善的部分，无论是BaaS模式还是FaaS模式，都没有完全解决产品，效率，成本之间的问题。但是相信通过不断的实践和迭代，未来会发展的更好，从而带来一个新的技术变革热潮，也期待新模式的Serverless的产生。 扩展阅读

---

中生代技术推荐图书