基于Spring Boot、Spring Cloud、Docker的微服务系统架构实践

原文/项目 地址：github.com/sqshq/Piggy…

这个项目的名字叫：Piggy Metrics，一个供我的处理财务的解决方案。

简介 这是一款概念性的应用程序，基于Spring Boot，Spring Cloud和Docker 简单演示了微服务的架构模式，顺便说一句，它还有一个很是漂亮整洁的用户界面。下面是它的界面演示：

功能服务

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

帐户服务

包含通常用户输入逻辑和验证：收入/费用项目，储蓄和账户设置。

统计服务

对主要统计参数执行计算，并为每一个账户的时间序列。数据点包含基准货币和时间段的值。此数据用于跟踪账户生命周期中的现金流动动态（还没有在UI中实现的花式图表）。

通知服务

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

**小结：

每一个微服务都有本身的数据库，所以没有办法绕过API和直接访问数据库。

在这个项目中，使用MongoDB做为每一个服务的主数据库。它是支持多种编程语言持久性架构（包括最适合服务需求的数据库类型）。

Service-to-service的通讯是至关简单的：各个微服务之间的通讯只使用同步的RESTAPI。在现实世界中一般的作法是使用交互风格的组合。例如，执行同步GET请求以检索数据，并经过消息代理使用异步方法进行建立/更新操做，以便分离服务和缓冲消息，这为咱们带来了一致性。

基础服务设施

在分布式系统中有一些常见的架构，这能够帮助咱们理解核心服务的工做原理。Spring Cloud提供了强大的工具来加强基于Spring Boot的应用程序，以此来实现这些架构。

Config service

Spring Cloud Config是用于分布式系统的水平可扩展的集中式配置服务。支持本地存储、Git和Subversion。

在这个项目中，使用native profile，它从本地类路径加载配置文件。能够查看shared在Config服务资源中的目录。如今，当通知服务请求其配置时，配置服务以shared/notification-service.yml和shared/application.yml响应（在全部客户端应用程序之间共享）。

客户端使用 只需构建具备spring-cloud-starter-config依赖的Spring Boot应用程序，自动配置将完成其他全部工做。

如今，不须要在应用程序中使用任何嵌入式属性。只需提供bootstrap.yml应用程序名称和配置服务url：

使用Spring Cloud Config，能够动态地更新配置。 例如，EmailService bean已注释@RefreshScope。这意味着，能够更改电子邮件文本和主题，而不须要从新部署启动通知服务。

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

此外，也可使用Repository webhooks自动执行此过程

**小结：

动态更新有一些限制。@RefreshScope不与@Configuration类一块儿使用，而且不影响@Scheduled方法 fail-fast属性意味着Spring Boot若是它没法链接到Config Service就将启动失败，这在批量启动时很是有用。 安全注意事项请往下看

Auth service 受权的责任彻底抽取到单独的服务器，它为后端资源服务授予OAuth2令牌。Auth服务器用于用户受权以及在外围内的安全的机器对机器通讯。

在这个项目中，我使用Password credentials受权类型的用户受权（由于它只由本地PiggyMetrics UI使用）和Client Credentials授予微服务权限。

Spring云安全提供了方便的注释和自动配置，使得从服务器端和客户端端都很容易实现。您能够在文档中了解更多信息，并在Auth Server代码中检查配置详细信息。

从客户端，一切工做与传统的基于会话的受权彻底相同。您能够Principal从请求中检索对象，检查用户的角色和其余使用基于表达式的访问控制和@PreAuthorize注释的东西。

PiggyMetrics（账户服务，统计服务，通知服务和浏览器）中的每一个客户端都有一个范围：server用于后端服务，以及ui- 用于浏览器。所以，咱们还能够保护控制器免受外部访问，例如：

API Gateway 能够看到，有三个核心服务，它们向客户端公开外部API。在现实世界的系统中，这个数字能够快速增加以及整个系统的复杂性。实际上，上百个服务可能涉及到渲染一个复杂的网页。

在理论上，客户端能够直接向每一个微服务器发出请求。可是显然，这个选项有挑战和限制，如须要知道全部端点地址，分别执行每一个信息的http请求，在客户端合并结果。另外一个问题是非web友好的协议，可能在后端使用。

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

Netflix打开了这样一个边缘服务，如今使用Spring Cloud，咱们可使用一个@EnableZuulProxy注释启用它。在这个项目中，我使用Zuul来存储静态内容（ui应用程序），并将请求路由到适当的微服务。这是一个简单的基于前缀的路由配置Notification服务：

