2024 nju se 研 软件体系结构 期末笔记

CSDN复制过来的格式不得的，建议去在线文档看：
【金山文档 | WPS云文档】 njuse 软件体系结构 期末笔记
https://kdocs.cn/l/cttpbHIgNFiy

笔记：

第一个PPT

第一次提到NRF

。Non-functional requirements (NFRs) define "how well a system works?"

。NFRs rarely captured in functional requirements

. aka. architecture requirements

. Must be elicited by architect

。NFRs include:

. Technical constraints

. Business constraints

. Quality attributes

- 非功能性需求（NFRs）定义了“系统工作得如何？”

- NFRs很少在功能需求中被捕捉到

  - 也称为架构需求

  - 必须由架构师引出

- NFRs包括：

  - 技术约束

  - 商业约束

  - 质量属性

Generic Design Strategies:

. Decomposition

. Abstraction

. Stepwise: 'Divide and Conquer'

. Generate and Test

. literation: Incremental Refinement

. Reusable elements

通用设计策略：

- 分解

- 抽象

- 逐步："分而治之"

- 生成和测试

- 迭代：增量细化

- 可重用元素

P. Krutchen's 4+1 View Model

. Logical view: describes architecturally significant elements of the architecture and the relationships between them.

. Process view: describes the concurrency and communications elements of an architecture.

. Physical view: depicts how the major processes and components are mapped on to the applications hardware.

. Development view: captures the internal organization of the software components as held in e.g., a configuration management tool.

- Architecture use cases: capture the requirements for the architecture; related to more than one particular view

克鲁琴的4+1视图模型

. 逻辑视图：描述架构中具有重要意义的元素以及它们之间的关系。

. 进程视图：描述架构的并发性和通信元素。

. 物理视图：描绘主要进程和组件如何映射到应用程序硬件上。

. 开发视图：捕获软件组件的内部组织，如在配置管理工具中的信息。

- 架构用例：捕获架构的需求；与多个特定视图相关。

第二个PPT

软件架构定义：

Software Architecture is the structure or structures of the system, which comprise software elements, the externally visible properties of these components, and the relationship among them.

软件体系结构是系统的一个或多个结构，包括软件元素、这些组件的外部可见特性以及它们之间的关系。

Box-and-line drawings alone are not architecture, but a starting point.

Architecture includes behaviour of components.

框线图本身不是架构，而是一个起点。

架构包括组件的行为。

软件架构的角色

.An architecture is one of the first artifacts that represents decision on how requirements are to be achieved.As the manifestation of early design decisions, the architecture represents those design decisions that are hardest to change and hence deserve the most careful consideration.

.An architecture is the key artefact in achieving successful product line engineering, the disciplined development of a family of similar system with less effort, expense, and risk than developing each system independently.

.An architecture is usually the first design artefact to be examined when someone starts working on a system.

.Software architecture provides a framework of reference for maintenance and modification decisions.

一个架构是最早代表如何实现需求的决策之一。作为早期设计决策的体现，架构代表了那些最难改变的设计决策，因此值得最仔细的考虑。

架构是实现成功产品线工程的关键工件，即以比独立开发每个系统更少的努力、成本和风险，有纪律地开发一系列类似的系统。

当某人开始在系统上工作时，架构通常是第一个被检查的设计工件。

软件架构为维护和修改决策提供了一个参考框架。

Why is software architecture important ?

- Software architecture provides a vehicle for communication

  - It is a frame of reference in which competing interests may be identified and negotiated

    . Negotiating requirements with users

    . Keeping customer informed of progress, cost etc.

    . Implementing management decisions and allocations.

Software architecture manifests the earliest set of design decisions

  - It constraints the implementation and developers

    - Implementation must conform to architecture

    - Resource allocation decisions constrain implementations of individual components

Manifestation of early design decisions

  . Software architecture dictates organizational structure for development & maintenance efforts, e.g.,

    . Division into teams

    . Units for budgeting, planning

    . Basis of Work Breakdown Structure

    . Organization for documentation

    . Organization for CM libraries

    . Basis of integration

    . Basis of test plans, testing

. Basis of maintenance

为什么软件架构很重要？

- 软件架构提供了一种沟通的载体

  - 它是一个参考框架，可以在其中识别并协商相互竞争的利益

    - 与用户协商需求

    - 向客户通报进展、成本等信息

    - 实施管理决策和分配

软件架构体现了最早的设计决策集

  - 它约束了实现和开发者

    - 实现必须遵循架构

    - 资源分配决策约束了各个组件的实现

早期设计决策的体现

  - 软件架构规定了开发和维护工作的工作组织结构，例如，

    - 团队划分

    - 预算、规划的单位

    - 工作分解结构的基础

    - 文档组织

    - CM库的组织

    - 集成的基础

    - 测试计划、测试的基础

    - 维护的基础

