博文精选 | 我的 Serverless 实战——引领云计算的下一个十年

2021-07-23 10:09:37

F5小安

PHPWord

文章速览:

 

行业:互联网

 

关键字:Serverless、云计算、前端、研发运维

 

摘要:如今,越来越多的大厂企业开始大规模使用 Serverless,处于变革中的开发者,大多已从观望状态转向尝试阶段,越来越多 Serverless 落地场景被解锁。作为基础研发底座,越来越多企业开始接受 Serverless,并将其应用于业务实践中。预计 Serverless 架构将引领云计算的下一个十年已成为共识。这个 Serverless 不仅适合与小场景,同样适用与大厂秒杀,12306 抢票的大业务场景。Serverless 不是不需要 Server,而是需要我们前端较少的关注服务器端,前端程序员可以好好研究一下。

 

阅读时长:10分钟

 

 

以下文章来源于InfoQ!作者:孙叫兽

 


前言:如今,越来越多的大厂企业开始大规模使用 Serverless,处于变革中的开发者,大多已从观望状态转向尝试阶段,越来越多 Serverless 落地场景被解锁。作为基础研发底座,越来越多企业开始接受 Serverless,并将其应用于业务实践中。预计 Serverless 架构将引领云计算的下一个十年已成为共识。这个 Serverless 不仅适合与小场景,同样适用与大厂秒杀,12306 抢票的大业务场景。Serverless 不是不需要 Server,而是需要我们前端较少的关注服务器端,前端程序员可以好好研究一下。

培养自己的 Serverless 思维与认知

以前很多开发者都是采用的单体架构,为了保证服务的稳定性,只需要维护一台服务器及数据库就可以啦,但是随着业务的增长会面临两个问题,如果流量比较大,这个服务器可能顶不住这么大的流量,其次硬件啥的损坏也会导致整个系统瘫痪。

 

解决这个问题的办法就是使用负载均衡,分担各个服务器的压力。然后整个系统就有一定的水平伸缩能力,如果一台服务器坏了,其它的服务器也能正常运行,保证系统稳定运行。

 


随着业务的进一步增长,增加大量的开发人员去处理这种单体应用,就会出现大量的冲突问题,这个就需要管理者进行人工协调,公司整体研发效率比较低,后台大家想到一个好办法就是把这个单体应用分为一个个独立开发、测试及部署。每个环节都是独立而又有一定的联系,这个就是微服务的雏形。服务和服务之间采用 API 通信,这种微服务架构大大提升了研发人员的工作效率。


再到后来,估计大家都有所了解,如果从物理的角度思考这个问题就会发现分布式的一些困难与挑战,比如大家使用分布式服务及框架,使用一些 Redis 缓存、配置服务 ACM 以及分布式追踪系统等。这个微服务架构给运维也带来不少的难题,感觉运维大哥都快成全能底层人才了,以前运维只需要维护一个应用,现在估计一个人都得看几十个、几百个应用。对应用分发、自动化弹性等能力有一定的要求。


现在很多人都谈云计算,云架构,简单理解就是这个架构长在“云”上就是云架构。 有了应用分发的标准和生命周期的标准,云就能提供标准化的应用托管服务。在整个架构的演变的过程中,我们发现,研发运维人员希望用平台系统的去管理机器,而不是人去管理这些个玩意。这可能就是 server is less.


Serverless 的使用价值及常见的架构模式


我们抛去这些抽象的概念,看一下这个 Serverless 的使用价值主要有以下几点:


1.不用过多的关注服务器。

(Serverless 平台具备自动识别故障,移除故障的能力)

2.自动弹性。

(Serverless 平台自动及时稳定的实现自动弹性)

3.按照实际资源的消耗进行计费。

(Serverless 模式下,按照实际消耗资源及使用存储进行计费)

4.更少的代码,更快的交付速度。

(Serverless 提供成熟的代码构建发布、版本切换等特性,交付速度更快)



Serverless 由开发者实现的服务端逻辑运行在无状态的计算容器中,它由事件触发, 完全被第三方管理,其业务层面的状态则被开发者使用的数据库和存储资源所记录。Serverless 涵盖了很多技术,分为两类:FaaS 和 BaaS。


FaaS(Function as a Service,函数即服务)


FaaS 意在无须自行管理服务器系统或自己的服务器应用程序,即可直接运行后端代码。其中所指的服务器应用程序,是该技术与容器和 PaaS(平台即服务)等其他现代化架构最大的差异。


FaaS 可以取代一些服务处理服务器(可能是物理计算机,但绝对需要运行某种应用程序),这样不仅不需要自行供应服务器,也不需要全时运行应用程序。


FaaS 产品不要求必须使用特定框架或库进行开发。在语言和环境方面,FaaS 函数就是常规的应用程序。例如 AWS Lambda 的函数可以通过 Javascript、Python 以及任何 JVM 语言(Java、Clojure、Scala)等实现。然而 Lambda 函数也可以执行任何捆绑有所需部署构件的进程,因此可以使用任何语言,只要能编译为 Unix 进程即可。FaaS 函数在架构方面确实存在一定的局限,尤其是在状态和执行时间方面。


