Serverless 应用引擎 SAE:让应用管理如此简单

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
云效 DevOps 流水线,基础版人数 不受限
云效 DevOps 制品仓库,基础版人数 不受限
简介: 本次课程由阿里云智能集团高级技术专家赵庆杰分享,主题为“Serverless 应用引擎 SAE:让应用管理如此简单”。课程涵盖四个主要部分:降本增效、功能场景、关键技术与客户案例。SAE 引擎通过按量付费、弹性伸缩等特性简化应用管理,帮助企业将更多精力投入到 AI 应用和业务价值上。SAE 提供了低门槛微服务架构转型、应用快速上云、一键启停环境、高可用方案及 CI/CD 解决方案等功能。此外,还介绍了高等教育出版社使用 SAE 进行云原生改造的案例,展示了其在降本增效、提升研发效能和安全性方面的显著成果。

Serverless 应用引擎 SAE:让应用管理如此简单

 

内容介绍:

一、降本增效

二、功能场景

三、关键技术

四、客户案例

 

本次课程的主题是“Serverless 应用引擎 SAE:让应用管理如此简单”,由阿里云智能集团高级技术专家赵庆杰分享。

本次课程看似与AI的关联度较低,但实则与后续AI应用与学习密切相关。如今AI应用是一个领域需要大量的时间学习,如卷积神经网络AR大模型等。本次课程内容是非常关键的一部分,包括如何管理存量应用(如非AI应用)以节省时间到AI应用能力。

本次课程共分为四个部分,即降本增效、功能场景、关键技术与客户案例。

 

一、降本增效

Serverless场景与成本和人效的关联度很高,如果使用AI可以有效降低成本提高人效。通过对近几年Serverless年度新增应用数、AI应用占比、微服务占比、应用实例数以及使用AI成本的降幅等几个数据的分析,可以发现很多的企业已经意识到了应将大量的时间放AI应用上,多的企业使用Serverless场景帮提高人效降低成本。

1、Serverless SAE引擎的作用

Serverless SAE引擎的作用非常明显,包含阿里云团队在内,都是从独立的云账号开始起,一开始可能无需经过任何管控,仅仅以机器为单位进行使用,结果月底发现了巨额的账单,为了降低成本,在删除时删除了标题为test的机器,可能会产生故障。或者应用流量大幅上涨则需要扩容,可能会在ECS场景下找不到相应的节点也可能在扩容后对故障未产生预期的有利作用,这会使我们非常被动。SAE引擎可以帮助们解决这问题。

高可用场景,最近也发生了几起故障,但使用Serverless SAE引擎运行的业务恢复非常快,也就是说Serverless SAE引擎帮助业务方做了高可用的建设来达到整体的稳定性。

2、Serverless的价值

Serverless 的价值非常广泛除此之外还有很多,这里不做一一介绍。总之,可以按量付费,弹性伸缩,省事省心,一些复杂没有核心价值或对业务帮助的繁杂的琐事都可以交给Serverless完成从而把主要的精力放在AI应用或AI的业务价值上。

 

二、功能场景

Serverless引擎应用(SAE)已经一款非常稳定成熟的产品它的功能面非常多,本节课就其几个关键的、最近更新的功能进行介绍。

1、SAE的优势

首先,SAE一个包资源的产品,在使用时无买单独的机器,也无需再ECS机器以及其他的一些计算付费。SAE包装使其实例计费,实例以容器维度,小规格可达0.5C们的应用只需通过相应的文件编译成镜像即可SAE运行

其次,SAE底层的技术是基于阿里云的基础设施,神龙物理机,进行了虚拟化的动作吧,还使用了其他的技术,如通过镜像加固架构实例的启动

包装成产品之后,上层应用部分添加了微服务治理,尤其是全链路灰度的能力,这一功能在电商类的场景作用明显全链路一起请求会涉及到很多模块,库存订单等,链路非常长如果做发布变的时需要进行灰度,在ECS上可能需要动进行,在SAE场景下已经默认集成了这些能力。

