190315-Quick-Fix 通过反射执行任意类目标方法的实现全程实录(中篇)

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

190311-Quick-Fix 通过反射执行任意类目标方法的实现全程实录(上篇)

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

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

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

190108-Quick-Fix 如何优雅的实现应用内外交互之接口设计篇

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

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

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

190104-Quick-Fix 纯Jar应用及扩展手册

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

190102-Quick-Fix 从0到1构建一个应用内服务/数据访问订正工具包

I. 背景说明

Builder

case1: 程序出bug了

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

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

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

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

case2: 缓存数据有问题

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

3. 小结

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

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

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

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

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

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

相关系列博文:

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

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

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

相关系列博文:

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

logo

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

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

相关博文:

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

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

logo

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

相关博文:

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

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

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

logo

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

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

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

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

Java 借助ImageMagic实现图片编辑服务

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

7. 报警系统QuickAlarm之默认报警规则扩展

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

扩展遵循两个原则

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

6. 报警系统QuickAlarm使用手册

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

5. 报警系统QuickAlarm之频率统计及接口封装

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

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

4. 报警系统QuickAlarm之报警规则解析

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

3. 报警系统QuickAlarm之报警规则的设定与加载

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

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

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

2. 报警系统QuickAlarm之报警执行器的设计与实现

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

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

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

1. 报警系统QuickAlarm设计总纲

背景

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

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

Java 动手写爬虫: 五 对象池

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

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

设计

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

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

Java 动手写爬虫: 四、日志埋点输出 & 动态配置支持

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

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

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

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

Java 动手写爬虫: 三、爬取队列

第三篇 爬取队列的实现

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

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

Java 动手写爬虫: 二、 深度爬取

第二篇:深度爬取

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

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

Java 动手写爬虫: 一、实现一个最简单爬虫

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

准备写个爬虫, 可以怎么搞?

I. 使用场景

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

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

4. SPI框架实现之旅四:使用测试

使用测试

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

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

3. SPI框架实现之旅三:实现说明

实现说明

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

类图结构如下:

https://static.oschina.net/uploads/img/201705/27183336_TOny.png

2. SPI框架实现之旅二:整体设计

整体设计

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

1. SPI框架实现之旅一:背景介绍

背景介绍

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

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×