说在前面

本文转自“天河聊技术”微信公众号

财务平台在美利1年多的时间经过了2次平台架构的演变，中间也遇到了这样那样的架构、技术的问题，今天整理了下，希望可以给予大家一些启发。

架构演变

财务平台整体架构图

业务处理流程

财务平台是和美利的大数据平台、用友NC系统进行合作来完成整个财务的账务处理过程的。

大数据平台把对接财务平台的业务系统，如公司新核心、资产、负债、结算、支付等业务系统的mysql数据库数据通过sqoop抽取到hive中进一步转换成财务业务数据口径数据推送到财务平台接入服务数据库中，再由财务平台的批处理服务拉起台账转换的任务进行集群全服处理后，财务人员进行台账数据核对后创建明细账，在进行明细账核对后创建凭证数据，再把凭证数据推送到用友NC服务系统，财务余额管理、总账管理、相关财报管理有用友NC系统来实现。

财务平台V1架构

1.0应用架构采用的是单体模式，数据库架构采用的是分片架构

项目背景

技术的应用架构、数据架构一定是为业务架构服务，脱离业务只谈技术架构是纸上谈兵。

为了尽快满足业务需求，财务组面临财务业务专业、复杂，数据量巨大这样的问题，就要求开发要很懂财务业务知识、对海量数据处理的相关技术要熟悉、甚至要精通，代码性能要很好，财务平台从0到1搭建、财务组团队也是从0到1搭建，因此面对这样的客观原因，要快速落地财务平台，对财务平台灵活性（如会计科目、事务处理规则、会计规则配置灵活配置化）、扩展性（抽象出来事务处理规则引擎、会计规则引擎、计费引擎、账务处理引擎）、账务处理性能（能吞吐海量数据）都有很高的要求，因此更急切的架构是数据库架构要能抗住这么大的数据量，因此采用了数据库分片架构，数据库架构由我的上级阿兵主刀，感谢阿兵，到现在财务平台已经到了平稳运营阶段，抗住了第一次业务历史数据亿级别数据结账以及到现在的单日业务数据量500W左右、月账务处理数据量在5000W左右的一个体量。

应用架构为什么采用单体模式？

单体模式架构有很多好处

1、        代码共享

2、        易于测试

3、        容易部署

因此如果需要从0到1快速落地一个项目这种应用架构方案是不二选择，虽然财务平台采用的是单体模式架构，但是财务平台模块设计是以微服务架构设计模式的，为后期的微服务化架构落地打下了坚实的基础。

没有完美的架构只有最合适的架构，架构都是根据业务变化一步一步演变而来，否则有可能导致过度设计适得其反。

面对这么大的数据量财务平台采用了分片架构模式，中间件采用的是sharding-jdbc，这个框架财务平台用的是1.5版本，基于client的实现jdbc规范的一个增强数据库驱动，比较轻量级，目前财务平台对其进行了一部分定制化开发，现在已经很稳定。目前的账务处理流程是写大于读的场景，因此这个架构版本中是没有考虑读写分离的。

在架构1.0版本中利息计提服务是采用的存储过程逻辑来实现。

为什么要采用存储过程

1. 存储过程可以更好的进行模块化设计。

2. 执行更快，如果一个SQL要大量、重复执行、存储过程要比SQL快的多。

3. 减少网络消耗。

4. 版本迭代比较快，只专注开发SQL就可以，开发、测试比较方便。

这种数据库架构方案也是为了快速落地。

财务平台V2架构

架构1.0有哪些不好的地方呢

单体应用架构模式的弊端

1、        不够灵活

2、        妨碍持续交付

3、        受技术栈限制

4、        技术债务，代码耦合，牵一发而动全身

存储过程有哪些不好的地方呢

1、        执行进行SQL级别的数据库优化

2、        运行在mysql服务器端，数据量大的话会造成数据库服务器io、cpu性能消耗，无法进行优化，在mysql环境下不同的应用服务的数据库在一台mysql实例上，一个数据库的存储过程把数据库服务器资源都占用，对其他应用服务来说无疑是一场灾难。

因此在架构2.0中我们对利息计提进行了服务化，替换掉了全部的存储过程，演变为服务化架构模式。

财务平台V3架构

为什么要做服务化、微服务化是为了达到服务高可用的终极目标。

架构2.0中服务化架构还是比较粗粒度的，那么在这个架构模式下有哪些问题呢？

1、        服务之前还是耦合到一起的，没有真正的解耦

2、        数据库还是耦合到一起的

3、        不是严格的遵循了单一职责原则

4、        一些服务是耦合到一起的不能做到真正的独立部署、升级、替换，账务服务是一个服务包括台账、明细账、凭证

因此基于现在的服务化架构还需要进一步服务化，达到微服务化的目的，财务平台采用的技术栈是spring cloud。

微服务化后带来了哪些好处呢

1、        更便于开发、不同开发分工协作、持续交付

2、        应用启动更快

3、        故障进一步隔离，一个微服务出现问题不会影响其他服务，更不会影响整个应用

4、        理论上不受限制于技术栈，只要服务之前通讯协议达成一致即可。

数据库采用了读写分离

写还是sharding-jdbc+mysql数据库集群、读采用的是elasticsearch，elasticsearch采用的是倒排索引机制，理论上比SQL查询的效率要快上百倍以上，如果想详细了解elasticsearch，请关注“天河聊技术”微信公众号，有更详细的关于elasticsearch的总结、还有其他技术的一些看法。

微服务化后面临的问题

最大的问题就是分布式数据一致性的问题，目前财务平台采用TCC实现的强一致性事务。其他一些问题spring cloud生态体系基本上解决或者加以定制化。

财务平台业财一体化架构的一些思考

财务平台现阶段来说是一个后知的系统。

对接财务平台的系统之多、业务场景之多，数据治理是需要一个漫长而艰辛的过程，比如结算支付退票这种场景，线下结算的这种场景，线下还款等等业务场景，财务平台拿到的数据并非实时、完全准确的，也可能是一种业务上中态的数据，所以目前业务数据到财务平台是经过大数据平台这个桥梁来对业务数据进行统一对接，因此财务平台无法实时感知业务端的数据的，所以要达到真正的业财务一体化，决策者可以实时看到财报，财报的实时性、准确性暂时还是无法达到的，这也是财务平台未来规划要实现的，后期要把财务平台和业务数据真正的实时打通，业务系统全部线上化、财务平台进行实时记账、财务对账流程自动化、账务处理流程自动化，才能做到财报的实时性，最终也才能达到业财一体化的目的。

现在处理方案是T日抽取T-1日的业务数据来进行财务账务处理，因此数据量集中在一起对数据库的压力、服务器的压力是很大的，峰值都在一个时间区间，除了这个时间区间其他时间服务器基本上是空闲的，很大程度是这是一种服务器的资源浪费，这也是财务平台架构上要后期优化的地方。

这个架构方案目前只是一个idea，还没有进行详细规划，算是一个思路，要走到这一步是需要一个漫长而艰辛的过程。

要实现这个目标要这些事情

1、        业务数据治理、操作全部线上化。

2、        业务数据与财务平台实时打通。

3、        账务处理完全自动化。

说道最后

以上是针对财务平台的三个版本应用、数据库演变之路做了些总结，仅供参考。