架构设计:数据服务系统0到1落地实现方案

02/24 08:00
阅读数 19
基于业务场景做好服务的划分和设计,以及公共服务的基础构建,确保业务层的架构合理且可扩展,是否合理的基本考量就是,不断的新增业务场景是否需要做系统的大刀阔斧的改版,如果服务能力不断丰富,系统的改造成本很小,自然架构合理。

本文源码:GitHub·点这里 || GitEE·点这里

一、基于业务

数据服务通常有很多种业务模式,也就导致系统的架构与业务都会很复杂,不同的业务都具有自身的能力和复杂度,数据管理本身就是一件不容易的事情,所以在系统架构初期都会考虑服务能力的业务场景:

API服务:基于Http模式的数据服务,通过请求获取数据,例如风控模型,评分,反欺诈等各种业务;

平台服务:综合性的服务能力集成系统,客户的自定义服务需求很低,具有完整流程的数据服务能力,例如自动化数字营销平台,提供营销的全流程管理能力;

采集服务:通常客户以埋点的方式提交相关点击事件,采集系统基于全渠道进行汇总分析并向客户反馈;

可视化分析:这里分为两大块,数据分析与可视化,数据可以加载多方数据源联合分析,基于前端组件做高度自动化分析,例如常见的数据洞察系统;

工具私有化:基于积累的技术能力,把数据管理的系统直接销售给客户,部署在客户自己本地的服务上;

数据服务的场景,不同的业务需要各自场景下的数据支撑,但是不同的业务都需要相同的运营,结算,订单等基础功能,理解不同的业务场景,需要找出共同点与不同点,很简单的思路:相同点在公共服务中开发,业务不同点在独立的服务中开发,方便系统的不断扩展与演进。

二、业务层架构

不同的数据服务能力,最大的不同点就是需要依赖核心数据的支撑,从业务层面看系统架构层,还需要的功能复杂公共功能,这些需要在架构初期就考虑好,不然随着业务发展很快就要面临重构问题。

客户运营:每个客户的接入都需要一套完整的流程,服务说明,计费规则,合同管理,充值,服务开通停用,账单等一系列配套功能,通常都有两个入口:客户登录端,服务方运营端。

支付结算:功能最复杂的系统模块,提供支付能力,例如聚合多个支付渠道,用来解决客户的充值退款,或者服务方自己的支付需求,并提供各种结算账单的数据输出,对账平账能力。

订单管理:客户的每次请求,或者每个服务的使用,产生的计费动作都需要详细的订单记录,涉及单价,单号,时间很多关键因素,作为结算的核心依据,也是业务数据最集中爆发的地方。

权限体系:在数据服务体系中,权限系统的设计更侧重解决公司主体层面的需求,不同的商务团队负责不同的服务运营,客户管理等,所以需要清晰的体系化权限管理,给不同的角色的商务人员分配合理的权限。

日志集成:在详细的日志体系中,正常的业务日志数据可以用来在服务异常时的数据补全分析,异常的日志数据可以给开发用来分析系统问题和瓶颈不断的优化服务能力。

基于业务场景做好服务的划分和设计,以及公共服务的基础构建,确保业务层的架构合理且可扩展,是否合理的基本考量就是,不断的新增业务场景是否需要做系统的大刀阔斧的改版,如果服务能力不断丰富,系统的改造成本很小,自然架构合理。

三、数据中心

不同的业务服务场景需要依赖核心数据能力,这是服务卖点,通常会把支撑服务能力的核心数据单独部署并提供各种服务场景,通常理解为数据中心,同时业务服务自身也会产生各种数据,这里会根据服务的部署方式独立存储。

服务能力:数据中心作为多个业务公共依赖,不但要提供数据基础的查询能力,在处理海量数据任务时,还需要提供一定的调度和计算.........

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部