关于架构设计

架构设计

架构设计的主要目的：
解决复杂度带来的问题

架构复杂度来源

1. 孜孜不倦追求 高性能\
   所有性能提高的背后，都是方法的优化和系统复杂度的提高

2. 防止意外的高可用\
   系统高可用 本质通过冗余，水多加面，面多加水

3. 应对变化的可拓展\
   保障在不重构的情况下，为需求变化提供实现可能

高性能、高可用性、可拓展，是架构师工作着重考虑缓解，三点直接作用于 架构设计内部

同样要注意 外部环境 对架构设计影响，比如安全性、成本、规模

找出业务场景短板

面对实际业务场景

第一步 分析并确定架构方向

需要 高可用? 高性能? 可扩展? 安全?

第二步 准备几套备用方案

与开发 运维等部门讨论，选择针对实际情况最优方案

虚拟场景

前浪微博 中间件 团队 6人
整体熟悉 JAVA，一人 C/C++
开发平台 Linux
数据库 MySQL
业务系统 单机房部署

p.s: 发展快 系统协作效率低 各子系统 通过接口调用 出现问题 难定位

架构设计问题根源 在于 各个业务 子系统 强耦合, 信息列队系统 可满足 子系统 解耦

架构难在哪里?

难在灵活多变。高性能、高可用、可拓展、安全性、规模 等, 不可能样样兼顾

判断复杂度

对关键点 分权重

1. 是否需要高性能？\
   目前，发展趋势，预留系统容量 应对 未来业务增长。设计目标定为现在峰值4倍 较为合理

2. 是否需要高可用？\
   信息审核、用户服务 是社交媒体 关键业务。信息列队 需要 高可用性，包括 信息写入、消息储存、消息读取

3. 是否需要高扩展？\
   本虚拟场景 前浪微博 消息列队 功能明确，基本无须拓展

初步设计备选方案，分析优缺点

综上，前浪微博 信息列队系统 需要 高性能 消息读取、高可用 消息写入、高可用 消息存储和读取

3种备选方案

1. 开源Kafka 本身是 成熟的开源信息列队方案，性能好
2. 集群 + MySQL存储。采用 数据分散集群架构，省略
3. 集群 + 自研存储方案