架构迭代无法一蹴而就，做开源亦是如此
发布时间：2022-08-25 11:58:09 所属栏目：大数据 来源：互联网
导读：Apache DolphinScheduler是基于Apache开源社区理念打造的知名DataOps 领域开源项目。作为一个分布式去中心化，易扩展的可视化工作流任务调度平台，Apache DolphinScheduler目前已累计在1000多家公司生产环境中作为企业的核心调度系统。在近日的【TTalk】系列
|
Apache DolphinScheduler是基于Apache开源社区理念打造的知名DataOps 领域开源项目。作为一个分布式去中心化，易扩展的可视化工作流任务调度平台，Apache DolphinScheduler目前已累计在1000多家公司生产环境中作为企业的核心调度系统。在近日的【T·Talk】系列技术分享活动中，Apache Member、Apache DolphinScheduler PMC Chair、白鲸开源联合创始人代立冬老师详细介绍了Apache DolphinScheduler架构迭代中的经验与教训，并分享了自己对开源的理解与思考。【T·Talk】也将本次分享的精彩内容进行了整理，希望大家喜欢。 Apache DolphinScheduler Apache DolphinScheduler是一个云原生的分布式的工作流调度系统，也是首个由国人主导并贡献到Apache基金会的大数据工作流调度领域的顶级项目，拥有着每日支持千万级任务调度的能力。据不完全统计，目前已有一千多家不同领域企业在生产环境上使用Apache DolphinScheduler。 能够拥有如此多的用户群体，主要由于Apache DolphinScheduler拥有着以下几个关键优势： 高可靠性：调度最重要的能力是可靠性。Apache DolphinScheduler在架构上采用了去中心化的多Master和多Worker的设计。所有的Master Server都会同时工作，包括Worker也是无中心的。且在这样的架构下采用了任务队列机制去避免过负载，这样可以有效避免机器卡死。 简单易上手：ApacheDolphinScheduler的前身是EasyScheduler，Easy和Simple一直是我们的核心理念。ApacheDolphinScheduler拥有可视化的拖拉拽界面，所有的定义都是通过拖拉拽形成的，同时也有OpenAPI与第三方系统对接。有一些习惯于使用Python的小伙伴，也可以使用PY DolphinScheduler去创建工作流定义。 使用场景丰富：ApacheDolphinScheduler能够支持多租户、权限管理以及超过20种的常用任务。这一能力是目前很多开源项目，包括一些商业调度系统所不具备的。ApacheDolphinScheduler设计之初的目标就是超越一些商业公司的调度系统。如果开源项目有足够的价值，足以代替一些商业公司产品。 高扩展性：我们希望ApacheDolphinScheduler支持自定义任务类型，目前已实现了SPI化，未来还会使其拥有更好的热加载能力。Apache DolphinScheduler分布式调度的特性将得到强化，例如拥有更多K8S能力，随着集群的能力而实现线性增长。扩展性方面，应当具备弹性伸缩的能力，未来也会实现K8S的Operator，Serverless以加大Master的伸缩容。 当然，作为一款开源项目，ApacheDolphinScheduler的每一步发展与成长都离不开社区的贡献，开源社区的力量是非常强大的。为了能够让大家更好地记住ApacheDolphinScheduler，这里也介绍一个社区所贡献的slogan，那就是“工具选的好，下班回家早。调度用的对，半夜安心睡。" 架构迭代中的经验与教训 "优秀的架构不是设计出来的，而是迭代出来的。“这句话在ApacheDolphinScheduler中体现得淋漓尽致。以下是ApacheDolphinScheduler最新的架构。最上端能够直观可感知的是UI，UI界面下面则承载着APIServer，如果通过OpenAPI去调ApacheDolphinScheduler，也是通过这样一个服务接口来调起的。 在此之下还有数个对等的Master Server，Master Server会根据一些算法，例如随机、轮询或是基于CPU和内存的线性加权等给Worker分任务，WorkerServer则会在接收任务时响应，并在完成任务时回应Response。大数据调度很重要的特点是很多任务是离线的，任务的运行时间较长，大部分任务都会超过30分钟甚至几个小时，所以需要分响应和Response。Master Server和Worker Server都会注册ZK集群，主要负责服务的注册、监听。如果Master或Worker Server挂了，需要恢复，包括一些容错的机制，以及极个别情况下，会用到分布式锁。去分布式锁、减少数据库轮询是架构改造的核心目标之一。Master Server在工作时，先抢一把锁，谁抢到锁谁工作。这时ZK在充当分布式锁的过程中，性能是比较低的，对此我们做了去分布式锁的优化，大幅减少线程的使用。 1.3架构与1.2架构也存在一个明显的区别，1.3架构在1.2架构的基础上删除了TaskQueue。之所以如此设计，是因为越来越多的用户发现，在任务较多的时候，Worker Server能够到达上百台。由于其用TaskQueue做了缓冲，因此会给数据库造成极大的压力，仅是维护一个数据库连接池就有可能都会把数据库的连接池耗尽。 （编辑：肇庆站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
