数据服务背后的产品技术-数据服务技术

数据服务背后的产品技术

为了快速支撑不同业务对数据服务的需求，数据服务有多种生成方式，通过选取合适的生成方式，快速生成适合业务的数据服务。常见的数据服务生成方式如下。

标签服务化:对接标签管理，快速选取所需的标签，通过配置输出满足业务场景的数据服务实现标签服务化。这种生成方式主要面向业务人员，不需要具备技术基础就可以快速将数据以服务化的方式提供出去。
自定义SQL服务化:通过把自定义SQL脚本封装成服务的方式，直接将数据变为一种服务能力对外输出，实现自定义SQL服务化。在一些对服务灵活性有较高要求的场景下，一般会选择对接数据源并通过自定义SQL的方式来实现 API，这对于服务的开发者有一定的SQL编程要求，并且需要对数据库存储有一定的认知。
算法模型服务化:对接算法模型，通过部署算法模型的方式输出模型服务，实现算法模型服务化。将算法人员实施的算法模型快速进行工程化、服务化实现，让算法人员不具备工程化能力的企业也具备算法工程化的能力，快速将算法技术赋能业务。
注册API服务化:企业还有一些特殊的API，也需要统一管控，支持将企业已有的API注册到数据服务进行统一管理和输出，实现注册API服务化。统一企业的服务出口，统一托管API，形成企业服务能力中心。

对API服务提供完整的生命周期管理，可以大大降低日常维护成本，包括 API服务的新建、维护、上线/下线、授权、监控等。数据服务的生命周期全链路管理主要分为以下几个阶段。

服务的创建前提是已经明确该服务的使用场景，是用于报表分析、活动定向人群投放还是用于金融交易风控，抑或其他，只有明确了该服务的应用场景，解决何种问题的目标，才能明确创建服务时选择哪种服务组件。

另外，在服务组件的选型完成后还要考虑服务部署的环境，部署环境分为本地机房服务器环境、云服务器环境、远程Docker仓库环境等。准备工作就绪后，即可创建一个服务，服务创建时底层会将该组件包部署在所选择的环境中，一旦部署完成，平台上即可查看到服务的成功运行状态、部署过程日志、服务相关详情信息等。

服务在部署完成后，仅服务的创建者有权直接使用该服务，其他用户必须经过授权才能访问。

服务在经过创建、部署、授权后，可以正常运行使用，在运行使用的过程中需要有自动化的运维监控机制来保障服务状态正常。服务正常运行时需要能够监控记录服务的运行时长、历史出错频率等重要参考信息，这样，一旦服务出现故障，自动化运维监控机制可以及时告警通知相关人员，从而尽量减少故障带来的损失。

服务部署并投入使用后，并不是一成不变的，中间可能会存在组件升级、数据异常重配、环境缩扩容等情况，此时需要对服务进行更新升级。

服务到期或者不需要使用时，需要终止服务并将服务下架，此为该服务的生命周期最后阶段。