软考高级架构 —— 10.6 大型网站体系架构演化实例 + 软件架构维护

10.6 大型网站体系架构演化实例

        大型网站的技能挑衅重要来自于巨大的用户，高并发的访问和海量的数据，重要办理这类题目。        
1. 单体架构

• 特点: 全部资源（应用步调、数据库、文件）会合在一台服务器上。
  
• 实用场景: 小型网站，用户和数据量较少。
  
• 限定: 随用户增长，性能和存储空间成为瓶颈。
  
• 
  
  

2. 垂直架构

• 优化: 应用步调与数据分离，分为应用服务器、文件服务器、数据库服务器。
  
• 上风:
  
  
  
  • 根据差异需求优化硬件设置（CPU、内存、硬盘）。
    
  • 数据存储和业务处理惩罚本领提升。
    
  
  
• 挑衅: 数据库压力依然会随着用户增长增长。
  
• 
  
  

3. 引入缓存

• 缘故原由: 数据访问依照“二八定律”，80%的访问会合在20%的数据。
  
• 方法:
  
  
  
  • 本地缓存：快速但受服务器内存限定。
    
  • 长途分布式缓存：支持大规模缓存，性能更稳固。
    
  
  
• 结果: 缓解数据库访问压力，但应用服务器毗连数有限，成为瓶颈。
  
• 
  
  

4. 应用服务器集群

• 办理方案: 利用负载平衡器，将用户哀求分配到多个应用服务器。
  
• 上风:
  
  
  
  • 通过横向扩展增长服务器，提升体系可伸缩性。
    
  • 不依赖更强盛的单台服务器。
    
  • 
    
    
  
  

5. 数据库读写分离

• 题目: 写利用和部门读利用仍会合在主数据库，负载高。
  
• 优化:
  
  
  
  • 主数据库负责写利用。
    
  • 从数据库通过主从复制负担读利用。
    
  • 数据访问模块实现透明的读写分离。
    
  
  
• 结果: 数据库性能进一步提升。
  

6. 反向署理与 CDN

• 目的: 缓解因地域网络差异导致的访问耽误题目。
  
• 方法:
  
  
  
  • CDN: 摆设在网络提供商机房，用户从迩来位置获取内容。
    
  • 反向署理: 缓存服务器，用户哀求优先访问署理缓存内容。
    
  
  
• 结果: 提升相应速率，低落伍端服务器负载。
  

7. 分布式文件与数据库

• 题目: 单一数据库或文件服务器无法满足一连增长需求。
  
• 办理方案:
  
  
  
  • 分布式文件体系: 将文件分布在多个服务器上。
    
  • 分布式数据库: 拆分业务数据库，淘汰单表数据规模。
    
  
  
• 结果: 支持海量数据存储与高并发访问。
  

8. 引入 NoSQL 与搜索引擎

• 缘故原由: 数据布局复杂，传统关系型数据库难以满足需求。
  
• 优化:
  
  
  
  • NoSQL: 提供分布式、弹性的数据存储。
    
  • 搜索引擎: 加速复杂数据检索。
    
  
  
• 结果: 更机动的数据存储与查询本领。
  

9. 业务拆分

• 目的: 按产物线拆分网站（如首页、订单、用户等）。
  
• 方法:
  
  
  
  • 每个产物线独立摆设为单独应用。
    
  • 应用间通过消息队列或共享数据存储体系通讯。
    
  
  
• 结果: 低落单一应用复杂度，进步团队开辟服从。
  

10. 分布式服务化

• 挑衅: 应用复杂度增高，维护资本增长。
  
• 办理方案:
  
  
  
  • 提取共用业务逻辑为分布式服务（如用户管理、订单管理）。
    
  • 应用通过服务调用完成详细利用。
    
  
  
• 结果: 简化应用间依赖关系，提升开辟与运维服从。
  

10.7 软件架构维护

•         架构知识管理：
  
  
  
  • 界说：包罗架构计划和计划决定，用于表明架构方案的选择缘故原由。
    
  • 目的：确保关键计划知识不会因职员流失或变动而丢失，支持架构的演化和恒久可维护性。
    
  • 近况：架构知识文档化实践较少，重要由于动机不敷、文档维护资本高等题目。
    
  
  
•         架构修改管理：
  
  
  
  • 创建隔离地域以最小化修改影响，明确修改规则和范例。
    
  • 追踪修改的副作用和影响范围，提升修改过程的可靠性。
    
  
  
•         架构版本管理：
  
  
  
  • 提供演化控制和度量底子，支持静态与动态演化分析。
    
  • 利用矩阵方法分析架构演化的波及效应，量化组件的贡献和影响。
    
  
  
•         架构可维护性度量：
  
  
  
  • 圈复杂度(CCN)：衡量架构复杂水平，用于早期风险评估，保举值≤10。
    
  • 扇入扇出度(FFC)：表现模块与其他模块的交互频率，高值表明模块关联麋集。
    
  • 模块间耦合度(CBO)：评估模块依赖关系的水平，高耦合模块维护风险高。
    
  • 模块相应度(RFC)：衡量模块提供的功能数量及其复杂性。
    
  • 紧内聚度(TCC) 和松内聚度(LCC)：表现模块内部组件的协作水平，评估模块内聚性。
    
  
  

评估方法与结果

• 将体系组件图导出为数据文件（如XML），利用架构评估工具盘算各项指标。
  
• 示例体系的盘算结果表现：
  
  
  
  • 高度关联的模块（如RSApplication）FFC和CBO较高，维护风险较大。
    
  • 独立模块（如User和DB）度量值较低，复杂性和耦合水平较小。
    
  • 组件内聚性仅实用于包罗子模块的组件，如ClientApplication。
    
  
  

发起与实践

•         文档化和知识管理：
  
  
  
  • 推动团队创建有用的架构知识管理机制，利用工具化本领纪录计划决定。
    
  • 定期复盘计划决定的恒久影响，提升架构演化的可猜测性。
    
  
  
•         主动化与工具支持：
  
  
  
  • 应用架构评估工具（如MSAES）主动化度量指标盘算，淘汰人工偏差。
    
  • 在计划初期及演化关键点评估CCN、CBO等指标，引导后续优化。
    
  
  
•         培训与意识提升：
  
  
  
  • 强化团队成员对架构知识纪录和分享告急性的明确。
    
  • 鼓励在开辟过程中留意长远可维护性而非短期长处。