springcloud微服务

一：spring boot基础项目搭建及问题处理

spring boot的理念是“习惯优于配置”，我个人的理解就是尽量减少开发过程中手动的spring相关的配置文件。同时使用spring boot还有一个优点就是，它可以内嵌很多容器，例如tomcat，使得原本可能需要安装tomcat才能运行的web项目，可以直接以运行jar文件的形式启动运行。

spring boot项目创建有多种方式，鉴于目前工作中使用的是eclipse开发工具，因此整个学习过程中，也都是在eclipse中进行。

而eclipse中的创建实际上也是可以有两种方式的，一种是在安装了STS插件之后直接创建，另一种是创建简单的maven项目后，修改pom.xml文件，为了提高效率，我这里就安装了STS插件，以第一种方式创建。

这个过程中还有一个小插曲，我原本的eclipse版本是Mars.1 Release (4.5.1)，安装STS的时候安装不成功，说是eclipse版本不匹配，于是安装了新版的eclipse，版本号Neon.3 Release (4.6.3)。但是当我在新版的eclipse中安装好STS后，再来尝试在旧版安装时，居然又一路畅通无阻的成功了。

eclipse中STS安装也有几种方式，我的STS的安装过程是这样的： help –> Eclipse Marketplace –>Popular，然后选择下图中的插件install。 

这个插件安装成功以后，就可以看到在eclipse中new project时会有spring这个选项了（当然了，不知这一个地方有变化），打开之后还会有几个子选项，如图： 

而我快速创建spring boot项目的时候，使用的就是上图中第三个子选项Spring Starter Project。具体步骤是：new –>Project –>Spring Starter Project –>出现的界面中name选项后输入项目名称 –>接下来出现如下图所示界面： 
 
这里我主要是使用了两个地方，第一个就是选择spring boot version，第二个就是在标示2的位置选择要创建的具体spring boot项目，有很多选项可供选择，而我就选了一个web项目。

创建好的web项目基本结构如下图： 
 
创建的时候它会自动生成一个带有main方法的类，这个main方法实际上就是spring boot项目的程序入口，我在里边加入了一个@RestController和这样一段代码：

@RequestMapping("/")
String index(){
    return "Hello Spring Boot";
}
 
 
1
2
3
4
 
 
1
2
3
4

之后整个类的代码如下：

package com.springTest.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@SpringBootApplication
public class SpringBootDemo1Application {

    @RequestMapping("/")
    String index(){
        return "Hello Spring Boot";
    }

    public static void main(String[] args) {
        SpringApplication.run(SpringBootDemo1Application.class, args);
    }
}
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

当安装好STS插件之后，创建一个简单的spring boot的web项目就是这么简单，不需要像传统的spring项目一样还要配置spring.xml等配置文件以及web.xml文件。

但是需要注意的是，我在第一次创建的时候，spring boot相关的jar包下载不下来，因为公司的maven仓库中没有对应版本的，于是自己修改了maven的配置文件，加入了阿里云的maven仓库：

<mirror>  
      <id>alimaven</id>  
      <name>aliyun maven</name>  
 <url>http://maven.aliyun.com/nexus/content/groups/public/</url>  
      <mirrorOf>central</mirrorOf>          
</mirror>  
 
 
1
2
3
4
5
6
 
 
1
2
3
4
5
6

当重新配置maven仓库，使得程序编译没有问题后，就可以启动项目了，eclipse中使用run as –>Spring Boot App就可以直接运行，不需要像传统web项目那样要加入到tomcat中才行。

启动成功后浏览器访问localhost:8080，会看到页面如下，一个简单的spring boot web项目就成功创建了。 

二：Eureka服务治理之服务注册中心

当初步的学习了spring boot，了解了spring boot的基本实现过程后，我就正式开始学习spring cloud，首先就从Eureka服务治理开始。

服务治理包含三个核心的角色：服务注册中心、服务提供者和服务消费者，他们相对独立，新的服务要向服务注册中心注册，新的消费者会向服务注册中心索引服务列表。

一番了解之后，让我想到了人才招聘。在我看来，现在普遍存在的招聘形式也是分为了三个部分：招聘网站或者人才市场、发布招聘需求的企业、需要找工作的人。当然了，也可以把企业和人换一下位置，那就是：招聘网站或者人才市场、找工作的人发布的简历、需要招聘的企业。