Software Architecture process

软件架构过程

Stakeholders①, 涉众

Specifying ASRs②, 制定架构关键需求

Patterns and tactics③.1, 模式和策略

Prioritized Quality Attribute Scenarios③.2, 已排序的质量属性场景

Requirements and constraints③.3, 需求和约束

Architecture design④, 架构设计

"Sketches" of candidate views, Determined by patterns⑤, 由模式决定的视图草图

Documenting, ⑥文档化

Chosen, combined views plus doc'n. beyond views⑦.1, 选择，组织视图和文档

Architecture Evaluation⑦.2架构评估

①→②⑥⑦.2

③.2→④⑦.2

功能性需求

. Functional requirements state what the system must do and address how the system provides value to the stakeholders.

. Functional requirements means the behaviour of the system.

. Functionality is the ability of the system to do the work for which it was intended, e.g., enable students to enrol online.

. Functionality may be achieved through the use of any number of possible structures.

. Functionality is largely independent of structure,because it could exist as a single monolithic system without any internal structure.

. 系统的功能需求说明系统必须做什么，以及系统如何为利益相关者提供价值。

. 功能需求指的是系统的行为。

. 功能是系统完成其预期工作的能力，例如，允许学生在线注册。

. 功能可以通过使用任何可能的结构来实现。

. 功能在很大程度上独立于结构，因为它可以作为一个单一的单体系统存在，没有任何内部结构。

质量需求

. Quality requirements are desirable characteristics of the overall system (aka. quality attributes) that system should provide on the top of its functional requirements.

. Quality requirements are qualifications of the functional requirements or of the overall product.

. Software architecture constrains the allocation(mapping) of the functionality onto various structures if quality attributes are important.

. 质量需求是系统整体所期望的特性（也称为质量属性），系统应在其功能需求之上提供这些特性。

. 质量需求是功能需求或整体产品的资质要求。

. 如果质量属性很重要，软件架构会限制功能分配（映射）到各种结构上的方式。

约束

. A constraint is a design decision with ZERO degrees of freedom.

. Constraints are pre-specified design decisions that have been already made.

. Constraints are satisfied by accepting the design decision and reconciling it with other affected design decisions.

- 约束是一个具有零自由度的设计决策。

- 约束是已经预先确定的设计决策。

- 通过接受设计决策并将其与其他受影响的设计决策协调一致来满足约束。

非功能性需求

. Non-functional requirements or architectural requirements are alternative terms used for quality attributes.

. It is not possible to get the functionality right and then try to accommodate non-functional requirements (NO retro-fitting quality).

· Non-functional requirements must be taken into account during any design decision.

· There are two broad categories of non-functional requirements:

。Observable(External) during execution: How well a system satisfies its behavioral requirements? e.g., performance, security, availability, usability etc.

。Not observable(Internal) during development &maintenance: How easily a system can be maintained, integrated, or tested? e.g.,modifiability, portability, reusability, testability etc.

. 非功能性需求或架构需求是用于质量属性的替代术语。

. 无法先正确实现功能，然后尝试适应非功能性需求（不能事后添加质量）。

. 在任何设计决策中都必须考虑非功能性需求。

. 非功能性需求大致分为两类：

. 可观察（外部）在运行期间：系统满足其行为需求的程度如何？例如，性能、安全性、可用性、易用性等。

. 不可观察（内部）在开发和维护期间：系统维护、集成或测试的容易程度如何？例如，可修改性、可移植性、可重用性、可测试性等。

质量

. Quality isn't something that can be added to a software intensive system after development finishes.

. Quality concerns need to be addressed during ALL phases of the software development.

. Business goals determine qualities that a system must possess.

. Quality attributes are over and above of system's functionality, which is the basic statement of the system's capabilities, services, and behaviors.

. Functionality usually takes the front seat in the development plan.

. However, systems are usually redesigned because they lack desired level of quality, i.e. difficult to maintain, port, or scale.

. Software architecture constrains the achievement of various quality attributes, e.g., performance, security, usability etc.

. That is why software architecture is considered the most appropriate level of addressing the quality issues.

. No quality attribute is entirely dependent on design, nor is it dependent on implementation or deployment.

质量不是在软件开发完成后可以添加到软件密集型系统中的东西。

在软件开发的所有阶段都要考虑质量问题。

商业目标决定了系统必须具备的质量。

质量属性是系统功能之上的，这是系统能力、服务和行为的基本陈述。

功能通常在开发计划中占据首位。

然而，系统通常因为缺乏所需的质量水平而被重新设计，例如难以维护、移植或扩展。

