想要设计自己的微服务？看这篇文章就对了

欢迎大家前往腾讯云+社区，获取更多腾讯海量技术实践干货哦~

本文由我就静静地看发表于云+社区专栏

本文通过使用Spring Boot，Spring Cloud和Docker构建的概念验证应用程序的示例，为了解常见的微服务架构模式提供了一个起点。

该代码在Github上可用，并且可以在Docker Hub上获得图像。只需一个命令即可启动整个系统。

作为这个系统的基础，我选择了一个旧项目，其后端曾经是一个整体。该应用程序提供了一种处理个人财务，组织收入和支出，管理储蓄，分析统计数据和创建简单预测的方法。

功能服务

整体应用程序被分解为三个核心微服务。所有这些都是可独立部署的应用程序，围绕某些业务功能组织。

帐户服务

包含一般用户输入逻辑和验证：收入/费用项目，节省和帐户设置。

METHOD	PATH	DESCRIPTION	USER AUTHENTICATED	AVAILABLE FROM UI
GET	/accounts/{account}	Get specified account data
GET	/accounts/current	Get current account data	×	×
GET	/accounts/demo	Get demo account data (pre-filled incomes/expenses items, etc)		×
PUT	/accounts/current	Save current account data	×	×
POST	/accounts/	Register new account

统计服务

对主要统计参数执行计算并捕获每个帐户的时间序列。数据点包含标准化为基本货币和时间段的值。此数据可用于跟踪帐户生命周期中的现金流动态。

METHOD	PATH	DESCRIPTION	USER AUTHENTICATED	AVAILABLE FROM UI
GET	/statistics/{account}	Get specified account statistics
GET	/statistics/current	Get current account statistics	×	×
GET	/statistics/demo	Get demo account statistics		×
PUT	/statistics/{account}	Create or update time series datapoint for specified account

通知服务

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

METHOD	PATH	DESCRIPTION	USER AUTHENTICATED	AVAILABLE FROM UI
GET	/notifications/settings/current	Get current account notification settings	×	×
PUT	/notifications/settings/current	Save current account notification settings	×	×

注意

每个微服务都有自己的数据库，因此无法绕过API并直接访问持久性数据。
对于这个项目，我使用MongoDB作为每个服务的主数据库。拥有多语言持久性体系结构（以便选择最适合服务要求的数据库类型）也是有意义的。
服务到服务通信非常简单：微服务仅使用同步REST API进行通信。现实世界系统中的常见做法是使用交互方式的组合。例如，执行同步GET请求以检索数据并通过Message broker使用异步方法进行创建/更新操作，以便解耦服务和缓冲消息。这带给我们一致性。

基建服务

分布式系统中有许多常见模式，可以帮助我们使所描述的核心服务工作。Spring cloud 提供了强大的工具，可以增强Spring Boot应用程序的行为以实现这些模式。我简要介绍一下：

配置服务

Spring Cloud Config 是分布式系统的水平可扩展集中配置服务。它使用可插入的存储库层，目前支持本地存储，Git和Subversion。

在这个项目中，我使用 native profile，它只是从本地类路径加载配置文件。你可以在Config服务资源中查看 share 目录。现在，当Notification-service请求它的配置时，使用shared/notification-service.yml 和配置服务响应 shared/application.yml （在所有客户端应用程序之间共享）。

客户端使用

只需构建具有spring-cloud-starter-config 依赖性的Spring Boot应用程序，自动配置将完成剩下的工作。

现在，你的应用程序中不需要任何嵌入属性。只需提供 bootstrap.yml 应用程序名称和配置服务URL：

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

使用Spring Cloud Config，可以动态更改应用程序配置

例如， EmailService bean 使用注释 @RefreshScope。这意味着你可以更改电子邮件文本和主题行，而无需重建和重新启动Notification Service应用程序。

首先，在Config服务器中更改所需的属性。然后，对Notification服务执行刷新请求： curl -H "Authorization: Bearer #token#" -XPOST http://127.0.0.1:8000/notifications/refresh