那么这里的招聘网站或者人才市场就如同Eureka服务治理中的服务注册中心，不管是企业的招聘需求还是人的简历，都可以看做一种需求的同时看成一种服务。当有了一个这种新的服务或者需求后会发布在网站上或者人才市场，实际上就相当于Eureka服务治理中，新的服务通知注册到服务注册中心。而我们企业查找相关简历，或者找工作的人查找相关的招聘需求，就是客户端向注册中心索引服务。

在这个过程中，招聘网站、企业和找工作的人是各自独立的，由招聘网站把企业和人联系起来，前提就是企业和人知道网站的地址，这就如同在Eureka服务治理的服务提供者和服务消费者的application.properties文件中配置eureka.client.serviceUrl.defaultZone来指定服务注册中心。

有了一点简单的理解之后，就是实际的项目构建，首先需要构建一个基础的spring boot项目作为服务注册中心，勾选web选项，这样会创建一个上一篇结构的项目。然后在pom.xml文件中加入Eureka的以来配置：

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-eureka-server</artifactId>
</dependency>
 
 
1
2
3
4
 
 
1
2
3
4

以及如下的dependencyManagement，指定spring cloud的版本：

<dependencyManagement>
        <dependencies>
            <dependency>
               <groupId>org.springframework.cloud</groupId>
               <artifactId>spring-cloud-dependencies</artifactId>
               <version>Brixton.RELEASE</version>
               <type>pom</type>
               <scope>import</scope>
            </dependency>
        </dependencies>
</dependencyManagement>
 
 
1
2
3
4
5
6
7
8
9
10
11
 
 
1
2
3
4
5
6
7
8
9
10
11

这里需要注意的是，spring cloud的版本号是以英国伦敦地铁站的名字命名的，按首字母A-Z的顺序排，不同的spring cloud版本相对应的spring boot的版本是有限制的，否则无法使用。 
具体的对应需要参考官网说明，目前比较新的spring boot版本是1.5.2，而对应的spring cloud的版本是Dalston，我这里例子中用的是1.3.8的spring boot，因此spring cloud版本是Brixton。

配置好依赖之后，下一步就是在创建项目时自动生成的那个类中加入@EnableEurekaServer注解，来启动一个服务注册中心，如下：

@EnableEurekaServer
@SpringBootApplication
public class EurekaServer1Application {

    public static void main(String[] args) {
        SpringApplication.run(EurekaServer1Application.class, args);
    }
}
 
 
1
2
3
4
5
6
7
8
 
 
1
2
3
4
5
6
7
8

然后便是在基本的配置文件application.properties中进行一些必要的配置：

#应用名，服务名，如果不指定就是unkown
spring.application.name=eureka-server
#服务端口，实际上就是tomcat端口，浏览器访问或者其他地方调用时需要用的端口
server.port=1000
#实例的主机名
eureka.instance.hostname=server1
#设置是否向注册中心注册，默认是true
eureka.client.register-with-eureka=false
#是否需要去检索寻找服务，默认是true
eureka.client.fetch-registry=false
#指定注册中心
eureka.client.serviceUrl.defaultZone=http://server1:1000/eureka/
 
 
1
2
3
4
5
6
7
8
9
10
11
12
 
 
1
2
3
4
5
6
7
8
9
10
11
12

就这样，一个简单的Eureka服务注册中心就完成了，除了引入依赖包的配置、properties的基本配置外，就是在代码中加了一个@EnableEurekaServer，非常的简单。 
然后浏览其访问localhost:1000或者server1:1000（这里使用主机名需要配置ip和主机的映射）就可以看到如下界面： 

如果有新的服务注册到服务注册中心，那么在上图中红框标注的地方就会有所显示，就比如如果我修改application.properties文件，去掉这一段配置：

#设置是否向注册中心注册，默认是true
eureka.client.register-with-eureka=false
#是否需要去检索寻找服务，默认是true
eureka.client.fetch-registry=false
 
 
1
2
3
4
 
 
1
2
3
4

那么该服务注册中心就会把自己也当做一个服务注册到这个注册中心中，那么就会如下图所示： 

上边所实现的是单机版的服务注册中心，而微服务架构的九大特征之一就是高可用性，也就是需要注册中心从单机模式变为集群模式，使其中某个注册中心出现故障的情况下不影响整个业务系统的运行。 
在spring cloud中，这个实现过程就十分的简单，简单到我们只需要在上述的过程中仅仅做一个很小的配置修改就可以了。 
一是去掉eureka.client.register-with-eureka=false和eureka.client.fetch-registry=false的配置，使得注册中心可以自己把自己注册为服务，二是在指定注册中心的时候指定所有的注册中心，三是修改端口和主机实例名，修改后的配置如下：

