最近了解了一下Spring-cloud微服务架构，主要是对《Spring+Cloud与Docker微服务架构实战》的keypoint进行记录，方便以后查看
- Spring Cloud技术储备：Java+ Spring Boot+ Maven/Gradle(项目管理与构建工具)
- 使用微服务构建的是分布式系统，微服务之间通过网络进行通信，使用服务提供者/服务消费者描述微服务间调用关系
- 服务提供者：服务的被调用方
- 服务消费者：服务的调用方
- Maven项目中pom.xml中：
- 引入spring boot的依赖，引入spring cloud的依赖，添加spring-boot的maven插件
- groupid和artifactId被统称为“坐标”是为了保证项目唯一性而提出的；GroupID 是项目组织唯一的标识符，实际对应JAVA的包的结构，是main目录里java的目录结构；ArtifactID是项目的唯一的标识符，实际对应项目的名称，就是项目根目录的名称。
- 在类上使用@SpringBootApplication生命这是一个SpringBoot项目
- 传统Web开发中，常使用properties格式文件作为配置文件，Spring Boot及Spring Cloud支持使用properties/yml格式文件作为配置文件，yml(YAML:yet another markup language)和properties格式文件可互相转换，前者结构更清晰，可读性可维护性更强，但有严格的缩进
- 使用RestTemplate调用用户微服务中的RESTful API，IP和端口可以硬编码在代码中，也可以提取到配置文件中，存在的问题：
- 适用场景有限：e.g.服务提供者IP和端口发生变化，需要修改服务消费者的配置并重新发布（不可取）
- 无法动态伸缩：每个微服务一般会部署多个实例，实现容灾和负载均衡，系统需要具备自动伸缩能力，硬编码无法实现
- 微服务注册和发现：
- 服务发现组件：服务消费者需要一个强大的服务发现机制，获取服务提供者的网络信息，同时服务提供者信息变化时，服务消费者也无需修改配置文件
- 各个微服务启动时，将自己的网络地址等信息注册到服务发现组件中，服务发现组件会存储这些信息
- 服务消费者可从服务发现组件查询服务提供者的网络地址，并使用改地址调用服务提供者的接口
- 各个微服务与服务发现组件使用一定机制（e.g.心跳）通信，服务发现组件如长时间无法与某位服务实例通信，会注销该实例
- 微服务网络地址发生变更（e.g.实例增减/IP端口发生变化）时，会重新注册到服务发现组件，服务消费者无需人工修改提供者的网络地址
- Eureka，Cousul,Zookeeper等：Spring Cloud提供的多种服务发现组件
- Ribbon:负载均衡器，控制HTTP和TCP客户端的行为，为Ribbon配置服务提供者的地址列表后，Ribbon就可以基于某种负载均衡算法，自动帮助服务消费者去请求，Ribbon默认为我们提供很多的负载均衡算法，e.g.轮询，随机...也可为Ribbon实现自定义的负载均衡算法
- 在Spring Cloud中，当Ribbon和Eureka配合使用时，Ribbon可自动从Eureka Server获取服务提供者地址列表，并基于负载均衡算法，请求其中一个服务提供者实例
- 脱离Eureka使用Ribbon，对于一些遗留的微服务，可能并未注册到Eureka Server上，甚至根本不是使用SpringCloud开发的。
- Feign：实现声明式REST API调用
- 使用RestTemplate实现REST API调用，使用拼接字符串构造URL，而URL往往有多个参数，这种构造方式很低效
- 使用Feign，可以更简洁，优雅调用HTTP API，在Spring Cloud中使用Feign，只需添加Feign依赖，创建一个接口，并在接口上添加一些注解，代码就完成了，Feign支持自定义配置...
- Hystrix：实现微服务容错
- e.g. 某电商网站在黑色星期五发生过载，过多的并发请求，导致用户支付请求延迟很久没有响应，等待很长时间后最终失败，支付失败又导致用户重新刷新页面并在此尝试支付，进一步增加服务器负载，最终整个系统崩溃了——>雪崩效应，描述服务提供者不可用导致服务消费者不可用，并将不可用逐渐放大的过程——>使用容错机制来避免，具体要实现以下两点：
- 为网络请求设置超时
- 使用断路器模式
- Hystrix实现了超时机制和断路器模式的工具类库
- Turbine：聚合Hystrix监控数据的工具，让集群的监控更加方便
- e.g. 某电商网站在黑色星期五发生过载，过多的并发请求，导致用户支付请求延迟很久没有响应，等待很长时间后最终失败，支付失败又导致用户重新刷新页面并在此尝试支付，进一步增加服务器负载，最终整个系统崩溃了——>雪崩效应，描述服务提供者不可用导致服务消费者不可用，并将不可用逐渐放大的过程——>使用容错机制来避免，具体要实现以下两点：
- Zuul：用于构建微服务网关
- 不同微服务有不同网络地址，外部客户端（e.g. 手机App）可能需要调用多个服务的接口才能完成一个业务需求
- 让客户端直接与各个微服务通信会存在很多问题，通过借助微服务网关可以解决，它位于客户端和服务端之间的中间层，所有的外部请求会先经过微服务网关
- Spring Cloud Config：用于统一管理微服务配置，为分布式系统外部化配置提供了服务器端和客户端支持
- 传统单体应用，常使用配置文件管理所有配置，e.g.一个Spring Boot开发的单体应用将配置内容反正yml文件中，然而在微服务架构中，微服务的配置管理有以下需求：
- 集中管理配置，一个使用微服务架构的应用系统可能会包含成百上千个微服务
- 不同环境，不同配置，e,g,数据源配置
- 运行期间可动态调整
- 配置修改后自动更新
- Spring Cloud Sleuth: 实现微服务跟踪
