架构设计之业务应用技术数据架构

Posted 2021-04-10 致IT向前跑

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了架构设计之业务应用技术数据架构相关的知识，希望对你有一定的参考价值。

1. 概述

我们在日常软件架构设计中会根据需求做出不同的架构设计，而在设计时需要涉及一定的架构设计核心要素，本文将会简述日常较为普遍的业务、应用、技术及数据架构。

2. 架构设计简述

架构设计是从业务需求到系统实现的一个转换，是对需求进一步深入分析的过程，用于确定系统中实体与实体的关系，以及实体的形式与功能。架构根据业务需求到系统实现主要分为：业务架构、应用架构、技术架构、数据架构，下文从基于IoT平台系统进行简述。

2.1. 业务架构

业务架构是对业务需求的提炼和抽象，使用一套方法论对产品/项目所涉及需求的业务进行业务边界划分，根据一套逻辑思路进行业务拆分，开发软件必须满足业务需求，否则就是空中楼阁。

软件系统在业务上的复杂度问题，可以从业务架构的角度切分工作界面来解决。如在做一个基于IoT平台系统时候，需要把用户管理、设备管理、订单管理、支付处理及支付管理等功能很清晰地划分出来，不要在业务架构中考虑用什么技术开发、并发量是否太大、选择什么样的硬件，等等。

这里简单规划了IoT平台系统的业务模块，对其根据业务架构的模块不断细化，一直分解到代码流程。对于软件开发而言，以业务架构为依托，架构师和开发者能比较清晰地看到系统的业务全貌，架构师能更方便地分析系统复杂度，分解业务逻辑，做好开发的分工。

业务架构是决定一个软件项目能否顺利开展的总纲，软件架构是业务架构在技术层面的映射，合理的开发分工也应该基于业务架构去做。如果没有业务架构，进行软件开发就会很盲目。业务架构是需求和开发的汇聚点，需求分析是否做到位，功能开发是否达到预期目标，都以此为依托。我们在工作中会遇到一些问题，例如研发人员说需求分析做得不到位，而做需求的人员会质疑需求做到怎样才算到位，为什么开发出的产品和用户想要的不一致，这些从根上来说，都是因为没有将业务架构梳理清楚，没有达成共识。

站在软件项目的角度来看，在项目前期做好业务架构设计，对整个项目的开发都有重要的意义。例如，对于比较类似的业务系统，可能业务架构在比较粗的颗粒度上是一样的，而在细化过程中不一样。

在做项目时，当手头有一个现成的系统，需要做一个需求类似的项目时，大家可能会首先尝试用现成的系统去覆盖新项目，以求利益最大化。对于该想法能否实现，可以通过业务架构来衡量，如果没有业务架构，则接下来的工作会非常盲目。

业务架构的设计原则如下。

2.1.1. 业务平台化

n 业务平台化，相互独立，例如用户平台、交易平台、支付平台、设备平台等。

n 基础业务下沉，可复用，例如用户、设备、订单、支付渠道等。

2.1.2. 核心业务和非核心业务分离

将平台系统的核心业务和非核心业务如主交易服务和通用交易服务分离，将核心业务精简（利于稳定），并将非核心业务多样化。

2.1.3. 隔离不同类型的业务

n IoT平台的作用是让用户使用便捷的IoT服务，所以需要优先保证高可用，向用户提供便捷的服务。

n 履约业务对可用性没有太高要求，但要优先保证一致性。

n 秒杀业务对高并发要求很高，应该和常规业务分离。

2.1.4. 区分主流程和辅助流程

要清楚哪些是平台系统的主流程，在运行时优先保证主流程的顺利完成；对辅助流程可以采用后台异步的方式，避免辅助流程的失败影响主流程的失败回流。

2.2. 应用架构

应用架构介于业务与技术之间，是对整个系统实现的总体架构，需要指出系统的层次、系统开发的原则、系统各个层次的应用服务。

将系统分为展示层、接口层、服务层、服务构建层、业务流程层、数据层、集成层、数据架构层和服务治理层，并写明每个层次的应用提供的服务。

在进行系统拆分时，要平衡业务和技术的复杂度，保证系统形散神不散。系统采用什么样的应用架构，则受到业务复杂度的影响，包括企业的发展阶段和业务特点；同时受技术复杂度的影响，包括 IT技术的发展阶段和内部技术人员的水平。业务的复杂度（包括业务量大）必然带来技术的复杂度，应用架构的目标是在解决业务复杂度的同时避免技术太复杂，确保业务架构落地。

架构设计之业务、应用、技术、数据架构

应用架构的设计原则如下。

2.2.1. 稳定

n 一切以稳定为中心。

n 架构尽可能简单、清晰，追求小而美，不要大而全。

n 不过度设计。

2.2.2. 解耦

n 将稳定部分与易变部分分离。

n 将核心业务与非核心业务分离。

n 将电商主流程和辅助流程分离。

n 将应用与数据分离。

n 将服务和实现细节分离。

