如何设计可扩展架构

创始人

2024-03-03 14:17:49

0次

架构设计复杂度模型

在这里插入图片描述

业务复杂度和质量复杂度是正交的

业务复杂度

业务固有的复杂度，主要体现为难以理解、难以扩展，例如服务数量多、业务流程长、业务之间关系复杂

质量复杂度

高性能、高可用、成本、安全等质量属性的要求

架构复杂度应对之道

复杂度等级	业务复杂度	质量复杂度	架构模式
1	低	低	框架，如LAMP、SSH
2	高	低	SOA、DDD、微服务
3	低	高	集权、缓存、Reactor、分片、副本
4	高	高	融合所有模式

架构设计环

在这里插入图片描述

可扩展复杂度模型

可扩展（extensibility）：系统适应变化的能力，包含可理解和可复用两个部分

可伸缩（scalability）：系统通过添加更多资源来提升性能的能力

可扩展复杂度模型

在这里插入图片描述

“拆分”复杂度分析和设计

拆分复杂度模型

在这里插入图片描述

拆分粒度

两个复杂度

内部复杂度

又称为“单体复杂度”，指单个对象内部的复杂度，例如传统的单体系统，所有业务都在一个系统里面

可以用参与的开发人数来衡量单个拆分对象的复杂度（三个火枪手原则）

例如：3个人负责一个子系统/子模块是比较合理的，20个人在同一个子系统上开发，则内部复杂度过高

外部复杂度

又称为“群体复杂度”，指拆分后的多个对象之间的关系复杂度

可以用业务流程涉及对象数量来衡量外部复杂度

例如：1次用户请求需要5个子系统参与是比较合理的，如果需要20个子系统参与，则外部复杂度过高

平衡的艺术

内外平衡原则

内部复杂度和外部复杂度是天平的两端，一方降低，另一方必然升高，关键在于平衡

先粗后细原则

如果你把握不准，那么就先拆少一些，后面发现有问题再继续拆分

“封装”复杂度分析和设计

封装复杂度模型

在这里插入图片描述

预测的艺术

2年原则

只预测2年内的变化，不要试图预测10年后的变化

3次原则

预测没有把握就不要封装，等到需要的时候重构即可

封装的技巧

在这里插入图片描述

上一篇：Junit5的断言方式，一学就会

下一篇：Web3.0带来天翻地覆的变化？全面科普！所谓的Web3.0到底是什么？

如何设计可扩展架构

架构设计复杂度模型

业务复杂度

质量复杂度

架构复杂度应对之道

架构设计环

可扩展复杂度模型

可扩展复杂度模型

“拆分”复杂度分析和设计

拆分复杂度模型

拆分粒度

两个复杂度

内部复杂度

外部复杂度

平衡的艺术

内外平衡原则

先粗后细原则

“封装”复杂度分析和设计

封装复杂度模型

预测的艺术

2年原则

3次原则

封装的技巧

相关内容

热门资讯