CN110149364A - 基于数据服务平台提供微服务的方法、装置、存储介质 - Google Patents

Abstract

本发明提供了基于数据服务平台提供微服务的方法、装置、存储介质，该方法包括：在所述数据服务平台上设置API服务网关，所述微服务通过所述API服务网关访问数据库，当所述数据服务平台的访问处于瓶颈时将所述微服务拆分为多个子微服务，将所述多个子微服务之间的依赖关系及子微服务的状态生成服务编排文件，所述多个子微服务的运行状态进行监控，以确定数据服务平台的异常情况，基于所述异常情况对相应的子微服务进行熔断、限流或降级处理。本发明采用微服务架构，使得服务便于更新及复用，采用去中心化管理数据，使用统一的权限验证，并对请求进行过滤，提高了系统的可修改性、可操作性。

Description

基于数据服务平台提供微服务的方法、装置、存储介质

技术领域

本发明涉及数据处理技术领域，特别是基于数据服务平台提供微服务的方法、装置、存储介质。

背景技术

随着从IT时代步入DT时间的过程中，互联网的快速发展及信息技术的迅猛发展，数据信息技术已经成为科技信息的核心地位，从而数据服务化也成为底层数据架构的重要的环节，对于数据服务是直接面向用户群体，在数据开放，数据运营，数据使用的过程中，对数据服务输出的进行数据内容进行加密及脱敏，数据标准结构的处理，并对所有用户的数据访问行为动作进行监控、审计等，在数据服务化的运营中，保障数据有效，高效的输出高可用的数据服务，打破数据孤岛，实现数据的最大价值。

现今数据的服务化主要体现于微服务化，所谓微服务化，基于不同的技术框架实现，将数据业务逻辑进行前后端的分离，实现的技术框架有，spring boot,springmvc,dubbo等，由于服务化改造后，通过不同的入口进行访问，且没有统一的访问标准及访问的入口，所以衍生了服务API网关，网关是提供高性能、高可用的服务托管管理、帮助用户对外开放及共享应用的服务能力，提供完整的服务发布、管理、维护生命周期管理、安全管理。用户只需要进行简单的的操作，即可以快速、低成本、低风险地开放数据及服务的能力。

由于目前数据形态各种各异，有结构化、非结构化、图文化，从数据存储的类型来看，有关系型数据库、非关系型数据库、内存数据库、图数据库等，纵观不同的数据形态来看，服务的多样性，让数据服务化的改造添加了很大的难度。并且达不到通用类型。影响服务的迭代更新。

目前很多应用的体系是基于单一的应用架构及垂直应用架构，各种业务的逻辑服务都会相互影响及使用。整体应用体系的依赖关系的组件组成的架构，比如分层，界面的展示层依赖于业务逻辑层，而且业务逻辑层依赖于数据库访问层。当将整体应用作为通用化的服务改造，存在服务受限于应用本身，如果某个业务逻辑出现异常，可能影响整体业务服务逻辑。

发明内容

本发明针对上述现有技术中的缺陷，提出了如下技术方案。

一种基于数据服务平台提供微服务的方法，该方法包括：

设置步骤，在所述数据服务平台上设置API服务网关，所述微服务通过所述API服务网关访问数据库；

拆分步骤，当所述数据服务平台的访问处于瓶颈时将所述微服务拆分为多个子微服务；

服务编排步骤，将所述多个子微服务之间的依赖关系及子微服务的状态生成服务编排文件；

监控步骤，所述多个子微服务的运行状态进行监控，以确定数据服务平台的异常情况；

处理步骤，基于所述异常情况对相应的子微服务进行熔断、限流或降级处理。

更进一步地，所述API服务网关完成数据聚合，以及为所述多个子微服务提供统一的认证和鉴权。

更进一步地，在API服务网关和所述子微服务中设置缓存以提高数据响应速度。

更进一步地，通过对所述服务编排文件的修改可以实现子微服务的更新、回滚、扩容和/或缩容。

更进一步地，在在所述数据服务平台设置有配置单元和日志单元，用于记录所有微服务及子微服务的配置数据和日志数据。

