# microservicecloud

**Repository Path**: souls/microservicecloud

## Basic Information

- **Project Name**: microservicecloud
- **Description**: springcloud微服务
- **Primary Language**: Java
- **License**: Not specified
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 0
- **Created**: 2020-04-12
- **Last Updated**: 2020-12-18

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# microservicecloud
springcloud微服务 2018年发布第一季

# Cloud
## eureka 注册发现
> 服务注册与发现(服务端、客户端)
* 自我保护
* AP原则
* 集成
> zookeeper、eureka的区别
1. zookeeper机制保证CP（master结点故障，选举leader的时间太长，30~120s）
2. eureka保证AP（各结点平等）
3. 网络故障结点，导致瘫痪
    1. Eureka不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
    2. 虽然能接受新服务的注册和查询请求，但不会同步到其它结点
    3. 当网络稳定时，新加入的信息才会同步到其它结点

## Ribbon 负载均衡(nginx)
> 实现的一套客户端的负载均衡算法工具
* 负载均衡 LB = load balancer,集中式LB(偏硬件);进程内LB（偏软件）.
* HA 高可用
* @LoadBalanced SC Ribbon负载均衡工具
* 核心组件IRule
* 策略：轮询，随机，加权等7种算法
```text
IRule策略:
RoundRobinRule 轮询
RandomRule 随机
AvailabilityFilteringRule 先过滤掉由于多次访问故障而处于断路的服务，还有并发连接数超过阀值的服务，对剩余的进行轮询
WeightedResponseTimeRule 根据平均响应时间计算服务权重，时间越快权重越高
RetyRule 先按RoundRobinRule策略，如果服务失败则在指定时间内重试，获取可用服务
BestAvailableRuele 先过滤掉失败的，在选择并发小的服务
ZoneAvoidanceRule 复合判断server所在区域的性能和可用性选择服务
```
* 需要使用@RibbonClient
* 警告：自定义配置类不能放在@ComponentScan所扫描的当前包下以及子包下，否认则这个配置类就会呗所有的Ribbon客户端所共享，也就是说达不到定制化的效果

## Feign 接口客户端
* 声明了Rest客户端、webserver客户端
* 只需要创建接口和注解即可
* 可以和Eureka和Ribbon组合使用以支持负载均衡
* @EnableFeignClients
* 源码：https://github.com/OpenFeign/feign
* 通过微服务名称调用
* 通过接口和注解调用
* 统一的面向接口编程
* 如:
```java
@Mapper
public interface DeptDao{}
```

## Hystrix 断路器（豪猪）
* 主要是服务熔断，服务降级等，处理延迟和容错，不会导致服务整体失败，避免级联故障，提高分布式系统的弹性
* 扇出：依赖关系
* 雪崩
* 断路器是一个开关装置，当服务某个服务故障后，通过断路器的故障监控，向调用方返回一个符合预期的、可处理的备选响应（FallBack）,而不是长时间的等待活着抛出异常
* 源码：https://github.com/Netflix/Hystrix/
* @HystrxCommand
* @EnableCircuitBreaker //对hystrix熔断机制的支持
* 服务降级：整体资源快不够用了，忍痛将某些服务先关掉，待度过难关，再开启回来
* 降级是在客户端进行的，与服务端无关
* 通过面向切面编程解耦，最好在接口模块中实现
* 服务熔断：（如保险丝）一般是某个服务故障或是异常，直接熔断整个服务，而不是一直等到服务超时
* 服务降级：从整体考虑，当服务熔断之后，服务器将不再被调用，此时客户端自己准备一个fallback回调，返回一个缺省值。
* HystrixDashboard服务监控：实时滴调用监控系统，Hystrix会持续记录所有通过Hystrix发起的请求信息，并以统计报表和图形的形式展示，包括多少次，成功多少，失败多少等
* HystrixDashboard：通过hystrix-metrics-event-stream项目实现了指标的监控
* @EnableHystrixDashboard
* 所有Provider类都需要提供监控以来配置(actuator)
* 启动访问地址：http://127.0.0.1:9001/hystrix
* 被监控的访问：http://业务服务/hystrix.stream(7色、一圈（健康度:绿色<黄色<橙色<红色,流量大:实心圆越大）、一线)

## zuul 路由网关
> 包含了对请求的==路由和过滤==的主要功能
1. 路由:主要负责将外部请求转发到具体的微服务上，实现外部访问的统一入口
2. 过滤:负责对请求的处理过程进行干预，实现请求校验（安全）、服务聚合等功能的实现
* zuul注册为Eureka服务治理下的应用，可以通过Eureka获取其他微服务的消息,以后的访问可通过zuul跳转
* 提供=代理+路由+过滤
* 源码：https://github.com/Netflix/zuul/
* @EnableZuulProxy
* 访问方式，如：gateway-9527.com:9527/microservicecloud-dept/dept/list
* 路由映射

