浅谈系统架构设计-从架构设计原理、架构设计原则、架构设计方法展开

 

我们工作中一直强调要做架构设计、系分，最近前端同学在追求前端质量提升的时候，也在进行架构设计、前端系分的推广，那到底什么是架构设计和系分？该怎么做架构设计和系分？本文尝试对架构设计进行全面的介绍和分享，希望统一相关认识和术语，推动我们自己架构设计和系分工作的专业发展。

架构发展历程

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

《人月神话》作者布鲁克斯率领的IBM System/360操作系统开发，2000多个程序员共计5000人/年的工作量，将近100万行源码，总共投入5亿美元，是美国的“曼哈顿”原子弹计划投入的1/4，项目进度却一再延迟，软件质量也得不到保障。为了解决问题，1968、1969年，提出了“软件工程”和“结构化程序设计”两种解决方案。“结构化程序设计”就是面向过程的设计思想。

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

第二次软件危机主要体现在软件的“扩展”变得非常复杂，促进了面向对象设计思想的发展。面向对象真正开始流行是在 20 世纪 80 年代，主要得益于 C++ 的功劳，后来的 Java、C# 把面向对象推向了新的高峰。到现在为止，面向对象已经成为了主流的开发思想。

软件架构的真正流行(20 世纪 90 年代开始)

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

相关概念定义

软件开发过程包括了分析、设计、实现、测试、验证、部署、运维等多个环节。一个成功的软件设计是要适应并满足业务需求，同时不断“演化”的。设计需要根据业务的变化、技术的发展不断进行“演进”，这就决定了这是一个动态活动，出现新问题，解决新问题，没有所谓的“一招鲜”。
系统：

泛指由一群有关联的个体组成，根据某种规则运作，能完成个别元件不能独立完成的工作能力的群体。
子系统：也是由一群关联的个体组成的系统，多半是在更大的系统中的一部分。
模块：

就是从逻辑上将系统分解， 即分而治之， 将复杂问题简单化。模块的粒度可大可小， 可以是系统，几个子系统、某个服务，函数， 类，方法、 功能块等等。
组件：

可以包括应用服务、数据库、网络、物理机、还可以包括MQ、容器、Nginx等技术组件。
框架：

是组件实现的规范，例如：MVC、MVP、MVVM等，是提供基础功能的产品，例如开源框架：Ruby on Rails、Spring、Laravel、Django等，这是可以拿来直接使用或者在此基础上二次开发。
架构：

是经过系统性地思考, 权衡利弊之后在现有资源约束下的最合理决策, 最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则.并由它来指导团队中的每个人思想层面上的一致。
系统架构：
国际标准化组织（ISO）系统和软件工程标准认为，系统的架构是一系列基本概念或者系统在其环境中表现出来的属性，体现在它的元素、关系及设计和发展的原则中。根据ISO给出的这一架构定义，系统架构包括系统元素、基本系统属性、设计和发展原则3个主要方面。
架构设计：
是以干系人提出的业务需求为源头、以技术管理和过程改进体系为工作流程、以质量为重心的一项系统工程。架构设计往往首先关注系统的主要构成部分及它们相互之间的关系，然后进一步挖掘每个构成部分的细节，以便确定模块、组件、接口等元素，并确保这些元素满足既定的架构设计原则。比如常用的MVC框架。

系分（前端系分、后端系分、测试系分）：

系分的全称是“系统设计、业务分析”，阿里的“系分”文化，要求每一个程序员都要会写系分，后端要写后端系分，前端要写前端系分，测试要写测试系分，如果没有做系分，是不允许直接进入研发工作的，我们公司也是如此。

系统架构师：
架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力，能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。在软件开发的整个过程中起着很重要的作用。

在系统工程中，业务需求需要进行分析和抽象、过程需要进行管理和改进、设计质量需要进行保障，完成包含这些活动在内的整个系统架构设计工作的角色就是架构师。因此架构师具备能力：理解业务&#x