Serverless架构综述

更新时间:2023-05-06 23:07:11 阅读: 评论:0

Serverless架构综述
跟很多其它软件类似,对Serverless还没有清晰定义,但是肯定有两个互相有重叠的定义:
1. Serverless最初是用于描述依赖第三方服务(‘云端’)实现对逻辑和状态进行管理的应用。
典型的包括“厚客户端”(例如单页Web应用、移动应用),他们一般都使用基于云端的数据库(例如Par、Fireba),认证服务(Auth0、AWS congnito)等。这类服务以前被称为“(Mobile) backend as a Service ”,我将在本文中称他们为“BaaS”。
2. Serverless也可以指这样的应用,一部分服务逻辑由应用实现,但是跟传统架构不同在于,他
们运行于无状态的容器中,可以由事件触发,短暂的,完全被第三方管理。(感谢
ThoughtWorks在最近Tech Radar中做出的定义)。这种思路是‘Functions as a Service / FaaS’,AWS Lambda是目前最佳的FaaS实现之一,本文后续介绍中将使用FaaS作为这种架构的缩写。
但是我更愿意讨论的是本领域第二种方式,相比来说技术架构更新,引领了Serverless的很多创新。然而,这两个领域开始融合,一个例子是Auth0,一开始Auth0是作为Baas(‘Authentication as a Service’),但是随着Auth0 webtask的发布,演变成了FaaS应用。
更多场合,当开发基于BaaS的应用时,特别当开发基于web的应用而不是移动应用时,更需要一部分服务端功能。特别当跟正在使用的BaaS整合在一起时,FaaS模式可以作为最佳实践。这类功能包括数据认可(以免客户端恶意攻击)和计算敏感进程(例如图像或者视频篡改)。
例子
UI驱动应用
先讨论一个带有服务功能逻辑的传统面向客户端的三层应用,一个典型的电子商务应用(例如在线宠物商店)。
一般架构如图所示,假如服务端用Java开发完成,客户端用HTML/Javascript:
这种架构中,因为有不少系统逻辑,例如认证、页面导航、搜索、交易等在服务端完成,客户端显得相对不太智能。
采用Serverless架构,开起来如图二所示:
这仅是最简单的视图,但是即使如此,还是有不少改变。请注意并不是建议架构迁移,而是使用这个工具来解释某些Serverless概念。
1. 删除了认证逻辑,而用第三方BaaS服务取代。
2. 使用另外一个BaaS,允许客户端直接访问架构与第三方(例如AWS Dynamo)上的数据子
库。通过这种方式提供给客户更安全的访问数据库模式。
3. 前两点中包含着很重要的第三点,也就是以前运行在宠物商店服务端的逻辑现在都转移到客户
端中,例如跟踪用户访问,理解应用的UX架构(例如页面导航),读取数据库转化为可视视图等。客户端则慢慢转化为单页面应用。
4. 某些我们想保留在服务端的UX相关功能,例如,计算敏感或者需要访问大量数据,比如搜索
这类应用。对于搜索这类需求,我们不需要运行一个专用服务,而是通过FaaS模块,通过API Gateway对http访问提供响应。 这样可以使得客户端和服务端都从同一个数据库读取相关数据。 由于原始服务使用Java开发,AWS Lambda(FaaS提供者)支持Java功能,因此可以直接从宠物商店服务端将代码直接移植到宠物商店搜索功能,而不用重写代码。
5. 最后,可以将‘purcha’功能用另外一个FaaS功能取代,因为安全原因放在服务端还不如
重新在客户端重新实现,当然前端还是APIGateway。
消息驱动应用
一个不同的例子是后台数据处理服务。例如正在写一个面向用户的应用,需要对UI请求快速响应,但是同时还想获取所有发生的行为。我们设想一个在线广告系统,当用户点击一个广告时,希望快速导向目标,但是同时,需要搜集点击量以便向广告商收取费用。
传统的架构,‘Ad Server’同步地响应客户,但是同时还会向异步处理‘点击量’的应用发送一个消息更新,以便以后向广告商收费的数据库。
而Serverless架构则如下:
架构跟我们第一个例子有些许不同,这里我们用FaaS功能取代了一个一直运行的应用。此FaaS运行于方案提供商提供的消息驱动上下文之间。需要注意的是供应商提供了消息代理和FaaS,两者之间更加紧密地合作在一起。
FaaS环境通过复制出若干实例也可以并行处理这些点击,这对开发无疑带来全新概念。
解密 ‘Function as a Service’
我们已经多次提过FaaS概念,现在我们来看看其真正含义。我们先看看Amazon Lambda产品的公开说明。我自己添加了标记,将会逐一展开说明。
AWS Lambda使得用户不需部署或者管理服务就可运行代码(1)…通过Lambda,可以
虚拟化地运行任何类型应用和后台服务(2)—都是免管理的。只需上载代码,Lambda
会管理其他一切(3)并且以高可用模式扩展应用(4)可以配置自动从其他AWS服务激
活代码(5)或者从任何移动应用中调用(6)。
1. 功能上FaaS就是不需要关心后台服务器或者应用服务,只需关心自己的代码即可。与现代其他
架构相比(例如容器和PaaS),这是最大的不同。 如果回到上面所说的点击案例,FaaS代替了点击处理服务器(至少是一台物理服务器,但是绝对是一个特定应用),因为这种架构不需要一台指定服务器,甚至不需要一个一直运行的应用模块来处理。
2. FaaS并不需要特定框架或者库,从编程语言和环境角度更像是一个普通应用。例如AWS
Lambda功能可以采用JavaScript、Python和任何其他JVM语言(Java、Clojure、Scala
等)。Lambda功能可以运行任何其他绑定部署的代码,因此可以用任何可以编译成Unix进程的语言。FaaS功能也有一些架构上的限制,特别当面对状态(state)或者执行区间
(execution duration)的问题,后面我们会提到。回到上面说的点击系统,转到FaaS架构唯一需要更改的代码就是‘main method/startup’代码(示例中被删除了),开始来代码应该是在顶层消息处理器中(‘message listener interface’实现),但却可能只是在方法签名(method signature)的一个小小改变。所有其他代码(例如写入数据库的代码)都没有任何改变。
3. 因为没有应用服务需要部署因此FaaS跟传统架构差别很大,只需要上载代码到FaaS提供者就
足够了。现在这也就意味着上载一个代(例如以zip或者JAR形式),然后调用特定API初始话此更新。
4. 水平扩展是完全自动、弹性,由提供者来管理。如果应用需要并发处理100个请求,提供者将
会处理后台所有需求。‘计算容器’只是短暂运行应用代码,运行完毕后就销毁这些需求。仍然回到点击案例,假如今天运气不错,客户点击了日常点击量的十倍。点击进程能处理这些变化吗?例如,我们设计的代码可以同时处理多条消息吗?即使可以,一个进程可以处理这么多负载吗?是否可以动态自动扩展进程还是需要手工重新配置?有了FaaS,代码只需要处理并发,而其他自扩展功能则由提供者自动处理。
5. FaaS功能是由提供者定义的消息类型触发的。对于Amazon AWS,这些出发包括 S3(文件)
更新,时间(调度任务)和添加到消息总线上的消息(例如kinesis)。代码一般都会提供消息源所需的参数。点击案例中,已经假定我们使用了支持FaaS的消息代理。如果还没有的话,就需要一个,对消息生产者也有同样的要求。
6. 许多提供者允许FaaS功能作为http响应来出发,一般是API网关。例如在宠物商店案例
中,‘arch’和‘purcha’功能。
State状态
FaaS功能如果使用本地状态,会有很多严格限制。简单说需要假设任何进程间或者主机状态对子进程都不可见,包括在RAM和写到本地盘上的状态。换句话说,从一个部署单元来看FaaS功能是无状态的。这一点对应用架构来说影响很大,同样‘Twelve-Factor App’概念对架构也有细致的限制。
考虑到限制,应该如何解决呢?一般来说FaaS功能要么是自然无状态,也就是提供纯功能调用,要么会使用数据库,跨进程见cache(例如Redis),或者共享文件系统(或者S3)来存放状态或者提供处理请求所需的更多输入信息。
Execution Duration执行区间
FaaS功能一般会限制每个功能允许运行多长。目前AWS Lambda功能允许最多运行5分钟,如果超出就被强行退出。这意味着某些长时间运行的任务如果转到FaaS架构,就需要重新设计,也就是说需要多创建几个不同FaaS功能协调器,而在传统架构中,只需有一个就可以了。
Startup Latency启动延迟
目前FaaS功能多长时间会响应跟很多因素有关,其延迟可能从10ms到2分钟。听起来不太好,我们用AWS Lambda举个例子。
加入你的功能用Javascript或者Python开发,也不大(例如小于几千行代码),此时延迟一般不会超过10-100ms。更大的功能有可能会有更长的响应时间。
如果Lambda功能运行在JVM上,当JVM运行时,偶尔会看到响应时间更长(例如大于10秒)的情况,然而对于以下情况,高延迟则会很显著:
应用并不是很活跃,大概每十分种处理一次事件。
突然流量爆发。例如从每秒10次濡染增长到每秒100次。
前者一般可以通过提高响应频次的方法来解决。
这些问题需要考虑吗?的确需要看应用的具体情况。我以前团队用Java开发过一个异步消息处理Lambda应用,每天处理上亿条消息,而且没有启动延迟问题。也就是说不管采用什么开发语言,如果你想写一个低延时交易应用,现在可能并不适合采用FaaS架构。
为了确认应用是否有问题,最好是用生产类型负载测试一下。如果场景不适合,可以考虑转向FaaS 提供商。
API Gateway
关于FaaS我们之前讨论过‘API Gateway’,一个API Gateway是一个http服务器,路由和服务点都在配置里定义,每个路由都跟一个FaaS功能有联系。当一个API Gateway接受请求,找到提供请求服务的路径,然后调用相关FaaS功能。一般API Gateway允许将http参数映射成FaaS功能需要的输入参数。API Gateway将FaaS功能结果转换为http响应,返回调用者。
Amazon Web Services等云服务提供商都各自提供自己的API Gateway。
除了API Gateway路由请求需要认证,输入验证,相应代码映射等,有时候可能还会想是否这是个好主意,那么让我们更深入论证一下。
APIGateway+FaaS的一个应用场景就是用Serverless方式创建http前端微服务,充分利用扩展,管理和其它与FaaS功能有关的其它优点。
目前API Gateway开发工具并不太成熟,因此定义API Gateway应用时候最好不是非常核心的引用。
Tooling工具
API Gateway工具不太成熟事实上也同样适用于Serverless FaaS。然而有些例外,例如Auth0 Webtask将大量重要UX开发放在自己的工具上。Tomasz Janczuk在最近的Serverless会议上给出了很好的演示。
排错和监控对于Serverless应用有点儿需要技巧。我们后续会谈到它们。
Open Source开源
Serverless FaaS目前最大优势就是产品安装部署透明,因此开源对这块的影响并不是像对其它领域,例如Docker和容器。未来有可能出现FaaS/API Gateway平台会运行在云或者工作站上。IBM 的OpenWhisk是这样一种实现,看这样的平台如何演变也是很有意思的事情。
除了运行部署,其它开源工具和框架用于定义,部署和运行时支持,例如Serverless Framework跟API Gateway+Lambda结合比AWS更早。尽管很依靠Javascript,但是如果你写JS API Gateway 应用,绝对值得一试。
另外一个例子是Apex,一个用于简化AWS Lambda功能安装,部署和管理的工具。Apex很有趣的一个地方在于可以选用Amazon并不直接支持的语言(例如Go)来开发Lambda功能。

本文发布于:2023-05-06 23:07:11,感谢您对本站的认可!

本文链接:https://www.wtabcd.cn/fanwen/fan/89/862808.html

版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。

标签:应用   功能   需要
相关文章
留言与评论(共有 0 条评论)
   
验证码:
推荐文章
排行榜
Copyright ©2019-2022 Comsenz Inc.Powered by © 专利检索| 网站地图