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

  • Post author:
  • Post category:其他




统一版本

通过全服务共享一个总父项目,各个子项目不加版本,由这个总父项目来控制版本,子项目会根据情况自动升级。

这种专门管理版本的项目,我们一般称为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. 仓壁模式[调用方/提供方],利用线程池或者信号量等其他手段进行资源隔离,确保不会产生级联故障



版权声明:本文为monkey__yang原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。