软件架构限制了实现各种质量属性的成就，例如性能、安全性、可用性等。

这就是为什么软件架构被认为是解决质量问题最合适的层次。

没有任何质量属性完全依赖于设计，也不依赖于实现或部署。

Specifying Quality Attributes

. Precise definition of a quality attribute is necessary to evaluate it at the architecture level.

. Quality attribute scenarios are used to define the desired quality attribute.

· Scenarios are simple descriptions with certain structure. Two main classes of scenarios are:

  . General scenarios are system independent scenarios to guide the specification of quality attribute requirements.

  . Concrete scenarios are system specific scenarios to guide the specification of quality attribute requirements for a particular system. They are instances of generals scenarios.

指定质量属性

. 精确定义质量属性是必要的，以便在架构层面评估它。

. 使用质量属性场景来定义所需的质量属性。

. 场景是具有一定结构的简单描述。场景主要分为两类：

. 通用场景是系统无关的场景，用于指导质量属性需求的指定。

. 具体场景是针对特定系统的系统特定场景，用于指导特定系统的质量属性需求。它们是通用场景的实例。

. Stimulus: A condition that needs to be considered when it arrives at a system.

. Source of Stimulus: An entity (human, system, or any actuator) that generates the stimulus.

. Response: The activity undertaken after the arrival of the stimulus.

. Response Measure: The response to the stimulus should be measurable in some fashion so that the requirement can be testable.

. Environment: A system's condition when a stimulus occurs, e.g., overloaded, running etc.

. Artifact: The whole system or the portion of the system to which the requirement applies.

- 刺激：到达系统时，需要考虑的一种条件。

- 刺激源：生成刺激的实体（人类、系统或任何执行器）。

- 响应：刺激到达后进行的活动。

- 响应度量：对刺激的响应应该以某种方式可测量，以便需求可以被测试。

- 环境：刺激发生时系统的状态，例如，过载、运行中等。

- 工件：整个系统或需求适用的系统部分。

可用性

Period of loss of availability determined by:

1. Time to detect failure
2. Time to correct failure
3. Time to restart application

Strategies for high availability include:

1. Eliminate single points of failure.
2. Replication and failover
3. Automatic detection and restart.

Recoverability (e.g., a database)

1. The capability to re-establish performance levels and recover affected data after an application or system failure.

可用性损失期时长由以下因素决定：

1.检测故障的时间

2.纠正故障的时间

3.重新启动应用程序的时间

高可用性策略包括：

1.消除单点故障。

2.复制和故障转移

3.自动检测并重新启动。

可恢复性（例如，数据库）

1. 在应用程序或系统故障后重新建立性能级别并恢复受影响数据的能力。

-可用性可以计算为在指定的时间间隔内在所需范围内提供指定服务的概率。

。MTBF（平均无故障时间）

。MTTR（平均修复时间）

MTBF/（MTBF+MTTR）

。在计算可用性时，可能不考虑计划中的停机时间。

outage, failure, fault and error

Availability is about minimizing the service outage time by mitigating faults.

A failure's cause is called a fault.

A failure occurs when a system cannot deliver a service that is expected of that system.

A failure is an observable characteristics of a system's state.

A fault in any part of a system has a potential to cause a failure; a system can be repaired or recovered from a failure.

Intermediate states between the occurrence of a fault and a failure are called errors.

可用性是关于通过减轻故障来最小化 服务中断时间。

故障的原因称为错误。

当系统无法提供预期的服务时，就会发生故障。

故障是系统状态的可观察特征。

系统中任何部分的错误都有可能导致 故障；系统可以从故障中被修复或恢复。

错误(error)是发生在错误(fault)发生和故障之间的中间状态。

互操作性

. Interoperability is about the degree to which two or more systems can usefully exchange meaningful information via interfaces in a particular context.

。Ability to exchange data (syntactic interoperability)

。Ability to correctly interpret the data (semantic interoperability)

. Interoperability needs to identify with whom, with what, and under what circumstances (the context).

互操作性是指两个或多个系统能够在特定上下文中通过接口有效地交换有意义的信息的程度。

。交换数据的能力（句法互操作性）

。正确解释数据的能力（语义互操作性）

.互操作性需要确定与谁、通过什么消息以及在什么情况下（上下文）。

。Two important aspects of interoperability:

. Discovery: the consumer of a service must discover the location, identity, and the interface of the service.

. Handling of the response:

. reports back to the requester with response.

. sends its response on to another system.

. broadcasts its response to any interested parties.

。互操作性的两个重要方面：

。发现：服务的使用者必须发现服务的位置、标识和接口。

。答复的处理：

.向请求者报告并作出响应。

.将其响应发送到另一个系统。

.向任何相关方广播其回应。

