如何学习架构

编程需要掌握的技能：

技术+业务+架构
职业等级晋升答辩的时候，也是需要熟练掌握上面三个部分，特别是技术和架构

技术方面，程序设计的关键思维是逻辑与实现，是代码层面的设计
架构方面，关键思维判断与取舍，是整体技术组合框架上的设计

学习一门编程语言：

先学习一下基本的语法；
研究一下细节和设计原理；
实践一下就能够快速掌握；
技术解决了什么问题？解决的思路是什么，怎么解决的？技术使用实践会产生什么问题，有什么缺陷和限制？

学习架构设计：

开始接触架构设计 ---> 我感觉初步完整掌握架构设计 ---> 自我感觉彻底掌握架构设计的精髓
架构设计本身的一些特性导致架构设计不容易掌握：

架构设计的思维和程序设计的思维差异很大。架构设计的关键思维是判断和取舍，程序设计的关键思维是逻辑和实现。

架构设计没有体系化的培训和训练机制。

程序员对架构设计的理解存在很多误区。例如：要成为架构师必须要有很强的技术天分；架构师必须有很强的创造力；架构设计必须要高大上才能体现架构师能力；架构一定要具备高可用、高性能……这些似是而非的误区让很多技术人员望而生畏，还没尝试就已经放弃了。

一套架构设计方法论：

有了这套方法论后，首先，我自己在做架构设计的时候游刃有余，不管什么样的业务，不管什么样的技术，按照这套方法论都能够设计出优秀的架构。
在职业等级面评的时候，就算我之前从来没有接触过对方的业务，也能快速理解对方描述的架构和发现其中做得好或者做得不好的地方；其次，在指导其他同事的时候效果明显。原来对架构设计比较迷茫的同学，通过几次结合案例进行的方法论培训，都能够很快地掌握这套方法论并在实践中应用。
整套架构设计方法论和架构实践，主要包括以下内容：

● 架构基础：介绍架构设计的本质、历史背景和目的，然后从复杂度来源以及架构设计的原则和流程来详细介绍架构基础。
● 高性能架构模式：从存储高性能、计算高性能方面，介绍几种设计方案的典型特征和应用场景。
● 高可用架构模式：介绍 CAP 原理、FMEA 分析方法，分析常见的高可用存储架构和高可用计算架构，并给出一些设计方法和技巧。
● 可扩展架构模式：介绍可扩展模式及其基本思想，分析一些常见架构模式。
● 架构实战：将理论和案例结合，帮助你落地前面提到的架构原则、架构流程和架构模式。

获：
● 清楚地理解架构设计相关的概念、本质、目的，避免架构师在实践过程中把握不住重点、分不清主次，眉毛胡子一把抓，导致架构设计变形或者“四不像” 。
● 掌握通用的架构设计原则，无论是何种业务或技术，架构师在判断和选择的时候有一套方法论可以参考，避免架构设计举棋不定，或者拍脑袋式设计。
● 掌握标准的架构设计流程，即使是刚开始做架构设计的新手，也能够按照步骤一步一步设计出合适的架构，避免某些步骤缺失导致错误的架构设计。
● 深入理解已有的架构模式，做到能够根据架构特点快速挑选合适的模式完成架构设计，或者在已有的模式上进行创新，或者将已有的模式组合出新的架构。
● 掌握架构演进和开源系统使用的一些技巧。

掌握架构设计的技巧，更好地设计出优秀的架构，实现自己心中的技术梦想！
毕竟，只要你努力，技术的梦想一定会实现！

架构设计的历史背景：

软件逻辑的复杂性
业务带来的软件扩展性

高级语言的出现：（20 世纪 50 年代）

高级语言的出现，只要关注具体的问题和业务即可。不需要再去关注机器底层的复杂结构和逻辑；
通过编译程序的处理，高级语言可以被编译为适合不同 CPU 指令的机器语言。程序员只要写一次程序，就可以在多个不同的机器上编译运行，无须根据不同的机器指令重写整个程序。

第一次软件危机与结构化程序设计：（20 世纪 60 年代~20 世纪 70 年代）