更进一步地，在一个服务发现被调用的服务过于繁忙、线程池满、连接池满或者一直出错，则应该及时进行熔断处理；

当所述数据服务平台负载过高时，选择重要程度低的微服务或子微服务进行降级；

当超出所述数据服务平台支撑能力范围时，对微服务或子微服务进行限流。

本发明还提出了一种基于数据服务平台提供微服务的装置，该装置包括：

设置单元，用于在所述数据服务平台上设置API服务网关，所述微服务通过所述API服务网关访问数据库；

拆分单元，用于当所述数据服务平台的访问处于瓶颈时将所述微服务拆分为多个子微服务；

服务编排单元，用于将所述多个子微服务之间的依赖关系及子微服务的状态生成服务编排文件；

监控单元，用于所述多个子微服务的运行状态进行监控，以确定数据服务平台的异常情况；

处理单元，用于基于所述异常情况对相应的子微服务进行熔断、限流或降级处理。

更进一步地，所述API服务网关完成数据聚合，以及为所述多个子微服务提供统一的认证和鉴权。

更进一步地，在API服务网关和所述子微服务中设置缓存以提高数据响应速度。

更进一步地，通过对所述服务编排文件的修改可以实现子微服务的更新、回滚、扩容和/或缩容。

更进一步地，在在所述数据服务平台设置有配置单元和日志单元，用于记录所有微服务及子微服务的配置数据和日志数据。

更进一步地，在一个服务发现被调用的服务过于繁忙、线程池满、连接池满或者一直出错，则应该及时进行熔断处理；

当所述数据服务平台负载过高时，选择重要程度低的微服务或子微服务进行降级；

当超出所述数据服务平台支撑能力范围时，对微服务或子微服务进行限流。

本发明还提出了一种计算机可读存储介质，所述存储介质上存储有计算机程序代码，当所述计算机程序代码被计算机执行时执行上述之任一的方法。

本发明的技术效果为：本发明提供了基于数据服务平台提供微服务的方法，其通过在所述数据服务平台上设置API服务网关，所述微服务通过所述API服务网关访问数据库，当所述数据服务平台的访问处于瓶颈时将所述微服务拆分为多个子微服务，将所述多个子微服务之间的依赖关系及子微服务的状态生成服务编排文件，所述多个子微服务的运行状态进行监控，以确定数据服务平台的异常情况，基于所述异常情况对相应的子微服务进行熔断、限流或降级处理。本发明采用微服务架构，每个业务模块作为一个微服务，根据需求不断完善对应模块的API，可以局部更新且不影响其它模块也达到模块复用的目的。在应对不同需求只需调整前端页面和调用不同API，而不必复制整个项目。其采用去中心化管理数据，每个微服务都有自有的数据库，这样做到去中心化数据管理。使用统一的权限验证，使用Spring Cloud提供API网管来管理微服务接口并做到请求过滤的功能，这样就可以对多个微服务做到统一的权限验证，提高了系统的可修改性、可操作性。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显。

图1是根据本发明的实施例的一种基于数据服务平台提供微服务的方法的流程图。

图2是根据本发明的实施例的一种基于数据服务平台提供微服务的装置的结构图。

具体实施方式

下面结合附图和实施例对本申请作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释相关发明，而非对该发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与有关发明相关的部分。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

需要进一步说明的是，本发明中的术语‘微服务’、‘子微服务’是相对的概念的，二者有时在实施例中也称为服务。

图1示出了本发明的一种基于数据服务平台提供微服务的方法，该方法包括：

设置步骤S101，在所述数据服务平台上设置API服务网关，所述微服务通过所述API服务网关访问数据库。在实施微服务的过程中，不免要面临服务的聚合与拆分，当后端服务的拆分相对比较频繁的时候，作为手机App来讲，往往需要一个统一的入口，将不同的请求路由到不同的服务，无论后面如何拆分与聚合，对于手机端来讲都是透明的。有了API网关以后，简单的数据聚合可以在网关层完成，这样就不用在手机App端完成，从而手机App耗电量较小，用户体验较好，这是本发明的一个重要发明点之一。