你还可以使用 webhooks自动执行此过程。

注意

动态刷新有一些限制。 @RefreshScope 不适用于 @Configuration 类，不能影响 @Scheduled 方法。
fail-fast property表示如果Spring Boot应用程序无法连接到Config Service，则会立即失败启动。当你同时启动所有应用程序时，这非常有用。
下面有重要的安全说明。

验证服务

授权职责完全提取到单独的服务器，该服务器为后端资源服务授予 OAuth2令牌。Auth Server用于用户授权以及周边内部的安全机器到机器通信。

在这个项目中，我使用 Password credentials 授权类型进行用户授权（因为它仅由本机应用程序UI使用），并且 Client Credentials 用作微服务授权的授权类型。

Spring Cloud Security提供方便的注释和自动配置，使服务器和客户端都能轻松实现。你可以在文档中了解有关它的更多信息，并检查Auth Server代码中的配置详细信息。

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

PiggyMetrics中的每个客户端（帐户服务，统计服务，通知服务和浏览器）都有一个范围： server用于后端服务， 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请求，在客户端合并结果。另一个问题是非网络友好协议，可能在后端使用。

通常，更好的方法是使用API网关。它是进入系统的单一入口点，用于通过将请求路由到适当的后端服务或通过调用多个后端服务并聚合结果来处理请求。此外，它还可用于身份验证，压力测试，服务迁移，静态响应处理，主动流量管理。

Netflix开源了这样的优质服务，现在有了Spring Cloud，我们可以通过一个@EnableZuulProxy注释启用它。在这个项目中，我使用Zuul存储静态内容（UI应用程序）并将请求路由到适当的微服务。以下是Notification服务的简单基于前缀的路由配置：

