作者个人资料

本文是一篇联合文章，作者团队负责集团的付款会计系统，消费者财务会计系统，清算，和解和和解的开发，设计，操作和维护。

一

1。序言

最初，随着自己的业务发展，内的各种会计系统是建立的。有一些常见的事情，但也有很多差异。但是，其基础业务的抽象是统一的，可以将其抽象成：开放，会计和审计。为了促进系统开发，运营和维护，并更好地为前端业务提供支持，我们计划实施会计中端系统以实现会计系统：

1）敏捷性：迅速适应业务需求的变化，满足快速变化的外部需求并实现业务敏捷性。

2）解耦：建立一个功能上独立的系统，以避免由于函数的修改并降低功能耦合程度而影响许多方面。

3）重用：重用一些公共组件来提高发展效率，避免重复的结构，以便可以控制数据和过程。

一

2。通往台湾中部会计的道路 - 基础知识

2.1系统概述2.1.1背景

会计系统的第一阶段开始于2014年建立，并进行了两次主要的技术架构升级。

问题I：

当会计小组首次成立时，的Java 尚未完善。

从技术上讲，我们是第一个飞行Java的小组。所使用的分布式RPC框架是冰。它可以支持多语言，通过文件生成代码，并更好地执行代码，因此我们在选择模型时使用了它。消息队列，缓存。这些集群是自我操作和维护的。

在业务方面，业务的第一阶段仅支持单个用户帐户模型，交易支持补给，付款，退款，预授权（预授权冻结，预授权撤销，预授权完成，预授权撤销预撤销），撤回），撤回和转移。这些接口都是根据业务界面独立开发的。

系统业务体系结构图如下：

阶段2：

随着的Java技术堆栈的改进，第二阶段主要升级了Java ，放弃了自动操作和维护群集，并使用了的Java系统，包括SOA，QMQ和其他技术。会计系统和日期的实施已在业务中添加。

系统业务体系结构图如下：

原始会计核心系统有以下问题：

1）抽象不足：如果需要通过编码来实施新业务，则业务规则的抽象不足

2）隔离不足：系统中不同服务的系统流量和数据不是隔离的，某个业务存在问题，这将影响全球风险。

3）降级策略：不支持

4）难以扩大能力

基于上述问题，我们设计并实施了一个新的统一会计平台。

2.1.2目标

为了响应旧系统的缺点，我们确定了统一会计平台的目标：

1）摘要

2）隔离

3）易于扩展

4）配置

5）支持多个机构和多个货币

2.2系统体系结构和简介

统一会计系统旨在建立一个基于组下的高度可用，易于缩放和可自定义的会计系统。该系统包括方案代码系统，会计预注册系统，会计核心系统，帐户管理系统，会计系统，异步系统，工作系统和日志系统。每个系统之间的服务分裂和解耦。

系统业务体系结构图如下：

2.3系统设计

2.3.1基本组件设计

2.3.1.1日志组件

当我们输出日志时，我们将遇到以下疼痛点：

1）我们经常记录该方法的参数，参数和例外，并将标签写入和ess。笔迹的工作量很大。

2）需要脱敏一些日志，例如手机号码，ID号和卡号，并且无法将纯文本输出到日志中。

3）目前，它仅支持分发公司的日志平台。部门很难自定义日志查询分析工具。

因此，在设计统一会计中端化的项目中，设计了日志组件：

1）均匀地使用高性能更换；

2）通过AOP并支持方法传入参数，传出参数和异常日志的自动打印；

3）支持堵塞和ES标签的配置。它们可以从参数获得并通过它们输入本地线程。标签在线程使用过程中共享。代码如下：

4）支持脱敏规则的配置并执行敏感信息的脱敏处理；

5）同时分发公司的堵塞和猫，异步分发，异步接受ETL处理程序，并分发部门自己的日志系统（例如 ，Hive Log ）；

6）分发时，在原始消息上执行ARVO压缩，以减少传输带宽；

7）支持本机API，可以手动调用标签并脱敏。

流程图如下：

2.3.1.2库和表组件

对于图书馆组件，我们已经研究了公司现有和开源组件，最后选择了开源-JDBC。

1）的DAL组件

DAL使用DAL通过服务器配置库和表信息，但是使用DAL的完整集太大了。这是一个完整的ORM框架。生成SQL的工具不支持特殊自定义SQL的生成。

2）的QDB组件

缺点是，文档较少，很容易陷入数据库。