这意味着全部开始的请求/notifications都将路由到Notification服务。没有硬编码的地址，你能够看到。Zuul使用服务发现机制来定位通知服务实例，以及断路器和负载平衡器，以下所述。

Service discovery 另外一个公知的架构模式是服务发现。它容许自动检测服务实例的网络位置，因为自动扩展，故障和升级，可能会动态分配地址。

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

使用Spring Boot，您能够轻松地使用spring-cloud-starter-eureka-server依赖关系，@EnableEurekaServer注释和简单配置属性来构建Eureka注册表。

支持@EnableDiscoveryClient注释的客户端支持bootstrap.yml应用程序名称：

如今，在应用程序启动时，它将注册到Eureka服务器并提供元数据，如主机和端口，运行情况指示器URL，主页等。Eureka从属于一个服务的每一个实例接收心跳消息。若是心跳故障切换到可配置的时间表，则实例将从注册表中删除。

此外，Eureka提供了一个简单的界面，您能够跟踪运行的服务和可用实例数： http://localhost:8761

负载均衡器，断路器和Http客户端 Netflix OSS提供了另外一个伟大的工具集。

Ribbon Ribbon是一个客户端负载均衡器，它为您提供了对HTTP和TCP客户端行为的大量控制。与传统的负载均衡器相比，每一个线上调用不须要额外的跳跃 - 您能够直接联系所需的服务。

开箱即用，它与Spring Cloud和服务发现自己集成。Eureka Client提供了可用服务器的动态列表，以便Ribbon能够在它们之间进行平衡。

Hystrix Hystrix是断路器模式的实现，它提供了对经过网络访问的依赖性的延迟和故障的控制。主要思想是在具备大量微服务的分布式环境中中止级联故障。这有助于快速失败，并尽快恢复 - 自愈的容错系统的重要方面。

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

此外，Hystrix生成每一个命令的执行结果和延迟的指标，咱们能够用它来监视系统行为。

Feign Feign是一个声明式Http客户端，它与Ribbon和Hystrix无缝集成。实际上，使用一个spring-cloud-starter-feign依赖项和@EnableFeignClients注释，您拥有一组完整的负载平衡器，断路器和Http客户端，并具备合理的即用型默认配置。

如下是账户服务的示例：

你须要的只是一个接口

你能够用@RequestMapping在Spring MVC控制器和Feign方法之间共享部分 上面的示例指定只须要的服务id -

statistics-service，因为经过Eureka自动发现（但显然，您能够访问任何资源与特定的网址） 监视仪表板

在这个项目配置中，Hystrix的每一个微服务经过Spring Cloud Bus（使用AMQP代理）将指标推送到Turbine。监控项目只是一个小的Spring启动应用程序与涡轮和Hystrix仪表板。

看下面如何让它运行。

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

blog.csdn.net/rickiyeat/a…

日志分析

当尝试在分布式环境中识别问题时，集中式日志记录可能很是有用。Elasticsearch，Logstash和Kibana堆栈使您能够轻松搜索和分析您的日志，利用率和网络活动数据。个人其余项目中描述的即开即用 Docker配置。

安全

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

基建自动化

部署微服务及其相互依赖性，比部署单片应用程序要复杂得多。拥有彻底自动化的基础设施很是重要。咱们能够经过持续交付方法实现如下优点：

随时释放软件的能力

任何构建可能最终都是发布

构建工件一次 - 根据须要部署

这里是一个简单的连续交付工做流，在这个项目中实现：

在此配置中，Travis CI为每一个成功的git push创建标记的映像。所以，latest对于Docker Hub上的每一个微服务总有图像，而且用git提交哈希标记的旧图像。它很容易部署任何一个，并快速回滚，若是须要。

如何运行全部的东西？

记住，你要启动8个Spring Boot应用程序，4个MongoDB实例和RabbitMq。确保您4 Gb的计算机上有可用的RAM。您能够始终运行重要的服务，虽然：网关，注册表，配置，Auth服务和账户服务。

在你开始以前

• 安装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具备在本地构建映像的额外可能性，并公开全部容器端口以方便开发。

重要端口

小结

全部Spring Boot应用程序都须要运行Config Server进行启动。可是咱们能够同时启动全部容器，由于fail-fastSpring Boot属性和docker restart: always-compose选项。这意味着全部依赖的容器将尝试从新启动，直到Config Server启动并运行。

此外，在全部应用程序启动后，服务发现机制须要一些时间。任何服务都不可用于客户端发现，直到实例，Eureka服务器和客户端都在其本地缓存中具备相同的元数据，所以可能须要3个心跳。默认心跳周期为30秒。