有了统一的API网关，还可以进行统一的认证和鉴权，尽管服务之间的相互调用比较复杂，接口也会比较多，API网关往往只暴露必须的对外接口，并且对接口进行统一的认证和鉴权，使得内部的服务相互访问的时候，不用再进行认证和鉴权，效率会比较高，有了统一的API网关，可以在这一层设定一定的策略，进行A/B测试，蓝绿发布，预发环境导流等等。API网关往往是无状态的，可以横向扩展，从而不会成为性能瓶颈。

影响应用迁移和横向扩展的重要因素就是应用的状态，无状态服务，是要把这个状态往外移，将Session数据，文件数据，结构化数据保存在后端统一的存储中，从而应用仅仅包含商务逻辑。状态是不可避免的，例如ZooKeeper,DB，Cache等，把这些所有有状态的东西收敛在一个非常集中的集群里面。整个业务就分两部分，一个是无状态的部分，一个是有状态的部分。

无状态的部分能实现两点，一是跨机房随意地部署，也即迁移性，一是弹性伸缩，很容易地进行扩容。有状态的部分，如DB，Cache，ZooKeeper有自己的高可用机制，要利用到他们自己高可用的机制来实现这个状态的集群。

虽说无状态化，但是当前处理的数据，还是会在内存里面的，当前的进程挂掉数据，肯定也是有一部分丢失的，为了实现这一点，服务要有重试的机制，接口要有幂等的机制，通过服务发现机制，重新调用一次后端服务的另一个实例就可以了。

数据库是保存状态，是最重要的也是最容易出现瓶颈的。有了分布式数据库可以使数据库的性能可以随着节点增加线性地增加。分布式数据库最最下面是RDS，是主备的，通过MySql的内核开发能力，本发明能够实现主备切换数据零丢失，所以数据落在这个RDS里面，是非常放心的，哪怕是挂了一个节点，切换完了以后，数据也是不会丢的。再往上就是横向怎么承载大的吞吐量的问题，上面有一个负载均衡NLB，用LVS，HAProxy,Keepalived，下面接了一层Query Server。Query Server是可以根据监控数据进行横向扩展的，如果出现了故障，可以随时进行替换的修复，对于业务层是没有任何感知的。另外一个就是双机房的部署，DDB开发了一个数据运河NDC的组件，可以使得不同的DDB之间在不同的机房里面进行同步，这时候不但在一个数据中心里面是分布式的，在多个数据中心里面也会有一个类似双活的一个备份，高可用性有非常好的保证。这是本发明的另一个重要发明点。

拆分步骤S102，当所述数据服务平台的访问处于瓶颈时将所述微服务拆分为多个子微服务。

当系统遇到瓶颈，应用变化快的时候，往往要考虑将比较大的服务(微服务)拆分为一系列小的服务(多个子微服务)。其优点在于开发比较独立，解决了当非常多的人在维护同一个代码仓库的时候，往往对代码的修改就会相互影响，常常会出现没改什么测试就不通过了，而且代码提交的时候，经常会出现冲突的技术问题，提高了开发的效率。

另一个好处就是上线独立，物流模块对接了一家新的快递公司，需要连同下单一起上线，这是非常不合理的行为，都是应该拆分的时机。另外再就是高并发时段的扩容，往往只有最关键的下单和支付流程是核心，只要将关键的交易链路进行扩容即可，如果这时候附带很多其他的服务，扩容即是不经济的，也是很有风险的。再就是容灾和降级，在大促的时候，可能需要牺牲一部分的边角功能，但是如果所有的代码耦合在一起，很难将边角的部分功能进行降级。当然拆分完毕以后，应用之间的关系就更加复杂了，因而需要服务发现的机制，来管理应用相互的关系，实现自动的修复，自动的关联，自动的负载均衡，自动的容错切换。这是本发明的另一个重要发明点。

服务编排步骤S103，将所述多个子微服务之间的依赖关系及子微服务的状态生成服务编排文件。

