Java中的魔法: SPI

Java中的魔法: SPI

SPI 全称为 (Service Provider Interface) ,是JDK内置的一种服务提供发现机制,常用于创建可扩展、可替换组件的应用程序,是java中模块化插件化的关键。

SPI 框架包含3个基本组件:

  1. 服务接口 Service Interface
  2. 服务接口的实现类,Service Provider
  3. 服务加载器 Service Loader

Service Interface是一组定义标准的接口和类。Service Provider是服务接口的特定实现,需要实现接口,并子类化服务本身中定义的类。java.util包下的ServiceLoader类就是SPI机制的核心类,主要功能是通过相关的类加载器扫描并加载provider的jar包,并且通过反射实例化服务的实现类。服务Provider程序可以以扩展的形式安装在Java平台的实现中,也就是说,可以将provider的jar文件放置在任何常用扩展目录中,也可以通过将其jar包添加到应用程序的类路径或通过其他一些特定于平台的方式来使使用方来调用。

ServiceLoader机制允许用户在其应用程序代码保持不变的前提下扩展程序功能或者添加新功能。例如SLF4J本身只是API,日常编程中我们只需要使用LogFactory获得log实例,而不用关心底层是的日志实现框架是Logback还是Log4J;java.sql.Driver是在java中定义的标准SQL服务API,如果需要从oracal数据库切换到mysql数据库,我们的数据访问层代码不需要任何修改,只需要替换掉jdbc 驱动包即可。

JDK中包含了非常多的SPI服务功能(如servlet、邮件服务、音频服务、SQL驱动,大部分位于javax),以供不同的服务厂商或者插件商基于标准定义实现自己的方案。除了能够服务于厂商或插件商,JavaSPI 也为我们实现框架扩展提供了一个不错思路。当一个功能可能会有两种以上的实现方案时,可以在应用程序中预留出 SPI 接口,剩下的适配工作便留给了开发者,这样可以在不侵入代码的前提下,通过增删依赖来扩展框架

解密SPI

目标:实现消息推送功能,要求后期能够切换不同推送厂商的推送服务(例如极光推送、小米推送、百度推送等等)


GIT多仓库迁移合并技术方案

领导说:

​ “目前各个项目分散在不同的仓库中,不利于管理,需要将多个项目仓库合并到一个工程仓库来进行开发,要求保留各个仓库迁移前的commits 记录,最好还能对命名不规范的项目进行重命名”

恕我直言,可以实现!

Git 多仓库合并

假设要合并ABC 不同的分支到新工程X,ABC 工程作为X工程的子目录

迁移A 工程的5.0分支到新工程X的A1目录

迁移B工程的dev分支 到新工程X的B1目录

迁移C 工程的6.0分支 到新工程X的C1目录

期望:合并后的目录结构

新工程X(master分支)
.
├── A1 (原A工程的某分支)
├── B1 (原B工程的某分支)
├── C1 (原C工程的某分支)
.git
README.md


网页长截图

网页长截图

雄文十万,也挡不住管理方的删帖封号,本文就来说一下怎么通过技术的方式来保存网页内容


oauth2-client在Nginx代理后遇到的问题和解决方案

OAuth2 Client在实际运用过程中遇到的问题

服务程序集成了OAuth2-Client,以便于用户能够方便集成到支持OAuth2第三方登录的自有业务系统中。开发完成后,本地测试、或者直连服务程序,都没有问题。但凡放到线上环境,经过了nginx 转发后,我们的服务程序OAuth登录永远是以失败告终。

现象如下:

访问需要授权的接口时 https://blog.95id.com:4005/user_attr,期望是跳转到授权服务器 github.com进行登录授权,但实际都是跳转到``http://blog.95id.com/login`

因为当时直接用服务程序的端口没问题,就将解决思路放在了nginx 转发过程上。

当时线上环境路由规则类似于:

第一层:nginx1 4005 (ssl、负载均配置在这)

第二层:nginx2 4005

第三层:oauth2-client 8082

再看nginx 的配置,第一层nginx 配置:


Aspectj LTW 实践

Aspectj LTW 实践

本文将介绍使用 AspectJ,介绍它的 3 种织入方式。

AspectJ 作为 AOP 编程的完全解决方案,提供了三种织入时机,分别为

  1. compile-time:编译期织入,在编译的时候一步到位,直接编译出包含织入代码的 .class 文件
  2. post-compile:编译后织入,增强已经编译出来的类,如我们要增强依赖的 jar 包中的某个类的某个方法
  3. load-time:在 JVM 进行类加载的时候进行织入

AOP 面向切面编程

AOP 面向切面编程

概念

