基于Spring Boot、Spring Cloud、Docker的微服务系统架构实践
由于最近公司业务需要，需要搭建基于Spring Cloud的微服务系统。遍访各大搜索引擎，发现国内资料少之又少，也难怪，国内Dubbo正统治着天下。但是，一个技术总有它的瓶颈，Dubbo也有它捉襟见肘的地方。所幸霸主Spring也推出了一整套微服务解决方案，各个子项目也巧妙地解决了分布式系统开发过程中的各种各样的问题。看了很多国内的资料，最早的几份文档也是互相借用，恐怕究竟是什么都说不清楚了。撸主在github上面发现几个很好的相关项目，就想翻译来看看。这篇其实是项目说明，但是里面很多知识点是百度找不到的，下面就来看看吧，想要部署来看看的可以去下载：
这个项目的名字叫：Piggy Metrics，一个供个人处理财务的解决方案。
简介
这是一款概念性的应用程序，基于Spring Boot，Spring Cloud和Docker 简单演示了微服务的架构模式，顺便说一句，它还有一个非常漂亮整洁的用户界面。下面是它的界面演示：
功能服务
PiggyMetrics被分解为三个核心微服务。这些服务都是围绕某些业务能力组织的可独立部署的应用程序。
账户服务
包含一般用户输入逻辑和验证：收入/费用项目，储蓄和帐户设置。
统计服务
对主要统计参数执行计算，并为每个帐户的时间序列。数据点包含基准货币和时间段的值。此数据用于跟踪帐户生命周期中的现金流动动态（尚未在UI中实现的花式图表）。
通知服务
存储用户联系信息和通知设置（如提醒和备份频率）。计划工作人员从其他服务收集所需的信息，并向订阅的客户发送电子邮件。
小结：
- 每个微服务都有自己的数据库，因此没有办法绕过API和直接访问数据库。
- 在这个项目中，使用MongoDB作为每个服务的主数据库。它是支持多种编程语言持久性架构（包括最适合服务需求的数据库类型）。
- Service-to-service的通信是相当简单的：各个微服务之间的通信只使用同步的REST API。在现实世界中通常的做法是使用交互风格的组合。例如，执行同步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：
application：
name：notification-service
cloud：
config：
uri：http：// config：8888
fail-fast：true
使用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- 用于浏览器。因此，我们还可以保护控制器免受外部访问，例如：
@PreAuthorize("#oauth2.hasScope('server')")
@RequestMapping(value = "accounts/{name}", method = RequestMethod.GET)
public List<DataPoint> getStatisticsByAccountName(@PathVariable String name) {
return statisticsService.findByAccountName(name);
}
API Gateway
可以看到，有三个核心服务，它们向客户端公开外部API。在现实世界的系统中，这个数字可以快速增长以及整个系统的复杂性。实际上，上百个服务可能涉及到渲染一个复杂的网页。
在理论上，客户端可以直接向每个微服务器发出请求。但是显然，这个选项有挑战和限制，如需要知道所有端点地址，分别执行每个信息的http请求，在客户端合并结果。另一个问题是非web友好的协议，可能在后端使用。
通常一个更好的方法是使用API网关。它是进入系统的单个入口点，用于通过将它们路由到适当的后端服务来处理请求，或者通过调用多个后端服务并聚合结果。此外，它可以用于身份验证，洞察，压力和金丝雀测试，服务迁移，静态响应处理，主动流量管理。
Netflix打开了这样一个边缘服务，现在使用Spring Cloud，我们可以使用一个@EnableZuulProxy注释启用它。在这个项目中，我使用Zuul来存储静态内容（ui应用程序），并将请求路由到适当的微服务。这是一个简单的基于前缀的路由配置Notification服务：
zuul：
routes：
notification-service：
path：/ notifications / **
serviceId：notification-service
stripPrefix：false
这意味着所有开始的请求/notifications都将路由到Notification服务。没有硬编码的地址，你可以看到。Zuul使用服务发现机制来定位通知服务实例，以及断路器和负载平衡器，如下所述。
Service discovery
另一个公知的架构模式是服务发现。它允许自动检测服务实例的网络位置，由于自动扩展，故障和升级，可能会动态分配地址。
服务发现的关键部分是注册表。我在这个项目中使用Netflix Eureka。当客户端负责确定可用服务实例（使用注册表服务器）和负载平衡请求的位置时，Eureka是客户端发现模式的一个很好的例子。
使用Spring Boot，您可以轻松地使用spring-cloud-starter-eureka-server依赖关系，@EnableEurekaServer注释和简单配置属性来构建Eureka注册表。
支持@EnableDiscoveryClient注释的客户端支持bootstrap.yml应用程序名称：
spring：
application：
name：notification-service
现在，在应用程序启动时，它将注册到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客户端，并具有合理的即用型默认配置。
以下是帐户服务的示例：
@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);
}
- 你需要的只是一个接口
- 你可以用@RequestMapping在Spring MVC控制器和Feign方法之间共享部分
- 上面的示例指定只需要的服务id -
- statistics-service，由于通过Eureka自动发现（但显然，您可以访问任何资源与特定的网址）
监视仪表板
在这个项目配置中，Hystrix的每个微服务通过Spring Cloud Bus（使用AMQP代理）将指标推送到Turbine。监控项目只是一个小的Spring启动应用程序与涡轮和Hystrix仪表板。
看下面如何让它运行。
让我们看看我们的系统在负载下的行为：帐户服务调用统计服务，它的响应具有不同的模仿延迟。响应超时阈值设置为1秒。
表现良好的系统。吞吐量约为22请求/秒。统计服务中的活动线程数较少。中位服务时间约为50 ms。
活动线程的数量在增加。我们可以看到紫色线程池拒绝的数量，因此约30-40％的错误，但电路仍然关闭。
半开状态：故障命令的比率大于50％，断路器启动。在睡眠窗口的时间后，下一个请求被允许通过。
100％的请求失败。电路现在永久打开。在睡眠时间后重试不会再次闭合电路，因为单个请求太慢。
日志分析
当尝试在分布式环境中识别问题时，集中式日志记录可能非常有用。Elasticsearch，Logstash和Kibana堆栈使您可以轻松搜索和分析您的日志，利用率和网络活动数据。我的其他项目中描述的即开即用 Docker配置。
安全
高级安全配置超出了此概念验证项目的范围。对于真实系统的更真实的模拟，考虑使用https，JCE密钥库加密微服务密码和配置服务器属性内容（有关详细信息，请参阅文档）。
基建自动化
部署微服务及其相互依赖性，比部署单片应用程序要复杂得多。拥有完全自动化的基础设施非常重要。我们可以通过持续交付方法实现以下优势：
- 随时释放软件的能力
- 任何构建可能最终都是发布
- 构建工件一次 - 根据需要部署
这里是一个简单的连续交付工作流，在这个项目中实现：
如何运行所有的东西？
记住，你要启动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具有在本地构建映像的额外可能性，并公开所有容器端口以方便开发。
重要端口
http://DOCKER-HOST:80 - Gateway http://DOCKER-HOST:8761 - Eureka Dashboard http://DOCKER-HOST:9000/hystrix - Hystrix Dashboard http://DOCKER-HOST:8989 - Turbine stream (source for the Hystrix Dashboard) http://DOCKER-HOST:15672 - RabbitMq management (default login/password: guest/guest)
小结
所有Spring Boot应用程序都需要运行Config Server进行启动。但是我们可以同时启动所有容器，因为fail-fastSpring Boot属性和docker restart: always-compose选项。这意味着所有依赖的容器将尝试重新启动，直到Config Server启动并运行。
此外，在所有应用程序启动后，服务发现机制需要一些时间。任何服务都不可用于客户端发现，直到实例，Eureka服务器和客户端都在其本地缓存中具有相同的元数据，因此可能需要3个心跳。默认心跳周期为30秒。