当服务拆分后，进程就会非常的多，因而需要服务编排来管理服务之间的依赖关系，以及将服务的部署代码化，也就是我们常说的基础设施即代码。这样对于服务的发布，更新，回滚，扩容，缩容，都可以通过修改编排文件来实现，从而增加了可追溯性，易管理性，和自动化的能力。

既然编排文件也可以用代码仓库进行管理，就可以实现一百个服务中，更新其中五个服务，只要修改编排文件中的五个服务的配置就可以，当编排文件提交的时候，代码仓库自动触发自动部署升级脚本，从而更新线上的环境，当发现新的环境有问题时，当然希望将这五个服务原子性地回滚，如果没有编排文件，需要人工记录这次升级了哪五个服务。有了编排文件，只要在代码仓库里面revert，就回滚到上一个版本了。所有的操作在代码仓库里都是可以看到的。

监控步骤S104，所述多个子微服务的运行状态进行监控，以确定数据服务平台的异常情况。

当系统(即数据服务平台)非常复杂的时候，要有统一的监控，主要有两个方面，一个是是否健康，一个是性能瓶颈在哪里。当系统出现异常的时候，监控系统可以配合告警系统，及时地发现，通知，干预，从而保障系统的顺利运行。当压力测试的时候，往往会遭遇瓶颈，也需要有全方位的监控来找出瓶颈点，同时能够保留现场，从而可以追溯和分析，进行全方位的优化。

处理步骤S105，基于所述异常情况对相应的子微服务进行熔断、限流或降级处理。

服务要有熔断，限流，降级的能力，当一个服务调用另一个服务，出现超时的时候，应及时返回，而非阻塞在那个地方，从而影响其他用户的交易，可以返回默认的托底数据。

当一个服务发现被调用的服务，因为过于繁忙，线程池满，连接池满，或者总是出错，则应该及时熔断，防止因为下一个服务的错误或繁忙，导致本服务的不正常，从而逐渐往前传导，导致整个应用的雪崩。

当发现整个系统的确负载过高的时候，可以选择降级某些功能或某些调用，保证最重要的交易流程的通过，以及最重要的资源全部用于保证最核心的流程。

还有一种手段就是限流，当既设置了熔断策略，又设置了降级策略，通过全链路的压力测试，应该能够知道整个系统的支撑能力，因而就需要制定限流策略，保证系统在测试过的支撑能力范围内进行服务，超出支撑能力范围的，可拒绝服务。当你下单的时候，系统弹出对话框说“系统忙，请重试”，并不代表系统挂了，而是说明系统是正常工作的，只不过限流策略起到了作用。这是本发明的另一个重要发明点。

在一个实施例中，在API服务网关和所述子微服务中设置缓存以提高数据响应速度。在高并发场景下缓存是非常重要的。要有层次的缓存，使得数据尽量靠近用户。数据越靠近用户能承载的并发量也越大，响应时间越短。

在手机客户端App上就应该有一层缓存，不是所有的数据都每时每刻从后端拿，而是只拿重要的，关键的，时常变化的数据。尤其对于静态数据，可以过一段时间去取一次，而且也没必要到数据中心去取，可以通过CDN，将数据缓存在距离客户端最近的节点上，进行就近下载。

有时候CDN里面没有，还是要回到数据中心去下载，称为回源，在数据中心的最外层，称为接入层，可以设置一层缓存，将大部分的请求拦截，从而不会对后台的数据库造成压力。如果是动态数据，还是需要访问应用，通过应用中的商务逻辑生成，或者去数据库读取，为了减轻数据库的压力，应用可以使用本地的缓存，也可以使用分布式缓存，如Memcached或者Redis，使得大部分请求读取缓存即可，不必访问数据库。当然动态数据还可以做一定的静态化，也即降级成静态数据，从而减少后端的压力。

在一个实施例中，在在所述数据服务平台设置有配置单元和日志单元，用于记录所有微服务及子微服务的配置数据和日志数据。

