vue+springcloud项目核心技术表述描述模板

上面的Refresh方案虽然可以解决单个微服务运行期间重载配置信息的问题，但是但是在真正的实践生产中，可能会有N多的服务需要更新配置。

如果每次依靠手动Refresh将是一个巨大的工作量，这时候Spring Cloud提出了另外一个解决方案：Spring Cloud Bus。

Spring Cloud Bus通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其它的消息指令中。

Spring Cloud Bus的一个核心思想是通过分布式的启动器对Spring Boot应用进行扩展，也可以用来建立一个或多个应用之间的通信频道。目前唯一实现的方式是用AMQP消息代理作为通道。

Spring Cloud Bus是轻量级的通讯组件，也可以用在其它类似的场景中。有了 Spring Cloud Bus之后，当我们改变配置文件提交到版本库中时，会自动的触发对应实例的Refresh,

服务网关

在微服务架构模式下，后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。

因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway作为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。

Spring Cloud体系中支持API Gateway落地的技术就是Zuul。Spring Cloud Zuul路由是微服务架构中不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。

Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。

链路跟踪

随着服务的越来越多，对调用链的分析会越来越复杂，如服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等，对这些信息进行监控就成为一个问题。

在实际的使用中我们需要监控服务和服务之间通讯的各项指标，这些数据将是我们改进系统架构的主要依据。

因此分布式的链路跟踪就变的非常重要，Spring Cloud也给出了具体的解决方案：Spring Cloud Sleuth 和 Zipkin。

Spring Cloud Sleuth为服务之间调用提供链路追踪。通过Sleuth可 以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。Zipkin是Twitter的一个开源项目，允许开发者收集Twitter各个 服务上的监控数据，并提供查询接口。

总结

我们从整体上来看一下Spring Cloud各个组件如何来配套使用：

从上图可以看出Spring Cloud各个组件相互配合，合作支持了一套完整的微服务架构。

其中Eureka负责服务的注册与发现，很好将各服务连接起来

Hystrix负责监控服务之间的调用情况，连续多次失败进行熔断保护。

Hystrix dashboard, Turbine负责监控Hystrix的熔断情况，并给予图形化的展示

Spring Cloud Config提供了统一的配置中心服务

当配置文件发生变化的时候，Spring Cloud Bus负责通知各服务去获

取最新的配置信息

的作用

最后我们使用Sleuth+Zipkin将所有的请求数据记录下来，方便我们

进行后续分析

Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需

的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数 据监控等。

这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程 中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。