同样是笔记摘录自---极客时间 李运华 《从0开始学架构》。
0、引言
专栏作者定义：软件架构指软件系统的顶层结构。
这个其实很宽泛，个人理解：软件架构就是软件系统的一个顶层设计，是在一系列前提条件（约束）下，对系统整体结构的一个粗线条结构的决策结果，涉及到组成系统的各部分的划分、系统运作规则、各部分之间的协作规则。如果系统很小，其实就无所谓架构不架构。简单来说，架构设计其实就是：划分结构组成 + 确定协作规则。
和框架等相比，框架是一个具体的技术实现，例如SSH框架、MVC框架等。架构可以基于某个框架来实现。系统拆分成子系统；子系统拆分成模块。或者系统划分成一系列组件。这些都可以作为软件架构设计的重要内容。涉及到系统关联部分的划分原则；就是结构的部分。另外一个部分，就是确定系统的工作流程、各部分的协作规则（包括唯一性确认机制、通信机制、数据交互机制等。）
一、复杂度来源
1、高性能：单机要考虑多进程、多线程等方案，带来进程间同步、多线程并发等复杂性；集群要考虑任务分配、任务分解等复杂性问题；架构设计之外，在具体的逻辑实现上，要考虑各种算法优化和程序优化。
2、高可用：可靠性范畴，计算高可用要采取冗余机制和同步机制；存储高可用要重点解决数据一致性和数据丢失问题。其实高可用是比高性能要更难解决一些的问题。常见解决方案有：多机房、主备、同城多活、异地多活等。
3、可扩展：系统需要拆分出变化层和稳定层；需要设计变化层和稳定层之间的接口，完美地封装变化层，尽量实现接口稳定。
4、其它：
4.1低成本：一般要通过创新来解决问题。不断优化可以在模块层面解决一些问题。
4.2安全：安全可以分为两类：一类是功能上的安全，要解决各类软件漏洞，这个其实不属于架构设计领域；一类是架构上的安全，确保功能域划分合理，方便实现安全防护。
4.3规模：规模带来复杂度的主要原因就是“量变引起质变”，当数量超过一定的阈值后，复杂度会发生质的变化。常见的规模带来的复杂度有：1. 功能越来越多，导致系统复杂度指数级上升；需要拆分子系统、新服务；2. 数据越来越多，系统复杂度发生质变。需要分库分表。
4.4 其它 如：跨地域带来的国际化问题等；兼容性带来的逻辑复杂性
二、三个基本原则：合适原则、简单原则、演化原则。
合适原则：一般来说，架构要适合业务特点、业务规模、人力资源情况、投入资金、时间、技术积累等各方面的限制。不要幻想高大上，一上来就来个业界领先、世界首创什么的。
Q：不得不受制于内部竞争资源、对外宣传等，要加入一些噱头。这时候怎么办？
A：好好评估一下，这些如果是老大要求的，就不是技术问题，而是政治问题，必须实现则属于“各方面限制”，就是软件需求中的关键干系人的要求。合适的要求是，架构师本人不要去盲目追求高大上和新潮，不能说服老大或老大的老大，则只能接受。
简单原则：敏捷宣称的 简单优于复杂。软件结构复杂或者逻辑复杂都容易带来设计困难，以及后期维护、扩展等方面的问题。
演化原则：演化优于一步到位。 其实和合适、简单是一脉相承的。
三原则说穿了就是放下面子，先干出来再说。后面根据情况，业务发展了，该优化的优化，该重构的重构，该推倒重来的推倒重来。还是敏捷的道理是相通的。
三、设计步骤
1）识别复杂度：针对上述的高性能、高可用、可扩展、安全、规模等各个方面，分析复杂度关键点，确定主要矛盾。
2）提出备选方案：针对识别出来的关键点，参考业界方案，提出合适、简单的可选方案
3）评估备选方案：常见的有最简派、最牛派、最熟派、领导派。其实最好就是360度环评，召集开发、测试、运维、业务开会，各方代表来从几个方面发表意见。开发团队一般会选最熟悉的，运维团队、测试团队一般会选最简单的，业务团队会选最牛B的或者领导喜欢的。综合一下，从几个角度打分，对照关键复杂度看看，基本可以评估出来，最后交领导审批好了。
4）设计详细方案。细化到可以实施的程度。对主要的数据库表设计、通信消息设计、业务流程设计、关键操作设计。
