看了这个无服务器的案例,国内云都是浮云

18-08-21 banq
                   

我们知道无服务器架构背后是有服务器。那有什么意义呢?有人开玩笑说:那只是别人的服务器。 使用无服务器架构有几个好处:

1.不需要自己配置或管理服务器了,用别人的。

2.能够量入为出,根据系统规模扩张伸缩

3.仅仅为调用API付费,因为你到底调用了别人的服务器了,用多少算多少。

4.天然的高可用性和容错

以上优势使得我们无法抗拒地将无服务器用于新的和现有的解决方案架构中。今天,我们来讨论几个无服务器的实际用例。

1. Web应用程序

2. 事件驱动的数据处理

3. 流处理

4. 会话机器人

5. 无服务器工作流

虽然这里将使用亚马逊的AWS云范式来讨论上述模式,但大多数领先的云提供商都支持这些架构设计。

Web应用程序

无服务器Web应用程序是无服务器计算的最常见用例。请考虑以下情形。

如果你是斯里兰卡最大购物中心的首席技术官,每天有10,000名用户访问网站,该应用程序具有Web、移动前端和连接到数据库的API。目前,它使用自己的内部服务器运行,这给公司带来了巨大的成本。你现在希望将整个站点移至AWS Cloud,以实现更高的可用性和成本降低。

你如何进行这种迁移?

涉及无服务器Web应用程序一般有以下考虑因素:

1. Web应用的运行成本应该是最低的

2. 能够运行和监控Web应用以实现业务价值

3. 必须不惜一切代价保护Web应用的数据

4. Web应用应该能够从服务中断中恢复

5. Web应用应满足要求中的性能标准

在上面这张指定的场景中,显然有一个与API通信的静态Web应用程序。在AWS中,托管静态Web应用程序的最佳方式是在S3上。

好了,我们使用了S3存储桶托管静态Web应用程序,然后通过CDN厂商CloudFront分发服务。为什么我们在网站前使用CloudFront?简单地说,CloudFront充当CDN,用于缓存网站的图像,html,css和javascript。

接下来我们有一个rest API需要放入架构。可以使用AWS API Gateway作为我们的REST api实现。

API Gateway是AWS提供的无服务器API,它可以自动扩展以满足来自客户端的任意数量的请求。在API网关收到请求后,它将转发到相应的资源或代理服务,在本例中代理服务为AWS Lambda。

AWS Lambda是AWS的无服务器计算产品,它可以启动数十万个并行lambda函数,以便从任意数量的请求中执行业务逻辑,因此,你不必担心如何扩展无服务器了!

Lambda函数内部的逻辑可以处理包括与数据库通信等工作。在上面的在线购物中心场景,数据库可以使用AWS DynamoDB,它是AWS提供的完全托管的NoSQL数据库产品。

然而,我们的架构并不完整,安全性必须设计到位,由于这是一个在线购物中心,安全是最重要的。让我们将AWS Cognito服务插入到体系结构中。

对于无服务器应用程序,将用户与应用程序分离是一种很好的做法,这将让用户在不影响应用程序性能的情况下独立增长,你可以确保该应用支持具有行业标准身份验证和授权协议的数十亿用户。

AWS Cognito可用于身份验证和授权需求,Cognito有两个部分,Cognito User Pool和Cognito Federated Identities。

Cognito UserPool是您的用户池,它将管理应用程序的所有用户,它支持多种行业标准协议,如OAuth 2.0和SAML。

Cognito Federated Identities将为已登录用户应用AWS策略,其中说明了已登录用户允许或拒绝的资源,一旦用户登录,他就可以调用下游服务,只有当用户被允许调用它们时才会允许。

我们可以使用IAM策略在三个级别上保护下游服务。

1. 认证

2. API网关级安全性

3. 数据库级安全性

好的!我们完成了在线购物中心的所有设置。

事件驱动的数据处理

如果应用已在S3上成功启动并运行,开发人员可以开始优化该站点,因为客户抱怨:“该网站非常慢”。

经过研究发现,在登录页上加载高分辨率产品图片会导致速度变慢,作为补救措施,可以决定每次上传产品图片时生成缩略图并在登录页面上显示它们,从而加快网站加载速度。

事件驱动的数据处理是无服务器计算的另一个主要用例,根据上面的场景,让我们用异步方式创建上传图像的缩略图到S3的工作。

当站点管理员将产品图像上传到S3时,它将发出S3 PUT事件。我们可以设置由此事件触发一个Lambda函数。这是完全异步处理,因此上传过程可以与缩略图生成的过程解耦,此外,由于我们使用lambda进行处理,即使在大量请求时它也会很好地扩展。

流处理

让我们继续当前这个场景案例。

作为另一项改进,如果希望在网站上添加搜索引擎,以便用户即使在不知道产品的确切名称/品牌的情况下也可以方便地搜索产品。

当新产品添加到数据库时,你决定使用Elasticsearch来索引所有产品信息。