. An Architecturally Significant Requirement(ASR) is a requirement that will have a profound effect on the architecture - the architecture might well be dramatically different in the absence of such a requirement.

.The more difficult and important the QA requirement,the more likely it is to significantly affect the architecture, and hence to be an ASR.

. How to systematically identify the ASRs and other factors that will shape the architecture?

. Gathering ASRs from requirements documents.

. Gathering ASRs by interviewing stakeholders.

. Gathering ASRs by understanding the business goals

. Capturing ASRs in a utility tree

Architecturally Significant Requirement（ASR）是一种将对体系结构产生深远影响的需求-如果没有这样的需求，体系结构可能会有显著的不同。

.QA需求越困难、越重要，就越有可能显著影响体系结构，从而成为ASR。

.如何系统地识别ASR和其他将塑造架构的因素？

.从需求文档中收集ASR。

.通过访谈利益相关者收集ASR

.通过了解业务目标来收集ASR

.在实用程序树中捕获ASR

.Quality Attribute Workshop (QAW)

。1) QAW presentation and introductions

。2) Business mission presentation

。3) Architectural plan presentation

。4) Identification of architectural drivers: to reach a consensus on a distilled list of architectural drivers that includes overall requirements, business drivers, constraints,and quality attributes.

。5)Scenario brainstorming: each stakeholder expresses a scenario representing his/her concerns with respect to the system.

。6) Scenario consolidation (merging similar scenarios)

。7) Scenario prioritization(by voting)

。8) Scenario refinement: the top scenarios are refined and elaborated.

The results of QAW include a list of architectural drivers and a set of QA scenarios that the stakeholders (as a group prioritized).

质量属性研讨会（QAW）

质量属性研讨会（QAW）

1. QAW演示和介绍
2. 商业使命演示
3. 架构计划演示
4. 识别架构驱动因素：达成共识，提炼出包括总体要求、业务驱动因素、约束条件和质量属性的架构驱动因素列表。
5. 场景头脑风暴：每个利益相关者表达一个代表其对系统的关切的场景。
6. 场景整合（合并类似场景）
7. 场景优先级排序（通过投票）
8. 场景细化：细化和阐述优先级最高的场景。

QAW的成果包括一份架构驱动因素列表和一组利益相关者（作为一个群体优先考虑的）质量属性场景集。

第三个PPT

An architectural pattern is a set of architectural design decisions that are applicable to a recurring design problem, and parameterized to account for different software development contexts in which that problem appears.

Architectural patterns are similar to DSSAs but applied "at a lower level" and within a much narrower scope.

架构模式是一组架构设计决策，适用于重复出现的设计问题，并进行参数化，以考虑出现该问题的不同软件开发上下文。

架构模式类似于DSSA，但应用于“较低级别”和更窄的范围内。

Domain-Specific Software Architectures (DSSA) is an assemblage of software components

. specialized for a particular type of task (domain)

. generalized for effective use across that domain, and

. composed in a standardized structure (topology) effective for building successful applications.

DSSAs are the pre-eminent means for maximal reuse of knowledge and prior development and hence for developing a new architectural design



特定于域的软件架构（DSSA）是软件组件的集合

.专门用于特定类型的任务（域）

.在该领域内有效使用的通用化，以及

.以标准化结构（拓扑）组成，有效地构建成功的应用程序。

DSSA是最大限度地重用知识和先前开发，从而开发新架构设计的卓越方法

分层模式

Overview

The layered pattern defines layers (groupings of modules that offer a cohesive set of services) and a unidirectional allowed-to-use relation among the layers. The pattern is usually shown graphically by stacking boxes representing layers on top of each other.

Elements

Layer, a kind of module. The description of a layer should define what modules the layer contains and a characterization of the cohesive set of services that the layer provides.

Relations

Allowed to use, which is a specialization of a more generic depends-on relation. The design should define what the layer usage rules are (e.g., "a layer is allowed to use any lower layer" or "a layer is allowed to use only the layer immediately below it") and any allowable exceptions.

Constraints

. Every piece of software is allocated to exactly one layer.

. There are at least two layers (but usually there are three or more).

. The allowed-to-use relations should not be circular(i.e., a lower layer cannot use a layer above).

Weaknesses

. The addition of layers adds up-front cost and complexity to a system.

. Layers contribute a performance penalty.

概述

分层模式定义了层（提供一组凝聚性服务的模块组）以及层之间的单向允许使用关系。该模式通常通过将代表层的方框堆叠在一起来图形化展示。

元素

层，一种模块类型。层的描述应定义该层包含哪些模块以及该层提供的一组凝聚性服务的特征。

关系

允许使用，这是更通用的依赖关系的一种特化。设计应定义层的用法规则是什么（例如，“一个层允许使用任何更低层”或“一个层只允许使用紧接其下的层”）以及任何允许的例外情况。

