建筑中的结构思维pdf(1、什么是软件架构)

Posted 2023-05-25

篇首语：仓廪实则知礼节，衣食足则知荣辱。本文由小常识网(cha138.com)小编为大家整理，主要介绍了建筑中的结构思维pdf(1、什么是软件架构)相关的知识，希望对你有一定的参考价值。

建筑中的结构思维pdf(1、什么是软件架构)

系统和子系统

系统泛指一群有关联的个体，根据某种规则运作，能完成个别元件不能完成的工作群体。

关联：系统由一群有关联的个体组成的，没有关联的个体堆在一块毫无意义不能称之为系统。eg1、公司里有做研发的人、运营的人、市场的人、财务的人 eg2、汽车有发动机、地盘、轮胎、车架等组合。

规则：系统内的个体需要按照指定的规则运作，而不是单个个体各自为政。eg1、研发人员写代码搞产品、运营人员负责使系统运转、市场人员跑客户开拓新业务、财务人员管钱 eg2、汽车能够前进是因为发动机将动能给到变速箱，经过转动轴带动轮胎运转。

能力：系统能力和个体能力有本质区别，系统能力大于个体能力。eg1、不要把公司的发展认为是自己业务能力强，离开公司这个平台你可能什么也不是，公司也一样可以运转，就算你很重要，最多是对公司造成一定影响 eg2、汽车可以跑，发动机、变速箱等个体不能

分层：任何系统都可以自顶向下逐层分解（分解为子系统或模块）

子系统也是由一群有关联的个体组成的系统，多半是更大系统中的一部分。

eg1、微信本身是一个庞大的系统，包含聊天、朋友圈、广告、支付、登录等等子系统。

eg2、一个电商系统由销售系统、采购系统、仓储系统、配送系统、财务系统等子系统组成。

子系统也可能根据逻辑或业务进行拆分。eg1、朋友圈子系统拆分为动态、评论、点赞等子系统，评论子系统还可以拆分为发布子系统、防刷子系统、存储子系统、审核子系统等。

当子系统不能再根据逻辑或业务进行拆分时（即最小粒度），它看起来就像是包含了多个模块或组件，这些模块或组件本身也是另外一个维度上的系统。eg、MySql、Redis等是存储系统，但不是业务子系统。

模块与组件

从逻辑的角度来拆分得到的单元就是“模块”，划分模块主要目的是职责分离。
从物理的角度来拆分得到的单元就是“组件”，划分组件主要目的是单元复用。

组件的英文component也翻译为“零件”一词，这样似乎更好理解组件的概念。

eg1、学生管理系统从逻辑角度拆分为登录模块、个人信息模块、个人成绩模块，从物理角度拆分为Nginx、Web服务器、MySql等。

eg2、maven项目中的一个module、一个微服务、代码中的package

模块是可能被分开编写的单位，由多人同时协作编写。一些大的模块也可以称之为子系统，关注重点逻辑和职责分离，模块中也可以包含一些组件作为实现的一部分。

组件可以是一个jar包、也可以是独立的子系统（对外提供某种能力的系统[有API]、MySql、Redis等）。

框架和架构

软件框架（Software Framework）通常指的是实现了某个业界标准或某个组件规范时，提供了标准或规范所要求的基础功能的软件产品。

框架是一个软件产品，对组件规范进行实现，且提供了基础功能。

eg、MVC/MVP/MVVM等都是一些开发规范和业界定的标准，对应的Spring MVC/Struts框架等除了满足MVC规范外还提供了很多基础功能（包括注解、JPA等）、Spring框架、SpringBoot框架。

软件架构（Software Architecture）是软件系统的“基础结构”或者说“顶层结构”，它定义了系统由哪些角色（Role）组成，角色之间的关系（Relation）和运作规律（Rule）。

4R架构

建筑架构与软件架构的一个核心区别就在于：建筑架构是静态的，软件架构是动态的，它由运作规则。

4R架构的应用

这个定义很简单，但包含的内容丰富。基本上把系统、子系统、模块、组件、架构等概念都串起来了。

首先，系统是由一群关联的个体（角色）组成，这些个体可以是子系统、模块、组件等。架构关注的是结构，架构需要明确系统包含了哪些个体（个体有运作规则）以及个体运作和协作的规则。

顶层结构的描述是为了区分系统架构和子系统架构，避免导致架构层次混乱。（即你负责子系统架构还是负责系统架构，根据你的岗位职责不一样，你负责哪块，对应的[子]系统架构就是顶层结构）