但是如何将Elasticsearch插入当前架构?

Elasticsearch是一个基于Lucine的搜索引擎,根据当前该场景,我们可以用Elasticsearch集群对产品进行索引,这样能超快速地搜索产品。为了以更异步的方式索引Elasticsearch中的条目项,我们可以使用DynamoDB流。

流是按时间排序的数据序列,DynamoDB生成一个个条目项的修改动作流。我们设置一个Lambda函数,它在DynamoDB中创建条目项时被触发。

这个Lambda函数只能由创建条目流触发,它被触发后,提取其中的条目项,放入Elasticsearch索引中,这样前端客户就可以查询elasticsearch,更快速轻松地搜索到自己需要的产品条目。

这时,CTO又得到了管理层的更多指示要求。

随着网站越来越受欢迎,希望实时查看网站指标以获得洞察力:

>谁访问该网站

>访客数量

>在网站上花费的时间

>页面浏览量

>有多少访客几乎买了一个产品并退出

如何在架构中实现实时数据处理?

构建良好的无服务器应用程序的关键支柱之一是“卓越运营”,业务经理应该能够查询监控日志获得业务价值,以下是实时用户事件日志聚合器,它提供了有价值的分析:

该网站托管在S3。我们可以设置AWS Pinpoint服务来记录兴趣点(在Checkout页面/登录页面等等处设置)的用户事件,并将这些事件收集存储到AWS的Kinesis Firehose。

为了分析感兴趣的数据和运行聚合的事件,我们可以使用Kinesis Data Analytics在预定义窗口(基于时间或基于大小)期间的访问流,Kinesis Data Analytics使用SQL查询数据流,它从定义的流窗口创建一个虚拟表并运行SQL查询。我们可以挂钩一个Lambda函数来消费使用Elasticsearch中的信息和索引,一旦数据存在Elasticsearch中,我们就可以使用Kibana或其他可视化工具来直观观察这些数据。

基于人工智能的聊天机器人

我们对该网站又有一个有趣的要求:

为了改善网站的用户体验(UX),作为CTO,决定集成会话机器人,用户可以通过语音搜索和订购项目,机器人将以语音回复用户的所有查询。

AWS Lex是一项托管服务,允许开发人员以简单的步骤创建会话机器人,开发人员不需要是深度学习或NLP(自然语言处理)专家。他们只需要提供几个示例短语和相应的Lambda函数来执行,然后,AWS Lex将创建具有深度学习功能的NLP模型,它将在一段时间内接受培训。

连接到Lex的Lambda函数可以执行很多操作(例如:创建订单),并使用AWS Polly进行语音响应,这是一种文本到语音服务。

无服务器工作流

让我们继续看看前面网上商城的情景。

如果你有三个主要供应商为公司提供库存,需要设置一个工作流程能每次自动以检查库存中产品数量是否有少于5的?如果有就从相应的供应商处下订单;如果无法联系供应商,就将产品标记为少于5个项目,否则更新库存数量为新的数量。

如何将这个工作流分解为一个个步骤?

如何保持请求的状态(跟踪步骤)?

根据这个场景,该公司只有三个主要供应商,所有产品都属于这些供应商之一,如果产品数量小于5,则应从相应的供应商处进行重新排序过程。

Lambda是无服务器应用程序的计算构建块,Lambdas目的是在指定的调用中运行单个操作,当我们为多个彼此依赖的操作添加逻辑时,如果整个操作过程全部完成肯定会超过300秒,那可能也会超时,这就有了一个问题。

实际上,单一责任原则(SRP)是一种很好的设计模式,可以在任何上下文中使用,以实现解耦和可管理的代码单元,因此,AWS引入了Step Function,它提供了一组连接任务(可以是lambda函数)来运行工作流。

当我们跨多个lambda函数分发工作流时,我们如何保持请求的状态?换句话说,我们如何保存工作流的状态呢?从而能表达这个长流程当前位于哪个步骤?

Step Function提供了解决方案,它是一个状态机,能被事件(例如:来自APIGateway的Http调用)调用,并保持运行直到当前这个工作流程完成,这样也就是保存了请求的状态。


上图是状态机的图片,在第一步,它将运行一个lambda函数以获得库存数量少于五个的所有产品;在第二步,它将在有效负载上运行另一个lambda函数,该函数从基于第一步的结果来查询相应产品的供应商;然后它将在供应商上运行一个选择策略,它就像一个普通的开关逻辑,触发相应供应商的重新下单功能(调用供应商的API),如果供应商没有回复,它将触发默认的lambda函数,将当前产品的标签更新为库存少于5个以便后续人工处理。

结论

这篇文章是关于无服务器模式和用例,无服务器架构使我们能够以最低成本从小规模开始,逐步发展具有丰富特性和功能的架构,同时保持架构高度可扩展且经济高效。

Evolving Architecture | Serverless Patterns and Us

[该贴被admin于2018-08-23 13:50修改过]

                   

1