服务拆分以后，服务的数量非常多，如果所有的配置都以配置文件的方式放在应用本地的话，非常难以管理，可以想象当有几百上千个进程中有一个配置出现了问题，是很难将它找出来的，因而需要有统一的配置中心，来管理所有的配置，进行统一的配置下发。

在微服务中，配置往往分为几类，一类是几乎不变的配置，这种配置可以直接打在容器镜像里面，第二类是启动时就会确定的配置，这种配置往往通过环境变量，在容器启动的时候传进去，第三类就是统一的配置，需要通过配置中心进行下发，例如在大促的情况下，有些功能需要降级，哪些功能可以降级，哪些功能不能降级，都可以在配置文件中统一配置。

同样是进程数目非常多的时候，很难对成千上百个容器，一个一个登录进去查看日志，所以需要统一的日志中心来收集日志，为了使收集到的日志容易分析，对于日志的规范，需要有一定的要求，当所有的服务都遵守统一的日志规范的时候，在日志中心就可以对一个交易流程进行统一的追溯。例如在最后的日志搜索引擎中，搜索交易号，就能够看到在哪个过程出现了错误或者异常。

本方法的技术效果在于：其采用微服务架构，每个业务模块作为一个微服务，根据需求不断完善对应模块的API，可以局部更新且不影响其它模块也达到模块复用的目的。在应对不同需求只需调整前端页面和调用不同API，而不必复制整个项目。其采用去中心化管理数据，每个微服务都有自有的数据库，这样做到去中心化数据管理。使用统一的权限验证，使用Spring Cloud提供API网管来管理微服务接口并做到请求过滤的功能，这样就可以对多个微服务做到统一的权限验证，提高了系统的可修改性、可操作性。

进一步参考图2，作为对上述图1所示方法的实现，本申请提供了一种基于数据服务平台提供微服务的装置的一个实施例，该装置实施例与图1所示的方法实施例相对应，该装置具体可以包含于各种电子设备或通过网络连接的多个电子设备中。

图2示出了本发明的本发明的一种基于数据服务平台提供微服务的装置，该装置包括：

设置单元201，在所述数据服务平台上设置API服务网关，所述微服务通过所述API服务网关访问数据库。在实施微服务的过程中，不免要面临服务的聚合与拆分，当后端服务的拆分相对比较频繁的时候，作为手机App来讲，往往需要一个统一的入口，将不同的请求路由到不同的服务，无论后面如何拆分与聚合，对于手机端来讲都是透明的。有了API网关以后，简单的数据聚合可以在网关层完成，这样就不用在手机App端完成，从而手机App耗电量较小，用户体验较好，这是本发明的一个重要发明点之一。

有了统一的API网关，还可以进行统一的认证和鉴权，尽管服务之间的相互调用比较复杂，接口也会比较多，API网关往往只暴露必须的对外接口，并且对接口进行统一的认证和鉴权，使得内部的服务相互访问的时候，不用再进行认证和鉴权，效率会比较高，有了统一的API网关，可以在这一层设定一定的策略，进行A/B测试，蓝绿发布，预发环境导流等等。API网关往往是无状态的，可以横向扩展，从而不会成为性能瓶颈。

影响应用迁移和横向扩展的重要因素就是应用的状态，无状态服务，是要把这个状态往外移，将Session数据，文件数据，结构化数据保存在后端统一的存储中，从而应用仅仅包含商务逻辑。状态是不可避免的，例如ZooKeeper,DB，Cache等，把这些所有有状态的东西收敛在一个非常集中的集群里面。整个业务就分两部分，一个是无状态的部分，一个是有状态的部分。

无状态的部分能实现两点，一是跨机房随意地部署，也即迁移性，一是弹性伸缩，很容易地进行扩容。有状态的部分，如DB，Cache，ZooKeeper有自己的高可用机制，要利用到他们自己高可用的机制来实现这个状态的集群。

虽说无状态化，但是当前处理的数据，还是会在内存里面的，当前的进程挂掉数据，肯定也是有一部分丢失的，为了实现这一点，服务要有重试的机制，接口要有幂等的机制，通过服务发现机制，重新调用一次后端服务的另一个实例就可以了。

