前言 上一篇简单入门了SpringBoot+SpringCloud 构建微服务。但只能算是一个demo级别的应用。这次会按照实际生产要求来搭建这套服务。 Swagger应用上次提到我们调用自己的http接口的时候采用的是PostMan来模拟请求，这个在平时调试时自然没有什么问题，但当我们需要和前端联调开发的时候效率就比较低了。 通常来说现在前后端分离的项目一般都是后端接口先行。 后端大大们先把

前言随着互联网的兴起，现在三高(高可用、高性能、高并发)项目是越来越流行。 本次来谈谈高并发。首先假设一个业务场景：数据库中有一条数据，需要获取到当前的值，在当前值的基础上+10，然后再更新回去。如果此时有两个线程同时并发处理，第一个线程拿到数据是10，+10=20更新回去。第二个线程原本是要在第一个线程的基础上再+20=40,结果由于并发访问取到更新前的数据为10，+20=30。 这

前言 有看过我之前的SSM系列的朋友应该有一点印象是非常深刻的。 那就是需要配置的配置文件非常多，什么Spring、mybatis、redis、mq之类的配置文件非常多，并且还存在各种版本，甚至有些版本还互不兼容。其中有很多可能就是刚开始整合的时候需要配置，之后压根就不会再动了。 鉴于此，Spring又推出了又一神器SpringBoot. 它可以让我们更加快速的开发Spring应用，甚至做到了

前言针对于我们现在常用的RESTful API通常我们需要对请求进行唯一标识，也就是每次都要带上一个请求号,如reqNO。 对于入库这种操作数据库的请求我们一般要保证他的唯一性，一个请求号通常只能用一次，所以需要我们对这种请求加上校验机制。 该需求的实现思路是通过自定义annotation，只给需要进行校验的接口加上注解。然后通过切面使用了注解的接口将每次请求号存进Redis，每次都进行判断是

前言通常来说一个dubbo服务都是对内给内部调用的，但也有可能一个服务就是需要提供给外部使用，并且还不能有使用语言的局限性。 比较标准的做法是对外的服务我们统一提供一个openAPI，这样的调用方需要按照标准提供相应的appID以及密钥来进行验签才能使用。这样固然是比较规范和安全，但复杂度也不亚于开发一个单独的系统了。 这里所讲到的没有那么复杂，就只是把一个不需要各种权限检验的dubbo服务对外

在如今的HTTPS大当其道的情况下自己的博客要是还没有用上。作为互联网的螺丝钉(码农)岂不是很没面子。 使用CLOUDFLARE这里使用CLOUDFLARE来提供HTTPS服务。 在其官网进行注册，按照提示添加好自己的域名即可。 之后需要在自己域名的提供商处修改DNS服务器，我是在万网购买的修改后如下图：其中的DNS服务器地址由CLOUDFLARE是提供的。修改完成之后通常需要等待一段时间才能

前言在之前dubbo分布式框架中讲到了如何利用dubbo来搭建一个微服务项目。其中还有一些值得优化提高开发效率的地方，比如日志： 当我们一个项目拆分为N多个微服务之后，当其中一个调用另一个服务出现了问题，首先第一步自然是查看日志。 出现问题的有很多情况，如提供方自身代码的问题，调用方的姿势不对等。 自身的问题这个管不了，但是我们可以对每一个入参、返回都加上日志，这样首先就可以判断调用

前言现在越来越多的互联网公司还是将自己公司的项目进行服务化，这确实是今后项目开发的一个趋势，就这个点再凭借之前的SSM项目来让第一次接触的同学能快速上手。 浅谈分布式架构分布式架构单看这个名字给人的感觉就是高逼格，但其实从历史的角度来分析一下就比较明了了。 我们拿一个电商系统来说： 单系统对于一个刚起步的创业公司项目肯定是追求越快完成功能越好，并且用户量也不大。

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

前言相信做Java的童鞋或多或少都听过反射，这也应该是Java从入门到进阶的必经之路。 但是在我们的实际开发中直接使用它们的几率貌似还是比较少的，（除了造轮子或者是Spring Mybatis这些框架外）。 所以这里介绍一个在实际开发中还是小有用处的反射实例。 传统日志有关反射的一些基本知识就不说了，可以自行Google，也可以看下反射入门。 日志相信大家都不陌生，在实际开发中一些比较敏感的数据