spring.application.name=eureka-server
server.port=1000
eureka.instance.hostname=server1
eureka.client.serviceUrl.defaultZone=http://server1:1000/eureka/,http://server2:2000/eureka/
 
 
1
2
3
4
 
 
1
2
3
4

同样的，我们需要在另一个注册中心中把配置文件改为类似下边的样子：

spring.application.name=eureka-server
server.port=2000
eureka.instance.hostname=server2
eureka.client.serviceUrl.defaultZone=http://server1:1000/eureka/,http://server2:2000/eureka/
 
 
1
2
3
4
 
 
1
2
3
4

然后我们启动其中一个注册中心后再访问各自的页面，会看到如下所示： 

这时候会看到我们的服务注册中心已经成为了集群模式，但是server2是unavailable的，并不可用，而当我们把另一个注册中心server2启动后，就会看到有些内容有了变化，server2也是可用的了，同样的，如果访问server2的页面，会看到这里列出server1的状态。 

正常情况来说，两个注册中心是应该在不同的服务器中运行的，这样才能更好的实现高可用，所以就是两套代码。 
但是在学习的过程中由于环境的限制，也为了方便，实际上就可以用一套代码，然后弄两个分别代表server1和server2的配置文件就可以了，文件命名需要遵循spring boot的约定规则，然后再application.properties文件中使用spring.profiles.active属性来指定运行的时候需要具体启用的篇配置就可以了，如图： 

三：Eureka服务治理之注册服务提供者及服务的发现和消费

当服务注册中心成功建立以后，就需要有服务的注册和消费，否则这个服务注册中心就没有了存在的意义，而实际上，一个简单的服务注册也是非常简单的，仅仅需要实现四部曲就好。

首先，还是建立一个基本的spring boot的项目，创建的时候选择web，然后在pom.xml文件中加入Eureka的依赖，和服务注册中心的maven配置一样，这里就不再罗列代码。

第二步，就是修改application.properties文件，指定端口和服务名称以及注册中心的地址：

server.port=1001
spring.application.name=hello-service
eureka.client.serviceUrl.defaultZone=http://server1:1000/eureka/,http://server2:2000/eureka/
 
 
1
2
3
 
 
1
2
3

因为上一步中实现了注册中心的集群模式，因此这里可以指定两个，如果有更多的服务注册中心，还可以指定更多，中间以逗号分隔。

第三步，使用注解开启自动装配，使服务能够向注册中心注册、向注册中心服务租约（实际上就是定时器持续发送心跳告诉服务注册中心自己还活着）、取消租约、查询服务列表等，这个注解是@EnableDiscoveryClient，添加以后的代码如下：

@EnableDiscoveryClient
@SpringBootApplication
public class EurekaService1Application {

    public static void main(String[] args) {
        SpringApplication.run(EurekaService1Application.class, args);
    }
}
 
 
1
2
3
4
5
6
7
8
 
 
1
2
3
4
5
6
7
8

第四步，我们说要进行服务注册，当上边一切准备工作做好以后，自然需要有服务才能注册，而这个服务就是一个看起来很普通的controller类，如图：

@RestController
public class HelloController {

    @Autowired
    private DiscoveryClient client;

    @RequestMapping(value="/hello",method=RequestMethod.GET)
    public String sayHello(){
        ServiceInstance instance=client.getLocalServiceInstance();
        return "hello "+instance.getHost()+","+instance.getPort()+","+instance.getServiceId();
    }
}
 
 
1
2
3
4
5
6
7
8
9
10
11
12
 
 
1
2
3
4
5
6
7
8
9
10
11
12

这里的DiscoveryClient可以获取注册到服务注册中心的服务的相关信息，并不是必须注入的，这里完全可以写成如下所示的代码：

@RestController
public class HelloController {

    @RequestMapping(value="/hello",method=RequestMethod.GET)
    public String sayHello(){
        return "hello";
    }
}
 
 
1
2
3
4
5
6
7
8
 
 
1
2
3
4
5
6
7
8

当然了，因为只是了解服务注册的过程，所以这里仅仅这么简单，实际的业务逻辑自然不会是这样。

那么通过上边四步，一个能够注册到服务注册中心提供服务的服务就完成了，启动这个服务就会被注册到服务注册中心，我们可以通过服务注册中心的页面来查看： 

