在上一篇文章中，概要讲述了架构师在实际工作中到底要做些什么，以及要匹配具备什么样的能力。
接下来，我们逐步展开来讲述，从零开始，逐步培养架构设计思维、讲解架构设计技术、掌握架构设计方法、循序渐进进行架构设计实战训练，从根本上提升能力，早日成长成为真正的架构师。
先来聊聊两个基本的概念：什么是架构，以及架构的分类。
一：什么是架构
关于架构的定义，业界有太多不同的说法，但大同小异，本质趋同，只不过侧重各有不同，这里选取IEEE（电气和电子工程师协会）的定义：
架构描述了一个系统的基本组织结构，包含了组成系统的组件、组件之间的关系、组件与环境之间的关系，以及指导上述内容进行设计和演化的原则。
1：系统
组织起来完成一系列功能的组件集
2：组件
组件是一个系统模块化的一部分，是一系列功能集的封装体
3：环境
环境或上下文，指的是会对这个系统的开发、运行等造成影响的环境和设置，比如：政策法规、软硬件环境等，是一些软件系统之外的因素。
二：对架构的基本认识
- 架构定义了系统结构，尤其是高层结构
- 架构定义了行为
这里的行为主要是一些交互行为，比如：组件之间的交互，组件和环境之间的交互等
- 架构关注系统的主要元素
主要元素，比如从用户角度来看，用户关注的一些重点、难点功能；或者是有特色亮点的功能。
另外就是一些解决重要特性的元素，比如：影响高性能、高可用的一些因素。
这样的一些元素是做架构设计特别关注的主要元素。
- 架构要平衡系统利益相关者的需要
利益相关者：指的是对这个系统感兴趣，或者是与这个系统有关系的人、团队或组织。
通常来说，不同的利益相关者，他的关注点是不一样的，有些关注点是冲突的，甚至是矛盾的，架构师就需要平衡这些关注点。
- 架构基于合理的证据使决策具体化
架构设计不是拍脑门，是基于一些合理的证据的，比如：同类产品的参考，以前设计的经验，或者是一些设计Demo的实际测试，证明这样设计是可行的。
- 架构会受到环境的影响
比如，架构会受到法律法规的要求、行业标准的约束等
- 架构会影响开发团队的结构
比如，现在的架构决定采用微服务的架构，那么开发团队，就需要按照匹配微服务的方式来建设和组织
三：架构分类
没有统一的标准
有按实现层次划分的、有按关注方向划分的、有按软工阶段划分的、有按视图类型划分的、有按技术实现风格划分的……等等。
就是从不同的角度、不同的侧重点，对架构设计这件事进行划分，当然有很多是交叉重叠的。
按实现层次划分
- 移动架构
- 前端架构
- 系统架构（应用架构，技术架构）
- 平台架构
- 应用集成架构
- 数据库架构
- 存储架构
- 网络架构
按关注方向划分
- 业务架构
- 应用架构
- 技术架构
- 开发架构
- 数据库架构
- 存储架构
- 安全架构
- 部署架构
- 开放架构（OpenAPI架构）
按软工阶段划分
- 解决方案架构
- 业务架构
- 系统架构
- 概念架构
- 细化架构
- 平台架构
- 开发架构
- 部署架构
- 运维架构
按视图类型划分
- 逻辑架构
- 数据架构
- 开发架构
- 运行架构
- 物理架构
按技术实现风格划分
- 分布式架构
- 微服务架构
- 分层架构
- 事件驱动架构
- 微内核架构
- SOA架构
- 响应式架构
这些都是一些基本的概念，作为一个架构师，还是要有一个清晰的认知的。从零开始，逐步培养架构设计思维嘛！
网友评论