大家都知道OOP,即ObjectOriented Programming,面向对象编程。而本文要介绍的是AOP。AOP是Aspect Oriented Programming的缩写,中译文为面向切向编程。OOP和AOP是什么关系呢?首先:

在OOP的世界中,问题或者功能都被划分到一个一个的模块里边。每个模块专心干自己的事情,模块之间通过设计好的接口交互

OOP和AOP都是方法论。我记得在刚学习C++的时候,最难学的并不是C++的语法,而是C++所代表的那种看问题的方法,即OOP。同样,今天在AOP中,我发现其难度并不在利用AOP干活,而是从AOP的角度来看待问题,设计解决方法。这就是为什么我特意强调AOP是一种方法论的原因

###AOP

Java 语言中,从织入切面的方式上看,存在三种织入方式:编译期织入、类加载期织入和运行时织入。

编译期织入是指在Java编译期,采用特殊的编译器,将切面织入到Java类中;而类加载织入则指通过通过特殊的类加载器,在类字节码加载到JVM时,织入切面;运行期织入则是采用CGLib工具或者JDK动态代理进行切面的织入。

所以,AOP 代理则可分为静态代理和动态代理两大类

  • 静态代理是指使用 AOP 框架提供的命令进行编译,从而在编译阶段就可生成 AOP 代理类,因此也称为编译时增强;典型代表Aspectj。
  • 动态代理则在运行时借助于 JDK 动态代理、CGLIB 等在内存中“临时”生成 AOP 动态代理类,因此也被称为运行时增强

【PaaS】认证、授权、鉴权和权限控制

【PaaS】认证、授权、鉴权和权限控制

本篇将对信息安全领域中(主要指)认证、授权、鉴权和权限控制这四个概念给出相应的定义,并对这个概念之间的相互关系进行梳理。

1. 认证

认证是指根据声明者所特有的识别信息,确认声明者的身份。认证在英文中对应于identification这个单词。

最常见的认证实现方式是通过用户名和密码,但认证方式不限于此。下面都是当前常见到的认证技术,

  • 身份证
  • 用户名和密码
  • 用户手机:手机短信、手机二维码扫描、手势密码
  • 用户的电子邮箱
  • 基于时间序列和用户相关的一次性口令
  • 用户的生物学特征:指纹、语音、眼睛虹膜
  • 用户的大数据识别
  • 等等

为了确认用户的身份,防止伪造,在安全要求高的场合,经常会使用组合认证(或者叫多因素认证),也就是同时使用多个认证方式对用户的身份进行校验。


Python效率提升技巧

Python 效率提升技巧

副标题:超三成的python 初学者,倒在了这三个坑内

坊间流传着一句经典:“人生苦短,我用Python!”

python目前斩获的头衔有:挤掉java成为编程语言排行第二、增量最快、AI时代头牌语言,甚至已经入选北京山东等地的中小学教材,因为其简单易用,适用广泛,已经成为很多初学编程人的首选语言。

但由于Python的某些特有的历史原因,例如版本兼容问题等,导致在学习的过程中,总会遇到几个大坑,导致刚刚萌芽的学习热情就被无情浇灭。本篇主要讲解初学python过程中最常遇到的3个大坑:

  1. 版本兼容问题
  2. 依赖包无法下载安装问题
  3. 工程依赖环境问题

学习这几点,初学者不再倒在入门的门槛上,轻松入门;已入门的,可以帮您提高python开发使用和效率


金融系统中正确的金额计算及存储方式

金融系统中正确的金额计算及存储方式

经典的精度丢失问题

Java中的类型float、double用来做计算会有精度丢失问题,下面来看下面的示例。

1
2
3
4
5
6
7
8
9
10
11
public static void main(String[] args) {
test1();
test2();
}

private static void test1() {
double totalAmount = 0.09;
double feeAmount = 0.02;
double tradeAmount = totalAmount - feeAmount;
System.out.println(tradeAmount);
}

上面的程序输出结果是多少?

0.07?非也!

正确的结果是:

1
0.06999999999999999

为什么是这样?


Nginx配置经验

1. Nginx 会导致 带下划线命名的Header参数丢失

nginx对下划线的头信息做了限制

  1. 不用下划线

  2. 配置nginx 参数

    underscores_in_headers on; (默认 underscores_in_headers 为off)

2. nginx proxy_pass后的url加不加/的区别

第一种:proxy_pass后缀不加斜杠

1
2
3
location /abc/ {
proxy_pass http://172.16.1.38:8080;
}

第二种:proxy_pass后缀加斜杠

1
2
3
location /abc/ {
proxy_pass http://172.16.1.38:8081/;
}

上面两种配置,区别只在于proxy_pass转发的路径后是否带/


Your browser is out-of-date!

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

×