# springcloud_demo

**Repository Path**: lifewang/springcloud_demo

## Basic Information

- **Project Name**: springcloud_demo
- **Description**: SpringCloud
- **Primary Language**: Unknown
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2020-06-28
- **Last Updated**: 2020-12-19

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

#### SpringCloud
 **技术：** 
```
    spring Data Jpa、rpc、restFull、cap、eureka、ribbon、feign、Hystrix、sentinel、zuul、链路追踪 etc。。
```
 **优点：** 
```
    1.通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成本也将大幅度下降；
    2.微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。
```
 **缺点：** 
```
    1.微服务过多，服务治理成本高，不利于系统维护；
    2.分布式系统开发的技术成本高(容错、分布式事务等)。
```
| 功能  | SOA  | 微服务  |
|---|---|---|
| 组件大小 | 大块业务逻辑  | 单独任务或小块业务逻辑  |
| 耦合  | 通常松耦合  | 总是松耦合  |
| 公司架构  | 任何类型  | 小型、专注于功能交叉团队  |
| 管理  | 着重中央管理  | 着重分散管理  |
| 目标  | 确保应用能够交互操作  | 执行新功能、快速拓展开发团队  |

| 比较项 |  RESTful |  RPC
|---|---|---|
| 通讯协议 |  HTTP |  一般使用TCP
| 性能  | 略低 |  较高
| 灵活度 |  高 |  低
| 应用 |  微服务架构 |  SOA架构

 **分布式中的CAP原理** 
```
    Consistency（一致性）：数据一致更新，所有数据的变化都是同步的； 
    Availability（可用性）：在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求；
    Partition tolerance（分区容忍性）：某个节点的故障，并不影响整个系统的运行。
```
通过学习CAP理论，我们得知任何分布式系统只可同时满足二点，没法三者兼顾，既然一个分布 式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样:

| 选 择  |  说 明 |
|---|---|
| CA  | 放弃分区容错性，加强一致性和可用性，其实就是传统的关系型数据库的选择  |
| AP  | 放弃一致性（这里说的一致性是强一致性），追求分区容错性和可用性，这是很多分布式 系统设计时的选择，例如很多NoSQL系统就是如此  |
| CP  | 放弃可用性，追求一致性和分区容错性，基本不会选择，网络问题会直接让整个系统不可用  |

需要明确一点的是，在一个分布式系统当中，分区容忍性和可用性是基本的需求，所以在分布是系统 中，我们的系统当关注的就是A（可用性）P（容忍性），通过补偿的机制寻求数据的一致性。

 **Eureka注册中心** 
```
    微服务每隔30秒向注册中心发送一次心跳，如果90秒内没有发送心跳，代表这个微服务已经宕机。
```
 **Ribbon负载均衡** 
 ```
    1、同一个服务提供者做集群，只有端口号不同
    2、默认有负载均衡策略，如果要修改，可在消费者端配置如下：
        service-product:
          ribbon:
             NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule   #修改负载均衡策略为：随机轮询
    3、如果服务提供者中的一个服务出现问题，消费者调用的时候就会报错，针对这个问题，采用 重试机制 解决
        添加依赖(消费方)并配置：
            <dependency>
            	<groupId>org.springframework.retry</groupId>
            	<artifactId>spring-retry</artifactId>
            </dependency>
            service-product:
              ribbon:
                 ConnectTimeout: 250 # Ribbon的连接超时时间
                 ReadTimeout: 1000 # Ribbon的数据读取超时时间
                 OkToRetryOnAllOperations: true # 是否对所有操作都进行重试
                 MaxAutoRetriesNextServer: 1 # 切换实例的重试次数
                 MaxAutoRetries: 1 # 对当前实例的重试次数
     4、服务重试机制解决了：防止服务宕机造成的服务异常。
 ```
 **Feign服务调用** 
```
    1、支持多种注解，支持SpringMVC注解，并整合了Eureka和Ribbon；
    2、本身已经集成了Ribbon依赖和自动配置，所以不需要引入额外的依赖。
    3、开启请求、响应压缩，以减少通信过程中的性能损耗，配置如下:
        feign:
          compression:
             request:
               enabled: true # 开启请求压缩
             response:
               enabled: true # 开启响应压缩
        同时，我们也可以对请求的数据类型，以及触发压缩的大小下限进行设置：
        feign:
          compression:
             request:
               enabled: true # 开启请求压缩
               mime-types: text/html,application/xml,application/json # 设置压缩的数据类型
               min-request-size: 2048 # 设置触发压缩的大小下限
    4、日志
        feign:
          client:
             config:
               shop-service-product:
                 loggerLevel: FULL 
        logging:
          level:
             cn.life.order.fegin.ProductFeginClient: debug
        日志级别：
            NONE【性能佳，适用于生产】：不记录任何日志（默认值） 
            BASIC【适用于生产环境追踪问题】：仅记录请求方法、URL、响应状态代码以及执行时间 
            HEADERS：记录BASIC级别的基础上，记录请求和响应的header。 
            FULL【比较适用于开发及测试环境定位问题】：记录请求和响应的header、body和元数据。
```