一、架构设计相关
0. 什么是微服务？什么是分布式系统？什么是集群？
微服务： 构建分布式系统的一种架构方式， 核心思路是：去中心化。
分布式系统： 一件事情，多系统协同完成。
集群： 多机器做同一件事情。比如在淘宝买东西，会有一个商品展示的系统，看到合适的商品了就会下单这是会有一个订单系统，下单完成了就进入发货阶段，这个时候就会有一个物流系统，买东西就形成了一个分布式系统，而每个系统又由多个微服务组成，所以微服务是构建分布式系统的一种架构方式，当买东西的人多了，系统就会出现慢的现象，这个时候就需要把每个系统里面的微服务多部署几台机器来承载更多的请求，这样就形成了集群。
1. RPC和RPC框架
RPC：远程过程调用 ，实现远程过程调用的方式有很多种，Dubbo，Rmi，Hessian等等；RPC的核心过程包括了客户端和服务端的通讯协议，寻址，数据序列化/反序列化；
RPC框架：实现远程过程调用方式的组件 ，不需要开发人员自己去定义通讯协议，去实现序列化的细节工作
常见RPC框架有 thrift，gRpc，dubbo，motan
2. 序列化方式及作用
序列化： 将java对象或者其他内存中的数据，转换为一种可以在网络上传输 和可以在磁盘上存储 的格式（流）的数据。反序列化： 将可以在网络上传输 和可以在磁盘上存储 的格式（流）的数据转为java对象或者内存中其他形式的数据。序列化方式： json，jdk serializable , Hessian，Dubbo, Protobuf 。序列化的作用：压缩、持久化存储、跨网络传输。
3. 分布式系统中事务的处理
3.1 事务相关必了解的概念：
3.1.1 ACID （Atomic原子性，Consistency一致性，Isolation隔离性，Durability持久性）
A是原子性(atomic)：事务中包含的各项操作必须全部成功执行或者全部不执行。 任何一项操作失败，将导致整个事务失败，其他已经执行的任务所做的数据操作都将被撤销，只有所有的操作全部成功，整个事务才算是成功完成。
C是一致性(consistent)：保证了当事务结束后，系统状态是一致的。 那么什么是一致的系统状态？例如，如果银行始终遵循着"银行账号必须保持正态平衡"的原则，那么银行系统的状态就是一致的。上面的转账例子中，在取钱的过程中，账户会出现负态平衡，在事务结束之后，系统又回到一致的状态。这样，系统的状态对于客户来说，始终是一致的。
I是隔离性(isolated)：并发执行的事务，彼此无法看到对方的中间状态。 保证了并发执行的事务顺序执行，而不会导致系统状态不一致。
D是持久性(durable)：保证了事务完成后所作的改动，即使是发生灾难性的失败都会被持久化。 可恢复性资源保存了一份事务日志，如果资源发生故障，可以通过日志来将数据重建起来
3.1.2 CAP理论 （一致性Consistency，可用性Availability，分区容错性Partition tolerance），分布式系统来说，P是不能放弃的
C（Consistency） 一致性：分布式数据库的数据保持一致
A（Availability） 可用性：任何一个节点挂了，其他节点可以继续对外提供服务
P（Partition tolerance） 分区容错性（网络分区）：一个数据库所在的机器坏了，如硬盘坏了，数据丢失了，可以新增一台机器，然后从其他正常的机器把备份的数据同步过来
CAP理论的特点： CAP只能满足其中2条
CA(放弃P)：将所有的数据放在一个节点。满足一致性、可用性。AP(放弃C)：放弃强一致性，用最终一致性来保证。CP(放弃A)：一旦系统遇见故障，受到影响的服务器需要等待一段时间，在恢复期间无法对外提供服务。
举例说明CAP理论：
有3台机器，分别有3个数据库、有两张表，数据都是一样的 Machine1-db1-tbl_person、tbl_order Machine2-db2-tbl_person、tbl_order Machine3-db3-tbl_person、tbl_order 1）当向machine1的db1的表tbl_person、tbl_order插入数数据时，同时要把插入的数据同步到machine2、machine3，这就是一致性2）当其中的一台机器宕机了，可以继续对外提供服务，把宕机的机器重新启动起来可以继续服务，这就是可用性3）当machine1的机器坏了，数据全部丢失了，不会有任何问题，因为machine2和machine3上还有数据，重新加一台机器machine4，把machine2和machine3其中一台机器的备份数据同步过来就可以了，这就是分区容错性
3.1.3 BASE 理论（Basically Available（基本可用），Soft state（软状态），Eventually Consistent（最终一致性））
BA（* Basically Available*）基本可用：在分布式系统出现故障时，允许损失部分可用性（服务降级、页面降级）。 比如系统挂了，在页面上给个提示啥的S（* Soft state*）软状态：允许分布式系统出现中间状态。而且中间状态不影响系统的可用性。这里的中间状态是指不同的数据复制data replication之间的数据更新可以出现延时的最终一致性。 如CAP理论里面的示例，当向machine1的db1的表tbl_person、tbl_order插入数数据时，同时要把插入的数据同步到machine2、machine3，当machine3的网络有问题时，同步失败，但是过一会网络恢复了就同步成功了，这个同步失败的状态就称为软状态，因为最终还是同步成功了。E（* Eventually Consistent*）最终一致性：数据复制data replications经过一段时间达到一致性。
3.2 分布式事务实现方式：
- XA （数据库厂商实现）；
- 后台任务定期校对数据；
- 通过消息队列，实现最终一致(确保消息到达MQ，幂等性)；
- TCC机制(Try,Confirm,Cancel)
补偿事务（TCC）
TCC其实就是采用的补偿机制，核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。 它分为三个阶段：
- Try 阶段主要是对业务系统做检测及资源预留
- Confirm 阶段主要是对业务系统做确认提交 ，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的 。即：只要Try成功，Confirm一定成功 。
- Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
示例1：假入 Bob 要向 Smith 转账
思路大概是：我们有一个本地方法，里面依次调用 1、首先在 Try 阶段，要先调用远程接口把 Smith 和 Bob 的钱给冻结起来。2、在 Confirm 阶段，执行远程调用的转账的操作，转账成功进行解冻。3、如果第2步执行成功，那么转账成功，如果第二步执行失败，则调用远程冻结接口对应的解冻方法 (Cancel)。
优点： 跟2PC比起来，实现以及流程相对简单了一些，但数据的一致性比2PC也要差一些
缺点： 缺点还是比较明显的，在2,3步中都有可能失败。TCC属于应用层的一种补偿方式，所以需要程序员在实现的时候多写很多补偿的代码，在一些场景中，一些业务流程可能用TCC不太好定义及处理。
参考文章：
聊聊分布式事务，再说说解决方案：https://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html
示例2：餐馆或者KTV的预定、付款、取消
Try 预定
Confirm 付款
Cancel 取消
4. 系统监控
# 链路监控Spring‐Cloud‐Sleuth + Zipkin Sleuth收集微服务之间的接口调用信息以及内部方法调用。通过采样之后，将数据传输致Zipkin，由Zipkin负责存储和可视化查询；
# 核心概念：Trace，Span。公开课有讲过Sleuth；
Sleuth 是一种提供的跟踪服务，也就是说利用 sleuth 技术可以实现完整的微服务的访问路径的跟踪操作
在 SpringCloud 之中提供的 Sleuth 技术就可以实现微服务的调用跟踪，也就是说它可以自动的形成一个调用连接线，通过这个连接线使得开发者可以轻松的找到所有微服务间关系，同时也可以获取微服务所耗费的时间， 这样就可以进行微服务调用状态的监控以及相应的数据分析。
Span 里面包含有如下内容：
· cs-Client Sent：客户端发出一个请求，描述的是一个 Span 开始；
· sr-Server Received：服务端接收请求，利用 sr-cs 就属于发送的网络延迟；
· ss-Server Sent：服务端发送请求（回应处理），ss-sr 就属于服务端的消耗时间；
· cr-Client Received：客户端接收到服务端数据，cr-ss 就表示回复所需要的时间。
# 日志监控ELK 1）ElasticSearch搜索服务器，提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。2）Logstash是可以对日志进行收集、过滤、分析，并将其存储供以后使用; 3）Kibana 是Elasticsearch前端展示工具,可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助您汇总、分析和搜索重要数据日志
# 代码性能监控Metrics：度量；我们需要为某个系统某个服务做监控、做统计，就需要用到Metrics；代码执行的吞吐量，响应时间，并发量，瞬时状态值。
# 这个需要通过代码埋点实现，公开课有讲过Metrics+Grafana构建性能监控平台；
5. 高可用
服务的高可用可以通过多实例，自检测，自恢复，快速扩容机制来实现；多实例：一个服务部署多个实例，通过负载均衡机制降低单实例的负载以及实现容错；自检测：系统预留健康检查接口，通过docker集群模式的健康检查机制来实现自动重启和预警；自恢复：对于网络抖动的问题，需要程序有一定的容错性，比如：熔断机制，Eureka的自我保护措施；快速扩容：互联网应用的特殊性，在特定时候会出现高峰期的海量请求，此时，需要我们的分布式系统能够快速扩容。docker的服务编排就可以实现已有硬件资源的情况下秒扩容；对于硬件资源，需要结合云计算技术来实现；
6. 服务调用的负载均衡
# 服务端负载均衡：
对客户端屏蔽具体的接口地址，对外仅暴露负载均衡器，所有请求经过统一的负载服务；有硬件负载(f5,radware)和软件负载(nginx,apache,lvs)优势： 屏蔽了微服务地址多变的复杂性,统一管理，控制；对外部调用友好；劣势： 性能要求高，流量大对负载服务本身有很高的要求；管理复杂，大多数服务端负载器需要手工配置服务实例信息；
# 客户端负载均衡：
由客户端自己选择目标服务器，直调对应的地址；dubbo(源码参考com.alibaba.dubbo.rpc.cluster.LoadBalance)，springcloud(ribbon)都是客户端负载均衡；优势： 性能好，可以根据具体应用微调负载策略；易管理，服务实例信息自发现劣势： 服务实例信息在多客户端之间的不同步；通常是集群内部使用；
7. 分布式配置中心
类似产品有很多：360 Qconf，百度 Disconf，淘宝 Diamond 参考：https://www.cnblogs.com/zhangxh20/p/5464103.html
我们着重讲了springcloudconfig分布式配置中心，用来解决多配置的问题；将配置文件统一存储在gitlab，svn，filesystem，并支持敏感信息的加密存储(configserver或者client均可解密)
现在可以思考一个问题：在一个实际的项目开发过程之中，有可能会出现有上百个微服务（创建微服务的标准实际上就是业务设计，也就是说你有多少个业务接口那么就有可能需要定义有多少个的微服务，而且不要忘记了，微服务还会存在有负载均衡的问题），那么这样一来对于配置文件的管理就非常麻烦了。
如果现在要想进行某一个微服务的配置文件的变更，那么就有可能需要去修改上百个微服务的信息。所以为了解决这些配置文件的统一的管理问题，那么在 SpringCloud 架构里面提出有一个思想，借助于：SVN、GITHUB 来进行微服务配置文件的保存。
实现原理：所有微服务的配置文件放在git仓库里面，建立一个SpringCloudConfig的微服务并添加git仓库的配置，这样就能实时获取git仓库里面的配置文件了，其他的微服务就追加SpringCloudConfig的微服务的配置就能通过SpringCloudConfig的微服务获取到各自的配置文件了
但是在此时也需要注意几个问题：
- 一旦使用了 SpringCloudConfig 之中，现在的项目的中心就变为了 SpringCloudConfig 服务；
- 为了解决配置文件的安全问题，在 SpringCloudConfig 之中还提供有一个所谓的安全加密处理，例如：一些重要的密码有可能需要被加密，所以可以使用两种加密处理（密钥处理、jks 安全处理）。
8. 服务注册与发现机制
这种机制目的是实现：服务提供者的自注册，服务消费者的主动发现服务提供者；服务注册：服务提供者启动实例时，将信息存储到注册中心；注册中心：保存服务提供者或者消费者的实例信息(服务名称，IP,端口，方法地址等等) 服务发现：服务消费者，通过服务名在注册中心的信息中查询出具体的服务提供者实例信息。
9. 分布式系统如何拆分？
业务线(订单系统，积分系统，审计系统，支付系统，结算系统，推广系统….) 技术栈（php，java，nodejs，go）
架构分层 (前台，中台，后台；存储服务，缓存服务，MQ服务，搜索引擎服务….)
前台：页面相关技术如node.js、网关
中台：APP注册时除了调用后台的增加功能以外还会发优惠卷，PC网站注册时除了调用后台的增加功能以外还会发送积分。这样的服务称为中台
后台：增删改查
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
二、SpringCloud
1. 微服务是如何保护自己的
信息加密：
通过Https实现信息传输的加密(nginx，tomcat都可以配置https)；对代码侵入性很小。因为微服务集群不直接对外提供服务，由统一的网关来提供业务API(zuul，nginx都可以的)。
权限校验方案：
单点登录：
什么是单点登录：一个系统登录以后，其他系统不需要再次登录
# 每个应用都必须接入单点登录，大型系统中，需要集成单点登录带来的复杂工作和性能损耗；
分布式session方案：
流程：客户端 ‐> 获取session ‐> 请求微服务 ‐> 查询共享存储中授权信息 ‐> 校验权限 ‐> 提供服务 ‐> 给予响应
分布式session保存方案，根据session去查找共享存储中对应的权限信息来实现权限校验；
# 共享存储的高可用和安全性是个问题，类似直接redis，memcache来做；
token方案：
- 客户端 ‐> uaa认证 ‐> 获取token
- 客户端 ‐> 微服务 ‐> 校验token
token包含必要的授权信息，一次获取，多次使用，相对独立，实现简单，不需要cookie；长度有限，不能撤销，需要设置过期时间；# 可以在网关层做；也可以构建成通用的组件，放在每个微服务上面去做；# 根据不同的业务场景：token可以发放一次，也可以在每次请求的时候去申请，这样能够实现分控需要的账户禁用，黑名单等功能
2. 微服务网关
在很多的开发之中为了规范微服务的使用，提供有一个路由的处理控制组件：Zuul，也就是说 Zuul 就作为中间的一个代理层出现
zuul是springcloud提供的成熟的路由方案；根据请求的路径不同，网关会定位到指定的微服务，并代理请求到不同的微服务接口；对外屏蔽了微服务接口调用的复杂性。三个重要概念：动态路由表，路由定位，反向代理 反向代理：客户端请求到网关，网关受理后，再对目标服务发起请求，拿到响应之后，再响应给客户端；动态路由表：zuul支持eureka路由，手动配置的路由，这两种都支持动态更新；路由定位：根据请求路径，zuul有一套自身的服务定位规则以及路由匹配的表达式；
# 应用场景：对外暴露，权限校验，服务聚合，日志审计
3. 各服务之间如何调用
服务对外以http接口形式暴露，所以调用有多种方式；Fegin是cloud提供的一种服务调用客户端；Resttemplate也可以快速的发起服务调用；同时，也可以手动获取对应接口的具体地址，通过平常的httpclient进行调用；# Feign和Resttemplate 都可以集成负载均衡，失败重试，熔断的功能；
4. 如何保证服务健康的情况
1.spring-boot-starter-actuator可以用来监控我们的项目，可以通过HealthEndPoint/health来查看应用的健康状况；SpringBoot在集成很多组件时，都会实现一个健康检查的接口，如ElasticsearchHealthIndicator，RedisHealthIndicator， RabbitHealthIndicator等。
- 在微服务集群中，我们通常还会通过sleuth来进行服务调用的链路追踪，可以通过抽样看到服务调用的异常情况；
- 日志信息也是我们监控服务监控情况的一个重要手段，常用通过ELK实现日志收集，分析和查看；
- 在通过docker部署微服务时，我们可以利用docker的健康检查机制，实现服务的自动重启；
5. 容错机制
# Ribbon 负载均衡&重试 通过服务名获取实例信息，根据负载策略选择合适的实例去访问；服务调用失败时，可以配置重试次数，以及实例切换的次数；
Ribbon 是一个服务调用的组件，并且是一个客户端实现负载均衡处理的组件 。服务器端实现负载均衡可以使用 Nginx、 HAProxy、LVS 等。
# Hystrix熔断机制
限流，降级，熔断；限流：限制接口访问并发量，限制缓冲区大小，超出限制，调用Fallback方法 熔断：出错率超过阈值，一定时间内不再请求该接口。(超时、run方法抛出异常) 降级：凡是没有正常的从接口中拿到数据，就会调用Fallback方法，获取一个结果
# 通过命令模式的封装，SpringCloud内部自动集成，且可作用于任意JAVA方法上，不关心方法的具体实现。代表着(http、redis、db操作都可以做熔断)；
所谓的熔断机制和日常生活中见到电路保险丝是非常相似的，当出现了问题之后，保险丝会自动烧断，以保护我们的电器， 那么如果换到了程序之中呢？
当现在服务的提供方出现了问题之后整个的程序将出现错误的信息显示，而这个时候如果不想出现这样的错误信息，而希望替换为一个错误时的内容。
一个服务挂了后续的服务跟着不能用了，这就是雪崩效应
对于熔断技术的实现需要考虑以下几种情况：
· 出现错误之后可以 fallback 错误的处理信息；
· 如果要结合 Feign 一起使用的时候还需要在 Feign（客户端）进行熔断的配置。
6. SpringCloud中的服务注册与发现机制
两个角色eurekaServer， eurekaClient server提供httpapi服务，存储服务实例的信息，并且具备主动剔除服务(心跳检测)和server高可用的功能；client集成在具体的微服务中，在服务启动时，将服务实例信息post到server上；client也会定时同步server上面其他service信息；# eureka的工作大多是后台thread在定时工作，任务执行的间隔时间都可以通过配置文件进行配置；
7. SpringCloud的实施推广
# 集成SpringMVC项目 微服务改造的过渡期，在传统的SpringMvc项目中，引入部分SpringCloud的特性，即可通过微改造变成微服务；
# 其他语言的项目加入SpringCloud微服务系统 Eureka提供HttpApi，使得非java语言加入到SpringCloud微服务集群成为可能；
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
