简介：计算无服务器体系结构，数据存储和消息通信。我们可以从操作和维护，安全性，可靠性，可扩展性和成本的角度来衡量体系结构的优势和缺点。本文将介绍一些常见的业务场景，以探索如何使用无服务器体系结构来支持这些场景。
根据CNCF对无服务器计算的定义，无服务器体系结构应是使用FAA（功能作为服务）和BAAS服务来解决问题的设计。该定义使我们能够理解对无服务器的理解，但它也会引起一些争议。
1.随着需求和技术的发展，有一些无FAAS的无服务器计算服务，例如Google Cloudrun。阿里巴巴云启动了面向应用程序的无服务器应用机器服务。充电模型与充电模型的使用具有无服务器服务的形式，可以说这可以进一步扩展CAMP计算。
2.为了解决冷启动的影响，FAAS类（例如Alibaba Cloud的功能计算和AWS的Lambda）也启动了保留功能。
3.其他基于服务器的后端服务还启动了无服务器表单产品，例如AWS无服务器Aurora，Alibaba Cloud无服务器HBase服务。
因此，无服务器的边界有点模糊，但是云服务不断地朝着无服务器的方向发展。如何指示我们解决业务问题？无服务器的最基本概念是：最大化用户的业务逻辑。诸如不关心服务器，自动弹性以及使用计费等的功能以实现此概念。无服务器的概念使我们能够更好地解决真正需要使用有限资源来解决的问题。这是因为我们做的事情更少，让其他人做这些事情，我们可以做更多的业务。
著名的无服务器从业者本·凯霍（Ben Kehoe）描述了无服务器的原始思想：
1.我的生意是什么？
2.您可以使我的业务发行吗？
3.如果没有，为什么我要这样做，而不是让其他人解决这个问题？
4.在解决业务问题之前，无需解决技术问题。
在练习无服务器体系结构时，最重要的头脑不是选择哪些流行的服务和技术以及克服了哪些技术问题，而是始终记住始终专注于业务逻辑。对于我们来说，选择适当的技术和服务并澄清如何设计应用程序体系结构是更容易的。
无服务器体系结构具有计算，数据存储和消息通信。我们可以从操作和维护，安全性，可靠性，可伸缩性和成本的角度来衡量体系结构的优势和缺点。本文将介绍一些常见的业务场景，以探索如何使用无服务器架构来支持这些场景。为了使讨论不太抽象，下面将介绍一些特定的技术实施，但是这些体系结构的想法很常见，可以与其他类似产品一起实施。
静态站点的业务需求相对简单，相当于信息显示的网站。例如，早期网站显示静态，如1997年的中文黄页所示，它实际上是一个单个层次页面。特征可以分为三点：
1.它的页面是非常静态的显示信息。
2.页面更新并不常见。
3.不确定的访问量。
从云到云从云到云的转换，从管理服务器到管理服务器再到开发人员的转换为开发人员带来了巨大好处。例如，前两个方案需要预算，扩展，高可用性，高可用性，当时，监视等。中文黄页开发人员的业务逻辑只是想简单地显示信息以使世界了解中国。它与无服务器的原始思想相吻合，这使开发人员可以最大程度地发挥业务逻辑。
在传统体系结构模式下网站的开发将在服务器上部署网站，然后将该服务器托管到计算机室，然后用户或客户端使用计算机浏览器访问此网站。它存在的缺点是：该网站存在问题，服务器不再可用。为了保持本网站的高度可用性，将悬挂一个负载平衡和两个储备服务器。这是服务器服务的体系结构。对于开发人员，无服务器体系结构仅需要直接将其静态页面发布到对象存储中，而对象存储本身是无服务器的文件存储服务。Do无限扩展。
无服务器体系结构还有其他无法将优势进行比较的计划：
静态是一件好事，缓存也是一种经常用于软件开发的技术。尽管有一个笑话是计算机技术中只有两件最困难的事情，但使高速缓存失败并命名。但这也反映了缓存的重要性。只要合适，它就可以大大提高系统的性能。
例如，许多Android应用程序目前都在各种渠道供应商（例如小米App Store和Huawei App Store）中发布。开发人员希望收拾母袋并将其放在对象存储中，而不是反复执行频道包裹以维护重复工作的维护任务。对于用户，只需要维护母袋，然后维护一个简单的动态计算。实际上，CDN可以不仅返回对象存储，而且还返回到动态后端，例如API网关，功能计算，负载Balanor等，不仅CDN可以缓存此类型，还可以使用Redis以及在处理缓存。
为什么由于静态站点而有单一和微服务，它可能只是解决了某些显示信息的需求，但是随着业务需求的复杂性增加，需要动态站点。例如：例如：
静态页面和站点适合用于更少内容更新频率的方案。相反，例如图中的TAOBAO之类的产品详细信息页面，使用静态站点的页面是不现实的。原因如下：
1.商品很大。
2.频繁更新
3.动态信息的来源很广，例如基本信息，价格，货运，销售，库存，评论等。
上面提到的原始思维有助于我们专注于业务。例如：
关于体系结构的演变，服务器单个体系结构对服务器的微服务体系结构以及无服务器微服务架构的过程。随着业务的开发，组织的规模继续增加。目前，需要将单个应用程序的逻辑分为多个执行单元，例如对产品页面，销售信息和交付信息的评论。单独的微服务；右侧的体系结构介绍了API网关，功能计算或SAE来实现计算层，该计算层将以大量的工作交换服务完成。无服务器的微服务体系结构的好处是，每个单元都可以高度自动，松动在单元之间，并且很容易开发（例如使用不同的技术），部署和扩展。
但是，该体系结构还引入了分布式系统的一些问题，例如负载平衡，故障处理，分布式交易等。服务之间的通信。不同阶段的组织可以选择合适的方法来解决其面临的主要业务问题。
实际上，尽管这里的产品页面有很多信息，但它相对简单，主要是因为它仅涉及阅读操作。该图显示了系统中多个微服务的相互作用。通过提供商品聚合服务，多个内部微服务是均匀地存在于外部。这里的微服务可以通过SAE或功能实现。
另一个扩展是，我们的开展业务需求不会提及访问与不同客户的访问。实际上，这种需求很常见，不同客户所需的信息可能不同。
这涉及另一个单词BFF，即前端，是前端开发工程师尊重的前端的后端。无服务器的技术允许这种结构是宽的BFF，而无需管理与服务器相关的事物，这些内容使前端工程师更加头痛。
本节介绍了特定的业务方案：对于事件触发类的场景，解释了无服务器体系结构如何解决问题。前面提到的动态页面生成是通过同步请求完成的，并且也有一个常见的方案。请求处理通常需要长时间或更多的资源，例如用户评论中的图片和视频内容管理。图像（缩略图，水印，评论等），视频处理以满足不同客户播放需求的需求等。例如，这张照片中的业务场景是买家展览。买家完成交易后，您要发布图片或视频。购买者完成后，需要制定各种格式并进行审查，因为有必要适应各种不同的终端。
该业务特征实际上是非常CPU，并且每个任务执行通常很长。因此，对于这项业务，我们可能会有一些技术架构的发展。
例如，熟悉的douyin是用户上传视频的业务场景。在Douyin后端，该视频还需要统一处理：例如添加水印，将其转编码为各种不同的代码速率或较长的宽度分辨率以匹配以匹配不同的手机。此业务在CPU计算资源中解决。同时，带宽的压力也很大。这次，您只能保留带宽和机器。结果，操作，维护和维护的成本正在增加。第二个问题是将有一个峰值山谷，例如早上8点的地铁时间和晚上8点在中午吃1小时的时间，业务量可能非常高的。如果您的业务需要1,000台机器，但是在清晨，可能不会使用这1000台机器，因此会导致一些资源浪费。在同一时间内，还需要进行操作和维护监视，扩展，扩展和其他任务。
扩展体系结构的演变，事件触发能力是FAA的非常重要的特征。此Pub-Sub事件驾驶模式不是一个新概念，而是在无服务器的流行之前，事件的生产商，消费者和Middleall用户中的中间连接中心负责，就像以前的体系结构Evolution中的第二个体系结构一样.Serverless允许生产者发送事件，维护从用户职责中省略的所有连接中心，并且只需要注意消费者的逻辑，这是无服务器的价值。功能计算服务还集成了其他云服务事件，以便您以为您可以在您的业务中使用一些通用模式，例如酒吧/子，事件流模式，事件源模式。
尽管以前的产品页面很复杂，但所有操作都是读取操作，并且聚合服务API无状态并同步。LET查看E -Commerce -Order Process中的核心场景。
例如，用户在淘宝内购物，或者他们饿了并放了外卖。它涉及订单的过程。此订单过程比产品显示更为复杂。因为在订单过程中，它会保留更多的东西。例如，当有用户下订单时，第一步是检查库存。如果库存储量足够，则将库存减少1，然后将微信或支撑台服务连接到付款扣除额。同时，送达后期，检查物流的详细信息并发出SMS通知，等等，依此类推。。
同时，在这些代码逻辑中，您必须编写各种评论逻辑。如果我们最终未能失败，我们必须退缩已完成的内容。如果用户取消了订单，则需要回滚更多。例如，如果将此资金返回给用户，则此场景非常复杂。我们可以看到这个过程是如何上升的。此订单服务将生成订单号；然后，它将涉及买方是谁，卖方是谁。第二步，我们将把消息发送到消息总线。其他服务（分销服务，库存服务，付款服务）将订阅消息总线。
另一方面，它的观察和描述性不好。其次，在安排中，其重复使用非常差。如果开发人员已更改为另一个流程服务，那么此组将被重写。
在此无服务器体系结构中，每个服务都是直接独立的，并且不会通过事件传递信息。取而代之的是，有一项集中式协调服务来派遣单个业务服务。业务逻辑和状态通过集中协调维护。从网关层下订单后，由触发函数计算出的函数执行，函数执行的逻辑将触发工作流程的执行。例如，在权利实际上是用户自己写的。这个过程是一个工作流程。
例如，第一步是订购，第二步是付款，付款成功将会发生什么，如果付款失败，该怎么办。整个订单等同于执行正确的过程。执行可以追溯到每个过程。您可以理解他是一个组织者，然后调用其他云服务。
因此，在此架构中，我们可以看到，对于开发人员，我们不需要进行消息总线，进行逻辑处理并保持数据的一致性。他只需要专注于他的业务逻辑，写每个过程的服务致电，并写下这些安排的过程。
如果您直接依靠云上的服务（例如阿里巴巴云的无服务器工作流服务），可以将这些东西移交给平台上以执行的操作。用户返回仅关注业务逻辑的状态。正确的是过程定义。我们可以看到，这实现了基于事件的传奇模式的效果，并且该过程的复杂性得到了极大的简化。
无服务器技术无疑将承担更多的责任，使用户能够更快，更好地构建应用程序。无服务器体系结构的使用可以涵盖许多方案。在这里，它仅介绍了几个场景的体系结构，例如网站的前端，微服务，事件触发器和服务安排。没有更多的东西可以将事物移交给可靠的平台（例如云制造商），以便开发人员可以可以更多地关注其核心业务价值，这是无服务器一直钦佩的概念。
资料来源：阿里巴巴云