00-分布式架构
有效系统设计
- 了解问题和设计范围
- 要开发的功能
- 有多少用户:qps,tps
- 后续的扩展性,扩展速度
- 公司的技术栈,有哪些现成的服务
分布式架构
- 分布式架构的难点在于系统设计,服务管理和运维
- 分布式系统中的问题
- 异构系统的不标准问题
- 系统架构中的服务依赖性问题
- 故障发生的概率很大
- 运维的复杂度大
- 分布式分层
- 基础层
- 平台层
- 应用层
- 接入层
- 构建分布式应用需要关注的点
- 大流量处理
- 关键业务保护
- 提高架构的性能
- 缓存系统
- 负载均衡系统
- 异步调用
- 数据分区和数据镜像
- 提高架构的稳定性
- 服务拆分
- 服务冗余
- 限流降级
- 高可用架构
- 多租户隔离
- 灾备多活
- 高可用运维
远程调用
- 三个经典问题
- 数据的表示
- 数据的传输
- 方法的确认
RUST风格
- 面向资源编程
- 希望软件系统设计的重点放到抽象系统该有哪些资源上,而不是抽象系统该有哪些行为上。
- 六大原则
- 服务端与客户端分离,前后端分离
- 无状态
- 可缓存
- 分层系统
- 不是表示层,服务层,持久层这种意义上的分层,而是指客户端 一般不需要知道是否直接连接到了最终的服务器,亦或连接到路径上的中间服务器。该原则的典型是CDN
- 统一接口(可选)
- 面向资源开发接口,而不是根据行为开发接口
- RUST的缺点
- 只适合CRUD,不适合逻辑复杂的业务
- 与http绑定,不适合应用于要求高性能传输的场景中
- 不利于事务支持
- 没有传输可靠性支持,无法确认是未接收到消息,然后接收消息后的响应丢失
- 缺乏对资源进行部分和批量的处理能力
代码层注意的问题
划清业务边界
- DDD(领域驱动设计)可以作为一个指导原则,但是 DDD 比较偏向于理论,需要执行人员有良好的专业能力才能实施的比较好。
代码层次结构
- 按照功能区分modle
- package的设计
- 根据业务模块然后内部按MVC划分
- 将每个业务模块作为一个 package,然后每个package里面有自己的 MVC,这样就做到业务模块的隔离
- 根据MVC模式然后内部按业务划分
- 先根据 MVC模式划分不同的包,service,serviceImpl,dto等,然后再是各个业务自己的模型和服务接口。
- 根据业务模块然后内部按MVC划分
避免多边界的业务查询
- 如果同属于一个业务领域则可以使用关联查询,而那些微服务拆分后属于不同领域的业务则应避免使用多表关联查询,因为不同的业务领域后期会被隔离拆分到不同的服务当中,即数据库表都是分布在不同的服务器上,所有服务之间都是通过RPC方式进行通信,关联查询这时是无法处理的。
00-分布式架构
https://x-leonidas.github.io/2025/04/30/12分布式系统/00-分布式架构/