Serverless

一、介绍

是指依赖于第三方应用程序或服务来管理服务器端逻辑的应用程序。 此类应用程序是基于云的数据库（如Google Firebase）或身份验证服务。

无服务器也意味着开发为事件触发的代码，并且在无状态计算容器中执行。 这种架构通常称为功能即服务（FaaS）。

FaaS(Function as a service 函数作为一种服务) 本质上是一个小程序或函数，它执行由事件触发的小任务，而不像单个应用程序那样做很多事情。因此，在FaaS架构中，我们将应用程序分解为小型，自包含的程序或功能，而不是在PaaS上运行并执行多种功能的单一应用程序。例如，API中的每个端点都可以是一个单独的函数，我们可以按需运行这些函数，而不是全时运行应用程序。

二、Serverless的主要优点

开发者只需要专注于业务逻辑就可以了，开发效率更高。开发一个典型的服务器端项目，需要花很多时间处理依赖、线程、日志、发布和使用服务、部署及维护等相关的工作，基于Serverless架构则不需要操心这些工作。
不需要关注云主机、操作系统、网络等基础资源，Serverless框架还可以根据负载量自动水平扩展。
不需要架构。Serverless架构本身就是高可用、高扩展的架构，基本上不需要架构师的参与。
按需付费， 成本相对比较低。用户购买的ECS使用时间一般不到5成，但是为另外5成闲置时间付费了。Lambda按照运行的时间收费，成本会低很多。

三、Serverless的主要缺点

不适合处理复杂的业务逻辑，它更适合调用云上的其他服务，粘合关键的产品。以AWS Lambda例，我们通常使用Lambda写一段逻辑将文件上传到S3，将请求的数据写入到DynamoDB或RDS数据库等一些相对简单的功能。
排查问题困难，因为逻辑散落在各处。
Serverless无法用于高并发应用，为每个请求启动一个进程开销太高，流量瞬间爆发容易导致超时。例如双十一支付宝高峰期每秒处理的交易数为8.59万笔，如果使用Serverless架构，意味着我们的系统内每秒有8.59万个进程被创建又被销毁，这是难以负担的开销。
Serverless调用之间不能共享状态让编写复杂程序变得极度困难。无状态是互连网应用追求的目标，例如满足“12要素”的应用。但Serverless将无状态进行的更加彻底，在不同的调用之间无法共享内存状态，例如使用hashmap。我们的AI应用中统计已处理图片总数的全局计数器在传统架构中只是一个全局变量，但在Serverless架构中它变成存储在内存数据库（Redis）中的一条记录，更新成本、保证原子性等因素让我们的编码变得数倍复杂。对于大多云原生的互联网应用来说，这种彻底的无状态架构是一个巨大的挑战，而对于动辄有几十万、上百万行代码的、充满了状态的企业应用来说，Serverless的无状态改造几乎是一个无法完成的任务。
业务拆分问题。如何将业务拆分成成百上千个运行在独立进程、运行时间受限的函数是巨大的挑战。而是否需要如此细粒度的拆分是需要回答的第一个问题。有些问题或许变成无解难题又或成本极高，例如分布式数据库事务。
厂商锁定。云计算是赢者通吃的行业，大而全的云厂商优势巨大，Serverless加剧了这种趋势。以前用户还需要自己写很多服务器端的逻辑，迁移的时候，把服务器端代码重新部署一下。采用Serverless架构之后，代码都是各个平台的Lambda代码片段，没法迁移。从客户的角度来看，是不希望自己被某家云厂商所绑架的。所以云计算行业需要做很多标准化的工作，方便用户无缝在各种云之间迁移。

对已存在的项目迁移困难。将现有的复杂的单体式应用进行如此细粒度的拆分需要极高的成本。

四、Microservice与Serverless的适用场景

Microservice适合构建复杂的应用。比如：构造一个分布式数据库。

Serverless 适合构建比较简单的应用，比如上传一张图片、对一段音频/视频进行编解码、对IOT设备的请求返回一小段数据等。

原文链接:https://www.cnblogs.com/wangzhongqiu/p/11103845.html
如有疑问请与原作者联系

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有