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.确定数据管理组织或岗位。