分布式任务调度框架和微服务的区别

朱雀 2022-12-26 11:23 171阅读 0赞

## 一、前言 ##

分布式大行其下的时代，让大家彻底的抛弃了传统陈旧的技术框架。几乎每一个技术人都知道和掌握了微服务架构，微服务自然有它的美，但是所以技术框架都必须服务于业务，结合自身业务选取甚至自研适合自身的技术框架也是技术人必须首先考虑的事情。分布式作业调度框架，是一个开发迅速、学习简单、轻量级、易扩展、高可用分布式任务调度框架。

## 二、分布式任务调度框架 ##

### 2.1 任务调度框架的简介 ###

任务调度是指基于给定的时间点，给定的时间间隔或者给定执行次数自动的执行任务。任务调度涉及到多线程并发、运行时间规则定制及解析、线程池的维护等诸多方面的工作。

*  同一服务多个实例的任务存在互斥时，需要统一协调
 *  定时任务的执行需要支持高可用、监控运维、故障告警
 *  需要统一管理和追踪各个服务节点定时任务的运行情况，以及任务属性信息，例如任务所属服务、所属责任人

## 2.2 常见分布式任务调度框架 ##

目前主流的分布式作业调度平台，主要有：当当网开源项目Elastic-job、大众点评开源项目xxl-job、唯品会开源项目Saturn、阿里巴巴早期开源项目TBSchedule等。

![0d130b49ed295be61c9e382956228be6.png][]

### 2.3 实现原理 ###

Java有个标准定时任务Quartz，它的关注点在于定时任务而非数据，并无一套根据数据处理而定制化的流程。虽然Quartz可以基于数据库实现作业的高可用，但缺少分布式并行调度的功能。

分布式任务调度框架，就是基于Quartz的理念，支持任务动态分片、集群部署、轻量级易上手的分布式定时作业调度架构。

详细查看另一篇文章，专门介绍Saturn：[唯品会开源分布式作业调度平台Saturn][Saturn]

## 三、分布式微服务框架 ##

### 3.1 微服务框架的简介 ###

官方对于微服务并没有一个详细的定义，最初是有从传统的单体式应用架构，可以做垂直于水平拆分而衍生出的一种架构理念。于是，分布式微服务技术就因运而生了。一个去中心化的多业务独立部署和运维的SOA(面向服务的架构)集群。

### 3.2 主流的微服务框架 ###

目前主流的微服务框架有：国外开源项目SpringCloud、阿里巴巴开源项目Dubbo和SpringCloudAlibaba（基于SpringCloud）、新浪微博Motan、腾讯开源项目Tars等。

国内用的最多的框架是SpringCloud和Dubbo，详细查看另一篇文章：[SpringCloud与Dubbo的比较][SpringCloud_Dubbo]

### 3.3 原理简介 ###

简单来说，微服务就是一种将一个单一应用程序拆分为一组小型服务的方法，拆分完成后，每一个服务都运行在独立的进程中，服务于服务之间采用轻量级的通信机制来进行沟通（Spring Cloud 中采用基于HTTP 的 RESTful API）。

微服务可以理解为是 SOA （面向服务的体系结构） 的一个传承，一个本质的区别是微服务是一个真正分布式、去中心化的，微服务的拆分比 SOA 更加彻底。

**微服务的优势**

1.  复杂度可控
2.  独立部署
3.  技术选型灵活
4.  较好的容错性
5.  较强的可扩展性

## 四、任务调度和微服务的区别 ##

### 4.1 对比 ###

**任务调度：**可用于精确至时分秒定时执行的作业，可重复执行，可动态设置分片参数来设置任务的并发大小数。

1、轻量级，支持通过Web页面对任务进行动态CRUD操作，操作简单，一分钟上手，这点应该都差不多  
2、只依赖数据库作为集群注册中心，接入开发简单，不需要ZK  
3、高可用、解耦、高性能、监控报警、分片、重试、故障转移  
4、团队持续开发  
5、支持后台直接查看每个任务执行实时日志

**微服务：**去中心化，基于业务拆分的某个独立部署和运行的模块，高可用高扩展。

●单一职责原则

指的是每一个微服务模块，只关心自己的业务规则。例如订单模块只关心订单的相关业务，不牵扯其他业务的逻辑。

●服务自治原则

每一个微服务模块的开发，需要有自己的开发、测试、运维、部署这一条独立的栈，并且有自己的数据库等一切，完全把其当成一个单独的项目来做，不牵扯到其它无关业务。

●轻量级通信原则

微服务的通信协议需要跨平台、跨语言的通信协议，因为微服务是不绑定技术栈的，不论使用Java、PHP还是.net去开发Web系统，它们之间的通信一定是去语言特色的。

●接口明确原则

前面提到了微服务的“接口调整成本高”，那么怎么去避免它呢？我们一开始就应该规划好微服务的模块是一种什么样的模型，尽量去避免A接口的改动会导致B接口的改动这种情况。

## 五、总结 ##

技术框架没有好坏之分，只有适合于不适合的概念。基于各自业务和场景，选择适合的技术框架是每一个技术人必须要首先考虑的事情。业务驱动技术，技术为业务服务，每一个伟大的技术架构的诞生都是从业务本身抽象和发展而来。随着时代的发展，先进的技术架构必然淘汰陈旧的技术框架。保持持续学习的热情和心态才能让我们跟随科技发展的脚步。

--------------------

既然都看完了整篇文章，相信对你一定有所帮助。原创不易，勿做伸手党。

点击下方【打赏】小编，或者关注公众号给予支持，你们的每一份鼓励都将是小编伟大的动力。

--------------------

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ZvbGxvd18yNA_size_16_color_FFFFFF_t_70][] 同名原创公众号：  **程序大视界**

[0d130b49ed295be61c9e382956228be6.png]: /images/20221120/dedd11e5b1a2467595a12506c8a776ea.png
[Saturn]: https://mp.weixin.qq.com/s?__biz=MzUzOTk5MzYyNg==&mid=2247484000&idx=1&sn=12fb654153013751ead69285280301e3&chksm=fb3eb115cc493803b3bd87667910badcff167981f0abc68ce37f27f76c31fc94cc8f7d1c0e3f&token=2106674903&lang=zh_CN#rd
[SpringCloud_Dubbo]: https://mp.weixin.qq.com/s?__biz=MzUzOTk5MzYyNg==&mid=2247483791&idx=1&sn=1abf41ad88963c6ffc9b0e94403d942c&chksm=fb3eb2facc493bec2e9f57f77c7b45331cd8835e0e01b61130a487c9a41dae1b7aac5f51d4e0&token=2106674903&lang=zh_CN#rd
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ZvbGxvd18yNA_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20181224142546363.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L0ZvbGxvd18yNA==,size_16,color_FFFFFF,t_70