成功的创建了一个服务并注册到注册中心，同样的，为了高可用，我们可以再建一个具有同样功能的服务，而这个过程就更加的简单，只需要更改一下端口号，也就是server.port，然后重新启动就可以，启动后会看到上边的页面如下（当然了，这里也是为了测试方便，实际情况也应该是在两台机器上运行的两套代码才对）： 

这里我们会看到已经有了两个同应用名的服务，端口分别是1001和2001。 
而在上述页面中还需要注意的是那一段醒目的红色提示，它的意思就是说开启了自我保护机制，也就是说当服务失效后，有可能注册中心还会保留一段时间该服务的信息，这样就可能导致服务消费方获取服务列表的时候依然能够获取到这个服务，但是实际上向该服务发送请求的时候又无法成功请求，那么学习的过程中可以使用以下配置关闭自我保护机制，然后如果再访问注册中心的页面便不会再出现这个提示，也不会出现那种服务失效后还保留在注册中心的情况。

#设置是否开启自我保护机制，默认是true
eureka.server.enable-self-preservation=false
 
 
1
2
 
 
1
2

服务注册好以后，下边就是服务的发现和消费，通常有ribbon和feign两种方式，而feign实际上也是以ribbon为基础的，这两种后边都还需要具体详细的学习，所以这里只简单的演示一下消费的过程，不做太详细的解释。ribbon可以实现负载均衡，这里使用最简单的模板实现。 
首先还是建立一个基础spring boot项目，然后pom.xml中加入eureka和ribbon的依赖以及eureka的版本信息：

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

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

<dependencyManagement>
        <dependencies>
            <dependency>
               <groupId>org.springframework.cloud</groupId>
               <artifactId>spring-cloud-dependencies</artifactId>
               <version>Brixton.RELEASE</version>
               <type>pom</type>
               <scope>import</scope>
            </dependency>
        </dependencies>
</dependencyManagement>
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

然后application.properties文件内容如下：

server.port=3001
spring.application.name=rabbit-client
eureka.client.serviceUrl.defaultZone=http://server1:1000/eureka/,http://server2:2000/eureka/
 
 
1
2
3
 
 
1
2
3

再然后就是创建项目时生成的类中加入@EnableDiscoveryClient参数开启自动装配，以及注入服务消费模板并开启负载均衡：

@Bean
@LoadBalanced
RestTemplate restTemplate(){
    return new RestTemplate();
}
 
 
1
2
3
4
5
 
 
1
2
3
4
5

之后的这个步骤实际不是必要的，只是为了能够更直观的在页面中看到结果，所以加入一个controller类，输出服务的一些基本信息：

@RestController
public class ConsumerController {

    @Autowired
    RestTemplate restTemplate;

    @RequestMapping(value="/hello",method=RequestMethod.GET)
    public String hello(){
        return restTemplate.getForEntity("http://HELLO-SERVICE/hello", String.class).getBody();

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

那么当我们启动这个消费端以后，页面访问localhost:3001/hello就可以看到如下页面： 

四：服务容错保护Hystrix断路器

通过前边的学习，服务注册中心、服务提供者和服务消费者都成功建立并运行起来，而且通过默认的配置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
 
 
1
2
3
4
5
 
 
1
2
3
4
5

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

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]
 
 
1
2
3
4
5
6
7
8
9
 
 
1
2
3
4
5
6
7
8
9

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

<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-hystrix</artifactId>
</dependency>
 
 
1
2
3
4
 
 
1
2
3
4

同时在服务消费端的主类加上@@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);
    }
}
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

这里实际上有一点需要说明的是，这个类上边的三个注解其实是可以用一个注解代替的，这个注解是@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 "服务器出现故障";
    }
}
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

就这样，一个简单地断路器功能就实现了，为了证明确实有效，我在两个服务正常运行的情况下再次关闭其中一个，然后再在浏览器访问的时候就不会再出现之前的500提示，后台也同样不再有error的日志，证明成功的处理了的这种故障，浏览器访问结果如图： 
 
当然了，我这里演示的时候，为了方便都是直接关掉了其中一台服务器，这相当于实际生产中的服务器突然宕机或者进程突然中断的情况，而实际上这种情况发生的几率还是比较少的。 
由于在分布式高可用的系统中，一般不同的服务是部署在不同的服务器上，不同的服务器间就会涉及到网络通讯和数据传输，因此正常来说网络故障导致服务异常的情况会更多一些。 
如果要演示这种情况，就可以在服务接收请求到返回数据之前加入线程休眠，从而模拟网络阻塞，只需要注意hystrix的默认超时时间是2000毫秒，也就是2秒就够了。