架构定义
软件架构指系统的顶层结构：
- 系统由一群关联个体组成，这些个体可以是子系统、模块、组件，架构需要明确系统包括哪些个体
- 系统中的个体需要根据某种规则运作，架构需要明确个体运作和协作的规则
- 框架关注的是规范，架构关注的是结构
1. 架构设计原则
- 具体的：能够具体描述解决的实际问题，不是虚无缥缈的
- 可度量：不应包括“无限”这样的词汇，具备具体的衡量指标
- 可到达：鼓舞人心的，能够在设计和执行上实现
- 现实的：符合当前团队达成目标的能力，有些可以实现的，但是需要时间或天赋
- 可测试：可以用于测试设计，以验证它是否符合需要
1.1 简单原则
大道至简
简单的架构就是最好的架构，从用户、产品、运维三个维度考量一个架构设计的是否简单。
用户：能够让小白都会使用，如果一个系统让开发接入的学习成本非常高，那么这样的产品很难被推广使用，而且使用过程中也很容易出错。
产品：架构是子系统、模块、组件之间根据某种规则运作，模块领域边界定义越清晰，自上而下的结构越清晰，这样的设计的产品本身扩展性和稳定性也越高。
运维：一个系统的正常运行离不开后期的运维，出现问题能否在很短的时间内发现并解决，与架构本身的设计有很大的关系，越简单的架构在调用链路上也越简单，排查问题也越容易。
奥卡姆剃刀
如无必要、勿增实体，即简单有效原理。
很多架构师在设计架构的时候往往会进入一个误区，认为设计的系统功能越多越好，为了将来的可能遇到的扩展添砖加瓦，导致设计的系统庞大复杂。
如何避免过度设计？每个功能在提出的时候需要认真考虑，对系统的核心没有影响，去掉也不会影响系统正常工作，那么在架构设计的时候可以直接去掉。
少即是多，多用减法设计，明确设计的系统的定位，该干什么，不该干什么，对于超越模块领域边界的职能要敢于Say NO 。
帕累托原则
二八原则简化方案，收益80%源于20%的工作 （ROI）
1.2 合适原则
合适优于业界领先！
梦想是好的，但再好的梦想，也需要脚踏实地的实现。真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大的功效，并能够快速落地。
1.3 演化原则
演化优于一步到位！
架构需要随着业务的发展而不断演化。对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。软件架构设计类似于生物演化。
