修图可以说是国内技术领先的一大特点了，现在的图片处理技术可以说是非常厉害了，比如老旧照片修复，自动美化，各种滤镜，自动抠图等等，结合高大上的机器学习，功能越强大，感觉对于我这种图像门外汉来说，门槛也响应的越来越高了

那么有什么简单的方式，可以实现照片的处理嘛，接下来介绍一个纯java的工具包，来做图片处理

hello，各位小伙伴们大家早上|中文|晚上|凌晨好，相信看这篇文章的有很多新朋友，估计也有少量的老朋友，首先做个简短的自我介绍，我是一灰灰，码农界的资深搬运工；今天呢，没有站在我身边的捧哏老师，那就只好给大伙来个单口的灌水博文了

大街上铺天盖地的520促销优惠买一赠一的宣传语，宣告了初夏的第一个特殊节日，可好巧不巧的是到了5.21号这天我才发现，居然又到了520啊，然后再一看手机，卧槽，居然过了。。。这特么回家还不得跪我那斥巨资200大洋买的机械键盘了

赶紧发动一下高达249IQ的大脑，思考一下有什么补救的措施，是时候解开封印已旧的人肉爬虫技能，看看票圈晒图的朋友们，能不能提供有价值的灵光一现

功夫终负有心人，果不其然毫无收获；老老实实的发挥一下职业特长，码农可以整些什么浪漫的活 呢？

• 写个html页面，陪她去看流星雨
• 用她的照片组个带音乐、能自动播放的PPT
• 黑个商场大屏幕，附上她的美图秀秀 + 爱你一万年
• AI自动写个xxx 爱你一万年的藏头诗
• 写个无界面的APP，偷偷装在她的手机上，设置定时弹出一朵鲜花（不怕被打的话恐怖图片也可以🤭）

可选择的不少，接下来就剩下一个小问题了，5.21号送出5.20号的小礼物能被原谅么？（请看到这里的美少女么摸着自己的良心，在评论区大声告诉我”能“ 好么）

话接上文，就算有再多得小仙女告诉我能，讲道理我也不敢信啊，接下来免费给各位看官分享一个价值99的idea，用她的名字做一幅画（如下），下面这么大的工作量，delay个一两天不很正常么（请大声告诉我，是不是很机智）

接下来，老司机教你如何使用三十行用她(他它)的名字画出她的艺术画

又一年的中秋将至，要怎么样才能蹭一波它的热度呢？作为一个coder，是不是可以用代码写首诗？想法是好，可惜难度有点大，那么就简单点，给自己的二维码上，加个月饼吧

quick-media 升级2.6.0，二维码组件扩展两种样式规则

• MINI_RECT: 超火的小方块二维码生成
• IMAGE: 图片二维码，当相同的区域指定多个图片时，支持随机挑选渲染

项目源码: https://github.com/liuyueyi/quick-media

Java端”最强”二维码渲染工具又双叒叕升级了，新增前置模板渲染，简单几行代码即可实现酷炫的二维码生成

项目源码：https://github.com/liuyueyi/quick-media

Quick-Media 项目提供了一些列多媒体操作的开箱即用工具类，比如图片编辑合成，markdown/html/svg渲染，音频处理；当然还有本文重点说明的二维码生成解析

QrCode-Plugin支持丰富的酷炫二维码生成，大概十来天前有个小伙伴提了一个非常有意思的方向，能否将二维码中的黑白方块换成中文

趁着端午放假前夕的空闲时间，把这个集成在QrCode插件中，生成效果如下（从左往右，从上往下读，千字文😝）

Quick-Alarm时隔一年半，新增钉钉报警支持，在原有的项目基础上，新增报警规则比较简单；下面介绍一下实现与使用姿势

现在二维码可以说非常常见了，当然我们见得多的一般是白底黑块，有的再中间加一个logo，或者将二维码嵌在一张特定的背景中（比如微信、支付宝的收款码）；偶尔也可能看到一些酷炫的二维码，比如非黑白的、渐变色的、非方块样式的，或者说是动态的二维码

