# microservice-parent

**Repository Path**: weixin.com/microservice-parent

## Basic Information

- **Project Name**: microservice-parent
- **Description**: 练习小项目
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 1
- **Forks**: 0
- **Created**: 2018-03-12
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README


# 项目版本1.5.2
# 遇到的坑
1. feignClien中不能直接使用@GetMapping,智能换一种写法
`@RequestMapping(value="",Method=RequestMethod.get)`
2. swagger和feign一起一起引用，那么swagger如果是2.x，那么最好升级到2.5之后，否则
报错。(null指针错误)
3. 最好不要在配置文件中添加**context-path**属性


# 项目启动及其请求路径
1. 因为boot项目部分先后启动 ，所以可以随意启动
2. 请求时候最好先请求zuul代理的路径


# microservice-parent
父项目

# microservice-user
1. 用户服务，该项目**结合了swagger**， 启动之后可以访问接口页面
请求地址：http://localhost:8080/{modelName}/swagger-ui.htm
modelName:application.yml 中context-path的值
2. **结合feign插件** ，调用role项目使用的是feign
3. 微服务做为一个config-client，从config服务中读取配置。config微服务读取
   远程git仓库的配置

# microservice-role
1. 结合**swagger**


# microservice-zuul
1. 路由层，第一步先请求这个项目路径，拦截请求到不同的项目中
2. 项目使用了**hystrix** 熔断器，为所有的请求添加了熔断器，防止雪崩效应
3. 可以实现接口权限校验与微服务的业务解耦
4. 系统统一入口，屏蔽得了各个微服务之间的细节
5. 匹配规则，现在有两个微服务，一个是userService，请求路径是/user-service/ **,
 一个是userServiceExt，请求路径/user-service-ext/user-service/ext/ **,
userServiceExt是从userService中分离出来的，那么就有问题了， 请求userServiceExt
的路径和userService是一样的了。  Zuul是线性路由，谁第一个配置就访问谁。
```
zuul:
  routes:
    user-ext:
      path: /user/ext/**
      serviceId: MICROSERVICE-USER-EXT

zuul:
  routes:
    user:
      path: /user/**
      serviceId: MICROSERVICE-USER
```
6. 尽量使用path 和serviceId组合进行配置，如果使用path和url配置路由规则时候，请求就有没有线程隔离和断路器的保护，
也不会有负载均衡的能力。

# microservice-eureka 和 microservice-eureka-ha 高可用
这是两个是高可用的eureka服务器，互相注册，启动两个的同时得在C盘的system2中hosts修改添加如此下配置
1. 127.0.0.1 peer1
2. 127.0.0.1 peer2


# hystrix 缓存注解介绍
1. **@HystrixCommond(fackbackMethod="")** 指定服务降级方法
2. **@CacheResult**,该注解用来标记请求返回的结果被缓存，必须与@HystrixCommand一起使用，例子
```
@CacheResult
@HystrixCommand
public User getUserById(int id){
    return restTemplate.getForObject(URL,User.class,1);
}
```
定义缓存key，使用cacheKeyMethod属性
```
@CacheResult(cacheKeyMethod="getUserCachekey")
@HystrixCommand
public User getUserById(int id){
    return restTemplate.getForObject(URL,User.class,1);
}

public int getUserCachekey(int id){
    return id
}
``` 
3. **@CacheKey**，用来标记方法的参数，也是缓存key，**优先级比cacheMethod低**，如果同时使用，那么
@CacheKey不起作用
```
@CacheResult
@HystrixCommand
public User getUserById(@CacheKey("id") int id){
    return restTemplate.getForObject(URL,User.class,1);
}
```

4. **@CacheRemove**, 在之前的例子中，我们使用了@CacheResult来缓存结果，但是有的时候是update操作时候，
那么之前的结果就是错误的。这个时候我们应该在更新的时候把之前的结果过清除掉。
```
@CacheResult
@HystrixCommand
public User getUserById(@CacheKey("id") int id){
    return restTemplate.getForObject(URL,User.class,1);
}

@CacheRemove(commandKey="getUserById")
@HystrixCommand
public User update(@CacheKey("id") User user){
    return restTemplate.postForObject(URL,user,User.class);
}
```


# microservice-config 配置服务
1. 这是可以获取远程配置的服务
2. 最好在远程git上创建的文件名称命名方式是 application-profile.yml
3. URL 与 文件映射关系 /{application}-{profile}.yml  
4. application 是你文件的 - 之前的名字 。
5. 项目启动时候会在本地生成一个备份，控制台可以看见
6. 结合 **bus** 消息总线 ，当git服务端进行配置修改的时候，给config-server以post方式
推送一个**/bus/refresh**， 这样bus就可以给所有服务推送最新的配置。如果要是局部
刷新，那么可以使用参数**destination**


# microservice-config-client 配置服务客户端
1. 客户端配置读取**microservice-config**
2. **microservice-config** 读取远程git配置
3. 结合 **bus** 消息总线 ，如果config在线更改配置，那么bus总线会给所有在线上的微服务推送
  配置
  ```
    /bus/refresh 必须是post请求
  ```
  
# microservice-stream 消息驱动
1. 输入通道和输出通道不能是重名


# microservice-sleuth-trace1 日志跟踪
1. 整合logstash
2. 根据配置，会在项目路径下创建一个build文件夹 ，根据
    spring.application.name创建不同的log

# zipkin 分布式链路日志收集
1. 可以查看这个请求spaceID, traceid 话费的时间
2. 可以分布式
3. 本系统默认是http请求，可以改进的方式的是socket
4. 配置如下，其中 percentage 这个参数是必须，因为是采样比例。默认是0.1 
```
spring:
  zipkin:
    base-url: http://localhost:9411
    enabled: true
  sleuth:
    sampler:
      percentage: 1.0 #默认配置是0.1 ， 指数是采样的比例,最大1，全要日志
```

# microservice-zipkin-server-stream
1. 项目是集成rabbitmq作为中间件
2. 在rabbitmq的web管理页面，我们可以看到sleuth的交换器
3. 日志先是推送到rabbitmq，然后再推送到zipkin服务上

# zipkin核心概念
## Span
代表一个基本的工作单元
## trace 
一系列具有相同traceId的span组成树状结构，在复杂的分布式系统中 ，一个
外部请求会产生一个复杂的树状结构
## annotaion
记录一个事件的存在，也可以理解为一个包含时间戳的事件标签，一个http
请求来说，在sleuth中定义了4个核心的标识
1. cs：client send ，客户端发起一个请求
2. sr：server received， 服务端接受到请求，通过sr与cs可以计算网络延迟
3. ss：server send，服务端处理请求完毕之后准备发送响应信息。通过ss与sr可以计算
服务处理时间
4. cr：client received，客户端接收到响应信息
## binaryAnnotaion
用来对跟踪信息添加一些额外的补充说明，一般以键值出现。比如，http请求之后执行业务逻辑处理，此时没有annotation标识
但是有binaryAnnotation进行补充说明