使用 Spring Cloud 和 Docker 构建微服务架构

文章译者：Oopsguy（http://oopsguy.com/） 文章链接：http://oopsguy.com/2017/08/05/microservice-architectures-with-spring-cloud-and-docker/

如何使用Spring Boot、Spring Cloud、Docker和Netflix的一些开源工具来构建一个微服务架构。

本文通过使用Spring Boot、Spring Cloud和Docker构建的概念型应用示例，提供了了解常见的微服务架构模式的起点。

该代码可以在Github上获得，并且在Docker Hub上提供了镜像。您只需要一个命令即可启动整个系统。

我选择了一个老项目作为这个系统的基础，它的后端以前是单一应用。此应用提供了处理个人财务、整理收入开销、管理储蓄、分析统计和创建简单预测等功能。

功能服务

整个应用分解为三个核心微服务。它们都是可以独立部署的应用，围绕着某些业务功能进行组织。

使用Spring Cloud和Docker构建微服务架构

账户服务

包含一般用户输入逻辑和验证：收入/开销记录、储蓄和账户设置。

统计服务

计算主要的统计参数，并捕获每一个账户的时间序列。数据点包含基于货币和时间段正常化后的值。该数据可用于跟踪账户生命周期中的现金流量动态。

通知服务

存储用户的联系信息和通知设置（如提醒和备份频率）。安排工作人员从其它服务收集所需的信息并向订阅的客户发送电子邮件。

注意：

• 每一个微服务拥有自己的数据库，因此没有办法绕过API直接访问持久数据。

• 在这个项目中，我使用MongoDB作为每一个服务的主数据库。拥有一个多种类持久化架构（polyglot persistence architecture）也是很有意义的。

• 服务间（Service-to-service）通信是非常简单的：微服务仅使用同步的REST API进行通信。现实中的系统的常见做法是使用互动风格的组合。例如，执行同步的GET请求检索数据，并通过消息代理（broker）使用异步方法执行创建/更新操作，以便解除服务和缓冲消息之间的耦合。然而，这带给我们是最终的一致性。

基础设施服务

分布式系统中常见的模式，可以帮助我们描述核心服务是怎样工作的。Spring Cloud提供了强大的工具，可以增强Spring Boot应用的行为来实现这些模式。我会简要介绍一下：

基础设施服务

配置服务

Spring Cloud Config是分布式系统的水平扩展集中式配置服务。它使用了当前支持的本地存储、Git和Subversion等可拔插存储库层（repository layer）。

在此项目中，我使用了native profile，它简单地从本地classpath下加载配置文件。您可以在配置服务资源中查看shared目录。现在，当通知服务请求它的配置时，配置服务将响应回shared/notification-service.yml和shared/application.yml（所有客户端应用之间共享）。

客户端使用

只需要使用sprng-cloud-starter-config依赖构建Spring Boot应用，自动配置将会完成其它工作。

现在您的应用中不需要任何嵌入的properties，只需要提供有应用名称和配置服务url的bootstrap.yml即可：

spring:
 application:
 name: notification-service
 cloud:
 config:
 uri: http://config:8888
 fail-fast: true

使用Spring Cloud Config，您可以动态更改应用配置：

比如，EmailService bean使用了@RefreshScope注解。这意味着您可以更改电子邮件的内容和主题，而无需重新构建和重启通知服务应用。

首先，在配置服务器中更改必要的属性。然后，对通知服务执行刷新请求：

curl -H "Authorization: Bearer #token#" -XPOST 




    
http://127.0.0.1:8000/notifications/refresh。

您也可以使用webhook来自动执行此过程。

注意：

• 动态刷新存在一些限制。@RefreshScope不能和@Configuraion类一同工作，并且不会作用于@Scheduled方法。

• fail-fast属性意味着如果Spring Boot应用无法连接到配置服务，将会立即启动失败。当您一起启动所有应用时，这非常有用。

• 下面有重要的安全提示

授权服务

负责授权的部分被完全提取到单独的服务器，它为后端资源服务提供OAuth2令牌。授权服务器用于用户授权以及在周边内进行安全的机器间通信。

在此项目中，我使用密码凭据作为用户授权的授权类型（因为它仅由本地应用UI使用）和客户端凭据作为微服务授权的授权类型。

Spring Cloud Security提供了方便的注解和自动配置，使其在服务器端或者客户端都可以很容易地实现。您可以在文档中了解到更多信息，并在授权服务器代码中检查配置明细。

从客户端来看，一切都与传统的基于会话的授权完全相同。您可以从请求中检索Principal对象、检查用户角色和其它基于表达式访问控制和@PreAuthorize注解的内容。

