JAVA前往高级开发架构方向随笔（第一天）

一、什么是spring cloud？

微服务架构集大成者，云计算最佳业务实践。
百度百科这样说的：

Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，
如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。
Spring Cloud并没有重复制造轮子，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，
通过Spring Boot风格进行再封装屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。

二、使用Eureka 进行服务治理

服务治理可以说是微服务架构中最为核心和基础的模块，它主要用来实现各个微服务实例的自动化注册和发现。

Spring Cloud Eureka是Spring Cloud Netflix 微服务套件的一部分，主要负责完成微服务架构中的服务治理功能。

• 搭建服务注册中心

<!-- 引入eureka server依赖 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka-server</artifactId>
        </dependency>

/**
 * 
 * @EnableEurekaServer
 * 用来指定该项目为Eureka的服务注册中心
 */

#设置tomcat服务端口号
server.port=1111
#设置服务名称
spring.application.name=eureka-service

eureka.instance.hostname=localhost
#注册中心不需要注册自己
eureka.client.register-with-eureka=false
#注册中心不需要去发现服务
eureka.client.fetch-registry=false
#设置服务注册中心的URL
eureka.client.serviceUrl.defaultZone=http://${eureka.instance.hostname}:${server.port}/eureka
 

• 注册服务提供者

 <!-- 引入eureka 客户端依赖 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>

 * @EnableDiscoveryClient
 * 让服务使用eureka服务器
 * 实现服务注册和发现

server.port=9090
#设置服务名
spring.application.name=hello-service
#设置服务注册中心的URL，本服务要向该服务注册中心注册自己
eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka
 

• 服务发现和消费

 <!-- 引入eureka 客户端依赖 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <!-- 引入ribbon 依赖 ，用来实现负载均衡，我们这里只是使用，先不作其他介绍-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-ribbon</artifactId>
        </dependency>

@EnableDiscoveryClient
@SpringBootApplication
public class ConsumerApp {

    //@Bean 应用在方法上，用来将方法返回值设为为bean
    @Bean
    @LoadBalanced  //@LoadBalanced实现负载均衡
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
    
    public static void main(String[] args) {
        SpringApplication.run(ConsumerApp.class, args);
    }
}

这里也要用到@EnableDiscoveryClient， 让服务使用eureka服务器， 实现服务注册和发现

以上实例实现了基本的服务治理：

通过spring-cloud-starter-eureka-server和@EnableEurekaServer实现服务注册中心
通过spring-cloud-starter-eureka和@EnableDiscoveryClient使用并注册到服务注册中心
通过spring-cloud-starter-eureka和@EnableDiscoveryClient使用注册中心并发现服务，通过spring-cloud-starter-ribbon来实现负载均衡消费服务
 

三、使用Eureka 搭建高可用服务注册中心

搭建的服务注册中心是单体的，

但是在实际的应用中，分布式系统为了防止单体服务宕机带来严重后果，一般都会采用服务器集群的形式，服务注册中心也是一样，需要多台服务一起工作，组成高可用的服务注册中心。这样，如果有其中一台宕机，系统也能正常运行。

那么如何来构建高可用的服务注册中心呢？

由于eureka注册中心既可以作为服务端（服务注册中心），也可以作为客户端（到别的注册中心注册自己），

我们可以通过在机器上部署peer1和peer2两个服务，两个服务相互注册

如果在application-{profiles}.properties中再配置一遍就又可以覆盖application.properties里面的配置。

代码读取顺序是这样的：

先读取默认配置-->然后读取application.properties-->读取application-{profiles}.properties。

四、使用Hystrix 实现断路器进行服务容错保护

在微服务中，我们将系统拆分为很多个服务单元，各单元之间通过服务注册和订阅消费的方式进行相互依赖。但是如果有一些服务出现问题了会怎么样？

比如说有三个服务（ABC），A调用B，B调用C。由于网络延迟或C本身代码有问题导致B迟迟得不到回应，这样B调用C的请求就会被挂起，等待。

在高并发的访问的情况下，这些挂起的线程得不到释放，使后续的请求阻塞，最终导致B也挂掉了。依次类推，A可能也会挂掉，进而使整个系统全部崩溃。

为了解决整个问题，Spring Cloud 使用Hystrix进行服务容错保护，包括断路器、线程隔离等一系列的保护功能，今天我们就来看下如何通过Hystrix实现断路器。

一、什么是Spring Cloud Hystrix？什么是断路器？

Spring Cloud Hystrix是基于Netflix的开源框架Hystrix实现的，其目的是为了通过控制那些访问远程系统、服务和第三方的节点，从而对延迟和故障提供强大的容错能力。

断路器类似于我们家里面强电箱里面用到的漏电断路保护器，当服务单元出现故障（类似于电器发生短路），通过断路器的故障监控功能（类似于保险丝），向调用方返回一个错误响应，避免长时间等待，从而避免故障蔓延到整个系统。
 

五：使用Feign 实现声明式服务调用

