https://www.jianshu.com/p/27612883468d
前言：
springcloud 作为当下主流的微服务架构，让我们实现微服务架构简单快捷，spring coud中各个组件在微服务架构中扮演的角色如下图所示。黑线表示注释说明，蓝线由A指向b,表示b从A处获取服务。
springcloud 组成的微服务架构图：
由上图所示微服务架构大致由上图的逻辑结构构成，期指那个各种微服务，注册发现，服务网关。熔断器。统一配置，跟踪服务等。下面说说spring cloud中的组件 分别充当其中的什么角色。
feign:
Feign（接口调用）：微服务之间通过rest接口通讯，Springcloud 提供feign框架来支持Rest的调用，Feign使得不同进程的Rest接口调用得以用优雅的方式进行，这种优雅表现就像同一个进程调用一样。
Eureka:
Nettflix eureka(注册发现)： 微服务模式下，一个大的Web应用通常被拆分为很多比较小的web应用（服务），这个时候需要有一个地方保存这些服务的相关信息，才能让各个小的应用彼此知道对方，这个时候就要在注册中心进行注册。每个应用
启动时向配置的注册中心注册自己的信息（ip地址，服务端口号，服务名称等信息），注册中心将他们保存起来，服务间相互调用的时候，通过服务名称就可以到注册中心找到对应的服务信息，从而进行通讯。注册与发现服务为为服务之间的调用带来了方便，解决了硬编码的问题。服务间只通过对方的服务id,而无需知道其ip和端口即可获取对方的服务名称。
Ribbon：
Ribbon(负载均衡)：ribbon时Netflix发布的负载均衡器，他有助于控制HTTP和TCP客户端的行为。为Ribbon,配置服务提供者的地址列表后，RIbbon就可以基于某种负载均衡算法，自动的帮助服务消费者去请求。ribbon默认为为我们提供了很多负载均衡算法，例如： 轮询，随机等。当然，我们也可以为ribbon实现自定义的负载均衡算法，在springCloud中,当ribbon与eureka配合使用时，Ribbon可自动从EurekaServer获取服务提供者的地址列表，并基于负载均衡算法，请求其中一个服务提供者的实例（为了服务的可靠性，一个微服务可能部署多个实例）
Hystrix
Hystrix（熔断器）：当服务提供者响应非常慢，那么消费者对提供者的请求就会强制等待，直到提供者响应或超时。在高负载场景下，如果不做任何处理，此类问题可能会导致服务消费者的资源耗劫甚至系统的崩溃（雪崩效应）。Hystrix 正是为了防止此类问题发生。Hystrix是由Netflix 开源的一个延迟和容错库，用于隔离访问远程系统，服务或者第三方库，防止级联失败，从而提升系统的可用性和容错性。Hystrix主要通过以下几点实现延迟和容错。
包裹请求： 使用HystrixCommand(或HystrixObservableCommand)包裹对依赖的调用逻辑，每个命令在独立线程中执行，这使用了设计模式中的命令模式；
跳闸机制： 当某服务的错误率超过一定阀值时，Hystrix可以自动或者手动跳闸，停止该服务一段时间。
资源隔离： Hystrix为每一个依赖都维护了一个小型的线程池（或者信号量），如果该线程池已满，发生该依赖的请求就被立即拒绝，而不是排队等候，从而加速失败判定。
监控： Hystrix可以近乎实时地监控运行指标和配置的变化，例如成功，失败，超时和被拒绝的请求等。
回退机制： 当请求失败，超时，被拒绝，或当断路器打开时，执行回退逻辑。回退逻辑可由开发人员指定。
Zuul
Zuul(微服务网关)： 不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求。例如一个购买电影票的手机APP，可能调用多个微服务的接口才能完成一次购票的业务流程，如果让客户端直接与各个微服务通信，会有以下的问题：
客户端会多次请求不同的微服务，增加了客户端的复杂性。
存在跨域请求，在一定场景下处理相对复杂。
认证复杂，每个服务都需要独立认证。
难以重构，随着项目的迭代，可能需要重新划分微服务。例如： 可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将很难实施。
某些微服务可能使用了对防火墙/浏览器不友好的协议，直接访问时会有一定的困难。
以上问题可以借助微服务网关来实现，微服务网关是介于客户端和服务端之间的中间层，所有的外部请求都会先经过微服务网关。使用微服务网关后，微服务网关将封装应用程序的内部结构。客户端只需要跟网关交互，而无需直接调用特定的微服务的接口。这样，开发就可以得到简化。不仅如此。使用微服务网关还有以下优点：
易于监控：可以在微服务网关收集监控数据并将其推送到外部系统进行分析。
易于认证： 可在微服务网关上进行认证，然后将请求转发到后端的微服务，而无需再每个微服务中进行认证。
减少了客户端和各个微服务之间的交互次数。
Config:
spring cloud Config(统一配置服务)： 对于传统的单体作用，常使用配置文件管理所有配置.例如一个springboot 开发的单体应用，可以将配置内容放在application.yml文件中，如果需要切换环境，可以设置多个Profile,并在启动的时候指定spring.profiles.active={profile}.然而，在微服务架构中，微服务的配置管理一般有以下需求：
集中管理配置，一个使用微服务架构的应用系统可能包含成百上千个微服务，因此集中管理配置是非常有必要的；
不同的环境，不同的配置。例如：数据源配置在不同的环境（开发测试，预发布，生产等）中是不同的，运行期间可以动态调整。例如。可以根据各个微服务的负载情况，动态调整数据源连接池大小或熔断阀值，。并且在调整配置时不停止微服务；
配置修改后可以自动更新，如果配置内容发生变化，微服务能自动更新配置。综上所述，对于微服务架架构而言，一个通用的配置管理机制是必不可少的，常见做法是使用配置服务器管理配置。spring cloud bus利用 git或svn等管理配置，采用kafaka或者RabbitMQ等消息总线通知所有应用，从而实现配置的自动更新并且刷新所有微服务实例的配置。
Zipkin：
Sleuth+zipkin(跟踪服务)： Sleuth和ZIpkin 结合使用可以通过图形化的界面查看微服务请求的延迟情况以及各个微服务的依赖情况。需要注意的是spring boot2以及以上不在支持Zipkin的自定义，需要到官方下载ZipKin相关的jar包；
其他：
另外需要提一点的是springboot acutor。提供了很多监控端点：
如/acutor/info ,/acutor/health, /acutor/refresh 等，可以查看微服务的信息，健康状况，刷新配置等。