约束

· 每段软件都被分配到恰好一个层中。

· 至少存在两个层（但通常有三个或更多）。

· 允许使用关系不应是循环的（即，低层不能使用高层）。

弱点

· 增加层级会增加系统的初始成本和复杂性。

· 层级会导致性能损失。

Service-Oriented Pattern(SOA)

Connectors in SOA

. SOAP(Simple Object Access Protocol): Service consumers and providers interact by exchanging request/reply XML messages typically on top of HTTP.

. REST (Representational State Transfer) : A service consumer sends HTTP requests that rely on four basic HTTP commands (POST,GET,PUT,DELETE)

. Asynchronous messaging ("fire-and-forget"):Participants do not have to wait for an

acknowledgment of receipt.

SOA中的连接器

· SOAP（简单对象访问协议）：服务消费者和服务提供者通过在HTTP之上交换请求/回复XML消息进行交互。

· REST（表述性状态转移）：服务消费者发送依赖于四个基本HTTP命令（POST、GET、PUT、DELETE）的HTTP请求。

· 异步消息传递（“发射后不管”）：参与者无需等待接收确认。

Architecture Patterns and Tactics

· Tactics are simpler than patterns; they use a single structure or mechanism to address a single architectural force.

. Patterns typically combine multiple design decisions into a package.

. Patterns and tactics together constitute the software architect's primary tools.

. Tactics are "building blocks" of design from which architectural patterns are created.

· Most patterns consist of several different tactics that may:

. all serve a common purpose,

. be often chosen to promise different quality attributes.

. Example: layered pattern

. Increase semantic coherence

. Restrict dependencies

- 策略比模式更简单；它们使用单一的结构或机制来解决单一的架构影响因素。

- 模式通常将多个设计决策组合成一个包。

- 模式和策略共同构成了软件架构师的主要工具。

- 策略是设计的“构建块”，从中创建出架构模式。

- 大多数模式由几种不同的策略组成，这些策略可能：

  - 都服务于一个共同的目的，

  - 为了确保不同的质量属性经常被选择。

- 示例：分层模式

  - 提高语义一致性

  - 限制依赖性

第四个PPT

. What about the non-ASR requirements?

。The choice of ASRs implies a prioritization of there quirements.

。A) You can still meet the other requirements.

。B) You can meet the others with a slight adjustment ofthe existing design.

。C) You cannot meet the others under the current design.

. a) you are close to meeting the requirements.

. b) re-prioritize the requirements and revisit the design.

. c) you cannot meet requirements.

. Design for all of ASRs or one at a time?

。The answer is a matter of experience.

。Through experience and education, you will develop an intuition for designing, and employ patterns/tactics to aid you in designing for multiple ASRs.

非ASR要求如何处理？

· 选择ASR（架构重要需求）意味着对需求进行了优先级排序。

· A) 你仍然可以满足其他需求。

· B) 你可以通过轻微调整现有设计来满足其他需求。

· C) 在当前设计下，你无法满足其他需求。

· a) 你接近满足需求。

· b) 重新排序需求并重新审视设计。

· c) 你无法满足需求。

针对所有ASR或逐一设计？

· 答案取决于经验。

· 通过经验和教育，你将培养出设计直觉，并运用模式/策略来帮助你同时为多个ASR进行设计。

View a particular design as a hypothesis: the things wrong with the current design hypothesis are fixed in the next design hypothesis, and the things right are kept.

. Where does the initial hypothesis come from?

  . Existing systems

  . Frameworks (partial designs)

  . Patterns and tactics

  . Design checklists (providing guidance and confidence)

. What are the tests that are applied?

  . Analysis techniques

  . Design checklists

. How is the next hypothesis generated?

. When are you done?

  . Either have a design that satisfies the ASRs or when you exhaust your budget for design.

  . implement the best hypothesis you made

将特定设计视为假设：当前设计假设中的错误在下一个设计假设中得到修正，而正确的内容则被保留。

初始假设从何而来？

· 现有系统

· 框架（部分设计）

· 模式和策略

· 设计检查清单（提供指导和信心）

应用哪些测试？

· 分析技术

· 设计检查清单

如何生成下一个假设？

何时完成？

· 要么得到一个满足ASR（架构重要需求）的设计，要么在你用尽设计预算时。

· 实施你提出的最佳假设。

ADD

1:confirm there is sufficient requirements information

2:choose an element of the system to decompose

3:identify the ASRs for the chosen element

4:choose a design concept that satisfies the ASRs

4.1:identify design concerns

4.2:list alternative patterns/tactics for subordinate concerns

4.3:select patterns/tactics from the list