此外上层应用的模型方面也就是指何种应用可以在SAE运行。对于SAE来说,应用不限制业务类型,只要做成相应的镜像,即可在上运行在SAE。关于这一能力,其与函数计算不同函数计算需要一定的改造成本,但SAE只需应用打包成镜像上传即可运行,并且微服务的配套的设施也无需很多的迁移成本,只需与SAE进行高度集成即可

通过企业反馈以及内部运行得出一些SAE的数据,可以看到他的启动效率很高,提效明显。

2、SAE的功能

包括低门槛微服务架构转型、应用快速上云、一键启停环境的解决方案、面向大促的高可用方案、CI/CD解决方案、作为PaaS底座被集成等等。我们可以通过开发态从CI/CD的集成(如云效以及自研应用平台直接对接应用,使用一些插件对接完成,即可通过github提交代码,通过预定的发布流程进行应用部署。

3、SAE安全防护

安全防护的能力是今年全力集成能力。我们发现大量的应用可能已经存在了一些隐性的自变异的病毒,如近期发生的AK、SKD泄露事件,它们都会导致应用被植入自变异的病毒,应用可能已经在不知不觉间运行了一些挖矿程序。SAE高度集成了安全防护能力,只需一键开启即可使用,帮助我们发现隐藏病毒

关于安全防护,我们可以从以下几个角度进行:

在我们使用一些开源组件时,尤其是现在的软件大部分哦都使用了开源组件,这些组件可能会存在风险,可能会被漏洞程序侵入,通过SAE安全扫描进行扫描。在发现漏洞之后,SAE提供可一些建设性的漏洞修复方案,包含恶意文件检测或配置风险。只需打开SAE的开关,即可使用SAE集成的安全防护能力

4、功能详解

(1)应用托管

应用托管是最基础的功能,通过平台我们可以实现可灰度回滚和可观测,这些能力都基于此前进行了改版,目前只完成了一部分用户的灰度。灰度是研发平台是最关键的几个步骤,它的完成与否会极大影响业务整体的稳定性。任何平台都有改进空间,阿里云目前已支持单批发布分批发布等等

(2)全套微服务治理

①无损下线

它与微服务治理能力进行了结合。对于微服务,在下线时如果进行重启必然会影响业务,在消费端结合SAE无损下线即可避免对业务的影响。对于普通的微服务,在服务下线时首先会停机,但在停机过程中由于客户端存在延迟,仍有部分请求传入,这段延迟时间内请求的处理就会受到影响。在结合了SAE无损下线后,在请求上加上了特殊的标签,服务变更会主动通知到消费端,待客户端发现后,上册注册中心即可感知到,进而及时更新列表,保证prestop的无损下线。

②无损上线

它是业界的一个标准方案。如果K8S通过readiness检查进行无损上线,若要自研还需要进行相应的开发,如要对初始化的readiness进行集成,一般是依靠端口检测,但由于微服务应用启用时间太长,我们很难判断内部应用是否启动,如果应用上线过快,整体应用可能会处于不可用的状态。SAE对readiness做了内部的集成,预留了一些接口,无需做任何研发,即可让微服务真正启动,确保readiness检查的正常顺利进行上层应用也无需更多地确认健康状态即可使用。此外,如果应用还未预热,可以通过小流量配置相应的时间,逐步地放大流量,直至应用全线启动。

③端到端全链路灰度

在长请求链路下,请求可能会经过5-6个模块,要控制这个完整的灰度链路,我们可以使用全链路网关在上游对新旧版本进行区分,新的流量可以通过网关打上一个标签,这样全链路均可使用设计好的甬道,即灰度版本的链路。如果没有这项能力,我们可能会有多套环境,如测试环境可能回到多个预发环境,则会造成资源的浪费,在使用全链路网关后,我们可在一个环境内进行多版本的测试或A/B test。

(3)运维配套

①CICD的集成

尤其是应用类的研发平台,它需要与内部系统、Jenkins、阿里云云效进行集成,通过与CICD的集成可以使得整个流程更加平滑。SAE封装了一些插件,只需在Jenkins等上安装(云效上直接加载)这些插件即可使用SAE的CI和CD(自动化部署集成解决方案)的能力,当然还存在一定的改进空间。

②基于请求的弹性能力

对于新研发的Web场景,该场景是基于请求的弹性能力,即缩0。函数计算是基于函数维度,SAE较其力度较大,如应用维度可以基于请求缩0,进而实现实例级别的启动,实现降本,当然要考虑冷启动的时间。

(4)ARMS:云原生可观测平台

SAE与ARMS进行了深度的集成,如基础架构下基础资源的云监控,我们可以使用标准的API接口对接,直接使用Prometheus、Grafana的数据。上层应用中,SAE默认集成了日志采集客户端,只要安装配置相应的插件,即可搜集日志,即可使用日志的告警、监控,以及ARMS、JVM的相关能力。

这里着重介绍ARMS链路。课程中展示了JVM的监控,JVM的多线程的队列会影响性能、内存及应用的启动状态等。对于这些问题的排查目前的监控就已经细粒度到内存和线程的状态并且火焰图分析内存的使用CPU是否存在热点,这些已经默认集成在SAE的控制台上。目前虽然只支持Java,但其他的多语言能力已经在研发过程中了

 

三、关键技术

这里分享今年SAE场景下重点优化的功能这些功能对于SAE或应用管理非常重要,把更多的时间放到AI应用上,而把不重要的非核心链路的工作放在SAE完成,管理节约的时间。除了功能性的优化,还做了实例的弹性加速,以及系统类的冷启动加速,这里选取了几个重点进行分享

1、实例的弹性

(1)单体应用百毫秒、微服务2秒

结合了标准的K8S指标,再加上更灵敏的弹性比开源的延时性更低,当发现指标不满足可以进行快速的扩缩指标,可以通过基础的CPU 、Mem、QPS做设置,也可以做定时特别是秒杀的场景,这一点很多的弹性策略都无法满足但可以结合定时的场景做这扩缩容。还有混合弹性,即定时加弹性的指标同时扩有一个客户会在每周六的早晨8点做考试类的应用可能会有几万人参与,但在考试结束后资源可以立马释放,这就用到了混合弹性的策略8点定时扩1000个实例,在用户使用完后再自动地在11点进行缩。当然,缩的指标除了定时之外可以根据CPU设比例进行自动的

(2)突破Java冷启动瓶颈,提速40%

特定的IDK运行时做加速,即AppCDS技术目前已经比较成熟的一项技术,流行度较高的JDK做了集成,已经线上运行,可以在SAE控制台上直接选择使用冷启动加速的能力。

2、VPC访问模式加速演进

pod实例在冷启动应用启动挂载非常耗时,特别是VPC或跨VPC的场景插拔应用网卡。在此情境下,我们做了overlay网络相当于代理的能力可以加度网卡的插拔。

3、缓存能力

SAE做了四层缓存基层是物理盘,物理盘之上是本机云盘,可以直接读取云盘的镜像等云盘之后挂载了NASNAS的网盘最后一层是OSS盘。这是内部技术无需用户过多关心即可使用相应的Serverless Caching能力镜像的加速等。表格展示了目前Serverless存储可以支持的水平除了做应用层面的管理,还有内部研发的核心竞争力,更多地,与自建的K8S其他开源的产品相比Serverless caching优势明显。每个自建的产品,如自建K8S可能面临的问题是,自建的存储加速能力都需要团队维护但在SAE场景下进行了默认集成,只需在控制台上一键开启或一键使用,就可以直接使用目前的能力。这也是SAE的核心竞争力。

 

四、客户案例

目前很多行业特别是互联网类的企业,已经使用了SAE,本节课介绍了教社使用SAE做应用管理的案例

高等教育出版社——云原生Serverless改造的探索之路

(1)背景介绍

高教社建设于1954年5月18日,迄今为止已有70年的历史,是一个较为传统的行业,教育出版,包括普通高等教育职业教育继续教育专业学术类教育,是全国最大的单体出版社业务覆盖了教育出版主题与学术出版融合发展研究与评价产品有图书音像制品电子出版物网络出版物期刊在线教育和数据服务。其中,在线教育和数据服务是在传统的主业基础之进行了很大的探索,推进的数字产品包括新形态教材数字教材电子书有声书专题资源库数字课程虚拟仿真实验等各种数字产品不断的丰富和扩展,建设了数字出版云平台实验空间、iSmart、爱习题、高校书苑等平台。这些平台建设的基础上,2021年承担了国家智慧教育平台的建设国家智慧教育平台分三横”“三纵,其中两横高等教育职业教育都由高教社承担),又提了更高的要求。高教社又建设了统一资源中心统一支付中心统一安全中心智能审等一系列平台,并持续优化。

