软考笔记（八）高级系统架构师/分析师：系统架构 架构设计
目录
- 软考官网 报名通道
- 软考架构师笔记（一）：计算机系统基础
- 软考架构师笔记（二）：计算机网络基础与信息安全
- 软考架构师笔记（三）：操作系统基础
- 软考架构师笔记（四）：企业信息化与系统规划
- 软考架构师笔记（五）：系统需求工程 需求分析
- 软考架构师笔记（六）：数据库
- 软考架构师笔记（七）：系统分析 系统设计
- 软考架构师笔记（八）：系统架构 架构设计
- 软考架构师笔记（九）：软件工程与项目管理
- 软考架构师笔记（十）：系统测试 维护 稳定性
目录
软件架构概念
软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。
架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性
软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础
软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量
软件架构建模
结构模型：以架构的构件、连接件和其他概念来刻画结构
框架模型：不太侧重描述结构的细节而更侧重于整体的结构
动态模型：系统的“大颗粒”的行为性质
过程模型：构建系统的步骤和过程
功能模型：由一组功能构件按层次组成，下层向上层提供服务
RUP 4+1
用例视图（Use Cases View），最初称为场景视图，关注最终用户需求，为整个技术架构的上线文环境.通常用UML用例图和活动图描述。
逻辑视图（Logical view），主要是整个系统的抽象结构表述，关注系统提供最终用户的功能，不涉及具体的编译即输出和部署，通常在UML中用类图，交互图，时序图来表述，类似与我们采用OOA的对象模型。
开发视图(Development View)，描述软件在开发环境下的静态组织，从程序实现人员的角度透视系统，也叫做实现视图(implementation view)。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件, 在UML中用组件图，包图来表述。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。
物理视图（Physical view ）物理视图通常也叫做部署视图(deploymentview)，是从系统工程师解读系统，关注软件的物流拓扑结，以及如何部署机器和网络来配合软件系统的可靠性、可伸缩性等要求。物理视图和处理视图的关系：处理视图特别关注目标程序的动态执行情况，而物理视图重视目标程序的静态位置问题；物理视图是综合考虑软件系统和整个IT系统相互影响的架构视图。
处理视图（Process view）(进程视图) 处理视图关注系统动态运行时，主要是进程以及相关的并发、同步、通信等问题。处理视图和开发视图的关系：开发视图一般偏重程序包在编译时期的静态依赖关系，而这些程序运行起来之后会表现为对象、线程、进程，处理视图比较关注的正是这些运行时单元的交互问题，在UML中通常用活动图表述。
软件架构风格
架构设计的一个核心问题是能否达到架构级的软件复用
架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
Garlan和Shaw对通用软件架构风格进行了分类，他们将软件架构分为数据流风格、调用/返回风格、独立构件风格、虚拟机风格和仓库风格。
（1）数据流风格：数据流风格包括批处理序列和管道/过滤器两种风格。
（2）调用/返回风格：调用/返回风格包括主程序和子程序、数据抽象和面向对象，以及层次结构。
（3）独立构件风格：独立构件风格包括进程通信和事件驱动的系统。
（4）虚拟机风格：虚拟机风格包括解释器和基于规则的系统。
（5）仓库风格：仓库风格包括数据库系统、黑板系统和超文本系统。
（6）过程控制：闭环控制
仓库风格中构件分两种：
- 一种是中央数据结构，保存系统的当前状态；
- 另一种是独立构件，对中央数据存储进行操作。
黑板系统：
黑板（共享数据）,知识源 , 控制
知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板；黑板是一个全局数据库，包含问题域解空间的全部状态，是知识源相互作用的唯一媒介；知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中（信号处理、问题规划和编译器优化，语音识别等）。
超文本：
构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。
层次架构风格
- CS架构：架构是客户端和服务器架构，通过充分利用两端硬件环境的优势，将任务合理分配到Client端和Server端来实现。
- BS架构：架构是浏览器和服务器架构，用户工作界面是通过浏览器来实现，极少部分事务逻辑在前端（Browser）实现，但是主要事务逻辑在服务器端（Server）实现。
富互联网 RIA
HTML5， AJAX，Laszlo，Bindows，FLex，JAVA
RIA结合了C/S架构反应速度快、交互性强的优点，以及B/S架构传播范围广及容易传播的特性
RIA简化并改进了B/S架构的用户交互
数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面
基于服务的架构 SOA
面向服务的架构（Service-Oriented Architecture，SOA）是透过业务服务的概念来提供IT的各项基本应用功能，让这些服务可以自由地被排列组合，融会贯通，以便在未来能随时弹性配合新的需求而调整。
SOA架构只是实现和解决了服务模块间调用的互操作问题，为了更好地服务于企业应用，引入了企业服务总线（ESB）的应用架构。这一构架是基于消息中间件（Messaging Middleware）、智能路由和数据转换等技术实现的。
SOA的实现方式：ESB 服务总线 各种服务挂到总线上，依赖总线 完成互联互通
充当中介者角色，对接各个服务; 例如Webservice 封装遗留系统为单个服务；
特点：
松散耦合，粗粒度，标准化接口；
ESB提供了一个基于标准的松散应用耦合模式，
ESB由以下3层构成：
总线接入层：通过这一层可以使用户的各种应用接入ESB，使用ESB的各种服务。在这一层提供对多种主流应用的接入协议支持，如HTTP、JCA/J2C、NET和IBM/CICS等。同时考虑到一些客户自己定制的应用与ESB的连接，在总线接入层提供了适配器服务。
核心层：提供多种企业服务总线所需的必要服务支持，在这一层除了提供总线基本服务（如分发/订阅、队列、安全服务和仲裁服务等）外，还提供了QoS的支持（如高可用性、确保消息传输等）。微流程组合/拆分或定制
路由层：这一层是侧重在业务支持上。通过通用和标准的对象、服务模型，可以在这一层上定义可重用和基于业界标准的业务流程。
关键技术
WSDL：
WSDL就是WebService接口对应的WSDL文件，该文件通过xml格式说明如何调用，可以看作WebService的接口文档（使用说明书）。
服务实现定义： 服务和端口
服务接口定义：绑定，端口类型，消息，类型
SOAP：
SOAP，Simple Object Access Protocol，简单对象访问协议，简单的说就是用于访问网络服务的协议；它是基于XML的简易协议，可使应用程序在HTTP之上进行信息交换。
SOAP是一种网络通信协议，用于网络上、不同平台、不同语言的应用程序间的通讯。 HTTP协议+XML数据格式
SO方法的服务建模：按照实施的阶段，服务建模可以分为服务发现、服务规约和服务实现三个阶段。
（1）服务发现。采用自上而下、自下而上和中间对齐的方式，得到候选服务。
（2）服务规约。对候选服务进行分类，根据是否便于复用和组装，是否具有业务对齐性来决定是否将服务暴露。同时，需要考虑服务的信息系统特性。服务规约还包括服务编排、服务库和服务总线中间件模式的设计等过程。
（3）服务实现。根据对业务领域的理解和现有系统的分析，将服务的实现分配到相应的服务构件中，并决定服务的实现方式。具体的实现方式既可以由现有系统暴露相关功能为服务，或者重新开发相关功能提供务，也可以由合作伙伴来提供服务。无论采用哪种方式，系统分析师都需要对于关键点进行技术可行性分析。
MDA
架构描述语言ADL
ADL是一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。基于底层语义的工具为体系结构的表示、分析、演化、细化、设计过程等提供支持。
ADL的三个基本元素
构件：计算或数据存储单元；
连接件：用于构件之间交互建模的体系结构构造块及其支配这些交互的规则；
架构配置：描述体系结构的构件与连接件的连接图
特定领域软件架构 DSSA
基于架构的软件开发 ABSD
ABSD方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。
使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成（甚至远远没有完成），就开始了软件设计。
ABSD方法有三个基础。
第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术；
第二个基础是通过选择架构风格来实现质量和业务需求；
第三个基础是软件模板的使用。软件模板利用了一些软件系统的结构。
ABSD方法是递归的，且迭代的每一个步骤都是清晰地定义的。因此，不管设计是否完成，架构总是清晰的，这有助于降低架构设计的随意性。
视角与视图：从不同的视角来检查，所以会有不同的视图。
用例用来捕获功能需求、特定场景来捕获质量需求。
开发过程
软件质量属性
软件建构评估
中间件技术
中间件是一种独立的系统软件或服务程序，可以帮助分布式应用软件在不同的技术之间共享资源;
它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
- 负责客户机与服务器之间的连接和通信，以及客户机与应用层之间的高效率通信机制
- 提供应用层不同服务之间的互操作机制，以及应用层与数据库之间的连接和控制机制
- 提供多层架构的应用开发和运行的平台，以及应用开发框架，支持模块化的应用开发
- 屏藏硬件、操作系统、网缩和数据库的差异
- 提供应用的负载均衡和离可用性、安全机制与管理功能，以及交易管理机制，保证交易的一致性
- 提供一组通用的服务去执行不同的功能，避免重复的工作和使应用之间可以协作
Web架构设计
主要涉及：
从架构来看：MVC，MVP，MWM，REST，Webservice，微服务，中台。
从缓存来看：MemCache，Redis，Squid。
从并发分流来看：集群（负载均衡）、CDN。
从数据库来看：主从库（主从复制），内存数据库，反规范化技术，NosQL，分区（分表）技术，视图与物化视图。
从持久化来看：Hibernate，Mybatis。
从分布存储来看：Hadoop，FastDFS，区块链。
从数据编码看：XML，JSON。
从Web应用服务器来看：Apache，WebSphere，Weblogic，Tomcat，JBOSS，IS。
其它：静态化，有状态与无状态，响应式Web设计。
负载均衡问题
典型应用架构
- J2EE 分布式多层应用程序
- .NET
- MVC/MVP设计模式
MVC模式，即模型一视图一控制（Model-View-Controller）模式，它实际上是一种架构模式，是为那些需要为同样的数据提供多个视图的应用程序而设计的，它很好地体现了数据层与表示层的分离。
MCV把应用程序分为3种对象类型。
模型：应用问题域中包含的抽象领域知识；
视图：将应用问题域中包含的抽象领域知识呈现给用户的方法：一个模型可以用于多个视图；
控制器：用户界面对用户输入的响应方式。 - Web系统架构
负载均衡：
基于特定软件的负载均衡（HTTP重定向）（应用层）
反向代理负载均衡（应用层）
基于DNS的负载均衡（传输层）
基于NAT的负载均衡（传输层）
混合型负载均衡
静态算法：轮转算法、加权轮转算法、源地址哈希散列算法、目标地址哈希散列算法、随机算法
动态算法：最小连接数算法、加权最小连接数算法、加权百分比算法 - 面向消息中间件（Message-Oriented Middleware，MOM）：利用高效可靠的消息传递机制进行平台无关的数据传递，并可基于数据通信进行分布系统的集成。通过提供消息传递和消息队列模型，可在分布环境下扩展进程间的通信，并支持多种通信协议、语言、应用程序、硬件和软件平台。
- EJB EJB是企业级Java构件，用于开发和部署多层结构、分布式、面向对象的Java应用系统。
EJB分为会话Bean、实体Bean和消息驱动Bean。
（1）会话Bean：用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当客户端请求时，容器就会选择一个会话Bean来为客户端服务。会话Bean可以直接访问数据库，但更多时候，它会通过实体Bean实现数据访问。
（2）实体Bean：用于实现O/R映射，负责将数据库中的表记录映射为内存中的实体对象。事实上，创建一个实体Bean对象相当于新建一条记录；删除一个实体Bean会同时从数据库中删除对应记录；修改一个实体Bean时，容器会自动将实体Bean的状态和数据库同步。
（3）消息驱动Bean:EJB3.0中引入的新的企业Bean，它基于JMS消息，只能接收客户端发送的JMS消息后处理。MDB实际上是一个异步的无状态会话Bean，客户端调用MDB后无须等待，立刻返回，MDB将异步处理客户请求。这适合于需要异步处理请求的场合，如订单处理，这样就能避免客户端长时间地等待一个方法调用直到返回结果。 - CORBA服务端构件模型中，
（1）伺服对象（Servant）：CORBA对象的真正实现，负责完成客户端请求。
（2）对象适配器（Object Adapter）：用于屏蔽ORB内核的实现细节，为服务器对象的实现者提供抽象接口，以便它们使用ORB内部的某些功能。
（3）对象请求代理（Object Request Broker）：解释调用并负责查找实现该请求的对象，将参数传给找到的对象，并调用方法返回结果。客户方不需要了解服务对象的位置、通信方式、实现、激活或存储机制。