3）

这是一种拦截用户发送的SQL语句的中间件。首先，它对SQL语句执行一些特定的分析：例如分片分析，路由分析，读取和写入分离分析，缓存分析等，然后将此SQL发送到后端真实数据库，并适当处理返回的结果，然后将其返回给用户。缺点是它需要建立一组中间件作为拦截器，并且需要自己操作和维护它，这相对昂贵。

4）-JDBC

由首先启动的开源库组件现已成为一个项目，分为-JDBC和 - 。开源社区很活跃。我们使用轻巧的-JDBC，可以编写支持精确碎片，范围碎片，复合碎片和自定义提示碎片的算法。配置方法支持XML，YML和Java API方法。它基本上可以解决我们所有的库和表要求。我们将库算法包装到JAR软件包中，以便于使用。要配置，我们使用YML。在使用过程中，您需要组合DAL的钥匙。代码示例如下：

2.3.2前系统设计

会计位于整个会计系统的顶部，并提供标准交易界面，包括存款，存款退款，撤回，撤回，授权，转移和批处理接口。

2.3.2.1标准交易接口

集成之前的旧系统都是所有面向业务的接口。随着业务的持续迭代，添加了越来越多的接口，尚不清楚责任，并且代码重复，这为维护带来了很多工作。例如：将现金提取界面分为个人现金提取，现金提取，商人现金提取和有针对性的现金提取。另外，原始子账户的交易顺序是硬编码的。如果子账户增加交易顺序的增加或变化，则复杂性将成倍增加。

经过研究，我们发现会计处理具有共同的特征，并且可以提取属性以进行交易顺序和原子交易类型。因此，我们构建了场景代码模型。

首先，我们定义子帐户ID，并仅按帐户类型 +货币 +业务类型来定义子帐户。

其次，根据产品代码 +事务类型定义事务订单，交易订单与子帐户ID相关联，该子元ID设置为默认场景代码。只要在接口中传递产品代码和事务类型，就可以遵循默认方案代码。

第三，我们支持商家自定义场景代码。我们维护一个后端管理系统，该系统允许商人自定义场景代码。通过审查后，接口可以将场景代码编号传递到场景代码编号中，然后可以遵循您定义的场景代码。

2.3.2.2异步

我们的接口都是同步接口。为了减少同步响应时间，辅助工作是通过MQ异步处理的。例如：转移的转移方已存放，转移已转移到会计等。

2.3.2.3数据库策略

除了支持自己的付款业务外，它还支持将会计系统导出到其他总线。为了避免数据许可和相互影响，我们进行了数据隔离。应当指出，仅使用数据隔离，并且系统还使用相同的集合，并且不执行隔离，从而有助于释放，操作和维护。数据隔离分为两层，第一层是区分自己的/bu。第二层是特定的库。

还有两组库，库和交易库。库存中请求的流量号与前流数之间的关系。交易库存存储所有交易信息。特别是，我们将反交易和原始交易放在同一DB中，这有利于控制反交易和原始交易。

首先，我们使用请求流量编号来执行哈希算法并将其分配给数据库。 DB仅保存所请求的流量号和前流数字之间的关系。 DB也分为库。拆分商店的数量最初是固定的。将来，可以使用一致的哈希算法扩大容量。

我们的交易表通过权重配置分为库，可以通过权重来自由分配数据。 DB支持友好的容量扩展，下线和故障转移。我们有一个故障转移解决方案。如果在碎片中发生例外，我们将抛出付款监控系统。监视系统将具有一组智能算法，该算法将实时监视，并在达到阈值后自动触发碎片。

2.3.2.4例外处理

在高并发方案中进行的例外处理一直是各方研究的主题。为了适应高并发方案，预安装进行了以下例外处理：

1）意外机制：所有界面都支持透视操作。

2）重试机制：从接口中重试的内部呼叫，工作补偿重试和上游也可以启动同一请求消息的失败重试。

3）查询机制：所有接口都编写了一组查询接口，并且上游可以通过查询接口检查交易的最终状态。

4）通知机制：支持积极通知上游成功/失败结果的机制。

2.3.3原子系统设计

在原子系统的过程中，主要有以下步骤：订单参数预处理，订单除法，同步执行程序，异步执行程序，后处理，最后包装参数返回。为了促进业务扩展和系统维护，在订单部门和执行零件中，系统体系结构采用了订单部门设备，具有责任链模型；代理执行订单划分，生成订单，然后通过同步执行器和同步执行器执行该订单，并由系统自动注册。目前，仅订单注册簿是异步完成的，并且任务将在随后的工作系统中得到相应的补偿。

