用豆包辅助从头开始学习java spring cloud（八）

用豆包辅助从头开始学习java spring cloud八昨天学习了redis的一些基本操作今天学习以理论为主学习架构理论 RESTful API 规范。第一部分架构演进1.单体架构所有功能全部卸载一个springboot工程里面以商城为例用户、订单、支付、商品全部在一起一份代码、一个包一套数据库。这种架构的优点就是开发简单部署简单小项目效率高。但是缺点也非常明显1.代码量大模块耦合严重改其中一处容易牵连其他功能2.全部功能公用一个实例当某一个功能压力大的时候需要整体扩容不能单独给高压力部分扩容3.所有人在一个代码库开发代码冲突频繁4.一个模块出现了漏洞整个应用可能就宕机了。所以也就限制了这类项目的适用范围小型项目内部管理系统。tips耦合就是两个功能模块之间绑的太紧密了当a模块小小改动b模块也跟着受影响。生活化的类比一下高耦合计算机一体机显示器、内存、cpu、显卡、风扇、电源整体焊死在一块板子上当其中不论是内存或是显示器或是电源存在一点损坏整台计算机一起报废低耦合台式计算机组装机现在的品牌台式计算机也大多如此显卡坏了只需要把显卡换掉其他部件依旧正常可以使用各个部件通过接口插在一起。为了解决这个问题解耦开始进行项目拆分出现了项目拆分。2.垂直拆分多个单体把大的单体项目按照业务类别拆分成多个独立的单体项目以商城为例用户系统、订单系统分成独立系统各自部署。特点是各个项目代码完全隔离可以单独扩容某一个业务模块问题是服务和服务之间调用很麻烦没有统一的服务治理数据可能存在重复。3.SOA面向服务架构把公共能力抽离成服务其他业务系统调用服务出现了ESB企业服务总线所有服务的交互都从总线走。特点是公共服务的复用能力好缺点是ESB总线很重配置复杂粒度依然偏大适合传统企业。tips1ESBEnterprise Service Bus企业服务总线在SOA架构里面的核心组件想象成一条中央总线网所有的服务不直接互相调用全部接入这条ESB总线。当服务A需要调用服务B时请求发送给ESB由ESB做转发、协议转换、鉴权、日志、数据格式转换、再转给服务B。好处就是所有服务都有ESB管控缺点是ESB本身是一个庞大的、独立的软件部署维护麻烦配置繁琐所有服务必须经过ESBESB瘫痪时成为整个系统的瓶颈点。2粒度粒度就是拆分出来的服务的大小粒度大指的就是一个服务里面包含了许许多多的业务服务需要做的事很多相反的粒度小指的是一个服务职责单一只做一小块业务。SOA时代基于ESB拆分出来的服务不够细以商城举例只拆分出电商业务、会员服务其中电商业务里面同时包含了商品、订单、库存等一大堆的业务这就是粒度大粒度小就拆成更多、更小、职责更单一的服务。以SOA为基础进一步演进为微服务架构。4.微服务架构把系统拆分成粒度更小、高度自治的业务服务。每一个微服务独立开发、独立部署、独立数据库服务之间通过HTTP/RPC远程调用通信。✅微服务优点独立扩容哪个服务压力大就只扩容哪个服务技术异构不同服务可以选用适合自己的技术栈局部故障隔离订单服务挂掉不会直接导致用户服务不可用团队解耦不同团队维护不同微服务代码互不干扰❌微服务缺点复杂度大幅上升不再是本地方法调用变成远程网络调用引入一堆组件注册中心、配置中心、网关、分布式事务、链路追踪运维成本暴涨需要容器、监控、日志分布式带来新问题网络超时、数据一致性问题重要认知微服务不是万能神器不是项目一用上所有问题自动全部解决小业务不要强行上微服务tips1.SOA、微服务是软件架构设计的思想是一套架构方案是架构演进概念和具体代码框架不绑定2.Spring Boot是开发框架用来快速开发Java应用的工具微服务里的每个服务是可以使用Spring Boot开发出来的3.Spring Cloud是微服务的整套解决方案、是实现微服务的组件集合是建立在Spring Boot基础之上的Spring Boot开发每个服务Spring Cloud提供微服务的配套组件比如Nacos 注册中心、网关、分布式锁、分布式事务等。第二部分微服务拆分原则1.**按业务域拆分最核心**围绕业务能力而不是按技术层拆分。❌错误拆法把所有 controller 抽一个服务所有 service 抽一个服务。✅正确拆法用户域、订单域、商品域一个业务域作为一个微服务。2.单一职责一个微服务只负责自己业务域的事情。3.高内聚低耦合域内功能尽量内聚服务之间尽量少依赖。4.数据私有微服务尽量不要跨库直接访问别人的表通过接口拿数据。第三部分RESTful API 接口规范这个部分内容在我们之前学习代码的时候部分使用过下面学习一下基础理论。核心思想URL 代表「资源」HTTP Method请求方式代表「动作」。URL 里面尽量不要写动词不要写getXXX / addXXX / deleteXXX。资源系统里的实体用户、订单、商品、购物车都叫资源。1、HTTP 方法与语义方法含义使用场景示例 URLGET查询获取数据不修改服务器数据GET /users查询全部用户GET /users/{id}根据 id 查单个用户POST新增创建新资源POST /users新增一个用户PUT全量更新把对象完整覆盖更新所有字段都传PUT /users/{id}修改 id 对应的用户DELETE删除删除资源DELETE /users/{id}删除指定用户PATCH局部更新只传要修改的部分字段项目实际用的少PATCH /users/{id}只修改 agetipsGET 请求不能做新增、修改、删除GET 会被浏览器缓存、日志记录用来改数据会产生安全问题。2、URL 命名规范资源用名词复数优先/users、/orders、/goods获取单个资源/users/1路径放 id子资源订单下面的明细GET /orders/1001/items查询 1001 号订单的所有订单项禁止带有动作的命名如/getUserById?id1,/addUser,/updateUser,/delUser,动作是要交给对应类的方法去执行的违背了REST思想tipsREST 思想Representational State Transfer表述性状态转移用资源为中心通过 HTTP 标准方法完成对资源的操作不需要额外自定义动作。3、请求参数我想细心的朋友可能会注意到我们放问某些网页的时候网址会出现、这样的符号下面详细学习一下1.路径变量pathVariable资源唯一标识写在 url 路径上GET /users/11 是用户 id。2.query 查询参数? 后面过滤、分页、排序如GET /users?pageNum1pageSize10age20,分页、筛选条件放在?后面不要写到路径里。3.body 请求体POST、PUT新增 / 修改时JSON 放 BodyGET 请求不要使用 body很多网关、浏览器会丢弃 GET 的 body。4、返回数据规范1.使用统一返回体就是我们 common 模块写的ResultT2.集合查询data 返回数组分页返回 data 里面包含列表 总条数。3.异常场景全局异常处理器统一捕获依然返回 Result 格式 JSON不要返回 html 错误页面。5.HTTP 状态码语义REST 建议200 OK查询、修改成功201 CreatedPOST 新增资源成功400 Bad Request参数错误404 Not Found访问的资源不存在500 Internal Server Error服务内部异常实际开发很多项目 http 状态码统一返回 200业务错误放到 code 字段里面就是我们 Result 的 code两种都可以团队保持统一即可。6、举一套完整用户 CRUD REST 示例查询全部用户GET /users查询单个用户GET /users/2新增用户POST /usersbody 传 json全量修改用户PUT /users/2body 完整用户 json删除用户DELETE /users/27.无状态**每一次 HTTP 请求服务器不保存客户端会话状态。**每个请求自带全部需要信息token、参数服务端不用记住上一次请求。好处服务端更容易扩容、集群坏处每次请求都要带上身份凭证 token。7、现实开发注意点RESTful 是设计思想不是强制法律很多公司会做折中。如果业务动作不是简单增删改查例如用户登录、导出没有合适 HTTP 方法允许 URL 带动词POST /users/login这种属于合理妥协。RESTful API遵循 REST 思想写出来的接口。REST 是思想RESTful 是遵循这套思想的实践产物。简单 CRUD 严格遵守特殊业务动作可以妥协。第四部分电商系统如何做微服务拆分这是一道思考题大家可以先自行思考再往下看我们先思考一下参照现在的电商系统想象一下电商系统需要的模块1.首先是用户注册、登录、用户信息、地址信息等用户相关的2.登录之后开始查看商品对商品管理的商品信息、分类、图片、商品的上架和下架信息3.查看商品之后考虑是不是要加入购物车购物车的增删改查以及分类下架的商品正常的商品4.不论是不是加入购物车都需要考虑是不是下单也就是订单的增删改查包括订单退货流程5.下单之后就要对应商品库存了商品库存的增删改查6.下单的话还要考虑支付问题是对接三方支付还是自有支付暂不考虑对接三方的话接口的调用和回调7.下单之后的物流发货、物流轨迹查询等。所以对应的拆分思路就是user‑service 用户服务注册、登录、用户信息、地址管理goods‑service 商品服务商品信息、分类、图片、商品上下架cart‑service 购物车服务购物车增删改查order‑service 订单服务创建订单、订单状态、订单查询stock‑service 库存服务商品库存扣减、库存查询pay‑service 支付服务对接第三方支付支付回调logistics‑service 物流服务发货、物流轨迹查询订单产生和退单过程都调用商品服务商品服务再去调用库存服务订单并发产生的商品库存增减也是事务问题。第五部分小结今天学习了编程思想的演进过程以及接口规范的做法最后简单思考了一下电商系统该如何设计拆分服务。截止当前第一阶段学习完毕明天是对第一阶段的整体回顾考虑到都是各种问题就直接罗列在今天学习的后面了明天不再单独罗列下一次学习进入第二阶段学习。问题的答案大家自行思考和搜索不再复述了第一阶段通关验收清单全部需要可以口述出来一共 6 大项每一项下面附带提问全部理解清楚才算通关才能进入 第二阶段。题目 1 SpringBoot 自动配置原理说出ConfigurationFull 模式 和 Lite 模式区别ConditionalOnMissingBean的作用是什么简单说下 SpringBoot 自动配置的加载原理META‑INF/spring/org.springframework.boot.autoconfigure.imports题目 2 common 公共模块RestControllerAdvice ExceptionHandler作用是什么BizException 自定义业务异常和通用 RuntimeException处理器如何区分处理为什么项目抛出异常不能直接返回原生错误页面要统一封装为 Result 返回题目 3 独立单体 SpringBoot MyBatis‑PlusMyBatis‑Plus 的QueryWrapper条件构造器作用是什么::方法引用写法含义MyBatis‑Plus 分页插件必须配置什么否则分页 total 总数不对Druid 数据源作用是什么题目 4 Spring 本地事务事务 ACID 分别代表什么Transactional(rollbackFor Exception.class)rollbackFor 不加会有什么坑说出 2 种以上事务失效场景非 public、内部 this 调用、try‑catch 吃掉异常以及失效原因题目 5 Redis 缓存三大问题缓存穿透现象 解决方案缓存击穿现象 解决方案缓存雪崩现象 解决方案实操为什么不能直接把 null 存入 RedisTemplateJackson 序列化坑我们是如何解决缓存穿透的题目 6 架构演进 RESTful 规范架构演进路线单体 → 垂直拆分 → SOA → 微服务每个阶段简单特点ESB 是什么SOA 粒度偏大什么意思微服务优点、缺点为什么微服务不是银弹微服务拆分核心原则REST 思想是什么GET/POST/PUT/DELETE 各自语义URL 编写禁忌什么场景可以适度妥协 REST 规范简单说电商系统如何做微服务拆分用户、商品、订单、库存、支付…