PiggyMetrics（帐户服务、统计服务、通知服务和浏览器）中的每一个客户端都有一个范围：用于后台服务的服务器、用于浏览器展示的UI。所以我们也可以保护控制器避免受到外部访问，例如：

@PreAuthorize("#oauth2.hasScope('server')")
@RequestMapping




    
(value = "accounts/", method = RequestMethod.GET)
public List<DataPoint> getStatisticsByAccountName(@PathVariable String name) {
 return statisticsService.findByAccountName(name);
}

API网关

您可以看到，有三个核心服务。它们向客户端暴露外部API。在现实系统中，这个数量可以非常快速地增长，同时整个系统将变得非常复杂。实际上，一个复杂页面的渲染可能涉及到数百个服务。

理论上，客户端可以直接向每个微服务直接发送请求。但是这种方式是存在挑战和限制的，如果需要知道所有端点的地址，分别对每一段信息执行http请求，将结果合并到客户端。另一个问题是，这不是web友好协议，可能只在后端使用。

通常一个更好的方法是使用API网关。它是系统的单个入口点，用于通过将请求路由到适当的后端服务或者通过调用多个后端服务并聚合结果来处理请求。此外，它还可以用于认证、insights、压力测试、金丝雀测试（canary testing）、服务迁移、静态响应处理和主动变换管理。

Netflix开源这样的边缘服务，现在用Spring Cloud，我们可以用一个@EnabledZuulProxy注解来启用它。在这个项目中，我使用Zuul存储静态内容（UI应用），并将请求路由到适当的微服务。以下是一个简单的基于前缀（prefix-based）路由的通知服务配置：

zuul:
 routes:
 notification-service:
 path: /notifications/**





    
 serviceId: notification-service
 stripPrefix: false

这意味着所有以/notification开头的请求将被路由到通知服务。您可以看到，里面没有硬编码的地址。Zuul使用服务发现机制来定位通知服务实例以及断路器和负载均衡器，如下所述。

服务发现

另一种常见的架构模式是服务发现。它允许自动检测服务实例的网络位置，由于自动扩展、故障和升级，它可能会动态分配地址。

服务发现的关键部分是注册。我使用Netflix Eureka进行这个项目，当客户端需要负责确定可以用的服务实例（使用注册服务器）的位置和跨平台的负载均衡请求时，Eureka就是客户端发现模式的一个很好的例子。

使用Spring Boot，您可以使用spring-cloud-starter-eureka-server依赖、@EnabledEurekaServer注解和简单的配置属性轻松构建Eureka注册中心（Eureka Registry）。

使用@EnabledDiscoveryClient注解和带有应用名称的bootstrap.yml来启用客户端支持：

spring:
 application:
 name: notification-service

现在，在应用启动时，它将向Eureka服务器注册并提供元数据，如主机和端口、健康指示器URL、主页等。Eureka接收来自从属于某服务的每个实例的心跳消息。如果心跳失败超过配置的时间表，该实例将从注册表中删除。

此外，Eureka还提供了一个简单的界面，您可以通过它来跟踪运行中的服务和可用实例的数量：http://localhost:8761

Eureka仪表盘

负载均衡器、断路器和Http客户端

Netflix OSS提供了另一套很棒的工具。

Ribbon

Ribbon是一个客户端负载均衡器，可以很好地控制HTTP和TCP客户端的行为。与传统的负载均衡器相比，每次线上调用都不需要额外的跳跃——您可以直接联系所需的服务。

它与Spring Cloud和服务发现是集成在一起的，可开箱即用。Eureka客户端提供了可用服务器的动态列表，因此Ribbon可以在它们之间进行平衡。

Hystrix

Hystrix是断路器模式的一种实现，它可以通过网络访问依赖来控制延迟和故障。中心思想是在具有大量微服务的分布式环境中停止级联故障。这有助于快速失败并尽快恢复——自我修复在容错系统中是非常重要的。

除了断路器控制，在使用Hystrix，您可以添加一个备用方法，在主命令失败的情况下，该方法将被调用以获取默认值。

此外，Hystrix生成每个命令的执行结果和延迟的度量，我们可以用它来监视系统的行为。

Feign

Feign是一个声明式HTTP客户端，能与Ribbon和Hystrix无缝集成。实际上，通过一个spring-cloud-starter-feign依赖和@EnabledFeignClients注解，您可以使用一整套负载均衡器、断路器和HTTP客户端，并附带一个合理的的默认配置。

以下是账户服务的示例：

@FeignClient(name = "statistics-service")
public interface StatisticsServiceClient {
 @RequestMapping(method = RequestMethod.PUT, value = "/statistics/", consumes = MediaType.APPLICATION_JSON_UTF8_VALUE)