介绍：Serverless架构包括计算、数据存储、消息通信等技术的使用。我们可以从运维、安全、可靠、可扩展、成本等角度来衡量架构。优点和缺点。本文将介绍一些常见的业务场景，并讨论如何使用无服务器架构来支持这些场景。Serverless架构根据CNCF对Serverless计算的定义，Serverless架构应该是一种使用FaaS（functionasaservice）和BaaS（后端服务）服务来解决问题的设计。这个定义让我们对Serverless的理解更加清晰了一些。但它也可能引起了一些争议。随着需求和技术的发展，业界出现了一些FaaS以外的Serverless计算服务，比如GoogleCloudRun，阿里云推出了面向应用的Serverless应用引擎服务。收费模式有了serverlessservice的形式，可以说进一步扩大了serverless计算的阵营。为了解决冷启动的影响，阿里云的函数计算、AWS的Lambda等FaaS类也相继推出了预留函数。一些基于服务器（Serverful）的后端服务也推出了Serverless产品，例如AWSServerlessAurora和阿里云ServerlessHBase服务。因此，Serverless的界限有些模糊，但云服务却在不断朝着Serverless的方向演进。歧义如何指导我们解决业务问题？Serverless最基本的概念之一是：让用户最大限度地专注于业务逻辑。其他诸如不关心服务器、自动弹性、按用量计费等特性都在服务中实现这一理念。Serverless的概念可以让我们更好的利用有限的资源去解决真正需要解决的问题。正是因为我们少做一些事情，让别人去做这些事情，我们才能在业务上做得更多。著名的Serverless从业者BenKehoe是这样描述Serverless的原生思维的：Whatismybusiness？这样做会让我的企业脱颖而出吗？如果不是，为什么我要这样做而不是让别人弄清楚呢？没有必要先解决技术问题，再解决业务问题。在实践Serverless架构的时候，最重要的不是选择去攻克哪些流行的服务和技术，而是时刻牢记和关注业务逻辑，这样我们更容易选择合适的技术和服务，并且阐明如何设计应用程序架构。无服务器架构包括使用技术的计算、数据存储和消息通信。我们可以从运维、安全性、可靠性、扩展性、成本等角度来衡量架构的优劣。本文将介绍一些常见的业务场景，并讨论如何使用无服务器架构来支持这些场景。为了使这个讨论不至于太抽象，下面介绍一些具体的技术实现作为参考，但是这些架构的思想是通用的，可以用其他类似的产品来实现。静态站点静态站点的业务需求比较简单，相当于一个展示信息的站点。比如早期的网站都是静态展示的。图为1997年的中国黄页，实际上是单层页面。它的特点可以分为三点：1.它的页面是信息的静态展示。2.页面更新不频繁。3.不确定的流量。从云下到云上，从托管服务器到非托管服务器（即Serverless）的架构演进图，给开发者带来了巨大的收益。比如前两种方案需要预算、扩容、高可用、自监控等，而中国黄页开发者的业务逻辑仅仅是展示信息，让世界了解中国。恰好与Serverless的初衷不谋而合，即让开发者最大程度专注于业务逻辑。购买一台服务器托管在IDC机房运行站点。为了解决高可用的问题，买了负载均衡服务和多台服务器。静态站点方式，站主直接用对象存储服务（如OSS）支持站点，使用CDN做缓存。传统架构模式开发网站，网站会部署在服务器上，然后服务器托管在机房，然后用户或客户端使用电脑浏览器访问网站。它的缺点是：如果网站出现问题，服务器不再可用，为了维持网站的高可用性，会链接一个负载均衡器和两个备用服务器。这就是Serverful服务的架构。Serverless架构对于开发者来说，只需要将其静态页面直接发布到对象存储即可，而对象存储本身就是一个Serverless文件存储服务，可以存储静态页面、图片、音频、视频等，并且可以做无限扩展。Serverless架构具有其他方案无法比拟的优势：无需管理服务器，如操作系统安全补丁升级、故障升级、高可用等。这些云服务（OSS、CDN）都在提供帮助。无需预估资源和考虑未来的扩展，因为OSS本身具有弹性，使用CDN使得系统延迟更小，成本更低，可用性更高。按实际使用的资源付费，包括存储费和请求费，无请求时不收取请求费。安全性：这样的系统连服务器都看不到，不需要SSH登录，DDOS攻击也交给云服务来解决。静态是个好东西，缓存也是软件开发中经常用到的技术，虽然有个笑话，计算机技术中最难的只有两件事，缓存失效和命名。但是这也体现了缓存的重要性，只要使用得当，可以大大提高系统的性能。比如目前很多安卓应用需要发布到小米应用商店、华为应用商店等各个渠道商，开发者更喜欢打包一个父包放到对象存储中，而不是重复渠道包维护。等待重复性工作。对于用户来说，只需要维护一个父包，然后维护一个简单的动态计算即可。实际上，CDN不仅可以回源到对象存储，还可以回源到API网关、函数计算、负载均衡器等动态后端。不仅CDN可以使用这种缓存，还可以Redis和进程内缓存。单体和微服务为什么会有单体和微服务，因为静态站点可能只是解决一些信息展示的需求，但是随着业务需求的复杂化，需要动态站点。比如：淘宝的商品页面，用静态页面来管理商品信息是不现实的。商品数量多，商品上下架信息更新频繁，商品页面复杂。网易和新浪门户，实时新闻更新，评论、点赞、转发等静态页面和站点，适用于内容较少、更新频率较低的场景。页面不真实，原因有以下几点：1、产品数量较多。2.更新频繁3.广泛的动态信息源，如基本信息、价格、运费、销量、库存、评论等实时变化。上面提到的Serverless原生思维帮助我们专注于业务。比如：是否需要自己购买服务器安装数据库实现高可用、管理备份、升级版本等，或者可以将这些事情交给RDS等托管服务；是否可以使用表存储、ServerlessHBase等Serverless数据库服务，实现按需Elastic扩缩容和支付。单体应用是需要自己购买服务器运行，还是可以交给托管服务，比如函数计算、Serverless应用引擎。能否通过函数实现轻量级微服务，取决于函数计算提供的负载均衡、自动伸缩、按需付费、系统监控等能力。基于SpringCloud、Dubbo、HSF等实现的微服务应用是否需要购买服务器来部署应用、管理服务发现、负载均衡、弹性伸缩、熔断、系统监控等，或者这些工作能否交给服务例如无服务器应用程序引擎。从架构的演进来看，经历了从Serverful单体架构到Serverful微服务架构再到Serverless微服务架构的过程。随着业务的发展和组织规模的不断扩大，一般需要将单体应用中的逻辑拆分成多个执行单元，比如商品页面的评论信息、销售信息、发货信息等。单个微服务;而右边的架构引入了API网关，函数计算或者SAE来实现计算层，和云服务交换了很多工作。Serverless微服务架构的优点是每个单元可以高度自治，单元之间松耦合，易于开发（如使用不同的技术）、部署和扩展。但这种架构也引入了分布式系统的一些问题，例如服务间通信的负载均衡、故障处理、分布式事务等。不同阶段和规模的组织可以选择合适的方法来解决其面临的主要业务问题。其实这里的商品页面虽然信息量很多，但是比较简单，主要是只涉及阅读操作。这种图展示了系统内部多个微服务的交互。通过提供商品聚合服务，将内部多个微服务统一呈现给外部。这里的微服务可以通过SAE或者函数来实现。还有一个延伸就是我们开始的业务需求没有提到需要支持不同客户端的访问。实际上，这种要求很普遍，不同的客户可能需要不同的信息。例如，手机可以根据位置信息进行相关推荐。移动客户端和不同的浏览器如何从无服务器架构中获益？这就涉及到另外一个词，BFF，backendforfronted，也就是为前端定制的后端，深受前端开发工程师的推崇。Serverless技术让这种架构得到了广泛的流行，因为前端工程师可以直接从业务角度来写。BFF，不用去管理那些让前端工程师更头疼的服务器相关的东西。事件触发本节介绍一个具体的业务场景：针对事件触发场景，讲解Serverless架构是如何解决的。上面提到的动态页面生成是通过同步请求完成的。还有一个常见的场景，请求处理通常需要很长时间或者需要很多资源，比如用户评论中的图片和视频内容管理，这涉及到如何上传图片和处理图片（缩略图、水印、审核等）.),满足不同客户端播放需求的视频处理等。比如图中的业务场景是买家秀。当买家完成交易后，想要发布图片或视频评论，买家完成后，后台服务需要给图片加水印，然后缩放查看；因为需要适配各种终端，所以需要进行多次格式转换和审核。这种业务特性其实是非常耗CPU的，每个任务的执行时间一般都比较长。所以，对于这种业务，我们可能会有一些技术架构的演进。比如大家熟悉的抖音就是用户上传视频的业务场景。在抖音的后端，还需要对视频进行统一的处理：比如加水印，转码成各种码率或者长宽分辨率，以适配不同的手机。这种业务结算消耗了大量的CPU计算资源。同时，对带宽的压力也很大。这时候只能不断增加带宽和机器，结果是运维成本不断增加；第二个问题是会有高峰和低谷，比如早上8点的地铁时间和中午的午餐时间。或者晚上8点，业务量可能会很大。如果你的业务需要1000台机器，但是在凌晨，这1000台机器可能没有用到，会造成一些资源浪费。同时，你还需要处理运维监控、弹性扩展、扩缩容等，延伸架构的演进，事件触发能力是FaaS非常重要的特性。这种Pub-Sub事件驱动模型并不是一个新概念，而是在Serverless流行之前，事件生产者、消费者、中间连接hub都是用户的责任，就像之前架构演进中的第二个架构一??样。Serverless允许生产者发送事件和维护连接集线器从用户职责中省略，只需要关注消费者的逻辑，这就是Serverless的价值。函数计算服务还集成了其他云服务事件源，让您可以更方便地使用业务中的一些常用模式，例如Pub/Sub、事件流模式、EventSourcing模式。服务编排前面的产品页面虽然复杂，但是所有的操作都是读操作，聚合服务API是无状态同步的。让我们来看看电子商务中的一个核心场景——订单流程。比如用户在淘宝上购物，或者在饿了么下单外卖，都涉及到下单流程。这个订购过程比产品展示更复杂。因为在订单过程中，它需要保留更多的东西。例如，当用户下订单时，第一步是检查库存。如果库存充足，则库存减1，然后接入微信或支付宝服务进行扣款支付。收到订单后，我们会安排物流。发货，同时查询物流明细及发送短信通知等。同时，你还要在这些代码逻辑中写各种重试逻辑。如果最后失败了，我们必须回滚已经完成的事情。如果用户取消订单，需要回滚的东西就更多了。比如需要把钱退给用户。这个场景非常复杂。我们可以看看这个过程是如何启动的。比如用户在第一步下单后，实际上是去到订单服务，会生成一个订单号；那么就会涉及到谁是买家，谁是卖家。在第二步中，我们将消息发送到消息总线，而这些其他服务（送货服务、库存服务、支付服务）订阅消息总线。另一方面，它的可观察性和描述性不好，其次，它在布局方面的复用性很差。如果开发者改变了另一个进程的服务，那么这个集合就得重写了。在这种无服务器架构中，每个服务都是直接独立的，不通过事件传递信息。相反，有一个集中的协调器服务来调度单个业务服务，业务逻辑和状态由集中协调器维护。从网关层下单后，会触发函数计算的函数执行，函数执行的逻辑会触发工作流的执行。比如右图，其实是用户自己写的。这个过程就是工作流。比如第一步下单，第二步付款。支付成功怎么办，支付失败怎么办。整个命令相当于右边流程的执行。并且流程的每一次执行都可以追溯。你可以理解为他是一个组织者，然后去调用其他的云服务。所以在这个架构中，我们可以看到对于开发者来说，不需要做消息总线，不需要做逻辑处理，不需要维护数据一致性等等。他只需要专注于自己的业务逻辑，写好各个流程调用的服务，写好这些编排好的流程。编写大量代码实现编排逻辑、状态维护、错误重试等功能，而这些实现很难被其他应用复用。维护运行编排应用程序的基础架构，以确保编排应用程序的高可用性和可扩展性。考虑状态持久性以支持多步骤长时间运行的流程并确保流程事务性。如果直接依赖云上的服务，比如阿里云的Serverless工作流服务，这些东西都可以交给平台。用户又回到了只关注业务逻辑的状态。右图是流程定义。我们可以看到，这样就达到了之前基于事件的Saga模式的效果，流程的复杂度大大简化。Serverless技术无疑会承担更多的责任，让用户更快更好地构建应用。使用无服务器架构可以覆盖很多场景。这里只介绍网站前后端、微服务、事件触发、服务编排等几个场景的架构。Lessismore是Serverless一直倡导的理念，将事情委托给可靠的平台（比如云厂商），让开发者可以更专注于自己的核心业务价值。原文链接本文为阿里云原创内容，未经许可不得转载。
