YML

分布式定时任务—xxl-job学习（一）:简单demo搭建 一、xxl-job简介 1.1 xxl-job特性介绍 1.2 官方仓库+文档地址 二、简单搭建一个xxljob_demo 2.1 搭建调度中心 2.1.1 初始化“调度数据库” 2.1.2 配置部署“调度中心”xxl-job-admin 2.1.2.1 配置调度中心 2.1.2.2 部署xxl-job-admin项目 2.1.2.3 调度中心集群（可选） 2.2 搭建执行器项目demo 2.2.1 创建一个springboot的maven项目 2.2.2 执行器配置 2.2.3 执行器组件配置 2.2.4 开发一个简单的demo定时任务 2.2.5 部署 2.2.6 调度中心配置相应任务 2.2.6.1 新建一个执行器 2.2.6.2 新建一个任务 2.2.6.3 查看调度日志 2.2.6.4 查看执行日志 2.2.6.5 终止运行中的任务 三、彩蛋 一、xxl-job简介 XXL-JOB是大佬许雪里开源的一个分布式任务调度平台，其核心设计目标是开发迅速、学习简单、轻量级、易扩展。现已开放源代码并接入多家公司线上产品线，开箱即用。 1.1 xxl-job特性介绍 Features特性： 1、简单：支持通过Web页面对任务进行CRUD操作，操作简单，一分钟上手； 2、动态：支持动态修改任务状态、启动/停止任务

