聊聊分布式开发 Spring Cloud
概述
本文章只是简单介绍了微服务开发的一些关键词，如果需要知道具体实现和可以评论留言 我会及时的增加连接写出具体实现(感觉没人看 就没写具体实现)。
先说下分布式系统的CAP理论：
C：一致性 A：可用性 P：分区容错性(集群 扩展性)
CAP理论特点是三者得其二，也是分布式系统目前的瓶颈
Eureka:AP 这应该和Eureka的自我保护机制有关，强调服务的可用性 而不是一致性
zookeeper:CP 因为请求zookeeper服务的时候 往一台机器写东西，会通知机器的所有的机器，可用性就不如一台机器的时候好用(耽误时间)
除了CAP理论 还有一个CBP理论 Capability Beauty Personality：能力 美貌 性格
SpringCloud和Dubbo的区别
1.底层实现：
Dubbo的定位始终是一款基于传输层(TCP)的RPC框架，RPC(Remote Procedure Call)通信过程在传输层中完成(HTTP通信在应用层完成)，
所以RPC调用方式需要服务端与客户端之间建立Socket连接来实现二进制数据的交换
SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式(Spring Cloud就真正的将整个Rest作为RPC实现技术)。
2.使用体验：
Dubbo:利用动态代理 以SDK的方式接口调用(泛化调用：服务调用方不依赖服务方提供的API)
因为在设计RPC之初，设计者的最高理念就是你去面向接口编程，
你在进行远程调用的时候，并没有意识到你在进行远程调用，却也能拿到接口一样，
相信你也感觉到了，服务消费者在调用服务的时候，与调用一个普通的接口是一样的。
SpringCloud: 需要硬编码Http请求(不过也可以使用Fegin声明式调用)
服务治理和服务发现Eureka
Spring的服务治理是使用Netflix的Eureka作为服务治理的，它是我们构建Spring Cloud分布式最为核心和最为基础的模块，
他的作用是注册和发现
@EnableEurekaServer ：在启动类上添加@EnableEurekaServer注解，声明这是一个Eureka Server
@EnableEurekaClient：将微服务注册到Eureka Server上
@EnableDiscoveryClient：将微服务注册到Eureka Server上
注解@EnableEurekaClient上有@EnableDiscoveryClient注解，
可以说基本就是EnableEurekaClient有@EnableDiscoveryClient的功能
其实@EnableEurekaClientz注解就是一种方便使用eureka的注解而已，
Spring Boot服务，并提供监控管理功能。
每一个微服务都可以像服务治理中心注册多个节点(服务名称相同，更改端口号 在启动一次即可)
很多时候 我们也希望服务治理中心也是多个节点，这才可能满足高可用和负载均衡的要求
解决办法: 我们可以采用服务治理中心互相注册来保持相互监控
服务治理中心名称保持不变，将当前的服务治理中心节点A注册到服务治理中心节点B，然后将服务治理中心节点B注册到服务治理中心节点A。
Eureka心跳机制
微服务客户端之所以可以和Eureka保持联系，依靠的是心跳机制，也就是说你客户端可以自己来进行心跳的配置处理。
如果最大心跳时间间隔微服务没有进行心跳(如配置2s心跳心跳一次 最大心跳时间间隔5s)，则认为该微服务已经死宕机了(Eureka会默认出现红字提醒)
微服务之间的调用
Rabbion实际上是一个RestTemplate对象，通过注解@LoadBalance 可以让RestTemplete实现站点层到服务层负载均衡
也就是通过这个restTemplete对象调用用户微服务请求的时候，Ribbon会自动给用户微服务实现负载均衡，请求会被分摊到微服务的各个节点上。
Feign声明式调用。
使用restTemplete对象调用除了编写URL，还需要注意这些参数的组装和结果的返回操作。为了克服这些不友好，Spring Cloud提供了声明式调用组件Feign。
Feign是一个基于接口的编程方式，开发者只需要声明接口和配置注解，在调度接口方法时，Spring Cloud就根据配置来调度对应的REST风格的请求。
@FeignClient(value = "order")，它代表的是一个Feign客户端，而配置的order是一个服务的ID(Service ID)它指向了用户微服务
这样Feign就会知道向用户微服务请求，并实现负载均衡。这里的注解@GetMapping代表启动HTTP的GET请求用户微服务，
而方法中的注解@PathVariable代表从URL中获取参数，(和SpringMVC规则相同)
断路器—Hystrix
在互联网中，某一个微服务可能出现故障，为了不蔓延到其他微服务上面导致雪崩效应。断路器会将产生故障的服务节点进行"熔断"，保持各个微服务持续可用。
处理熔断的方式有 限流、缓存、服务降级，下面介绍服务降级。
所谓降级服务，就是当请求发生超时或者发生故障时，就会使用自身服务的其他方法进行相应。
在服务启动类上加@EnableHystrix注解表示启动断路机制，
方法上增加@HystrixCommand注解，其属性fallbackMethod则可以指定降级方法
对于Hystrix，Spring Cloud还提供了一个仪表盘进行监控短路的情况。
在注册中心增加注解@EnableHystrixDashboard输入URLhttp://127.0.0.1:8761/hystrix就可以看到Hystrix仪表盘首页
路由网关Zuul
网关的功能对分布式网站十分重要，首先他可以将请求路由到真是服务器的IP地址，避免直接的攻击真实服务器
其次它也可以作为一种负载均衡的手段，使请求按照一定的算法平摊到多个节点上，减缓单点的压力。
程序启动主类 注解：@EnableZuulProxy表示我现在要启动的是一个Zuul的代理
从注解中可以看到，Zuul已经引入了断路机制，之所以引入断路机制，是因为在请求不到的时候，会进行断路，以避免网关发生请求无法释放的场景，导致微服务瘫痪。
zuul的配置：
表示zuul代理服务器home路径下所有的请求转发给user服务
https://www.jianshu.com/p/29e12ac2ce42
zuul和feign的区别
zuul的定位是网关，网关的作用是请求路由，相当于你服务的入口。然后根据请求的url不同转发到不同的服务中去。就像nginx的反向代理。
需要通过Nginx负载均衡到不同的Zuul网关？？
feign是抽象的http请求工具。
Spring Cloud 通过Zuul路由到不同的服务，不同服务直接用Feign进行声明式调用
SpringCloud Stream
Spring Boot之中为了方便开发者，已经整合了消息组件，也提供了有一系列的处理支持。如果按照这样的方式在Spring Cloud之中进行消息处理，有些人会认为比较麻烦。
所以在Spring Cloud里面将消息整合的处理操作进行了进一步的抽象操作，实现了更加简化的消息处理。
简单总结：SpringCloud Stream就是实现了MDB功能，同时可以增加更加简化方便的整合消息组件。
SpringCloud Config
顾名思义SpringCloudConfig的核心作用就在于配置文件的管理上。
当项目开发复杂微服务有特别多几百个的时候，对于配置文件的管理就非常麻烦，如果想要进行某一个项配置文件的变更(举例 数据库驱动变更)，那么就有可能修改上百个配置文件。
SpringCloudConfig借助SVN、GITHUB来进行微服务配置文件的保存，SpringCloudConfig保存的配置就是我们GIT仓库。
至于配置文件的安全问题(举例 配置的JDBC不能泄露)，在SpringCloudConfig之中还提供有一些安全加密处理 密钥处理、jsk安全处理。
本质：SpringCloudConfig要求我们所有的配置服务项都要求放到GIT之中，我们使用的时候进行加载，方便整套微服务架构中配置文件的统一管理。
Docker
几乎每个有趣的应用都至少有一个类似数据库或者消息中间件的基础设施服务，我们可以选择把这些基础设施服务安装在自己的机器上。
不幸的是安装起来并不容易，就比如说之前在window上安装mysql各种问题。如果有一键安装的配置就完美了，并且我们并不喜欢在自己的机器上装满各种乱七八糟的服务。
因此我们要用docker容器，docker将作为一个容器运行我们需要的所有的服务。(Nginx Mq Redis Mysql 等等等等)
Docker几个重要的概念
镜像
Docker资源库(只读)，类似Win7操作系统中的光盘 如果想提供服务，还需要docker run命令，创建对应的容器并启动服务
容器
是镜像的实列，由Docker容器创建，类似我们的PC机，每一个PC机安装了Win7的操作系统之后 都可以称为Win7的实列
如果我们把Docker镜像理解为Win7系统光盘的话，那么Docker容器就相当于装了Win7系统的PC机。
仓库
集中存放镜像文件的地方(可以理解为GitHub这样的托管服务器)
Jenkins
我们使用Git管理代码，使用Maven构建项目，使用Docker封装服务，这些事情都需要通过手工方式一步一步的完成，能否让这些步骤自动的去执行呢？
