1.基于业务数据服务的业务模型通常有很多，导致系统架构和业务复杂，不同的业务有各自的能力和复杂度在一定程度上，数据管理本身并不是一件容易的事情，所以在系统架构初期会考虑服务能力的业务场景：API服务：基于Http方式的数据服务，通过请求获取数据，比如风控模型，评分、反欺诈等业务；平台服务：综合服务能力集成体系，客户定制化服务需求低，全流程数据服务能力，如自动化数字营销平台，为营销提供全流程管理能力；采集服务：通常客户以埋点的方式提交相关点击事件，采集系统基于全渠道进行汇总分析并反馈给客户；可视化分析：这里分为两个部分，数据分析和可视化，数据可以加载到多个数据源的联合分析，基于前端组件做高度自动化的分析，比如常见的数据洞察系统；工具私有化：基于积累的技术能力，直接向客户销售数据管理系统，部署在客户自己的本地服务上；数据服务场景，不同的业务需要各自场景的数据支撑，但是不同的业务需要的运营、结算、订单等基本功能是相同的，要理解不同的业务场景，需要找出共性和差异性。很简单的想法：相似点在共同的服务中开发，不同的业务点在独立的服务中开发，便于系统的不断扩展和演进。2、不同业务层架构的数据服务能力，最大的区别在于需要依赖核心数据的支撑。从业务层面看系统架构层，他们也需要复杂的、公共的功能。这些都需要在架构的早期就考虑到，否则业务发展很快就会面临重构的问题。客户运营：每个客户的接入都需要一套完整的流程、服务描述、计费规则、合同管理、充值、服务开通和停用、账单等一系列配套功能。通常有两个入口：客户登录端、服务器操作端。支付结算：功能最复杂的系统模块，提供支付能力，如聚合多个支付渠道解决客户的充值退款，或服务商自身的支付需求，提供数据输出和各类结算账单的对账能力帐户。订单管理：客户的每一个请求，或者每一项服务的使用，都需要详细的订单记录来进行计费行为，涉及单价、订单号、时间等诸多关键因素。作为结算的核心依据，也是业务数据最集中的地方。权限系统：在数据服务系统中，权限系统的设计更侧重于解决公司主体的需求。不同的业务团队负责不同的业务运营、客户管理等，因此需要清晰、系统的权限管理，给不同角色的业务人员分配合理的权限。日志集成：在详细的日志系统中，正常的业务日志数据可以在业务异常时进行数据补全分析，异常的日志数据可以供开发者分析系统问题和瓶颈，持续优化业务能力。基于业务场景的服务划分和设计，以及公共服务的基础构建，保证了业务层结构的合理性和可扩展性。如果服务能力不断丰富，系统改造成本很小，自然结构合理。3、数据中心不同的业务服务场景需要依赖核心数据能力，这是服务的卖点。通常，支撑业务能力的核心数据是单独部署的，提供各种业务场景。通常理解为数据中心。同时，业务服务本身也会产生各种数据，这些数据会根据服务的部署方式独立存储。服务能力：数据中心作为多个业务的公共依赖，不仅需要提供基于数据的查询能力，在处理海量数据任务时，还需要提供一定的调度和计算机制。部署方式：根据数据的特点，通常采用集群、分库分表、OLAP引擎、数据仓库等多种方式存储，并根据数据的特点提供统一的服务能力和对业务层开放。数据更新：数据需要实时或定期更新。数据的来源通常是大数据计算处理后的各种数据，以及业务层验证不正确的数据，或者是在使用过程中不断优化的数据。数据中心的独立架构部署是非常必要的操作。大多数数据是关联的。数据之间的联动处理，完全不需要耦合到业务层面。数据流校正安全管理可以在数据中心完成。统一管理，避免了数据混合部署带来的一系列复杂问题。4.大数据数据服务能力底层需要海量数据处理能力的支撑，因此很多大数据组件技术被用来存储、计算、分析和传输数据。数据存储：大数据底层最常见的存储形式是文件、结构化数据库存储、半结构化日志文件和一些非结构化数据。计算能力：海量数据的处理需要依靠各种并行计算、离线任务、实时计算等方式来达到快速处理的目的。数据处理：数据处理完成后，不直接提供底层服务能力。通常，数据同步到上层数据中心，为业务提供服务能力。这里的handling可以是数据输出，也可以是待处理的数据输入。大数据的底层组件是系统的核心能力。数据的精确计算和分析保证了服务的能力，对现有架构的持续自动化和工具管理非常重要。海量数据管理的过程越来越人工化。越多意味着效率越低，尤其是在向数据中心推送数据或者底层接收数据的过程中，需要约定一个策略来保证数据安全稳定的自动传输。5.统筹考虑对于一个复杂系统的设计，首先也是最重要的就是要清晰梳理业务模型，分析业务模型，根据业务特点制定系统架构可以少走很多弯路，比如以上数据服务体系：首先，从大的层面来看，系统将业务服务、数据中心、大数据底层能力拆分为三大块，要求各大模块之间不存在强耦合关系，以保证模块可以独立扩展；其次，确定每个模块的要求。实现核心功能，业务层保障基础服务能力，然后抽取封装各个业务需要的基础功能，拆分出业务服务和公共服务，支撑业务能力；然后确定模块之间的协作方式，例如业务与数据中心的通信能力、接口标准、数据安全等细节，或者数据中心与底层大数据之间的数据传输方式，以保证数据的安全。流通能力；最后，这里需要考虑每个模块的具体实现细节。根据业务模型，如果可以选择相同的组件和架构，尽量统一架构选择和组件依赖，减少不同模块之间的壁垒；上述完整的系统架构从开始到提供稳定的服务能力大约需要七个小时。在此期间，将不断演进升级，不断推出新的服务模块，对系统进行监控，直至业务服务相对完善，系统相对稳定。6.源码地址GitHub地址：Cicadasmilehttps://github.com/cicadasmile/spring-cloud-baseGitEE地址：Cicadasmilehttps://gitee.com/cicadasmile/spring-cloud-base
