时代各有不同，青春一脉相承。

SpringCloud的项目中bootstrap.yml配置文件与配置中心配置，在 SpringCloud 的项目中，我们常常会碰到另外一个配置文件 bootstrap.yml。这个配置文件主要是用于应用程序上下文的引导阶段，该配置文件的加载是在 application.yml 之前。在 SpringCloud 项目中，我们的配置常由配置中心进行统一管理，这就涉及到本地与远程配置文件的优先级问题。这里只说明遇到过的两种:SpringCloud Config和Nacos。

部署Seata的tc-server，首先我们要下载seata-server包，修改conf目录下的registry.conf文件，为了让tc服务的集群可以共享配置，我们选择了nacos作为统一配置中心。因此服务端配置文件seataServer.properties文件需要在nacos中配好。其中的数据库地址、用户名、密码都需要修改成你自己的数据库信息。tc服务在管理分布式事务时，需要记录事务相关数据到数据库中，你需要提前创建好这些表。

为了保障金融系统的高可用，分布式事务服务必须达到 99.99% 的可用率。分布式事务使用了蚂蚁金服的三地五中心架构部署，在每个机房都独立部署分布式事务服务，分布式事务服务是无状态的，而底层数据库副本在各机房间也是双向同步，这样业务流量从一个机房切到另外一个机房，分布式事务服务不会对业务有任何影响，从而保证了分布式事务服务的高可用。

Seata会有 4 种分布式事务解决方案，分别是AT模式、TCC模式、Saga模式和XA模式。AT模式是一种无侵入的分布式事务解决方案。在AT模式下，用户只需关注自己的业务SQL，用户的 业务SQL 作为一阶段，Seata框架会自动生成事务的二阶段提交和回滚操作。TCC模式需要用户根据自己的业务场景实现 Try、Confirm和Cancel三个操作；事务发起方在一阶段 执行Try方式，在二阶段提交执行Confirm方法，二阶段回滚执行Cancel方法。Saga模式是Seata提供的长事务解决方案。XA模式是

从RabbitMQ 3.8版本开始，引入了新的仲裁队列，他具备与镜像队里类似的功能，但使用更加方便。在任意控制台添加一个队列，一定要选择队列类型为Quorum类型。可以看到，仲裁队列的+ 2字样。代表这个队列有2个镜像节点。因为仲裁队列默认的镜像数为5。如果你的集群有7个节点，那么镜像数肯定是5；而我们集群只有3个节点，因此镜像数量就是3。

RabbitMQ集群的普通模式中，一旦创建队列的主机宕机，队列就会不可用。不具备高可用能力。如果要解决这个问题，必须使用官方提供的镜像集群方案。默认情况下，队列只保存在创建该队列的节点上。而镜像模式下，创建队列的节点被称为该队列的主节点，队列还会拷贝到集群中的其它节点，也叫做该队列的镜像节点。但是，不同队列可以在集群中的任意节点上创建，因此不同队列的主节点可以不同。甚至，一个队列的主节点可能是另一个队列的镜像节点。用户发送给队列的一切请求，例如发送消息、消息回执默认都会在主节点完成，如果是从节点接收到请求，

在RabbitMQ的官方文档中，讲述了两种集群的配置方式：普通模式、镜像模式。普通模式：普通模式集群不进行数据同步，每个MQ都有自己的队列、数据信息（其它元数据信息如交换机等会同步）。例如我们有2个MQ：mq1，和mq2，如果你的消息在mq1，而你连接到了mq2，那么mq2会去mq1拉取消息，然后返回给你。如果mq1宕机，消息就会丢失。RabbitMQ底层依赖于Erlang，而Erlang虚拟机就是一个面向分布式的语言，默认就支持集群模式。集群模式中的每个RabbitMQ节点使用cookie来确定它们是否被

分片集群特征：集群中有多个master，每个master保存不同数据；每个master都可以有多个slave节点；master之间通过ping监测彼此健康状态；客户端请求可以访问集群任意节点，最终都会被转发到正确节点。如何将同一类数据固定的保存在同一个Redis实例？这一类数据使用相同的有效部分，例如key都以{typeId}为前缀。

Redis提供了哨兵（Sentinel）机制来实现主从集群的自动故障恢复。哨兵的作用如下：监控：Sentinel会不断检查您的master和slave是否按预期工作。自动故障恢复：如果master故障，Sentinel会将一个slave提升为master。当故障实例恢复后也以新的master为主。通知：Sentinel充当Redis客户端的服务发现来源，当集群发生故障转移时，会将最新信息推送给Redis的客户端。

