一、架构到底指什么？

架构师顶层设计；
框架是面向编程或配置的半成品；
组件是从技术维度上的复用；
模块是从业务维度上职责的划分；
系统是相互协同可运行的实体；

框架偏技术，框架可以说是一种开发规范，是一种开发思路，引用于系统或子系统中，使得开发人员能快速设计出程序编写的代码组织结构；而架构相对偏业务一点，是针对业务需求，分解整个系统，梳理出数据流转逻辑，有哪些子系统、子模块、组件组成，他们之间相互关系是怎么样的，需要更多的考虑未来需求的变化，考虑系统的可扩展性，可靠性，容错性等。

二、架构设计的历史背景

20世纪60年代第一次软件危机引出了“结构化编程”，创造了“模块”概念；
20世纪80年代第二次润健危机引出了“面向对象编程”，创造了“对象”概念；
到了20世界90年代“软件架构”开始流程，创造了“组件”概念。我们可以看到，“模块”，“对象”，“组件”本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的颗粒度越来越粗，拆分的层次越来越高。

在古代的狼人传说中，只有用银质子弹（银弹）才能制服这些异常凶残的怪兽。在软件开发活动中，“银弹”特指人们渴望找到用于制服软件项目这头难缠的“怪兽”的“万能钥匙”。
软件开发过程包括了分析、设计、实现、测试、验证、部署、运行等过个环节。从IT技术的发展历程来看，先辈们在上述不同的环节中提出过很多在当时看来很先进的方法与理念。但是，这些方法、理念在摩尔定律、业务创新、技术发展面前都被一一验证了以下观点：我们可以通过出多方式去接近“银弹”，但很遗憾，软件活动中没有“银弹”。
布鲁克斯发小《人月神话》三十年后，又写了《设计原本》。他认为一个成功的软件项目的最重要因素就是设计，架构师、设计师需要在业务需求和IT技术中寻找到一个平衡点。个人觉得，对于这个平衡点的把握，就是架构设计中的取舍问题。而这种决策大部分是靠技术，但是一定程度上也依赖于架构师的“艺术”，技术可以依靠工具、方法论、管理模式去提升，但是“艺术”无法量化，是一种权衡。
软件设计过程中，模块、对象、组织本质上是对一定规模软件在不同颗粒度和层次上的“拆分”方法论，软件架构是一种对软件“组织”方法论。一分一合，其目的是为了软件研发过程中的成本、进度、质量得到有效控制。但是，一个成功的软件设计师要适应并满足业务需求，同时不断“演化”的。设计需要根据业务的变化、技术的发展不断进行“演进”，这就决定了这是一个动态活动，出现新问题，解决新问题，没有所谓的“一招鲜”。
以上只是针对设计领域的银弹讨论，放眼到软件全生命周期，银弹问题会更加突出。
小到一个软件开发团队，大到一个行业，没有“银弹”，但是“行业最佳实践”可以作为指路明灯，这个可以有。

软件开发最本质的挑战有两个：复杂和变更，而软件的价值是保证业务的向应力，而与之相对的是开发资源的有限。而各种的软件开发方法论，也都是在研究有限的资源下，如何应对这两个挑战，寻找平衡点，实现业务目标，因为是寻找平衡点，就说明是有取舍的，所有就没有所谓的银弹存在。

软件本身的复杂度难以衡量，随着时间和规模发展，原有的方案很快难适应，人们就不断总结经验模式和设计解决新困难的办法，但是不管什么样的架构设计都是在尽量满足适应我们可能遇到的问题的解决方案，不是解决问题方案。生活中我们的应用从单体到主备再到集群、分布式、微服务最后到最新的ServiceMesh ,这些其实都是解决和改善、完善、优化我们在软件开发过程中遇到的问题。

为什么我们在谈“架构”，他不是平白无故产生的，他是在一定背景下产生的。更好的理解他产生的原因，会在具体解决问题的时候有的放失。直到现在才看明白，what, why, how 。这真实一个认清事物最本质的三步。

三、架构设计的目的

架构设计的误区

1.因为架构很重要，所以要做架构设计；
2.公司流程要求系统开发过程中必须要有架构设计；
3.为了高性能、高可用、高扩展，所以要做架构设计

架构设计的真正目的

架构设计师为了应对软件系统复杂度而提出的一个解决方案，通过回顾架构产生的历史背景和原因，我们可以基本推导出答案： 架构设计的主要目的是为了解决软件系统复杂度带来的问题。 理解每个架构方案背后所需要解决的复杂点，然后才能对比自己的业务复杂点，参考复杂点相似的方案。

架构是为了应对软件系统复杂度而提出的一个解决方案。个人感悟是：架构即（重要）决策，是在一个有约束的盒子里去求解或接近最合适的解。这个有约束的盒子是团队经验，成本、资源、进度、业务所处阶段等所编织、掺杂在一起的综合体（人、财、物、时间，事情等）。架构无优劣，但是存在恰当的架构用在合适的软件系统中，而这些就是决策的结果。

需求驱动架构。在分析设计阶段，需要考虑一定的人力与时间去“跳出代码，总览全局”，为业务和IT技术之间搭建一座“桥梁”。

架构设计处于软件研制的前期，一方面，越是前期，如有问题，就能够越早发现，修改的代价也就越低；另一方面，也意味着，软件实施后期若有架构上的修改，也需要付出更多的代价。

业务架构和业务量级应该算是“软件系统复杂度带来问题”的具体化呈现。业务架构和业务量级都是从每个具体项目的实际应用场景中提炼出来的。业务架构是对业务需求的提炼和抽象，开发软件必须要满足业务需求，否则就是空中楼阁。软件系统业务上的复杂问题，可以从业务架构的角度切分工作界面来解决。设计软件架构，首先是要保证能和业务架构对的上，这也是从业务逻辑转向代码逻辑的过程，所以软件架构的设计为开发指明了方向。另外架构设计也为接下来的开发工作分工奠定了基础。

业务量级表现在存储能力、吞吐能力和容错能力等，主要是软件运维期业务的复杂度。做软件架构设计，是要保证软件有能力托起它在业务量级上的要求的，如果软件到运行使用期废了，那么前面的所有工作都付诸东流了。不同的业务量级，对应的软件的架构复杂度是不同的，所以对于不同的项目，业务量级不同，架构设计也不同。

每个软件在开发前，都要结合自己的应用场景设计适合自身的软件架构，现成的架构方案只能借鉴，不能直接套用。另外，由于业务架构和业务量级也会不断调整或长大，软件架构也不是一劳永逸的，会随业务不团调整。

今日得到：
①.架构是为了应对软件系统复杂度而提出的一个解决方案。
②.架构即（重要）决策。
③.需求驱动架构，架起分析与设计实现的桥梁；
④.架构与开发成本的关系。