[笔记] 03 架构设计的流程

目录

• 识别复杂度
• 设计备选方案
• 评估和选择方案
• 详细方案设计
• 风险规避

识别复杂度

架构设计的本质，是为了解决软件系统复杂性。只有准确分析出了业务系统的复杂性，后续的设计才不会偏离方向。否则做的越好，就越麻烦。
将主要的复杂性问题列出来排序，优先解决最重要的1-2个问题。

设计备选方案

设计常见的3个错误：

1. 设计最优秀的方案
2. 只做一个方案
   单一方案，会出现过度辩护的情况。
   一般3-5个最佳；备选方案之间差异比较明显；不要局限于已经熟悉的技术。
3. 备选方案过于详细
   备选阶段关注的是技术选型，而不是细节。

评估和选择方案

每个方案都是可行的，否则就不应该作为备选；没有完美方案；评价标准主观性比较强，所以，评估并不容易。
采用多维度进行分析，成了容易想到的方法。但：

1. 数一数优势维度的多少来确定最终选择，显然过于粗暴；
2. 进一步会想到打分法，给每个维度打分；但不同维度的重要性都是相同的吗？明显不是。
3. 于是加权法成为最常用的方法。这个缺点是无法给每个维度客观的分配权重。
4. 正确的做法：按优先级选择。就是按照当前业务发展情况、团队情况、中短期发展预测等，将维度排序，从高优先级的满足情况开始分析评估。

详细方案设计

让最终选择的方案可以落地，确定关键技术细节。这里可能有相对小的一些方案要评估和选择。如：

1. if use ElasticSearch then 确定索引划分方式、副本数量、集群节点数量；
2. if use mysql 分表分库 then 确定哪些表要分，按什么分，分了后联合查询怎么处理等；
3. if use Nginx 做负载均衡 then 主备怎么做，均衡策略用哪个(轮询、加权轮询、ip_hash、fair、url_hash)

风险规避

架构设计最大的风险在于：备选方案不可行；比如技术复杂远超预期、或者细节太多开发周期漫长、遗漏重要质量属性等等；

1. 架构师需要对备选方案的关键细节有较深入理解，不能因为听说很牛就引入。
2. 分步骤、分阶段、分系统等方式，尽量降低方案复杂度，避免不可控。
3. 可以采用设计团队的方式，避免思维盲区和经验盲区。