通用业务平台设计:自动化打包平台建设

Posted 当年的春天

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了通用业务平台设计:自动化打包平台建设相关的知识，希望对你有一定的参考价值。

前言

在上家公司，随着业务的不断拓展，需要打多个包来支持业务的快速发展；这篇文章主要为大家分享在构建自动化打包平台过程中一些经验总结以及躺过的坑。

通用业务平台系列

自动化打包平台

  • 生成nginx接口混淆（55个老接口），并在测试和预生产环境进行部署

    • 数据库表-注意新的url加唯一索引（生成策略:每级：产品名首尾字母，加随机数），表结构 老接口地址->新接口地址；表结构如下
-- 基础配置表
CREATE TABLE `hx_url_config` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `config_no` varchar(64) DEFAULT '' COMMENT '配置编码',
  `config_name` varchar(80) NOT NULL DEFAULT '' COMMENT '配置名称',
  `file_name` varchar(80) NOT NULL DEFAULT '' COMMENT '文件名称',
  `config_url` varchar(80) NOT NULL DEFAULT '' COMMENT '配置地址',
  `type` int(2) DEFAULT NULL COMMENT '类型，(1：配置类型，2：配置地址)',
  `status` int(2) DEFAULT NULL COMMENT '环境(1:测试，2:预生产，3:生产1，4:生产2)',
  `sort` int(2) DEFAULT NULL COMMENT '权重',
  `create_uid` varchar(32) NOT NULL DEFAULT '-1' COMMENT '创建人',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  `param1` int(2) DEFAULT NULL COMMENT '预留字段1',
  `param2` int(4) DEFAULT NULL COMMENT '预留字段2',
  `param3` int(11) DEFAULT NULL COMMENT '预留字段3',
  `param4` varchar(32) DEFAULT '' COMMENT '预留字段4',
  `param5` varchar(64) DEFAULT '' COMMENT '预留字段5',
  `param6` varchar(128) DEFAULT '' COMMENT '预留字段6',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='配置表';

