原文：https://dzone.com/articles/microservice-architecture-with-spring-cloud-and-do
作者：Alexander Lukyanchikov
译者：Oopsguy
本文通过一个使用了 Spring Boot、Spring Cloud 和 Docker 构建的概念型应用示例来提供了了解常见的微服务架构模式的起点。
代码可以在 Github 上获得，同时 Docker Hub 上也提供了镜像。你只需要一个命令即可启动整个系统。
我选择了一个老项目作为这个系统的基础，它的后端以前是单体应用。该应用提供了处理个人财务、整理收入开销、管理储蓄、分析统计和创建简单预测等功能。
功能服务
整个应用分解为三个核心微服务。它们都是可以独立部署的应用，围绕某些业务功能进行组织。
账户服务
包含一般用户输入逻辑和相关验证：收入/开销记录、储蓄和账户设置。
| 方法 | 路径 | 描述 | 用户验证 | UI可用 |
|---|---|---|---|---|
| GET | /accounts/{account} | 获取指定账户数据 | ||
| GET | /accounts/current | 获取当前账户数据 | x | x |
| GET | /accounts/demo | 获取演示账户数据（预先填入收入/开销记录等） | x | |
| PUT | /accounts/current | 保存当前账户数据 | x | x |
| POST | /accounts/ | 注册新账户 | x |
统计服务
计算关键的统计参数，并获取每一个账户的时间序列。一个数据点包含了基于货币和时间段常规化后的值。该数据可用于跟踪账户生命周期中的现金流量动态。
| 方法 | 路径 | 描述 | 用户验证 | UI可用 |
|---|---|---|---|---|
| GET | /statistics/{account} | 获取指定账户统计数据 | ||
| GET | /statistics/current | 获取当前账户的统计数据 | x | x |
| GET | /statistics/demo | 获取演示账户统计数据 | x | |
| PUT | /statistics/{account} | 创建或更新指定账户的时间序列数据点。 |
通知服务
存储用户的联系信息和通知设置（如提醒和备份频率）。安排工作人员从其它服务收集所需的信息并向订阅的客户发送电子邮件。
| 方法 | 路径 | 描述 | 用户验证 | UI可用 |
|---|---|---|---|---|
| GET | /notifications/settings/current | 获取当前账户的通知i设置 | x | x |
| PUT | /notifications/settings/current | 保存当前账户的通知设置 | x | x |
注意
- 每一个微服务拥有自己的数据库，因此没有办法绕过 API 直接访问和持久化数据。
- 在这个项目中，我使用 MongoDB 作为每个服务的主数据库。拥有一个混合持久化架构（polyglot persistence architecture）也是很有意义的（数据库的选择根据微服务的要求而定）。
- 服务间（Service-to-service）通信非常简单：微服务仅使用同步的 REST API 进行通信。现实中的系统常见的做法是使用多种组合的交互风格。例如，执行同步的 GET 请求检索数据，并通过消息代理（broker）使用异步方法执行创建/更新操作，以便解除服务和缓冲消息之间的耦合。然而，我们需要面临最终的一致性的问题。
基础设施服务
分布式系统中常见的模式，可以帮助我们描述核心服务如何工作。Spring Cloud 提供了强大的工具，可以增强 Spring Boot 应用的行为来实现这些模式。我会简要介绍一下：
配置服务
Spring Cloud Config 是分布式可水平扩展的配置服务中心。它使用了一个可拔插存储库层（repository layer），当前支持本地存储、Git 和 Subversion 等。
在此项目中，我使用了 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/{name}", 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
负载均衡器、断路器和 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/{accountName}", consumes = MediaType.APPLICATION_JSON_UTF8_VALUE)
void updateStatistics(@PathVariable("accountName") String accountName, Account account);
}
- 你需要的只是一个接口
- 你可以在 Spring MVC 控制器和 Feign 方法之间共享
@RequestMapping部分 - 以上示例仅指定所需要的服务 ID ——
statistics-service，这得益于 Eureka 的自动发现（但显然你可以使用特定的 URL 访问任何资源）。
监控仪表盘
在这个项目配置中，每一个集成了 Hystrix 的微服务都通过 Spring Cloud Bus（通过 AMQP broker）将指标推送到 Turbine。监控项目只是一个使用了 Turbine和 Hystrix 仪表盘的小型 Spring Boot 应用。
让我们看看系统在负载下的行为：账户服务调用统计服务和它在一个变化的模拟延迟下的响应。响应超时阈值设置为 1 秒。
日志分析
当你尝试查找分布式环境中的问题时，集中式日志记录就显得非常有用。Elasticsearch、Logstash 和 Kibana 技术栈可让你轻松搜索和分析日志、利用率和网络活动数据。在我的另一个项目中已经有现成的 Docker 配置。
安全
高级安全配置已经超过了此概念性项目的范围。为了模拟真实系统，请考虑使用 HTTPS 和 JCE 密钥库来加密微服务的密码和配置服务器的 properties 内容（有关详细信息，请参阅文档）。
基础设施自动化
部署微服务比部署单一的应用的流程要复杂得多，因为它们相互依赖，因此拥有完全基础设置自动化是非常重要的。我们可以通过持续交付的方式获得以下好处：
- 随时发布软件的能力。
- 任何构建都可能成为一个发行版本。
- 构建工件（artifact）一次，根据需要进行部署。
这是一个简单的持续交付工作流程，该项目的实现：
在此配置中，Travis CI 为每一次的 Git 推送创建了标签镜像。因此，每个微服务在 Docker Hub 上的都会有一个 latest 镜像，而较旧的镜像则使用 Git 提交的哈希进行标记。在需要时，可以轻松部署任何一个镜像，并快速回滚。
如何全部运行？
这真的很简单，我建议你尝试一下。请记住，你将要启动 8 个 Spring Boot 应用、4 个 MongoDB 实例和一个 RabbitMq。请确保你的机器上有 4GB 的内存来运行网关、注册中心、配置中心、认证服务和账户中心这些重要的服务。
运行之前
- 安装 Docker 和 Docker Compose
- 配置环境变量：
CONFIG_SERVICE_PASSWORD, NOTIFICATION_SERVICE_PASSWORD, STATISTICS_SERVICE_PASSWORD, ACCOUNT_SERVICE_PASSWORD, MONGODB_PASSWORD
生产模式
这种模式下，所有最新的镜像都将从 Docker Hub 上拉取。只需要复制 docker-compose.yml 并执行 docker-compose up -d 即可。
开发模式
如果你想自己构建镜像（例如，修改部分代码），你需要克隆所有仓库（repository）并使用 Mavne 构建工件（artifact）。然后，运行 docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d
docker-compose.dev.yml 继承了 docker-compose.yml，附带额外配置，可在本地构建镜像，并暴露所有容器端口以方便开发。
重要的端点（Endpoint）
- localhost:80 —— 网关
- localhost:8761 —— Eureka仪表盘
- localhost:9000 —— Hystrix仪表盘
- localhost:8989 —— Turbine stream（Hystrix 仪表盘来源）
- localhost:15672 —— RabbitMq管理
注意
所有 Spring Boot 应用都需要在配置服务器运行时才能启动。得益于 Spring Boot 的 fail-fast 属性和 docker-compsoe 的 restart:always 选项，我们可以同时启动所有容器。这意味着所有依赖的容器将尝试重启，直到配置服务器启动运行为止。
此外，服务发现机制在所有应用启动后需要一段时间。在实例、Eureka 服务器和客户端的本地缓存中都具有相同的元数据之前，任何服务都不可用于客户端发现，因此可能需要 3 次心跳。默认的心跳周期为 30 秒。