问题：软件逻辑的复杂性
随着软件的规模和复杂度的大大增加，软件质量低下、项目无法如期完成、项目严重超支等，因为软件而导致的重大事故时有发生。
解决：结构化程序设计方法

采取“自顶向下、逐步细化、模块化”的指导思想。结构化程序设计本质上还是一种面向过程的设计思想，但通过“自顶向下、逐步细化、模块化”的方法，将软件的复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。

第二次软件危机与面向对象（20 世纪 80 年代）

问题：业务带来的软件扩展性
● 第二次软件危机的根本原因还是在于软件生产力远远跟不上硬件和业务的发展。
● 第一次软件危机的根源在于软件的“逻辑”变得非常复杂，而第二次软件危机主要体现在软件的“扩展”变得非常复杂。
结构化程序设计虽然能够解决（也许用“缓解”更合适）软件逻辑的复杂性，但是对于业务变化带来的软件扩展却无能为力，软件领域迫切希望找到新的银弹来解决软件危机，在这种背景下，面向对象的思想开始流行起来。
解决：面向对象的软件思想解决业务变化带来的软件扩展；

软件架构的历史背景：

与之前的各种新方法或者新理念不同的是，“软件架构”出现的背景并不是整个行业都面临类似相同的问题，“软件架构”也不是为了解决新的软件危机而产生的，这是怎么回事呢？
随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题。

软件规模大后会遇到强耦合导致开发效率低下，难修改和拓展，容易出错等问题，因此需要软件架构设计。
这段话很好地解释了“软件架构”为何先在 Rational 或者 Microsoft 这样的大公司开始逐步流行起来。因为只有大公司开发的软件系统才具备较大规模，而只有规模较大的软件系统才会面临软件架构相关的问题，例如：

系统规模庞大，内部耦合严重，开发效率低；
系统耦合严重，牵一发动全身，后续修改和扩展困难；
系统逻辑复杂，容易出问题，出问题后很难排查和修复。
软件架构的出现有其历史必然性：
● 20 世纪 60 年代第一次软件危机引出了“结构化编程”，创造了“模块”概念；
● 20 世纪 80 年代第二次软件危机引出了“面向对象编程”，创造了“对象”概念；
● 到了 20 世纪 90 年代“软件架构”开始流行，创造了“组件”概念。
我们可以看到，“模块”“对象”“组件”本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的粒度越来越粗，拆分的层次越来越高。

为何结构化编程、面向对象编程、软件工程、架构设计最后都没有成为软件领域的银弹？

软件开发过程包括了分析、设计、实现、测试、验证、部署、运维等多个环节。
软件本身的复杂度难以度量，随时间和规模发展，原有的解决方案很快难适应，人们就不断总结经验模式和设计解决新困难的办法，但是不管什么样的架构设计都是在尽量满足适应我们可能遇到的问题的解决方案，不是解决问题方案。生活中我们的应用从单体到主备再到集群、分布式、微服务最后到最新的Service Mesh，这些其实都是解决和改善、完善、优化我们在软件开发遇到的问题。There is no silver bullet.
软件设计过程中，模块、对象、组件本质上是对一定规模软件在不同粒度和层次上的“拆分”方法论，软件架构是一种对软件的“组织”方法论。一分一合，其目的是为了软件研发过程中的成本、进度、质量得到有效控制。但是，一个成功的软件设计是要适应并满足业务需求，同时不断“演化”的。设计需要根据业务的变化、技术的发展不断进行“演进”，这就决定了这是一个动态活动，出现新问题，解决新问题，没有所谓的“一招鲜”。
小到一个软件开发团队，大到一个行业，没有银弹，但是“行业最佳实践”可以作为指路明灯，这个可以有。
软件开发最本质的挑战有两个:复杂和变更，而软件的价值是保证业务的响应力，而与之相对的是开发资源的有限，而各种的软件开发方法论，也都是在研究有限的资源下，如何应对着两个挑战，寻找平衡点，实现业务目标，因为是在寻找平衡点，就说明是有取舍的，所以就没有所谓的银弹的存在。
变化才是唯一的不变，所以银弹不会存在，，“银弹”产生于一定的历史背景和大环境，而历史和环境总是会变化的