那么问题来了，走位一个java开发者而言，有没有什么开源库，可以简单迅速不烧脑的实现各种炫酷的二维码呢？

接下来我们将介绍下，如何借助 https://github.com/liuyueyi/quick-media 项目的 qrcode-plugin 来生成各种酷炫的二维码

前面两篇反射，分别介绍了如何封装参数和定位方法，对于最终的反射调用，还缺少的是目标类的确定和方法执行；本篇博文将目标集中在这最后一块

链上上两篇文章地址

• 190311-Quick-Fix 通过反射执行任意类目标方法的实现全程实录（上篇）
• 190315-Quick-Fix 通过反射执行任意类目标方法的实现全程实录（中篇）

全程实录上篇，主要介绍了如何解析传入的String参数为我们目标方法的参数类型和对象，其中主要讲述的是基本类型、Class类型、泛型以及普通的POJO类型转换；我们这一篇，目的则放在如何找到需要执行的类和方法，这里需要借助前面的参数解析结果来确定目标方法

反射可以说是java中非常强大的一个特性了，而我们的quick-fix整个项目，也都是基于反射的基础实现任意目标方法的调用执行，对于fix项目而已，核心在于以下几点

• 如何将外部请求定位我们需要执行的类、方法
• 如何将外部参数转换为目标方法的可执行参数
• 如何执行目标方法

简单来讲，就是封装参数为目标类型，定位目标，然后执行

如何实现应用内外交互，是Quick-Fix框架的核心之一，我们常见的应用有提供web服务的（如Spring应用），有进行大数据计算的（如Storm应用），有提供rpc的后台服务（如通过dubbo提供rpc的数据服务），有纯jar服务等；基本上我们可以划分为两类

• 应用本身，有一套健全的与外界交互的机制（这里不包括db/redis等数据的读写）
• 应用只关注自己的服务功能（接收数据，产生数据，保存数据），本身不与第三方的应用进行交互

针对上面这两种case，我们应该怎么来设计一套应用内外交互的方案，来实现接收外部请求，执行应用内部方法或访问应用内部数据，并返回结果的目的？

目前Quick-Fix框架提供了两种类型，三中不同场景下的Fixer，一种是以Jar方式启动的，一个是基于Spring生态体系玩法的，下面主要介绍这jar方式，如何使用QuickFix来实现应用内服务调用和数据订正

I. 背景说明

case1: 程序出bug了

在我们的实际工作中，当我们遇到别人反馈代码出问题了吧，怎么返回的数据不对？

当应用持续跑了一段时间之后，这个时候我们的第一个反应基本是确认能复现么？如果能复现，那么调用的姿势是不是对的？如果确认姿势没问题，那么就是请求参数不对了!!! 如果请求参数还没有问题，卧槽，这下完了，真可能有bug了，这下怎么办？

接下来，一般的讨论是在测试环境复现一下，如果能复现，那么开启debug（或者远程debug），一行行调试，相信很快就能搞定了；

但是，最怕的就是但是，测试环境没法复现，至于线上环境才有问题，这下怎么搞？

case2: 缓存数据有问题

另外一个场景就是为了提升服务性能，缓存基本上会被大量的使用在各个系统之间；有缓存，那么就会有缓存不一致的问题，如果缓存用的是外部的如(redis/memcache)之类的，那么缓存数据的查询和订正，就相对简单了；但是，如果我们使用了内存作为数据的缓存，比如（hashmap, guava)，这种时候，我想知道这个内存中的数据怎么办？我想修改这个内存的中的数据怎么办？

3. 小结

上面两个场景，归纳一下主要是两个问题

• 如何知道线上应用中，某个服务的方法的执行结果；
• 如何知道线上应用中，某些内存数据的结果

Quick-Task 动态脚本支持框架之Groovy脚本加载执行

上一篇简答说了如何判断有任务动态添加、删除或更新，归于一点就是监听文件的变化，判断目录下的Groovy文件是否有新增删除和改变，从而判定是否有任务的变更；

