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

时间 2021-02-24

标签前端 git github 算法 spring 数据库设计模式安全架构 app 栏目系统架构繁體版

原文原文链接

1、基于业务

数据服务一般有不少种业务模式，也就致使系统的架构与业务都会很复杂，不一样的业务都具备自身的能力和复杂度，数据管理自己就是一件不容易的事情，因此在系统架构初期都会考虑服务能力的业务场景：git

API服务：基于Http模式的数据服务，经过请求获取数据，例如风控模型，评分，反欺诈等各类业务；github

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

采集服务：一般客户以埋点的方式提交相关点击事件，采集系统基于全渠道进行汇总分析并向客户反馈；spring

可视化分析：这里分为两大块，数据分析与可视化，数据能够加载多方数据源联合分析，基于前端组件作高度自动化分析，例如常见的数据洞察系统；数据库

工具私有化：基于积累的技术能力，把数据管理的系统直接销售给客户，部署在客户本身本地的服务上；设计模式

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

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

客户运营：每一个客户的接入都须要一套完整的流程，服务说明，计费规则，合同管理，充值，服务开通停用，帐单等一系列配套功能，一般都有两个入口：客户登陆端，服务方运营端。app

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

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

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

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

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

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

服务能力：数据中心做为多个业务公共依赖，不但要提供数据基础的查询能力，在处理海量数据任务时，还须要提供必定的调度和计算机制。

部署方式：根据数据特色一般会以集群、分库分表、OLAP引擎、数仓等多种方式存储，并根据数据特色提供统一的服务能力对业务层开放。

数据更新：数据是须要实时或者定时更新，数据来源一般是通过大数据计算和处理后的各类数据，还有就是业务层校验有误的数据，或者在使用过程不断优化的数据。

数据中心的独立架构部署是很是有必要的操做，大部分的数据都是具备联动性的，数据间的联动处理彻底不用耦合到业务层面，数据的流动校订安全性管理等等均可以在数据中心统一管理，规避掉数据混合部署带来的系列复杂问题。

数据服务能力的最底层须要海量数据处理的能力作支撑，因此用到不少大数据组件技术，对数据作存储、计算、分析、搬运等等操做。

数据存储：大数据底层最多见的存储就是文件形式，结构化的数据库存储，半结构化的日志型文件，还有一些非结构化数据。

计算能力：对于海量数据的处理须要依赖各类并行计算，离线任务，实时计算等多种方式，达到快速处理的目的。

数据搬运：数据处理完成以后并不会在底层直接提供服务能力，一般会把数据同步到上面数据中心，在对业务提供服务能力，这里搬运能够是数据输出，也多是待处理的数据输入。

大数据的底层组件则是系统的核心能力，对数据的精准计算分析确保服务的能力，而且不断的对现有架构作自动化和工具化管理，这点很是重要，海量数据管理的流程人工介入越多则说明效率越低下，尤为在底层向数据中心推送数据或者数据接收的过程，须要约定好策略保证数据安全稳定的自动传输。

对一个复杂系统的设计，首先最关键的就是清晰的整理出业务模式，对业务模式进行分析，根据业务特色作系统架构能够避免不少弯路，例如上面的数据服务系统：

首先从大的层面看，系统拆分业务服务，数据中心，大数据底层能力这三大块，而且要求各个大模块之间不存在强耦合关系，确保模块之间能够独立的扩展；

其次肯定各个模块须要的实现的核心功能，业务层保证基本的服务能力，而后把每一个业务都须要的基础功能向下抽取封装，拆分出业务服务和公共服务，支撑业务能力；

而后肯定各个模块之间协做的方式，例如业务与数据中心的通讯能力，接口标准，数据安全等细节，或者数据中心与底层大数据之间的数据搬运模式，确保数据流通能力；

最后各个模块具体的细节实现，这里须要考量的就是根据业务模式，若是能够选择相同的组件和架构方式，尽可能统一架构选型和组件依赖，下降不一样模块之间的壁垒；

上述完整的系统架构从开始搭建到提供稳定的服务能力，大概耗时七个月的时间，期间不断的演进和升级，而且不断上线新的服务模块并进行系统监控，直至业务服务相对完善和系统相对稳定。

GitHub地址：知了一笑
https://github.com/cicadasmile/spring-cloud-base
GitEE地址：知了一笑
https://gitee.com/cicadasmile/spring-cloud-base

阅读标签

【Java基础】【设计模式】【结构与算法】【Linux系统】【数据库】