系统架构师-软件架构设计

软件架构设计

软件架构设计
1. 软件架构的概念
2. 软件架构风格
3. 架构描述语言ADL
4. 特定领域软件架构
5. 基于架构的软件开发
6. 软件质量属性
7. 软件架构评估
8. 软件产品线
9. 构件与中间件技术
10. Web架构设计

一、软件架构的概念

img.png

  1. 软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个体系结构定义一个词汇表和一组约束。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。
  2. 软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。
  3. 软件架构是项目干系人进行交流的手段，明确了对系统实现的约束条件，决定了开发和维护组织的组织结构，制约着系统的质量属性
  4. 软件架构使推理和控制的更改更加简单，有助于循序渐进的原型设计，可以作为培训的基础
  5. 软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量

img.png

  1. 结构模型以架构的构件、连接件和其他概念来刻画结构
  2. 框架模型∶不太侧重描述结构的细节而更侧重于整体的
  3. 结构动态模型︰系统的“大颗粒”的行为性质
  4. 过程模型∶构建系统的步骤和过程
  5. 功能模型︰由一组功能构件按层次组成，下层向上层提供服务

img.png

二、软件架构风格

  • 架构设计的一个核心问题是能否达到架构级的软件复用
  • 架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统
  • 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则

软件架构风格类型

  1. 数据流风格︰批处理序列（全部数据）、管道-过滤器(流式处理数据)
  2. 调用/返回风格(面向对象):主程序/子程序、面向对象、层次结构
  3. **独立构件风格(事件驱动风格)**∶进程通信、事件驱动系统(隐式调用)
  4. 虚拟机风格︰解释器、基于规则的系统
  5. 仓库风格︰数据库系统、超文本系统、黑板系统

2.1 数据流风格

img.png

img.png

批处理序列

  • 构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始，数据必须是完整的，以整体的方式传递。

管道-过滤器

  • 每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理，然后产生输出数据流。这个过程通常是通过对输入数据流的变换或计算来完成的，
    包括通过计算和增加信息以丰富数据、通过浓缩和删除以精简数据、通过改变记录方式以转化数据和递增地转化数据等。
    这里的构件称为过滤器，连接件就是数据流传输的管道将一个过滤器的输出传到另一个过滤器的输入。
  • 早期编译器就是采用的这种架构。要一步一步处理的，均可考虑采用此架构风格。

2.2 调用/返回风格

主程序/子程序

  • 单线程控制，把问题划分为若千个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。
    过程调用作为交互机制，即充当连接件的角色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性
    面向对象

  • 构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，
    对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的
    层次结构

  • 构件组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，
    只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。
    修改某一层，最多影响其相邻的两层（通常只能影响上层)

img.png

2.3 独立构件风格(隐式调用)

进程通信

  • 构件是独立的过程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程（方法）调用等。

事件驱动系统(隐式调用)

  • 构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，
    当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。
    这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。
    主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便;其缺点是构件放弃了对系统计算的控制。

2.4 虚拟机风格

解释器（自定义需求的场景）

  • 解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，
    以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。

基于规则的系统

  • 基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存，一般用在人工智能领域和DSS中。

2.5 仓库风格

仓库风格中构件分两种:一种是中央数据结构，保存系统的当前状态;另一种是独立构件，对中央数据存储进行操作。

  1. 数据库系统
  2. 黑板系统(语音识别系统)
  • 包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。 知识源响应黑板的变化，也只修改黑板;黑板是一个全局数据库，包含问题域解空间的全部状态，
    是知识源相互作用的唯一媒介;知识源响应是通过黑板状态的变化来控制的。 黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。
  1. 超文本系统
  • 构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。
    超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。

现代集成编译环境一般采用仓库这种架构风格。

img.png

img.png

2.6 闭环控制架构

当软件被用来操作一个物理系统时，软件与硬件之间可以粗略地表示为一个反馈循环，这个反馈循环通过接受一定的输入，
确定一系列的输出，最终使环境达到一个新的状态。适合于嵌入式系统，涉及连续的动作与状态。

img.png

2.7 C2风格

C2架构的基本规则︰

  • 构件和连接件都有一个顶部和一个底部
  • 构件的顶部要连接到连接件的底部，构件的底部要连接到连接件的顶部，构件之间不允许直连
  • 一个连接件可以和任意数目的其它构件和连接件连接
  • 当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

img.png

2.8 分层架构风格

img_1.png

img.png

img.png

img.png

img.png

2.9 MVC架构风格

