一·微服务架构的组件
服务注册中心：注册系统中所有服务的地方
服务注册：服务提供方将自己调用地址到服务注册中心，让服务调用方能够方便地找到自己
服务发现：服务调用方从服务注册中心找到自己需要调用的服务的地址
负载均衡：服务提供方一般以多实例的形式提供服务，使用负载均衡能够让服务调用方连接到合适的服务节点。
服务容错：通过断路器（也称熔断器）等一系列的服务保护机制，保证服务调用者在调用异常服务时快速地返回结果，避免大量的同步等待。
服务网关：也称API网关，是服务调用的唯一入口，可以在这个组件中实现用户鉴权、动态路由、灰度发布、负载限流等功能。
分布式配置中心：将本地化的配置信息注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
健康检查
日志处理
二·Spring Boot的工作机制
Spring Boot 的核心注解：@SpringBootApplication
是由@SpringBootConfiguration
@EnableAutoConfiguration
@ComponentScan 组成的 可以由这三个注解替换@SpringBootApplication这一注解
在@SpringBootApplication的源码中可以看出是由这三个注解组成的，这三个注解都有各自的作用
@SpringBootConfiguration 表示其标注的类是IoC容器的配置类
@EnableAutoConfiguration 用于将所有的符合自动配置的Bean加载到当前Spring Boot创建并使用的IoC容器中
@ComponentScan 用于扫描和加载符合条件的组件或Bean，并将Bean加载到ioc容器中
main方法的执行流程：
1 创建SpringApplication对象
2 调用实例的run()方法
执行流程：
spring boot整合了多个组件 redis、activeMQ等等，直接在pom.xml中配置相应的依赖就可以。
三·Spring Cloud
服务发现：用于实现各个微服务实例的自动化注册与发现。spring cloud使用Eureka来实现服务的发现功能。
Eureka:主要用于达到负载均衡和中间层服务故障转移的目的（失效转移）。
Eureka的服务发现包含两大组件：服务端发现组件也叫服务注册中心，主要提供了服务的注册功能(Eureka Server)和客户端发现组件（Eureka Client），主要用于处理服务的注册与发现。
Eureka的服务发现机制如下图所示
Eureka移除服务节点的条件：如果连续三次心跳都不能发现服务，那么Eureka就会将这个服务节点从服务注册表中移除。心跳默认时间为30s。
与此同时，客户端发现组件还会从服务端查询当前注册的服务信息并缓存到本地，即使Eureka Server出现了问题，客户端组件也可以通过缓存中的信息调用服务节点的服务。各个服务之间会通过注册中心的注册信息以Rest方式来实现调用，并且可以直接通过服务名进行调用。
Eureka的服务发现机制包含了3个角色：服务注册中心、服务提供者和服务消费者，三个角色之间的关系如图所示：
服务提供者可以是spring boot应用，也可以是其他技术平台遵循Eureka通信机制的应用，应用在运行时会自动的将自己提供的服务注册到Eureka Server以提供其他应用的发现。
服务消费者就是需要服务的应用，该服务在运行时会从服务注册中心获取服务列表，然后通过服务列表知道去何处调用其他服务。服务消费者会与服务注册中心保持心跳连接，一旦服务提供者的地址发生变化时，注册中心会通知服务消费者。
客户端负载均衡：
由 Spring cloud Ribbon 实现，Ribbon 在工作时主要分为两步：
首先选择Eureka Server 他会优先选择在同一个区域且负载较少的Server
第二步会根据用户指定的策略(如轮询、随机等)从Server取到的服务注册列表中选择一个地址。
服务容错保护 Spring cloud Hystris
分布式架构的熔断器相当于我们生活中的空气开关，当电流发生短路的时候，空气开关会立刻断开电流。
在微服务架构中，通常存在多个服务层调用的情况，如果基础服务出现故障可能会发生级联传递，导致整个服务链上的服务不可用。
图中A为服务提供者，B为A的服务服务调用者，C和D是B的服务调用者。随着时间的推移，当服务A不可用的时候，会引起服务B的不可引用，进而影响服务C和D对于服务B的引用这一连锁反应。
熔断器可以解决这个问题，也就是Spring cloud Hystris这一组件。它是用来实现断路器、线程隔离等服务保护功能的。
熔断器是可以实现弹性容错的，在一定条件下他能够自动打开或关闭，其使用时主要有三种状态：
断路器的开关由关闭到打开的状态是通过当前服务健康状况（服务的健康状况=请求失败数/请求总数）和设定阈值（默认为10秒内的20次故障）比较决定的。当断路器开关关闭时，请求被允许通过断路器，如果当前健康状况高于设定阈值，开关继续保持关闭；如果当前健康状况低于设定阈值，开关则切换为打开状态。当断路器开关打开时，请求被禁止通过；如果设置了fallback方法，则会进入fallback的流程。当断路器开关处于打开状态，经过一段时间后，断路器会自动进入半开状态，这时断路器只允许一个请求通过；当该请求调用成功时，断路器恢复到关闭状态；若该请求失败，断路器继续保持打开状态，接下来的请求会被禁止通过。
Spring Cloud Hystrix能保证服务调用者在调用异常服务时快速地返回结果，避免大量的同步等待，这是通过HystrixCommand的fallback方法实现的。虽然A服务仍然不可用，但采用fallback的方式可以给用户一个友好的提示结果，这样就避免了其他服务的崩溃问题。
@HystrixCommand 注解来指定回调方法 该方法是通过其属性fallbackMethod属性值来指定的。回调方法的的参数类型以及返回值必须要和原方法保持一致。
/**
* 用户控制器类
*/
@RestController
public class UserController {
@Autowired
private RestTemplate restTemplate;
/**
* 查找与用户相关的订单
*/
@GetMapping("/findOrdersByUser/{id}")
@HystrixCommand(fallbackMethod = "fallbackInfo")
public String findOrdersByUser(@PathVariable String id) {
return this.restTemplate.getForObject("http://microservice-eureka-order/order/" +
id,String.class);
}
/**
* 返回信息方法
*/
public String fallbackInfo(@PathVariable String id){
return "服务不可用，请稍后再试！";
}
}
Hystris Dashboard：能够对服务进行实时监控。要想实时地对服务进行监控，需要在项目中添加相关的依赖：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
API网关：
微服务基础架构：
集群包含ServiceA 和ServiceB两种服务，他们会向Eureka Server注册和订阅服务，Open Service是一个人对外的RESTful API服务，客户端会通过负载均衡技术，如Ngnix，实现对Open Servise的调用，同时服务之间也会通过Ribbon技术实现服务之间负载均衡的调用。但实际应用中，客户端与微服务进行直接交互还是存在着一些困难和限制的，主要体现在如下几个方面：
1 增加开发成本和维护成本
2 微服务重构困难
3 微服务协议限制 web socket协议(服务端推送技术) http协议 rpc协议(跨越应用层和传输层)
解决上述问题最好的办法就是采用API Gateway网关的方式。API Gateway是一个服务器，可以说是进入系统的唯一节点，他封装了内部系统的架构，并且提供可API给客户端。它还可以有其他功能，如授权、监控、负载均衡、缓存、请求分片和管理、静态相应处理。
当前架构图
API Gateway负责请求转发、合成和协议转换。所有来自客户端的请求都要先经过API Gateway，然后负载均衡这些请求到对应的微服务。API Gateway还可以在Web协议与内部使用的非Web协议间进行转换，如HTTP协议、WebSocket协议。
Ngnix 反向代理：正向代理最大的特点是客户端非常明确要访问的服务器地址 。 反向代理的客户端不知道要访问哪台服务器。主要用于服务器集群分布式部署的情况下，反向代理隐藏了服务器的信息。多个客户端给服务器发送的请求，nginx服务器接收到之后，按照一定的规则分发给了后端的业务处理服务器进行处理了。此时~请求的来源也就是客户端是明确的，但是请求具体由哪台服务器处理的并不明确了，nginx扮演的就是一个反向代理角色。
nginx支持的负载均衡调度算法方式如下：
weight轮询（默认）：接收到的请求按照顺序逐一分配到不同的后端服务器，即使在使用过程中，某一台后端服务器宕机，nginx会自动将该服务器剔除出队列，请求受理情况不会受到任何影响。 这种方式下，可以给不同的后端服务器设置一个权重值（weight），用于调整不同的服务器上请求的分配率；权重数据越大，被分配到请求的几率越大；该权重值，主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
ip_hash：每个请求按照发起客户端的ip的hash结果进行匹配，这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器，这也在一定程度上解决了集群部署环境下session共享的问题。
fair：智能调整调度算法，动态的根据后端服务器的请求处理到响应的时间进行均衡分配，响应时间短处理效率高的服务器分配到请求的概率高，响应时间长处理效率低的服务器分配到的请求少；结合了前两者的优点的一种调度算法。但是需要注意的是nginx默认不支持fair算法，如果要使用这种调度算法，请安装upstream_fair模块
url_hash：按照访问的url的hash结果分配请求，每个请求的url会指向后端固定的某个服务器，可以在nginx作为静态服务器的情况下提高缓存效率。同样要注意nginx默认不支持这种调度算法，要使用的话需要安装nginx的hash软件包。（摘自：原文：https://blog.csdn.net/tsummerb/article/details/79248015 ）
分布式配置管理：Spring Cloud Config
是Spring Cloud团队创建的一个全新的项目，该项目主要用来为分布式系统中的外部配置提供服务器和客户端支持。
服务器端(Config Server)：也被称之为分布式配置中心，它是一个独立的微服务应用，主要用于集中管理应用程序各个环境下的配置，默认使用git存储配置文件内容，也可以使用svn、本地文件存储。
客户端(Config Client):是Config Server的客户端，即微服务架构中的各个微服务应用。它们通过指定的配置中心(Config Server)来管理应用资源以及与业务相关的配置内容，并在启动时从配置中心获取和加载配置信息。
用户会先将配置文件推送到Git或SVN中，然后在微服务应用(Config Client)启动时，会从配置中心(Config Server)中获取配置信息，而配置中心会根据配置从从Git或SVN中获取相应的配置信息。
配置的资源文件按照如下格式命名：
/{application}/{profile}[/{lable}]
/{application}-{profile}.yml
/{lable}/{application}-{profile}.yml
/{application}-{profile}.properties
/{lable}/{application}-{profile}.properties 其中application表示应用名称，profile表示变化的文件，而lable是可选的，表示Git的分支，默认是master
pom.xml文件添加config的server依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-config-server</artifactId>
</dependency>
application.yml配置文件如下
spring:
application:
name: microservice-config-server #服务名
profiles:
active: native # 使用本地文件系统的存储方式来保存配置信息，一般来说使用git
server:
port: 8080
新建三个分别用于表示开发、预发布和测试的资源配置文件
·application-dev.yml中编写内容：clientParam: native-dev-1.0
·application-prod.yml中编写内容：clientParam: native-prod-1.0
·application-test.yml中编写内容：clientParam: native-test-1.0 其中 dev、 prod、test是表示可变化的文件profile（之后会用到）
在启动类上新增一个@EnableConfigServer注解来开启服务端功能、然后启动工程，在地址栏中输入localhost:8080/microservice-config-server/dev，其中地址中的dev会找到application-dev.yml文件，显示出应用名microservice-config-server、环境名dev，以及资源文件路径等等信息。也可以直接访问资源文件localhost:8080/application-dev.yml显示其中的信息。
然后创建客户端工程：
在客户端工程的pom.xml文件中新增两条依赖
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-config</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>
编写bootstrap.yml文件，在其中配置应用名称、服务中心地址、需要访问的文件和端口号信息。这个配置文件的名称必须为bootstrap.yml或bootstrap.properties，只有这样配置中心才能够正常加载，bootstrap.yml或bootstrap.properties必须要优先加载。
spring:
application:
name: microservice-config-client
cloud:
config:
profile: prod # 配置服务中的{profile}
uri: http://localhost:8080/ # 配置中心的地址
server:
port: 8081
创建启动类，在启动类上加上@RestController注解，然后启动工程，在浏览器中输入localhost:8081/clientParam
@SpringBootApplication
@RestController
public class Application {
@Value("${clientParam}")
private String clientParam;
@RequestMapping("/clientParam")
public String getParam(){
return this.clientParam;
}
@RequestMapping("/hello")
public String hello(){
return "hello world";
}
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
会将application-prod.yml中的内容native-prod-1.0显示出来
工作中我们一般采用的是git配置仓库
（1）在Git上创建microservice-study-config目录，并在目录中增加开发、预发布和测试的配置文件，分别编辑三个文件中的内容如下：
·application-dev.yml中编写内容：clientParam: git-dev-1.0
·application-prod.yml中编写内容：clientParam: git-prod-1.0
·application-test.yml中编写内容：clientParam: git-test-1.0
（2）修改服务端配置文件。将microservice-config-server工程的配置文件中本地文件存储方式的配置删除（或注释），并添加git的配置信息
spring:
application:
name: microservice-config-server
cloud:
config:
server:
git: # 使用git的方式
uri: https://github.com/993640191/microservice-study-config.git
server:
port: 8080
修改客户端配置文件。在microservice-config-client工程的配置文件中添加属性label，并将其属性值设置为master（label属性表示Git中的分支，其属性默认值为master）
启动工程，测试应用。分别启动Spring Cloud Config的服务端和客户端工程，通过访问地址http://localhost:8081/clientParam，发现已经可以获取Git中的配置信息了
流程：首先通过localhost:8081访问Spring cloud config客户端，然后根据客户端配置文件bootstrap.yml中的uri: http://localhost:8080/找到配置中心(服务端)，因为配置中心的server.port是8080。然后根据Spring cloud config服务端的配置文件application.yml中配置的uri，uri: https://github.com/993640191/microservice-study-config.git 去该git地址中找。根据地址栏的clientParam这一路由找到启动类中对应的方法 。然后根据客户端配置文件bootstrap.yml中的 profile: prod 这一条件找到git中的application-prod.yml文件，并获取到了我们在这个文件中定义的clientParam属性对应的值。