架构可以从不同的维度或视角进行描述（4+1视图）。

eg、MVC/MVP架构、微服务架构

架构设计的误区

为什么要做架构设计？

重要（提高开发效率，促进业务发展）：做架构设计需要投入人力和时间成本，反倒创业公司那种直接撸起袖子干效率更高啊；就算你照搬微信的架构，你就能将业务做得和微信一样好吗？
公司流程需要，不是每个系统都要做架构设计吗：不知道为什么所以无知
为了使系统可以高性能、高可用、可扩展：听起来好像有点道理，实际上这种想法很危险，不管什么系统什么业务，上来就高性能、高可用、高扩展，结果搞得系统架构设计很复杂，很难落地和维护

纵观软件的发展史，机器语音->汇编语言->高级语音->第一次软件危机与结构化程序设计->第二次软件危机与面向对象设计->[软件架构]

第一次软件危机：根源在于软件逻辑变得非常复杂，典型表现有软件质量低下、项目无法如期完成。（《人月神话》的诞生，曾几何时也提出“软件工程”并将其视作为银弹）

在古代的狼人传说中，只有用银质子弹（银弹）才能制服这些异常凶残的怪兽。在软件开发活动中，“银弹”特指人们渴望找到用于制服软件项目这头难缠的“怪兽”的“万能钥匙”。

在软件开发中，变化才是唯一的不变，所以根本不存在银弹。
软件本身没多少价值，就一坨正常人看不懂的字符代码，只有业务才能使其产生价值，就像一个人，静静地在那里默默无闻没啥用，只有产生能量，运动起来，与其他人或物产生交互才能体现其价值。
复杂和变化是软件开发过程常见的2个问题，实际开发过程往往还受资源的限制（人力、时间、硬件等成本），各种的软件开发方法论，也都是在研究有限的资源下，如何应对着两个挑战，寻找平衡点，实现业务目标。因为是在寻找平衡点的过程是有取舍的，所以压根就没啥银弹。这个取舍的过程需要有经验的架构师来，否则有了银弹还要人来作甚。

结构化程序设计：面向过程编程，采取“自顶向下、逐步细化、模块化”的指导思想

第二次软件危机：软件生产力远远跟不上硬件和业务的发展，扩展能力差。

面向对象设计：曾几何时就像当初人们看“软件工程”那样，将其视作为银弹。实际上其只是一种新的软件方法而已。

软件架构：这个概念的出现不是整个行业都面临类似危机问题而产生，而是初期在一些较大规模的公司中的一些大型开发系统出现一些问题。什么问题呢？

系统规模庞大，内部耦合严重，开发效率低
系统耦合严重，牵一发动全身，后续修改和扩展困难
系统逻辑复杂，容易出问题，出问题后很难排查和修复

随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题；当系统由许多部分组成时，整个系统的组织，也就是所说的“软件架构”，导致了一系列新的设计问题

20 世纪 60 年代第一次软件危机引出了“结构化编程”，创造了“模块”概念
20 世纪 80 年代第二次软件危机引出了“面向对象编程”，创造了“对象”概念
20 世纪 90 年代“软件架构”开始流行，创造了“组件”概念

模块、对象、组件本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的粒度越来越粗，拆分的角度越来越高。

架构设计的真正目的

纵观整个软件发展史，其实就是一部与“复杂度”斗争的历史，架构的出现也不例外。
架构设计的主要目的是为了解决复杂度带来的问题。

通过熟悉理解需求，识别系统复杂性所在的地方，然后针对这些复杂点进行架构设计。
架构设计也并不一定需要面面俱到，不是每个架构都要具备解决三高问题的能力，而要针对具体业务的复杂点进行针对性的解决问题。
理解每个架构方案背后所要解决的复杂点，根据自身情况选择合适方案。

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

某种意义上做架构设计，就是要将组成派和决策派思想进行结合。

其他心得

拿着锤子找钉子：刚学会了某个新技术总想着在项目架构中使用，而忽略了架构设计的主要目的是为了解决复杂度，可能项目中的复杂度并不在这里，无法通过这个技术解决。
项目已经处于后续的迭代过程了，除非新功能产生了新的复杂度问题，否则架构师不需要进行架构设计的参与或调整，新功能对应业务的活动图等详细设计可以由开发或初级架构师完成。