精华内容
下载资源
问答
  • 数据架构设计
    千次阅读
    2021-12-10 11:57:53

    目录

    4.1引言

    4.1.1业务驱动因素

    4.1.2数据架构成果和实施

    4.1.3基本概念

    4.2活动

    4.2.1建立企业数据架构

    4.2.2整合其他企业架构

    4.3工具

    4.3.1数据建模工具

    4.3.2资产管理软件

    4.3.3图形设计应用

    4.4方法

    4.4.1生命周期预测

    4.4.2图标使用规范

    4.5实施指南

    4.5.1就绪评估和风险评估

    4.5.2组织和文化

    4.6数据架构治理

    4.6.1数据架构治理活动

    4.6.2度量指标

    声明:未经许可,严禁抄袭。


    4.1引言

    架构是构建一个系统(如可居住性建筑)的艺术和科学,以及在此过程中形成的成果-系统本身。

    通俗讲,架构是对组件要素有组织的设计,旨在优化整个结构或系统的功能、性能、可行性、成本和用户体验。

    国际标准中,将架构定义为“系统的基本机构,体现在架构构成中的组件、组件之间的相互关系以及管理其设计和演变的原则。”

    架构设计工作在信息系统的不同层级(企业架构包括:基础架构、应用架构、业务架构、数据架构等)来开展。

    架构师就是通过自身专业技能,将难以理解或迷惑的内容定义和设计清晰,以便浅显易懂,这是架构师的价值之所在

    数据架构主要目标①有效地管理数据,以及有效地管理存储和使用数据的系统。

    本章主要从以下3个方面考虑数据架构(基本组成部分):

    1. 数据架构成果——不同层级的模型、定义、数据流,这些被称为架构的构件;
    2. 数据架构活动——用于形成、部署和实现数据架构的目标;
    3. 数据架构行为——包括影响企业架构不同角色的协作、思维方式和技能;

    为什么需要数据架构:数据架构是数据管理的基础。大多数组织的数据超出了个人可理解的范围,因此有必要爱不同抽象层级上描述组织的数据,以便更好地了解数据,帮助管理层做出决策。

    数据架构的作用:良好的企业架构管理有助于组织了解系统的当前状态,加速向期待状态的转变。实现遵守规范,提高效率的目标。

    数据架构的构件包括当前状态的描述、数据需求的定义、数据整合的指引、数据管控策略中要求的数据资产管理范围。

    组织中的数据架构是指不同抽象层级主要设计文档的集合,主要包括数据的收集、存储、规划、使用和删除等标准。

    详细的数据架构设计文件是正式的企业数据模型,它包含数据名称、数据属性和元数据定义、概念和逻辑实体、关系以及业务规则。物理数据模型也属于数据架构文件,但物理数据模型是数据建模和设计的产物,而不是数据架构的产物

    数据架构能完全支持整个企业的需求,它才是最有价值的。

    架构师设计的数据架构构件是非常有价值的元数据的重要组成部分。数据架构构件应该在企业级元知识库中被集中存储和管理。

    4.1.1业务驱动因素

    数据架构主要目标②在业务战略和技术实现之间建立起一座通畅的桥梁。

    数据架构在企业架构中主要职责是:

    1. 利用新兴技术带来的优势,从战略上帮助组织快速改变产品、服务和数据
    2. 将业务需求转换为数据和应用需求,为业务流程处理提供有效数据
    3. 管理复杂数据和信息,并传递至整个企业
    4. 确保业务和IT技术保持一致
    5. 为企业改革、转型和提高适应性提供支撑

    以上业务驱动职责是评判数据架构任务完成情况或价值的重要指标,这些指标直接影响数据架构工作的好坏评估。

    4.1.2数据架构成果和实施

    主要成果包括(P71——图4-1):

    1. 数据存储和处理需求
    2. 涉及满足企业当前和长期数据需求的结构和规划
    3. 战略性地为组织做好准备,快速发展其产品、服务和数据,以利用新兴技术中固有的商机

    架构师寻求一种能为组织带来价值的方式对组织的数据架构进行设计。这种价值主要通过合适的技术应用、有效运营、项目效率提升以及数据应用能力加强来体现。

    为了实现该目标,组织要求具有良好的设计和计划以及确保设计和计划能够被执行的能力。

    为了达到该目的,架构师需要定义和维护的具体事宜如下:

    1. 定义组织中的数据当前状态
    2. 提供数据和组件的标准业务词汇
    3. 确保数据架构和企业战略以及业务架构保持一致
    4. 描述组织数据战略需求
    5. 高阶数据整合概要设计
    6. 整合业务数据架构蓝图

    总体实施包括:

    1. 使用数据架构构件(主蓝图)来定义数据需求、指导数据整合、管控数据资产、确保数据项目投入与企业战略保持一致
    2. 与参与改进业务或IT系统开发的利益相关方合作,学习并影响他们
    3. 通过数据架构及通用的数据词汇,搭建业务数据语言

    4.1.3基本概念

    1.企业架构类型(P72——表4-1)

    企业业务架构

            目的:识别企业如何为消费者和其他利益相关方创造价值

            元素:业务模型、流程、功能、服务、事件、策略、词汇

            依赖项:制定其他架构的需求

            角色:业务架构师和分析师、业务数据管理员

    企业数据架构:

            目的:描述数据应该如何组织和管理

            元素:数据模型、数据定义、数据映射规范、数据流、结构化数据应用编程接口

            依赖项:管理业务架构创建和需要的数据

            角色:数据架构师、建模师、数据管理员

    企业应用架构:

            目的:描述企业应用的结构和功能

            元素:业务系统、软件包、数据库

            依赖项:依赖业务需求来处理指定的数据

            角色:应用架构师

    企业技术架构:

            目的:描述能使系统发挥功能和传递价值的实体技术

            元素:技术平台、网络、安全、整合工具

            依赖项:承载并执行应用架构

            角色:基础设施架构师

    2.企业架构框架(P73——图4-2)

    主要讲述了Zahman的6*6矩阵模型,可以完整的描述一个企业以及相互之间的关系。

    矩阵框架的两个维度是:问询沟通重新定义转换

    列中显示的是问询沟通(可以寻问任何实体的基本问题,将其转换成企业架构对应每个列的理解):

    1. 是什么——目录列,表示构建架构的实体
    2. 怎么做——流程列,表示执行的活动
    3. 在哪里——分布列,表示业务位置和技术位置
    4. 是谁——职责列,表示角色和组织
    5. 什么时间——时间列,表示角色和组织
    6. 为什么——动机列,表示目标、策略和手段

    每个对应列下行中的值显示其重新定义转换(是将抽象概念转变为具体的实例的必经步骤,如识别、定义、描述、规范、配置和实例[注:每一列中都对应自己的这些步骤,识别→实例])。

    矩阵中的每一行代表不同的角色,包括规划者、所有者、设计师、建造者、实施者和用户。

    每个角色对不同问题解决持有不同的视角。例如每个视角与“什么”列交叉。

    具体如下:

    1. 高管视角(业务背景)——定义不同模型范围的业务元素目录
    2. 业务管理视角(业务概念)——不同业务模型涉及的不同的业务概念间的关系
    3. 架构师视角(业务逻辑)——作为模型设计的架构师细化系统需求,设计系统逻辑模型
    4. 工程师视角(业务实体)——具体的模型建造者,优化和实施具体应用设计的物理模型
    5. 技术人员视角(组件程序集)——采用特定技术、脱离上下文语境的视角,并解释配置模型的技术人员如何使用、组装和实施配件组件
    6. 用户视角(操作类)——参与人员所使用的实际功能实例

    3.企业数据架构

    数据架构定义了对组织非常难重要元素的标准术语和设计。设计中包括业务数据描述,如数据的收集、存储、整合、移动和分布。

    当数据在组织中通过源或接口流动时,需要安全、集成、存储、记录、分类、共享的报表和分析,最终交付给利益相关方使用。在这个过程中数据可能被验证、增强、链接、认证、整合、脱敏处理及用于分析,直到数据被归档或清除。

    因此企业数据架构必须包括企业数据模型数据流设计

    1.企业数据模型是一个整体的、企业级的、独立实施的概念或逻辑数据模型,为企业提供通用的、一致的数据视图。

    企业数据模型包括数据实体(如业务概念)、数据实体间关系、关键业务规则和一些关键属性,它为所有数据和数据相关项目奠定了基础。

    2.数据流设计,定义数据库、应用、平台和网络(组件)之间的需求和主蓝图。数据流展示了数据在业务流程、不同存储位置、业务角色和技术组件间的移动。

    (1)企业数据模型

    企业数据模型包括通用的(企业范围的概念和逻辑模型)和特定于应用或具体项目的数据模型及其定义、规范、映射和业务规则。

    P75——图4-3显示了不同模型是如何关联的,以及概念模型如何最终与物理应用数据模型关联,其明显特征为:

    1. 企业主题域的概念概述
    2. 各主题域的实体和关系概述
    3. 归属与同一主题域的详细逻辑概述
    4. 具体到应用或项目的逻辑和物理模型

    各层级的模型是企业数据模型的组成部分。模型链接定义和管理了模型的纵向从上到下以及横向间的关联路径。

    纵向:不同层级模型间的映射

    横向:同一个实体和关系可能出现在同一层级的多个模型中(用于关联关系的,主外键)

    企业数据模型是由主题域模型相结合构建的。构建方法为自上而下,或自下而上:

    自上而下是从主题域开始的:概念模型→主题域模型→逻辑模型→逻辑数据模型——物理数据模型

    自下而上是现有逻辑数据模型向上提炼抽象而成。

    通常推荐2种方法相结合共同完成企业数据模型的设计工作。

    主题域识别的准则必须在整个企业模型中保持一致。通常常用准则包括:

    使用规范化,从系统组合中分离主题域,基于顶级流程(业务价值链)或基于业务能力(企业架构)从数据治理结构和数据所有权(或组织)中形成主题领域。

    (2)数据流设计

    数据流是一种记录数据血缘的数据加工过程。

    数据流映射记录了数据与以下内容的联系:

    1. 业务流程的应用
    2. 某个环境中的数据存储或数据库
    3. 网段
    4. 业务角色(描述哪些角色有职责创建、更新和删除数据)
    5. 出现局部差异的位置

    数据流用于描述主题域、业务实体,乃至属性层面的映射关系。

    数据流呈现方式有:
    1.二维矩阵(P78-图4-5)(横向是业务流程和纵向是主要实体)——通过矩阵图形能清晰地展现创建和使用数据的过程。

    采用矩阵的优势是可以清楚看出数据不是只在一个方向上流动的。通过矩阵可以明确流程中的数据获取职责及数据依赖关系,反过来可以促进流程的制定。

    2.数据流图

    4.2活动

    简化数据和企业架构所面临的复杂问题,解决方式:

    1.面向质量。专注与业务和IT开发周期内对数据架构进行不断改进。如果架构没有得到妥善管理,也会慢慢遭到损坏,逐渐变得越复杂和缺乏扩展性,从而给组织带来风险。对数据整合、数据复制以及“意大利面式”接口关系无法控制,使组织效率越来越低,降低数据真实性。

    2.面向创新。专注与业务和IT转换,致力于新的期待和机会。用创新性技术和数据使用驱动创新,成为现代企业架构的一种功能。

    运用这2种方法有不同的方法论;

    面向质量的方法与传统的数据架构工作保持一致,其中架构质量改进是逐步完成的。架构师需要掌握整体架构、将治理、标准化、架构发展作为长期目标进行持续投入。

    面向创新的方法通常不用面面俱到,可以应用未经广泛验证的业务逻辑和前沿技术。需要架构师与产品经理和业务设计者进行联系。

    4.2.1建立企业数据架构

    数据架构应该是企业架构的组成部分。如果没有企业架构,也可以构建数据架构团队,组织应该设计有助于明确目标和驱动数据架构的框架。该框架对数据架构实施路线图中的方法、范围和工作优先级产生影响。

    建立企业数据架构通常架构师包括以下工作(可串行或并行执行):

    1. 战略——选择框架,制定方法,开发路线图
    2. 沟通与文化——建立沟通机制,并激励积极参与者
    3. 组织——通过明确责任和职责来组织数据框架工作
    4. 工作方法——与企业架构保持一致,在开发项目中定义最佳实践并执行数据架构工作
    5. 结果——在总体路线图中产出数据架构产品

    企业数据架构也会影响项目和系统开发的范围边界,如:

    1. 定义项目数据需求——通过数据架构为企业提供每个项目数据需求
    2. 评审项目数据设计——通过评审来确保概念、逻辑和物理数据模型与架构一致,与企业长期战略一致
    3. 确定数据溯源影响——确保数据流在应用中的业务规则一致且可溯源
    4. 数据复制控制——复制,能够改善应用和便于获取数据的方法。数据架构治理能保证充分的复制控制(方法和机制)来达到所需的一致性
    5. 实施数据架构标准——为企业数据架构生命周期制定和实施标准。标准可以表示为原则、流程、指南和规划蓝图
    6. 指导数据技术和更新决策——数据架构与企业架构管理每个应用的数据技术版本、补丁和技术路线策略

    1.现有数据架构规范评估

    为了解现有架构,需要识别现有系统的一系列文件,并评估其准确性、完整性和详细程度。如需必要,还需要更新这些文件使其真实反应系统当前状态。

    2.开发路线图

    如果一个企业是从零开始开发的,那么一个最佳的体系结构将仅仅基于运行该企业所需的数据,优先级将有业务战略确定,决策可以不受过去的阻碍。

    企业架构路线图提供了一种管理这些依赖性(数据依赖关系)并做出前瞻性决策的方法。路线图包括(高层次里程碑事件、所需资源、成本评估、业务能力工作流划分)

    企业数据架构路线图描述了架构3-5年的发展路径,路线图和业务需求共同将目标架构变为现实。业务数据驱动路线图(P81——图4-7)可以从最独立的业务能力开始,再处理相互依赖程度较高的业务能力。按照顺序处理每个业务能力,遵循整体业务数据生成顺序。

    在理想中,建议从图中产品管理和客户管理能力开始路线图,然后从上到下解决每一步依赖关系。

    3.在项目中管理企业需求

    架构不应该受开发时间的限制。利用数据模型及其有关规范描述的组织数据架构必须足够灵活,并能适应未来需求。构建架构层级的数据模型不仅应有企业全局观,而且要有足够让企业内部完全清楚理解的定义。

    对获取、存储、分发数据的开发项目实施解决方案,需要以业务需求和企业数据架构的标准为基础。

    在项目级别上,通过数据模型定义需求的过程是从审查业务需求开始的。通常这些需求是特定于项目目标的,不会对企业产生影响。

    重要的是,数据架构师必须能够理解需求与其他整体架构的关系,当项目范围完成时,架构师应该决定:

    1. 规范中所描述实体是否符合标准
    2. 在需求中,哪些实体应该被包括在整体企业数据架构中
    3. 规范中的实体和定义是否需要扩大或加深以满足将来的趋势
    4. 是否更新数据架构或是否向开发指出了哪些可以重用

    企业数据架构项目项相关活动包括:

    1. 定义范围。保证范围和接口与企业数据模型一致。理解项目对整体企业数据架构的潜在贡献、项目的建模和设计、哪些现有组件应该或能被重用。
    2. 理解业务需求。获取数据相关需求,如实体、资源、可用性、质量和痛点,自己评估满足这些需求的业务价值
    3. 设计。形成详细的目标规范。包括:数据生命周期内的业务规则、验证结果的有效性、需要提供的时间、提升模型的扩展性和改进标准模型等
    4. 实施分为

            ①什么时候购买考虑购买支持逆向工程的软件、逆向数据库中的数据模型(如果可以,让供应商提供其数据模型)

            ②什么时候重用数据。建立应用数据模型与通用数据结构、现有流程和新流程之间的对比映射关系,来理解CRUD操作。

            ③什么时候构建。根据数据结构进行数据存储;根据标准或设计并评审通过的规范进行集成

    项目在企业数据架构角色依赖软件开发过程,采用的方式有3种:

    1. 瀑布式——作为整个企业设计的一部分,在连续阶段中理解需求和构建系统。但需确保能够从企业视角设计架构和考虑问题,以避免局限性
    2. 迭代方式——适合总体需求模糊的原型。这种方式在启动阶段至关重要,最好早期迭代中创建一个全面的数据设计
    3. 敏捷方式——敏捷模型能够提供高目标导向的模型,强调用户界面设计、软件设计和系统行为

    4.2.2整合其他企业架构

    事实上,数据架构可能会影响项目的范围,因此,最好把企业数据架构问题和项目组合管理进行整合 。

    企业数据架构师的工作应被包含在企业应用开发和整合计划中,同时将数据架构视图应用于目标应用场景以及该场景的路线图中。

    4.3工具

    4.3.1数据建模工具

    在管理所有层级数据模型的过程中,数据模型工具和模型库都是非常必需的。

    4.3.2资产管理软件

    资产管理软件用于管理数据资产目录,描述其内容以及跟踪它们之间的关系。

    由于通过数据资产管理软件盘点了IT资产,所以包含了关于系统及相关数据的元数据。在创建数据流或研究当前状态时,这些元数据非常有用。

    4.3.3图形设计应用

    可以用于创建架构设计图形、数据流、数据价值链和其他架构构件。

    4.4方法

    4.4.1生命周期预测

    架构设计可以是针对当前的、面向未来的、实施完成的及将要退役的产品。

    无论哪种情况,其工作成果都应该存档管理。

    1. 当前的——当前支持和使用的产品
    2. 部署周期的——未来1-2年部署使用的产品
    3. 策略周期的——未来2年后使用的产品
    4. 退役的——一年内,已经停用或打算停止的产品
    5. 优先的——被多数应用优先使用的产品
    6. 限制的——在一定应用中限制使用的产品
    7. 新兴的——将来可能部署研究和试行的产品
    8. 审核的——以评估的产品,评估结果不能用于以上的产品

    4.4.2图标使用规范

    使用图标来实现视觉转换,以达到提高可读性和便于理解的目的。

    具体使用规范如下:

    1. 清晰一致的说明
    2. 所有图表对象与说明相匹配
    3. 清晰一致的线条方向
    4. 一致的交叉线显示方法,交叉并非连接点
    5. 一致的对象属性,如大小、粗细、颜色等
    6. 线性对称

    4.5实施指南

    实施企业数据架构主要包含内容:

    1. 建立企业数据架构团队和举办问题讨论会
    2. 生成数据架构构件的初始版本,如企业数据模型、企业范围数据流和路线图
    3. 在开发项目中,形成和建立数据架构工作方式
    4. 提高组织对数据架构工作价值的认识

    实施可以从部分组织中开始,或从某些数据域中开始,如产品数据或消费者数据。认知和工作方式成熟后,可以逐步扩大实施范围。

    通常,从非常需要改进的主数据域开始建立企业数据架构,一旦被接受,发展到包括面向业务事件的数据中。

    4.5.1就绪评估和风险评估

    最明显的风险有:

    1. 缺少管理层支持
    2. 成功与否缺乏证据
    3. 缺乏管理者的信任
    4. 管理层不正确的决策
    5. 文化冲击
    6. 缺乏有经验的项目经理
    7. 单一维度视角

    4.5.2组织和文化

    组织架构实施的速度依赖于适应文化的程度

    以产出为导向,战略一致的组织能更好地适应架构实施。

    一个组织接受并实施数据架构的能力依赖于以下几个方面:

    1. 对架构方法的接受度(开发架构的友好性)
    2. 确认数据属于组织的业务资产,而不仅仅是IT的任务
    3. 放弃局部数据视角,接受企业级数据视角的能力
    4. 将架构交付成果整合到项目实施中的能力
    5. 规范数据治理的接受程度
    6. 立足企业全局

    4.6数据架构治理

    数据架构活动能直接支持数据模型不同层级的映射管理及控制数据。

    理想情况下,数据架构师和数据管理员对每个主题域,甚至每个主题域的实体都保持一致。而且,数据监督应该与流程监督保持一致。业务事件主题域应该与流程监督保持一致。每个实体通常与业务流程相对应。

    4.6.1数据架构治理活动

    1.项目监督,确保符合项目所需的数据架构活动、使用和提高架构资产

    2.管理架构设计、生命周期和工具。必须对架构设计进行定义、评估和维护

    3.定义标准,制定数据在组织内如何使用的规则、指南和规范

    4.创建数据相关构件,支持治理规范的构件

    4.6.2度量指标

    数据架构的衡量指标反映了架构目标:架构接受度、实施趋势、业务价值

    1.架构标准接受率

            可以测量项目与已建立的数据架构的紧密程度及项目与企业架构参与流程的遵循度,

    2.实施趋势,对跟踪架构改善组织实施项目能力的程度,分为:

            1.使用/重用/代替/废弃测量。决定使用新架构构件与重用、代替或废弃构件的比例。

            2.项目执行效率测量。测量交付时间和可重用构件及指导构件的交付改进成本。

    3.业务价值度量指标

    追踪向期待的业务效果和利益方向的发展过程:

            1.业务敏捷性改进,解释生命周期改进或改变的好处,改进延误成本的测量方法

            2.业务质量,测量业务案例是否按期完成

            3.业务操作质量,测量改进效率的方法

            4.业务环境改进,由数据错误减少而改变客户的保留率和在递交中当局评论的减少率

    声明:未经许可,严禁抄袭。

    更多相关内容
  • 那么该如何设计元数据管理的架构,才能最大...本次公开课将重点为大家讲解元数据架构设计的相关内容。第一部分:如何理解元数据这个比较抽象的概念?1、 如何理解元数据?2、 传统元数据与广义元数据之间有什么关系?
  • 微服务架构设计实践 目 次1 序言2 微服务3 软件架构设计思想4 微服务架构设计实践4.1 项目概述4.2 架构准备阶段4.3 概念架构阶段4.4 细化架构阶段4.4.1 业务架构4.4.2 数据架构4.4.3 应用架构4.4.4 技术架构4.4.5 ...

    微服务架构设计实践
     


    目    次

    4.4.2  数据架构

    4.4.2.1  数据架构定义

            数据架构定义了用来支持业务的各种数据,以及他们之间的关系。

            数据架构着重考虑“数据需求”,关注点是持久化数据的组织。

            在数据架构设计过程中,主要涉及三部分内容:数据定义、数据分布与数据管理:

            1.数据定义,是数据架构规划中最重要内容。定义良好的数据模型,包括数据概念模型、数据逻辑模型、数据物理模型,以及更细化的数据标准,可以反映业务模式的本质,确保数据架构为业务需求提供全面、一致、完整的高质量数据,且为划分应用系统边界,明确数据引用关系,定义应用系统间的集成接口,提供分析依据。良好的数据模型与数据标准的制定才是实现数据共享、保证一致性、完整性与准确性的基础。有了这一基础,企事业单位才能通过信息系统应用逐步深入,最终实现基于数据的管理决策。

            2.数据分布,一方面是分析数据的业务,即分析数据在业务各环节的创建、引用、修改或删除的关系;另一方面是分析数据在单一应用系统中的数据结构与应用系统各功能模块间的引用关系,分析数据在多个系统间的引用关系。数据业务分布是数据系统分布的基础。对于一个拥有众多分支机构的大型企事业,数据存储模式也是数据分布中一项重要内容。从地域的角度看,数据分布有数据集中存储和数据分布存储两种模式。数据集中存储是指数据集中存放于企事业总部数据中心,其分支机构不放置和维护数据;数据分布式存储是指数据分布存放于企事业总部和分支机构,分支机构需要维护管理本分支机构的数据。这两种数据分布模式各有其优缺点,企事业应综合考虑自身需求,确定自己的数据分布策略。

            3.数据管理,一方面要制定贯穿企事业数据生命周期的各项管理制度,包括:数据模型与数据标准管理,数据分布管理,数据质量管理,数据安全管理等制度;另一方面应该确定数据管理组织或岗位。

            数据架构规划是进行企事业IT架构规划不能绕开的重要环节,对于完全通过定制化开发进行应用系统实施的企事业单位来说,数据架构设计是完全可以指导应用系统开发的。

            数据架构规划的目的有三个:

            1.分析业务运作模式的本质,为未来核心应用系统的确定以及分析不同应用系统间的集成关系提供依据。

            2.通过分析核心数据与业务之间的应用关系,分析规划应用系统间的集成关系。

            3.数据管理的需要,明确企事业的核心业务数据,这些数据是应用系统实施与运行时IT系统实施人员或管理人员应该重点关注的,要时时考虑保证这些数据在整个企事业层面的一致性、完整性与准确性。

    4.4.2.2  数据架构设计原则

            在数据架构设计过程中,应该考虑如下因素:

             
    4.4.2.3  数据架构实践

    4.4.2.3.1  数据定义

            一、 概念数据模型

            根据业务需求,分析业务过程中涉及到的所有业务实体,抽取出满足用户场景的实体对象,以及它们之间的关联关系。

            在概念建模阶段,主要做三件事:

            1.客户交流。

            2.理解需求。

            3.形成实体。

            这是一个迭代,如果先有需求,尽量去理解需求,明白当前项目需要完成什么,不明白或者不确定的地方和客户及时交流,和客户二次确认过的需求,落实到实体。如果没有,则通过先和客户交流,进而将交流结果落实到需求,之后进一步具体到实体。

            分行特色业务云平台数据概念模型-基本配置管理部分如下:

            

     

            1.系统管理类

            该部分主要包括系统管理类对象。由于采用基于角色的权限管理,所以涉及的对象主要有用户、角色、功能。

            2.基础数据类

            该部分主要是各种参数配置对象和流水的统一基础数据属性信息,包括:服务场景类型,业务领域,业务区域,机构信息等,后续可根据服务类型的扩展增加相应基础数据对象。

            其中,服务场景类型,业务领域和业务区域后续在控制及事后监控中控制风险使用,例如:通过定义不同的服务场景,来形成各服务场景调用内联服务的风险级别,配置不同的风险控制策略,并且在监控时进行区分关注。

            3.特色应用类:

            该部分主要包括特色业务应用组织、特色业务应用,特色业务产品信息、特色业务合作方信息以及使用业务服务的应用服务场景信息。这些对象用来管理各分行实现的特色业务应用,应用上实现的业务产品以及该业务产品归属的合作方信息,并且通过配置这些应用使用服务融合中心上业务服务的场景(服务场景)来差异化的控制调用服务时的数据属性以及业务风险。

            4.业务服务类:

            业务服务:管理服务融合中心对外发布的业务服务信息。

            业务服务原子服务映射规则:对业务服务与平台内部原子服务调用关系进行管理授权。

            5.原子服务类:

            原子服务:管理由服务融合中心封装的原子服务信息,这些原子服务不直接对外调用,供流程服务调用。原子服务可实现本地的原子服务功能以及后台模块的原子服务功能,针对于后台服务的原子服务一对一的进行封装。

            模块信息:管理服务融合中心原子服务的归属模块,对于服务融合中心封装的远程原子服务,在该表中注册远程服务的归属模块(如PE,NPS),对于本地封装的原子服务,在该表中注册本地模块。

            6.通用功能类:

            通用扩展属性:用来存储各个对象(如业务服务,服务场景等)扩展属性,通过对象类型+对象编码+控制规则主键匹配一组规则。

            对象营业时间:用来存储各对象的营业时间属性。如(特色业务应用、特色业务、特色业务合作方、服务场景、业务服务、原子服务)。

        分行特色业务云平台数据概念模型-流水部分如下:

        

     

            流水表主要分成基础类流水表和业务类流水表。

            1.基础类流水表:

                 接入流水表主要负责当外模块调用服务中心业务服务时,统一记录服务流水。

                 接出流水表主要负责当服务中心业务服务调用外部模块时,登记接出流水,记录与外部模块的交互情况。

            2.业务类流水:

                 目前主要先使用账务流水表,登记账务类流水的信息,后续可根据实际业务类型,扩展不同的业务流水表。

            上述概念数据模型定义了特色业务云平台核心部分的实体对象及它们之间的关系。后续随着功能的完善,业务的增加,需要继续完善概念数据模型。 

            二、 逻辑数据模型

            概念数据模型完成以后,需要进一步对实体对象进行细化,细化成具体的表,同时丰富表结构。

            根据需求确定具体需要哪些表,以及每张表的属性。此时会涉及主键的选取,外键的关联,约束的设置等细节。笔者认为只要能把每个实体属性落实下来就是很不错了,因为随着项目的开展,很多表的列都会有相应的改动。

            这个阶段的产物是,可以在数据库中生成的具体表及其他数据库对象,包括主键,外键,属性列,索引,约束甚至是视图以及存储过程。

            以下为服务融合中心部分逻辑数据模型,以供参考。

            1.系统管理部分逻辑数据模型:

            

             2.基本配置部分逻辑数据模型:

                 服务配置部分: 

                

                 业务产品配置部分: 

                

                 其它配置部分:

                

             3.流水部分逻辑数据模型:

     

             三、 物理数据模型

            物理建模可以将在逻辑建模阶段创建的各种数据库对象生成为相应的SQL代码,运行来创建相应具体数据库对象。

            这个阶段我们不仅仅创建数据库对象,针对业务需求,我们也可能做如数据拆分(水平或垂直拆分)、读写分离。

            根据所选数据库管理系统的类型,生成相关的SQL语句,然后创建具体的数据库对象。

            例如:业务区域表在MySQL数据库的创建语句:

            CREATE TABLE `t_busi_area_info` (

              `busi_area` VARCHAR(10) COLLATE utf8_bin NOT NULL COMMENT '区域编码',
              `area_name` VARCHAR(60) COLLATE utf8_bin NOT NULL COMMENT '业务领域名称',
              `area_level` CHAR(1) COLLATE utf8_bin NOT NULL COMMENT '区域层级',
              `parent_area` CHAR(6) COLLATE utf8_bin NOT NULL COMMENT '上级区域编码',
              `branch_no` CHAR(4) COLLATE utf8_bin DEFAULT NULL COMMENT '分行机构号',
              `status` CHAR(1) COLLATE utf8_bin NOT NULL DEFAULT '1' COMMENT '状态',
              `memo` VARCHAR(255) COLLATE utf8_bin DEFAULT NULL COMMENT '备注',
              `dac` CHAR(16) COLLATE utf8_bin DEFAULT NULL COMMENT 'dac校验',
              PRIMARY KEY (`busi_area`),
              KEY `t_busi_area_info_IDX0` (`area_name`)
        ) ENGINE=INNODB DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='业务区域表';

            四、 数据字典

            在数据建模过程中,基于对需求的理解,会抽取出部分业务规则,这些信息将会成为数据字典中非常重要的部分,即元数据。

            以下是数据字典的部分内容,以作参考:

            1.服务功能类型

            以服务的业务功能领域来定义数据规则,目的是为了统一规范服务的业务领域编码规范,后续可通过该编码对相同功能的服务进行统一管理、统计。

            两位编码表示一个类型含义,最多能表示15个层次的类型含义。

            功能类型按照从粗到细的原则进行编排,下级功能领域含义需要与上级功能领域含义一致。

            一级功能领域目前定义如下:

            

            各一级功能领域内的二级功能领域编码定义如下:

            


            2.业务领域

         

        

            

    4.4.2.3.2  数据存储

            一、 数据库管理系统

            在总行,数据库管理系统采用DB2,版本建议为10.5及以上。

            在总行,由于数据库管理系统采用DB2,所以数据库高可用性通过DB2 数据库产品所提供的多种高可用性策略的功能来实现,具体如下:

                1. DB2 高可用性功能部件-HA:支持IBM DB2服务器和集群管理软件相集成。

                2. DB2 数据服务器高可用性灾难恢复功能-HADR:一种数据库复制功能,它提供针对部分站点故障和整个站点故障的高可用性解决方案。HADR 通过将数据更改从源数据库(称为主数据库)复制到目标数据库(称为备用数据库)来防止数据丢失。

                3. DB2日志镜像:支持数据库级别的日志镜像。

                4. DB2故障监视器工具:该工具通过监视 DB2 数据库管理器实例并重新启动任何过早退出的实例来使 DB2 数据库正常运行。

            在分行,根据每个分行各自的需求,从DB2 10.5及以上、Oracle11g及以上、MySQL5.5及以上三种数据库管理系统中任选其一。 

            在分行,根据所选的数据库管理系统,采用相应的产品和工具实现数据库高可用性。

    4.4.2.3.3  数据分布

            根据系统数据产生、使用、管理等方面的不同特点,采用不同的数据分布式存储和处理手段。

            数据分布策略的3条应用原则:

            1.合适原则:合适的才是最好的。把握系统特点,确定分布策略。

            2.综合原则:当系统比较复杂时,其数据产生、使用、管理等方面可能很难表现出压倒性的特点,此时,就需要考虑综合运用不同的数据分布策略。

            3.优化原则:当难以“一步到位”地作出数据分布策略的正确选择,以及还存在质疑时,应从“对吗”、“好吗”两个方面进行对比、评估、优化。

            由于项目时间紧,人员紧缺,总行科技其它相关项目组进度方面的影响,以及其它一些行方政策上约束,所以在项目第一、二阶段,服务融合中心支持两种应用部署方式:

            一、 集中模式+复制模式+子表模式

            在项目第一、二阶段,主要进行服务融合中心基础开发框架、公共技术组件、公共业务组件的开发、测试。此时,总行服务融合中心提供的服务以对总行核心系统提供的服务进行服务封装为主,业务数据存储在总行核心系统中,不在服务融合中心存储。

            另外,总行服务融合中心接入的分行业务有限,业务访问量较低,每天产生的流水类数据量较少。

            基于上述原因,建议服务融合中心作为单一应用部署,采用集群部署实现水平扩展,支持大并发访问,实现高可用性。

            在数据库方面,同样采用单一库部署,通过读写分离、一写多读、内存缓存的方式保证读操作的性能和高可靠。

            单一应用集群模式如下图所示:

            

     

            在上述部署模式下,数据分布模式如下:

            1.服务融合中心中系统管理类、基本配置类数据,此类数据属于配置型数据,读写比大(即读多,写少),强依赖读,弱依赖写,不要求严格的读一致性,读可靠性要求高。对于这类数据,采用集中式管理。另外,通过读写分离、一写多读、分布式缓存、内存缓存的方式保证读操作的性能和高可靠。

            2.服务融合中心中流水类数据,属于流水型数据,此类数据读写比小(即读少、写多),不断产生新的数据,各条数据间是独立的。单条数据的更新需要保证强一致性。流水型数据很方便做水平扩展。对于流水类数据,由于处于刚投产阶段,接入的分行特色业务数量有限,所以暂时采用集中模式和子集模式。

            3.为每张流水类数据的表建立一个副本表(数据结构与主表一致),这样流水类数据的主表只存储热点数据,即指定维度内的数据(如按照时间维度:1个月以内、1个季度以内等,或按其它业务维度),而其它数据保存在副本表内。这样针对主表、副本表分别进行优化(如:支持大量写操作的主表减少索引,以读为主的副本表可以根据查询需求设置多个索引)。

            二、 集中模式+复制模式+子表模式+独立Schema 模式

            如果在项目第一、二阶段需要实现的本地业务服务较多,接入的分行业务较多,建议把服务融合中心中的流程服务按照业务域分组,每组单独集群部署。

            分布式应用集群部署模式如下图所示:

            

     

            在这种部署模式下,数据分布模式调整为:

            1.把单一数据库拆分为一个通用的基本配置管理库和多个应用业务库(一个应用对应于一个业务库)。

            2.通用基本配置管理库主要包括系统管理类、基本配置类、流水类数据,数据分布模式同单一应用集群模式。

           3.应用业务库主要包括该应用所需的业务相关数据,数据分布模式采用独立Schema模式,即每个应用采用单独数据库Schema的方式管理每个应用涉及的业务数据。

            4.每个应用涉及的业务数据,大部分属于状态型数据,读写比相当,必须保证可写才有意义,每一次写操作必须基于前一个正确的状态。针对关键业务的状态型数据,应尽量把维度拆细,一是提高并发处理能力,二是方便隔离故障影响。

            5.状态型数据要求严格的数据一致性。对于这类数据,除了阿里自主研发的基于 Paxos 协议的分布式强一致数据库(对于单节点故障,它提供 RPO=0,RTO<30 秒的容灾能力,致力于从数据库层屏蔽容灾细节,为应用层提供简单的使用方式)),暂时没有很好的完整解决方案。所以,这部分数据暂时采用单一数据库存储。

            三、 集中模式+复制模式+分区模式

            随着接入的分行特色业务数量的增加,预计每天1亿笔交易量,导致流水相关表的数据量急剧增加。

            在这种海量业务场景下,上述针对流水型数据的子表模式的数据库设计会遇到单表的容量瓶颈和单库的性能瓶颈。

            针对这种情况,按照分布式的思想,对数据进行拆分,让集中在单点的读写访问分布到多个数据库服务器上,从而获得容量和性能上的弹性延伸能力。

            常用的数据拆分模式:

                 垂直拆分:按业务域进行拆分;

                 水平拆分:按某个业务维度进行拆分,如用户、区间等;

                 读写拆分:读写分离;

            为了支持灵活的数据分区,并且数据分区对应用层透明,分行特色业务云平台引入分布式数据访问组件ZDAL支持数据库拆分模式。在引入ZDAL组件以后,针对不同类型的数据采用不同的处理方式。

            1.配置型数据:涉及系统管理类表、基本配置类表

            此类数据的特征是读多写少,数据量较小,采用群组模式。

            群组(Group)模式,示意图如下:

            

     

            采用该模式,一个主库,多个从库,主库负责写、从库负责读,在事务内的读也使用主库。

            2.流水型数据:涉及流水类表

            对于流水类相关表,进行分库分表设计,采用切片模式。

            切片(Shard)模式,示意图如下:

             

            流水类表采用该模式,按照表中流水号ID进行拆分,根据逻辑切片与物理数据库、表的路由规则分布到据库中。

            在本项目中,考虑到项目后期数据扩容方面的简易性、可维护性,建议采用如下数据库与表的拆分路由规则:

                     

            对按流水号ID进行切分的相关表水平切分为1024个逻辑分片,物理库为4个,逻辑分片按照分库分表规则分布在不同物理库中。1024个逻辑分片,逻辑分片与物理表一一对应,每个库256张表,每个表的顺序号都不相同,该模式下分库分表示意图如下:

            

     

            如果扩容物理库到8台,则只需修改分库分表路由映射规则,之前四个库的后128张表分别迁移到新增的物理库中,同时调整逻辑数据库序号。该模式数据迁移相对方便,每次扩容时,每个库的表数量都在减少,扩容上限1024。

            扩容后数据拆分示意图如下:

             

            迁移过程需要一定时间,由于涉及到表数据的迁移和路由规则的切换,所以会影响一段时间数据服务的访问,迁移流程大致如下:

                 停止对外提供服务,然后开始进行数据备份导出;

                 进行表数据的迁移工作;

                 修改ZDAL数据源配置文件,通过配置中心推送ZDAL动态加载;

                 迁移验证,主要包括迁移数据完整性、数据路由是否正确,交易服务是否正常;

                 验证无误后,删除原数据库中已迁移表;

                 对外开始提供服务;

            3.状态型数据

            针对本地服务业务库中的数据,如果某些业务表的数据量达到或超出特定数据库的单表限制,或单表数据量已经影响数据库读、写性能,则建议参考上述流水型数据,进行分库分表设计。

    4.4.2.3.4  数据管理

            在数据管理方面,主要包括两个部分:

            1.制定贯穿整个数据生命周期的各项管理制度,包括:数据模型与数据标准管理,数据分布管理,数据质量管理,数据安全管理等制度。

            2.确定数据管理组织或岗位。


      微信扫一扫,关注该公众号

      该系列文章已经在微信公众号发布,如果感兴趣,请关注。

       以后更多知识通过该微信公众号分享。


    展开全文
  • 微服务开发中的数据架构设计

    千次阅读 2018-03-18 23:08:04
    原文:微服务开发中的数据架构设计 关注微信公众号:「GitChat 技术杂谈」 一本正经的讲技术 【不要错过文末彩蛋】 前言 微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性...

    GitChat 作者:陈伟荣
    原文:微服务开发中的数据架构设计
    关注微信公众号:「GitChat 技术杂谈」 一本正经的讲技术

    【不要错过文末彩蛋】

    前言

    微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和业务持续提供了一个良好的基础平台。本文分享在这种技术架构下的数据架构的设计思想以及设计要点,本文包括下面若干内容。

    • 微服务技术框架中的多层数据架构设计
    • 数据架构设计中的要点
      • 要点1:数据易用性
      • 要点2:主、副数据及数据解耦
      • 要点3:分库分表
      • 要点4:多源数据适配
      • 要点5:多源数据缓存
      • 要点6:数据集市

    为了容易理解,本文用一个简化的销售模型来阐述,如下图。图1显示了客户、卖家、商品、定价、订单的关系(这里省略支付、物流等其他元素)。

    enter image description here

    图1 销售模型

    在这个销售模型中,卖家提供商品、制定价格,客户选择产品购买、形成销售订单。根据微服务的理念设计,可以划分为客户服务、卖家服务、商品服务、定价服务、订单服务,以及公共服务(比如认证、权限、通知等),如图2所示。

    enter image description here

    图2 微服务功能

    微服务架构中的多层数据架构设计

    分布式架构一般把系统分为 Saas(Software-as-a-Service)、Paas(Platform-as-a-Service)、Iaas(Infrastructure as a Service )三层。其中 Saas 层负责对外部提供业务服务,Paas 层提供基础应用平台,Iaas 层提供基础设施。微服务垂直嵌入这三层服务之中,相互独立。因此数据架构设计时需要考虑三层服务对数据的关注点,又要考虑微服务的独立性。

    数据架构的分层设计

    图三 分布式·微服务构架
    图3 微服务技术框架

    如图3所示,Iaas 层提供程序运行的物理基础环境(这边涉及很多硬件·网络内容,在本文中省略)。Pass 层细分为三层,基础服务层,主要负责数据存储处理;事务框架层,主要负责微服务的注册·调度管理、分布式事务处理;应用服务层、主要实现各个微服务的 API,供其它微服务直接调用以及 Saas 层的服务调用。Saas 服务就是公开对外提供的业务服务。

    数据架构自下向上相应的分为 Raw Data 层、Logic Data(inner)层和 Logic Data(outer)层(Iaas 中主要以基础硬件环境为主,在本文中省略)。Raw Data 层是基于数据库、文件或者其他形式数据内容。Logic Data(inner)层是微服务 API 使用的逻辑数据,比如客户数据、订单数据等等。Logic Data(outer)层是对外服务提供数据,比如客户订单数据。因此,我们的数据架构的分层结果如图4所示。

    enter image description here

    图4 数据分层架构

    除此之外,很多情报会以画面或报表的形式展现出来。因此在 Logic Data(outer) 之上,可以构建 Information Block(常用的信息块)、通过 View type(显示模式)的设定后,最终 View 展现出来。

    如图4所示,越靠近对外服务层,客户对设计者的影响度越大,越需要从使用性、易用性、适用性等考虑。反之,越远离对外服务层,设计上更关心数据的存储。

    数据三层架构的好处是实现数据从系统实现到业务实现的逐层过渡,实现业务数据和系统数据间的松耦合。同时实现业务的灵活扩展和系统的灵活扩展。

    数据架构设计中的要点

    上面讲述了数据架构的分层设计,下面讲述数据架构设计中的要点。

    要点1:数据易用性

    数据无论用什么方式实现,其最终目的都是为业务(或者是客户)使用的。因此,在对外提供服务的时候,数据的易用性非常关键。

    enter image description here

    图5 数据易用性

    如图5所示,客户信息在 Logic Data(inner) 层中为了数据的柔软性和非冗余,把人员信息拆成若干子表来存储。比如,人员地址表可以无限多的存储客户地址信息。这样的好处在于每次人员地址更新时,不用直接更新人员地址,而是生成一个新的地址数据,原有的地址信息作为历史数据得到保存,易于数据快速恢复和历史信息追踪。但在 Logic Data(outer)层提供外部数据的时候,首先考虑的是一次性能提供足够用的信息(毕竟查询的操作大大高于修改的操作),减少业务场景中不需要的信息。比如对一般客户只提供三个常用地址的时候,数据设计中地址1、地址2和地址3放在一张表中。

    要点2:主、副数据及数据解耦

    每个微服务 API 的数据完全独立是不太现实的,比如订单中需要有商品、客户(包括收货者)、卖家以及价格等数据。如果这些数据都在订单服务 API 中管理,那么客户情报的变更、价格调整等信息都要同步给订单 API 中数据,数据的耦合度就会变得非常高。在数据设计的时候,需要考虑降低数据间的相互依赖性。因此,首先需要确定每个微服务 API 的主数据和副数据。主数据指微服务 API 的核心数据,这种数据的增删改主要集中在某个微服务 API 中,比如订单服务 API 中的订单数据。副数据指参照或者映射其他微服务 API 的数据,比如订单服务 API 中的商品数据、价格数据等。其次,为了降低数据之间的耦合度,用数据关联表来表征数据间的关系。如果想去掉数据间的关联关系,直接去掉关联表即可,对数据本身的没有任何影响。具体如图6所示。

    enter image description here

    图6 主、副数据及数据解耦

    要点3:分库分表

    随着业务数据量不断增加,单一数据库或单一数据表中会积累大量的数据,比如订单数据,随着时间推移和客户数量的增加,产生的订单数据也会越来越多。当数据累积到一定程度后,数据操作的性能会大幅下降,也就是我们常说的数据库“带不动了”。所以,在数据架构设计阶段就应该考虑数据的分库分表。

    如图7所示,分库,即我们把订单数据分为当前数据应用库、历史数据库、历史归档数据库。当前数据应用库用来支持新订单的生成以及执行中订单的增删改查。历史数据库(这里举例分为最近3个月和最近1年)当客户想看过往订单的时候才使用。历史归档数据(按年间归档)原则上不直接对客户公开,用于备查、统计分析。对于当前数据应用库,可以继续再分库,按客户号范围来分库。这样每个数据库的大小都能得到有效控制。分表,即把一条信息分别存储在两张或多张表中。比如把订单信息按基本信息和详细信息分表,就可以适用于订单的基本信息查询和订单详细信息查询。总之,分库分表的核心就是控制单一数据库的负荷(数据量和数据信息量),通过多表多库来应对业务数据量的增长。

    enter image description here
    图7 分表分库

    要点4:多源数据适配

    传统的关系型数据库之外,有多种多样的数据源,比如图像、声音、视频等多媒体数据文件或数据流,CSV、TXT、Doc、Excle、PDF、XML 等各种异构数。这些数据都需要做相应的处理,转换成可管理的数据信息。因此在数据架构设计的时候,需要给不同性质的数据源配置相对应的读写适配器,同时也需要有统一调度的地方,如图8所示。

    enter image description here

    图8 多源数据适配

    要点5:多源数据缓存

    数据处理的性能除了处理逻辑的复杂度以外,还有很大一部分是目标数据的操作时长(含对硬件磁盘设备的读写以及网络的传输)。网络速度特别是光纤的使用后已经大幅度提高,但机器磁盘的读写效率并没有显著提高,因此减少磁盘读写是提高效率的一个重要途径。数据缓存就是把常用的数据(不会经常更改的数据)、最近使用数据放到内存中。这样就可以大幅降低系统对硬件磁盘设备的操作开销,提高整个数据系统的性能,如图9所示。

    enter image description here

    图9 数据缓存

    要点6:数据集市

    数据集市是一个很大的话题。当现有的数据不能简单地通过几个表数据关联以及简单加工后就可以供业务使用的时候,就需要考虑构建数据集市。数据集市以数据运用的观点来分析加工数据,通过多源数据的导入、清洗、加工、视图做成等一系列的数据操作后,为业务提供可用的、稳定的数据源。例如,对销售分析中、什么样的客户喜欢什么样的商品、价格对销售金额的影响、销售金额跟地区日期的关联关系等多维度分析,就要用数据集市的概念,如图10所示。

    enter image description here

    图10 数据集市

    数据承载着信息,好的数据架构设计会使业务系统变得更加流畅、更加容易理解和维护。本文只是总结一些在实际工程中的体会,供大家分享。如果有不足之处、也请大家补充、赐教。

    【GitChat达人课】

    1. 前端恶棍 · 大漠穷秋 :《Angular 初学者快速上手教程
    2. Python 中文社区联合创始人 · Zoom.Quiet :《GitQ: GitHub 入味儿
    3. 前端颜值担当 · 余博伦:《如何从零学习 React 技术栈
    4. GA 最早期使用者 · GordonChoi:《GA 电商数据分析实践课
    5. 技术总监及合伙人 · 杨彪:《Gradle 从入门到实战
    6. 混元霹雳手 · 江湖前端:《Vue 组件通信全揭秘
    7. 知名互联网公司安卓工程师 · 张拭心:《安卓工程师跳槽面试全指南
    展开全文
  • 软件架构设计入门学习

    千次阅读 2022-02-21 12:36:07
    本文是笔者做立项时,针对产品规划的需求,梳理各种架构图的过程中学习软件架构相关知识笔记。

    什么是软件架构

    定义

      软件架构(Software Architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。软件架构是一个系统的草图。---百度百科
      软件架构指软件系统的“基础结构”,创造这些基础结构的准则,以及对这些结构的描述。---维基百科
      从上面两个对软件架构的定义和软件架构发展史中,我们可以总结得出软件架构是以结构化、模块化和组件化的设计形态进行指导软件程序研发,从而降低软件程序的复杂性。
      注意事项:框架和架构是比较相似的概念,且两者有较强的关联关系,我们需要将框架和架构进行概念区分,根据框架定义(软件框架(Software Framework)通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范,也指为了实现某个软件组件规范时,提供规范所要求之基础功能的软件产品),我们可以发现:框架关注的是“规范”(开发规范),架构关注的是“结构”,框架能够提供基础功能,而架构提供的则是设计指导。

    作用

      软件架构的核心价值,即是控制系统的复杂性,将核心业务逻辑和技术细节的分离与解耦。软件架构是系统的草图,它描述的对象是直接构成系统的抽象组件,各个组件之间的连接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际的组件,比如具体某个类或者对象。在面向对象领域中,组件之间的连接通常用接口来实现。架构师的职责是努力训练自己的思维,用它去理解复杂的系统,通过合理的分解和抽象,理解并解析需求,创建有用的模型,确认、细化并扩展模型,管理架构;能够进行系统分解形成整体架构,能够正确的技术选型,能够制定技术规格说明并有效推动实施落地。

    架构类别

      按照架构面向对象的维度,可以将架构分为业务架构、应用架构、数据架构、功能架构、物理架构(基础架构)这几大类。
      业务架构:面向业务需求价值链的维度进行编制,着眼于跨部门、跨机构提升业务效率,解决业务带来的系统复杂性、重复建设、信息孤岛等问题。在构图时,一般通过分解细化组织/公司的价值链信息,进行模块化、组件化的分类与串联。示例图如下:

                          生鲜行业业务架构
    请添加图片描述

                           供应链业务架构

    请添加图片描述

      应用架构:面向IT系统应用(应用就是处理器)设计和技术实现内容的维度进行编制,提供构建应用时应遵循的路线图和最佳实践,它包含了包含系统的边界和定义、前后端服务、系统间的关联关系等方面的内容,一般分为多个系统的应用架构(企业级应用架构)和单个系统的应架构。示例图如下:

                企业级应用架构(多系统应用架构)
    请添加图片描述

                    电商系统应用架构(单个系统)

    请添加图片描述

      数据架构:面向数据信息产生、交互以及存储的维度进行编制,一般包括:数据源、数据采集、数据存储、数据处理、数据加工、数据分析、数据应用,常见的分为基于业务流程与运营的概念级数据架构和基于数据库技术与数据处理技术的逻辑级数据架构设计。示例图如下:

               MES系统数据架构(基于业务流程与运营概念)
    请添加图片描述

         数据中心(或大数据平台)的数据架构(基于数据库技术与数据处理技术)

    请添加图片描述

      功能架构:面向软件系统功能模块的维度进行编制,主要是介绍模块下其各功能组成的图表,体现了产品功能的同时,也展示了功能的从属关系。示例图如下:

                    供应链系统功能架构图

    请添加图片描述

      物理架构:又称基础架构,面向系统、网络、服务器的维度进行编制,专注于通过服务器部署和配置网络环境,来实现应用程序的“可伸缩性、高可用性”,包括机房搭建、网络拓扑结构,网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。示例图如下:

                    物理架构图
    请添加图片描述

    如何绘制架构图

    (1)明确架构的使用对象
      通过明确使用对象,确认需要画出那种架构图。
    (2)明确架构范围
      通过需求信息明确软件系统的覆盖范围,确认出架构范围边界。
    (3)结构要素梳理
      对事物进行抽象建模,梳理出对应的信息结构,建立关键信息要素之间的关联关系:包含、支撑、同级并列等。
    (4)输出关联关系清晰的架构图
      使用对应工具,进行架构图绘制。

    常用制图工具

      PPT、Visio、draw.io、亿图...
    展开全文
  • 浅谈大数据平台架构设计

    千次阅读 2022-05-07 00:45:18
    全文共3735个字,建议8分钟阅读近年来,随着IT...如果缺乏有效的数据整体架构设计或者部分能力缺失,会导致业务层难以直接利用大数据大数据,大数据和业务产生了巨大的鸿沟,这道鸿沟的出现导致企业在使用大数据的过...
  • 数据交换平台系统的设计方案,从事数据采集交换平台类大型系统架构设计时,可参考。
  • 微服务数据架构设计

    千次阅读 2018-03-19 12:42:30
    微服务开发中的数据架构设计前言微服务是当前非常流行的技术框架,通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性,可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和...
  • 常见的大数据平台架构设计思路

    千次阅读 2020-02-16 21:17:15
    近年来,随着IT技术与大数据、机器学习、算法方向的不断发展,越来越多的企业都意识到了数据存在的价值,将数据作为自身宝贵的资产进行管理,利用大数据和机器学习能力去挖掘、识别、利用数据资产。...
  • 数据中心架构设计

    千次阅读 2020-10-22 09:21:42
    目录 功能架构 技术架构 总体架构 功能架构 技术架构 总体架构
  • 软件架构设计---软件架构概述

    万次阅读 2018-09-17 21:25:54
    通俗地讲,软件架构设计就是软件系统的“布局谋篇”。 人们在软件工程实践中,逐步认识到了软件架构的重要性,从而开辟了一个崭新的研究领域。软件架构的研究内容主要涉及软件架构描述、软件架构设计、软件架构...
  • ERP系统架构设计

    千次阅读 多人点赞 2018-07-23 22:48:30
    [分布式、服务化的ERP系统架构设计] ERP之痛 我混迹于伟创力3年多,为这个行业开发过两套大型业务系统(ERP)。作为一个ERP系统,系统主要功能模块无非是订单管理、商品管理、生产采购、仓库管理、物流管理、财务...
  • 数据中台系统架构设计

    千次阅读 2021-03-11 01:00:01
    架构总览数据中台通常采用分层架构,各层应用采用微服务化方式构建。针对不同的行业,系统托管方式各不一样,比如传统企业更倾向于采用私有云或自建机房,小型互联网企业倾向采用公有云等;针对不同应用...
  • 微信小程序原理与架构设计

    千次阅读 2020-07-06 18:34:49
    微信小程序原理与架构设计0.目前移动端主流的开发模式:1.0 小程序页面与H5页面的区别2.0 小程序的架构设计2.1 双线程模型2.2 组件系统3. 小程序的生命周期 0.目前移动端主流的开发模式: Native APP 原生应用 开发...
  • 5. 数据架构 二、数据设计 1. 数据库的逻辑模型 2. 数据库的常用模型 3. 实现从面对对象模型到表的转换 4. 数据库的物理模型 一、架构设计五视图 1. 逻辑架构 逻辑架构关注的是功能,包含用户直接可见的...
  • 第三,如何进行数据架构设计。 技术架构:应用架构本身只关心需要哪些应用系统,哪些平台来满足业务目标的需求,而不会关心在整个构建过程中你需要使用哪些技术。技术架构是应接应用架构的技术需求,并根据识别的...
  • 数据架构与数据模型

    千次阅读 2020-06-26 21:12:57
    数据架构与数据模型 数据架构与数据模型两者关系经常是讨论的热点。 因为数据架构里面主要工作和产物就是数据建模和数据模型,那为什么要将两者作为独立的两个过程域。 本文将对此问题进行探讨。 在《数据管理...
  • 数据仓库(6)数仓分层设计架构

    千次阅读 2022-04-14 11:46:15
      目前主流的数据仓库分层大多为四层,也有五层的架构,这里介绍基本的四层架构。 分别为数据贴源层(ods)、数据仓库明细层(dw)、多维明细层(dws)和数据集市层(dm)。   下面是架构图:   数据分层的目的是:...
  • 软件架构设计-软件架构风格、分层架构

    万次阅读 多人点赞 2021-06-12 15:39:23
    一、软件架构设计 软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件元素、元素的外部可见属性及它们之间的关系组成。 软件系统架构是关于软件系统的 结构、行为和属性 的高级抽象。指定了软件...
  • 典型数据中台分析,实现数据中台技术分析,数字化产品分析(仿真数据洞察,数字化数据洞察,2D数据洞察)
  • 软件架构设计

    千次阅读 2022-02-20 15:23:48
    系统设计是业务处理设计,而架构设计是设计一个机制和方案,让业务处理能够实现和落地。 架构设计填补了用户需求和系统设计之间的鸿沟。
  • 到底什么叫作数据架构

    千次阅读 2021-03-18 00:23:25
    随着数据治理工作的深入,数据标准的理念逐步为人所知、所识。但是,数据架构是什么,如何管理,谁来负责,还没有形成一致的共识。早前,在技术领域,系统架构、应用架构、信息架构相对为人了解,近年来...
  • 数据中台02:数据中台架构

    千次阅读 2022-03-17 12:48:38
    前面我们通过理论层面对数据中台有了一定的了解,下面我们通过架构层面来详细看一下数据中台的设计数据中台是位于底层存储计算平台与上层的数据应用之间的一整套体系。 数据中台屏蔽掉底层存储平台的计算技术...
  • 互联网架构设计

    千次下载 热门讨论 2015-09-04 14:49:37
    空间换时间 数据与计算切分 多维度可用 伸缩 优化资源利用
  • 架构的定义      软件架构仍在不断发展中,还没有形成一个统一的、公认的定义,这里仅举出几个较为权威的定义。 软件或计算机系统的软件架构是该系统的一个(或多个)结构,而结构由软件...
  • 架构设计——架构概述

    千次阅读 2022-03-26 22:19:28
    介绍了架构的基础概念,何为架构以及架构如何学习。
  • 1:架构设计 2:项目验收 架构设计原则 1:体系安全 2:成本合理 3:稳定可靠 4:性能适用 5:运维高效 体系安全 1:合规标准:1,国际标准;2,国家标准;3,行业标准;4,公司要求 2:系统的整体安全 3...
  • 架构设计七张图

    千次阅读 2021-06-24 18:44:40
    架构设计是解决方案的腰,承上启下,统贯全局。解决方案架构设计通常包含七张图: 第一张图:
  • 什么是数据中心架构

    千次阅读 2022-03-14 21:36:03
    数据中心是支持企业计算活动的物理设施,实现信息的集中处理、存储、传输、交换和管理,数据中心架构作为一种在交换机和服务器之间建立连接的架构设计,通常是在数据中心设计和建设阶段创建的。此外,它指定了服务器...
  • 软件架构设计——软件架构风格

    千次阅读 2021-10-21 14:51:32
    软件架构是具有一定形式的结构化元素,即构件的集合,包括处理构件,连接构件和数据构件。处理构件负责对数据进行加工,数据构件是被加工的信息,连接构件把架构的不同部分组合连接起来。 特点: 1、软件架构风格是...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 968,849
精华内容 387,539
关键字:

数据架构设计

友情链接: dmnmucms-v1.2.0.full.zip