单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。全量同步：master将完整内存数据生成RDB，发送RDB到slave。后续命令则记录在repl_baklog，逐个发送给slave。增量同步：slave提交自己的offset到master，master获取repl_baklog中从offset之后的命令给slave。

Redis有两种持久化方案：RDB持久化、AOF持久化。RDB全称Redis Database Backup file（Redis数据备份文件），也被叫做Redis数据快照。简单来说就是把内存中的所有数据都记录到磁盘中。当Redis实例故障重启后，从磁盘读取快照文件，恢复数据。快照文件称为RDB文件，默认是保存在当前运行目录。AOF全称为Append Only File（追加文件）。Redis处理的每一个写命令都会记录在AOF文件，可以看做是命令日志文件。

现在，sentinel的所有规则都是内存存储，重启后所有规则都会丢失。在生产环境下，我们必须确保这些规则的持久化，避免丢失。规则是否能持久化，取决于规则管理模式，sentinel支持三种规则管理模式：原始模式：Sentinel的默认模式，将规则保存在内存，重启服务会丢失。pull模式：控制台将配置的规则推送到Sentinel客户端，而客户端会将配置规则保存在本地文件或数据库中。以后会定时去本地文件或数据库中查询，更新本地规则。push模式：控制台将配置规则推送到远程配置中心，例如Nacos。Sentinel

授权规则可以对请求方来源做判断和控制。授权规则可以对调用方的来源做控制，有白名单和黑名单两种方式。白名单：来源（origin）在白名单内的调用者允许访问；黑名单：来源（origin）在黑名单内的调用者不允许访问。默认情况下，发生限流、降级、授权拦截时，都会抛出异常到调用方。异常结果都是flow limmiting（限流）。这样不够友好，无法得知是限流还是降级还是授权拦截。而如果要自定义异常时的返回结果，需要实现BlockExceptionHandler接口。

SpringCloud中，微服务调用都是通过Feign来实现的，因此做客户端保护必须整合Feign和Sentinel。业务失败后，不能直接报错，而应该返回用户一个友好提示或者默认结果，这个就是失败降级逻辑。Sentinel支持的雪崩解决方案：线程隔离（仓壁模式）、降级熔断。线程隔离有两种方式实现：线程池隔离、信号量隔离（Sentinel默认采用）。熔断降级是解决雪崩问题的重要手段。其思路是由断路器统计服务调用的异常比例、慢请求比例，如果超出阈值则会熔断该服务。即拦截访问该服务的一切请求；而当服务恢复时，断路

雪崩问题虽然有四种方案，但是限流是避免服务因突发的流量而发生故障，是对微服务雪崩问题的预防。我们先介绍这种模式。当请求进入微服务时，首先会访问DispatcherServlet，然后进入Controller、Service、Mapper，这样的一个调用链就叫做簇点链路。簇点链路中被监控的每一个接口就是一个资源。默认情况下sentinel会监控SpringMVC的每一个端点（Endpoint，也就是controller中的方法），因此SpringMVC的每一个端点（Endpoint）就是调用链路中的一个资源。

Sentinel是阿里巴巴开源的一款微服务流量控制组件。Sentinel具有以下特征：丰富的应用场景：Sentinel承接了阿里巴巴近 10 年的双十一大促流量的核心场景，例如秒杀（即突发流量控制在系统容量可以承受的范围）、消息削峰填谷、集群流量控制、实时熔断下游不可用应用等。完备的实时监控：Sentinel同时提供实时的监控功能。广泛的开源生态：Sentinel提供开箱即用的与其它开源框架/库的整合模块。完善的 SPI 扩展点：Sentinel提供简单易用、完善的SPI扩展接口。

什么是雪崩问题？微服务之间相互调用，因为调用链中的一个服务故障，引起整个链路都无法访问的情况。限流是对服务的保护，避免因瞬间高并发流量而导致服务故障，进而避免雪崩。是一种预防措施。超时处理、线程隔离、降级熔断是在部分服务故障时，将故障控制在一定范围，避免雪崩。是一种补救措施。

单机的elasticsearch做数据存储，必然面临两个问题：海量数据存储问题、单点故障问题。海量数据存储问题：将索引库从逻辑上拆分为N个分片（shard），存储到多个节点。单点故障问题：将分片数据在不同节点备份（replica）。集群（cluster）：一组拥有共同的cluster name 的 节点。节点（node) ：集群中的一个 Elasticearch 实例。分片（shard）：索引可以被拆分为不同的部分进行存储，称为分片。在集群环境下，一个索引的不同分片可以拆分到不同的节点中。

