前言

由于我的工作中开发环境就是windows，IDE是eclipse，因此安装也只涉及和记录这两部分，在看书和动手的过程也就直接跳过其他部分。

继续阅读全文 »

前言

应公司要求，这一次的开发需要进行sonar进行静态代码质量检测。
接到这个任务的时候，我还并不知道sonar是什么，但听到静态代码检测几个字的时候，我下意识的以为是类似checkstyle之类的工具，但是真正用过之后我发现我错了。
我发现实际运行的时候，似乎并不纯粹是静态，因为整个检测过程中还会连接数据库，还会发送http请求，还会连接svn等等。
用完之后，深感这个工具的好用，不检测不知道，一检测吓一跳，竟然检查出来了26个bugs，可靠性级别是像毒血一样的黑红E。
那么废话不再多说，进入主题，记录一下整个环境搭建和检测过程，以便备忘。

继续阅读全文 »

前言

工欲善其事，必先利其器。对于java web开发者而言，或者说对于目前大部分java web开发者而言，eclipse、maven、svn、tomcat可能就是目前最常用也是必会的武器了，所以为了更高效的开发和解决问题，经过一番思考后我决定系统性的学学这几样武器。
这几样在我看来一样的重要，也就没有先后之分。都要学，于是我便随便抽了一个，就先从maven开始，主要是结合《maven实战》一书的电子版和纸质版来学习和实践。
为了更好的记忆，同时也为了能在学习的过程中帮到更多人，遂决定做这个系列的笔记。

继续阅读全文 »

面临的问题

不知不觉间，自己就已经有了三四年的实际工作经验了，虽然一直有在技术上不断的学习，但是最近一段时间似乎是遇到了一些瓶颈。
这些瓶颈具体表现是
随着接触的东西变多，越发的觉得自己知识深度匮乏，虽然似乎这也知道那也知道，目前很多工作问题也能解决，但是总觉得不会的越来越多。
java基础、spring原理、数据库、设计模式、分布式等等，遇到深一点的问题就总会有种力不从心的感觉，但因为欠缺的过多，一时之间就有种无从下手的感觉，茫然！

继续阅读全文 »

要把本地的数据提交到github远程仓库，需要几个必要的步骤，以下是根据自己的操作简单记录。

前提条件是本地安装好了git，并且做好了相应配置

继续阅读全文 »

在java的几十种设计模式中，可能单例模式算是最容易理解的吧！因为不论是目前的我自己，还是偶尔面试的别人，能稍微讲清楚的，基本就是单例模式。
什么叫单例模式？顾名思义，就是单一的实例，唯一的实 例。也就是说对于某个java类来说，他的实例对象最多只能创建一个。

继续阅读全文 »

有很多爱分享的技术人，都会在网上或多或少的写博客，一开始可能都是在那些有名气的网站上发表，例如CSDN、开源中国等，一方面是分享，一方面是作为自己的笔记。
但是时间久了就会发现在这种网站上写博客会受到各种制约和限制，如果网站本身技术不是很好或者其他原因，还会经常出现无法访问的情况。

继续阅读全文 »

之前在学习spring cloud微服务的时候，由于spring cloud的基础是spring boot，因此曾简单地了解过spring boot，但也只是简单的了解过而已。
而现在，需要把struts2项目改为spring boot，一开始时以为是整个项目重构，不仅限于struts2部分，因此就相对更系统、更细致的学了一下spring boot。
整个过程由易到难，大概分成了这么些模块：

继续阅读全文 »

使用

通过前边的学习，服务注册中心、服务提供者和服务消费者都成功建立并运行起来，而且通过默认的配置restTemplate及@loadbalanced注解开启了负载均衡。
在默认的情况下，负载均衡策略是线性轮询的方式，也就是说在客户端获取到的服务列表中依次交替，例如开启了三个服务server1、server2、server3，那么在线性轮询时，就会按这个顺序来调用。
我之前是开启了两个服务，一个端口是1001，另一个是2001，那么在之前的这种情况下，如果我关闭其中一个服务，就比如这里关闭1001端口的服务，当再次访问的时候，每访问两次，就会有一次是如下的error page：

Whitelabel Error Page
This application has no explicit mapping for /error, so you are seeing this as a fallback.
Fri May 26 09:31:57 CST 2017
There was an unexpected error (type=Internal Server Error, status=500).
I/O error on GET request for "http://HELLO-SERVICE/hello": Connection refused: connect; nested exception is java.net.ConnectException: Connection refused: connect

同时后台也会打印出错误日志：

java.net.ConnectException: Connection refused: connect
    at java.net.DualStackPlainSocketImpl.connect0(Native Method) ~[na:1.8.0_131]
    at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source) ~[na:1.8.0_131]
    at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source) ~[na:1.8.0_131]
    at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source) ~[na:1.8.0_131]
    at java.net.AbstractPlainSocketImpl.connect(Unknown Source) ~[na:1.8.0_131]
    at java.net.PlainSocketImpl.connect(Unknown Source) ~[na:1.8.0_131]
    at java.net.SocksSocketImpl.connect(Unknown Source) ~[na:1.8.0_131]
    at java.net.Socket.connect(Unknown Source) ~[na:1.8.0_131]

