最近在项目上遇到一个奇怪的问题： 我们有两个服务，服务A调用服务B发送邮件，但结果是重复发送了4封邮件，内容还是一样的。一开始以为是邮件服务器出问题，但通过本地调试发现发送邮件的方法是被重复调用了。 至于为什么会重复调用，这得先了解一下Spring Cloud 的重试机制。

上篇 使用Maven构建微服务的Docker镜像 写了如何构建微服务的镜像及运行镜像。但往往我们整个微服务架构中会有几十个甚至几百个微服务，我们不可能都使用手动去启停，那样效率很低，维护量也很大。

在预习了Docker的知识后，开始对微服务进行Docker容器化改造。

在微服务架构中可以使用Zipkin来追踪服务调用链路，可以知道各个服务的调用依赖关系。在Spring Cloud中，也提供了Spring Cloud Sleuth来方便集成Zipkin实现。

[TOC] 在学习完前面的知识后，微服务架构已经初具雏形。但还有一些问题：不同的微服务一般会有不同的网络地址，客户端在访问这些微服务时必须记住几十甚至几百个地址，这对于客户端方来说太复杂也难以维护。如下图：

目录 [TOC] 前面的文章为微服务架构引入了统一配置管理Spring cloud config，实现了各个微服务配置分布式管理。配置被修改后，我们不可能重新启动微服务，前面说到过Spring Cloud Config可以自动更新配置，本篇会对同步自动刷新配置进行学习记录。另外配置文件存储在GIT仓库中，很多场景下，对于某些敏感的配置内容(例如数据库账号，密码等)，应当加密存储。部分内容涉及上篇文章：微服务学习笔记–使用Spring Cloud Config 统一管理微服务配置

目录 [TOC] 微服务架构中为了方便管理与更新各微服务的配置，在Spring Cloud中可以使用 Spring Cloud Config 来统一管理系统内各微服务的配置文件。使用Config统一管理后，可实现git分布式版本控制，不同环境不同配置，动态调整自动更新配置等功能。Spring Cloud Config 包括Config Server 和 Config Client 两部分，Config Server用于管理配置，Config Client 则与各微服务集成负责向Config Server请求获取配置并进行缓存以提高性能。Config Server默认使用Git存储配置内容，当然也可以使用SVN,本地文件系统或Vault存储配置。下面把Config Server 、 Config Client 和 Eureka配合使用记录下来。

目录 [TOC] 在微服务架构中，如果服务提供者响应缓慢，那么服务消费者的请求就会被强制等待，或响应超时。在高负载场景下，如果不做任何处理，这类问题可能会导致服务消费者资源耗竭甚至整个系统的崩溃。

[TOC] 前面的文章中，服务消费者调用服务提供者的接口我们是使用RestTemplate实现的REST API调用的。但这种方式在参数比较多时会变得低效，难以维护。

目录 [TOC] 为了实现微服务架构的高可用性，一般在生产环境中，各个微服务会部署多个实例。这里我们需要用到负载均衡，将服务消费者的请求分摊到多个服务提供者实例上。