①高教社数字化现状

在2019年年初,高教社就跟阿里云接洽合作,当时阿里云已经提出了中台战略,在合作伊始,就提出了双中台的概念,即云原生技术中台数据中台。云原生技术中台以原生云为特色充分利用原生的能力把云原生的技术用到技术中台其中蓝色代表对外服务的系统,高教社采用公有云服务提供外服务,黄色代表的是内部的信息系统,早在2003年就启动了SAP系统的建设,这也是在国内较早采用SAPERP的企业。所以内部的信息系统年之前就全部实现了设备虚拟化。高教社也期望内部的虚拟化走向云原生方向

内部的虚拟化是指内部信息全部部署在内部的虚拟机上,同样,外部的系统全部部署在外部虚拟机公有云上。云原生技术建设的是数据中台把多个系统数据的采集传输加工处理清洗治理等一系列的操作合并成统一资源中心。实际上,高教社还未实现数据治理是完成了数据的整理,将数据的统一存储传输加工集合后建设数据中台,管理中心数字大屏专题库三个模块统一起来形成了统一资源中心。在统一资源中心之上,高教社在探讨业务是否还可以抽象

一个是用户要把所有的用户统一起来不仅仅是单点登陆而是以微服务的方式和SDK的方式把用户中心植入到各个平台,现在大约有一半以上的系统都接入了用户中心的服务。用户中心提供了统一的登录认证统一的用户信息更新用户中心提供的统一的运营统一消息,更重要的是,用户中心是服务的方式外提供服务,但目前期望和现实还有一差距

