美利财务平台架构演进

说在前面

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

财务平台在美利1年多的时间通过了2次平台架构的演变，中间也遇到了这样那样的架构、技术的问题，今天整理了下，但愿能够给予你们一些启发。

 

架构演变

财务平台总体架构图

业务处理流程

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

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

 

财务平台V1架构

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

 

项目背景

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

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

 

应用架构为何采用单体模式？

单体模式架构有不少好处

一、        代码共享

二、        易于测试

三、        容易部署

 

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

没有完美的架构只有最合适的架构，架构都是根据业务变化一步一步演变而来，不然有可能致使过分设计拔苗助长。

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

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

为何要采用存储过程

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

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

3. 减小网络消耗。

4. 版本迭代比较快，只专一开发SQL就能够，开发、测试比较方便。

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

 

财务平台V2架构

架构1.0有哪些很差的地方呢

单体应用架构模式的弊端

一、        不够灵活

二、        妨碍持续交付

三、        受技术栈限制

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

 

存储过程有哪些很差的地方呢

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

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

所以在架构2.0中咱们对利息计提进行了服务化，替换掉了所有的存储过程，演变为服务化架构模式。

 

财务平台V3架构

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

 

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

一、        服务以前仍是耦合到一块儿的，没有真正的解耦

二、        数据库仍是耦合到一块儿的

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

四、        一些服务是耦合到一块儿的不能作到真正的独立部署、升级、替换，帐务服务是一个服务包括台帐、明细帐、凭证

 

所以基于如今的服务化架构还须要进一步服务化，达到微服务化的目的，财务平台采用的技术栈是spring cloud。

 

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

一、        更便于开发、不一样开发分工协做、持续交付

二、        应用启动更快

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

四、        理论上不受限制于技术栈，只要服务以前通信协议达成一致便可。

 

数据库采用了读写分离

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

 

微服务化后面临的问题

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

 

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

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

 

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

 

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

 

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

 

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

一、        业务数据治理、操做所有线上化。

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

三、        帐务处理彻底自动化。

 

说道最后

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