《从0开始学架构》基础架构——小记随笔
架构是什么
要想准确地理解架构的定义,关键就在于把三组容易混淆的概念梳理清楚:
- 系统与子系统
系统泛指由一群有关联的个体组成,根据某种规则运作,能完成个别元件不能单独完成的工作的群体。它的意思是“总体”“整体”或“联盟”。
子系统也是由一群有关联的个体所组成的系统,多半会是更大系统中的一部分。
-
模块与组件
从业务逻辑的角度来拆分系统后,得到的单元就是“模块”;从物理部署的角度来拆分系统后,得到的单元就是“组件”。划分模块的主要目的是职责分离;划分组件的主要目的是单元复用。 -
框架与架构
框架和架构的区别还是比较明显的:框架关注的是“规范”,架构关注的是“结构”。
架构是顶层设计;框架是面向编程或配置的半成品;组件是从技术维度上的复用;模块是从业务维度上职责的划分;系统是相互协同可运行的实体。
- 重新定义架构:4R 架构
架构设计的目的
架构设计的主要目的是为了解决软件系统复杂度带来的问题。
复杂度的来源之一高性能
软件系统中高性能带来的复杂度主要体现在两方面,一方面是单台计算机内部为了高性能带来的复杂度;另一方面是多台计算机集群为了高性能带来的复杂度。
计算机内部复杂度最关键的地方就是操作系统。操作系统和性能最相关的就是进程和线程。
集群的复杂度,让多台机器配合起来达到高性能的目的,是一个复杂的任务。
- 任务分配
- 任务分解
复杂度来源:高可用
本质上都是通过“冗余”来实现高可用。
高性能增加机器目的在于“扩展”处理性能;高可用增加机器目的在于“冗余”处理单元。
- 计算高可用
- 存储高可用
存储与计算相比,有一个本质上的区别:将数据从一台机器搬到到另一台机器,需要经过线路进行传输。
存储高可用的难点不在于如何备份数据,而在于如何减少或者规避数据不一致对业务造成的影响。
分布式领域里面有一个著名的 CAP 定理,从理论上论证了存储高可用的复杂度。也就是说,存储高可用不可能同时满足“一致性、可用性、分区容错性”,最多满足其中两个,这就要求我们在做架构设计时结合业务进行取舍。
高可用状态决策
无论是计算高可用还是存储高可用,其基础都是“状态决策”,即系统需要能够判断当前的状态是正常还是异常,如果出现了异常就要采取行动来保证高可用。
如果状态决策本身都是有错误或者有偏差的,那么后续的任何行动和处理无论多么完美也都没有意义和价值。但在具体实践的过程中,恰好存在一个本质的矛盾:通过冗余来实现的高可用系统,状态决策本质上就不可能做到完全正确。
- 独裁式
独裁式的决策方式不会出现决策混乱的问题
- 协商式
最常用的协商式决策就是主备决策
协商式决策的架构不复杂,规则也不复杂,其难点在于,如果两者的信息交换出现问题(比如主备连接中断),此时状态决策应该怎么做。基本上很难搞定。
- 民主式
民主式决策和协商式决策比较类似,其基础都是独立的个体之间交换信息,每个个体做出自己的决策,然后按照“多数取胜”的规则来确定最终的状态。不同点在于民主式决策比协商式决策要复杂得多,ZooKeeper 的选举算法 ZAB,绝大部分人都看得云里雾里,更不用说用代码来实现这套算法了。
除了算法复杂,民主式决策还有一个固有的缺陷:脑裂。为了解决脑裂问题,民主式决策的系统一般都采用“投票节点数必须超过系统总节点数一半”规则来处理。
复杂度来源:可扩展性
设计具备良好可扩展性的系统,有两个基本条件:正确预测变化完美应对变化
- 方案一:提炼出“变化层”和“稳定层”
- 方案二:提炼出“抽象层”和“实现层”
1 写 2 抄 3 重构原则
复杂度来源:低成本、安全、规模
架构设计三原则
合适原则、简单原则、演化原则
- 合适原则宣言:“合适优于业界领先”。
- 简单原则宣言:“简单优于复杂”。
- 演化原则宣言:“演化优于一步到位”。
架构设计流程1:识别复杂度
将主要的复杂度问题列出来,然后根据业务、技术、团队等综合情况进行排序,优先解决当前面临的最主要的复杂度问题
架构设计流程2:设计备选方案
- 备选方案的数量以 3 ~ 5 个为最佳
- 备选方案的差异要比较明显
- 备选方案的技术不要只局限于已经熟悉的技术
架构设计流程3:评估和选择备选方案
列出我们需要关注的质量属性点,然后分别从这些质量属性的维度去评估每个方案,再综合挑选适合当时情况的最优方案。
常见的方案质量属性点有:性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。在评估这些质量属性时,需要遵循架构设计原则 1“合适原则”和原则 2“简单原则”,避免贪大求全,基本上某个质量属性能够满足一定时期内业务发展就可以了。
正确的做法是按优先级选择,即架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素,将质量属性按照优先级排序,首先挑选满足第一优先级的,如果方案都满足,那就再看第二优先级……以此类推
架构设计流程4:详细方案设计
详细设计方案阶段可能遇到的一种极端情况就是在详细设计阶段发现备选方案不可行,一般情况下主要的原因是备选方案设计时遗漏了某个关键技术点或者关键的质量属性
- 架构师不但要进行备选方案设计和选型,还需要对备选方案的关键细节有较深入的理解。
- 通过分步骤、分阶段、分系统等方式,尽量降低方案复杂度
- 如果方案本身就很复杂,那就采取设计团队的方式来进行设计,博采众长,汇集大家的智慧和经验,防止只有 1~2 个架构师可能出现的思维盲点或者经验盲区。
本文作者:Blue Mountain
本文链接:https://www.cnblogs.com/BlueMountain-HaggenDazs/p/18210431
版权声明:本作品采用知识共享署名-非商业性使用-禁止演绎 2.5 中国大陆许可协议进行许可。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步