随着应用规模的迅速扩张，单台机器的部署已经难以支撑用户大规模、高并发的请求了， 因此服务化、集群化、分布式概念应运而生。 然而， 集群的维护和多节点应用程序的协作运行远比单机模式复杂，需要顾及到的细节问题实在太多，比如说同一分配置在多台机器上的同步， 客户端程序实时感知服务机状态，应用与应用之间的公共资源的互斥访问等等一系列的问题。zookeeper能够给我们非常完美的解决这些问题，zookeeper天生的就是为解决分布式协调服务这个问题而来。

对于小白来说，下面的知识都是满满的干货，值得好好学习，具体的视频是学习的廖师兄的Spring Boot进阶之Web进阶，值得一看，下面是笔记总结。

在以前，所有的东西放在一起打包，放到服务器上也就不管了，但是到了分布式场景下，可能一个请求要经过十几个服务的周转，如果不进行链路的追踪，这些对于我们来说都是透明的，那么哪个节点存在问题或者存在超时隐患我们都是很难知道的，因此服务追踪是我们必须要做的一样事情。

对于MQ我们并不陌生，市面上也有形形色色的MQ，各有各的特点，原理上多多少少有一点区别，那么在进行MQ的更换的时候可能会出现代码的大片修改，这显然是很不好的，有没有一种方式来屏蔽掉这种MQ间的差异呢？这就引出了今天讨论的主角：Spring Cloud Stream.

为了实现依次redresh自动刷新所有服务的配置文件，所以需要引入消息总线进行消息的通知，本文主要采用kafka作为消息队列来实现，当然了，rabbitMQ也是比较简单的。

关于集中的配置管理已经在 10.天气预报系统-集中化配置 中详细介绍了。本文为了方便引出问题，所以重新介绍一下它的基本使用。

在 9.天气预报系统-API网关 中已经对API网关进行了详细的介绍。基础的概念就不再赘述了。下面着重看一下zuul中如何实现过滤器。

在微服务架构中，我们将一个项目拆分成很多个独立的模块，这些独立的模块通过远程调用来互相配合工作，但是，在高并发情况下，通信次数的增加会导致总的通信时间增加，同时，线程池的资源也是有限的，高并发环境会导致有大量的线程处于等待状态，进而导致响应延迟，为了解决这些问题，我们需要来了解Hystrix的请求合并。

基本的介绍和基本的演示都已经在11.天气预报系统-熔断机制中说明和演示了。下面来说点不一样的东西吧！

在微服务架构中，业务都会被拆分成一个独立的服务，服务与服务的通讯是基于http restful的。Spring cloud有两种服务调用方式，一种是ribbon+restTemplate，另一种是feign。在这一篇文章首先讲解下基于ribbon+rest。