数据库是保存状态，是最重要的也是最容易出现瓶颈的。有了分布式数据库可以使数据库的性能可以随着节点增加线性地增加。分布式数据库最最下面是RDS，是主备的，通过MySql的内核开发能力，本发明能够实现主备切换数据零丢失，所以数据落在这个RDS里面，是非常放心的，哪怕是挂了一个节点，切换完了以后，数据也是不会丢的。再往上就是横向怎么承载大的吞吐量的问题，上面有一个负载均衡NLB，用LVS，HAProxy,Keepalived，下面接了一层Query Server。Query Server是可以根据监控数据进行横向扩展的，如果出现了故障，可以随时进行替换的修复，对于业务层是没有任何感知的。另外一个就是双机房的部署，DDB开发了一个数据运河NDC的组件，可以使得不同的DDB之间在不同的机房里面进行同步，这时候不但在一个数据中心里面是分布式的，在多个数据中心里面也会有一个类似双活的一个备份，高可用性有非常好的保证。这是本发明的另一个重要发明点。

拆分单元202，当所述数据服务平台的访问处于瓶颈时将所述微服务拆分为多个子微服务。

当系统遇到瓶颈，应用变化快的时候，往往要考虑将比较大的服务(微服务)拆分为一系列小的服务(多个子微服务)。其优点在于开发比较独立，解决了当非常多的人在维护同一个代码仓库的时候，往往对代码的修改就会相互影响，常常会出现没改什么测试就不通过了，而且代码提交的时候，经常会出现冲突的技术问题，提高了开发的效率。

另一个好处就是上线独立，物流模块对接了一家新的快递公司，需要连同下单一起上线，这是非常不合理的行为，都是应该拆分的时机。另外再就是高并发时段的扩容，往往只有最关键的下单和支付流程是核心，只要将关键的交易链路进行扩容即可，如果这时候附带很多其他的服务，扩容即是不经济的，也是很有风险的。再就是容灾和降级，在大促的时候，可能需要牺牲一部分的边角功能，但是如果所有的代码耦合在一起，很难将边角的部分功能进行降级。当然拆分完毕以后，应用之间的关系就更加复杂了，因而需要服务发现的机制，来管理应用相互的关系，实现自动的修复，自动的关联，自动的负载均衡，自动的容错切换。这是本发明的另一个重要发明点。

服务编排单元203，将所述多个子微服务之间的依赖关系及子微服务的状态生成服务编排文件。

当服务拆分后，进程就会非常的多，因而需要服务编排来管理服务之间的依赖关系，以及将服务的部署代码化，也就是我们常说的基础设施即代码。这样对于服务的发布，更新，回滚，扩容，缩容，都可以通过修改编排文件来实现，从而增加了可追溯性，易管理性，和自动化的能力。

既然编排文件也可以用代码仓库进行管理，就可以实现一百个服务中，更新其中五个服务，只要修改编排文件中的五个服务的配置就可以，当编排文件提交的时候，代码仓库自动触发自动部署升级脚本，从而更新线上的环境，当发现新的环境有问题时，当然希望将这五个服务原子性地回滚，如果没有编排文件，需要人工记录这次升级了哪五个服务。有了编排文件，只要在代码仓库里面revert，就回滚到上一个版本了。所有的操作在代码仓库里都是可以看到的。

监控单元204，所述多个子微服务的运行状态进行监控，以确定数据服务平台的异常情况。

当系统(即数据服务平台)非常复杂的时候，要有统一的监控，主要有两个方面，一个是是否健康，一个是性能瓶颈在哪里。当系统出现异常的时候，监控系统可以配合告警系统，及时地发现，通知，干预，从而保障系统的顺利运行。当压力测试的时候，往往会遭遇瓶颈，也需要有全方位的监控来找出瓶颈点，同时能够保留现场，从而可以追溯和分析，进行全方位的优化。

处理单元205，基于所述异常情况对相应的子微服务进行熔断、限流或降级处理。

