架构设计三大原则
合适原则
合适优于业界领先
简单原则
简单优于复杂【结构复杂性、逻辑复杂性】
- 结构复杂性：组件数量多，组件之间的关系复杂。某个组件改动会影响关联所有组件。定位问题较难
- 逻辑复杂性：系统庞大，多人维护，分支合并覆盖，冲突解决，版本处理，定位问题。采用了复杂的算法，难以理解，实现，修改，解决
演化原则
软件架构需要根据业务发展不断变化，容易陷入试图一步到位的误区。
- 满足当前业务需要
- 要在实际应用中迭代，保留优秀的设计，修复有缺陷的设计
- 当业务发生变化时，架构要扩展、重构、重写；代码或许会重写，但是经验、逻辑、设计会在架构中延续
架构设计流程
识别复杂度
正确分析系统复杂性，后续的设计方案才不会偏离方向;
业务复杂度主要来源：高性能、高可用、可扩展等几个方面。绝大多数场景下复杂度只是其中一个，如果复杂度存在多个，则按照优先级来解决。
可能存在解决了排在最前优先级的复杂度后，后面的复杂度方案需要将以落地的方案推倒重来。原因在于软件系统的可塑性和易变性。
同一个复杂度的针对方案由多个，可以挑性价比较高的方案。
一般能达到理想状态方案的方法就是新技术引入。Hadoop就是将高可用、高性能、容量三个大数据处理复杂度问题同时解决
设计备选方案
备选方案关注技术选型而非技术设计，备选方案的技术选型差异要比较明显
评估备选方案
1. 备选方案特点：a. 每个方案都是可行的 b.没有哪个方案是完美的 c.评价标准主观比较强
2. 选择方案类型：a. 最简派 b. 最牛派：性能高、可用性强、可扩展 c. 最熟派 d. 领导派
3. 选择方案方法： 通过质量属性，挑选适合当前业务的方案
a.常见的质量属性 —— 性能、可用性、硬件成本、项目投入、复杂度、可扩展、安全性等。根据架构设计三大原则1，2，避免贪大求全.
b. 如何避免过度设计导致投入浪费? —— 要求某个质量属性能够满足一定时期内业务发展就可以了；考虑设计三大原则3。
- 质量属性评估和业务发展有很大关系。理想状态：简单的扩容就能跟的上业务的发展。但是往往量变引起质变
- 业务背景
c.备选方案设计 a. 横向扩展 b. 系统拆分 c. 360度环评（一目了然看到各个方案优缺点）a. 错误对比法： 优点数量对比法、质量属性加权法 b. 正确对比法： 按优先级选择
4. 详细的设计方案: 通过分步骤、分阶段、分系统的方式降低方案的复杂度
架构重构
系统架构师不断演化的，少部分需要推倒重写，绝大部分时通过重构来实现的。相比全新的架构，重构的要求更高
通常会遇到的问题
- 业务已上线
- 关联方众多
- 旧架构的约束：限制新架构的选择范围，即使重新设计也会瘦旧架构的影响，因为就架构产生的数据不可能推倒重来，需要考虑旧数据的转换
当系统架构不满足业务发展时，其表现形式就是不断出现各种问题。重构分析时会感觉到处是问题，要解决所有的问题无能为力。通过重构解决所有问题时不现实的，所以首要任务是从一堆问题中识别出真正想解决的问题。但是其他问题又不能不解决
解决方案
- 解决不合理的耦合
- 解决全局单点的可用性问题
- 解决大系统带来的开发效率问题
- 需要其他部门配合
只针对复杂性解决问题，还是无法落地，除了识别复杂度还需要知道为了解决这个问题，需要做哪些准备项？
- 区分优先级
- 问题分类
- 碍于业务版本压力，挑简单的实施 架构重构需要采取分段实施的策略，根据优先级，重要性，实施难度等划分为不同的阶段，每个阶段聚焦于整体目标