其实这个问题的原因就是，客户端的服务列表并不是在服务关闭的瞬间就会同步更新，而是根据它自己配置的更新服务列表间隔的时间每隔一段时间去注册中心获取一次。
因此，虽然这里我关闭了1001端口，但是实际上客户端并不知道，在它负载均衡进行线性轮询时，依旧会轮询之前保存的服务列表，但是发送请求后却发现这个服务实例并不存在，无法连接，于是就出现了上边的500错误。
这里为了演示，我是主动关闭了服务，但实际生产的过程中，难免会出现服务宕机或者网络故障等方面的问题，从而导致类似的无法连接到服务实例的情况。
那么这时候正常来说在这个故障恢复之前是不应该继续连接的，起码就算连接了也应该给用户展示更加友好的界面或其他信息，至于具体的情况就需要具体对待了。
而解决这个问题，就引出了服务容错保护机制Hystrix，也叫断路器。
既然之前说了消费方保存的服务列表是自己主动获取的，并非被动推送来的，那么可想而知这个断路器的定义也应该是在服务消费方。
首先需要引入hystrix相应的依赖，在之前的消费端pom.xml的基础上加上如下的配置：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>

同时在服务消费端的主类加上@@EnableCircuitBreaker注解，这个注解的作用就是开启断路器功能，所谓的主类就是具有main方法的那个类，修改之后这里的代码如下：

@EnableCircuitBreaker
@EnableDiscoveryClient
@SpringBootApplication
public class RibbonClient1Application {
    @Bean
    @LoadBalanced
    RestTemplate restTemplate() {
        return new RestTemplate();
    }
    public static void main(String[] args) {
        SpringApplication.run(RibbonClient1Application.class, args);
    }
}

这里实际上有一点需要说明的是，这个类上边的三个注解其实是可以用一个注解代替的，这个注解是@SpringCloudApplication，通过源码可以知道这个注解包含了上述三个注解，也意味着一个标准的springcloud应用是应该包括服务的注册发现以及断路器功能的。
那么除开主类加一个注解之外，原本的服务类也需要有一定的修改，首先是在原本调用的方法上加上@HystrixCommand(fallbackMethod = “helloError”)，意思是当调用的服务出现故障的时候回调helloError方法，或者说当调用服务出现故障的时候回滚一步，然后转而调用helloError方法。
不管怎样，既然要调用helloError方法，很显然需要存在这个方法，因此还需要加入一个helloError方法，当然了这个方法名是自定义的，里边的逻辑也是要根据具体的业务需要定义的，我这里就很简单的返回一个字符串，修改之后的代码如下：

@RestController
public class ConsumerController {
    @Autowired
    RestTemplate restTemplate;
    @RequestMapping(value="/hello",method=RequestMethod.GET)
    @HystrixCommand(fallbackMethod = "helloError")
    public String hello(){
        String string = restTemplate.getForEntity("http://HELLO-SERVICE/hello", String.class).getBody();
        System.out.println(string);
        return string;
    }
    public String helloError() {
        return "服务器出现故障";
    }
}

就这样，一个简单地断路器功能就实现了，为了证明确实有效，我在两个服务正常运行的情况下再次关闭其中一个，然后再在浏览器访问的时候就不会再出现之前的500提示，后台也同样不再有error的日志，证明成功的处理了的这种故障，浏览器访问结果如图：

当然了，我这里演示的时候，为了方便都是直接关掉了其中一台服务器，这相当于实际生产中的服务器突然宕机或者进程突然中断的情况，而实际上这种情况发生的几率还是比较少的。
由于在分布式高可用的系统中，一般不同的服务是部署在不同的服务器上，不同的服务器间就会涉及到网络通讯和数据传输，因此正常来说网络故障导致服务异常的情况会更多一些。
如果要演示这种情况，就可以在服务接收请求到返回数据之前加入线程休眠，从而模拟网络阻塞，只需要注意hystrix的默认超时时间是2000毫秒，也就是2秒就够了。

运行流程说明

流程图（来自网络）

流程说明

hystrix运行流程说明:

1. 每次调用创建一个新的HystrixCommand,把依赖调用封装在run()方法中.
2. 执行execute()/queue做同步或异步调用.
3. 判断熔断器(circuit-breaker)是否打开,如果打开跳到步骤8,进行降级策略,如果关闭进入步骤.
4. 判断线程池/队列/信号量是否跑满，如果跑满进入降级步骤8,否则继续后续步骤.
5. 调用HystrixCommand的run方法.运行依赖逻辑
   5a:依赖逻辑调用超时,进入步骤8.
6. 判断逻辑是否调用成功
   6a:返回成功调用结果
   6b:调用出错，进入步骤8.
7. 计算熔断器状态,所有的运行状态(成功, 失败, 拒绝,超时)上报给熔断器，用于统计从而判断熔断器状态.
8. getFallback()降级逻辑.
   8a:没有实现getFallback的Command将直接抛出异常
   8b:fallback降级逻辑调用成功直接返回
   8c:降级逻辑调用失败抛出异常
9. 返回执行成功结果

fallback触发场景

综合上边的流程可知，四种情况将触发getFallback调用：
(1):熔断器开启拦截调用
(2):线程池/队列/信号量是否跑满
(3):run()方法调用超时
(4):run()方法抛出非HystrixBadRequestException异常

如何判断熔断器是否打开：

(1):熔断器打开标示，为true为打开，否则查询度量指标（10s的时间窗）
(2):请求阀值是否超标，默认是20个请求，超标则为true
(3):请求错误百分比是否超标，默认是50，超标则为true
当2和3都超标时，熔断器标示会设为true，打开状态。

依赖隔离

默认是线程池隔离，可以改成信号量。
信号量开销比线程池小很多，但不支持异步访问和设置超时。