软件架构设计系列一
2024-06-21 11:18:14 0 举报AI智能生成
来自极客时间-从0开始学架构课程
作者其他创作
大纲/内容
原则
合适原则：根据所拥有的的资源来酌情设计
团队规模
平均技术水平
研发周期
简单原则：简单优于复杂
避免进入复杂度陷阱
简单代表更少的故障点
更清晰的逻辑
随时注意控制复杂度！
演进原则：演进优于一步到位
对于软件来说，变化才是永恒
没有完美的方案
案例
淘宝技术发展
“个人网站”→“Oracle/ 支付宝 / 旺旺”→“Java 时代 1.0”→“Java 时代 2.0”→“Java 时代 3.0”→“分布式时代”
开始的2个阶段是买买买，从第三个阶段开始自研，总体遵循上述原则
流程
1. 识别复杂度（根据右边列出的几个来源）
子系统太多？
业务逻辑太复杂，代码耦合严重？
当前集群性能不足？
存在单点故障？
引入语言过多？
。。。这是架构师的基本能力
2. 设计备选方案
备用
避免思维局限
没有完美方案
3. 评估备选方案（最难）
1. 按优先级列出需要考虑的每个方案的质量属性，如成本、性能、研发周期等
2. 按优先级得分评选方案
4. 详细方案设计
将方案涉及的关键技术细节给确定下来
案例：基于MySQL的消息队列方案
1. 确定分库分表方案：日志表和消息表
2. 发布消息时的写入顺序：先写日志表，由后台线程转写消息表
3. 表结构：日志表包含日志 ID。。消息表包含消息 ID（递增生成）。。
4. 存储机制：日志表需要及时清除已经写入消息表的日志数据，消息表最多保存 30 天的消息数据。
5. 数据如何复制：只复制消息表即可
6. 主备服务器如何倒换：使用zk来做主备决策
7. 业务服务器如何写入消息：提供SDK给各业务系统调用，SDK处理消息服务器细节
等等
来源：极客时间-从0开始学架构
本质
梳理概念
系统与子系统
系统：由一群有关联的个体组成，根据某种规则运作，具备更强的能力
子系统：概念不便，观察角度不同
子系统包含模块和组件
模块与组件
模块：从逻辑的角度来拆分系统后，得到模块
目的是职责分离
组件：从物理的角度来拆分系统后，得到组件
目的是单元复用
框架与架构
框架：是一种遵循规范的产品。例如Spring MVC框架遵循MVC规范
架构：是结构组成的总结描述
目的
为了解决软件系统复杂度带来的问题！
要考虑人员数量、水平、需求紧急度来酌情取舍！
不能教条式的设计架构，不考虑实际情况！
高铁比动车快，但维护成本更高！
理想目标
高性能、高可用、可扩展、安全性！
复杂度来源
高性能
计算机内部
进程、线程；多进程通信机制
多核并行方案：SMP/NUMA/MPP
多台计算机（集群）
流量分配
硬件：F5、交换机
算法
随机、轮训、加权轮训、最少连接数、加权最少连接
IP Hash、一致性Hash、地理位置、最少延迟
软件：LVS、Nginx和HAProxy
高可用
本质：系统无中断地执行其功能的能力！
核心实现方式：“冗余”
多进程、多机器、多机房、多通道
计算高可用、存储高可用
状态决策方式
独裁式：存在单点故障，适合小项目
协商式：容易脑裂。一般是人工切换主备
民主式：多数取胜，小概率脑裂可能。实现算法复杂，如Paxos
由于CAP原理，没有完美方案，需要进行取舍！
可扩展
本质：为了应对将来需求变化！
表现：当有新的需求出现时，系统不需要或者仅需要少量修改就可以支持。
实现方式
正确预测变化
没有通用的标准，依赖个人经验、直觉。
完美封装变化
拆分变化层和稳定层，抽象接口来连接不同层次
善用设计模式！
安全
功能安全
SQL注入、XSS攻击、CSRF攻击、中间人攻击
脱库、服务器入侵
架构安全
DoS/DDoS
防火墙功能强大，但性能一般
传统企业和银行可以使用防火墙
互联网系统由于高并发访问，所以没法使用防火墙。一般通过切换IP解决
可维护
拆分子系统（以微信为例）
网关、注册登录、IM消息、摇一摇等。
方便单独对个别子系统进行扩展
控制粒度，避免过长调用链增加延时！
低成本
当架构涉及上百台机器时，合理的涉及可以显著降低成本！
作为架构设计的附加约束，可以避免无脑扩张机器！
原则：先确定成本目标，再设计方案。
规模
功能数量
功能数量越来越多，导致系统复杂度指数级上升
数据规模
海量数据的收集、加工、存储、分析都需要新技术的引入
误区
设计最优秀的方案
只做一个方案
不要局限于已经熟悉的技术
备选方案考虑过多细节
0 条评论
下一页
