1.1简介
1.1.1 概念
集群： 它是一种物理形态，简单来讲就是把同一个业务部署到多个服务器上。而在接收到请求流量时，主要是通过负载均衡器，来进行流量分配。
分布式： 它是一种工作方式，将一个业务拆成多个小业务，然后部署在不同的服务器上。而分布式系统则指的是，部署在同一网络下，并通过网络进行通信与协调的多个组件，它们对外表现为一个系统。
微服务： 是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。
注意： 值得一提的是，集群与分布式、微服务区别很大。但是，分布式与微服务的概念却很模糊，对于二者的关系网上也是众说纷纭，这就类似于一直有人争论java中的值传递与引用传递。但我的理解是，分布式包含微服务，微服务是一种特殊的分布式。
结构图如下：
1.1.2 SpirngCloud
SpringCloud 是一套微服务架构的工具集，提供了一系列的微服务工具。并且其拥有众多子项目，如下图：
1.2 选型
本文的微服务工具选型是：nacos 、sentinel、seata、gateway、openfeign、ribbon。
1.2.1 Nacos 服务发现
微服务架构下，系统由一个又一个的服务组成，每一个服务都是一个独立的项目。而服务之间的通信则有网络完成，而如何实现服务之间的“牵线搭桥”，则主要依靠Nacos，所有的服务在注册时，都会往服务注册表中注册自己，以便其他服务进行发现，以及后续调用。
原理图如下：
1.2.2 Ribbon 负载均衡
负载均衡一词指的是，将负载或者压力进行均摊，例如在进行服务调用时，将请求流量均衡的分配给服务提供方。
常用负载均衡策略：
| 名字 | 备注 |
|---|---|
| 最小并发数 | 根据服务的并发数量，来选择一个最小的 |
| 轮询 | 按照轮次来进行服务调用 |
| 随机 | 根据随机算法完全随机调用 |
| 响应时间权 | 根据服务调用的响应时间来调用， 响应时间越长，权重越小 |
提示： 值得注意的是，openfeign底层内置了Ribbon，在进行服务调用的时候，便已经进行了负载均衡。
1.2.3 OpenFeign 服务调用
openfeign是声明式服务调用组件，它实现了像调用本地方法一样，调用远程方法。由于服务之间项目独立，因此其严格遵守resultful风格，使用post、delete、put、get来对应增删改查操作。
而共享接口，则指的是，将服务提供方的接口与实现进行分离，服务实现处于app模块下，而接口则处于client模块下，服务调用方只需要引入client的依赖即可使用。虽然它是openfeign的产物，但是我认为它与openfeign并没有实际的关系，因为共享接口实际上是依托于maven实现的。于是，通过共享接口，与声明式服务调用，它解决了服务之间的调用问题。
而openfeign的底层实现原理则是，通过spring-aop使用Jdk动态代理，同时通过反射来完成的。值得一提的是，openfeign是对于restTemplate的二次封装，因此在动态代理时，增加的额外代码则是，restTesmplate的服务调用代码。
服务项目模块划分结构图如下：
1.2.4 Nacos 配置管理
Nacos除了提供服务发现的功能以外，还提供了配置管理的功能。配置管理提供了三个重要的功能：审计、动态刷新、共享配置。
审计主要负责校验配置是否正确；动态刷新则指的是，需要更改配置时，不再需要下线项目，重新打包与部署，而是实时更新；共享配置则指的是，可以把共有且重复的配置提取出来，作为公共配置存在。
配置原理如下：
提示： 服务项目启动之时，便会去配置管理服务器中拉去相应的配置。
注意： Nacos之所以集成了两个工具，是因为二者的执行流程极其相似，如下表：
| 服务发现 | 配置管理 |
|---|---|
| 服务注册 | 新建配置 |
| 拉取服务列表 | 启动时拉取配置 |
| 健康检测 | 配置变动检测 |
| 变更通知 | 变动通知 |
| 重新拉取服务列表 | 重新拉取配置 |
Nacos系统架构图：
1.2.5 Seata 分布式事务
单体项目的事务管理，不能满足微服务项目的需求，因此需要使用分布式事务。
常见的分布式事务方案有： XA协议、TCC模式、SAGAS模式、 AT模式、重试+幂等性。
| 名字 | 描述 |
|---|---|
| XA协议： | 多个数据库同步打开事务，等待TC协调。等所有的分支事务确认提交之后，再统一提交。极其消耗数据库性能。 |
| TCC模式： | 将一个事务分成三个操作，try做业务检查与资源预留，comfirm则是确实操作，cancel则是取消操作。 |
| SAGAS模式： | 用于处理长事务，每个参与者都提交本地事务，一旦失败，那么则补偿前面的成功参与者。 |
| AT模式： | 是一种无侵入的分布式事务解决方案，主要分为两个阶段：1.代理数据源、获取操作前后的镜像数据，并记录得到undo_log表中、加入到当前事务。2.提交成功，则删除undo_log记录；失败则根据记录生成sql进行数据回滚。 |
| 重试+幂等： | 则是不断重试，然后人工介入。 |
注意： 这只是冰山一角，具体实现应该详细了解。
执行原理图：
1.2.6 gateway 服务网关
服务网关是整个分布式系统的唯一入口，它主要提供的功能有：IP黑白名单、动态路由、授权、日志记录、性能检测、跨域、协议转换、限流。
而至于为什么需要一个服务网关，则是因为它不仅可以集成具有横切性质的功能，还可以为整个微服务系统提供隐蔽性。
项目示意图如下：
实现原理：
1.2.7 单点登录
单体项目下，记录用户状态的方式有token与session两种。而在微服务中，由于服务之间的独立性，于是这种两种方式则不再可用，因此可以使用cas、oauth2、sa-token等方式实现。
而基于redis+cookie的sa-token的实现过程则是，当用户在某一个服务中的页面登录之后，由jwt生成一个签名作为redsi中的key来使用，并且将其通过父级域名存入值cookie之中。然后，将这个key携带数据保存至redis中。当每次发起请求之时，便会携带token，然后进行验证是否登录。
1.2.8 Sentinel 服务容错
为了尽量控制服务调用时出现的各种错误，尽量避免服务雪崩等情况的出现，我们需要使用服务容错，来对服务调用进行容错处理。
工作原理：
本文仅作为个人学习笔记，各种细节难免出错。留有此文，以便他日之需。