企业官网建设流程全解析

推荐几个看黄的网站,微网站用什么做,网站建设协议书样本,网页页面制作流程写在前面XXL-Job 是国内任务调度领域的标杆项目#xff0c;许雪里老师的设计兼顾了易用性与功能完整性。但在全面拥抱 Nacos Spring Cloud Alibaba 的架构中#xff0c;我们发现了一些摩擦#xff1a;XXL-Job 有自己的注册中心、配置存储#xff0c;与 Nacos 体系存在重复…写在前面XXL-Job 是国内任务调度领域的标杆项目许雪里老师的设计兼顾了易用性与功能完整性。但在全面拥抱 Nacos Spring Cloud Alibaba 的架构中我们发现了一些摩擦XXL-Job 有自己的注册中心、配置存储与 Nacos 体系存在重复。这不是设计缺陷而是架构演进阶段的自然差异。于是我们在思考在云原生时代中间件应该是独立的平台还是内嵌的能力模块这就是 JobFlow 这个想法的由来。在 Nacos 体系下遇到的挑战当技术栈选择了 Nacos 作为服务发现和配置中心后使用 XXL-Job 会遇到一些架构上的摩擦。这不是 XXL-Job 的问题而是两套体系的设计假设不同。挑战一两套注册中心导致状态不一致看看现在的架构同一个执行器实例要向两个注册中心汇报状态。问题来了这两个注册中心的状态可能不一致。举个实际场景你的某个服务内存占用高怀疑有内存泄漏想做 JVM dump 分析。于是你在 Nacos 控制台把这个实例手动下线避免有流量进来。你: 在 Nacos 点击下线Nacos: 实例已下线 ✓你: 放心了开始 dumpXXL-Job: 调度任务到这个实例你: ???为什么因为 XXL-Job 的注册中心还认为这个实例是在线的。你在 Nacos 的操作XXL-Job 根本不知道。再比如实例因为网络抖动在 Nacos 被标记为不健康但在 XXL-Job 还是健康的实例重启了在 Nacos 重新注册成功但 XXL-Job 还以为它下线了做灰度发布在 Nacos 控制权重但 XXL-Job 还是按原来的比例调度两套系统各管各的状态不同步运维时心里没底。挑战二观测性欠缺调度和执行是割裂的调度器触发任务 -- 执行器执行 -- 出问题了 | | | Admin日志 执行器日志 到底哪里出问题想要排查一次任务执行失败需要去 Admin 后台看调度日志去执行器服务看执行日志靠时间戳对日志祈祷两边的时钟同步没有统一的 TraceId排查问题全靠猜。挑战三分片缺少强约束XXL-Job 的分片是建议式的// 执行器拿到分片参数 int shardIndex XxlJobHelper.getShardIndex(); // 0 int shardTotal XxlJobHelper.getShardTotal(); // 10 // 然后自己算范围 ListOrder orders orderDao.findByIdMod(shardIndex, shardTotal);问题是没有分布式锁保护两个实例可能同时处理相同的数据。实际生产中见过这样的场景某个执行器重启XXL-Job 以为它下线了把分片分配给其他执行器结果这个执行器又回来了还在处理老的分片导致数据重复处理。核心思路中间件即业务在深入方案之前先说说设计理念。从重中间件到轻能力传统架构下中间件是一个外挂业务层订单服务、用户服务...微服务 ↓ 调用 中间件层XXL-Job Admin独立部署、独立运维、独立监控这种架构有明显的屏障中间件需要单独部署、单独配置监控告警要单独接入日志系统要单独打通配置管理要单独维护业务团队和中间件团队可能还不是一拨人但在云原生时代这些屏障是没有必要的。JobFlow 的理念是中间件即业务业务层订单服务、用户服务、JobFlow 调度器 ↓ 都是微服务都在同一个体系里调度能力不再是一个独立的平台而是业务能力的一部分同样的部署方式容器化、K8s同样的监控告警Prometheus、Grafana同样的配置管理Nacos Config同样的日志收集ELK/Loki同样的团队维护业务团队自己运维中间件不是外挂而是内嵌的能力模块。这种理念带来的好处架构统一认知成本低基础设施复用运维成本低状态一致不会出现Nacos 下线了但调度还在跑这种割裂业务团队自主可控不依赖中间件团队这就是 JobFlow 的战略定位不是要做一个通用的任务调度平台而是让调度能力融入微服务体系。具体怎么做减法和加法做减法去掉冗余既然已经有了 Nacos那就别再搞一套注册中心了去掉自建的注册中心统一用 Nacos 服务发现MySQL 存任务定义、执行记录和审计日志不存服务注册信息做加法补能力去掉冗余的同时把缺失的能力补上内置全链路 TraceId从调度到执行到日志一条线串起来真正的分片带分布式锁有状态可恢复智能重试指数退避死信队列调度器配置云原生化用 Nacos Config 管理调度器配置线程池、超时时间等支持动态调整、多实例共享、版本回滚共享基础设施作为微服务部署天然复用 Actuator、Prometheus、告警系统、日志收集等已有资源开箱即用的 Prometheus 指标RESTful API支持手动触发、查询、重试JobFlow 架构整体架构看起来清爽多了核心就三个东西Nacos统一的服务发现和配置中心JobFlow Scheduler一个轻量的调度器MySQL存任务定义、执行记录和审计日志重点是JobFlow Scheduler 作为微服务部署自动复用已有的 Prometheus、Actuator、告警、日志等基础设施零额外运维成本。调用流程重点在于第 3 步生成的 traceId会一路传递到执行器第 6 步执行器把 traceId 写入 MDC日志上下文第 7 步所有日志自动带上 traceId在 ELK 里搜这个 traceId就能看到完整的执行链路分片调度不是建议你处理哪一段而是明确告诉你处理哪一段并且用锁保护。关键特性详解特性一全链路 TraceId这是最重要的特性。调度器生成一个全局唯一的 traceId通过 HTTP Header 传给执行器// JobFlow Scheduler String traceId UUID.randomUUID().toString(); HttpHeaders headers new HttpHeaders(); headers.set(X-Trace-Id, traceId); headers.set(X-Shard-Index, 0); headers.set(X-Shard-Total, 10); restTemplate.postForEntity(url, new HttpEntity(params, headers), JobResult.class);执行器收到后写入 MDC// 执行器端 PostMapping(/internal/job/{jobName}) public JobResult execute(RequestHeader(X-Trace-Id) String traceId, ...) { MDC.put(traceId, traceId); try { log.info(开始执行任务); // 日志自动带 traceId // 执行业务逻辑 return JobResult.success(); } finally { MDC.clear(); } }这样一来在 ELK 里搜索 traceId就能看到调度器什么时候触发的调用了哪个执行器执行器处理了什么有没有报错错在哪里一个 traceId 贯穿全链路排查问题效率提升 10 倍。特性二真分片给执行器明确的数据范围并且用分布式锁保护// 调度器计算分片范围 int totalRecords 1000000;int shardTotal 10;int rangeSize totalRecords / shardTotal;for (int i 0; i shardTotal; i) { long startId i * rangeSize; long endId (i 1) * rangeSize - 1; // 生成锁的 key String lockKey String.format(lock:job:order-sync:range:%d-%d, startId, endId); // 调用执行器 JobRequest request new JobRequest(); request.setTraceId(traceId); request.setStartId(startId); request.setEndId(endId); request.setLockKey(lockKey); executeAsync(instance, request);}执行器拿到范围后先抢锁PostMapping(/internal/job/order-sync)public JobResult sync( RequestHeader(X-Start-Id) Long startId, RequestHeader(X-End-Id) Long endId, RequestHeader(X-Lock-Key) String lockKey ) { // 先抢锁 boolean locked redisLock.tryLock(lockKey, 60, TimeUnit.SECONDS); if (!locked) { log.warn(分片范围 {}-{} 已被其他实例锁定, startId, endId); return JobResult.skip(已有其他实例处理); } try { // 处理 startId 到 endId 之间的数据 ListOrder orders orderDao.findByIdBetween(startId, endId); // ... 业务处理 return JobResult.success(); } finally { redisLock.unlock(lockKey); }}这样就保证了每个分片有明确的数据范围同一个分片不会被多个实例同时处理即使执行器重启分片也不会乱特性三智能重试失败后不是简单重试而是指数退避// 配置 retry: max: 5 backoff: EXPONENTIAL initialDelay: 1s maxDelay: 5m// 调度器publicvoidscheduleRetry(JobExecution execution){ int retryCount execution.getRetryCount(); if (retryCount maxRetry) { // 超过最大重试次数进入死信队列 deadLetterQueue.send(execution); return; } // 计算延迟时间1s, 2s, 4s, 8s, 16s... long delay Math.min( initialDelay * (1 retryCount), maxDelay ); scheduler.schedule(() - { retry(execution); }, delay, TimeUnit.SECONDS);}特性四调度器配置云原生化JobFlow 自身的配置放在 Nacos Config享受云原生配置管理的好处# Nacos Config: jobflow-scheduler.yaml jobflow:scheduler: thread-pool-size:20 # 调度线程池大小 timeout:300 # 默认超时时间秒 max-retry:3 # 默认重试次数executor: connect-timeout:5000 # HTTP 连接超时 read-timeout:30000 # HTTP 读取超时 redis: lock-timeout:60 # 分片锁超时时间秒 compensation: enabled:true interval:60000 # 补偿任务间隔毫秒 stuck-threshold:600000 # 卡住阈值10分钟好处1.动态调整不重启业务高峰期任务调度压力大→ 在 Nacos 控制台把 thread-pool-size 从 20 改成 50→ 配置推送调度器立刻生效→ 高峰过后再调回来2.多实例共享配置部署 3 个调度器实例→ 改一次配置所有实例都生效→ 不用每个实例都去改 application.yml3.版本管理和回滚调整了参数发现效果不好→ Nacos 一键回滚到上一个版本→ 有完整的变更记录和审计日志注意这里说的是调度器自身的配置。任务的定义谁、什么时候、跑什么仍然存在数据库中通过 API 或 UI 管理。特性五精简的数据库设计MySQL 存储的内容-- 任务定义表 CREATETABLE job_definition ( idBIGINT PRIMARY KEY AUTO_INCREMENT, job_name VARCHAR(100) UNIQUE, service_name VARCHAR(100), handlerVARCHAR(100), cron VARCHAR(100), enabled BOOLEANDEFAULTTRUE, created_at TIMESTAMP, updated_at TIMESTAMP);-- 执行记录表CREATETABLE job_execution ( idBIGINT PRIMARY KEY AUTO_INCREMENT, job_name VARCHAR(100) NOTNULL, trace_id VARCHAR(64) NOTNULLUNIQUE, trigger_time TIMESTAMPNOTNULL, finish_time TIMESTAMP, statusVARCHAR(20) NOTNULL, -- PENDING/RUNNING/SUCCESS/FAILED retry_count INTDEFAULT0, result_message TEXT, INDEX idx_trace (trace_id), INDEX idx_job_time (job_name, trigger_time));注意这里只存任务定义通过 API 或 UI 管理执行状态和元数据审计日志不存服务注册信息在 Nacos调度器配置在 Nacos Config详细执行日志靠 traceId 去 ELK 查这样数据库职责清晰压力小查询快。常见疑问解答问题一Nacos 挂了怎么办答如果 Nacos 挂了整个微服务体系都挂了任务调度不是最高优先级。不过可以做降级Service publicclassExecutorDiscovery{ // 本地缓存 private LoadingCacheString, ListString cache CacheBuilder.newBuilder() .expireAfterWrite(5, TimeUnit.MINUTES) .build(key - namingService.getAllInstances(key)); public ListString getInstances(String serviceName){ try { return namingService.getAllInstances(serviceName); } catch (NacosException e) { log.warn(Nacos 不可用使用缓存); return cache.getIfPresent(serviceName); } }}这样 Nacos 短暂不可用时还能用缓存的实例列表继续调度。问题二数据库写失败导致状态不一致答采用最终一致性模型。// 调度时先写 PENDING jobExecutionDao.insert(new JobExecution() .setTraceId(traceId) .setStatus(PENDING) .setTriggerTime(now));// 异步调用执行器CompletableFuture.runAsync(() - { try { JobResult result executeJob(executor, request); // 更新为 SUCCESS 或 FAILED jobExecutionDao.updateStatus(traceId, result.getStatus()); } catch (Exception e) { jobExecutionDao.updateStatus(traceId, FAILED); }});// 后台补偿任务Scheduled(fixedDelay 60000)publicvoidfixStuckExecutions(){ // 查找 PENDING 超过 10 分钟的记录 ListJobExecution stuck jobExecutionDao.findStuckExecutions(); for (JobExecution exec : stuck) { // 通过 traceId 去 ELK 查日志确认真实状态 // 或者标记为 TIMEOUT }}即使写 DB 失败也能通过 traceId 在日志系统里找到执行结果。问题三没有 UI 怎么运维答初期提供 RESTful API后期补 UI。RestController RequestMapping(/api/jobs)publicclassJobController{ // 手动触发任务 PostMapping(/{name}/trigger) public JobResult trigger(PathVariable String name){ return jobService.triggerNow(name); } // 查询执行历史 GetMapping(/{name}/executions) public PageJobExecution history( PathVariable String name, RequestParam int page, RequestParam int size ){ return jobExecutionDao.findByJobName(name, PageRequest.of(page, size)); } // 根据 traceId 查询详情 GetMapping(/executions/{traceId}) public JobExecution detail(PathVariable String traceId){ return jobExecutionDao.findByTraceId(traceId); } // 重试失败的任务 PostMapping(/executions/{traceId}/retry) public JobResult retry(PathVariable String traceId){ return jobService.retry(traceId); }}配合 Swagger UI已经能满足基本的运维需求。等系统稳定了再用 Vue/React 做一个管理后台。问题四调度器怎么保证高可用答调度器无状态可以部署多个实例用分布式锁避免重复调度。Service publicclassJobScheduler{ Scheduled(cron ${job.cron}) publicvoidscheduledTrigger(){ ListJobConfig jobs getEnabledJobs(); for (JobConfig job : jobs) { // 每个任务用一把锁 String lockKey lock:schedule: job.getName(); boolean locked redisLock.tryLock(lockKey, 10, TimeUnit.SECONDS); if (locked) { try { trigger(job); } finally { redisLock.unlock(lockKey); } } } }}或者更优雅的方式用一致性哈希// 每个调度器实例只负责部分任务 publicbooleanisMyResponsibility(String jobName){ int hash jobName.hashCode(); ListString schedulerInstances getSchedulerInstances(); String responsible consistentHash.get(schedulerInstances, hash); return responsible.equals(myInstanceId); } if (isMyResponsibility(job.getName())) { trigger(job); }总结JobFlow 只是一个想法一个技术探讨。它的核心不是技术细节而是一个设计理念中间件即业务。在云原生时代调度能力不应该是一个独立部署、独立运维的平台而应该是内嵌在微服务体系中的能力模块。它不是要替代 XXL-Job而是在深度使用 Nacos 体系的场景下提供另一种可能的思路更契合 Nacos 生态复用已有的服务发现避免维护两套注册中心调度器配置统一在 Nacos Config 管理支持动态调整、多实例共享和版本回滚共享基础设施无需单独接入 Prometheus、Actuator、告警系统等作为微服务自动享有架构一致性更好运维成本更低更强的可观测性TraceId 贯穿全链路日志、调度、执行一条线串起来排查问题效率更高更严格的分片约束明确的数据范围分配分布式锁保护支持断点续传XXL-Job 在通用性、易用性、功能完整性上有巨大优势适合大多数场景。JobFlow 的思路更适合已经深度绑定 Nacos、对可观测性有较高要求的团队。这个想法可能有很多问题和不足欢迎大家提出不同的意见和看法。也许你有更好的解决方案也许你能指出这个思路的致命缺陷都很有价值。技术讨论的意义不在于一定要实现什么而在于通过思考和碰撞让我们对问题的理解更深入一些。最后再次感谢许雪里老师和 XXL-Job 社区正是因为有了这样优秀的开源项目我们才能站在巨人的肩膀上继续探索。来源juejin.cn/post/7583469866007969827