作者|晓峰，携程研发总监，专注于分布式数据库研究，大数据领域的实时计算和大数据应用的系统架构设计。背景随着携程酒店数据的膨胀和个性化需求的增加，各个数据接口的个性化行程开发，由于没有标准化，需要在需求讨论、数据准备、接口打包、在线调试、接口api等过程中花费描述。充足的时间。从实现一个接口到上线至少需要2天或更多时间，这个时间成本要看开发进度；随着历史接口的迭代，已经对外提供的700多个数据接口中有500多个还在使用，每年增量100多个，开发维护成本高，尤其是追溯的时候上游离线数据逻辑，过于依赖研发资源；不同的研发团队有不同的技术栈，算法相关的研发更偏向python开发，对外输出接口也是用python实现的，但是公司的框架对java接口的支持比较友好，对外输出的稳定性不同技术栈的接口值得怀疑，尤其是在人员流动和团队职责变化也会影响维护成本之后；随着业务的发展，各种业务系统的数据需求越来越大，需求响应要求也越来越高；通过对历史接口的分析和分类，80%以上的数据接口实际上是针对离线数据或者实时数据加需求方的检索条件可以返回数据，没有过多的处理逻辑或者过于复杂的业务逻辑实现在界面;为了更快的支持个性化业务需求，降低研发成本，起到降本增效的作用，同时避免烟囱式数据接口的开发，提高数据复用率，避免同一个数据同一个多个接口，并避免不同的研发团队获取相同的数据在各自场景的数据接口上工作，减少数据孤岛的情况。为此，我们设计了满足需求的数据服务平台。一、平台介绍统一数据服务平台建立在公司的soa服务的基础上。平台实现统一的技术方案，降低运营成本，提高接口稳定性、可维护性和连续性；运维配置降低数据接口实现成本，从2d+个性化开发到4h甚至更快上线，这种实现基本可以不严重依赖资源调度；通过统一的数据服务平台可视化界面配置，不依赖java开发人员的介入，可以由数据仓库团队生产的hive表，根据需求配置界面输出；统一数据源，保证数据使用的一致性；为请求方的应用接口提供标准模板，提高沟通效率和需求方对大数据需求的满意度。系统级架构图：接口应用配置流程如下：2.如何实现2.1平台关闭减少数据接口输出团队及技术方案；另外，随着业务量和数据量的增加，业务类型的积累，目前的接口还没有完全支持mysql，平台统一规划了技术方案。调用者不需要关心底层服务使用什么数据库如clickhouse、es、starrocks、redis，以及相关数据库的技术特点和语法特点。在实际配置中，我们需要结合调用方的场景以及不同olap数据库的特点和优缺点进行选择；例如：ES：核心、高并发非KV结构搜索场景；Redis：核心，高并发KV架构场景；MySql：核心，千万级以内小表简单查询，高并发场景；starrocks：分核，QPS不是很高，单表数据量在千万级、亿级场景；ClickHouse：非核心，QPS在100以内，数据量在千万级或亿级场景；trocks/Hbase：非核心KV结构场景；同时，对于不同的数据库，更新机制也需要我们注意哪些适合全量更新，哪些适合增量更新；2.2提高数据利用率。只要表已经同步，下次在其他业务场景使用时，可以通过配置不同的查询sql，对外提供一些数据。通过血缘关系的监控，可以减少离线数据的重复同步，提高数据的副本。应用面，从而提高数据的可用性和一致性，允许数据重用而不是复制。2.3接口安全验证每个调用者appid都需要提前申请某个接口的应用权限。统一服务平台通过授权token的方式验证appid+token的权限，防止未申请接口权限的应用非法调用。appid通过公司soa框架自动获取，避免appid被篡改，保证接口数据的安全稳定。2.4限流保护在高并发系统，尤其是统一服务平台，流量控制非常重要。当一个接口由于外部爬虫导致流量超过设定的阈值而未被阻塞时，可能会导致整个平台对外输出接口不可用。为此，我们引入了Sentinel限流机制。Sentinel是分布式服务架构的轻量级流量控制组件。它主要以流量为切入点，从限流、服务降级、系统负载保护等多个维度帮助我们保障服务的稳定性。实现原理是在指定时间内生成预先配置数量的token，每次请求都会消耗一个token，领取token后拒绝服务。目前每个接口名称都会有一个独立的token，接口之间的流量限制不会互相干扰，实现每个接口的流量控制，当qps超过设定的阈值时，接口会自动熔断。2.5数据缓存接口的配置信息，持久化保存在硬盘中，接口调用时会被频繁使用，如何快速高效的获取这些配置信息需要使用缓存机制。通过建立主动和被动缓存来避免高服务器负载。定期缓存数据源的配置信息，无需初始化即可在接口使用时快速调取基础数据。2.6通过本平台调用的接口统一服务合约，现在所有的请求都通过一个入口完成。接口收到请求后，会根据接口的配置信息自动进行卸载处理。请求合约包含两部分，head和params。head负责接口的基本信息，用于服务验证和业务中转。params参数是一个json字符串参数对象，服务会根据json信息和配置信息的匹配动态解析参数。响应契约包括接口成功标志和结果部分，其中result是一个json的字符串参数对象，需要调用方接收后进行解析。请求如下图：响应如下图：2.7数据服务配置与映射一个服务接口由数据源、sql语句、请求参数和响应参数组成。其中，sql语句中的参数替换为？和{序列号}占位符，与请求参数一起使用。sql有多少参数占位符，就需要配置多少个请求参数。接口运行时，会根据请求的参数自动进行匹配。在sql参数中。响应参数为了映射查询结果中的字段，可以将sql查询的输出结果通过映射转换为想要的输出参数。配置的响应参数是接口服务返回的查询结果。下图为配置sql的查询方式：2.8开发个性化接口，自动生成合约文档，需要对接口进行解释，告知调用方如何调用。结合接口输入输出参数自定义的特点，定义了一套服务文档展示模板，该文档包含调用接口的所有详细信息。只要定义接口，就会动态生成合同文档，申请服务的团队通过邮件发送信息，节省接口解释成本。文件在线效果如下图所示，同样会通过邮件发送给申请人。2.9服务监控服务接口正常运行后，使用公司的clog和ck日志框架监控接口调用情况。Clog监控主要是记录从调用开始到请求接口返回的所有流程记录，包括每个流程节点的调用时长、请求参数和返回参数。方便定位接口请求的整个链接。ck监控主要是记录接口层请求的参数，返回的参数和响应时间。每个请求只记录一次，统计可以监控每个时段的调用次数，接口响应时长等信息。2.10生产运营效果自2021年12月上旬上线以来，目前已接入10个调用端appid，提供100多个接口服务。请求数随着接口的增加而增加，目前每天的请求数超过390万。每个接口的在线时间为半天或更短。接口上线后，只需根据需求方进行配置，即刻上线即可使用，大大缩短了上线周期。91.49%的生产接口响应时间在10ms以内，99.99%在100ms以内。3.未来展望现在所有接口都部署在一个集群中。对于一些调用者，我们其实可以区分高、中、低级别，将优质调用者部署在一个独立的集群上，中级调用者部署在一个集群上，低优化的调用者部署在独立的集群上，资源相互隔离。打开测试环境。因为大部分大数据环境只有生产环境，没有测试环境和测试数据，所以统一服务平台现在只能在生产环境使用。开发环境或测试环境无法调用联调，调用者只能通过mock方法进行测试。这也是我们需要考虑如何用最低的成本来实现测试环境的可用性，让调用者更方便的使用。