我们期望所有的平台不存用户密码存储用户相关的表只通过用户中心提供服务,这不仅仅是技术的变革,更是一场思想观念的变革。用户中心之上还抽象了统一的支付中心,因为大量的业务系统存在付款的问题,所有的支付都通过支付中心进行,支付中心内部的SAP结算系统完全绑定,这也是其中的一个优势。除此之外,还抽象了教材课程考试等产品中心,还提供了实例搜索中心营销中心审核中心智能客服等一系列的中台以这种能力外提供服务。

数据中台之上建设的业务平台,业务平台基于技术中台用户要基于数据中台的用户,业务业务中抽象结合。高教社在承担国家的平台建设以来,从2021年开始参加了教育部公安部的各种网络安全演习所以网络安全的要求也高,因此建设了统一安全中心所有的平台都是在统一安全中心之下建设的因此,建设的中台系统和业务系统要实现的就是统一的管理和赋能业务,在建成几个大的中心之后用于支撑各个平台的开发和运维

②数字化转型遇到的问题

在转型的过程中,高教社也遇到了很多问题。第一,在上云原生之前,有海量的ECS实例,有近千台的虚拟机,对于这些数量庞大的虚拟机管理的难度很大,且运维人员的能力也严重不足,近两年要做90个项目60个供应商,很多运维工作进行了外包,完全不可控系统的稳定性难以保障。在基础上,原本是单体应用,服务器的应用也符合潮汐规律,在上班上课海量用户大量入,需要快速扩容,而周末访问量骤减,造成资源闲置。单体的应用在扩容上产生了很大的成本。因此高教社开始探索云原生之路。

2探索过程

①云原生的基本思路

高教社的云原生探索之路未涉及微服务改造。谈到云原生改造可能首先就要谈微服务的改造。微服务改造是一件非常复杂的问题,首先要把目前的主机变成容器,主机的上线变成自动化的部署CICD。这也是高教社云原生的两个主要方向,即K8S的集成和CICD的部署。