-- 原接口表
CREATE TABLE `hx_old_interface_url` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `old_url` varchar(80) NOT NULL DEFAULT '' COMMENT '访问地址',
  `create_uid` varchar(32) NOT NULL DEFAULT '-1' COMMENT '创建人',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  `param1` int(2) DEFAULT NULL COMMENT '预留字段1',
  `param2` int(4) DEFAULT NULL COMMENT '预留字段2',
  `param3` int(11) DEFAULT NULL COMMENT '预留字段3',
  `param4` varchar(32) DEFAULT '' COMMENT '预留字段4',
  `param5` varchar(64) DEFAULT '' COMMENT '预留字段5',
  `param6` varchar(128) DEFAULT '' COMMENT '预留字段6',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_hx_old_interface_url_old_url` (`old_url`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='原接口表';

-- 新接口混淆表
CREATE TABLE `hx_new_interface_url` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `app_product_name` varchar(32) NOT NULL DEFAULT '' COMMENT '包产品名',
  `hx_old_id` bigint(20) NOT NULL DEFAULT '0' COMMENT '原来接口的id',
  `new_url` varchar(80) NOT NULL DEFAULT '' COMMENT '访问地址',
  `create_uid` varchar(32) NOT NULL DEFAULT '-1' COMMENT '创建人',
  `create_time` datetime DEFAULT NULL COMMENT '创建时间',
  `param1` int(2) DEFAULT NULL COMMENT '预留字段1',
  `param2` int(4) DEFAULT NULL COMMENT '预留字段2',
  `param3` int(11) DEFAULT NULL COMMENT '预留字段3',
  `param4` varchar(32) DEFAULT '' COMMENT '预留字段4',
  `param5` varchar(64) DEFAULT '' COMMENT '预留字段5',
  `param6` varchar(128) DEFAULT '' COMMENT '预留字段6',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uk_hx_new_interface_url_new_url` (`new_url`),
  UNIQUE KEY `uk_hx_new_interface_url_appname_oldid` (`app_product_name`,`hx_old_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='新接口混淆表';

  • 三个环境的nginx配置文件，并上传至git

    location /ag/gdnf/gcoev 
	 rewrite ^ /ag_gdnf_gcoev last;

location /ag_gdnf_gcoev 
	proxy_pass http://192.168.168.62:8888/get/config/onoff;

  • 调用测试环境shell脚本进行拉取并reload对应环境的nginx

  • 上传固定的 图片，秘钥文件，google的json文件

  • 形成新的包（APP开发人员通过swagger接口进行访问）

    • 从git上拉原始代码并复制到新的目录下

    • 对源代码的秘钥 进行进行替换（调用python进行替换）

    • 替换图片(调用python进行替换)

    • 执行混淆后的接口替换（调用python进行替换）

    • 对源代码产品名替换(调用python)

    • 增加无效资源（调用python）

    • 增加无效方法

    • 将新形成的代码提交git(调用shell）

    • 针对新的代码打不同环境的apk包并将包上传至oss（调用shell脚本）

    • 将新的包的资源地址发邮件给 开发及测试

  • 生产环境处理

    • APP开发用新的机器打 生产包（生产域名替换）
    • 发上线申请邮件，发需要混淆接口的产品名，附件APP包
    • 运维执行生产环境nginx混淆，并将新包上传生产环境的OSS
    • 测试进行验证

  • 效率提升

    项手工方式自动化打包平台
    打包效率1个包/3人天1天/N个包（实际半年打包 412个，实际3个/1人天）
    受制约因素开发打包产品提供素材、测试、运营

总结

  • 本篇博文介绍了自动化打包平台的建设，建设该平台使得出包效率提高了10倍+；
  • 当我们在做重复工作时，一定要思考一下做成自动化，提高我们的工作效率，从而将自己的精力放到更具有创造性的工作中去；
  • 大家有相关经验也可以在评论区共享下。

谈谈通用对账平台的业务架构设计


前言

前面的《》一文主要阐述了对账的一些共性，本文主要聊一聊通用对账平台的业务架构设计。

个人理解的业务架构设计，主要是基于实际的需求，准确地识别出要解决的问题域，即识别出问题是什么及问题跟谁有关，从而确定问题域的边界，再基于要解决的问题域，梳理业务流程、划分功能模块、明确模块间的信息流、抽象核心业务实体等。

关于业务架构，业内其实也没有统一标准的权威定义，因此见仁见智，每个人的理解都可能会不同，但有一点则是大部分人所认可的，那就是：业务架构不需要考虑诸如我用什么语言开发、我的并发吞吐大怎么办、我选择什么样的中间件等，它更多的是对业务领域的不变性的一种抽象，比如概念的不变部分，关系的不变部分，逻辑的不变部分等。我们需要识别出这些不变的点，并将之与变化的点进行隔离。



— 1 —

业务边界


可能会有朋友会问，现有的各个业务系统其实各自或多或少已经内建了一定的对账功能，此时再去新建一个对账平台的意义是什么呢？是否有必要？其与现有的这些系统的内部对账模块的区别又是什么呢？

简单说，有如下2点区别：

  • 定位的不同：对账平台是面向所有业务系统的，定位为通用的数据核对平台，是服务外部所有业务的。而现有的业务系统的内部对账模块一般只给自己用，只满足自身业务的对账需要，尤其是有的对账逻辑与业务逻辑耦合较强。

  • 覆盖面不同：对于新建系统或没有对账能力的业务系统，对账平台可以帮助它们快速支撑起自己的业务对账能力，而对于已具备对账能力的业务系统，则对账平台可扩展其对账能力的深度与广度，补充其缺失或不足的方面。


谈谈通用对账平台的业务架构设计

上面的回答其实已涉及到了对账平台的核心问题域，那么， 通用对账平台到底能解决什么问题呢？

主要解决如下2个问题：

  • 通过核对数据之间的勾稽关系、识别异常差异（如长短款），促进业务交易数据的准确性和一致性的提升。

  • 提供的通用核对能力能快速支撑起各个业务的对账能力，能有效减少各个业务在对账方面的重复建设，节省资源。

以上2点其实也正是建设通用对账平台的价值所在，那么这个价值又是针对谁而言的呢，也即通用对账平台跟谁有关呢？

主要跟如下两方人员有关：

  • 相关业务系统的owner/leader

即接入对账平台的各个业务方，体现为这些业务系统的owner或leader。

  • 财务同事

出于财务稽核的需要，财务同事往往也属于对账平台的一个重要业务方。

上面2个问题如果要合成一个问题，那就是为谁提供了什么价值，那么该如何有效衡量这个价值呢？即该以哪些 KPI 指标来衡量通用对账平台的业务价值？

至少可以有如下几方面来衡量对账平台的业务价值：

  • 对账时效性：越高越好

  • 错核的次数：越低越好

  • 漏核的次数：越低越好

  • 数据的量级：越大越好

  • 接入业务数：越多越好

综上，如果要用一句话来描述，什么是通用对账平台的话，该如何描述呢？它是一个以促进数据准确性和一致性的提升为目标，面向各个业务方，基于具备勾稽关系的多个数据源，提供通用核对能力的中后台系统。

谈谈通用对账平台的业务架构设计

至此，已确定了对账平台是什么、跟谁有关、有什么价值，则也意味着确定了对账平台的业务边界，或者说问题域边界，后续的设计和实现都必须在这个边界之内进行才有意义。



— 2 —

核对什么

对账的实质是针对指定的关键数据项进行核对，那到底有哪些关键数据项呢？

谈谈通用对账平台的业务架构设计

个人认为，至少有以下几个：

  • 核对金额：必选，金融业务里的对账往往跟钱是强相关的，其实不光是金融业务，很多业务的对账也都基本会涉及到金额的核对。

  • 核对笔数 ：可选，因为更多地是适用于数量关系确定的业务场景，比如一对一或固定的一对N（N要为确定不变的某个固定值）。如果是不固定的一对多的场景，则不太适用，因为会引入不小的复杂度。

  • 核对状态：可选，因为仅适用于参与核对的两方在数据状态上存在一个确定的对应关系，这其实在一定程度上会让对账本身与具体业务产生耦合，需要感知和同步参与核对的两方的数据状态定义。

  • 核对关系：可选，关系核对属于比较复杂的一种核对，数据源必须要能提供体现关系映射的属性，否则是无法进行关系核对的。金融业务中典型的关系核对场景有比如是否存在错扣（扣A用户的钱扣成B）




— 3 —

对账流程


谈谈通用对账平台的业务架构设计

一个接入业务可以包含多个对账场景，而一个对账场景 = 数据准备 + 数据比对 + 结果处理 。

事实上，大部分的对账场景的处理流程其实都可以大致分为这三大环节。

第一个环节 数据准备：即准备好要比对的数据，该环节可抽象为如下几步：

1）数据获取

即如何获取数据源的数据，一般是按照指定的数据源规则来获取：

  • 获取方式：可分为DB、文件、RPC接口、消息几种

  • 获取频率：取决于数据源的提供频率，可分为天、小时、分钟3种

  • 细节配置：不同的获取方式下的配置不同，比如DB方式，则要配置DB的用户名密码、目标表名等，文件方式则要配置约定的文件名、分隔符等。

2）解析转换

即在获取到源数据后作一些预处理，比如支付的外部对账场景，就需要先将多个不同的外部支付渠道的源数据按照统一格式进行解析转换再入库，又比如部分一对多的对账场景中，会对“多”的那一方的源数据先做一定的归并计算再入库。

如果没有什么需要解析转换直接加载源数据入库，则这一步可以配置为跳过。

3）保存入库 

即持久化到DB，但也有可能不入库，直接进入下一步的比对环节，因此要看具体的场景需要。

第二个环节 数据比对：比对环节是最核心的环节。

该环节看着似乎很简单，无非就是数据的比较（虽然数据核对的本质就是基于相同的唯一属性，来关联两方数据源进行数据比较），但作为一个通用的对账平台，还是要更多考虑扩展性方面的设计。

谈谈通用对账平台的业务架构设计

如上图所示，比对环节可以抽象为由多个比对任务组成，每个比对任务又由多个处理器组成：

    1）比对任务：可以理解为比对环节的细分和拆解，上一个比对任务的输出是下一个比对任务的输入。

    2）处理器：可以理解为比对任务的细分和拆解，一个处理器可以理解为一个业务插件，包括：

加工器：负责对数据进行加工，例如金额的合并计算。

比对器：可分为金额比对器、笔数比对器、状态比对器、关系比对器。

其他处理器：可以针对实际的场景设计不同的处理器。

自定义的处理器：为业务方自定义的处理器，比如业务方的一个RPC接口。

而每个比对任务都由这些处理器组成，可以只是其中一个处理器，也可以是多个处理器的组合。每个处理器的输出可作为下个处理器的输入，也支持不采用上个处理器的输出，而是可以按照自定义的逻辑读取相应数据。

虽然大部分的常规核对场景都比较简单，比如可能就是简单地核对两方的金额即可，但也存在部分较为复杂的核对场景：

  • 比如“发生额-余额”的对账场景，需定时累加对应账户的发生额与该账户对应时间点的余额进行比对，则就需配置一个加工器+一个比对器，即加工器去累加该时间段内的所有发生额，并加上上个余额。

  • 又比如前面提到的“一对多”场景，可以配置一个加工器+一个比对器，加工器就是对“多”的那一方数据按照一定维度做合并计算，然后再由比对器负责将合并计算后的结果与另一边进行比对。

通过这种可插拔式、能自由组合的“插件化”的处理器机制，可达到“可胖可瘦、可高可矮”的良好扩展性。即：既可以满足简单通用的常规对账场景（如一对一的金额核对），又可以满足个性化的、较复杂的对账场景（例如账户发生额与余额的核对、一对多的核对多对多的核对等）。

谈谈通用对账平台的业务架构设计

比对环节还要注意如下几个设计要点：

1）比对任务的编排流转

由于比对环节被拆解为了多个比对任务，因此要考虑每个比对任务之间该如何编排、流转。当然了，如果是比较简单的核对场景，则配置为一个比对任务即可。

2）比对任务的前置检查

即每个比对任务都可以有一定的前置依赖，若有，则需检查是否满足依赖条件。

3）正常差异的勾兑冲销

比对发现的数据差异一般可分为“单边、重复、不一致”这3种：

  • 单边：指一边有一边无。

  • 重复：指两边都有对应记录，但至少有一边存在多条相同的记录。

  • 不一致：指非单边且非重复，但两边的关键数据项不同。

以上差异需要区分出正常差异和异常差异，其中正常差异指业务方可接受的差异，比如一笔跨天的转账交易，转出交易在T日，转入交易在T+1日，则在T日就是单边差异，可在T+1日将该单边差异勾兑冲销，因为属于正常差异。

谈谈通用对账平台的业务架构设计

因此这一步主要就是从核对出的数据差异中，识别出哪些属于正常差异，并将之勾兑冲销，剩余的就是异常差异了。

第三个环节 结果处理：即如何处理对账结果，可抽象为如下2步：

1）对账结果的反馈

即对账完成后，该如何通知业务方（上游业务owner、财务同事等）、该通知哪些内容（如成功与否、异常原因等），该以怎样的方式（邮件、文件、RPC接口、消息等）通知到业务方。

2）异常差异的处理

即对账结果中的异常差异记录的处理状态的扭转（处理与否、处理描述等），于对账平台而言，只是一个象征性的动作，表示该异常差异已经得到了处理，背后还是需要依靠业务方介入分析异常差异的原因。




— 4 —

功能划分


谈谈通用对账平台的业务架构设计

如上图所示，大概可以分为7大功能：

1）规则参数管理：主要负责如下三类规则或参数的配置：

  • 对账规则配置：如数据源规则、比对规则、结果处理规则 等

  • 比对处理器配置：如加工器、比对器、自定义处理器等

  • 其他参数配置：如日期参数配置

注：比对规则里主要是配置比对频率、差异阈值以及选择相关的比对处理器。

2）业务接入管理：负责为每个接入业务配置对应的对账场景，每个对账场景里则包含对应的数据源规则、比对任务、结果处理规则 等

3）批量任务管理：对账其实也是一个批处理任务，需要对这些批量任务的启动、停止、查看、重跑等进行管理，一般会由一个通用的批处理框架来支撑。

4）相关数据查询：负责对账数据的查询。

5）数据同步处理：按照配置好的对账场景进行数据获取、解析转换、保存入库等。

6）数据比对处理：按照配置好的对账场景进行负责数据的比对。

7）核对结果处理：负责核对结果的反馈与异常差异的处理。



— 5 —

领域实体

基于前面的对账流程和功能划分，可以抽象出如下几方面的领域实体，要注意的是，这里的领域实体描述的还是比较简略，因为并没有给出每个实体的核心属性有哪些，以及这些领域实体有哪些领域事件及事件约束等等。最终的领域实体还是要结合具体的业务场景、应用架构、技术架构等来确定。

规则参数相关：如下所示，从左至右属于包含关系，后者包含前者。

谈谈通用对账平台的业务架构设计

对账处理相关：如下所示，每个实体数据产生时的所处阶段如下所示：




— 6 —

总体逻辑架构


如上图所示，基于规则中心里的规则（数据源规则+比对规则+结果处理规则）来配置各个接入业务的对账场景（如信息流与信息流核对），按照对账场景来进行相关的对账处理（数据准备、数据比对、结果处理）。


最后的话

本文主要聊了聊通用对账平台的业务架构设计，但业务架构毕竟不是一个具体的技术实现方案，因此一个系统光有业务架构设计是很难落地的，后续将会另外开篇再聊一聊通用对账平台的应用架构和技术架构的设计。

完结 撒花


往期回顾：








以上是关于通用业务平台设计:自动化打包平台建设的主要内容，如果未能解决你的问题，请参考以下文章

一款企业信息化开发基础平台，拟集成办公自动化(办公自动化)、厘米(内容管理系统)等企业系统的通用业务功能 吉普车平台项目是一款以春靴为核心框架，集形式框架Mybatis，网页层框架春季MVC和多种开

自动化运维中的运维平台规划

TOP100summit 2017：案例分享魅族持续交付平台建设实践

谈谈通用对账平台的业务架构设计

某二手交易平台大数据平台从 0 到 1 演进与实践

某二手交易平台大数据平台从 0 到 1 演进与实践