@FeignClient(name = "sl-main-service", path = "${server.servlet.context-path}") public interface UserFeignClient { // 读取用户信息，若不存在，则新注册 @GetMapping("/user/readUsXXXXXXyRegistration/{mobile}") User readUserXXXXXXstration(@PathVariable("mobile") String mobile); } 如代码中的【path = "${server.servlet.context-path}"】，可动态获取application.yml文件中的对应值， 这个浏览了全网几乎没看到类似答案，俺是出自@Value("${...}")的灵感，还真成了，快夸夸俺... 希望能够帮得到小伙伴儿们 来源： oschina 链接： https://my.oschina.net/u/3901290/blog/4503190

前言 在实际工作中，如果要用appium实现多设备的兼容性测试，大家想到的也许是“多线程”，但由于python中GIL的影响，多线程并不能做到"多机并行"，这时候可以考虑使用多进程的方式 为什么基于pytest 我们知道，pytest中的conftest.py可以定义不同的fixture，测试用例方法可以调用这些fixture，来实现数据共享。以前的框架的思路是：Common目录下的base_driver.py定义生成driver的方法-->conftest.py中调用前者生成driver-->TestCases下的测试用例调用fixture，来实现driver共享 。但是现在不同了，我们有多个设备，这些设备的信息如果只是单纯的写在yml中，我们并行去取的时候似乎也不方便，那可以写在哪里？conftest.py似乎也不是写设备信息的好地方，最后只剩下了main.py，而且将main.py作为多进程的入口再合适不过了 但问题又来了，如果我们想启动多个appium服务，需要考虑以下几点： appium通过什么方式启动？ 设备信息如何传递给base_driver方法来生成driver 第一点很明确，客户端启动appium server的方式似乎有点不合时宜了，如果你要同时测5个手机，难道要一个个启动客户端吗？最好的方式是启动命令行，因为命令行启动更方便更快 再说第二点前，先整理一下思路

平时在application.yml中配置并读取参数的时候，@ConfigurationProperties这个注解总是必不可少的，例如： adaptor: request: queueSize: 1000 imp: hotReloadDelay: 60 threadPool: corePoolSize: 20 maximumPoolSize: 60 keepAliveTime: 60 queueSize: 1000 alarmSending: threadPool: corePoolSize: 5 maximumPoolSize: 20 queueSize: 2000 keepAliveTime: 60 timeout: 500 retry: MessageRetry: true PayloadExpirationTime: 10 RetryInterval: 5 PayloadDiscardDirectory: /home/ec2-user/daopinz/discard/ 代码读取的地方是这样的： @Value("${adaptor.alarmSending.retry.MessageRetry}") private boolean messageRetry = false; @Value("${adaptor.alarmSending.retry

下载安装 Windows下载 Linux： curl -s "https://raw.githubusercontent.com/ \ kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | bash linux环境下，为方便命令行调用，可将文件移动到PATH变量下的bin目录： sudo mv kustomize /usr/local/bin 其他方式参考 官方文档 为什么使用 统一规范容器编排文件。 复用通用配置。 分环境管理编排文件。 专注于环境变量，存储卷等本地化的配置，无需关心端口，监控，发布等细节。 使用方式 使用前提：理解 base编排 的概念： base编排 在远程git仓库，提供基础的约定好的配置，如端口，监控，健康监测，环境变量等。各应用程序以base编排为基础，自定义其余的内容。 1.创建目录结构 在项目根目录创建 kustomize 文件夹，其中包含 lan，test，prod 三个子文件夹（内网，线上测试，正式环境）， 每个文件夹下必须有一个 kustomization.yaml 文件，可选的 env.yaml 用于配置环境变量， volume.yaml 用于配置存储卷。 运行脚本可根据情况自己配置。 2.修改kustomization.yaml配置说明 以下以学服系统（lmss

Spring Cloud Gateway 是 Spring Cloud 新推出的网关框架，之前是 Netflix Zuul。 网关通常在项目中为了简化前端的调用逻辑，同时也简化内部服务之间互相调用的复杂度； 具体作用就是转发服务，接收并转发所有内外部的客户端调用； 其他常见的功能还有权限认证，限流控制等等。 Spring Cloud Gateway使用的Webflux中的reactor-netty响应式编程组件，底层使用了Netty通讯框架 作用： 1.反向代理 2.鉴权 3.流量控制 4.熔断 5.日志监控 … 三大核心概念 Route(路由) 路由是构建网关的基本模块，它由ID，目标URI，一系列的断言和过滤器组成，如果断言为true则匹配该路由 Predicate（断言） 参考的是java8的java.util.function.Predicate 开发人员可以匹配HTTP请求中的所有内容（例如请求头或请求参数），如果请求与断言相匹配则进行路由 Filter(过滤) 指的是Spring框架中GatewayFilter的实例，使用过滤器，可以在请求被路由前或者之后对请求进行修改。 Gateway工作流程：路由转发+执行过滤器链 入门配置 1.建module：gateway-gateway9527 2.pom <!--新增gateway--> <dependency>

在日常工作中，我们一定遇到过需要快速构建系统的工作情形： 作为资源管理人员，需要接收一定数量以及配置的资源申请，这些申请要求网络、存储设备按需到位； 作为开发人员，需要将一套开发环境，复制一份测试环境以及线上环境； 架构师规划一套系统，需要在云上进行搭建。 这些场景都展现着我们日常所遇的各种困难： 对各类云端资源需要进行广泛支持与管理 ：这其中需要包括常用基础IaaS 资源及 PaaS 服务，比如主机、路由器、负载均衡器等计算网络资源以及各种数据库、缓存、大数据、存储服务； 资源编排使用难度大 ：技术栈复杂而难用，实现复杂拓扑关系需要系统化知识与丰富经验； 大量机械重复的手动配置操作 ：不仅是各资源及其拓扑关系按配置进行手工部署，各资源间的拓扑关系更是令人头疼； 学习成本高 ：过往的资源管理依赖于通过命令行调用API 的方式，提升了操作难度和学习成本。 由此可见，自动化运维成了运维人员的业务刚需，各大云厂商也相继推出各自的资源编排服务（Resource Orchestration，以下简称 ROS）。ROS 的理念是“基础设施即代码”，一方面是用代码思维的版本管理来记录基础设施变化，另一方面通过代码实现自动化运维，简化编写代码复杂度，用户通过使用 Json / Yaml 格式模版描述多个云计算资源（如 ECS、RDS、SLB）的配置、依赖关系等

1、简介 Elasticsearch在5.3版本中引入了Cross Cluster Search（CCS 跨集群搜索）功能，用来替换掉要被废弃的Tribe Node。类似Tribe Node，Cross Cluster Search用来实现跨集群的数据搜索。 2、配置Cross Cluster Search 假设我们有2个ES集群： Node Address Port Transport Port Cluster elasticsearch01 127.0.0.1 9201 9301 America elasticsearch02 127.0.0.1 9202 9302 America elasticsearch03 127.0.0.1 9203 9303 Europe elasticsearch04 127.0.0.1 9204 9304 Europe 有2种方式可以用来配置CCS： 1）配置elasticsearch.yml search: remote: america: seeds: 127.0.0.1:9301 seeds: 127.0.0.1:9302 europe: seeds: 127.0.0.1:9303 seeds: 127.0.0.1:9304 注意：以上方式，在配置的时候，需要remote cluster处在运行状态。比如在配置“america”的集群的时候

XXL-JOB特性一览 基本概念 xxljob解决的是以下几个痛点： 1） 跑批处理监控无法可视化，当前跑批的状态是：成功？失败？挂起？进度？为什么失败/原因？ 2）批处理任务不可重用，特别是无法对批处理任务做：定时？重复使用？频次？其中路由调度？ 3）批处理任务无法做到网格计算（特别像：websphere ibm grid computing）即批处理任务本身可以做成集群、fail over、sharding 由其是批处理任务可以做成“ 网格计算 ”这个功能，有了xxljob后你会发觉特别强大。其实网格计算：grid computing早在7，8年前就已经被提出过，我在《 IBM网格计算与企业批处理任务架构 》一文中详细有过介绍。 我们在一些项目中如：银行、保险、零商业门店系统中的对帐、结帐、核算、日结等操作中经常会碰到一些"批处理“作业。 这些批处理经常会涉及到一些大数据处理，同时处理一批增、删、改、查等SQL，往往涉及到好几张表，这边取点数据那边写点数据，运行一些存储过程等。 批处理往往耗时、耗资源，往往还会用到多线程去设计程序代码，有时处理不好还会碰到内存泄漏、溢出、不够、CPU占用高达99%，服务器被严重堵塞等现象。 笔者曾经经历过一个批处理的3次优化，试图从以下几个点去着手优化这个企业跑批。 首先，我们需要该批处理笔者按照数据库连接池的原理实现了一个线程池

在Kubernetes中有几种不同的方式发布应用，所以为了让应用在升级期间依然平稳提供服务，选择一个正确的发布策略就非常重要了。选择正确的部署策略是要依赖于我们的业务需求的，下面我们列出了一些可能会使用到的策略： 重建(recreate)：停止旧版本部署新版本 （k8s内部支持） 滚动更新(rolling-update)：一个接一个地以滚动更新方式发布新版本 （k8s内部支持） 蓝绿(blue/green)：新版本与旧版本一起存在，然后切换流量 （k8s内部支持比较繁琐，argo（改动yml），不用太大改动） 金丝雀(canary)：将新版本面向一部分用户发布，然后继续全量发布 （k8s内部支持比较繁琐，argo（改动yml），不用太大改动） A/B测(a/b testing)：以精确的方式（HTTP 头、cookie、权重等）向部分用户发布新版本。A/B测实际上是一种基于数据统计做出业务决策的技术。在 Kubernetes 中并不原生支持，需要额外的一些高级组件来完成改设置（比如Istio、Linkerd、Traefik、或者自定义 Nginx/Haproxy 等） AB测试 (所有的请求必须走代理网关进行流量拦截，进行转发来实现AB测试 参考： ingress-nginx实现灰度发布 ) 改动点： 滚动更新(rolling-update)：yml配置下ok 蓝绿(blue