前言

针对于我们现在常用的RESTful API通常我们需要对请求进行唯一标识，也就是每次都要带上一个请求号,如reqNO。

对于入库这种操作数据库的请求我们一般要保证他的唯一性，一个请求号通常只能用一次，所以需要我们对这种请求加上校验机制。

该需求的实现思路是通过自定义annotation，只给需要进行校验的接口加上注解。然后通过切面使用了注解的接口将每次请求号存进Redis，每次都进行判断是否存在这个请求号即可。

来看下加上本次插件的实际效果：

前言

通常来说一个dubbo服务都是对内给内部调用的，但也有可能一个服务就是需要提供给外部使用，并且还不能有使用语言的局限性。

比较标准的做法是对外的服务我们统一提供一个openAPI，这样的调用方需要按照标准提供相应的appID以及密钥来进行验签才能使用。这样固然是比较规范和安全，但复杂度也不亚于开发一个单独的系统了。

这里所讲到的没有那么复杂，就只是把一个不需要各种权限检验的dubbo服务对外提供为HTTP服务。

调用示例:

在如今的HTTPS大当其道的情况下自己的博客要是还没有用上。作为互联网的螺丝钉(码农)岂不是很没面子。

使用CLOUDFLARE

这里使用CLOUDFLARE来提供HTTPS服务。

• 在其官网进行注册，按照提示添加好自己的域名即可。
• 之后需要在自己域名的提供商处修改DNS服务器，我是在万网购买的修改后如下图：
  
  其中的DNS服务器地址由CLOUDFLARE是提供的。
  修改完成之后通常需要等待一段时间才能生效。
• 接着在CLOUDFLARE配置DNS解析：
  
  点击CLOUDFLARE顶部的DNS进行如我上图中的配置，和之前的配置没有什么区别。

等待一段时间之后发现使用HTTP,HTTPS都能访问，但是最好还是能在访问HTTP的时候能强制跳转到HTTPS.

• 在CLOUDFLARE菜单栏点击page-rules之后新建一个page rule：
  
  这样整个网站的请求都会强制到请求到HTTPS.

前言

在之前dubbo分布式框架中讲到了如何利用dubbo来搭建一个微服务项目。其中还有一些值得优化提高开发效率的地方，比如日志：

当我们一个项目拆分为N多个微服务之后，当其中一个调用另一个服务出现了问题，首先第一步自然是查看日志。

出现问题的有很多情况，如提供方自身代码的问题，调用方的姿势不对等。

自身的问题这个管不了，但是我们可以对每一个入参、返回都加上日志，这样首先就可以判断调用方是否姿势不对了。

为了规范日志已经后续的可扩展，我们可以单独提供一个插件给每个项目使用即可。

效果如下：

1
2
3
4
5
6
7
8
9
10
11
12
13

2017-04-25 15:15:38,968 DEBUG [com.alibaba.dubbo.remoting.transport.DecodeHandler] -  [DUBBO] Decode decodeable message com.alibaba.dubbo.rpc.protocol.dubbo.DecodeableRpcInvocation, dubbo version: 2.5.3, current host: 127.0.0.1
2017-04-25 15:15:39,484 DEBUG [com.crossoverJie.dubbo.filter.DubboTraceFilter] - dubbo请求数据:{"args":[1],"interfaceName":"com.crossoverJie.api.UserInfoApi","methodName":"getUserInfo"}
2017-04-25 15:15:39,484 INFO [com.crossoverJie.api.impl.UserInfoApiImpl] - 用户查询Id=1
2017-04-25 15:15:39,505 DEBUG [org.mybatis.spring.SqlSessionUtils] - Creating a new SqlSession
2017-04-25 15:15:39,525 DEBUG [org.mybatis.spring.SqlSessionUtils] - SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@6f56b29] was not registered for synchronization because synchronization is not active
2017-04-25 15:15:39,549 DEBUG [org.mybatis.spring.transaction.SpringManagedTransaction] - JDBC Connection [com.alibaba.druid.proxy.jdbc.ConnectionProxyImpl@778b3121] will not be managed by Spring
2017-04-25 15:15:39,555 DEBUG [com.crossoverJie.api.dubbo.dao.T_userDao.selectByPrimaryKey] - ==>  Preparing: select id, username, password,roleId from t_user where id = ? 
2017-04-25 15:15:39,591 DEBUG [com.crossoverJie.api.dubbo.dao.T_userDao.selectByPrimaryKey] - ==> Parameters: 1(Integer)
2017-04-25 15:15:39,616 DEBUG [com.crossoverJie.api.dubbo.dao.T_userDao.selectByPrimaryKey] - <==      Total: 1
2017-04-25 15:15:39,616 DEBUG [com.alibaba.druid.pool.PreparedStatementPool] - {conn-10003, pstmt-20000} enter cache
2017-04-25 15:15:39,617 DEBUG [org.mybatis.spring.SqlSessionUtils] - Closing non transactional SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@6f56b29]
2017-04-25 15:15:45,473 INFO [com.crossoverJie.dubbo.filter.DubboTraceFilter] - dubbo执行成功
2017-04-25 15:15:45,476 DEBUG [com.crossoverJie.dubbo.filter.DubboTraceFilter] - dubbo返回数据{"args":[{"id":1,"password":"123456","roleId":1,"userName":"crossoverJie"}],"interfaceName":"com.crossoverJie.api.UserInfoApi","methodName":"getUserInfo"}

前言