接下来的问题就比较明显了，当任务变更之后，就需要重新加载任务了，即如何动态的编译并执行Groovy文件呢？

相关系列博文：

• 180628-Quick-Task 动态任务执行框架想法篇
• 180702-Quick-Task 动态脚本支持框架整体介绍篇
• 180723-Quick-Task 动态脚本支持框架之结构设计篇
• 180729-Quick-Task 动态脚本支持框架之任务动态加载

Quick-Task 动态脚本支持框架之任务动态加载

前面几篇博文分别介绍了整个项目的基本架构，使用说明，以及整体框架的设计与实现初稿，接下来则进入更细节的实现篇，将整个工程中核心实现捞出来，从为什么这么设计到最终的实现给予说明

相关系列博文：

• 180702-QuickTask动态脚本支持框架整体介绍篇
• 180719-Quick-Task 动态脚本支持框架之使用介绍篇
• 180723-Quick-Task 动态脚本支持框架之结构设计篇

文章链接：https://liuyueyi.github.io/hexblog/2018/07/23/180723-Quick-Task-动态脚本支持框架之结构设计篇/

Quick-Task 动态脚本支持框架之结构设计篇

相关博文:

• 180702-QuickTask动态脚本支持框架整体介绍篇
• 180719-Quick-Task 动态脚本支持框架之使用介绍篇

前面两篇博文，主要是整体介绍和如何使用；接下来开始进入正题，逐步剖析，这个项目是怎么一步一步搭建起来的；本篇博文则主要介绍基本骨架的设计，围绕项目的核心点，实现一个基础的原型系统

Quick-Task 动态脚本支持框架之使用介绍篇

相关博文：

• 180702-QuickTask动态脚本支持框架整体介绍篇

QuickTask这个项目主要就是为了解决数据订正和接口验证不方便的场景，设计的一个及其简单的动态脚本调度框架，前面一篇整体介绍篇博文，主要介绍了这是个什么东西，整体的运行原理，以及一些简单的使用demo

本篇博文将主要放在应用场景的探讨上，在实际的项目环境中，可以怎么用

Quick-Task 动态脚本支持框架整体介绍篇

一个简单的动态脚本调度框架，支持运行时，实时增加,删除和修改动态脚本，可用于后端的进行接口验证、数据订正，执行定时任务或校验脚本

本项目主要涉及到的技术栈:

• groovyEngine （groovy脚本加载执行）
• commons-io （文件变动监听）

java原生对于图片的编辑处理并没有特别友好，而且问题也有不少，那么作为一个java后端，如果要提供图片的编辑服务可以怎么办？也得想办法去支持业务需求，本片博文基于此进行展开

本篇主要是扩展默认的报警规则，使其能更加友好的支持同时选择多种报警方式

扩展遵循两个原则

• 不影响原有的配置文件格式
• 简化规则解析复杂度

本文将主要说明QuickAlarm该如何使用，以及使用时需要注意事项

前面将报警规则的制定加载解析，以及报警执行器的定义加载和扩展进行了讲解，基本上核心的内容已经完结，接下来剩下内容就比较简单了

• 报警频率的统计
• 报警线程池
• 对外封装统一可用的解耦

前面两篇分别说了报警执行器和报警规则的定义及用户扩展加载，接下来就是比较核心的一块了，如何将报警规则和报警执行器关联起来，即当发生报警时，应该call哪一个报警执行器

前面一篇是报警执行器的定义与加载已经完成，但与之对应的报警规则有是如何定义和加载的呢？

此外，既然命名为规则，那么就需要有对应的解析器，以根据报警规则和报警类型等相关输入条件，来选择对应的报警执行器，因此本文主要包括的内容就比较清晰了

• 报警规则的定义
• 报警规则的加载
• 报警规则的解析以及报警执行器选择

根据前面一篇总纲的博文，将整体结构划分为了四大块，本文则主要目标集中在第一块，报警执行器（AlarmExecute）的设计与加载上了

