从0开始学架构-架构设计的历史背景与目的
编程语言发展历程
机器语言->汇编语言->高级语言。
软件的规模和复杂度的大大增加，出现了两次软件危机。
- 第一次软件危机与结构化程序设计（20 世纪 60 年代~20 世纪 70 年代）
- 第二次软件危机与面向对象（20 世纪 80 年代）
软件架构的历史背景
随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问
题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列
新的设计问题。
规模较大的软件系统面临软件架构相关的问题：
- 系统规模庞大，内部耦合严重，开发效率低；
- 系统耦合严重，牵一发动全身，后续修改和扩展困难；
- 系统逻辑复杂，容易出问题，出问题后很难排查和修复。
小结：
- 软件开发过程包括了分析、设计、实现、测试、验证、部署、运维等多个环节。
- 软件设计过程中，模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的“拆分”
方法论，软件架构是一种对软件的“组织”方法论。 - 架构设计，不能脱离业务、公司实际情况、人员配置、经费预算、时间投入等等与技术本身无关的因素，但却又是影响，甚至决定架构设计方向的因素。因此说没有最好，只有更合适。
架构设计的误区
- 因为架构很重要，所以要做架构设计
- 不做架构设计系统就跑不起来
- 做了架构设计就能提升开发效率
- 设计良好的架构能促进业务发展
- 每个系统都要做架构设计
- 公司流程要求系统开发过程中必须有架构设计
- 为了高性能、高可用、可扩展，所以要做架构设计
架构设计的真正目的
架构设计的主要目的是为了解决软件系统复杂度带来的问题。
如何进行架构设计
- 通过熟悉和理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计
- 架构设计并不是要面面俱到，不需要每个架构都具备高性能、高可用、高扩展等特点，而
是要识别出复杂点然后有针对性地解决问题 - 理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂
点相似的方案。 - 如果系统的复杂度不是在性能这部分，TPS 做到 10 万并没有什么用
- 淘宝的架构是为了解决淘宝业务的复杂度而设计的，淘宝的业务复杂度并不就是我们的业
务复杂度，绝大多数业务的用户量都不可能有淘宝那么大。 - Docker 不是万能的，只是为了解决资源重用和动态分配而设计的，如果我们的系统复杂
度根本不是在这方面，引入 Docker 没有什么意义。
小结
业务架构和业务量级都是从每个具体项目的实际应用场景中提炼出来的。
业务架构是对业务需求的提炼和抽象，开发软件必须要满足业务需求，否则就是空中楼阁。软
件系统业务上的复杂度问题，可以从业务架构的角度切分工作交界面来解决。
设计软件架构，首先是要保证能和业务架构对的上，这也是从业务逻辑转向代码逻辑的过程，所以软件架构的设计为开发指明了方向。
另外架构设计也为接下来的开发工作分工奠定了基础。
业务量级表现在存储能力、吞吐能力和容错能力等，主要是软件运维期业务的复杂度。
做软件架构设计，是要保证软件有能力托起它在业务量级上的要求的，如果软件到运行使用期废了，前面所有的工作都付诸东流了。
不同的业务量级，对应的软件的架构复杂度是不同的，所以对于不同的项目，业务量级不同，架构设计也不同。
做业务架构必须与其面向的实际应用场景相匹配，由于每个产品或项目的业务场景均有所不
同，所以每次做新的软件开发前，必须先设计软件架构，试图不经分析直接套用先前的架构方
案，十有八九会让当前的系统在某个点上报出大问题导致推翻重来，更不要说直接拿别人的现
成架构方案了。
所以每个软件在开发前，都要结合自己的应用场景设计适合自身的软件架构，现成的架构方案
只能借鉴，不能直接套用。
另外，由于业务架构和业务量级也会不断调整或长大，软件架构也不是一劳永逸的，会随业务
不断调整。