zuul:

  routes:

    notification-service:

        path: /notifications/**

        serviceId: notification-service

        stripPrefix: false

这意味着所有以请求开头的请求 /notifications 都将路由到Notification服务。可以看到，没有硬编码的地址。Zuul使用服务发现机制来定位Notification服务实例以及 Circuit Breaker和Load Balancer。

Service Discovery

另一种众所周知的架构模式是Service Discovery。它允许自动检测服务实例的网络位置，这些服务实例可能由于自动扩展，故障和升级而动态分配地址。

服务发现的关键部分是注册表。我在这个项目中使用了Netflix Eureka。当客户端负责确定可用服务实例的位置（使用注册服务器）并在它们之间加载平衡请求时，Eureka是客户端发现模式的一个很好的例子。

使用Spring Boot，你可以轻松地使用spring-cloud-starter-eureka-server 依赖项， @EnableEurekaServer 注释和简单配置属性构建Eureka Registry 。

通过@EnableDiscoveryClient 注释和 bootstrap.yml 应用程序名称启用客户端支持：

spring:application:name: notification-service

现在，在应用程序启动时，它将向Eureka Server注册并提供元数据，例如主机和端口，运行状况指示器URL，主页等.Eureka从属于服务的每个实例接收消息。如果故障超过可配置的时间表，则实例将从注册表中删除。

此外，Eureka提供了一个简单的界面，你可以在其中跟踪正在运行的服务和可用实例的数量： http://localhost:8761

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

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

Ribbon

Ribbon是一个客户端负载均衡器，可以让你对HTTP和TCP客户端的行为进行大量控制。与传统的负载均衡器相比，每次线上调用都不需要额外的跳过 - 你可以直接联系所需的服务。

开箱即用，它本身与Spring Cloud和Service Discovery集成。 Eureka Client 提供可用服务器的动态列表，因此Ribbon可以在它们之间取得平衡。

Hystrix

Hystrix是Circuit Breaker模式的实现，它可以控制通过网络访问的依赖关系的延迟和故障。主要思想是在具有大量微服务的分布式环境中停止级联故障。这有助于快速失败并尽快恢复 - 自我修复的容错系统的重要方面。

除了断路器控制之外，使用Hystrix还可以添加一个回退方法，以便在主命令失败时获取默认值。

此外，Hystrix会为每个命令生成执行结果和延迟的指标，我们可以使用它来监控系统行为。

Feign

Feign是一个声明式HTTP客户端，可与Ribbon和Hystrix无缝集成。实际上，通过一个 spring-cloud-starter-feign 依赖关系和 @EnableFeignClients 注释，你可以拥有一整套负载均衡器，断路器和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代理）将指标推送到Turbine。Monitoring项目只是一个带有Turbine 和 Hystrix Dashboard的小型Spring启动应用程序。

让我们看看我们在负载下的系统行为：帐户服务调用统计服务，它响应模仿延迟。响应超时阈值设置为1秒。


0 ms delay	500 ms delay	800 ms delay	1100 ms delay
表现良好的系统。吞吐量约为22个请求/秒。统计服务中的活动线程数量很少。中位服务时间约为50毫秒。	活动线程的数量正在增长。我们可以看到紫色线程池拒绝的数量，因此大约有30-40％的错误，但电路仍然关闭。	半开状态：失败命令的比例超过50％，断路器启动。睡眠窗口的时间量后，下一个请求通过。	100％的请求失败。电路现在永久开放。睡眠时间后重试不会再次关闭电路，因为单个请求太慢。

日志分析

在尝试识别分布式环境中的问题时，集中日志记录非常有用。Elasticsearch，Logstash和Kibana堆栈使你可以轻松搜索和分析日志，利用率和网络活动数据。我的其他项目中描述随时可用的Docker配置。

安全

高级安全配置超出了此概念验证项目的范围。要更真实地模拟真实系统，请考虑使用https和JCE密钥库来加密微服务密码和配置服务器属性内容（有关详细信息，请参阅文档）。

基建自动化

与部署整体应用程序相比，部署微服务具有相互依赖性，这是一个复杂得多的过程。拥有一个完全自动化的基础设施非常重要。我们可以通过持续交付方法获得以下好处：

随时发布软件的能力。
任何构建都可能最终成为一个版本。
构建工件一次，根据需要进行部署。

这是一个简单的Continuous Delivery工作流程，在此项目中实现：

在此配置中，Travis CI为每个成功的Git推送构建标记图像。因此latest ，Docker Hub上的每个微服务始终都有一个映像，旧的映像使用Git commit hash进行标记。如果需要，可以轻松部署其中任何一个并快速回滚。

如何运行所有的东西？

这真的很容易，我建议你试试。请记住，你要启动8个Spring Boot应用程序，4个MongoDB实例和RabbitMq。确保4 Gb 的计算机上有 RAM。你始终可以通过网关，注册表，配置，身份验证服务和帐户服务运行重要服务。

在你开始之前

安装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。

发展模式

如果你想自己构建映像（例如，在代码中进行一些更改），则必须使用Maven克隆所有存储库并构建工件。然后，运行docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

docker-compose.dev.yml 继承 docker-compose.yml 在本地构建映像的额外可能性，并公开所有容器端口以便于开发。

重要的终点

localhost：80 - 网关
localhost：8761 - Eureka Dashboard
localhost：9000 - Hystrix仪表板
localhost：8989 - Hystrix仪表板源
localhost：15672 - RabbitMq管理

注意

所有Spring Boot应用程序都需要运行 Config Server 才能启动。但是我们可以同时启动所有容器，因为 fail-fast Spring Boot属性和 restart: always docker-compose选项。这意味着所有相关容器将尝试重新启动，直到Config Server启动并运行。

此外，Service Discovery机制在所有应用程序启动后需要一些时间。在实例，Eureka服务器和客户端在其本地缓存中都具有相同的元数据之前，客户端无法发现任何服务，因此可能需要3次侦听。默认侦听时间为30秒。

原文标题《Microservice Architectures With Spring Cloud and Docker》

作者:Alexander Lukyanchikov

译者：我就静静地看

不代表云加社区观点，更多详情请查看原文链接