服务要有熔断，限流，降级的能力，当一个服务调用另一个服务，出现超时的时候，应及时返回，而非阻塞在那个地方，从而影响其他用户的交易，可以返回默认的托底数据。

当一个服务发现被调用的服务，因为过于繁忙，线程池满，连接池满，或者总是出错，则应该及时熔断，防止因为下一个服务的错误或繁忙，导致本服务的不正常，从而逐渐往前传导，导致整个应用的雪崩。

当发现整个系统的确负载过高的时候，可以选择降级某些功能或某些调用，保证最重要的交易流程的通过，以及最重要的资源全部用于保证最核心的流程。

还有一种手段就是限流，当既设置了熔断策略，又设置了降级策略，通过全链路的压力测试，应该能够知道整个系统的支撑能力，因而就需要制定限流策略，保证系统在测试过的支撑能力范围内进行服务，超出支撑能力范围的，可拒绝服务。当你下单的时候，系统弹出对话框说“系统忙，请重试”，并不代表系统挂了，而是说明系统是正常工作的，只不过限流策略起到了作用。这是本发明的另一个重要发明点。

在一个实施例中，在API服务网关和所述子微服务中设置缓存以提高数据响应速度。在高并发场景下缓存是非常重要的。要有层次的缓存，使得数据尽量靠近用户。数据越靠近用户能承载的并发量也越大，响应时间越短。

在手机客户端App上就应该有一层缓存，不是所有的数据都每时每刻从后端拿，而是只拿重要的，关键的，时常变化的数据。尤其对于静态数据，可以过一段时间去取一次，而且也没必要到数据中心去取，可以通过CDN，将数据缓存在距离客户端最近的节点上，进行就近下载。

有时候CDN里面没有，还是要回到数据中心去下载，称为回源，在数据中心的最外层，称为接入层，可以设置一层缓存，将大部分的请求拦截，从而不会对后台的数据库造成压力。如果是动态数据，还是需要访问应用，通过应用中的商务逻辑生成，或者去数据库读取，为了减轻数据库的压力，应用可以使用本地的缓存，也可以使用分布式缓存，如Memcached或者Redis，使得大部分请求读取缓存即可，不必访问数据库。当然动态数据还可以做一定的静态化，也即降级成静态数据，从而减少后端的压力。

在一个实施例中，在在所述数据服务平台设置有配置单元和日志单元，用于记录所有微服务及子微服务的配置数据和日志数据。

服务拆分以后，服务的数量非常多，如果所有的配置都以配置文件的方式放在应用本地的话，非常难以管理，可以想象当有几百上千个进程中有一个配置出现了问题，是很难将它找出来的，因而需要有统一的配置中心，来管理所有的配置，进行统一的配置下发。

在微服务中，配置往往分为几类，一类是几乎不变的配置，这种配置可以直接打在容器镜像里面，第二类是启动时就会确定的配置，这种配置往往通过环境变量，在容器启动的时候传进去，第三类就是统一的配置，需要通过配置中心进行下发，例如在大促的情况下，有些功能需要降级，哪些功能可以降级，哪些功能不能降级，都可以在配置文件中统一配置。

同样是进程数目非常多的时候，很难对成千上百个容器，一个一个登录进去查看日志，所以需要统一的日志中心来收集日志，为了使收集到的日志容易分析，对于日志的规范，需要有一定的要求，当所有的服务都遵守统一的日志规范的时候，在日志中心就可以对一个交易流程进行统一的追溯。例如在最后的日志搜索引擎中，搜索交易号，就能够看到在哪个过程出现了错误或者异常。

本装置的技术效果在于：其采用微服务架构，每个业务模块作为一个微服务，根据需求不断完善对应模块的API，可以局部更新且不影响其它模块也达到模块复用的目的。在应对不同需求只需调整前端页面和调用不同API，而不必复制整个项目。其采用去中心化管理数据，每个微服务都有自有的数据库，这样做到去中心化数据管理。使用统一的权限验证，使用Spring Cloud提供API网管来管理微服务接口并做到请求过滤的功能，这样就可以对多个微服务做到统一的权限验证，提高了系统的可修改性、可操作性。