②云原生改造路径

高教社把云原生分为了四个层面

第一,开发云原生。首先,研发云原生,即研发流程要符合devops的理念,而高教社大部分研发人员非内部人员,而是外包给了其他公司所以devops操作在推广过程遇到大的困难和阻力。其次,需要集成的代码检测能力开发可以交给任何公司开发但在上线一定要通过自己的安全检测,所以代码检测能力是高教社强烈需求。同时还需要完善代码管理平台,很多开发部署工作源代码的获取存在滞后性,无法区分其内在逻辑,也无法保证获取的代码就是上线的代码。因此,所以要。首先工具平台需要代码管理项目管理文档管理。在开发部署中,最重要是自动化部署的能力,即需要开发一系列的流水线,使得开发之后的过程可以自动化部署。

第二,计算原生。它分为三个部分,第部分是容器化和Serverless化。之前大部分的代码都是使用JAVA开发的,JAVA项目在tomcatspring bot上有状态所以第一步就是要把项目做无状态的改造,第二步是服务器的容器化改造。这两个层面,容器化改造相简单无状态的改造比较复杂,涉及到代码层变动第二部分,充分利用SAE的弹性做到自动弹性扩缩容和运维;第三部分,全面的故障容灾网站的需要监控保障系统安全,尤其是在重点区域在探讨跨云的容灾能力。

第三,架构云原生。我们需要微服务的拆分,实现极简的研发加运维的模式。架构云原生是与阿里合作的统一资源中心的微服务改造。

第四,数据云原生要把所有的数据存储和历史数据迁移上云。问题有可能比较复杂,如在安全攻防时,网站上现了码或链接,开发人员会被它传到OSS,但在传小文件把文件传到本地服务器,可能会造成病毒的侵入。所以数据云原生是改造重点,把所有的数据全部上

在实施改造过程中,按照前面的思路提供了原生改造容器化改造的能力构建了统一的工具平台实行了基于云效的流水线部署。

③集成云效流水线CI/CD

流程:

开发人员开发相关的厂商通过git提交代码之后,首先要对所有的代码进行扫描扫描完成后,使用云的能力做代码的评审和合并,当然也有可能交给开发的厂商完成。然后把合并情况生成可以发布的分支后,使用代码做编译和构建构建完成后进行测试验证,再通过人工触发。测试之后先分三个环境,测试环境环境和生产环境。测试环境通过后,经人工触发实现编译构建,实现预发部署。预发部署验证通过后进入生产环境。

好处

原来单体部署的没有容灾、扩容成本高无法满足业务需求的环境变成了可弹性的简单的部署流水线的开发。如果顺利的情况下,仅需要两分钟。如果不太顺利,不超过2天。其中大量的时间不是开发的时间,而是业务方沟通的时间。

高教社云原生改造从2019年开始,图中有20+个项目,每项目都设定好负责人优先级处理能力需要改造的内容、容器化是否是统一代码统一存储等。

3改造成果

①改造历程

2019年一个K8S网站上线之年,我们将其定义为高教社云原生的元年2020年开始在技术部门内部做推广把较好的网站上K8S系统,2021年内部实现了普及。同时,从2021年开始基于云效建设的流水线启动了云原生改造的计划,也自研了全部的容器化部署平台。2023年,在内已全部铺开同时,内部的CICD建设进一步推进现在有三个人在负责CICD改造,云原生计划稳步实施。今年全面推进CRT的建设云原生也纳入了高社软件开发的管理规范发布了高校生内部的软件开发管理规范,发现有几十家供应商开发操作存在规范性问题,质量无法保障。首先,从制度的方式保障平台的质量,同时制定相应的标准,确保云原生改造的规范,包括用户中心也要纳入管理考核规范的标准

②改造成果

到2024年已经运行了160条流水线有260个容器在执行相关的操作。

4经验分享

①建设了统一的资源中心

高教社与阿里云合作建设的统一资源中心平台源自于社原来内容管理系统,这个系统始建于2005年,也有几个明显的优势。第一,该系统最先提出SOA架构基于服务的原生架构);

