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

一、基于业务

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

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

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

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

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

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

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

二、业务层架构

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

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

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

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

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

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

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

三、数据中心

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

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

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

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

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

四、大数据底层

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

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

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

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

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

五、整体考虑

对一个复杂系统的设计，首先最关键的就是清晰的整理出业务模式，对业务模式进行分析，根据业务特点做系统架构可以避免很多弯路，例如上面的数据服务系统：

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

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

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

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

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

六、源代码地址

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

阅读标签

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

【分布式架构】【微服务】【大数据组件】【SpringBoot进阶】【Spring&Boot基础】

【数据分析】【技术导图】【职场】

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

中信信用卡核心升级应用数据服务系统
整体架构图 data-azkaban-web 前端页面 data-azkaban-web-back 后台数据控制端,执行状态刷新等等. data-workflow-mgmt 定时任务基于springb ...
写代码犹如写文章: “大师级程序员把系统当故事来讲，而不是当做程序来写” | 如何架构设计复杂业务系统? 如何写复杂业务代码？
写代码犹如写文章: "大师级程序员把系统当故事来讲,而不是当做程序来写" | 如何架构设计复杂业务系统? 如何写复杂业务代码? Kotlin 开发者社区 "大师级程序员把 ...
怎么用vc采集ni卡数据_SystemLink自学笔记（6）：SystemLink架构和数据服务
1. SystemLink架构和数据服务 1.1. 架构和特点现在在对SystemLink的功能有了一个大概的了解后,可以进一步从它的整体架构学习这门新技术了.NI官网给出了白皮书,原文是英文资料, ...
后台架构设计—数据存储层
后台架构设计-数据存储层来源:http://www.cnblogs.com/xiwang6428/p/6060138.html 数据存储重要性: 数据是企业最重要的财产: 数据可靠性是企业的命根,一 ...
亚马逊光缆被挖？——阿里工程师讲解支付宝如何架构设计数据中心
文: 周瑜校对:李二全文2500字,建议阅读时长7分钟点击右上角关注我们,每天都能收到有趣的推文哦. 亚马逊光缆被挖?--阿里工程师讲解支付宝如何架构设计数据中心昨天科技圈最火的新闻应该是&q ...
架构师实战培训（架构设计+数据后台+快速开发+二次开发+发布部署）
架构师实战培训(架构设计+数据后台+快速开发+二次开发+发布部署)系列视频课程课程目标学习MIS系统.高并发系统.单机系统设计思路: 理解设计模式,学会命令模式: 适用人群 CIO.CTO.技术总 ...
架构设计第三步：评估和选择备选方案
上一期我讲了设计备选方案,在完成备选方案设计后,如何挑选出终的方案也是一个很大的挑战,主要原因有: 每个方案都是可行的,如果方案不可行就根本不应该作为备选方案. 没有哪个方案是完美的.例如,A 方案 ...
【架构设计】服务治理理论（一）
1. 前言微服务架构下,会引入很多服务问题,所以少不了需要做服务治理,包括:服务注册与发现.服务配置.服务限流.服务熔断.服务降级.负载均衡.链路追踪等. 关于服务治理的范畴应该包括哪些,业界其实也 ...
架构设计-数据访问层简述
在前面简单描述了下服务层,SOA面向服务架构,架构设计-业务逻辑层,以及一些面面向设计原则理解和软件架构设计箴言.这篇博客我们将继续进入我们的下一层:数据访问层.无论你用的是什么开发模式或者是业务模式 ...

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