为了描述的方便，描述以上装置时以功能分为各种单元分别描述。当然，在实施本申请时可以把各单元的功能在同一个或多个软件和/或硬件中实现。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

最后所应说明的是：以上实施例仅以说明而非限制本发明的技术方案，尽管参照上述实施例对本发明进行了详细说明，本领域的普通技术人员应当理解：依然可以对本发明进行修改或者等同替换，而不脱离本发明的精神和范围的任何修改或局部替换，其均应涵盖在本发明的权利要求范围当中。

Claims (13)

1.一种基于数据服务平台提供微服务的方法，其特征在于，该方法包括：

设置步骤，在所述数据服务平台上设置API服务网关，所述微服务通过所述API服务网关访问数据库；

拆分步骤，当所述数据服务平台的访问处于瓶颈时将所述微服务拆分为多个子微服务；

服务编排步骤，将所述多个子微服务之间的依赖关系及子微服务的状态生成服务编排文件；

监控步骤，所述多个子微服务的运行状态进行监控，以确定数据服务平台的异常情况；

处理步骤，基于所述异常情况对相应的子微服务进行熔断、限流或降级处理。

2.根据权利要求1所述的方法，其特征在于，所述API服务网关完成数据聚合，以及为所述多个子微服务提供统一的认证和鉴权。

3.根据权利要求2所述的方法，其特征在于，在API服务网关和所述子微服务中设置缓存以提高数据响应速度。

4.根据权利要求3所述的方法，其特征在于，通过对所述服务编排文件的修改可以实现子微服务的更新、回滚、扩容和/或缩容。

5.根据权利要求1-4任一项所述的方法，其特征在于，在在所述数据服务平台设置有配置单元和日志单元，用于记录所有微服务及子微服务的配置数据和日志数据。

6.根据权利要求5所述的方法，其特征在于，在一个服务发现被调用的服务过于繁忙、线程池满、连接池满或者一直出错，则应该及时进行熔断处理；

当所述数据服务平台负载过高时，选择重要程度低的微服务或子微服务进行降级；

当超出所述数据服务平台支撑能力范围时，对微服务或子微服务进行限流。

7.一种基于数据服务平台提供微服务的装置，其特征在于，该装置包括：

设置单元，用于在所述数据服务平台上设置API服务网关，所述微服务通过所述API服务网关访问数据库；

拆分单元，用于当所述数据服务平台的访问处于瓶颈时将所述微服务拆分为多个子微服务；

服务编排单元，用于将所述多个子微服务之间的依赖关系及子微服务的状态生成服务编排文件；

监控单元，用于所述多个子微服务的运行状态进行监控，以确定数据服务平台的异常情况；

处理单元，用于基于所述异常情况对相应的子微服务进行熔断、限流或降级处理。

8.根据权利要求7所述的装置，其特征在于，所述API服务网关完成数据聚合，以及为所述多个子微服务提供统一的认证和鉴权。

9.根据权利要求8所述的装置，其特征在于，在API服务网关和所述子微服务中设置缓存以提高数据响应速度。

10.根据权利要求9所述的装置，其特征在于，通过对所述服务编排文件的修改可以实现子微服务的更新、回滚、扩容和/或缩容。

11.根据权利要求7-10任一项所述的装置，其特征在于，在在所述数据服务平台设置有配置单元和日志单元，用于记录所有微服务及子微服务的配置数据和日志数据。

12.根据权利要求11所述的装置，其特征在于，在一个服务发现被调用的服务过于繁忙、线程池满、连接池满或者一直出错，则应该及时进行熔断处理；

当所述数据服务平台负载过高时，选择重要程度低的微服务或子微服务进行降级；

当超出所述数据服务平台支撑能力范围时，对微服务或子微服务进行限流。

13.一种计算机可读存储介质，其特征在于，所述存储介质上存储有计算机程序代码，当所述计算机程序代码被计算机执行时执行权利要求1-6之任一的方法。