Serverless Job——传统任务新变革
Job 作为一种运完即停的负载类型,在企业级开发中承载着丰富的使用场景。SAE Job 将 Serverless 技术所带来的普惠红利从应用领域向外延展至任务领域,通过结合 longrun + shortrun 的使用场景和最佳实践打造成为 Serverless 一体化企业级开发运维平台,以满足不同行业的差异化诉求,为用户提供更加完善多元的能力支持和稳定可靠的技术保障。
目前运行 Job 的主流方式是采用分布式任务框架,比如 Quartz、XXLJob 、ElasticJob 等。此类框架作为面世时间较长的开源项目,使用企业众多,功能成熟。而在云原生时代,K8S Job 和 CronJob 也逐渐被考虑采用。但是上述方案普遍存在以下痛点:
1、资源利用率低。采用开源的分布式框架需要程序常驻,在云主机中 7*24 小时收费。而 K8s 方案也需要用户维护集群节点,造成成本浪费。
2、可观测性差。用户需要完全自建一套日志采集、集群和业务监控指标采集、告警系统来满足生产环境的需要。
3、运维复杂。无论是开源框架还是 K8s,都需要关注底层资源的高可用、高并发下任务的容量和弹性,其运维操作具有较高的技术复杂度。
SAE Job 作为一款面向任务的 Serverless PaaS 平台,完美解决了以上痛点。SAE Job 重点解决了用户的效率和成本问题,在兼具传统任务使用体验和功能的同时按需使用,按量计费,做到低门槛任务上云,节省闲置资源成本。同时,体验上采用了事件驱动加无入侵任务调度和管控,用户零改造即可具备任务的全生命周期管理及可观测等开箱即用的功能。
SAE Job 支持多种调用方式,包括阿里云标准 API/SDK,能够通过可视化配置 Cron 表达式实现定时任务,通过 HTTP/MQ/OSS 等多种触发器来拉起 SAE Job 。同时支持诸多任务核心特性,包括任务生命周期管理、执行记录、事件通知、日志监控告警、超时重试、阻塞策略、任务分片、任务多并发等。
SAE Job 提供了三大核心价值:
1、完备全托管:提供了一站式全托管的管理界面,其任务生命周期管理、可观测性开箱即用,用户可以低心智负担、零成本地学习使用 SAE 。
2、简单免运维:屏蔽了底层资源,用户只需关注其核心的业务逻辑开发,无需操心集群可用性、容量、性能等方面的问题。
3、超高性价比:采用按需使用、按量付费的模式,只有任务执行业务逻辑时才会拉起收费,其余时间不收取任何费用,极大节省了资源的成本开销。
下面演示一下 SAE Job 的整体使用流程:
点击查看: https://developer.aliyun.com/live/249288
SAE Job 以任务为中心,提供传统的用户体验。当前聚焦支持单机广播、并行分片模型的任务,同时支持事件驱动、并发策略和超时重试等诸多特性,提供低成本、多规格、高弹性的资源实例来满足短时任务的执行。
相比开源的分布式框架,其优点在于全托管面运维的用户体验,开箱即用的完备功能以及白屏化管控,任务运行完立即释放资源,不会浪费闲置资源成本。
与 K8s Job相比,其优点除了全托管免费,还有用户无需了解 K8s 相关概念及技术细节,无需维护其复杂度。
SAE 支持 XXLjob 0 改造迁移,用户无需任何代码和配置的修改即可将 XXL JOB 应用部署至 SAE Job,用户只需为任务实际执行逻辑过程中付费。在此过程中 SAE Job 充当了 XXL Job 的调度中心和执行器,用户只需聚焦任务代码和简单配置,比如任务模板、并发重试等,由 SAE 负责无入侵地进行任务调度和管控。
将 XXL Job 部署到 SAE ,其核心价值是降本提效:
降本体现在:如果采用原有的 XXL Job,为了保持其高可用,至少需要 MySQL+2ECS+SLB+N*ECS 的常驻费用,而部署到 SAE 上则只需要为其任务执行具体业务逻辑所消耗的 CPU 内存付费,即 SAE 实际的资源消耗量。
提效体现在 : SAE 全托管面运维的体验,降低了整体运维复杂度,提升了应用可用性。
下面演示一下 XXL Job 0 改造迁移流程:
点击查看: https://developer.aliyun.com/live/249289
SAE Job 目前主要聚焦于泛互联网、新零售、电商、文化传媒、制造、 IoT、物流、金融证券、医疗卫健和保险等行业。主打的场景包含以下六个:
1、定时任务:定时拉取数据、爬虫。
2、批处理:数据清洗、转换、分析。
3、异步执行:异步进行状态刷新以及离线查询。
4、传统框架迁移:XXL Job 0 改造迁移等。
5、微服务架构:与原有的微服务架构进行调用通信、流程解耦。
6、CI/CD:用 SAE Job 作为构建镜像的载体实现 GitOps ,从而完善 CI/CD 的流程。
最后分享一个采用 SAE job 结合微服务的客户案例,用户的业务诉求为:需要通过定时任务将酒店产品变化的数据定期推送给第三方平台,比如飞猪等。其任务有两个特点:首先,任务的初始化耗时久,需要分钟级;其次,任务执行时间非常长,需要 5-6 个小时,并且除了处理业务逻辑之外,还需要调用其他微服务来获取元数据等信息。
我们为此提供的解决方案是将订单中心、产品中心、用户中心等微服务直接部署到 SAE 应用上,将定时任务部署到 SAE Job 里,用户无需改造即可通过 SAE 内置的注册中心实现通信。
该解决方案为用户提供了诸多价值:
- 两种负载统一入口操作、应用间调用 0 改造。
- 任务运完即停,立刻释放闲置资源,极大节省了资源成本。
- 超时失败自动重试,无需人工干预实现自愈。
- 提供完善的任务运行时监控报警机制。
借助这套解决方案,用户 0 代码改造即完成了整个架构 Serverless 化,同时节省了资源成本和运维成本,SAE 将持续为其应用和任务的可用性保驾护航。
最后,欢迎大家来使用 SAE Job, 一款面向任务的 Serverless PaaS 平台, 感受其对传统任务所带来的新变革。
点击此处,了解更多 SAE 详情~
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
参与 JetBrains IDE 的新版 UI 预览
IntelliJ IDEA 于去年庆祝了自己的 20 岁生日。在过去的 20 年中,我们一直在改进产品的各个方面,包括其用户界面和实用性。然而,其间我们在 UI 的许多方面进行的变化幅度都相对较小,主要是因为我们想让我们 IDE 的数百万现有用户都能一直使用他们所熟悉的 UI。与此同时,业内 UI 趋势却在不断发展,我们有许多新用户告诉我们 UI 看起来已有些笨重过时。解决这一问题势必涉及到大幅变更。因此,我们做出了大胆的决定,将以全新的眼光看待 UI 并彻底重新构想 IntelliJ IDEA 和相关 IDE 在当今时代下的外观。 我们的目标是降低视觉复杂性,使用户能够轻松访问基本功能,并根据需要逐级呈现复杂功能 —— 我们将打造整洁、现代且专业的外观和质感。 新版 UI 的主要变更包括: 包含新的 VCS、项目和运行微件的简化主工具栏。 新的工具窗口布局。 新的浅色和深色主题。 更新的图标集。 我们还发布了更加详细的变更和已知问题列表: https://youtrack.jetbrains.com/articles/IDEA-A-156/Main-changes-and-kn...
- 下一篇
常遇到读多写少,教你用ReadWriteLock实现一个通用的缓存中心
摘要:本文我们就来说说使用ReadWriteLock如何实现一个通用的缓存中心。 本文分享自华为云社区《【高并发】原来ReadWriteLock也能开发高性能缓存,看完我也能和面试官好好聊聊了!》,作者: 冰 河。 在实际工作中,有一种非常普遍的并发场景:那就是读多写少的场景。在这种场景下,为了优化程序的性能,我们经常使用缓存来提高应用的访问性能。因为缓存非常适合使用在读多写少的场景中。而在并发场景中,Java SDK中提供了ReadWriteLock来满足读多写少的场景。本文我们就来说说使用ReadWriteLock如何实现一个通用的缓存中心。 本文涉及的知识点有: 读写锁 说起读写锁,相信小伙伴们并不陌生。总体来说,读写锁需要遵循以下原则: 一个共享变量允许同时被多个读线程读取到。 一个共享变量在同一时刻只能被一个写线程进行写操作。 一个共享变量在被写线程执行写操作时,此时这个共享变量不能被读线程执行读操作。 这里,需要小伙伴们注意的是:读写锁和互斥锁的一个重要的区别就是:读写锁允许多个线程同时读共享变量,而互斥锁不允许。所以,在高并发场景下,读写锁的性能要高于互斥锁。但是,读写锁...
相关文章
文章评论
共有0条评论来说两句吧...