数据经过ETL、存储等数据处理过程之后，通过数据应用产品的形式呈现给最终使用方，PC和APP类数据产品以各类不同用途的数据大屏、看板将数据指标展示给管理者、运营和业务人员，数据应用后端也会为商城、CRM等业务团队开发出一些restful类型的数据接口，供他们取数使用。
数据应用层架构解析
数据应用层使用前后端分离的技术架构，后端遵守J2EE开发标准，是一套分布式系统，采用Spring Cloud Spring Boot微服务框架实现后端功能，后端服务架构如下：
Spring Boot 使用约定优于配置的理念，为分布式微服务系统提供了简单易用的编程模型，用来构建弹性、可靠的数据应用微服务系统，Spring Cloud 提供的一系列框架解决数据应用微服务架构中服务治理的问题。数据应用微服务系统整合Spring Boot和Spring Cloud组件，对外提供一套整体的数据应用微服务解决方案，这里简要介绍一下核心的微服务组件：
1、Spring Cloud ：Nacos 注册和配置中心
注册中心是微服务架构最核心的组件，它起到新服务节点信息（服务名称、IP、端口等）的注册与状态维护的作用。注册中心使用心跳机制定时检查该节点的运行状态，最大程度保证其持有的服务节点列表都是可用的。
配置中心的职责就是集中管理微服务架构中每一个服务实例的配置数据，诸如数据库连接字符串、各种用户名密码、IP 等信息均从配置中心远程下载，不再本地保存。修改配置时，服务实例自动从配置中心拉取最新配置信息，不需要重启服务实例，就能自动感知配置的变化。
2、Spring Cloud Ribbon：服务负载均衡
微服务间彼此调用时并不是直接通过 IP、端口直接访问，而是由调用者通过服务名在注册中心查询该服务拥有哪些可用节点，然后注册中心将可用节点列表返回给服务调用者，这个过程称为“服务发现”。因服务高可用的要求，服务调用者会接收到多个可用节点，必须要从中进行选择，因此在服务调用者一端必须内置负载均衡器，通过负载均衡策略选择适合的节点发起通信请求。
Netfilx Ribbon 是 Netflix 公司开源的一个负载均衡组件，属于客户端负载均衡器，运行时以 SDK 形式内嵌到每一个微服务实例中，为微服务间通信提供负载均衡与高可用支持。
3、Spring Cloud Fegin：服务通信
Netflix Feign 是 Netflix 设计的开源的声明式 WebService 客户端，用于简化服务间通信。Netflix Feign 采用“接口 注解”的方式开发，通过模仿 RPC 的客户端与服务器模式（CS），采用接口方式开发来屏蔽网络通信的细节。
4、Spring Cloud Gateway：服务网关
对于最终用户来说，微服务的通信与各种实现细节应该是透明的，用户只需关注他要使用的 API 接口即可。因此微服务架构引入服务网关控制用户的访问权限。服务网关是外部环境访问内部微服务的唯一途径，在这个基础上还可以扩展出其他功能，例如：用户认证与授权、容错限流、动态路由、A/B测试、灰度发布等。
Spring Cloud Gateway 是 Spring 自己开发的新一代 API 网关产品。它基于 NIO 异步处理，摒弃了 Zuul 基于 Servlet 同步通信的设计，因此拥有更好的性能。同时，Spring Cloud Gateway 对配置进行了进一步精简，比 Zuul 更加简单实用。
5、自建ELFK：集中式日志管理
微服务架构默认将应用日志分散保存在每一个微服务节点上，当系统进行用户行为分析、数据统计时必须收集所有节点日志数据。使用ELK、EFK组件，搭建独立的日志收集系统，定时抓取增量日志形成有效的统计报表，为决策提供数据支撑。
6、Spring Cloud ：Sentinel 服务保护
在服务间通信过程中，如果某个微服务出现响应高延迟可能会导致线程池满载，严重时会引起系统崩溃。这里就需要引入服务保护组件实现高延迟服务的快速降级，避免系统崩溃。
在 Spring Cloud 生态中有一个重要的流控组件 Sentinel。Sentinel 以流量为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性，并提供友好的UI界面对各类配置进行操作。
7、其他组件
其他组件诸如消息队列、调度组件等，在项目中按需对组件进行引入和调整即可，这里不做过多介绍。
数据应用工程分层规范
在设计架构和组织代码时，我们都会用到分层思想，分层思想是分而治之理论的体现，一些常见的软件设计原则也会在分层时使用到，比方说：
- 单一职责原则——规定每个类只有单一的功能
可以理解为每一层拥有单一职责，且层与层之间边界清晰；
- 迪米特法则——原意是一个对象应当对其它对象有尽可能少的了解
在分层架构的体现是数据的交互不能跨层，只能在相邻层之间进行；
- 开闭原则——要求软件对扩展开放，对修改关闭
它的含义其实就是将抽象层和实现层分离，抽象层是对实现层共有特征的归纳总结，不可以修改，但是具体的实现是可以无限扩展，随意替换的。
使用好分层思想和设计原则，不仅可以帮助我们设计出可扩展、可维护的软件系统，也可以帮助我们沉淀通用能力，提高开发效率，达到持续迭代、持续交付的目的。数据应用工程分层规范归纳如下：
数据应用无损上线方案
数据应用产品需求经过开发测试后，就进入上线阶段，由于这些数据应用产品是给B端或者C端用户使用的，上线时需考虑对用户访问和使用数据的影响，以下是两个上线操作对用户访问产生影响的例子:
- 上线过程中有的请求转发到了正在上线的节点导致访问超时或者访问异常
- 已有数据功能需求有了变化，后端API改变了入参，后端上线后，前端没有上线完成，这时候如果有用户访问，前端请求转发到了新接口上就会报错，从而用户看不到数据
为了保证用户的良好使用体验，我们需要采用无损上线的方案来保证上线不影响用户正常使用，整个无损上线方案如下：
小结&思考
数据应用的需求来源于业务，为业务提供数据支持，帮助业务根据数据实现决策。数据应用系统相对业务应用系统来说，数据应用产品有比较多的临时需求和短期需求，从需求提出、产品成型、成熟使用再到衰退下线，生命周期比较短，但数据的意义就在于及时性，过时的数据会让用户对数据的使用价值大打折扣。因此我们需要注重数据应用系统的可扩展性、可维护性和高可用性，需要不断沉淀通用能力，实现能力复用，快速迭代、持续交付，保证数据的快速产出，保障用户的良好使用体验。
欢迎扫码关注：