在迁往 FaaS 的过程中,唯一需要修改的代码是“主方法/启动”代码,其中可能需要删除顶级消息处理程序的相关代码(“消息监听器接口”的实现),但这可能只需要更改方法签名即可。在 FaaS 的世界中,代码的其余所有部分(例如向数据库执行写入的代码)无须任何变化。


相比传统系统,部署方法会有较大变化 – 将代码上传至 FaaS 供应商,其他事情均可由供应商完成。目前这种方式通常意味着需要上传代码的全新定义(例如上传 zip 或 JAR 文件),随后调用一个专有 API 发起更新过程。


FaaS 中的函数可以通过供应商定义的事件类型触发。对于亚马逊 AWS,此类触发事件可以包括 S3(文件)更新、时间(计划任务),以及加入消息总线的消息(例如 Kinesis)。通常你的函数需要通过参数指定自己需要绑定到的事件源。


大部分供应商还允许函数作为对传入 Http 请求的响应来触发,通常这类请求来自某种该类型的 API 网关(例如 AWS API 网关、Webtask)。


BaaS(Backend as a Service,后端即服务)


BaaS(Backend as a Service,后端即服务)是指我们不再编写或管理所有服务端组件,可以使用领域通用的远程组件(而不是进程内的库)来提供服务。理解 BaaS,需要搞清楚它与 PaaS 的区别。


首先 BaaS 并非 PaaS,它们的区别在于:PaaS 需要参与应用的生命周期管理,BaaS 则仅仅提供应用依赖的第三方服务。典型的 PaaS 平台需要提供手段让开发者部署和配置应用,例如自动将应用部署到 Tomcat 容器中,并管理应用的生命周期。BaaS 不包含这些内容,BaaS 只以 API 的方式提供应用依赖的后端服务,例如数据库和对象存储。BaaS 可以是公共云服务商提供的,也可以是第三方厂商提供的。其次从功能上讲,BaaS 可以看作 PaaS 的一个子集,即提供第三方依赖组件的部分。


BaaS 服务还允许我们依赖其他人已经实现的应用逻辑。对于这点,认证就是一个很好的例子。很多应用都要自己编写实现注册、登录、密码管理等逻辑的代码,而对于不同的应用这些代码往往大同小异。完全可以把这些重复性的工作提取出来,再做成外部服务,而这正是 Auth0 和 Amazon Cognito 等产品的目标。它们能实现全面的认证和用户管理,开发团队再也不用自己编写或者管理实现这些功能的代码。


函数计算介绍及其应用


从用户角度,他需要做的只是编码,然后把代码上传到函数计算中。上传代码就意味着应用部署。当有高并发请求涌入时,开发者也无需手动扩容,函数计算会根据请求量毫秒级自动扩容,弹性可靠地运行任务,并内置日志查询、性能监控、报警等功能帮助开发者发现问题并定位问题。


函数计算是事件驱动的无服务器应用,事件驱动是说可以通过事件源自动触发函数执行,比如当有对象上传至 OSS 中时,自动触发函数,对新上传的图片进行处理函数计算支持丰富的事件源类型,包括日志服务、对象存储、表格存储、消息服务、API 网关、CDN 等。


除了事件触发外,也可以直接通过 API/SDK 直接调用函数。调用可以分为同步调用与异步调用,当请求到达函数计算后,函数计算会为请求分配执行环境,如果是异步调用,函数计算会将请求事件存入队列中,等待消费。

函数的测试与部署


服务是函数计算资源管理的单位,同一个服务下有很多函数,这些函数共享服务的网络 配置、权限配置、存储配置、日志配置。 服务可以对应成一个“应用”,这个应用由很多函数共同组成,这些函数具有相同的访 问权限、网络配置,日志也记录到相同的 logstore。这些函数本身的配置可以各不相同, 比如同一服务下有的函数内存是 3G,有的函数内存是 512M,有些函数用 Python 写, 有些函数用 Node.js 写。


开发流程


函数测试部分,Serverless 稍微薄弱一点,软肋,这个调试一般可以采用云调试、命令行工具、VSCode 插件、无工具调试等方式,具体怎么调试我就不一一说明了,有兴趣的可以尝试一下。


至于部署,比较简单,我们可以使用在线部署、客户端部署(通过命令行工具、通过 VSCode 插件)。命令行工具的 - h 指令真的很棒, 无论使用什么指令,我们都可以通过 - h 查看到使用方法。


Serverless 容器服务及部署


Serverless Kubernetes 是以容器和 kubernetes 为基础的 Serverless 服 务,它提供了一种简单易用、极致弹性、最优成本和按需付费的 Kubernetes 容器服务, 其无需节点管理和运维,无需容量规划,让用户更关注应用而非基础设施的管理。我们可以把把 Serverless Kubernetes 简称为 ASK。