MVC的模型

  • Model（模型）是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。
  • View（视图）是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。
  • Controler(控制器）是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

J2EE体系结构中︰

  • 视图(View) : JSP
  • 控制 (Controller) : Servlet
  • 模型(Model) : Entity Bean、Session Bean

img_8.png

MVP模型 MVP是MVC的变种

  • MVP实现了V与M之间的解耦(V不直接使用M，修改V不会影响M)
  • MVP更好的支持单元测试(业务逻辑在P中，可以脱离V来测试这些逻辑;可以将一个P用于多个V，而不需要改变P的逻辑)
  • MVP中V要处理界面事件，业务逻辑在P中，MVC中界面事件由C处理

img_9.png

MVVM模型

img_10.png

富互联网应用(RIA)

img_11.png

2.10 基于服务的架构(SOA)

服务是一种为了满足某项业务需求的操作、规则等的逻辑组合，它包含一系列有序活动的交互，为实现用户目标提供支持。

  1. 服务构件粗粒度，传统构件细粒度居多
  2. 服务构件的接口是标准的，主要是WSDL接口，传统构件常以具体API形式出现服务构件的实现与语言无关，传统构件绑定某种特定语言
  3. 服务构件可以通过构件容器提供QoS的服务，传统构件完全由程序代码直接控制

img_12.png

img_13.png

img_14.png

img_15.png

企业服务总线的作用：

  1. 提供位置透明性的消息路由和寻址服务
  2. 提供服务注册和命名的管理功能
  3. 支持多种的消息传递范型
  4. 支持多种可以广泛使用的传输协议
  5. 支持多种数据格式及其相互转换
  6. 提供日志和监控功能

SOA-关键技术

img_16.png

SOAP ，Simple Object Access Protocol，简单对象访问协议，简单的说就是用于访问网络服务的协议;它是基于XML的简易协议，
可使应用程序在HTTP之上进行信息交换。SOAP是一种网络通信协议，用于网络上、不同平台、不同语言的应用程序间的通讯。

img_17.png

2.11 微服务（MicroServcie）

微服务顾名思义，就是很小的服务，所以它属于面向服务架构的一种。微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，
服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通
（通常是基于HTTP协议的RESTfulAPI)。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。
另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。

特点：小,且专注于做一件事情轻量级的通信机制松耦合、独立部署。

img_18.png

img_19.png

微服务的优势

  1. 技术异构性
  2. 弹性
  3. 扩展
  4. 简化部署(自动化部署)
  5. 与组织结构相匹配
  6. 可组合性
  7. 对可替代性的优化

微服务面临的挑战

  1. 分布式系统的复杂度
  2. 运维成本
  3. 部署自动化
  4. DevOps与组织结构
  5. 服务间依赖测试
  6. 服务间依赖管理

img_20.png

img_21.png

2.12 模型驱动架构MDA

img_22.png

img_23.png

三、架构描述语言ADL

ADL是这样一种形式化语言，它在底层语义模型的支持下，为软件系统的概念体系结构建模提供了具体语法和概念框架。
基于底层语义的工具为体系结构的表示、分析、演化、细化、设计过程等提供支持。

ADL的三个基本元素

  1. 构件∶计算或数据存储单元﹔
  2. 连接件∶用于构件之间交互建模的体系结构构造块及其支配这些交互的规则;
  3. 架构配置:描述体系结构的构件与连接件的连接图。

img_24.png

img_25.png

四、特定领域软件架构

img_26.png

img_27.png

  1. 领域专家: 有经验的用户、从事该领域中系统的需求分析、设计、实现以及项目管理的有经验的软件工程师等。领域专家的主要任务包括提供关于领域中系统的需求规约和实现的知识。
  2. 领域分析人员∶ 领域分析人员应由具有知识工程背景的有经验的系统分析员来担任。
  3. 领域设计人员: 领域设计人员应由有经验的软件设计人员来担任。
  4. 领域实现人员: 领域实现人员应由有经验的程序设计人员来担任。

img_28.png

五、基于架构的软件开发方法

5.1 基于架构的软件设计(ABSD)

img_29.png