4.4:determine relationship between patterns/tactics and ASRs

4.5:capture preliminary architectural views

4.6:evaluate and resolve inconsistencies

5:instantiate architectural elements and allocate responsibilities

6:define interfaces for instantiated elements

7:verify and refine requirements and make them constraints for instantiated elements

8:Repeat 1-7 until all the ASRs have been satisfied

1: 确认有足够的需求信息

2: 选择系统的一个元素进行分解

3: 确定所选元素的架构需求（ASRs）

4: 选择满足ASRs的设计概念

4.1: 识别设计关注点

4.2: 列出次要关注点的备选模式/策略

4.3: 从列表中选择模式/策略

4.4: 确定模式/策略与ASRs之间的关系

4.5: 捕捉初步的架构视图

4.6: 评估并解决不一致性

5: 实例化架构元素并分配责任

6: 为实例化的元素定义接口

7: 验证并细化需求，使其成为实例化元素的约束

8:重复1-7直到所有的ASR都被满足

Outputs of ADD

. software element: a computational or developmental artifact that fulfills various role sand responsibilities, has defined properties,and relates to other software elements to compose the architecture of a system

. role: a set of related responsibilities

. responsibility: the functionality, data, or information that a software element provides.

. property: additional information about a software element

. relationship: a definition of how two software elements are associated with or interact with one another

. 软件元素：一个计算或开发工件，它履行各种角色和责任，具有定义的属性，并与其他软件元素相关联以组成系统的架构

. 角色：一组相关的责任

. 责任：软件元素提供的功能、数据或信息

. 属性：关于软件元素的额外信息

. 关系：定义两个软件元素如何相互关联或相互作用的方式

第五个PPT 微服务

>单体架构的好处

·易于开发(Development)

—个应用(不复杂)

·易于修改(Modifiability)

代码和数据库模式

·易于测试(Testability)

端到端测试、UI测试

·易于部署(Deployability)

WAR文件复制

·易于伸缩(Scalability)

多个实例负载均衡

>单体架构的问题

·过度复杂性

·理解、数以千计JAR文件和百万行代码

·修复bug和实现新功能易出错、脏泥球

·开发速度缓慢

·lDE编辑-构建-启动运行

·部署周期长且易出错

·微小变更同—代码库提交、构建

·变更测试(持续集成测试套件、手动)

·难以扩展

·资源冲突

·可靠性差

·无法全面测试

·缺少故障隔离

·过期技术栈

分层架构是对复杂系统进行抽象和分层、结构化设计的架构方案

>垂直架构(结构简单，易于组织开发、测试和维护)

·表现层、业务层、(持久层)、数据层

·关注点分离原则

·软件元素的独特性

·责任分离

·高内聚、低耦合

· SOLID原则

·单一职责原则(Single Responsibility Principle)·开闭原则(Open/Closed Principle)·里氏替换原则(Liskov Substitution Principle)·接口隔离原则(Interface Segregation Principle)·依赖倒置原则(Dependency Inversion Principle)

问题：

·业务增长，更多、更高的非功能性需求，可用性、可靠性等

·单向层级调用性能代价

·紧耦合重复造轮子，堕落成无序的网状结构

>面向服务架构(SOA)

是一个分布式组件的集合，这些组件为其它组件提供服务(provider)，或者消费其它组件所提供的服务(consumer)，而无需知道其它组件的实现细节。

>企业服务总线(ESB)

为服务间的相互调用提供支持环境，路由服务间的消息，并对消息和数据进行必要的转换。

>服务编排引擎(Orchestration Engine)

可以根据预先定义的脚本对服务消费者与服务提供者之间的交互进行指挥。

·面向服务架构的特点:

+服务自身高内聚、服务间松耦合，最小化开发维护中的相互影响

+良好的互操作性，符合开放标准

+模组化，高重用性

+服务动态识别、注册、调用

-系统复杂性提高

-难以测试验证

-各独立服务的演化不可控

-中间件易成为性能瓶颈

·面向服务架构实现原则:

·服务解耦:服务之间的关系最小化，只是互相知道接口

·服务契约:服务按照描述文档所定义的服务契约行事

·服务封装:除了服务契约所描述内容，服务将对外部隐藏实现逻辑

·服务重用:将逻辑分布在不同的服务中，以提高服务的重用性

·服务组合:一组服务可以协调工作，组合起来形成定制组合业务需求

·服务自治:服务对所封装的逻辑具有控制权

·服务无状态:服务将一个活动所需保存的资讯最小化

微服务架构

服务解耦组件化

轻量级通信机制

非共享数据库

独立部署运行

独立扩展伸缩

去中心化协同管理

微服务架构 |定义

概括性描述:

微服务架构是把应用程序功能性分解为一组服务的架构风格，每一个服务都是由一组专注、内聚的功能职责组成。

微服务架构是一种将单体应用拆分为细粒度的服务，并使其运行在独立进程中，服务之间采用轻量级通信机制(如HTTP RESTful API)进行交互的架构风格。这些服务围绕系统的业务能力构建，且可以通过全自动的部署机制进行独立部署。服务可以进行分布式管理，从而支持不同的编程语言进行开发和不同的数据存储技术进行存储。

微服务拆分设计

1.定义系统操作

• 将需求提炼为系统必须处理的关键请求（系统操作）

• 定义架构的第一步

• 描述服务之间协作方式的架构场景

• 如更新/检索数据等

• 由抽象的领域模型定义

• 领域模型从需求派生

步骤1：分析用户故事中频繁出现的名词，创建（抽象的）领域模型

步骤2：分析用户故事和场景中的动词，确定系统操作

2. 定义微服务（围绕业务概念而非技术）

• 根据业务能力进行服务拆分

• 根据子域进行服务拆分

• 根据动静态调用关系进行服务拆分

3. 定义服务API和协作方式

• 将标识的系统操作分配给服务

• 独立或与其他服务协作（涉及通信方式）实现操作

微服务拆分设计|根据子域拆分

子域：领域驱动设计方法论的核心

• 领域驱动设计（DDD）

• 解决复杂软件业务领域范围/业务边界划分的问题

• 业务出发，以面向对象和领域模型为核心

• 领域

• 描述问题域，一种特定的范围，电商、外卖、保险…

• 子域是领域的细分，电商（订单、商品、物流）

• 核心域、通用域、支撑域

• 核心思想和流程

• 将问题域逐级细分，降低理解和实现的复杂度

• 从业务需求中提炼统一语言

• 战略设计：

• 构建领域模型，识别限界上下文，确定领域边界

• 上下文映射建立领域间关系

• 划分（微）服务的逻辑和物理边界

• 战术设计

• 限界上下文内领域建模，指导程序设计、编码和重构

• 通用语言（Ubiquitous Language）

• 定义领域内相关团队的词汇表

• 统一、简单、清晰、准确描述业务规则和业务

• 理解不一致问题，如账户

• 身份和访问管理上下文，身份验证和授权的凭证

• 客户管理上下文，人口统计和联系人属性

• 财务会计上下文，付款和历史交易的特定信息

• 领域模型 (Domain Model)

• 以解决具体问题的方式包含一个领域的知识

• 为每一个子域定义单独的领域模型

• 限界上下文(Bounded Context)

• 领域模型的边界

• 包括实现模型的代码集合

• 对应微服务架构中一个或一组服务

第六个PPT企业架构设计

自己总结：

业务架构设计  ←实现 指导→  IT架构设计

企业

有共同目标的组织集合体

架构

系统的基本组成部分，各组成部分之间及其与环境之间的关系，决定其设计与演进的治理原则

架构范围

可以是完整的企业，也可以是企业的一部分。无论是哪一种，都涉及多个系统或者功能组之间的交叉关系

企业架构

具有共同目标的组织集合体的基本组成部分及其内外部关系与设计、治理原则

企业架构方法论

关于企业架构如何设计、实施、治理的方法体系

架构三词: 结构、关系、原则，做架构就是一个找结构、找关系的过程

4A：业务架构、数据架构、应用架构、技术架构

经过信息化的长期发展，企业的数字能力建设正在从“企业软件”走向“软件企业”，逐渐回归软件建设的本原:企业能力的全面提升。

企业架构的概念与作用小结：

一、企业架构的视角很重要，但往往是企业的软件构建达到一定规模且开始出现一定程度的混乱时候，才会被意识到;

二、企业架构处理的通常是规模上升带来的复杂度，它的适用条件与企业规模有一定联系，但也不完全取决于企业规模，而是取决于业务复杂度导致的系统复杂度

➢ 业务架构：定义业务战略、治理、组织和关键业务流程

➢ 数据架构：描述组织的逻辑和物理数据资产以及数据管理资源的结构

➢ 应用架构: 为将要部署的单个应用程序、它们的交互以及它们与组织的核心业务流程的关系提供蓝图

➢ 技术架构：描述支持业务、数据和应用程序服务部署所需的逻辑软硬件能力，包括IT基础设施、中间件、网络、通信、处理、标准等。

企业架构的经典方法小结：

一、企业架构方法论的实践有两个关键点：组织方法和设计方法；

二、企业中的实践通常不会是很纯粹的某种方法，而是以完成为首要目标的混合手段；

三、目前最难解决的效率问题其实仍然是需求的澄清；

四、套路对人的成长很重要，要不断学会总结套路