当下各大云厂商都推出了自己的 Serverless 容器服务,上图为 Gartner 评估机构 整理的 Serverless 容器产品 Landscape,其中阿里云有 Serverless Kubernetes ASK 和 ECI;AWS 有 Fargate,基于 Fargate 有 EKS on Fargate 和 ECS on Fargate 两种形态;Azure 有 ACI。另外 Gartner 也预测,到 2023 年,将有 70% 的 AI 应用以容器和 Serverless 方式运行。


在对 Serverless Kubernetes 的基础概念有了充分了解之后,我们直接进入容器服务控制台进行集群的创建。集群创建完成后,接下来我们部署一个无状态的 nginx 应用,主要分成三步:


1.应用基本信息:名称、POD 数量、标签等; 

2.容器配置:镜像、所需资源、容器端口、数据卷等;

3.高级配置:服务、路由、HPA、POD 标签等


创建完成后,在路由中就可以看到服务对外暴露的访问方式了。


Serverless 应用引擎


主要的挑战:


1.开发难度和入门门槛高,业务轻量化困难,不能平滑地迁移现有应用 ;


2.担心被云厂商锁定,如 FaaS 形态的 Serverless 产品,每个厂商都希望推出自己的 标准,缺乏开源的规范和开源的生态支持。相似的一幕曾经在容器领域上演,直到后来 Kubernetes 成为事实标准,Serverless 还在寻找自己的事实标准;


3.如何方便地本地开发调试、监控,和现有业务做深度整合。


低门槛,无需任何代码改造就能直接使用的 Serverless PaaS 平台(SAE),是企业在线业 务平滑上云的最佳选择。


SAE 提供了成本更优、效率更高的应用托管方案。底层基于统一的 K8s 技术底座, 帮用户屏蔽复杂的 IaaS 层和 K8s 集群运维,提供计算资源、弹性、隔离性等能力,用 户只需关心应用实例的规格和实例数。 在应用层,除提供了生命周期管理、多发布策略外,还提供监控、日志、微服务治理能 力,解决应用可观测性和治理需求。同时提供一键启停、应用编排等高级能力,进一步提效 和降本。核心场景主要面向在线应用:微服务应用、Web 应用、多语言应用等。 在开发者工具方面,和 CI/CD 工具做了良好的集成,无论是 Jenkins 还是云效,都 能直接部署应用到 SAE,也可以通过 Cloud Toolkit 插件工具实现本地一键部署应用到 云端,可以说 SAE 覆盖了应用上云的完整场景常见的业务场景及经典案例。

至于行业一些经典案例这个场景,这个简单提一下 ,不过多介绍,有兴趣的可以查阅项目资料。

比如:Serverless 应用引擎弹性伸缩实践、基于函数计算实现 AI 推理、基于函数计算实现快速建站、基于函数计算快速搭建 Hexo 博客系统等等,然后再提一下相关的产品吧,比如函数计算(Function Compute)是一个事件驱动的全托管 Serverless 计算服务, 您无需管理服务器等基础设施,只需编写代码并上传,函数计算会为您准备好计算资源,并 以弹性、可靠的方式运行您的代码。Serverless 应用引擎(Serverless App Engine,简称 SAE)实现 Serverless 架构 + 微服务架构的完美融合,真正按需使用、按量计费,节省闲置计算资源,同时免去 IaaS 运维,有效提升开发运维效率。弹性容器实例 ECI 提供安全的 Serverless 容器 运行服务。您无需管理底层服务器,只需要提供打包好的 Docker 镜像,即可运行容器, 并仅为容器实际运行消耗的资源付费。GPU 云服务器基于 GPU 应用的计算服务,多适用于 AI 深度学习、视频处理、 科学计算、图形可视化等应用场景等。


好啦,本期内容就分享到这里,我们下期见!

 

 

以上是针对Serverless的分享,希望对大家有帮助!

 

 

 

阅读原文

 

声明:本文章版权归原作者及原出处所有 。凡本社区注明“来源:XXX或转自:XXX”的作品均转载自其它媒体,转载目的在于传递分享更多知识,内容为作者个人观点,仅供参考,并不代表本社区赞同其观点和对其真实性负责。本社区转载的文章,我们已经尽可能的对作者和来源进行了注明,若因故疏忽,造成漏注,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本社区拥有对此声明的最终解释权。

 

 

 

你还不能错过:

 

让云计算真正安全落地 - “F5跨越百城市巡展”简报

发布评论 加入社群

发布评论

相关文章

博文精选 | 人工智能企业的未来

F5小安

2021-09-22 11:09:13 5

博文精选| 大型互联网系统常用的技术方案

F5小安

2021-09-16 14:30:36 15

博文精选| 大型互联网应用面对的挑战及应对方案和手段

F5小安

2021-09-15 15:27:31 16

Login

手机号
验证码
© 2019 F5 Networks, Inc. 版权所有。京ICP备16013763号-1