elasticsearch中的酒店数据来自于mysql数据库，因此mysql数据发生改变时，elasticsearch也必须跟着改变，这个就是elasticsearch与mysql之间的数据同步。常见的数据同步方案有三种：方式一：同步调用，优点：实现简单，粗暴；缺点：业务耦合度高。方式二：异步通知，优点：低耦合，实现难度一般，缺点：依赖mq的可靠性。方式三：监听binlog，优点：完全解除服务间耦合，缺点：开启binlog增加数据库负担、实现复杂度高。

ElasticSearch之自动补全，当用户在搜索框输入字符时，我们应该提示出与该字符有关的搜索项，这种根据用户输入的字母，提示完整词条的功能，就是自动补全了。因为需要根据拼音字母来推断，因此要用到拼音分词功能。要实现根据字母做补全，就必须对文档按照拼音分词。在GitHub上恰好有elasticsearch的拼音分词插件。

聚合（aggregations） 可以让我们极其方便的实现对数据的统计、分析、运算。实现这些统计功能的比数据库的sql要方便的多，而且查询速度非常快，可以实现近实时搜索效果。聚合常见的有三类：桶（Bucket） 聚合：用来对文档做分组；度量（Metric） 聚合：用以计算一些值，比如：最大值、最小值、平均值等；管道（pipeline） 聚合：其它聚合的结果为基础做聚合。注意： 参加聚合的字段必须是keyword、日期、数值、布尔类型。

文档的查询同样适用RestHighLevelClient对象，基本步骤包括：1）准备Request对象2）准备请求参数3）发起请求4）解析响应。查询的基本步骤是：创建SearchRequest对象准备Request.source()，也就是DSL。① QueryBuilders来构建查询条件② 传入Request.source()的query()方法发送请求，得到结果解析结果（参考JSON结果，从外到内，逐层解析）

ElasticSearch搜索的结果可以按照用户指定的方式去处理或展示。elasticsearch默认是根据相关度算分（_score）来排序，但是也支持自定义方式对搜索结果排序。可以排序字段类型有：keyword类型、数值类型、地理坐标类型、日期类型等。elasticsearch默认情况下只返回top 10的数据。而如果要查询更多数据就需要修改分页参数了。高亮显示的实现分为两步：给文档中的所有关键字都添加一个标签，例如标签；页面给标签编写CSS样式。

elasticsearch的查询依然是基于JSON风格的DSL来实现的。Elasticsearch提供了基于JSON的DSL（Domain Specific Language）来定义查询。常见的查询类型包括：查询所有：查询出所有数据，一般测试用。全文检索（full text）查询：利用分词器对用户输入内容分词，然后去倒排索引库中匹配。精确查询：根据精确词条值查找数据，一般是查找keyword、数值、日期、boolean等类型字段。地理（geo）查询：根据经纬度查询。复合（compound）查询：复合查询可以

文档操作的基本步骤：初始化RestHighLevelClient创建XxxRequest。XXX是Index、Get、Update、Delete、Bulk准备参数（Index、Update、Bulk时需要）发送请求。调用RestHighLevelClient#.xxx()方法，xxx是index、get、update、delete、bulk解析结果（Get时需要）

ES官方提供了各种不同语言的客户端，用来操作ES。这些客户端的本质就是组装DSL语句，通过http请求发送给ES。JavaRestClient操作elasticsearch的流程基本类似。核心是client.indices()方法来获取索引库的操作对象。索引库操作的基本步骤：初始化RestHighLevelClient创建XxxIndexRequest。XXX是Create、Get、Delete准备DSL（Create时需要，其它是无参）发送请求。调用RestHighLevelClient#indic

文档操作有哪些？POST /{索引库名}/_doc/文档id { json文档 }GET /{索引库名}/_doc/文档idDELETE /{索引库名}/_doc/文档id修改文档：PUT /{索引库名}/_doc/文档id { json文档 }POST /{索引库名}/_update/文档id { "doc": {字段}}

ElasticSearch索引库就类似数据库表，mapping映射就类似表的结构。我们要向ElasticSearch中存储数据，必须先创建“库”和“表”。这里我们统一使用Kibana编写DSL的方式来演示。索引库操作有哪些？创建索引库：PUT /索引库名；查询索引库：GET /索引库名；删除索引库：DELETE /索引库名；添加字段：PUT /索引库名/_mapping