## config 分布式配置中心（服务端、客户端）
> 轻量级的集中式、动态的管理协调微服务，集中化的外部配置支持，运行环境动态配置，不需要重启获取最新的配置，已Rest接口的形式暴露
* Congif Server -> git(local,remote)
* 服务端：独立的微服务应用，用来连接配置服务器，为客户端提供配置信息，加密、解密等访问接口
* 客户端：通过指定的配置中心来管理应用资源，采用git来存储配置，有助于环境配置进行版本管理
* @EnableConfigServer
* config与git通信
> 服务端
```text
申请仓库地址: 
http方式:https://gitee.com/souls/microservicecloud-config.git
ssh方式:git@gitee.com:souls/microservicecloud-config.git

本地仓库:
E:\gitee\gitconfig

文件编码：使用utf-8
 
配置读取规则- 访问：
http://***:3344/application-test.yml
http://***:3344/master/application-test.yml
配置读取规则- 访问-json：
http://127.0.0.1:3344/application/dev/{master|dev|alpha}
```
> 客户端n
```text
配置文件： 
bootstrap.yml 是系统级，优先级最高
application.yml 是用户级的资源配置

```
* yml文件中“---”是分隔符
* @Value读取自己配置下的配置信息

## 其它
> 分布式数据库中CAP原理CAP+BASE
* 事物（Transaction）：所组成的一个程序执行逻辑单元（Unit）
* 事务具有四个特性，分别是原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）,简称为事务的ACID特性。
> ACID
```text
原子性:要么全部执行，要么全部不执行
一致性:指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行前后，数据库都必须处于一致性状态。
隔离性:指在并发环境中，并发的事务是相互隔离的，事务之间互不干扰
持久性又称为永久性，是指一个事务一旦提交，对数据库中对应数据的状态变更就应该是永久性的
```
> CAP定理:一致性（C:Consistency）、可用性（A:Availability）和分区容错性（P:Partition tolerance）
```text
一致性是指数据在多个副本之间是否能够保持一致的特性（这点跟ACID中的一致性含义不同）
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果，如果超过了这个时间范围，那么系统就被认为是不可用的。
分区容错性要求一个分布式系统需要具备如下特性：分布式系统在遇到任何网络分区故障的时候，仍然能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
```
> base理论
* BASE是Basically Available(基本可用）、Soft state(软状态）和Eventually consistent(最终一致性）
* 是对CAP中一致性和可用性权衡的结果，对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的
* 即使无法做到强一致性，但每个应用都可以根据自身的业务特点，采用适当的方法来使系统达到最终一致性

> 分布式
* RDBMS(mysql,oracle,sqlserver) => ACID
* nosql(reids,mongodb) => CAP(分布式系统中，最多只能实现两点)
* 传统的关系型数据库ACID(原子性、一致性、独立性、持久性)
* NOSQL数据库是CAP（consistency强一致性、availability可用性、partition tolerance分区容错性）
* P是必须要实现的
* CAP的3进2
* 举例：淘宝双十只能保证AP
* BASE是什么


> spring的ioc,aop
* aop切面编程
* ioc

> jvm
* bootstrap

> nginx
* 反向代理
* 动静分离
* 负载均衡
* Lvs(linux虚拟化)来实现负载均衡
* keepalived来实现HA(高可用)

> redis
* 哨兵模式
* Codis(加强redis高可用、高性能)

## 备注
- 白骨精（白领、骨干、精英）,等级：码神 > 码龙 > 码牛 > 码工 > 码农 > 码畜 > 码渣 (p10-p3)
- 梅花香自苦寒来，面试造飞机，工作拧螺丝

## 参考资料
[spring官网](https://spring.io/microservices)

## sql
```
create TABLE dept
(
	deptno BIGINT NOT NULL PRIMARY KEY AUTO_INCREMENT,
	dname VARCHAR(60),
	db_source VARCHAR(60)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

INSERT INTO `dept` (`dname`, `db_source`) VALUES ('开发部', 'cloudDB01');
INSERT INTO `dept` (`dname`, `db_source`) VALUES ('人事部', 'cloudDB01');
INSERT INTO `dept` (`dname`, `db_source`) VALUES ('财务部', 'cloudDB01');
INSERT INTO `dept` (`dname`, `db_source`) VALUES ('市场部', 'cloudDB01');
INSERT INTO `dept` (`dname`, `db_source`) VALUES ('运维部', 'cloudDB01');
```