架构师如何选型分布式定时任务

Posted 35岁程序员那些事

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了架构师如何选型分布式定时任务相关的知识,希望对你有一定的参考价值。


void run() log.info( (! log.info(Runnable() run() BrokerController.this.registerBrokerAll( brokerConfig.isForceRegister()); (Throwable e) log.error( , * MQClientException

使用Spring Framework框架自带的本地定时任务非常方便,如果你的基础框架采用Spring Boot或者更加高级一点Spring Cloud Alibaba,你不需要添加额外的Jar包依赖,因为@EnableScheduling和@Scheduled是Spring Context提供给我们的定时任务注解,只要你是Spring Framework生态的业务服务,你就可以使用它,非常的简单。


Quartz

Quartz可以说是非常古老的定时任务框架,目前最新的版本为2.3.2,项目最近一次更新是2019年,也就是说处于停更状态,不过这个不影响它的关注度,毕竟它是制定规范的。


看过Quartz底层源码的技术人应该都知道,Quartz中大量使用了线程来实现定时任务的功能,比如执行任务的线程池和调度任务的线程池等。


xxl-job


笔者在很多年之前就已经接触过xxl-job了,也是看着它成长起来的,该框架的作者也是非常的厉害,并且这个框架是个人维护到现在,如果我没记错的话应该有快10年了。


在Github上搜索xxl-job,目前Fork数为8.9k,Star 20.9k,这个成绩已经超过了很多Apache顶级项目的数据了,目前它的最新版本为v2.3.0,社区活跃度还是非常活跃的。


xxl-job给自己的定位是分布式任务调度平台,也就是说它不仅是要做定时任务,而是要做调度,这点就和云原生的理念不谋而合了。


关于xxl-job的原理大家可以参考官方https://github.com/xuxueli/xxl-job,分布式Job的原理其实不难,多实践一下,看看源码大致能知道它是如何完成调度的。


笔者也下载了它的源码大致看了一下,其实它本质上也是用线程来实现的定时Job,只不过加了一些动态调度的规则而已,并且能够做到非常优雅的和动态的杀死运行Job的线程,并完成线程Job的调度。


笔者当初关注过xxl-job,主要原因是它在那个版本把ZooKeeper去掉了,自己写了一套分布式一致性的框架,具体是在哪个版本改进的,这里我大概忘记了。

Elastic-job

Elastic-job是Apache的顶级项目,目前已经改名为shardingsphere-elasticjob,具体数据如下。



shardingsphere-elasticjob和xxl-job一个最大的不同点在于,前者还是重度依赖ZooKeeper的,毕竟ZooKeeper也是Apache的项目,哈哈,肯定不会去掉的。


还有一个比较大的不同点就是shardingsphere-elasticjob的定时任务规范是依赖Quartz的二次开发的产品,而xxl-job是完全自己写的。

目前shardingsphere-elasticjob最新的版本为3.0.1,社区活跃度是非常高的,如果大家对源码感兴趣可以下载相关源码,https://github.com/apache/shardingsphere-elasticjob。

shardingsphere-elasticjob包含两个部分:

  • Elastic-Job-Lite定位为轻量级无中心化解决方案,使用jar包的形式提供分布式任务的协调服务;

  • Elastic-Job-Cloud使用Mesos + Docker(TBD)的解决方案,额外提供资源治理、应用分发以及进程隔离等服务。

  • Saturn


    Saturn是唯品会在github开源的一款分布式任务调度产品。它是基于当当elastic-job 1.0版本来开发的,其上完善了一些功能和添加了一些新的feature。



    Saturn目前最新的版本为v3.5.1,社区活跃度不是很高。


    antares


    Antares是一个完全自研的个人维护的定时任务框架。



    Antares目前最新的版本为1.4.0,最近一次更新是2017年,几乎处于停止维护状态。


    Spring Cloud Alibaba Cloud SchedulerX


    SchedulerX(分布式任务调度) 是隶属于阿里云EDAS产品的组件, Spring Cloud AliCloud SchedulerX 提供了在Spring Cloud的配置规范下,分布式任务调度的功能支持。SchedulerX可提供秒级、精准、高可靠、高可用的定时任务调度服务,并支持多种类型的任务调度,如简单单机任务、简单多机任务、脚本任务以及网格任务。


    阿里巴巴并没有开放Spring Cloud Alibaba Cloud SchedulerX的源码,这个是一个硬伤,咱们只能使用阿里云的商业版本。


    总之,不论是哪一种分布式定时Job,都会有它适用的业务场景,并没有谁是绝对的好和绝对的不好,就像是RPC框架一样,合适才是最重要的。优秀的框架的架构和设计思想是非常有用的,我们能够把它学过来,并为自己所用也是一种能力的提升,毕竟咱们要先学会模仿,才能够学会创新。

    公众号初衷

    知识输出是笔者的初衷,借助知识输出,能够认识更多的牛人,能够和牛人沟通,也是自己技术提升的一个机会。

                            

         本人微信ID,如有需要惠请联系

    一路向北

    人间灯火无不休,爱与山水与春

                                                                                ----无题

    架构师如何选型分布式业务网关


    在日常工作中,不同的场合下,我们可能都会听说网关的概念,当然通常是指业务网关(API网关),负责API的输入和输出。有了业务网关之后,各个API服务提供者可以专注于自己的业务逻辑处理,而API网关更专注于安全、流量、路由等问题。从功能层次我们又会联想到一个概念——代理。网关与代理的区别:代理本质是数据的透传,协议不会发生变化;网关在数据透传的背景下,还会涉及协议的转换,比如从HTTP到Dubbo。


    那么作为一名架构师,我们该如何选型“业务网关”呢?我们自己先要学会做技术选型,自己预期有一个技术成本的预判,比如我推荐使用Spring Cloud Alibaba+Spring Gateway,就是我自己作为一个架构师的技术预判。

    Zuul


    Zuul是Netflix开源的微服务网关,可以和Eureka、Ribbon、Hystrix等组件配合使用,Spring Cloud对Zuul进行了整合与增强,Zuul总共有两个大的版本:Zuul1.0和Zuul2.0,目前最新的版本为v2.2.0,Zuul1.0和Zuul2.0版本之间功能差异性非常大。


    Netflix的Zuul包含如下功能:

  • 身份认证与安全:识别每个资源的验证要求,并拒绝那些与要求不符的请求;

  • 审查与监控:在边缘位置追踪有意义的数据和统计结果;

  • 动态路由:动态地将请求路由到不同的后端集群;

  • 压力测试逐渐增加指向集群的流量,以了解性能;

  • 负载分配:为每一种负载类型分配对应容量,并弃用超出限定值的请求

  • 静态响应处理:在边缘位置直接建立部分响应,从而避免其转发到内部集群;

  • 多区域弹性:跨越AWS Region进行请求路由,旨在实现ELB(Elastic Load Balancing)使用的多样化和以及让系统的边缘更贴近系统的使用者。

  • 以上介绍来自Zuul官方文档,但其实开源版本的Zuul以上功能一个都没有——开源的Zuul只是几个Jar包而已,以上能力指的应该是Netflix官方自用的Zuul的能力;Netflix自用的Zuul能力是比较强大的,可使用Groovy编写过滤器,并且可动态加载/卸载、修改规则,而且使用Cassandra作为数据库,然而开源版本这些一个都没有;Spring Cloud中,Zuul绝大部分功能都是Spring Cloud团队为Zuul开发的;所以Zuul 2.x的开源进度延后一年,Spring Cloud团队开发了自己的SCG,并宣布Spring Cloud不打算支持Zuul 2.x,你还觉得意外吗?看到这里,很多人可能没有动力学习Zuul了,个人认为还是可以了解一下的,后面讲到SCG时,你会发现很多设计理念是相通的。

     

     

    既然说到了Spring Cloud对Zuul的封装,那么我们来简单的分析下Spring Cloud与Zuul的关系。Spring Cloud通过Spring Cloud Netflix 1.X来封装Zuul1.0,1.X的最后一个版本是v1.4.7.RELEASE,对应的Zuul版本是1.3.1。Spring Cloud Netflix从3.X开始就没有封装Zuul网关,包括Zuul1.0和Zuul2.0,也就是说开发者想要通过Spring Cloud来复用Zuul,只能使用Zuul1.0,暂时不能复用Zuul2.0。


    Zuul目前在github上的star数为10.2k,fork数为2k,也就是说还是有很多开源爱好者会基于Zuul来定制化业务网关。


    除了开源的Spring Cloud定制化Zuul,开源微服务框架jhipster也参与了定制,并集成到它的生态中。Jhipster主要包含generator-jhipster和jhipster-registry,前者star数微17.7k,fork数为3.5k,后者star数为604,fork为607。


    Zuul1.0整体架构设计如图所示。


    Zuul2.0整体架构设计如图所示。

    Spring Cloud Gateway

    SCG是基于Spring Framework 5.0和Spring Boot 2.0构建的API网关,提供路由等功能。其旨在提供一种简单而有效的方法路由到API,并为它们提供跨领域的关注点,例如:安全性、监视/指标和弹性。


    主要特性:

  • Java8

  • Spring Framework5

  • Spring Boot2

  • 动态路由

  • Spring Handler Mapping内置的路由匹配

  • HTTP请求的路由匹配(路径、方法、Header、主机等)

  • 过滤器限定范围以匹配路由

  •  过滤器可以修改下游HTTP请求和HTTP响应(添加、删除Header、添加/删除参数、重写路径、设置路径等)

  • API或配置驱动

  • 支持Spring Cloud Discovery Client配置路由

  • SCG的专业术语包括:

  • 路由:它是基本构建模块,主要包含ID、URI、断言集合以及过滤器集合,如果能够匹配断言就会执行路由;

  • 断言:主要是指Java8的函数式断言,输入类型是Spring Framework的ServerWebExchange,基于断言可以匹配基于headers或者parameters的http请求;

  • 过滤器:它是通过特殊的工厂方法构造的基于Spring Framework GatewayFilter的实现,通过过滤器开发者可以在http请求下行之前修改请求响应参数,在请求响应返回之后可以修改响应的结果。

  • SCG整体架构设计如图所示。

    自研网关

    一个API网关的基本功能包括统一接入、协议适配、流量管控与容错,以及安全防护,这个四大基本功能构成了网关的核心能力。网关首要的功能是负责统一接入,然后将请求的协议转换成内部的接口协议,在调用的过程中还要限流、降级和熔断等容错的方式来保护网关的整体稳定,同时网关还要做到基本的安全防护(防刷控制),以及黑白名单(比如IP地址白名单)等基本的安全措施,主要包括:统一标准接入,具备高性能、高并发和高可靠性,具备负载均衡的能力;

    除了基本的四个功能,网关运行良好的环境还包括注册中心(比如通过Nacos读取已经发布的API接口的动态配置)。为了实现高性能,将数据全部异构到缓存(比如Redis)中,同时还可以配合本机缓存来进一步的提高网关系统的性能。为了提高网关的吞吐率,可以使用NIO+Servlet3异步的方式,还可以利用Servlet3的异步特性将请求线程与业务处理线程分开,为后续的线程池隔离做好基本的支撑。访问日志的存储我们可以放到Hbase或者ES中,如果要作为开放网关使用,那么需要一个支持OAuth2.0协议的授权中心,同时还可以引入Nginx+Lua的方式,将一些基本的校验判断前置到应用系统之上,这样可以更加轻量级的处理网关接入的问题。



    主要包括接入层,开发者可以通过Nginx和Lua脚本,解决限流、黑白名单、路由、负载均衡、长短连接以及容灾切换的问题。网关需要保证服务的稳定性,需要接入注册中心,因为本书是Spring Cloud Alibaba的布道书籍,所以强烈推荐使用Nacos作为注册中心和配置中心。统一的鉴权中心,主要是统一解决网关为各个API服务的鉴权问题,当然可以按照服务维度做隔离,自定义鉴权规则。统一用户中心主要是解决用户登录问题,确保微服务调用的安全性。


    自研网关还需要有泛化功能,使用者在调用提供者的接口的时候,不再需要API提供者的客户端JAR包,因此也就没有了POJO,通过泛化的方式进行远程调用。一般情况下我们要通过RPC调用接口提供方的服务,首先在系统中嵌入接口提供者的JAR包,然后使用JAR包里面的类和方法。对于一个网关系统来说,如果要调用N个接口,就需要N个JAR包,这样的网关是很难维护的,当然Dubbo RPC是支持泛化的。

    网关要具备时间校验、方法校验、版本校验和签名校验等功能,当然网关还需要具备服务降级、日志记录以及监控与告警功能。

    对比以上三种网关

    网关限流鉴权监控易用性可维护性成熟度
    SCG可以通过IP,用户,集群限流,提供了相应的接口进行扩展普通鉴权auth2.0Gateway Metrics Filter简单易用Spring系列可扩展强,易配置和可维护性好Spring社区成熟,但Gateway资源少。
    Zuul2可以通过配置文件配置集群限流和单服务器限流,也可以通过filter实现限流扩展filter中实现Filter中实现参考资料比较少可维护性差开源不就资源少。
    Zuul1同上同上同上同上同上同上
    自研网关需要开发需要开发需要开发需要开发可维护性极高需要开发

    总结

    推荐使用Spring Cloud Alibaba+Spring Cloud Gateway,可以更加高效的利用Spring Cloud ALibaba的服务治理能力去融合网关API的治理,从而提升业务服务API的系统稳定性。

    公众号初衷

    知识输出是笔者的初衷,借助知识输出,能够认识更多的牛人,能够和牛人沟通,也是自己技术提升的一个机会。

                            

         本人微信ID,如有需要惠请联系

    一路向北

    人间灯火无不休,爱与山水与春

                                                                                ----无题

    以上是关于架构师如何选型分布式定时任务的主要内容,如果未能解决你的问题,请参考以下文章

    架构师如何选型分布式业务网关

    分布式定时任务框架选型,写得太好了!

    分布式定时任务框架选型,写得太好了!

    分布式定时任务框架选型,写得太好了!

    看架构师对于前端框架的技术选型

    分布式定时任务框架选型,写得太好了!