主要的关注点无外乎 定义-》加载-》实现逻辑三块了：

• AlarmExecute 的接口定义
• 如何加载用户自定义的AlarmExecute
• AlarmExecute的内部实现

背景

日常的系统中，报警是不可缺少的一环，目前报警方式很多，最常见的有直接打日志，微信报警，短信报警，邮件报警等；而涉及到报警，一般不可避免的需要提前设置一些基本信息，如报警方式，报警频率，报警用户，开关等；

另外一个常见的问题是一般采用的是单一的报警方式，比如不管什么类型的报警全部都用短信方式触达，然后就会发现手机时常处于被淹没的状态了，久而久之对报警短信就不会敏感了

第五篇，对象池的设计与实现

前面每爬取一个任务都对应一个Job任务，试想一下，当我们爬取网页越来越多，速度越来越快时，就会出现频繁的Job对象的创建和销毁，因此本片将考虑如何实现对象的复用，减少频繁的gc

设计

我们的目标是设计一个对象池，用于创建Job任务，基本要求是满足下面几点:

• 可以配置对象池的容量大小
• 通过对象池获取对象时，遵循一下规则：
  • 对象池中有对象时，总对象池中获取
  • 对象池中没有可用对象时，新创建对象返回（也可以采用阻塞，直到有可用对象，我们这里采用直接创建新对象方式）
• 对象用完后扔回对象池

第四篇, 日志埋点输出 & 动态配置支持

前面基本上实现了一个非常简陋的爬虫框架模型，很多关键链路都没有日志，在分析问题时，就比较麻烦了，因此就有了这一篇博文

其次就是解决前几篇遗留的容易解决的问题

实际上，日志的输出应该贯穿在实际的开发过程中的，由于之前写得比较随意，直接System.out了, 所以现在就来填坑了

第三篇 爬取队列的实现

第二篇中，实现了深度爬取的过程，但其中一个比较明显的问题就是没有实现每个爬取作为一个独立的任务来执行；即串行的爬取网页中的链接；因此，这一篇将主要集中目标在并发的爬网页的问题上

目标是每个链接的爬取都当做一个独立的job来执行

第二篇:深度爬取

前面实现了一个最基础的爬取单网页的爬虫，这一篇则着手解决深度爬取的问题

简单来讲，就是爬了一个网页之后，继续爬这个网页中的链接

第一篇实现一个最简单爬虫

准备写个爬虫， 可以怎么搞？

I. 使用场景

先定义一个最简单的使用场景，给你一个url，把这个url中指定的内容爬下来，然后停止

• 一个待爬去的网址（有个地方指定爬的网址）
• 如何获取指定的内容（可以配置规则来获取指定的内容）

使用测试

前面三篇主要是介绍如何设计的，如何实现的，这一篇，则主要集中在如何使用。实现得再好，如果不好用，也白搭

本篇介绍几个简单的使用case，包括静态使用，动态适配，自定义选择器等

实现说明

前一篇 《SPI框架实现之旅二：整体设计》中，介绍了几个定义的接口，注解；叙述了实现流程；并简单的介绍了 SpiLoader中的部分实现； 本篇则主要介绍SpiLoader类的实现

类图结构如下：

整体设计

上一篇简单的说了一下spi相关的东西， 接下来我们准备开动，本篇博文主要集中在一些术语，使用规范的约定和使用方式

背景介绍

SPI的全名为Service Provider Interface，简单的总结下java spi机制的思想。我们系统里抽象的各个模块，往往有很多不同的实现方案，比如日志模块的方案，xml解析模块、jdbc模块的方案等。面向的对象的设计里，我们一般推荐模块之间基于接口编程，模块之间不对实现类进行硬编码。一旦代码里涉及具体的实现类，就违反了可拔插的原则，如果需要替换一种实现，就需要修改代码。为了实现在模块装配的时候能不在程序里动态指明，这就需要一种服务发现机制。 java spi就是提供这样的一个机制：为某个接口寻找服务实现的机制