阅读架构漫谈笔记

阅读架构漫谈笔记

本次主要针对阅读架构漫谈整理笔记，作者围绕软件架构，从起源、定义、原因等多方面来论述，我从中得到一定的启发，下面主要针对五个问题来进行笔记整理。

问题一：什么是架构

对于什么是架构，有很多的争论，每个人都有自己的理解。甚至于很多架构师一说架构，就开始谈论什么应用架构、硬件架构、数据架构等；在Wikipedia上，架构的定义为：Architecture (Latin architectura, from the Greek ἀρχιτέκτων arkhitekton"architect"， from ἀρχι- "chief" and τέκτων "builder") is both the process and the product of planning, designing, and constructing buildings and other physical structures；意思是（拉丁语结构建筑，from the希腊ἀρχιτέκτωνarkhitekton“建筑师”，从ἀρχι“首席”和“建设者”τέκτων）is both the process and the product of规划、设计和建设，建筑和其他物理结构。从定义出发结合实际，架构实际上①根据待解决问题，对目标系统边界进行界定②对目标系统按照某个原则进行切分③对于切分出来的部分设立沟通机制④保证各个部分之间能够联系，合并组装成为一个整体，完成一定工作。这就是架构，与其他各行各业存在一定的相通之处。

问题二：为什么要出现架构

从起源上看，架构随着建筑很早就出现了，在不同行业也有一定的相通之处；针对某一个需要人执行的工作，由于每个人的时间与能力有限，而人们又想要提供系统的整体质量，这是每个人之间就有了相互的影响，如何提高个人的效率，这时就出现了架构。其实架构是人类发展过程中，由懵懵懂懂的，被动的去认识这个世界，变成主动的去认识，并以更高的效率去改造这个世界的方法

问题三：架构解决谁的问题

从根本上讲，架构解决人的问题；在实际情况下，软件其实是把现实生活模拟到计算机中，并且在计算机硬件中运行起来。从这里可以分为两类：①业务问题：找到问题的主体，他需要解决什么问题，问什么会提出这个问题等②计算机问题：如何把现实生活用软件来模拟；

模拟出来的软件，需要哪些硬件设施才能够满足要求；当访问量越来越大的时候，软件能否支持硬件慢慢长大，性能线性扩展；因为硬件是可能会失效的，软件如何在硬件失效的情况下，仍然能够保证可用性，让用户能够不中断的访问软件提供的服务；怎么收集软件产生的数据，为下一阶段的工作提供依据等等这些是计算机问题，也是需要考虑的。

问题四：什么是软件体系结构

对于架构已经有了一定的了解，当架构涉及到软件本身的业务体系，就转变到软件体系架构层面；①软件因为流量增大而分拆成不同的运行单元，在不同的机器上部署所形成的架构，属于软件架构。②每个运行单元为了让不同角色的人，比如前端，业务，数据存储等能够并行工作，所分成的代码架构，也属于软件架构。由上可知，当我们说软件架构的时候，我们一定要讲清楚，究竟说的是部署的架构，还是代码的架构。软件架构的落地，需要软件的组织架构和流程来保障。架构是进化出来的，架构实际上是在量不断的增大，超过了单台服务器的容量，逐渐的分拆，同时导致超过单个人员的能力，工作人员不断的增多，工作内容不断的分拆形成的，这本身就是架构的意义所在。

问题五：架构师是什么

针对架构师，可能会经常提到，但其意义没有我们想象那么简单。当我们所做的工作是处于社会的分工的一环，需要帮助别人解决问题，并且按时解决别人的问题成为我们自己的问题的时候，我们就有了时间压力，潜意识里会自然而然的有一种对时间的恐惧。这个恐惧在潜意识里面会想方设法推动我们采用各种手段，以便及时的完成工作，换取报酬。甚至会加班加点，不择手段。如果我们还生活在这个恐惧下面，是不可能成为架构师的。要成为架构师，必须要超越这个恐惧才能够看清楚，我们要解决的是别人的问题，不是自己完成工作的问题。所以，对自己从事的工作有足够的自信，在自己服务的领域中可以按照要求完成工作，才能成为一个合格的架构师。架构师的主要任务是发现问题，发现这些问题背后的利益关系；在此基础之上，平衡自己与他人的利益，对自己所承担任务了然于心，可以在合理的标准下达到任务要求，这也就是架构师的权利和义务所在。

整体来说，架构广泛存在于各行各业，软件体系架构有共性也有特点，架构师应该把握这些问题，处理好各方利益关系，保证任务可以按时按量完成。所以，体系架构在软件整个周期中占有非常重要的地位。