现在越来越多的互联网公司还是将自己公司的项目进行服务化，这确实是今后项目开发的一个趋势，就这个点再凭借之前的SSM项目来让第一次接触的同学能快速上手。

浅谈分布式架构

分布式架构单看这个名字给人的感觉就是高逼格，但其实从历史的角度来分析一下就比较明了了。

我们拿一个电商系统来说：

单系统

对于一个刚起步的创业公司项目肯定是追求越快完成功能越好，并且用户量也不大。

前言

很久没有更新博客了，之前定下周更逐渐成了月更。怎么感觉像我追过的一部动漫。
这个博文其实很早就想写了。
之前所有的代码都是在一个模块里面进行开发，这和maven的理念是完全不相符的，最近硬是抽了一个时间来对项目的结构进行了一次重构。

先来看看这次重构之后的目录结构

前言

相信做Java的童鞋或多或少都听过反射，这也应该是Java从入门到进阶的必经之路。

但是在我们的实际开发中直接使用它们的几率貌似还是比较少的，（除了造轮子或者是Spring Mybatis这些框架外）。

所以这里介绍一个在实际开发中还是小有用处的反射实例。

传统日志

有关反射的一些基本知识就不说了，可以自行Google，也可以看下反射入门。

日志相信大家都不陌生，在实际开发中一些比较敏感的数据表我们需要对它的每一次操作都记录下来。

先来看看传统的写法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

@Test
public void insertSelective() throws Exception {

    Content content = new Content() ;
    content.setContent("asdsf");
    content.setCreatedate("2016-12-09");
    contentService.insertSelective(content) ;

    ContentLog log = new ContentLog();
    log.setContentid(content.getContentid());
    log.setContent("asdsf");
    log.setCreatedate("2016-12-09");
    contentLogService.insertSelective(log);
}

非常简单，就是在保存完数据表之后再把相同的数据保存到日志表中。

前言

在现在开发的过程中应该大多数朋友都有遇到过切换数据源的需求。比如现在常用的数据库读写分离，或者就是有两个数据库的情况，这些都需要用到切换数据源。

手动切换数据源

使用Spring的AbstractRoutingDataSource类来进行拓展多数据源。

该类就相当于一个dataSource的路由，用于根据key值来进行切换对应的dataSource。

下面简单来看下AbstractRoutingDataSource类的几段关键源码：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

@Override
public Connection getConnection() throws SQLException {
	return determineTargetDataSource().getConnection();
}

@Override
public Connection getConnection(String username, String password) throws SQLException {
	return determineTargetDataSource().getConnection(username, password);
}

/**
 * Retrieve the current target DataSource. Determines the
 * {@link #determineCurrentLookupKey() current lookup key}, performs
 * a lookup in the {@link #setTargetDataSources targetDataSources} map,
 * falls back to the specified
 * {@link #setDefaultTargetDataSource default target DataSource} if necessary.
 * @see #determineCurrentLookupKey()
 */
protected DataSource determineTargetDataSource() {
	Assert.notNull(this.resolvedDataSources, "DataSource router not initialized");
	Object lookupKey = determineCurrentLookupKey();
	DataSource dataSource = this.resolvedDataSources.get(lookupKey);
	if (dataSource == null && (this.lenientFallback || lookupKey == null)) {
		dataSource = this.resolvedDefaultDataSource;
	}
	if (dataSource == null) {
		throw new IllegalStateException("Cannot determine target DataSource for lookup key [" + lookupKey + "]");
	}
	return dataSource;
}

/**
 * Determine the current lookup key. This will typically be
 * implemented to check a thread-bound transaction context.
 * <p>Allows for arbitrary keys. The returned key needs
 * to match the stored lookup key type, as resolved by the
 * {@link #resolveSpecifiedLookupKey} method.
 */
protected abstract Object determineCurrentLookupKey();

可以看到其中获取链接的方法getConnection()调用的determineTargetDataSource则是关键方法。该方法用于返回我们使用的数据源。

前言

早在这个月初的时候我就很想写一篇年终总结了，因为这一年相对于去年确实是经历的太多了。
结果一直等到31号，在家里和媳妇吃完晚饭就马上打开电脑开码。

五月二十三-第一次跳槽

根据整年的时间线开始第一件大事自然就是换公司了。

先来点前景提要:我是14年11月份参加工作的。当时其实还没有毕业就在一家给大型企业做定制软件开发的公司实习。刚开始工作的时候什么事情都觉得非常新奇，一个在学校学的东西能运用到实际开发中并能给用户带来便利让我觉得做码农真是一件非常正确的选择啊(ps当时真是太年轻)。

后来真是造化弄人，当时负责我参与的这个项目的负责人跳槽了，我自然就成了整个公司最熟悉此项目的人了。现在不得不佩服公司老板真是心大啊，居然让一个实习生来负责这个项目。就这样我成了整个项目的负责人，从之后的开发到测试到上线到后面的维护几乎都是我一个人在负责。
来一张当时上线的截图：

由于这次项目的顺利验收，公司也对我越来越信任。之后也就理所当然的又负责了几个项目。

前言

由于最近换(mang)了(de)家(yi)公(bi)司接触了新的东西所以很久没有更新了。
这次谈谈Redis，关于Redis应该很多朋友就算没有用过也听过，算是这几年最流行的NoSql之一了。
Redis的应用场景非常多这里就不一一列举了，这次就以一个最简单的也最常用的 缓存数据 来举例。
先来看一张效果图：