下图是原子系统的系统体系结构图：

定制参数预处理零件以根据不同的呼叫区域进行验证和信息结构。

这是订单的一部分。由于原子系统负责管理帐户余额并且没有任何业务逻辑，因此可以将会计模型抽象以满足不同的业务需求。会计模型包括帐户帐户和帐户（），活动帐户和帐户（），基金冻结和融化（基金），每日注册簿帐户和帐户（），订单注册帐户和帐户（）等，以添加了有效性期概念的帐户，添加了注册簿管理。每日注册簿总结了帐户中同一有效期的资金。订单注册簿是有效期资金订单维度的记录。

主要负责会计的同步执行人，资金被冻结和融化以及每日注册书处理；负责订单注册书的会计操作的异步执行人。每日注册书采用同步执行，成功的每日注册书可以确保成功的订单注册簿。因此，订单注册书采用异步会计，以确保成功的会计并减少系统同步处理的时间。

后处理部分将向系统发送帐户消息，以关心帐户余额的变化，例如风险控制。

2.3.4会计系统设计

会计系统由双重核算完成，该会计系统可以清楚地描述资金来自何处和流向何处，并涉及不同企业的不同清算规则。可以在清算规则中配置不同的会计策略，例如单一和摘要会计等。

对于相同业务的多个帐户的方案，请添加扩展配置以实现清除规则的动态帐户动态。

2.3.5日末系统设计

2.3.5.1为什么您需要每日最终系统？

1）提供会计系统支持

为了确保会计系统可以正常运行，会计余额必须100％准确。影响会计系统稳定性的主要因素如下：

2）提供公司融资的摘要会计凭证

会计系统记录业务帐户，这些帐户是整个企业的财务数据的一部分，需要合并到公司的大型金融系统中。

每日最终系统处理并将会计条目映射到大型财务条目中，然后总结它们直接连接到 ERP总分类帐。

2.3.5.2一天结束时系统完成了什么

1）生成快照

截至一天清晨，所有帐户的快照被计算在内。

2）生成帐户

基于快照生成帐户共享帐户。

3）产生总分类帐

一般帐户分类帐是根据输入流生成的，帐户金额和余额是从最后一个帐户到第一级帐户的总结。

4）总分类帐余额检查

余额支票：第一级借方帐户余额=第一级信用帐户余额；

金额余额检查：第一级帐户借记的金额=第一级帐户信用的金额

5）总分验证

一般帐户的余额等于帐户帐户的余额。该业务每天24小时运营，帐户中的余额正在不断变化。在验证期结束时，不可能准确地获得帐户余额。余额快照用于验证总分类帐帐户的余额。

6）审核细节

检查详细帐户和输入流是否一致。对于同一天有余额变化的帐户，昨天的余额与入口流的数量不同，并检查计算的余额是否与快照余额一致。

2.3.5.3日末系统遇到的挑战

1）24小时会计

在银行帐户系统中，有许多用于24小时操作的解决方案，例如切换余额，记录不同的帐户帐户并在每日切割后补充流量等，但是无论哪种解决方案，它都无法实现全面的24小时操作。

主要问题是需要在一天结束时检查总分数，并且帐户的余额正在不断变化，因此我们需要找到一种方法来撤回该期限结束时验证帐户余额的方法。

一天结束的系统解决方案使用余额快照与总分类帐进行检查，因此，即使更改了帐户的余额，也不会影响总分的验证。

2）生成帐户快照

有两种生成快照的方法：

与数亿个帐户相比，每天进行的交易要少得多。动态帐户摘要的方法用于为数据库提供更少的操作和更快的处理时间。

3）复杂的过程和困难测试

根据业务边界，每日最终任务模型被抽象并分为多个子任务：快照生成，帐户部门生成，总账生成和其他子任务，并在任务工厂自动注册以进行编排和呼叫。

2.4摘要

该系统的业务访问规则和会计清算规则均基于配置，并且在业务发展中的新帐户类型，服务，货币，机构等日常更改可以基于配置。

一

3。后记

迄今为止，会计中间平台的构建已经完成。这只是中间平台构建的第一步。随后的计划还包括分布式交易和热门帐户处理；如何使新机构更简单的业务访问等。