第二2008年提出系统要基于可拖拽图形化实现系统的架构,在2018年之前就开始探索内容管理系统是否前进一步建设中台架构。在中台架构之上也启动了云原生的微服务改造。之前系统都是单体应用平台获得了2021年国家新闻出版总署的出版行业科技创新与师范项目,该项目的特色就在于基于数据中台和业务中台双中台架构,通过构建统一的数据模型标准统一的数据采集同步机制汇聚了高教社的各种数据,同时又借助之后的大数据人工智能相关的平台为数据赋智,为业务赋能。到2022年年底,ChatGPT出现人工智能爆火数据中台也为之后人工智能的建设提供了非常大的数据源。

在平台建设的过程中,也有几个问题是原来的系统未解决的。一,中台数据整体的存储架构未能实现所有的数据上云快速响应。之前的平台上线多以周记这次改造的目的就是要平台实现一天内上线包括平台的监控、微服务的拆分平台的服务double的框架在之上做微服务的开发平台的devops开发运维上线部署连在一起,即SAE的架构。

通过平台的建设,我们总结几个经验。

第一,降低服务成本。之前平台上线需要十几台服务器运行微服务拆分后仅需13个微服务应用。13个微服务又分了三个环境,即生产测试预发环境,共39个微服务应用39个微服务在SAE中的费用大幅下降,这也与国企的项目也有很大的关系项目意义重大,但实际使用人数较少,仅内部系统使用服务是服务,应用人数,而服务使用人数较少,只在数据处理时使用,对这些服务的存储一定程度上是一种资源浪费。

第二,降低运维难度。微服务架构拆分了后,分为了用户中心产品中心前端管理媒体资源等模块,而各个模块之间相独立研发人员在进行维护只需小的模块了解即可更新上线研发难度大大降低

第三,提升研发效能规范了流水线的流程,实现了基于云效持续集成发布

第四,提升稳定性平台基于SAE的建构之后,当服务故障时可以自动恢复和故障隔离稳定性进一步提升。

第五,更高的安全保障。在使SAEK8S的服务之后主机层面的安全无需再关心,在阿里的大门攻破后,只需要从业务层上做进一步的安全梳理即可

建设流水线

流水线的开发过程

统一代码管理因为大部分的代码管理平台Webhook的功能,在加了Webhook指令后,代码的提交即可与云效相关联。

第二步,编写Dock file。编写Dock filede的主要应用有JAVAPHP应用,有很多样例可供参考新的项目可以很快复制过来同时,要配置上传密钥字典,在其迁入云原生之前很多项目的代码密钥都写在

第三步,在了代码之后,所有的配置文件要单独处理,上传配置文件。

第四步,进行配置构建人工卡点,对代码做Sonar扫描。同时,项目负责人做代码的评审。

第五步,配置构建物上传。

第六步,完成配置任务的部署。

第七步,部署成功之后,云效平台可以集成多个平台的消息通知可以通过邮件短信钉钉发送成功的情况。

流水线的优势

第一,高度的集成化。自动化的流水线通过标准化的代码提交、构建、测试和部署,显著提高开发效率,降低了人为失误,保障了软件交付的持续性和稳定性可以快速响应市场变化

第二,强大的集成能力。云效流水线可以无缝集成代码仓库持续集成和项目工具优化研发流程,确保信息同步。

第三,灵活的部署策略。包括云效中的灰度发布蓝绿部署和分批发布等能够有效降低上线的风险确保业务的连续性和用户体验。

第四,全面的监控和反馈。云效通过严格的安全控制和权限管理保障代码与数据安全,利用加密和访问控制防止未授权的访问确保部署透明可控,详细的日志和报告为持续优化提供数据支持。

 