业务模型是由流程模型、产品模型、数据模型组成，并且作为扩展，定义了以提高生产效率和避免操作性错误为核心目的的用户体验模型。

流程模型:展现了业务执行的步骤，模型由外部客户事件触发或者内部触发器发起，包括了角色和职责、政策、业务规则及授权信息等等内容。

产品模型:展现了分类的可售产品，并关联于客户与渠道。另外模型为了能实现产品创新和对市场的快速响应，结构化地定义了基础产品、产品组件和产品条件。

数据模型:展现了结构化和标准化的业务信息，流程中涉及到的所有基础信息都包括在了模型中。

用户体验模型:展现了用户体验（界面）框架和需求，其目的是提高生产力、避免操作层面错误。

第七个PPT 解构领域驱动设计

领域驱动设计的立意是建立以领域为驱动力的过程体系，在这一核心驱动力的设计思想指导下，并没有死板僵化的构建过程来约束你。

全局分析

01.探索业务流程 02.识别业务服务 03.划分子领域 04.定义业务架构

架构映射

05.确定系统上下文 06.提炼限界上下文 07.绘制服务序列图 08.映射应用架构

领域建模

09.细化业务服务 10.抽象分析模型 11.精炼设计模型 12.构建实现模型

01:

IT应用的核心价值在于响应用户的服务请求，应用内部以及应用之间通过一系列的协作各自履行不同的业务职责，共同满足该服务请求对应的各阶段业务目标，从而为用户提供业务价值。这一协作的过程可以称为业务流程（business flow）。

02:

业务服务是业务的参与者（actor）主动向目标系统（后端）发起服务请求，完成一次连续而完整的功能交互，并体现服务价值的业务行为。

限界上下文的定义

封装了领域知识的领域对象在知识语境的界定下，扮演不同的角色，执行不同的活动，共同对外公开内聚的业务能力。

限界上下文的特征

顺变化方向而分，以知识语境为界。限界上下文体现了业务能力的纵向切分，限界上下文体现了领域模型的知识语境。

业务模块和限界上下文的对比

业务模块

模块首先按照技术维度对整个架构进行水平分层，业务模块只是业务层的一部分，不能提供完整的业务能力。当业务需求发生变化时，架构的每一层都可能会受到影响。

限界上下文

限界上下文首先按照领域维度对整个架构进行纵向切分，然后再按照技术关注点进行水平分层，并形成知识语境的边界，使得限界上下文在保证概念完整性的同时,能够提供完整的业务能力。

---

为了保障限界上下文的自治性，限界上下文的内部架构应采用菱形对称架构。菱形对称架构由内部的领域层与外部的网关层构成:

内外分离:内部领域层的领域逻辑与外部网关层的技术实现分开

南北对称:南向网关体现了抽象的设计原则，负责隔离内部领域层对外部资源的访问，北向网关体现了封装的设计原则，封装了内部的领域逻辑，定义远程服务、本地服务与消息契约，形成对外公开的服务契约

---

上下文映射

上下文映射的目的是让软件模型、团队组织和通信集成之间的协作关系能够清晰呈现，为整个系统的各个领域特性团队提供一个清晰的视图。

上下文映射将提供服务的限界上下文称为上游(upstream)，与之对应，消费服务的限界上下文则称为下游(downstream)。上下游关系既表达了影响作用力的方向，也代表了知识的传递方向。

实体与值对象

实体不是通过它们的属性而是连续性和标识定义的。这意味着要匹配一个实体的实例，并不要求属性是否匹配，只需要求概念性标识（identity）是否匹配。

跟踪实体的标识非常重要，但为其他对象也加上标识会影响系统性能并增加分析工作，而且会使模型变得混乱，因为所有对象看起来都是相同的。

现实世界的一个概念，究竟是实体，还是值对象，需要根据它所处的限界上下文（或业务场景）来确定“它”究竟需不需要概念性标识。

---

实体与值对象的特征

相等性

判断相等性是否按照值相等，若以值作为判断依据，则定义为值对象;否则需要定义唯一标识，作为实体.

不变性

若值发生变化，则需要生成不同对象，则定义为值对象;若仍然保持为相同对象，则需要唯一标识对其状态变化进行跟踪应定义为实体.

独立性

值对象不能独立管理生命周期，如果需要独立存在，需定义为实体。

优先级

若无特别理由，需优先定义为值对象

---

聚合是领域模型的概念边界

聚合是领域模型的概念边界。封装在聚合边界内的领域模型包括实体和值。它们组成一棵树，每棵树只能由一个根，且必须为实体，可称为根实体。

在聚合的内部，实体与值对象的协作完全遵循面向对象的行为协作模式，避免设计为贫血模型。根实体作为聚合的唯一出口与入口，通过它与外界协作。