架构设计
2024-10-28 17:27:48 1 举报AI智能生成
这是一个关于架构设计的描述。架构设计是一个系统、平台或软件的基础结构，它定义了各个组件之间的关系和交互方式。架构设计关注于整个系统的全局视图，包括组件的划分、接口的定义、数据的流动以及系统的性能和安全性。一个良好的架构设计可以提高系统的可扩展性、可维护性和可靠性，同时也能够降低开发成本和周期。在我们进行架构设计时，需要考虑到业务需求、技术选型、可扩展性、可维护性等多个方面，以确保架构设计的质量和可靠性。
作者其他创作
大纲/内容
架构的定义
系统
系统泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能单独完成的工作的群体
1、关联
关联是由一群有关联的个体组成，没有关联的个体堆在一起不能成为一个系统
2、规则
系统内的个体需要按照指定的规则运作，而不是单个个体各自为政，规则规定了系统内个体分工和协作的方式
3、能力
系统能力与个体能力有本质的差别，系统能力不是个体能力之和，而是产生了新的能力
子系列
子系统也是由一群有关联的个体所组成的系统，多半是更大系统中的一部分。例如：微信本身是一个系统，包括聊天、登录、支付等子系统
模块
软件模块（Module）是一套一致而互相有紧密关联的软件组织。它包含了程序和数据结构两部分，软件开发往往利用模块作为合成的单位。模块的接口表达了由该模块提供的功能和调用它时所需要的元素
组件
软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元
框架
软件框架（Framework）通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求的基础功能的软件产品
框架是组件规范
框架提供基础功能的产品
架构
软件架构指软件系统的基础结构，创造这些基础结构的准则，以及对这些结构的描述
总结
架构是顶层设计；框架是面向编程或配置的半成品；组件是从技术维度上的复用，模块是从业务维度上职责的划分；系统是相互协同可运行的实体
系统与子系统：系统是由一系列有关联按特定规则组成的个体，并且产生新的能力，而系统与子系统则是观察的角度不同
模块与组件：模块是从逻辑角度去看待而组件是从物理角度去看待
框架与架构：框架是规范也是约束，可以理解为封闭性的话题，定义好，让别人如何去使用，而架构是一种结构，是一种开放性的话题，如何去设计组织架构，如何让架构更具有拓展性，减少沟通错误成本
架构设计的目的
纵观整个软件技术发展的历史，其实就是一部与"复杂度"斗争的历史，架构也是为了应对软件系统复杂度而提出的一个解决方案。
架构设计的主要目的是为了解决软件系统复杂度带来的问题
复杂度来源
高性能
单机复杂度
进程
Redis采用的是单进程
线程
JBoss、Memcache采用的是多线程
多任务并行
集群复杂度
任务分配
每台机器都可以处理完整的业务任务，不同的任务分配到不同的机器上执行
任务分配器
硬件网络设备【F5】
软件网络设备【LVS】
负载均衡软件【Nginx、HAProxy】
自己开发的系统
任务分配算法
轮询算法
按权重分配
按负载进行分配
随着性能的增加，任务分配器本身又会成为性能瓶颈，任务分配器本身也需要扩展为多台机器
任务分配从1台变成了多台，这个变化带来的复杂度就是需要将不同的用户分配到不同的任务分配器上，常见的方法
DNS轮询
智能DNS
CDN
GSLB设备
任务分解
简单的系统更见容易做到高性能
可以针对单个系统进行扩展
高可用
定义：系统无中断地执行其功能地能力，代表系统的可用程度，是进行系统设计时的准则之一
方案：系统的高可用的方案非常多，本质上都是通过冗余来实现高可用
复杂度
计算高可用
计算的定义：计算指的是业务的逻辑处理。
计算的特点：无论在哪台机器上进行计算，同样的算法和输入数据，产出的结果都是一样的
存储高可用
难点：不在于如何备份数据，而在于如何减少或者规避数据不一致对业务造成的影响
高可用的决策状态
独裁式
明主式
协商式
任务分配器
选择需要考虑性能、成本、可维护性、可用性等各方面因素
分配算法
主备
冷备
温备
热备
主主
可扩展性
定义：系统为了应对将来需求变化而提供的一种扩展能力，当有新的需求出现时，系统不需要或者仅需要少量的修改就可以支持，无须整个系统重构或者重建
设计具备良好可扩展性的系统，有个基本条件
正确预测变化
完美封装变化
预测变化的难点
不能每个设计点都考虑可扩展性
不能完全不考虑可扩展性
预测都存在出错的可能性
封装变化
应对变化主要有两种方式
将变化封装在变化层，将不变的部分封装在稳定层
提炼出抽象层和实现层
成本
低成本本质上是与高性能和高可用冲突的，所以低成本很多时候不会是架构设计的首要目标，而是架构设计的附加约束
设计高性能、高可用的架构时，通用的手段都是增加更多的服务器来满足要求
创新
NoSql的出现是为了解决关系型数据库无法应对高并发访问带来的访问压力
全文搜索引擎的出现是为了解决关系型数据库like搜索低效的问题
Hadoop的出现是为了解决传统文件系统无法应对海量数据存储和计算的问题
安全
功能安全
架构安全
规模
规模带来复杂度的主要原因就是量变引起质变
常见的复杂度
功能越来越多，导致系统复杂度指数级上升
数据越来越多，系统复杂度发生质变
架构设计原则
合适原则
简单原则
演进原则
三原则优先级：合适优于业界领先进>演化优于一步到位>简单优于复杂
架构设计步骤
第一步：识别复杂度
优先解决当前面临的主要的复杂度问题
我们设计架构时，首先就要分析系统的复杂性。
将主要的复杂度问题列出来，然后根据业务、技术、团队等综合情况进行排序，优先解决当前面临的最主要的复杂度问题
常见系统的性能量级
Nginx负载均衡性能是3万左右
Redis的读取性能10万左右，Redis写性能8万左右
kafka号称百万级
ZooKeeper写入读取2万以上
http请求访问大概在2万左右
第二步：设计备用方案
备用架构的要点
备选方案的数量以3 ~ 5个为最佳
备选方案的差异要比较明显
备选方案的技术不要只局限于已经熟悉的技术
第三步：选择备用方案
评估和选择备选方案
通过“360度环评”来评估和选择备选方案
常见的方案质量属性点有：性能、可用性、硬件成本、项目投入、复杂度、安全性、可扩展性等。
在评估这些质量属性时，需要遵循架构设计的“合适原则”和“简单原则”
第四步：详细方案设计
0 条评论
下一页