通过前面的随笔，我们了解如何通过Spring Cloud ribbon进行负责均衡，如何通过Spring Cloud Hystrix进行服务断路保护，
两者作为基础工具类框架应用在各种基础设施类微服务和业务类微服务中，并且成对存在，那么有没有更高层的封装，将两者的使用
进一步简化呢？ 有！ 他就是Spring Cloud Feign。它基于Netflix Feign实现，整合了Spring Cloud Ribbon和Spring Cloud Hystrix，
除了提供两者强大的功能外，还提供了一种声明式的Web服务客户端定义方式
 <!-- 引入eureka 客户端依赖 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-eureka</artifactId>
        </dependency>
        <!-- 引入feign 依赖 -->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-feign</artifactId>
        </dependency>

 通过@EnableFeignClients来开启spring cloud feign的支持功能

/**
 * 通过@FeignClient注解指定服务名来绑定服务，这里的服务名字不区分大小写
 * 然后再通过@RequestMapping来绑定服务下的rest接口
 *
 */
@FeignClient(name="hello-service")
public interface FeignConsumerService{

    @RequestMapping("/hello")
    public void hello();
}

六、使用Zuul 实现API网关服务

 <!-- 引入zuul依赖 , 它依赖了spring-boot-starter-actuator/spring-boot-starter-hystrix/spring-boot-starter-ribbon-->
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-zuul</artifactId>
        </dependency>

