什么是系统架构师？什么是系统架构？

1. 什么是系统架构师？

系统架构设计师(System Architecture Designer）是项目开发活动中的关键角色之一。系统架构是系统的一种整体的高层次的结构表示，是系统的骨架和根基，其决定了系统的健壮性和生命周期的长短。

系统架构设计师(系统架构设计器)是项目开发活动中的关键角色之一。系统架构是系统的一种整体的高层次的结构表示，是系统的骨架和根基，其决定了系统的健壮性和生命周期的长短.本章首先从架构定义、发展历程、典型架构和未来发展等方面概要说明，给读者建立一个架构的整体概念；然后对系统架构设计师的定义、职责、范围和工作内容等进行讲解，并说明了对于一名合格的系统架构设计师的要求。

2. 系统架构的概述

自1946年世界上第一台计算机诞生，对人类的计算工具产生了革命性变革。冯诺依曼提出了计算机由运算器，控制器，存储器，输入和输出设备五部分组成，计算机的内部采用二进制。

计算机是全球信息化发展的核心载体，随着各种基础技术突飞猛进的发展，信息系统的规模越来越大、复杂程度越来越高、系统的结构显得越来越重要。如果在搭建系统时未能设计出优良的结构，势必对系统的可靠性、安全性、可移植性、可扩展性、可用性和可维护性等方面产生重大影响。

因此，系统架构（System Architecture）是系统的一种整体的高层次的结构表示，是系统的骨架和根基，也决定了系统的健壮性和生命周期的长短。

系统架构设计师是承担系统架构设计的核心角色，他不仅是连接用户需求和系统进一步设计与实现的桥梁，也是系统开发早期阶段质量保证的关键角色。随着系统规模和复杂性的提升，系统架构设计师在整个项目研制中的主导地位愈加重要。

可以说，系统架构师就是项目的总设计师，他是一个既需要掌控整体又需要洞悉局部瓶颈，并依据具体的业务场景给出解决方案的总体设计人员;他要确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员;他要掌握技术团队的能力需要，给出项目管理方法，采用合适生命周期模型，具备以自身为核心形成团队的能力，并在项目进度计划和经费分配等方面开展评估，以预防项目风险。

3. 系统架构的定义

这里的架构（Architecture）定义来源于IEEE 1471-2000:“IEEE's Recommand Practice forArchitectural Description of Software-Intensive Systems.”标准，本标准主要针对软件密集系统进行了架构描述，其对架构定义如下: 这里的架构(体系结构)ieee 1471-2000：“ieee对软件密集型系统体系结构描述的推荐和实践”。

标准，本标准主要针对软件密集系统进行了架构描述，其对架构定义如下：

架构是体现在组件中的一个系统的基本组织、它们彼此的关系与环境的关系及指导它的设计和发展的原则。
系统是组织起来完成某一特定功能或一组功能的组件集。系统这个术语包括了单独的应用程序、传统意义上的系统、子系统、系统之系统、产品线、整个企业及感兴趣的其他集合。系统用于完成其环境中的一个或多个任务。
环境或者上下文决定了对这个系统的开发、运作、政策以及会对系统造成其他影响的环境和设置。
任务是由一个或者多个利益相关者通过系统达到一些目标的系统的一个用途或操作。

系统架构设计的作用主要包含以下几点：

解决相对复杂的需求分析问题;
解决非功能属性在系统占据重要位置的设计问题;
解决生命周期长、扩展性需求高的系统整体结构问题;
解决系统基于组件需要的集成问题;
解决业务流程再造难的问题。

4.软件架构的分类和建模方法

4.1 分层架构

分层架构（Layered Architecture）是最常见的软件架构，也是事实上的标准架构。这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口进行通信。分层架构通常明确约定软件一定要分成多少层，但是，最常见的是四层结构，如下图所示。

表现层(Presentation Layer）:用户界面，负责视觉和用户互动;
业务层（Business Layer）:实现业务逻辑;
持久层(Persistence Layer）:提供数据，SQL语句就放在这一层;
数据库(Database Layer):保存数据。

4.2 事件驱动架构

事件（Event）是状态发生变化时软件发出的通知。事件驱动架构（Event-driven Architecture)是通过事件进行通信的软件架构，它分成四个部分，如下图所示。

事件队列（Event Queue）:接收事件的入口;
分发器（Event Mediator):将不同的事件分发到不同的业务逻辑单元;
事件通道(Event Channel）:分发器与处理器之间的联系渠道;
事件处理器（Event Processor):实现业务逻辑，处理完成后会发出事件，触发下一步操作。

4.3 微核架构

微核架构(Microkernel Architecture）又称为插件架构(Plug-in Architecture)，是指软件的内核相对较小，主要功能和业务逻辑都通过插件实现，如下图所示。

内核(Core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信应该减少到最低，避免出现互相依赖的问题。

4.4 微服务架构

微服务架构(Microservices Architecture）是服务导向架构（Service-Oriented Architecture，SOA)的升级。每一个服务就是一个独立的部署单元(Separately Deployed Unit)。这些单元都是分布式的，互相解耦，通过远程通信协议（比如 REST、SOAP)联系，如下图所示。

微服务的三种实现模式：

RESTful API模式:服务通过API提供，云服务就属于这一类;
RESTful应用模式:服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部;
集中消息模式:采用消息代理(Message Broker）可以实现消息队列、负载均衡、统一日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群。

4.5 云架构

云架构(Cloud Architecture）主要解决扩展性和并发的问题，是最容易扩展的架构。

它的高扩展性体现在将数据都复制到内存中，变成可复制的内存数据单元，然后将业务处理能力封装成一个个处理单元(Processing Unit)。若访问量增加，就新建处理单元;若访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，需要进行数据持久化。

云架构主要分成两部分:处理单元(Processing Unit）和虚拟中间件（Virtualized Middleware)，如下图所示。

(1）处理单元:实现业务逻辑。

(2）虚拟中间件:负责通信、保持会话控制(sessions)、数据复制、分布式处理和处理单元的部署。

这里，虚拟中间件又包含四个组件:

消息中间件（Messaging Grid):管理用户请求和会话控制(sessions)，当一个请求进来以后，它决定分配给哪一个处理单元。
数据中间件(Data Grid):将数据复制到每一个处理单元，即数据同步。保证某个处理单元都得到同样的数据。
处理中间件(Processing Grid):可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调处理单元。
部署中间件（Deployment Manager):负责处理单元的启动和关闭，监控负载和响应时间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。

5. 系统架构的常用建模方法

主要分为四种：结构模型，框架模型，动态模型，过程模型。

结构模型:这是一个最直观、最普遍的建模方法。此方法以架构的构件、连接件和其他概念来刻画结构。并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格和性质。研究结构模型的核心是架构描述语言。
框架模型:框架模型与结构模型类似，但它不太侧重描述结构的细节，而更侧重整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的结构。
动态模型:动态模型是对结构或框架模型的补充，主要研究系统的“大颗粒”行为的性质。例如，描述系统的重新配置或演化。这里的动态可以是指系统总体结构的配置、建立或拆除通信或计算的过程,这类系统模型常是激励型的。
过程模型:过程模型是研究构造系统的步骤和过程，其结构是遵循某些过程脚本的结果。