ABSD方法是架构驱动，即强调由业务、质量和功能需求的组合驱动架构设计。使用ABSD方法，设计活动可以从项目总体功能框架明确就开始，这意味着需求获取和分析还没有完成(甚至远远没有完成），就开始了软件设计。

ABSD方法有三个基础:

  1. 第一个基础是功能的分解。在功能分解中，ABSD方法使用已有的基于模块的内聚和耦合技术;
  2. 第二个基础是通过选择架构风格来实现质量和业务需求;
  3. 第三个基础是软件模板的使用。软件模板利用了一些软件系统的结构。

ABSD方法是递归的，且迭代的每一个步骤都是清晰地定义的。因此，不管设计是否完成，架构总是清晰的，这有助于降低架构设计的随意性。

视角与视图︰从不同的视角来检查，所以会有不同的视图。

用例用来捕获功能需求、特定场景来捕获质量需求。

5.2 开发过程

架构文档化过程的主要输出结果是架构规格说明和测试架构需求的质量设计说明书这两个文档。文档的完整性和质量是软件架构成功的关键因素。

关于文档的三大注意事项:

  1. 文档要从使用者的角度进行编写
  2. 必须分发给所有与系统有关的开发人员
  3. 且必须保证开发者手上的文档是最新的

架构复审的目的是标识潜在的风险，及早发现架构设计中的缺陷和错误

img_31.png

img_32.png

img_33.png

六、软件质量属性

  1. 性能: 性能( performance )是指系统的响应能力，即要经过多长时间才能对某个事件做出响应，或者在某段时间内系统所能处理的事件的个数。

    • 代表参数:响应时间、吞吐量
    • 设计策略:优先级队列、资源调度

  2. 可用性: 可用性 ( availability ）是系统能够正常运行的时间比例。经常用两次故障之间的时间长度或在出现故障时系统能够恢复正常的速度来表示。

    • 代表参数:故障间隔时间
    • 设计策略:冗余、心跳线

  3. 安全性: 安全性( security)是指系统在向合法用户提供服务的同时能够阻止非授权用户使用的企图或拒绝服务的能力。安全性又可划分为机密性、完整性、不可否认性及可控性等特性。

    • 设计策略:追踪审计

  4. 可修改性: 可修改性( modifiability ）是指能够快速地以较高的性能价格比对系统进行变更的能力。通常以某些具体的变更为基准，通过考察这些变更的代价衡量可修改性。

    • 主要策略︰信息隐藏

  5. 可靠性: 可靠性(reliability ）是软件系统在应用或系统错误面前，在意外或错误使用的情况下维持软件系统的功能特性的基本能力。主要考虑两个方面∶容错、健壮性。

    • 代表参数:MTTF、MTBF
    • 设计策略:冗余、心跳线

  6. 功能性: 功能性(functionality ）是系统所能完成所期望的工作的能力。一项任务的完成需要系统中许多或大多数构件的相互协作。

  7. 可变性: 可变性 ( changeability)是指体系结构经扩充或变更而成为新体系结构的能力。这种新体系结构应该符合预先定义的规则，在某些具体方面不同于原有的体系结构。当要将某个体系结构作为一系列相关产品（例如，软件产品线)的基础时，可变性是很重要的。

  8. 互操作性: 作为系统组成部分的软件不是独立存在的，经常与其他系统或自身环境相互作用。为了支持互操作性( interoperation )，软件体系结构必须为外部可视的功能特性和数据结构提供精心设计的软件入口.程序和用其他编程语言编写的软件系统的交互作用就是互操作性的问题，这种互操作性也影响应用的软件体系结构。

七、软件架构评估

img_30.png

  1. 风险点:系统架构风险是指架构设计中潜在的、存在问题的架构决策所带来的隐患。
  2. 敏感点:是指为了实现某种特定的质量属性，一个或多个构件所具有的特性。
  3. 权衡点:是影响多个质量属性的特性，是多个质量属性的敏感点。

架构评估方式

  1. 基于调查问卷(检查表)的方式
  2. 基于度量的方式
  3. 基于场景的方式

img_34.png

img_35.png

img_36.png

img_37.png

八、软件产品线

img_38.png

img_39.png

img_41.png

img_40.png

九、构件与中间件技术

9.1 构件

构件的定义:

  1. 定义1∶软件构件是一种组装单元，它具有规范的接口规约和显式的语境依赖。软件构件可以被独立地部署并由第三方任意地组装。
  2. 定义2∶构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能。
  3. 定义3∶构件是一个独立发布的功能部分，可以通过其接口访问它的服务。

img_42.png

构件系统架构特性

  1. 构件系统体系结构由一组平台决策、一组构件框架和构件框架之间的互操作设计组成。构件框架是一种专用的体系结构（通常围绕一些关键的机制），同时，也是一组固定地作用于构件层次机制的策略。
  2. 概念框架的互操作设计包括系统体系结构连接的所有框架间的互操作的规则。
  3. 构件是一组通常需要同时部署的原子构件。构件和原子构件之间的区别在于，大多数原子构件永远都不会被单独部署，尽管它们可以被单独部署。
  4. 一个原子构件是一个模块和一组资源。
  5. 模块是一组类和可能的非面向对象的结构体，比如过程或者函数。资源是一个类型化的项的固定集合。
  6. 资源这个概念可以包含代码资源，进而包含模块。问题在于除了编译器编译一个模块或包生成的资源外，还可能存在其他的资源。在“纯对象”的方法中，资源是外部化的不可改变的对象——不可改变是因为构件没有持久化的标志，而且复制不能被区分。

构件的复用

img_43.png

img_44.png

img_45.png

img_46.png

9.2 消息中间件

img_47.png

采用中间件技术的优点

  1. 面向需求。即设计师集中精力于业务逻辑本身。
  2. 业务的分隔和包容性。应用开发人员可以按照不同的业务进行功能的划分，体现为不同的接口或交互模式。
  3. 设计与实现隔离。构件对外发生作用或构件间的交互，都是通过接口进行的，构件使用者只需要知道构件的接口，而不必关心其内部实现，这是设计与实现分离的关键。
  4. 隔离复杂的系统资源。架构很重要的一个功能就是将系统资源与应用构件隔离，这是保证构件可复用甚至“即插即用”的基础，与中间件的意图也是一致的。
  5. 符合标准的交互模型。中间件则实现了架构的模型，实现了标准的协议。
  6. 软件复用。中间件提供了构件封装、交互规则、与环境的隔离等机制，这些都为软件复用提供了方便的解决方案。
  7. 提供对应用构件的管理。基于中间件的软件可以方便地进行管理，因为构件总可以通过标识机制进行划分。

img_48.png

img_49.png

img_50.png

CORBA体系的主要内容包括以下几部分︰

  1. 对象请求代理（ Object Request Broker，ORB)。负责对象在分布环境中透明地收发请求和响应，它是构建分布对象应用、在异构或同构环境下实现应用间互操作的基础。一
  2. 对象服务（ObjectServices )。为使用和实现对象而提供的基本对象集合，这些服务应独立于应用领域。
  3. 公共设施(Common Facilitites )。向终端用户提供一组共享服务接口，例如系统管理、组合文档和电子邮件等。
  4. 应用接口( ApplicationInterfaces )。由销售商提供的可控制其接口的产品，相应于传统的应用层表示，处于参考模型的最高层。
  5. 领域接口(Domain Interfaces )。为应用领域服务而提供的接口，如OMG组织为PDM系统制定的规范。

img_51.png

十、Web架构设计

img_52.png

img_53.png

img_54.png

img_55.png

img_56.png

10.1 有状态与无状态

  • 无状态服务(stateless service )对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到(比如说数据库），服务器本身不存储任何信息。
  • 有状态服务（statefulservice )则相反，它会在自身保存一些数据，先后的请求是有关联的。

10.2 数据库读写分离化

img.png

10.3 用缓存缓解读库的压力

img_1.png

  1. MemCache :Memcache是一个高性能的分布式的内存对象缓存系统，用于动态Web应用以减轻数据库负载。Memcache通过在内存里维护一个统一的巨大的hash表，它能够用来存储各种格式的数据，包括图像、视频、文件以及数据库检索的结果等。
  2. Redis : Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。
  3. Squid : Squid是一个高性能的代理缓存服务器，Squid支持FTP、gopher、HTTPS和HTTP协议。和一般的代理缓存软件不同，Squid用一个单独的、非模块化的、I/O驱动的进程来处理所有的客户端请求。

Redis 与 Memcache的差异

  1. Redis和Memcache都是将数据存放在内存中，都是内存数据库。他们都支持key-value数据类型。同时Memcache还可用于缓存其他东西，例如图片、视频等等，Redis还支持list.set、hash等数据结构的存储。
  2. Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。Memcache挂掉之后，数据就没了。
  3. 灾难恢复-Memcache挂掉后，数据不可恢复; Redis数据丢失后可以恢复。
  4. 在Redis中，并不是所有的数据都一直存储在内存中的。这是和Memcache相比一个最大的区别。当物理内存用完时，Redis可以将一些很久没用到的value交换到磁盘。
  5. Redis在很多方面支持数据库的特性，可以这样说他就是一个数据库系统，而Memcache只是简单地K/V缓存。

所以在选择方面如果有持久方面的需求或对数据类型和处理有要求的应该选择Redis.如果简单的key/value存储应该选择Memcache。

10.4 缓存技术

img_2.png

img_3.png

img_5.png

10.5 CDN网络技术

CDN的全称是Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。

img_4.png

10.6 XML与JSON

扩展标记语言(Extensible Markup Language, XML)，用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。

XML的优点

  1. 格式统一，符合标准;
  2. 容易与其他系统进行远程交互，数据共享比较方便。

XML的缺点

  1. XML文件庞大，文件格式复杂，传输占带宽;
  2. 服务器端和客户端都需要花费大量代码来解析XML，导致服务器端和客户端代码变得异常复杂且不易维护;
  3. 客户端不同浏览器之间解析XML的方式不一致，需要重复编写很多代码;
  4. 服务器端和客户端解析XML花费较多的资源和时间。

JSON(JavaScript Object Notation)一种轻量级的数据交换格式，具有良好的可读和便于快速编写的特性。可在不同平台之间进行数据交换。

JSON的优点

  1. 数据格式比较简单，易于读写，格式都是压缩的，占用带宽小;
  2. 易于解析，客户端JavaScript可以简单的通过eval()进行JSON数据的读取﹔
  3. 支持多种语言，包括ActionScript,C. C#，ColdFusion，Java，JavaScript,Perl,PHP. Python,Ruby等服务器端语言，便于服务器端的解析;
  4. 因为JSON格式能直接为服务器端代码使用，大大简化了服务器端和客户端的代码开发量，且完成任务不变，并且易于维护。

JSON的缺点

没有XML格式这么推广的深入人心和喜用广泛，没有XML那么通用性。

10.7 WEB应用服务器

WEB应用服务器可以理解为两层意思∶

  1. WEB服务器︰其职能较为单一，就是把浏览器发过来的Request请求返回Html页面。
  2. 应用服务器∶进行业务逻辑的处理。

常见的WEB应用服务器

  1. Apache: Web服务器，市场占有率达60%左右。它可以运行在几乎所有的Unix,Windows、Linux系统平台上。
  2. IIS:早期Web服务器，目前小规模站点仍有应用。
  3. Tomcat:开源、运行servlet和JSP Web应用软件的基于Java的Web应用软件容器。
  4. JBOSS: JBOSS是基于J2EE的开放源代码的应用服务器。一般与Tomcat或Jetty绑定使用。WebSphere :一种功能完善、开放的Web应用程序服务器，它是基于Java的应用环境，用于建立、部署和管理Internet和Intranet Web应用程序。
  5. WebLogic: BEA Weblogic Server 是一种多功能、基于标准的web应用服务器，为企业构建自己的应用提供了坚实的基础。
  6. Jetty: Jetty是一个开源的servlet容器，它为基于Java的web容器。

10.8 REST(表述性状态传递)

REST ( Representational State Transfer，表述性状态转移)是一种只使用HTTP和XML进行基于Web通信的技术，
可以降低开发的复杂性，提高系统的可伸缩性。REST的5个原则

  1. 网络上的所有事物都被抽象为资源。
  2. 每个资源对应一个唯一的资源标识。
  3. 通过通用的连接件接口对资源进行操作。
  4. 对资源的各种操作不会改变资源标识。
  5. 所有的操作都是无状态的。

10.9 响应式Web设计

响应式WEB设计是一种网络页面设计布局，其理念是:集中创建页面的图片排版大小，可以智能地根据用户行为以及使用的设备环境进行相对应的布局。

方法与策略

  • 采用流式布局和弹性化设计∶使用相对单位，设定百分比而非具体值的方式设置页面元素的大小。
  • 响应式图片∶不仅要同比的缩放图片，还要在小设备上降低图片自身的分辨率。

10.10 中台设计

中台是一套结合互联网技术和行业特性，将企业核心能力以共享服务形式沉淀，形成“大中台、小前台”的组织和业务机制，供企业快速低成本的进行业务创新的企业架构。中台又可以进一步细分，比如业务中台，数据中台，XX中台。本质上，都是对企业通用能力在不同层面的沉淀，并对外能力开放。
中台的践行者︰Supercell:芬兰移动游戏巨头，2015年世界游戏前10占5席，员工仅200多人，因使用中台，具有小团队快速开发能力，后被腾讯86亿美金收购。阿里:2015年参观Supercell，而后推行中台。

img_6.png

img_7.png

业务中台与数据中台

  • 多个电商渠道使用一个下单服务，一个订单接口同时为多个前台系统提供服务。
  • 多个前台系统，根据一个用户的手机号，获取对应的画像，用户的标签。
  • 将多个支付通道，抽象建立成一个发付API，暴露给前台业务系统。
  • 通过一个订单编号，来获取可能的商品推荐清单，从而做到交叉销售。
系统架构师
#软考 #系统架构师 #软件架构设计
系统架构师-软件架构设计
https://muchen.fun/passages/system-architect/03-软件架构设计/01-软件架构设计/
作者
沐晨
发布于
2024年4月2日
许可协议