#增加路由规则的配置
#通过zuul.routes.<route>.path和zuul.routes.<route>.url进行配置，<route>为路由的名字，可以任意指定，但是一组path和url的路由名要相同
#如下面的例子：所有满足/api-a/** 规则的访问都会被路由转发到//localhost:9001的地址
#也就是说，我们访问http://localhost:5555/api-a/hello的时候，API网关服务就会将该请#求路由到 http://localhost:9001/hello提供的微服务接口上
zuul.routes.api-a.path=/api-a/**
zuul.routes.api-a.url=http://localhost:9001

zuul.routes.api-b.path=/api-b/**
zuul.routes.api-b.url=http://localhost:9090
以上步骤实现了传统路由的配置，这种配置有个大的缺点，就是需要手工在application.properties文件中进行路由规则的配置，当服务很多的时候，维护工作量就会很大。为了减小维护成本，还有另外一种路由--面向服务的路由。

七、基于Git存储的分布式配置中心--Spring Cloud Config

我们前面接触到的spring cloud组件都是基于Netflix的组件进行实现的，这次我们来看下spring cloud 团队自己创建的一个全新项目：Spring Cloud Config.
它用来为分布式系统中的基础设施和微服务提供集中化的外部配置支持，分为服务端和客户端两个部分。

其中服务端也称为分布式配置中心，他是独立的微服务应用，用来连接配置仓库并为客户端提供获取接口(这些接口返回配置信息、加密、解密信息等)；

客户端是微服务架构中的各个微服务应用或基础设施，它们通过制定的配置中心来管理应用资源与业务相关的配置内容，并在启动的时候从配置中心获取和加载配置信息。
由于配置中心默认采用Git来存储配置信息，因此我们会用到Git相关的内容
 

* @EnableConfigServer
 * 
 * 开启Spring Cloud Config 的服务端功能

server.port=7001
spring.application.name=config-server

#配置Git仓库的地址
spring.cloud.config.server.git.uri=https://gitee.com/sam-uncle/spring-cloud-learning/
#配置仓库路径下的相对搜索位置，可以配置多个
spring.cloud.config.server.git.search-paths=spring-cloud-config-file
#这里配置你的Git仓库的用户名
spring.cloud.config.server.git.username=用户名
#这里配置你的Git仓库的密码
spring.cloud.config.server.git.password=密码

配置bootstrap.properties文件，指定config-server位置

server.port=7002
#{application}
spring.application.name=sam
#{profile}
spring.cloud.config.profile=dev
#{label}
spring.cloud.config.label=master

#config server uri
spring.cloud.config.uri=http://localhost:7001/

Spring Cloud Config配置中心的工作原理如下：

客户端启动时，根据bootstrap.properties中配置的应用名{application}、环境名{profile}、分支名{label}，向Config Server请求获取配置信息。
Config Server根据自己维护的Git仓库信息和客户传递过来的配置定位信息去查找配置信息。
通过git clone命令将找到的配置信息下载到本地（Config Server的文件系统中）。在通过页面访问或启动客户端的时候，我们在服务端能看到如下下载的log：
2018-05-14 22:51:58.055  INFO 3084 --- [nio-7001-exec-1] o.s.c.c.s.e.NativeEnvironmentRepository  : Adding property source: file:/C:/Users/sam/AppData/Local/Temp/config-repo-8627749771720918793/spring-cloud-config-file/sam-dev.properties
2018-05-14 22:51:58.055  INFO 3084 --- [nio-7001-exec-1] o.s.c.c.s.e.NativeEnvironmentRepository  : Adding property source: file:/C:/Users/sam/AppData/Local/Temp/config-repo-8627749771720918793/spring-cloud-config-file/sam.properties
Config Server创建Spring 的ApplicationContext实例，并从Git本地仓库中加载配置文件，最后将这些配置内容读取出来返回给客户端。
客户端在获取外部配置信息后加载到客户端的applicationContext实例。

八、使用spring cloud sleuth整合zipkin进行服务链路追踪

微服务架构是一种分布式架构，微服务系统按照业务划分服务单元，一个微服务往往会有很多个服务单元，一个请求往往会有很多个单元参与，一旦请求出现异常，想要去定位问题点真心不容易，因此需要有个东西去跟踪请求链路，记录一个请求都调用了哪些服务单元，调用顺序是怎么样的以及在各个服务单元处理的时间长短。常见的服务链路追踪组件有google的dapper、twitter的zipkin、阿里的鹰眼等，它们都是出众的开源链路追踪组件。

spring cloud 有自己的组件来集成这些开源组件，它就是spring cloud sleuth，它为服务链路追踪提供了一套完整的解决方案。

今天的主题就是如何使用spring cloud sleuth整合zipkin进行服务链路追踪。本博客将围绕下面的线索进行展开：

Server端代码实现
Client端代码实现
执行测试
 由上面的线索可以发现，zipkin分服务端和客户端。

客户端就是我们的服务单元，用来发送链路信息到服务端；

服务端用来接收客户端发送来的链路信息，并进行处理，它包括4个部分：

Collector组件：用来接收客户端发送的链路信息然后整理成zipkin能处理的格式，供后续存储或向外部提供查询使用。
Storage组件：对链路信息进行保存，默认存储在内存，通过配置还可以保存到mysql等地方。
Restful API组件：对其他服务单元提供api接口进行查询链路信息。
Web UI组件：调用API 组件的接口并将信息显示到web 画面。
 

 

七、Dubbo+zokeeper基础讲解

一、dubbo是什么？

1）本质：一个Jar包,一个分布式框架,，一个远程服务调用的分布式框架。

既然是新手教学，肯定很多同学不明白什么是分布式和远程服务调用，为什么要分布式，为什么要远程调用。我简单画个对比图说明（图1看到图2。画板画的，勿喷）。

你想一下，以前什么的都在一个服务器上，调用方法直接就自然而然调用了，没啥问题。现在因为需求增多拆分了这么多个，部署在不同的服务器上，那是不是相对以前都在一个服务器上，现在分布式后，web层调用service层的服务变成了远程调用？那怎样像以前那样都在一个服务器上自然而然调用方法呢？dubbo来解决。这就是下面dubbo的好处。

二、Dubbo的好处？

1.透明化的远程方法调用，就像调用本地方法一样调用远程方法，只需简单配置，没有任何API侵入。

2.软负载均衡及容错机制，可在内网替代F5等硬件负载均衡器，降低成本，减少单点。

3. 服务自动注册与发现，不再需要写死服务提供方地址，注册中心基于接口名查询服务提供者的IP地址，并且能够平滑添加或删除服务提供者。（下面讲解）

Dubbo采用全Spring配置方式，透明化接入应用，对应用没有任何API侵入，只需用Spring加载Dubbo的配置即可，Dubbo基于Spring的Schema扩展进行加载。

 

三、dubbo架构图如下所示：

讲解他的架构图之前，我们先普及下几个概念。

节点角色说明：

Provider（生产者）: 暴露服务的服务提供方。

Consumer（消费者）: 调用远程服务的服务消费方。

如图，我们可以简单理解为web1234需要调用service1234的服务，所以web1234是消费者，service1234是生产者。

那如果按照上面，消费者调用生产者的服务，那是不是如下图：

你看着晕不晕？晕不晕？晕不晕？反正我是晕了，万一分布式得更多呢？，所以我们需要他：

Registry（注册中心）: 服务注册与发现的注册中心。dubbo推荐的是zookeeper。什么是zookeeper？zookeeper是用于分布式中一致性处理的框架。更多的可以查看我之前的文章：这么说吧,zookeeper 很简单，其实就是个框架，是一致性处理用的。简单的讲，zookeeper就是个中介，卖楼的（生产者）把楼盘信息放在中介（注册中心）那里，想买楼的（消费者）去中介那里获得楼盘资源清单。于是，我们的图变成了这样：

是不是好很多了？还不够， 我们还需要个监控中心（干嘛用的？当然是监控用的，调用失败怎么办？挂了怎么办？）： Monitor: 统计服务的调用次调和调用时间的监控中心。（不画图了）

然后，Provider放在容器里运行，就叫做Container服务运行容器。（不画图了）

最终dubbo架构，如图（从0开始看起）：

自己脑海里按照上图走了一遍后，看看自己想的是不是和下面说明一样。

0 服务容器负责启动，加载，运行服务提供者。

1. 服务提供者（生产者）在启动时，向注册中心注册自己提供的服务。

2. 服务消费者在启动时，向注册中心订阅自己所需的服务。

3. 注册中心返回服务提供者地址列表给消费者，如果有变更，注册中心将基于长连接推送变更数据给消费者。

4. 服务消费者，从提供者地址列表中，基于软负载均衡算法，选一台提供者进行调用，如果调用失败，再选另一台调用。

5. 服务消费者和提供者，在内存中累计调用次数和调用时间，定时每分钟发送一次统计数据到监控中心