相关实践学习
1分钟部署经典小游戏
本场景介绍如何使用Serverless应用引擎SAE 1分钟快速部署经典小游戏。
SAE的功能与使用入门
欢迎来到《SAE的功能与使用入门》,本课程是“云原生Serverless Clouder认证“系列中的第三阶段。课程将向您介绍阿里云Serverless应用引擎(SAE)服务相关的概念、特性与使用方式。通过课程将带您逐步深入探索Serverless世界,借助SAE服务,即使没有丰富的云计算和IT经验,也能够让开发人员在实际业务场景中便捷的掌握如何构建和部署应用程序,快速拥抱Serverless架构,将精力聚焦在应用代码和业务逻辑的实现上。 学习完本课程后,您将能够: 掌握Serverless应用引擎(SAE)的基本概念与核心优势 了解Serverless应用引擎(SAE)的核心功能 掌握使用Serverless应用引擎(SAE)的开发和部署流程 了解Serverless应用引擎(SAE)的适用场景和最佳实践  
相关文章
云上应用管理问题之EDAS 对于Container + Serverless Container的场景该如何解决
云上应用管理问题之EDAS 对于Container + Serverless Container的场景该如何解决
101 10
云大使 X 函数计算 FC 专属活动上线!享返佣,一键打造 AI 应用
如今,AI 技术已经成为推动业务创新和增长的重要力量。但对于许多企业和开发者来说,如何高效、便捷地部署和管理 AI 应用仍然是一个挑战。阿里云函数计算 FC 以其免运维的特点,大大降低了 AI 应用部署的复杂性。用户无需担心底层资源的管理和运维问题,可以专注于应用的创新和开发,并且用户可以通过一键部署功能,迅速将 AI 大模型部署到云端,实现快速上线和迭代。函数计算目前推出了多种规格的云资源优惠套餐,用户可以根据实际需求灵活选择。
阿里云函数计算 x NVIDIA 加速企业 AI 应用落地
阿里云函数计算与 NVIDIA TensorRT/TensorRT-LLM 展开合作,通过结合阿里云的无缝计算体验和 NVIDIA 的高性能推理库,开发者能够以更低的成本、更高的效率完成复杂的 AI 任务,加速技术落地和应用创新。
214 13
7分钟玩转 AI 应用,函数计算一键部署 AI 生图大模型
人工智能生成图像(AI 生图)的领域中,Stable Diffusion WebUI 以其强大的算法和稳定的输出质量而闻名。它能够快速地从文本描述中生成高质量的图像,为用户提供了一个直观且高效的创作平台。而 ComfyUI 则以其用户友好的界面和高度定制化的选项所受到欢迎。ComfyUI 的灵活性和直观性使得即使是没有技术背景的用户也能轻松上手。本次技术解决方案通过函数计算一键部署热门 AI 生图大模型,凭借其按量付费、卓越弹性、快速交付能力的特点,完美实现低成本,免运维。
尽享红利,Serverless构建企业AI应用方案与实践
本次课程由阿里云云原生架构师计缘分享,主题为“尽享红利,Serverless构建企业AI应用方案与实践”。课程分为四个部分:1) Serverless技术价值,介绍其发展趋势及优势;2) Serverless函数计算与AI的结合,探讨两者融合的应用场景;3) Serverless函数计算AIGC应用方案,展示具体的技术实现和客户案例;4) 业务初期如何降低使用门槛,提供新用户权益和免费资源。通过这些内容,帮助企业和开发者快速构建高效、低成本的AI应用。
81 12
函数计算产品使用问题之修改SD模版应用的运行环境
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
函数计算产品使用问题之通过仓库导入应用时无法配置域名外网访问,该如何排查
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
ApsaraMQ Serverless 能力再升级,事件驱动架构赋能 AI 应用
本文整理自2024年云栖大会阿里云智能集团高级技术专家金吉祥的演讲《ApsaraMQ Serverless 能力再升级,事件驱动架构赋能 AI 应用》。
189 13
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
Serverless架构通过提供更快的研发交付速度、降低成本、简化运维、优化资源利用、提供自动扩展能力、支持实时数据处理和快速原型开发等优势,为图像处理等计算密集型应用提供了一个高效、灵活且成本效益高的解决方案。
116 1
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
Serverless架构在图像处理等计算密集型应用中展现了显著的优势
48 1

热门文章

最新文章