一、简介
Spring Cloud 为开发者提供了在分布式系统（配置管理，服务发现，熔断，路由，微代理，控制总线，一次性token，全居琐，leader选举，分布式session，集群状态）中快速构建的工具，使用Spring Cloud的开发者可以快速的启动服务或构建应用、同时能够快速和云平台资源进行对接。
Spring Cloud Config配置中心
Spring Cloud Config就是我们通常意义上的配置中心。Spring Cloud Config-把应用原本放在本地文件的配置抽取出来放在中心服务器，本质是配置信息从本地迁移到云端。从而能够提供更好的管理、发布能力。
Spring Cloud Config分服务端和客户端，服务端负责将git（svn）中存储的配置文件发布成REST接口，客户端可以从服务端REST接口获取配置。但客户端并不能主动感知到配置的变化，从而主动去获取新的配置，这需要每个客户端通过POST方法触发各自的/refresh。
Spring Cloud Netflix 服务发现
Spring Cloud Eureka提供在分布式环境下的服务发现，服务注册的功能。
Spring Cloud Netflix，该项目是Spring Cloud的子项目之一，主要内容是对Netflix公司一系列开源产品的包装，它为Spring Boot应用提供了自配置的Netflix OSS整合。
通过一些简单的注解，开发者就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统。它主要提供的模块包括：服务发现（Eureka），断路器（Hystrix），智能路由（Zuul），客户端负载均衡（Ribbon）等。Spring cloud Hystrix 熔断器
断路器(Cricuit Breaker)是一种能够在远程服务不可用时自动熔断(打开开关)，并在远程服务恢复时自动恢复(闭合开关)的设施。
断路器(Cricuit Breaker)是一种能够在远程服务不可用时自动熔断(打开开关)，并在远程服务恢复时自动恢复(闭合开关)的设施，Spring Cloud通过Netflix的Hystrix组件提供断路器、资源隔离与自我修复功能。
Spring Cloud Zuul 服务网关
Spring Cloud Eureka提供在分布式环境下的服务发现，服务注册的功能。
Spring Cloud Netflix，该项目是Spring Cloud的子项目之一，主要内容是对Netflix公司一系列开源产品的包装，它为Spring Boot应用提供了自配置的Netflix OSS整合。通过一些简单的注解，开发者就可以快速的在应用中配置一下常用模块并构建庞大的分布式系统。它主要提供的模块包括：服务发现（Eureka），断路器（Hystrix），智能路有（Zuul），客户端负载均衡（Ribbon）等。
当然Spring Cloud还有额外扩展的其它很多组件，包括了服务链路监控和跟踪（很关键的一个功能），消息总线，数据流处理，批量任务处理等。而对于整个Spring Cloud微服务框架简单来说，即是：
你只要划分到你的微服务组件和模块，并定义好需要暴露的API接口，那么剩下的整个开发和传统方式没有太大的区别，你开发完成的组件集成起来就是一个分布式可扩展的微服务环境。里面设计到的接口发布，服务注册，服务调用和路由，服务监控，健康检测和流控等都会由微服务框架来帮你完成。
正是有了成熟的微服务框架，我们才更应该将微服务架构设计重心从技术底层转移到组件划分和接口设计上。
SpringCloud和Dubbo的区别问题
对于两者的区别在如下文章有详细描述可以参考：
http://blog.didispace.com/microservice-framework/
可以看到SpringCLoud能够提供的基础能力要多于Dubbo，Dubbo可以看作是SpringCLoud简单实现。
Dubbo是RPC服务治理框架，和Spring Cloud一样具备服务注册、发现、路由、负载均衡等能力。但是没有配置中心，完整的好用全链路监控，需要采用开源的解决方案定制或者自研。Spring cloud的配置中心，全链路监控等组件。从目前来看，Spring Cloud国内中小型企业用的比较多，大型企业可能需要对其需要的组件进行定制化处理。
但是也需要看到Spring Cloud基于注解的服务发现，服务治理等功能具有代码侵入性，dubbo没有代码侵入性，业务开发人员不需要通过注解的方式去关注框架级别的处理。从中间件或者做基础架构的角度来看，其实服务治理等功能对普通的业务程序员应该是透明的，业务程序员不需要关注服务治理框架的使用，专注于业务代码即可。
基于SpringCLoud微服务框架的实践
对于基于SpringCLoud框架的具体实践，建议参考翟永超博客的系列文章，具体如下：
服务注册和发现：http://blog.didispace.com/springcloud1/
服务消费：http://blog.didispace.com/springcloud2/
服务熔断机制：http://blog.didispace.com/springcloud3/
服务配置中心：http://blog.didispace.com/springcloud4/
服务网关：http://blog.didispace.com/springcloud5/
高可用服务注册中心：http://blog.didispace.com/springcloud6/
消息总线：http://blog.didispace.com/springcloud7/
服务注册和发现
注意这里仍然使用的是SpringBoot框架，并和SpringBoot框架进行了集成，在pom.xml配置文件中增加了对SpringCLoud相关包和组件的依赖。在原有的接口API定义的基础上，我们增加@EnableDiscoveryClient注解后，即可以让服务注册中心很轻松的发现服务提供方以及提供的服务。
服务消费
方式1 - Ribbon是一个基于HTTP和TCP客户端的负载均衡器。Ribbon可以在通过客户端中配置的ribbonServerList服务端列表去轮询访问以达到均衡负载的作用。当Ribbon与Eureka联合使用时，ribbonServerList会被DiscoveryEnabledNIWSServerList重写，扩展成从Eureka注册中心中获取服务端列表。
方式2 - Feign是一个声明式的Web Service客户端，它使得编写Web Serivce客户端变得更加简单。我们只需要使用Feign来创建一个接口并用注解来配置它既可完成。它具备可插拔的注解支持，包括Feign注解和JAX-RS注解。Feign也支持可插拔的编码器和解码器。Spring Cloud为Feign增加了对Spring MVC注解的支持，还整合了Ribbon和Eureka来提供均衡负载的HTTP客户端实现。
断路器
首先在pom.xml文件中增加引入对hystrix依赖，同时在消费端Application主类上增加@EnableCircuitBreaker注解开启断路器功能。注意原有的服务消费方式也涉及到修改，增加了服务Callback的回调函数。
服务网关
服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。
spring cloud Eureka使用实例
spring cloud 是基于spring boot实现的微服务架构开发工具，他为微服务中设计的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策精选、分布式会话和集群状态管理等操作提供了一套简单的开发方式。
spring cloud eureka 我们可以把它看做cloud生态中的一个组成部分，它主要的职责是服务治理。
学习一个事物最简单的方式就是使用它，那么，我们从搭建一个实例开始入手，看看如何搭建spring cloud eureka
先说明下有两类角色：1，server 2，client
相对于注册中心来说，只有注册中心的实例为服务端，其余（服务提供方和客户端）均为client端。
1.新建spring boot应用，添加spring cloud eureka server组件，可以在生成的pom文件中添加，当然也可以在新建应用时指定，如：
（如果是注册中心则选在Eureka Server，如果是服务中心或者是client端则选择Eureka Discovery）
生成的pom文件：
@EnableEurekaClient
@SpringBootApplication
publicclass EurekaserverApplication {
public static void main(String[] args){
SpringApplication.run(EurekaserverApplication.class, args);
}
}
3.修改properties文件或yml文件
如果是注册中心实例则添加
server.port=8082
eureka.instance.hostname=localhost
eureka.client.register-with-eureka=false
eureka.client.fetch-registry=false
eureka.client.serviceUrl.defaultZone=http://[Math Processing Error]eureka.instance.hostname:{server.port}/eureka
如果是client端（服务提供方或者客户端）
server.port=8083
spring.application.name=hello-service
eureka.client.serviceUrl.defaultZone=http://localhost:8082/eureka
这里详细说明下各项的配置：
注册中心：
server.port不用说，指明启动的实例端口
eureka.instance.hostname：指明该eureka实例的主机名称
eureka.client.register-with-eureka：默认情况下，该注册中心实例也会向自己注册自己，所以说，设置为false即为禁用本身的客户端注册
eureka.client.fetch-registry：注册中心的职责是负责维护实例，并不需要去检索服务，因为此处设置为false
eureka.client.serviceUrl.defaultZone：这是spring cloud的服务划分机制，后面的博客会详细讲解，在这里你可以简单理解为集群中心url地址
client：
eureka.client.serviceUrl.defaultZone：指明集群中心的地址
好了，到目前为止，一个完备的集群中心就搭建完了，
我们来分析一下构成：
1.集群注册中心 2.服务提供方 3.客户端实例
他们三者之间关系可用下列示意图表示：
开启三个实例，分别担任上述三者。
可以通过访问注册中心地址：
http://localhost:8082/（8082是注册中心实例端口），可看到如下页面
ok,至此，即完成了一套服务的搭建，麻雀虽小五脏俱全。
我们现在可以来分析回顾一下上述基础架构中的三个核心要素：
**服务注册中心：Eureka提供的服务端，提供服务注册与发现的功能，即上述的eureka-server
服务提供者：提供服务的应用。可以是spring boot的应用，也可以是其他遵循Eureka的通信机制的应用。他将自己提供的服务注册到Eureka上以供其他的应用发现
服务消费者：消费者应用从服务注册中心上面获取服务列表，从而可以知道从何处可以调用其所需的服务。
很多时候，客户端既是服务提供者也是服务消费者。