江苏龙网

  1. 首页 > 人文 > >

江湖车侠|的自实现高可用方案，妙妙妙，PowerJob

本文适合有Java基础知识的人群
HelloGitHub推出的《讲解开源项目》系列 。
碎碎念高可用放到今天已经不是一个新颖的词汇了 ， 怎么实现高可用大家也已经了然于心 。 多实例部署+服务注册+服务发现这一套组合拳打下来 ， 实现高可用那还不是分分钟的事情 。 所以很多人看到PowerJob的介绍页面中写了任意组件支持集群部署以实现高可用 ， 想当然的以为也是走了上述的那套流程 。 然后看到系统依赖组件时 ， 发现......emmm......zookeeper呢？没看着 。 那找找Nacos？emmm......也没找着......不仅没找着 ， 还发现文档中明明白白的写着 ， 最小依赖仅为关系型数据库 。 许多用户看到这里就有点百思不得其解了 ， 正常来讲都会有两个疑惑 。
要做到分布式环境下的高可用 ， 肯定是需要服务注册、服务发现这样的概念的 。 没有外部注册中心 ， 说白了就是自己去实现了一套类似的机制 。 那为什么要怎么做呢？
其实答案很简单——成本 。 这个成本指的是用户的接入成本 。 对于一个需要部署的重型开源项目来说 ， 每少一个外部依赖 ， 就多一份潜在的用户 。 额外的系统依赖代表着额外的技术栈和额外的维护成本 ， 如果企业本身没有这一套技术体系（比如没用到zookeeper） ， 而PowerJob又强依赖zookeeper ， 那大概率只能说再见喽～
第一个问题解决了 ， 接下来进入第二个问题～
C/S架构下 ， 如果目标是server和client可以相互联通的“高可用” ， 那么实现起来其实非常容易 。
首先 ， 启动多个server应用实例 ， 集群部署 。 然后将多个server的IP地址统统填入worker的配置文件中 ， worker启动时 ， 随机找一个IP进行连接 ， 失败则重试 。 一旦成功连接到某一台server ， 就开始上报自己的地址信息 。 server通过持有这个信息也可以和worker进行通讯 。 如此一来 ， 一个最简单版本的“高可用”集群就搭建完成了 。 但是......它真的可用吗？
任务调度需要保证唯一性 ， 即某个任务在某一个时刻只能被一台机器调度 ， 否则就会导致重复执行 。 而前文提及的方案中 ， 每一台server都是完全等价的 ， 因此只能依靠分布式锁来保证唯一性 ， 即抢到锁的server执行调度 ， 其他server只能充当战地采访人员 ， 默默地边缘OB 。 这种方案下 ， 无论部署多少台server ， 系统整体的调度性能其实是固定的 ， 多实例部署只能做到高可用 ， 而不能做到高性能 。 server无法持有完整的worker集群信息 。 PowerJob的定位是任务调度中间件 ， 旨在为企业下各部门各业务线提供精准的调度和分布式计算能力 。 因此肯定会有集群分组的概念 ， 就像RocketMQ中存在ProducerGroup和ConsumerGroup一样 ， PowerJob有着AppName的概念 。 一个AppName逻辑上对应了某个应用下的一组任务 ， 物理上对应了这个应用所部署的集群 。 为了便于server统一管理以及一些额外功能的实现（分布式计算） ， server持有某一个AppName下完整的集群信息是一个强诉求 ， 而前文提及的“瞎猫撞上死耗子”式方案 ， 显然没办法做到这一点 。基于以上两点 ， 征途是星辰大海的PowerJob需要探索出一种更合理、更强大的高可用架构 。


推荐阅读


上一篇：北京花都家美|钢制更衣柜行业有前景吗

下一篇：NB物语|做抖音如何账号定位？，宁波象形视觉抖音运营干货之账号篇