ElasticSearch是一款非常强大的开源搜索引擎，具备非常多强大功能，可以帮助我们从海量数据中快速找到需要的内容。ElasticSearch结合kibana、Logstash、Beats，也就是elastic stack（ELK）。被广泛应用在日志数据分析、实时监控等领域。而ElasticSearch是elastic stack的核心，负责存储、搜索、分析数据。ElasticSearch底层是基于lucene来实现的。

Spring AMQP是基于RabbitMQ封装的一套模板，并且还利用SpringBoot对其实现了自动装配，使用起来非常方便。Spring AMQP提供了三个功能：自动声明队列、交换机及其绑定关系；基于注解的监听器模式，异步接收消息；封装了RabbitTemplate工具，用于发送消息。

微服务间通讯有同步和异步两种方式：同步通讯：就像打电话，需要实时响应。异步通讯：就像发邮件，不需要马上回复。MQ，中文是消息队列（MessageQueue），字面来看就是存放消息的队列。也就是事件驱动架构中的Broker。比较常见的MQ实现：ActiveMQ、RabbitMQ、RocketMQ、Kafka。RabbitMQ中的一些角色：publisher：生产者；consumer：消费者；exchange：交换机，负责消息路由；queue：队列，存储消息；virtualHost：虚拟主机，隔离不同租户的ex

Spring Cloud Gateway是Spring Cloud的一个全新项目，该项目是基于Spring 5.0，Spring Boot 2.0和Project Reactor等响应式编程和事件流技术开发的网关，它旨在为微服务架构提供一种简单有效的统一的 API 路由管理方式。Gateway网关是我们服务的守门神，所有微服务的统一入口。网关的核心功能特性：请求路由、权限控制、限流。

Feign是一个声明式的http客户端，其作用就是帮助我们优雅的实现http请求的发送，解决上面提到的问题。使用Feign的步骤：① 引入依赖② 添加@EnableFeignClients注解③ 编写FeignClient接口④ 使用FeignClient中定义的方法代替RestTemplate

Nacos除了可以做注册中心，同样可以做配置管理来使用。当微服务部署的实例越来越多，达到数十、数百时，逐个修改微服务配置就会让人抓狂，而且很容易出错。我们需要一种统一配置管理方案，可以集中管理所有实例的配置。Nacos一方面可以将配置集中管理，另一方可以在配置变更时，及时通知微服务，实现配置的热更新。

国内公司一般都推崇阿里巴巴的技术，比如注册中心，SpringCloudAlibaba也推出了一个名为Nacos的注册中心。Nacos是阿里巴巴的产品，现在是SpringCloud中的一个组件。相比Eureka功能更加丰富，在国内受欢迎程度较高。Nacos是SpringCloudAlibaba的组件，而SpringCloudAlibaba也遵循SpringCloud中定义的服务注册、服务发现规范。因此使用Nacos和使用Eureka对于微服务来说，并没有太大区别。主要差异在于：依赖不同、服务地址不同。

SpringCloud底层其实是利用了一个名为Ribbon的组件，来实现负载均衡功能的。SpringCloudRibbon的底层采用了一个拦截器，拦截了RestTemplate发出的请求，对地址做了修改。负载均衡的规则都定义在IRule接口中，而IRule有很多不同的实现类，默认的实现就是ZoneAvoidanceRule，是一种轮询方案。一般用默认的负载均衡规则，不做修改。Ribbon默认是采用懒加载，即第一次访问时才会去创建LoadBalanceClient，请求时间会很长。

order-service在发起远程调用的时候，该如何得知user-service实例的ip地址和端口？有多个user-service实例地址，order-service调用时该如何选择？order-service如何得知某个user-service实例是否依然健康，是不是已经宕机？需要利用SpringCloud中的注册中心来解决，其中最广为人知的注册中心就是Eureka。一个微服务，既可以是服务提供者，又可以是服务消费者，因此eureka将服务注册、服务发现等功能统一封装到了eureka-client端。

SpringCloud是目前国内使用最广泛的微服务框架。微服务的架构特征：单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责。自治：团队独立、技术独立、数据独立，独立部署和交付。面向服务：服务提供统一标准的接口，与语言和技术无关。隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题。微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。因此，可以认为微服务是一种经过良好架构设计的分布式架构方案 。