Dubbo的一些自身特性确保了Dubbo的高可用，比如当注册中心宕机后，服务提供者和服务消费者仍能通过本地缓存通讯；注册中心对等集群，任意一台宕掉后，将自动切换到另一台；当有多台服务提供者提供服务时，Dubbo内置了几种负载均衡算法，并且服务提供者是无状态的，任意一台宕掉后，不影响使用；我们还可以通过整合Hystrix来实现服务降级。

Dubbo给我们提供了dubbo-admin和dubbo-monitor-simple用于监控Dubbo服务，可以用来监控接口暴露，注册情况，也可以显示接口的调用明细和调用时间。dubbo-admin和dubbo-monitor-simple的下载地址为：https://github.com/apache/incubator-dubbo-admin/tree/master，这里简单介绍它们如何使用。

Dubbo是一款由阿里巴巴开发的远程服务调用框架（RPC），其可以透明化的调用远程服务，就像调用本地服务一样简单。截至目前，Dubbo发布了基于Spring Boot构建的版本，版本号为0.2.0，这使得其与Spring Boot项目整合变得更为简单方便。而Zookeeper在这里充当的是服务注册中心的角色，我们将各个微服务提供的服务通过Dubbo注册到Zookeeper中，然后服务消费者通过Dubbo从Zookeeper中获取相应服务并消费。本文案例的架构图可以简单用下图表示：

前后端分离的开发模式已经越来越流行，但是前后端的开发进度并不能完全保持一致，当前端需要调用后端尚未开发的RESTful接口时不得不等待后端开发完毕，这将影响并行开发的效率。http://wiremock.org就是一款用于解决这个问题的开源框架。WireMock可以快速的伪造RESTful接口并返回伪造的JSON数据。这里简单记录下WireMock的使用方法。

在微服务数量较多的系统架构中，一个完整的HTTP请求可能需要经过好几个微服务。如果想要跟踪一条完整的HTTP请求链路所产生的日志，我们需要到各个微服务上去查看日志并检索出我们需要的信息。随着业务发展，微服务的数量也会越来越多，这个过程也变得愈发困难。不过不用担心，Spring Cloud Sleuth为我们提供了分布式服务跟踪的解决方案。为了演示如何使用Spring Cloud Sleuth，我们需要构建一个小型的微服务系统。

在上一节Spring Cloud Config统一配置管理中，我们实现了通过往Config-Client发送/refreshPOST请求来刷新配置。不过这种方式只对单个Config-Client有效（往哪个Config-Client发送刷新请求，哪个配置就得到刷新，剩下的Config-Client获取的仍是旧的配置信息）。当Config-Client实例集群数量较多时，如果都要手动一个一个去刷新配置，不仅麻烦还容易遗漏。值得庆幸的是，我们可以借助Spring Cloud Bus来自动刷新集群的配置信息。

Spring Cloud Bus使用轻量级的消息代理（如RabbitMQ，Kafka）连接分布式系统的节点，可以以广播的形式将一些变更信息（如配置的变更）扩散到分布式链路中去。所以我们可以在Config-Server和Config-Client集群中加入Spring Cloud Bus，然后往某个Config-Server实例发送/refresh请求来刷新集群中所有实例的配置信息。

Spring Cloud Config可以对微服务配置进行统一的外部管理，并且默认采用Git来管理配置信息。相对于传统的每个微服务对应一份自个儿的配置文件来说，通过Spring Cloud Config统一管理所有微服务配置具有如下优点：1.集中管理微服务配置，当微服务数量众多的时候，使用这种方式会更为方便；2.通过Git管理微服务配置，方便追踪配置修改记录；3.可以在应用运行期间修改配置，微服务能够自动更新配置。

在微服务的架构中，服务网关就是一个介于客户端与服务端之间的中间层。在这种情况下，客户端只需要跟服务网关交互，无需调用具体的微服务接口。这样的好处在于，客户端可以降低复杂性；对于需要认证的服务，只需要在服务网关配置即可；同样也方便后期微服务的变更和重构，即微服务接口变更只需在服务网关调整配置即可，无需更改客户端代码。

Zuul是一款由Netflix开发的微服务网关开源软件，可以和其自家开发的Eureka，Ribbon和Hystrix配合使用，Spring Cloud对其进行了封装。