系统架构设计
软件架构
一个程序和计算系统软件体系结构是指系统的一个或者多个结构。结构中包括软件的构件，构件的外部可见属性以及它们之间的相互关系
软件架构指从需求分析到软件设计之间的过渡过程。只要软件架构设计好了，整个软件就不会出现坍塌性的错误，即不会崩溃
数据设计和体系结构设计。数据设计为软件体系结构设计提供了数据基础，而体系结构设计则为软件系统的整体结构提供了规划和设计
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用(连接件)、指导构件集成的模式以及这些模式的约束组成
软件架构就是软件的总体设计方案，它决定了软件如何组织和工作，规定了软件系统的整体结构和各个部分之间的关系，以满足用户需求和业务目标。好的架构是构建可靠软件的基础
需求分析-架构设计-系统设计
1、软件架构设计贯穿于软件开发生命周期的各个阶段，软件架构设计并非只在开发初期进行，而是贯穿于软件开发生命周期的各个阶段，包括需求分析、设计、实现、测试、部署和维护等
2. 需求分析阶段。需求分析和SA（架构）设计面临的是不同的对象：一个是问题空间；另一个是解空间。从软件需求模型向SA模型的转换主要关注两个问题：如何根据需求模型构建SA模型。如何保证模型转换的可追踪性。
简单来说，该阶段关注的是如何将用户需求转换为软件架构模型，并确保模型的可追踪性。
3. 设计阶段。是SA研究关注的最早和最多的阶段，这一阶段的SA研究主要包括：SA模型的描述、SA模型的设计与分析方法，以及对SA设计经验的总结与复用等。有关SA模型描述的研究分为3个层次：SA的基本概念(构件和连接件)、体系结构描述语言ADL、SA模型的多视图表示。
简单来说，该阶段关注的是软件架构模型的描述、设计与分析方法，以及设计经验的总结与复用。
4. 实现阶段。最初SA研究往往只关注较高层次的系统设计、描述和验证。为了有效实现SA设计向实现的转换，实现阶段的体系结构研究表现在对开发过程的支持、开发语言和构件的选择以及相关测试技术。
简单来说，该阶段关注的是如何将软件架构设计转换为代码，以及如何进行测试
5. 构件组装阶段。在SA设计模型的指导下，可复用构件的组装可以在较高层次上实现系统，并能够提高系统实现的效率。在构件组装的过程中，SA设计模型起到了系统蓝图的作用。
简单来说，该阶段关注的是如何在架构设计模型的指导下，进行可复用构件的组装，提高系统实现效率，并解决组装过程中的相关问题。
6. 部署阶段。提供高层的体系结构视图来描述部署阶段的软硬件模型，以及基于SA模型可以分析部署方案的质量属性，从而选择合理的部署方案。
简单来说，该阶段关注的是如何根据软件架构模型进行部署，并分析部署方案的质量属性。
7. 后开发阶段。是指软件部署安装之后的阶段。这一阶段的SA研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。
简单来说，该阶段关注的是如何根据软件架构模型进行维护和演化
构件
构件(Component)是指系统的重要部分，它们是功能上独立且可以被替代或扩展的模块或单元，外界通过接口访问其提供的服务
这些构件代表了系统中的不同功能区域，每个构件都可以独立开发、测试和维护。它们通过明确定义的接口和通信方式相互连接，以协同工作来实现整个电子商务网站的功能。
可以独立部署，没有外部的可见状态，不可拆分
类：类是面向对象编程中的基本概念，它描述了一种对象的属性和行为。类定义了对象的结构和行为模板，它可以包括属性(数据成员)和方法(函数成员)。类用于创建对象，对象是类的实例
模块：模块是一组相关的函数、类、变量或代码块的集合，模块用于划分代码，将相关功能或类放在一个地方，以便更好地组织和维护代码。它还可以支持代码的复用和封装
构件：是指软件系统中的可复用组件。构件可以是代码、数据、文档或其他任何类型的软件资产。构件通常是松散耦合的，并且可以组合起来形成更大的软件系统。构件的典型示例包括类、模块、组件和框架
服务：是指提供特定功能的软件单元。服务通常是独立的、可复用的，并且可以通过网络进行访问。服务的典型示例包括 Web服务、REST API 和微服务
服务和构件之间的主要区别如下：
服务侧重于功能，而构件侧重于结构。 服务提供特定的功能，而构件是软件系统的组成部分。
服务通常是独立的和可访问的，而构件通常是松散耦合的和可复用的。 服务可以独立运行并通过网络进行访问，而构件可以组合起来形成更大的软件系统。
服务通常用于面向服务的架构 (SOA)，而构件通常用于组件化开发。 SOA 是一种将软件系统构建为松散耦合的服务的架构风格。组件化开发是一种将软件系统构建为可复用构件的方法。
构件技术就是利用某种编程手段，将一些人们所关心的，但又不便于让最终用户去直接操作的细节进行了封装，同时对各种业务逻辑规则进行了实现，用于处理用户的内部操作细节。
目前，国际上常用的构件标准主要有三大流派。
EJB(Enterprise Java Bean)规范由Sun公司制定，有三种类型的EJB：
• 会话Bean(Session Bean)：用于管理会话和业务逻辑，有不同的类型适应不同的需求
• 实体Bean(Entity Bean)：用于与持久化数据交互，将对象映射到数据库表。
• 消息驱动Bean(Message-driven Bean)：用于异步消息处理，响应来自消息队列的消息
COM、DCOM、COM+：COM是微软公司的。DCOM是COM的进一步扩展，具有位置独立性和语言无关性。COM+并不是COM的新版本，是COM的新发展或是更高层次的应用：
CORBA标准主要分为三个层次：对象请求代理、公共对象服务和公共设施
• 最底层是对象请求代理ORB,规定了分布对象的定义(接口)和语言映射，实现对象间的通讯和互操作，是分布对象系统中的“软总线”;
• 在ORB之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务(交易)服务、安全服务等各种各样的服务；
• 最上层的公共设施则定义了组件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。
EJB和COM+较为适用于应用服务器
软件架构风格
是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义、一个词汇表和一组约束。架构定义描述了系统的整体结构和组织方式。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
简单来说，软件体系结构风格就是一个模板，它规定了特定应用领域中软件系统应该如何构建
软件架构风格的作用：反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统
架构设计的一个核心问题是能否达到架构级的软件复用，强调对架构设计的重用。
架构风格定义了用于描述系统的术语表和一组指导构建系统的规则
数据流风格
面向数据流，按照一定的顺序从前向后执行程序，代表的风格有批处理序列、管道-过滤器
批处理序列：构件为一系列固定顺序的计算单元，多件事情同步顺序执行，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。比如批量图像处理：一次性处理大量图像，例如调整大小、添加水印或转换格式。
管道-过滤器：每个构件都有一组输入和输出，构件读取输入的数据流，经过内部处理，产生输出数据流。前一个构件的输出作为后一个构件的输入，前后数据流关联。过滤器就是构件，连接件就是管道。比如文本处理管道：在文本分析中，可以将文本处理划分为分词、词干提取、情感分析等多个阶段，每个阶段是一个过滤器
早期编译器就是采用的这种架构，要一步一步处理的，均可考虑此架构风格。
二者区别：
批处理风格通常一次性处理大量数据，离线执行，适用于批量处理任务。
管道过滤器风格将任务分解为多个阶段，每个阶段逐个处理数据，通常是实时或近实时执行，适用于可组合和可扩展的任务。
调用返回风格
构件之间存在互相调用的关系，一般是显式的调用，代表的风格有主程序/子程序、面向对象、层次结构、客户端服务器
主程序/子程序：单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，充当连接件的角色
面向对象：构件是对象，对象是抽象数据类型的实例。连接件即使对象间交互的方式，对象是通过函数和过程的调用来交互的。
层次结构：构件组成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。修改某一层，最多影响其相邻的两层(通常只能影响上层)。
优点是可以将一个复杂问题分解成一个增量步骤序列的实现。
缺点是并不是每个系统都可以很容易的划分为分层的模式，并且因为进行层次调用，会影响效率。
客户端服务器(C/S)：早期是两层C/S架构模式，由三个部分组成：数据库服务器、客户端服务器和网络，其中服务器负责数据管理，客户端完成用户交互，称之为“胖客户机，瘦服务器”，后期又增加了一个应用服务器，称之为三层C/S架构,分别是表示层、功能层和数据层，表示层就是用户交互、功能层就是业务逻辑处理、数据层就是数据库处理，以上三层独立
独立构件风格
构件之间是互相独立的，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行，代表的风格有进程通信、事件驱动系统(隐式调用)
进程通信：构件是独立的进程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。进程通信涉及不同的进程或线程之间的通信和数据共享。这些进程可以运行在同一台计算机上，也可以分布在不同的计算机上。
事件驱动系统(隐式调用)：构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。
主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便；
缺点是构件放弃了对系统计算的控制，只能被动的控制
虚拟机风格
自定义了一套新规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配，代表的风格有解释器、基于规则的系统
解释器：通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。涉及解析和执行一系列指令或命令，通常通过解释器来实现。解释器将文本或代码解析成可执行的操作。缺点是执行效率低
基于规则的系统：包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS(决策支持系统)中。适用于根据一组事先定义的规则或条件来控制系统的行为。这种风格通常用于实现灵活的业务规则和决策逻辑。
以数据为中心风格
以数据为中心，所有的操作都是围绕建立的数据中心进行的，代表的风格有数据库系统、仓库系统、黑板系统
仓库风格的架构将数据存储在一个中央仓库或数据库中，各个组件可以从仓库中读取和写入数据。组件之间通过共享数据仓库进行通信和协作。
仓库超文本：网状连接，多用于互联网
黑板风格的架构类似于一个黑板或公告板，多个独立的组件称为”专家”共享一个公共存储区(黑板)，它们可以读取和写入数据。专家根据黑板上的信息进行推断和决策，适用于解决复杂的非结构化问题。
总之，仓库风格强调数据的集中存储和共享，组件通过访问共享的仓库来交互。
而黑板风格侧重于多个独立的组件共享一个中央知识存储区，根据共享的信息进行推断和决策。
这两种风格在处理复杂问题和协作方面都具有一定的优势。
闭环控制
当软件被用来操作一个物理系统时，软件与硬件之间可以粗略的表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态，适合于嵌入式系统，涉及连续的动作与状态。
C2风格
通过连接件绑定在一起的按照一组规则运作的并行构件网络。C2风格中的系统组织规则如下：
系统中的构件和连接件都有一个顶部和一个底部；
构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不允许的；
一个连接件可以和任意数目的其它构件和连接件连接；
当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。
构件中间要有连接件
软件架构复用
软件产品线是指一组（多个）软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，是以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统
软件架构复用根据复用的时机包括机会复用和系统复用。
机会复用是指开发过程中，只要发现有可复用的资产，就对其进行复用。
系统复用是指在开发之前，就要进行规划，以决定哪些需要复用
复用的基本过程主要包括3个阶段：
首先构造/获取可复用的软件资产，
其次管理这些资产(把它们放入到构件库)，
最后针对特定的需求，从这些资产中选择可复用的部分，以开发满足需求的应用系统
特定领域软件架构（DSSA）
DSSA就是专用于一类特定类型的任务(领域)的、在整个领域中能有效地使用的、为成功构造应用系统限定了标准的组合结构的软件构件的集合。它旨在满足该领域的独特需求和约束
DSSA就是一个特定的问题领域中支持一组应用的领域模型、参考需求、参考架构等组成的开发基础，其目标就是支持在一个特定领域中多个应用的生成
垂直域：在一个特定领域中的通用的软件架构，是一个完整的架构
水平域：在多个不同的特定领域之间的相同的部分的小工具
DSSA的三个基本活动：领域分析、领域设计和领域实现
领域分析：这个阶段的主要目标是获得领域模型**(领域需求)**，在此基础上就可以分析领域中系统的需求，确定哪些需求是领域中的系统广泛共享的，从而建立领域模型
领域设计：这个阶段的目标是获得DSSA
领域实现：这个阶段的主要目标是依据领域模型和DSSA开发和组织可重用信息
领域分析用于确定需求，领域设计用于提供通用架构，而领域实现用于将该架构转化为具体的应用程序模块。这个过程有助于确保系统能够满足特定领域的需求，并具备可维护和可重用的特性
DSSA的四种角色：领域专家、领域分析人员、领域设计人员和领域实现人员
三层次模型：领域开发环境、领域特定的应用开发环境、应用执行环境
基于架构的软件开发（ABSD）
基于架构的软件开发(Architecturally Based Software Development，ABSD)是一种软件开发方法，强调在开发过程中首先定义系统的体系结构，然后根据这个体系结构来实现系统。它有助于确保系统的结构和设计与业务需求保持一致
ABSD方法是架构驱动，强调由业务、质量和功能需求的组合驱动架构设计。它强调采用视角和视图来描述软件架构，用例描述的是功能需求，质量（属性）场景描述的是质量需求(或侧重于非功能需求)
ABSD方法有三个基础。
第一个基础是功能的分解，使用已有的基于模块的内聚和耦合技术;
第二个基础是通过选择架构风格来实现质量和业务需求;
第三个基础是软件模板的使用，软
件模板利用了一些软件系统的结构进行复用。
ABSD方法是递归的，且迭代的每一个步骤都是清晰定义的。因此，不管设计是否完成，架构总是清晰的，有助于降低架构设计的随意性。
ABSD六步：
1 . 架构需求：重在掌握标识构件的三步，生成类图，对类进行分组，把类打包成构件
- 架构设计：将需求阶段的标识构件映射成构件
- 架构(体系结构)文档化：主要产出两种文档，即架构(体系结构)规格说明，测试架构(体系结构)需求的质量设计说明书。文档是至关重要的，是所有人员通信的手段，关系开发的成败
- 架构复审：由外部人员(独立于开发组织之外的人，如用户代表和领域专家等)参加的复审，复审架构是否满足需求，质量问题，构件划分合理性等。若复审不过，则返回架构设计阶段进行重新设计、文档化，再复审
- 架构实现：用实体来显示出架构。实现构件，构件组装成系统
- 架构演化：对架构进行改变，按需求增删构件，使架构可复用
层次架构风格
两层C/S架构
开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能轻易应用、安全性问题、服务器端压力大难以复用
三层C/S架构
将处理功能独立出来，表示层和数据层都变得简单。表示层在客户机上，功能层在应用服务器上，数据层在数据库服务器上
三层B/S架构
是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的WEB服务器，又称为0客户端架构
富互联网应用RIA
弥补三层B/S架构存在的问题，RIA是一种用户接口，比用HTML实现的接口更加健壮，且有可视化内容，本质还是网站模式，其优点如下：
RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性；
RIA简化并改进了B/S架构的用户交互；
数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。
本质还是0客户端，借助于高速网速实现必要插件在本地的快速缓存，增强页面对动态页面的支持能力，典型的如小程序
MVC架构
控制器(Controller) ：是应用程序中处理用户交互的部分
模型(Model)：是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。模型表示业务数据和业务逻辑。
视图(View)：是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之交互的界面。
MVP架构
MVP是把MVC中的Controller换成了Presenter(呈现)，目的就是为了完全切断View跟Model之间的联系，由Presenter充当桥梁，做到View-Model之间通信的完全隔离
MVP特点：
M、V、P之间双向通信。
View 与Model不通信，都通过Presenter传递。Presenter完全把Model和View进行了分离，主要的程序逻辑在Presenter里实现。
View非常薄，不部署任何业务逻辑，称为”被动视图”(PassiveView)，即没有任何主动性，而Presenter非常厚，所有逻辑都部署在那里。
Presenter与具体的View是没有直接关联的，而是通过定义好的接口进行交互，从而使得在变更View时候可以保持Presenter的不变，这样就可以重用。
MVVM架构
MVVM模式和MVC模式类似，主要目的是分离视图(View)和模型(Model)，实现双向绑定，有几大优点：
低耦合，视图(vView)可以独立于Model变化和修改，一个ViewModel可以绑定到不同的”View”上，当View变化的时候Model可以不变，当Model变化的时候View也可以不变。
可重用性，可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
独立开发，开发人员可以专注于业务逻辑和数据的开发(ViewModel) ，设计人员可以专注于页面设计。
可测试，界面向来是比较难于测试的，而现在测试可以针对ViewModel来写。
面向服务的架构风格（SOA）
SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通信，不涉及底层编程接口和通信模型
服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。
实施SOA的关键目标是实现企业IT资产重用的最大化，在实施SOA过程中要牢记以下特征：可从企业外部访问、随时可用(服务请求能被及时响应)、粗粒度接口(粗粒度提供一项特定的业务功能，而细粒度服务代表了技术构件方法)、服务分级、松散耦合(服务提供者和服务使用者分离)、可重用的服务及服务接口设计管理、标准化的接口(WSDL、SOAP、XML是核心)、支持各种消息模式、精确定义的服务接口
从基于对象到基于构件再到基于服务，架构越来越松散耦合，粒度越来越粗，接口越来越标准
关键技术：
UDDI：用于WEB服务注册统一描述、发现，查找。
WSDL (Web Service描述语言)∶将Web服务描述定义为一组服务访问点，用于描述服务
SOAP(简单对象访问协议)：用于传递信息。
XML (可扩展标记语言)︰是WebService平台中表示数据的基本格式，用于数据交换
BPEL：将多个服务组合成一个新的复合服务
SOA的三种实现方式：WEB Service、服务注册表和企业服务总线ESB
WEB Service：服务提供者、服务注册中心(中介，提供交易平台，可有可无)、服务请求者
企业服务总线ESB：简单来说是一根管道，用来连接各个服务节点。
ESB的存在是为了集成基于不同协议的不同服务，ESB做了消息的转化、解释以及路由的工作，以此来让不同的服务互联互通。
包括：客户端(服务请求者)、基础架构服务(中间件)、核心集成服务(提供服务)。
ESB特点：
SOA的一种实现方式，ESB在面向服务的架构中起到的是总线作用，将各种服务进行连接与整合;
描述服务的元数据和服务注册管理;
在服务请求者和提供者之间传递数据，以及对这些数据进行转换的能力，并支持由实践中总结出来的一些模式如同步模式、异步模式等;
发现、路由、匹配和选择的能力，以支持服务之间的动态交互，解耦服务请求者和服务提供者。高级一些的能力，包括对安全的支持、服务质量保证、可管理性和负载平衡等