springcloud微服务项目解析与服务拆分

统一版本

通过全服务共享一个总父项目，各个子项目不加版本，由这个总父项目来控制版本，子项目会根据情况自动升级。
这种专门管理版本的项目，我们一般称为BOM(Bill Of Materials 物料清单)。已经成为非常成熟的模式。如果你沿着spring-boot的parent往上追溯也会找到spring-boot-dependencies，就是一个BOM。
这里需要了解下 这个标签，它会管理依赖的版本，包括依赖排除这些，但是不会为子项目加入这个依赖。这点跟 是不同的，这也是BOM的关键技术。
另外，子项目通过 指定父项目。
比如创建一个mall-parent项目，负责管理版本全局统一的父pom。

统一工具类

一般公司内部都有自己的工具类，会提供一些类似如日期格式化，ID生成等等的工具类。这类的工具类是非常通用的，每个项目的每个模块都会需要用上。所以会考虑直接在总父pom中加入依赖。一旦加入就是全局引入，所有项目就自动获得这个依赖。所以除了这个统一工具类的依赖以外，很少会再加入其他依赖。
比如创建一个mall-commons项目（单纯的maven-quickstart项目）来统一提供工具类，具体功能如下：

提供各种基础工具
统一响应格式
统一错误码
统一的异常父类
统一的ID生成工具
…

统一项目结构

项目当然可以是单体项目。但是既然是为了解决可能面对的复杂问题，我们就来模拟一个复杂的项目结构。
这里涉及到maven多模块项目的概念。
maven多模块项目其实是指在一个项目中包含多个独立的模块项目，每个模块可以单独打包成jar或者war。

项目拆分

单个项目组成部分

一个逻辑业务项目一般被具体拆分为以下几个部分
1.app层
2.service层
3.infra层
4.common层
5.client层
该业务的所有接口归纳给client层暴露出去，install 导本地的maven仓库，其他项目就可以调用此项目的各类业务接口，同时也将各个业务完整的划分开来。

项目依赖关系

居中的图片:

服务划分

原子层

通常面对用户的项目被单独领出来作为一个项目服务，列入 App，单点登录的服务器，mall等每个用户端，提供一个服务 。

原子服务层

在具体的业务逻辑中细化分为多个服务但是它们并不直接面向用户 ，而是有一顶的限制条件 比如需要用户登录后进行某些逻辑操作，想添加购物车，下单，贷款等各种功能都是一个原子服务层的一个服务。

分布式服务中涉及中间件及各种问题的处理方法

分布式事务

两阶段提交

阶段一： 预备阶段
● TC通知所有分支事务执行业务操作
● 所有分支事务处理完成后告知TC
阶段二： 提交阶段
● TC如果收到所有的分支事务提交都是完成，则全局事务提交，通知所有分支事务提交
● TC如果有收到存在部分提交失败或者超时，则全局事务回滚，通知所有分支事务回滚

常见解决方案

1.XA协议

2.TCC ： Try-Confirm-Cance

3.SAGAS

4.AT模式

分布式解决方案seata 提供的AT模式
阶段一：预备阶段
● 1.执行业务
● 2. 获取并持久化回滚数据
● （1）seata代理数据源（javax.sql.DataSource），拦截所有的数据库操作（SQL）
● （2）获取到操作执行前后的数据镜像，生成insert SQL，插入到undo_log表
● （3）加入到当前事务，提交
阶段二：提交阶段
● 正常提交：删除undo_log表中的记录
● 异常回滚：
○ seata提取对应的undo_log表中的记录，计算生成回滚用sql
○ 执行回滚SQL，提交事务
优势：
● 没有额外的事务方面的性能消耗，资源消耗低
● 不需要额外编码，对程序员完全透明
劣势：
● 需要额外建表

重试+幂等性校验

服务网关

整个分布式系统的唯一入口 / 边缘服务

职责：
● 提供一些通用的公共功能
○ ip黑名单，封禁ip
○ ip白名单，允许哪些ip通过
○ 认证、授权，进行权限控制
○ 动态路由，根据请求路径，转发给相应的服务
■ api.xxx.com/v2/xxx/xxx
○ 日志记录，原始数据
○ 性能统计
○ 协议转换， http -> dubbo/grpc/thrift
○ 限流

搭建网关

spring-cloud-gateway 官方提供的网关组件
常见网关组件：
● netflix-zuul 基于Servlet，tomcat
● cloud-gateway 基于Reactive技术栈，底层是Netty
○ 不允许有 starter-web依赖，不然报错
● apache APISIX
● kong

1. 新建mall-gateway，选择lombok、gateway、nacos
2. 配置端口

单点登录

解决的问题

sso(single sign on)单点登录：隶属于同一个网站的多个不同的页面系统，只需要登陆一次，就可以访问任何其他的系统。

单点登录的优势：

● 复用
● 集成

常见实现方式及实现原理

● cas协议 https://www.apereo.org/projects/cas
● oauth2协议 https://oauth.net/2/
● 基于redis共享+cookie的方式 sa-token https://sa-token.cc/doc.html#/

实现原理 cookie

**
存储结构 key-value
存储少量数据
存在浏览器端
可以设置过期时间
属于特定的域名，由某个网站写入 aaa.com
设置过后，每次请求自动携带cookie
**

服务容错

解决的问题

在复杂的分布式架构的应用程序有很多的依赖，都会不可避免地在某些时候失败。高并发的依赖失败时如果没有隔离措施，当前应用服务就有被拖垮的风险。

常见服务容错模式

1. 超时[调用方]， 限制资源的占用，给资源（线程、cpu时间）占用设置上线
2. 限流[提供方]，控制进入系统的流量，不超过本机最大处理能力
3. 仓壁模式[调用方/提供方]，利用线程池或者信号量等其他手段进行资源隔离，确保不会产生级联故障