我的经历及对软件架构的理解

我个人从事软件开发8年，大大小小软件做过不计其数，做过企业应用的架构设计，也做过全新的互联网在线SaaS应用的架构设计，也做过全新的互联网网站的架构设计，现在在做的是历史遗留的大型互联网应用的架构演进工作。基于我个人先谈谈自己对于软件架构的理解谈谈软件架构。

我理解的软件架构是设计师根据软件的各种类型的需求而设计的软件组成结构的设计。

那么这些需求应该包括业务目标、用户的软件功能性需求，非功能性需求；软件开发组织内部的开发效率需求，代码质量需求；软件运维组织的系统运维需求等等综合需求和设计约束等。

软件架构的组成我理解包括软件开发期的包以及类的设计及关系，项目工程组成及它们之间的关系，发布的应用程序及之间交互关系，软件系统最终运行期间的各种终端硬件、服务器、网络设备以及网络连接设备等。

但是我觉得我们很多被称作为“架构师”的人其实天天在做开发，做架构设计可能对架构的理解也是比较片面的，比较肤浅的，有的就好比是“盲人摸象”只知道局部不知道整体，了解的内容不够系统和全面，有的就好比是”不识庐山真面目，只缘身在此山中“，在某个领域做的时间太久了，思维和认知的局限性太强，没有对具体事务进行抽象，架构的本质认识不清晰。

《软件架构设计》的评价

我最近在阅读温昱编写的《软件架构设计》一书，温昱的个人实践经验更多的在企业级应用开发，所以本书中描述的很多内容都是企业级开发的一些具体方法及案例，因此对于我们很多骄傲的互联网行业的”架构师“会不屑一顾看，这些架构师会更多专注于”高并发、大数据、kafka、zookeeper，hadoop、redis"等等诸如这些高大上的具人技术上，根本看不起做企业应用开发的人。

但是我个人粗略看了本书，觉得对自己在理解软件架构及如何做软件架构设计方面有非常大的帮助，互联网的软件它本质上也是应用软件，只不过由于它的超大规模化部署导致软件架构及具体技术上产生很多巨大的挑战而已，但是本书是通用的讲解软件架构的概念及通用方法论的，对互联网应用同样是适用的。

《软件架构设计》一书对软件架构的定义

本书应该是总结了软件行业很多大牛对软件架构这个概念的看法，提取了大家的一些共识，应该是还是具有非常强的普适性的，我觉得对于我们从具体的软件架构中跳出来是有帮助的。

本文总结行业大牛对软件架构概念的定义分成两派，应该说相互联系但又互为补充。分别是“组成派”和“决策派”。

组成派

定义是：”软件系统的架构将系统描述为计算机组件及组件之间的交互“。这里的组件是广泛意义上的，是非常抽象的，既可以是软件也可以硬件，既可以很宏观，也可以很微小。它的描述是以软件本身为描述对象。

如上图所示，软件架构就是应用了一个组合模式，它是有很多部分组成的。

决策派

定义是软件系统是一些重要方面的决策集合。它包括这样一些问题的重要决策：

• 软件系统的组成。这点上又包含了组合派的定义。
• 选择组成系统的结构元素和他们之间的接口，以及当这些袁术交互协作所体现的行为；
• 如何组合这些元素，使它们逐渐组合成更加大的子系统；
• 用于指导这个系统组织的架构风格；这些元素以及它们的接口、协作和组合。
• 软件架构不仅这种软件本身的结构和行为，还注重其它特性：使用、功能性、弹性、重用、可理解性、经济和技术的限制及权衡，甚至包括美学等。

这个定义有些复杂，理解起来也比较困难，我的理解就为了设计出一个符合各种需求，满足各种角色的要求，在各种约束范围之类的软件组成结构而需要做的各种决策集合。它的定义关注软件架构实践的主体——人，以人的决策作为描述对象；

这是技术选型的决策示例。

这是系统切分的决策示例。

对我的启示

做一个好的”大架构师“，需要做非常多的决策，而做出优雅的决策，这不仅仅是技术，还需要艺术，如何在多种复杂的、矛盾的因数中做出一个良好的权衡，这是对于人本身的知识、技能经验的深度和广度都有较高的要求，本身对我的作用是让自己知道还有哪些差距，哪些地方还需要提高。

我曾经亲身经历并了解的一个错误决策带来的后果可以说给大家听听，某公司来了一个具有Oracle背景的CTO，这位牛人来之后，因为自己的技术背景就行政命令要求正在研发的某系统将数据库从MySQL修改为Oracle，这位某CTO没干多久就走了，现在各部门都在热火朝天的干着去Oracle的事情，因为这个错误的决策，给我们苦逼的程序猿带来多少额外的工作量，这样翻来覆去的改给公司带来多少成本损失。所以说没有科学严谨的决策方法，某位具有某种陈旧的经验的某CTO一句话就产生了一个及其错误的决策的事情真是害人不浅。