分享一下我的读书笔记

controller 中用到的 @getmapping、@postmapping、@putmapping、@deletemapping，都是spring 4.3 提供的新注解。它是一个组合注解，用于简化开发
⭐️ 作者也是时刻关注 spring 的新特性，自己却是在这本书中，才发下这个新特性，惭愧

Spring boot actuator : 提供了很多监控端点，可以使用 http://{ip}:{port}/{endpoint}的形式访问这些端点，从而了解应用程序的运行状况
⭐️actuator 只是 spring boot 自带的监控，大概了解，spring cloud 通常不会用这种监控



  ● spring-cloud-feign ：Netflix 开发的生命式、末班话的HTTP客户端、其灵感来自Retrofit、JAXRS-2.0，可以帮助我们更加便捷、优雅地调用HTTP API
  ● @FeignClient 注解中的value 可以是一个任意的客户端名称
  ● 修改启动类，为其添加@EnableFeignClients 注解
  ● 多参数的URL可以使用Map来构建
⭐️spring-cloud-feign 为消费者提供优雅的API调用工具

  ● spring-cloud-hystrix：Netflix 开源的一个延迟和容错库，用于隔离访问远程系统，服务或者第三方库，防止级联失败，从而提升系统的可用性和容错性
  ● 在启动类上添加注解@EnableCiruitBreaker && @EnableHystrix，从而为项目启用短路器支持
  ● spring cloud 默认为 feign 整合了 hystrix
  ● 使用 turbine 聚合监控数据，监控多个微服务，具体参考：https://github.com/Netfix/Turbine
⭐️断路器是为请求方法提供请求超时时间，失败回调本地方法提供默认值的方式来增加应用的可靠性，这种设计思想和java 8 的 optional<T> 类很类似

spring-cloud-zuul 是Netflx开源的微服务网关，
为什么要使用微服务网关？
  ● 因为不同的服务一般会有不同的网络地址，而外部的客户端（例如手机APP）可能需要调用多个服务的接口才能完成一个业务需求
  ● 如果让客户直接的与各个微服务通信，会有以下的问题：
  ● 客户端会多次请求不同的微服务，增加客户端的复杂性
  ● 存在跨域请求，在一定场景下处理相对复杂
  ● 认证复杂，每个服务都需要独立认证
  ● 难以重构，随着项目的迭代，可能需要重新划分微服务，如果客户端直接与服务通信，那么重构将很难实施
以上的问题都可以通过 spring-cloud-zuul 既微服务网关解决，微服务网关是介于客户端和服务端之间的中间层
⭐️总体来说，就是减少了分布式系统架构的复杂性，聚合所有一个请求，分发到每个微服务，再聚合数据，返回请求数据

zuul 的高可用，既 api 网关集群实现起来非常简单，只需将多个 zuul 节点注册到 eureka server上，就可实现 zuul 高可用，当 Zuul 客户端也注册到 eureka server 上时，只需部署多个 Zuul 节点即可实现其高可用
⭐相对来说，使用 spring-cloud-zuul 帮我们实现了，非常简单的 api 网关集群

zuul 聚合微服务数据，假如用户在APP上请求首页，首页内容会包含多个微服务的内容，如果使用手机直接请求各个微服务（即使使用 Zuul 进行转发），那么网络开销，流量耗费，耗费时长可能都无法令我们满意，那么对于这种场景可以使用 Zuul 聚合微服务请求，手机只发送一个请求给 zuul ，由 zuul 请求用户微服务并组织好数据给手机APP
⭐️ zuul 的实现方法实际上是在 zuul 内部声明对象和实现、请求路径，然后在实现类中调用相关的微服务，将微服务的返回接口组装在MAP中，返回给客户端，使用zuul 聚合微服务数据还兼容每个微服务的 Hystrix 容错机制

spring-cloud-config 为分布式系统外部化配置提供了服务器端和客户端的支持，各个微服务在启动时候，会请求config server 获取所需要的配置属性
为什么需要 spring-cloud-config 统一管理微服务配置？
  ● 一个微服务架构的应用系统可能会包含成百上千个微服务，因此集中管理配置是非常有必要的
  ● 不同环境不同配置，例如，数据源配置在不同的环境（开发、测试、预发布、生产）中是不同的
  ● 运行期间可动态调整，例如，可根据各个微服务的负载情况，动态调整数据源连接池大小或熔断阈值，并且在调整配置时不停止微服务
  ● 配置修改后可自动更新，如配置内容发生变化，微服务能够自动更新配置
⭐spring-cloud-config 配置中心的诞生也是为了解决=分布式架构所产生的复杂性，集中管理所有微服务的配置信息，可以动态加载，部署在远程的Git仓库中

spring-cloud-bus 是轻量级的消息代理，连接分布式系统的节点，通过消息传递机制，可以使用 spring cloud bus 实现 spring-cloud-config 配置自动刷新，
⭐️ 消息事件机制的简化版（MQ），具体还能在哪些场景使用，还不是很清楚

spring-cloud-sleuth 为 spring-cloud 提供了分布式的跟踪的解决方案，它大量的借用了google， dapper，twitter，zipkin，apache htrace的设计
为什么使用分布式跟踪？
在分布式的系统架构中，网络常常很脆弱，同时，网络的资源也是有限的，我们知道，微服务之间通过网络进行通信。如果能够跟踪每个请求，了解请求经过哪些微服务（从而了解信息是如何在服务之间流动），请求耗费时间，网络延迟，业务逻辑耗时等等指标，那么就能更好的分析系统的瓶颈，解决系统的问题
⭐️根据我目前的理解，这套跟踪系统，应该就是一套微服务架构的分析系统，了解每个请求，耗时等等……






本书参考资料：
官方文档搭建高可用的 GitLab : https://about.gitlab.com/hignavailability/
搭建高可用 RabbitMQ : https://www.rabbitmq.com/ha.html
ELK是一款非常流行的日志分析系统，搭建比较简单，可以参考官方文档 https://www.elastic.co/guide/index.html 自行安装