2.2.3. 抽象

n 应用抽象化：应用只依赖服务抽象，不依赖服务实现的细节和位置。

n 数据库抽象化：应用只依赖逻辑数据库，不需要关心物理库的位置和分片。

n 服务抽象化：应用虚拟化部署，不需要关心实体机的配置，动态调配资源。

2.2.4. 松耦合

n 跨域调用异步化：在不同的业务域之间尽量异步解耦。

n 非核心业务尽量异步化：在核心业务和非核心业务之间尽量异步化。

n 在必须同步调用时，需要设置超时时间和任务队列的长度。

2.2.5. 容错设计

n 服务自治：服务能彼此独立修改、部署、发布和管理，避免引发连锁反应。

n 集群容错：应用系统集群部署，避免单点服务。

n 多机房容灾：多机房部署、多活。

2.3. 技术架构

技术架构就是对在业务架构中提出的功能（或服务）进行技术方案的实现，包括软件系统实现、操作系统选择和运行时设计。技术架构的边界比较模糊，对于不同的受众，内容的详细程度也不同，技术栈自上而下比较关注技术架构，但是各层关注的点不同。技术决策层可能关心的是系统或系统群的技术选型，对整体的把握要保证不因为选型引起其他风险，例如，如果在高性能存储方面选择 Redis，就要尽量保证网络的封闭性，避免公网访问；再如，在选择开发语言实现的各类产品时，要考虑市场上开发人员数量少，需要承担更高的迭代成本等。

上述业务架构的一个简单技术架构。

技术架构的设计原则如下。

2.3.1. 无状态

即尽量不要把状态数据保存在本机上。

2.3.2. 可复用

n 复用粒度是有业务逻辑的抽象服务，不是服务的实现细节。

n 服务引用只依赖服务抽象。

2.3.3. 松耦合

n 跨业务域调用，尽可能异步解耦。

n 在同步调用时设置超时时间和队列大小。

n 将相对稳定的基础服务与易变流程服务分离。

2.3.4. 可治理

n 服务可降级。

n 服务可限流。

n 服务可开关。

n 服务可监控。

n 白名单机制。

n 制定服务契约。

2.3.5. 基础服务

n 基础服务下沉、可复用。

n 基础服务自治、相对独立。

n 对基础服务的实现要精简，并可水平扩展。

n 对基础服务的实现要进行物理隔离，包括基础服务相关的数据。

2.4. 数据架构

数据架构是对存储数据（资源）的架构，其设计原则和应用架构设计大同小异，在设计时需要考虑系统的业务场景，需要根据不同的业务场景对数据进行异构设计、数据库读写分离、分布式数据存储策略等。

下图为IoT平台系统中数据架构的一个概要。

数据架构包括两部分内容：静态部分的内容和动态部分的内容。

静态部分的内容的重点是数据元模型、数据模型，包括主数据、共享动态数据和所有业务相关的业务对象数据的分析和建模；动态部分的内容的重点则是对数据全生命周期的管控和治理。因此，不能单纯地将数据架构理解为纯静态的数据模型。业务架构中数据模型的分析重点是主数据和核心业务对象，应用架构中数据模型的分析重点则进一步转换为逻辑模型和物理模型，直到最终的数据存储和分布。

数据分两个层面的生命周期：单业务对象数据的全生命周期，它往往和流程建模中的单个工作流或审批流相关；跨多个业务域对象数据的全生命周期，它体现的是多个业务对象数据之间的转换和映射，

往往和端到端的业务流程BPM 相关。这里要注意，数据虽然是静态层面的内容，但是数据的生命周期或端到端的数据映射往往间接反映了流程，这是很重要的内容。

数据建模的方法包括面向结构的传统ER模型分析方法，也包括面向对象的对象类模型分析方法，它们都是可行的数据建模方法，只是传统ER模型分析方法更容易实现向底层物理数据库模型的转换，而面向对象的对象类建模方法更容易体现抽象和复用。特别是在企业架构建模中，面向对象和面向结构往往不是严格区分的，很多时候都会出现两种方法混用的情况，但重点是区分每种方法或工具的重点及要解决的问题。与数据相关的矩阵分析相当多，业务架构阶段的重点矩阵分析是业务对象和业务流程、业务组件、业务功能间的类CRUD矩阵分析；而应用架构阶段的重点矩阵分析是逻辑或物理模型对象和具体的应用模块或应用功能间的矩阵分析。两者的思路基本类似，只是关注的层面不同，前者重点关注主数据的识别和业务组件的分析，而后者重点关注应用功能模块的划分和模块间集成接口的初步分析。

根据前面的思路，我们仍然应该将数据集成分析分解为两个层面的内容：业务层面的分析，以及应用和 IT 实现层面的分析。前者的重点是理清业务流程或业务域之间的业务对象集成和交互，而后者的重点是如何更好地共享数据或如何通过类似的 BI 工具或大数据平台实现数据的集成和交互。

数据架构的设计原则如下。