一、Spring Cloud架构与组件

EureKa Server： 服务注册中心和服务发现中心。

二、Spring Cloud实例

2.1 依赖

spring-cloud-starter-eureka、spring-cloud-starter-eureka-server、spring-cloud-starter-ribbon、spring-cloud-starter-feign、spring-cloud-starter-hystrix、spring-cloud-starter-hystrix-dashboard、spring-cloud-starter-zuul、spring-cloud-starter-config、spring-cloud-config-server等。

2.2 Eureka服务注册中心(集群) 

创建一个E服务，将A、B、C、D四个服务的信息都注册到E服务上，E服务维护这些已经注册进来的信息。A、B、C、D四个服务都可以拿到Eureka(服务E)那份注册清单。A、B、C、D四个服务互相调用不再通过具体的IP地址，而是通过服务名来调用！Eureka专门用于给其他服务注册的称为Eureka Server(服务注册中心)，其余注册到Eureka Server的服务称为Eureka Client。Eureka Client分为服务提供者和服务消费者。

下面是Eureka的治理机制：

1）服务提供者：

（1）服务注册：启动的时候会通过发送REST请求的方式将自己注册到Eureka Server上，同时带上了自身服务的一些元数据信息。

（2）服务续约：在注册完服务之后，服务提供者会维护一个心跳用来持续告诉Eureka Server: "我还活着 ” 。

（3）服务下线：当服务实例进行正常的关闭操作时，它会触发一个服务下线的REST请求给Eureka Server, 告诉服务注册中心：“我要下线了 ”。

2）服务消费者：

（1）获取服务：当我们启动服务消费者的时候，它会发送一个REST请求给服务注册中心，来获取上面注册的服务清单。

（2）服务调用：服务消费者在获取服务清单后，通过服务名可以获得具体提供服务的实例名和该实例的元数据信息。在进行服务调用的时候，优先访问同处一个Zone中的服务提供方。

3）Eureka Server(服务注册中心)：

（1）失效剔除：默认每隔一段时间（默认为60秒） 将当前清单中超时（默认为90秒）没有续约的服务剔除出去。

（2）自我保护：EurekaServer 在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%(通常由于网络不稳定导致)。 Eureka Server会将当前的实例注册信息保护起来， 让这些实例不会过期，尽可能保护这些注册信息。

比如有3个eureka服务实例；java代码只有main函数启动spring应用，特殊注解@EnableEurekaServer。配置如下

2.3 服务提供方provider

比如有3个provider实例，3个实例的应用名称都是一样的，只是host、port不同。代码中main函数包含两个特殊注解：@EnableEurekaClient表示本服务启动后会自动注册进eureka服务中；@EnableDiscoveryClient表示服务发现，在该注解配合下，spring context中会有一个DiscoveryClient的Bean，可以根据应用名获取到所有serviceInstance，他们的host、port信息。其余controller、service、dao层的实现和普通rest服务一样。

此外，provider可以配置Hystrix，需要在main函数加一个特殊注解：@EnableCircuitBreaker。然后在controller action加一个@HystrixCommand(fallbackMethod ="processHystrix_Get")。并定义该fallback方法。

配置如下：

2.4 服务消费方consumer

（1）Ribbon：在main函数加入注解@RibbonClient(name ="serviceName", configuration = MyRule.class)，在启动该微服务的时候就能去加载我们的自定义Ribbon配置类。作为consumer，也会定义controller，只不过会命名controller_consumer，逻辑就是用restTemplate去调用provider的服务。配置RestTemplate的Bean时加上@LoadBalanced注解，来使用Spring Cloud Ribbon这个基于Netflix Ribbon实现的一套客户端负载均衡的工具。MyRule定义的是负载均衡规则，比如轮询每台机器访问5次。配置文件如下：

负载均衡分为客户端负载均衡(Ribbon)和服务端负载均衡(Nginx)。

1）Ribbon：服务实例的清单在客户端，客户端进行负载均衡算法分配。

2）Nginx：服务实例的清单在服务端，服务器进行负载均衡算法分配。

（2）Feign：在main函数加入注解@EnableFeignClients(basePackages = “xxx”)，在controller action中通过FeignClient来调用provider的服务。通过@FeignClient(value ="MICROSERVICECLOUD-DEPT", fallbackFactory = DeptClientServiceFallbackFactory.class)注解标注FeignClientService，该service也采用@RequestMapping注解，且仅为接口，没有实现。Feign可以指定fallback。配置文件如下：

（3）用Hystrix dashboard进行监控：在main函数使用注解@EnableHystrixDashboard。

