本文源码：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 根底】

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