2.5 Zuul路由网关

Main函数所在的类需要注解：@EnableZuulProxy。配置文件如下：

2.6 Spring Cloud配置

（1）SpringCloud Config服务端：main函数配置注解@EnableConfigServer。

（2）SpringCloud Config客户端：配置放在两个文件分别如下：这里的3344号服务指的就是上面的config server服务。也就是说去配置文件时拿到从3344微服务--->GitHub-->返回来的配置信息。

bootstrap.yml application.yml

三、Feign工作原理

主程序入口添加了@EnableFeignClients注解开启对FeignClient扫描加载处理。根据Feign Client的开发规范，定义接口并加@FeignClient注解。程序启动时扫描所有@FeignClient注解的类，并注入Spring IOC容器中。

当定义的的Feign接口中的方法被调用时，通过JDK代理为每个接口方法生成RequestTemplate，封装HTTP请求需要的全部信息，如请求参数名，请求方法等。RequestTemplate生成Request,然后把Request交给Client去处理，这里的Client可以是JDK原生的URLConnection、Apache的HttpClient，也可以是OKhttp，最后Client被封装到LoadBalanceClient类，这个类结合Ribbon负载均衡发器服务之间的调用。

四、总结Spring Cloud功能

SpringCloud的基础功能：服务治理 Spring Cloud Eureka；客户端负载均衡 Spring Cloud Ribbon；服务容错保护： Spring Cloud Hystrix；声明式服务调用： Spring Cloud Feign；API网关服务：Spring Cloud Zuul；分布式配置中心： Spring Cloud Config；

SpringCloud的高级功能还包括：消息总线： Spring Cloud Bus；消息驱动的微服务： Spring Cloud Stream；分布式服务跟踪： Spring Cloud Sleuth。

五、趣味名词解释

（1）集群：小周在公司写Java程序，但公司业务在发展，一个Java开发者可能忙不过来，小周有的时候也得请个假呀。于是请了3y过去一起做Java开发。平时小周和3y就写Java程序，但3y可能有事要回学校一趟。没事，公司还有小周做Java开发呢，公司开发还能继续运作。3y跟小周都是做Java开发。3y来了，小周的工作可以分担一些。3y请假了，还有小周在呢。集群：同一个业务，部署在多个服务器上(不同的服务器运行同样的代码，干同一件事)

（2）分布式：我的910便利网已经部署到两台服务器去了，但是越来越多的人去访问。现在也逐渐承受不住啦。那现在怎么办啊？？那继续充钱变强？？作为一个理智的我，肯定得想想是哪里有问题。现在910便利网的模块有好几个，全都丢在同一个Tomcat里边。

其实有些模块的访问是很低的(比如后台管理)，那我可不可以这样做：将每个模块抽取独立出来，访问量大的模块用好的服务器装着，没啥人访问的模块用差的服务器装着。这样的好处是：一、资源合理利用了(没人访问的模块用性能差的服务器，访问量大的模块单独提升性能就好了)。二、耦合度降低了：每个模块独立出来，各干各的事(专业的人做专业的事)，便于扩展

特点：

将910便利网的功能拆分，模块之间独立，在使用的时候再将这些独立的模块组合起来就是一个系统了。

好处：

模块之间独立，各做各的事，便于扩展，复用性高

高吞吐量。某个任务需要一个机器运行10个小时，将该任务用10台机器的分布式跑(将这个任务拆分成10个小任务)，可能2个小时就跑完了

分布式：一个业务分拆多个子业务，部署在不同的服务器上(不同的服务器，运行不同的代码，为了同一个目的)

（3）CAP：由于我们的系统是分布式的，节点之间的通信是通过网络来进行的。只要是分布式系统，那很有可能会出现一种情况：因为一些故障，使得有些节点之间不连通了，整个网络就分成了几块区域。现在出现了网络分区后，此时有一个请求过来了，想要注册一个账户。此时我们节点一和节点三是不可通信的，这就有了抉择：

如果允许当前用户注册一个账户，此时注册的记录数据只会在节点一和节点二或者节点二和节点三同步，因为节点一和节点三的记录不能同步的。

这种情况其实就是选择了可用性(availability)，抛弃了数据一致性(consistency)

如果不允许当前用户注册一个账户(就是要等到节点一和节点三恢复通信)。节点一和节点三一旦恢复通信，我们就可以保证节点拥有的数据是最新版本。

这种情况其实就是抛弃了可用性(availability)，选择了数据一致性(consistency)

P指的是Partition tolerance。