CN114068018A - 健康服务与码信息处理方法、设备、系统及存储介质 - Google Patents

Abstract

本申请实施例提供一种健康服务与码信息处理方法、设备、系统及存储介质。本申请实施例提供一种健康服务系统，在该健康服务系统中，基于健康服务需求动态配置生成健康码信息所需的多级健康服务，服务端设备可以调用动态配置的多级健康服务为用户生成健康码信息，用户可以通过终端设备向服务端设备发起获取健康码信息的服务请求，从服务端设备得到健康码信息，实现对用户健康状态的智能化管理。其中，基于健康服务需求动态配置生成健康码信息所需的多级健康服务，可满足不同应用场景、不同地域和/或不同时段对用户健康状态的差异化需求，解决多种服务需求下的健康状态智能化管理问题，极大地降低健康服务的开发成本。

Description

健康服务与码信息处理方法、设备、系统及存储介质

技术领域

本申请涉及软件技术领域，尤其涉及一种健康服务与码信息处理方法、设备、系统及存储介质。

背景技术

对用户健康状态的智能化管理，将成为城市智能化、数字化管理的新趋势。对用户健康状态的智能化管理，不仅可以为用户提供各种健康服务，让用户及时了解自己的健康状态，而且在特殊时期，还可以协助疾病防控，利于提高全民健康。

在不同应用场景或不同城市中，对用户健康状态的服务需求可能会有所不同，即对用户健康状态的智能化管理面临多种服务需求，如何解决具有多种服务需求的用户健康状态智能化管理问题是有待解决的问题。

发明内容

本申请的多个方面提供一种健康服务与码信息处理方法、设备、系统及存储介质，用以解决多种服务需求下的健康状态智能化管理问题。

本申请实施例提供一种健康服务系统，包括：服务端设备和终端设备；服务端设备，用于获取基于健康服务需求动态配置的多级健康服务，调用多级健康服务为至少一个用户生成健康码信息；以及接收来自第一用户的第一服务请求，并根据第一服务请求向第一用户返回其健康码信息，至少一个用户包含第一用户；第一用户的终端设备，用于向服务端设备发送第一服务请求，以及接收服务端设备返回的第一用户的健康码信息并展示。

本申请实施例还提供一种健康服务方法，该方法包括：基于健康服务需求，动态配置生成健康码信息所需的多级健康服务；调用所述多级健康服务为至少一个用户生成健康码信息；接收来自第一用户的第一服务请求，所述至少一个用户包含所述第一用户；根据所述第一服务请求向所述第一用户返回其健康码信息。

本申请实施例还提供一种服务端设备，包括：存储器、处理器以及通信组件；存储器，用于存储计算机程序；处理器，与存储器耦合，用于执行计算机程序，以用于：获取基于健康服务需求动态配置的多级健康服务，调用所述多级健康服务为至少一个用户生成健康码信息；以及通过通信组件接收来自第一用户的第一服务请求，并根据第一服务请求向第一用户返回其健康码信息，至少一个用户包含第一用户，多级健康服务是基于健康服务需求动态配置的。

本申请实施例还提供一种配置设备，包括：存储器和处理器；存储器，用于存储计算机程序；处理器，与存储器耦合，用于执行计算机程序，以用于：获取健康服务需求；根据健康服务需求，在服务端设备上动态配置生成健康码信息所需的多级健康服务，以供服务端设备基于多级健康服务为至少一个用户生成健康码信息。

本申请实施例还提供一种健康码信息展示方法，包括：向服务端设备发送服务请求，以请求用户的健康码信息，所述健康码信息包括健康码颜色和所述用户的标识信息；接收所述服务端设备返回的所述健康码信息以及与所述健康码颜色对应的原因信息；在健康码界面上，展示所述健康码信息以及与所述健康码颜色对应的原因信息。

本申请实施例还提供一种服务配置方法，包括：响应服务配置操作，展示服务配置界面，所述服务配置界面上包含自定义服务是否依赖第三方服务的第一配置项；响应对所述第一配置项的配置操作，获取所述自定义服务是否依赖第三方服务的配置信息；若所述第三方服务依赖第三方服务，则显示用于配置第三方服务的服务域名的第二配置项；响应于对所述第二配置项的配置操作，获取所述第三方服务的服务器域名，以供访问所述第三方服务。

本申请实施例还提供一种终端设备，包括：存储器、处理器和通信组件；所述存储器，用于存储计算机程序；所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：通过所述通信组件向服务端设备发送服务请求，以请求用户的健康码信息，所述健康码信息包括健康码颜色和所述用户的标识信息；接收所述服务端设备返回的所述健康码信息以及与所述健康码颜色对应的原因信息；在健康码界面上，展示所述健康码信息以及与所述健康码颜色对应的原因信息。

本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，当所述计算机程序被处理器执行时，致使所述处理器实现本申请实施例提供的健康服务方法中的步骤。

本申请实施例还提供一种码信息处理系统，包括：服务端设备和至少一个终端设备；所述服务端设备，用于获取基于状态码服务需求动态配置的多级状态码服务，调用所述多级状态码服务为至少一个数据对象生成状态码信息；以及接收来自第一终端设备的第一服务请求，并根据所述第一服务请求向所述第一终端设备返回第一数据对象的状态码信息，所述第一数据对象属于所述至少一个数据对象；所述第一终端设备，用于向所述服务端设备发送第一服务请求，以及接收所述服务端设备返回的所述第一数据对象的状态码信息并展示；所述至少一个终端设备属于所述至少一个终端设备。

本申请实施例还提供一种码信息处理方法，包括：基于状态码服务需求，动态配置生成状态码信息所需的多级状态码服务；调用所述多级状态码服务为至少一个数据对象生成状态码信息；接收来自第一终端设备的第一服务请求，所述第一服务请求用于请求所述第一数据对象的状态码信息；根据所述第一服务请求，向所述第一终端设备返回所述第一数据对象的状态码信息，所述第一数据对象属于所述至少一个数据对象。

本申请实施例还提供一种服务端设备，包括：存储器、处理器以及通信组件；所述存储器，用于存储计算机程序；所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：获取基于状态码服务需求动态配置的多级状态码服务；调用所述多级状态码服务为至少一个数据对象生成状态码信息；接收来自第一终端设备的第一服务请求，所述第一服务请求用于请求所述第一数据对象的状态码信息；根据所述第一服务请求，向所述第一终端设备返回所述第一数据对象的状态码信息，所述第一数据对象属于所述至少一个数据对象。

本申请实施例提供一种健康服务系统，在该健康服务系统中，可基于健康服务需求动态配置生成健康码信息所需的多级健康服务，服务端设备可以调用动态配置的多级健康服务为用户生成健康码信息，用户可以通过终端设备向服务端设备发起获取健康码信息的服务请求，从服务端设备得到健康码信息，实现对用户健康状态的智能化管理。其中，基于健康服务需求动态配置生成健康码信息所需的多级健康服务，可满足不同应用场景、不同地域和/或不同时段对用户健康状态的差异化需求，解决多种服务需求下的健康状态智能化管理问题，极大地降低健康服务的开发成本。

同理，本申请实施例还提供一种码信息处理系统，在该码信息处理系统中，可基于状态码服务需求动态配置生成状态码信息所需的多级状态码服务，服务端设备可以调用动态配置的多级状态码服务为相关数据对象生成状态码信息，需要数据对象的状态码信息的一方，可通过终端设备向服务端设备发起获取状态码信息的服务请求，从服务端设备得到相关数据对象的状态码信息，实现对数据对象相关状态的智能化管理。其中，基于状态码服务需求动态配置生成状态码信息所需的多级状态码服务，可满足不同应用场景、不同地域和/或不同时段对对象状态的差异化需求，解决多种服务需求下的对象状态智能化管理问题，极大地降低状态管理服务的开发成本。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请示例性实施例提供的一种健康服务系统的结构示意图；

图2为本申请示例性实施例提供的一种服务端设备101内部服务框架及其工作原理示意图；

图3a为本申请示例性实施例提供的另一种服务端设备101内部服务框架及其工作原理示意图；

图3b为本申请实施例提供的又一种服务端设备101内部服务框架及其工作原理示意图；

图4a为本申请示例性实施例提供的一种健康服务方法的流程示意图；

图4b为本申请示例性实施例提供的一种健康码信息展示方法的流程示意图；

图4c为本申请示例性实施例提供的一种服务配置方法的流程示意图；

图5为本申请示例性实施例提供的一种服务端设备的结构示意图；

图6为本申请示例性实施例提供的一种配置设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

随着对用户健康状态智能化管理需求的出现，面临着如何解决具有多种服务需求的用户健康状态智能化管理的问题。针对该技术问题，本申请实施例提供一种健康服务系统，如图1所示，该健康服务系统100包括：服务端设备101和终端设备103。

在本实施例的健康服务系统100中，使用健康码信息表示用户的健康状态，其中，健康码信息可以是任何能够表示用户健康状态的信息形式，对此不做限定。例如，健康码信息可以包含“健康”、“不健康”等文字信息。又例如，健康码信息可以包含表示健康状态的颜色信息，例如表示健康的“绿色”，表示不健康的“红色”等。

其中，对用户健康状态的智能化管理包括为用户生成并提供健康码信息的过程，但不限于此。在本实施例中，将为用户生成健康码信息的过程划分为多个阶段，每个阶段采用独立的健康服务完成，相邻阶段中的健康服务之间级联，即上一阶段中健康服务的结果汇聚后作为下一阶段中健康服务的输入，依次执行下去，直至最后一阶段中的健康服务生成健康码信息。在本实施例中，按照生成健康码信息的多个阶段之间的关系，将生成健康码所需的健康服务划分为多级，称为生成健康码信息所需的多级健康服务。

具体地，由服务端设备101基于生成健康码信息所需的多级健康服务，为用户生成表示用户健康状态的健康码信息；用户在需要健康码信息的情况下，可以通过终端设备103向服务端设备101发起获取健康码信息的服务请求，从服务端设备101得到健康码信息，进而基于得到的健康码信息开展与健康状态相关的后续操作，例如向健康查验人员展示自己的健康码信息，以配合健康查验人员的查验工作，从而实现对用户健康状态的智能化管理。在此说明，本实施例并不限定服务端设备101和终端设备103的设备形态，例如服务端设备101可以是但不限于：常规服务器、云服务器或服务器阵列等；终端设备103可以是但不限于：智能手机、平板电脑，台式电脑或智能电视等。

进一步，在本实施例中，考虑到在不同应用场景中、在不同地域和/或在不同时期，对用户健康状态的服务需求可能会有所不同。举例说明，在就医应用场景中，在特殊时期(例如疫情期间)，可能更关注用户是否看过与疫情有关的门诊(例如发热门诊)，如果用户有看过与疫情有关的门诊(例如发热门诊)，则认为用户处于不健康状态；反之，认为用户处于健康状态。另外，在就医应用场景中，在非特殊时期，可能更关注用户是否住院，如果用户有住院，则认为用户处于不健康状态；反之，认为用户处于健康状态。在城市A中，在特殊时期(例如疫情期间)，可能更关注用户是否与疫情发源地有较为密切的接触和/或用户是否看过与疫情有关的门诊(例如发热门诊)，如果用户与疫情发源地有较为密切的接触，或者用户看过与疫情有关的门诊，则认为用户处于不健康状态；反之，认为用户处于健康状态。在城市B中，可能只需要考虑用户在疫情期间是否去过城市A；如果用户在疫情期间去过城市A，则认为用户处于不健康状态；反之，认为用户处于健康状态。在这些示例中，仅以用户处于健康状态和不健康状态为例对用户健康状态进行说明，并不限于此。例如，用户健康状态还可以被划分为健康高风险、健康中风险、健康低风险和无健康风险等几个级别，具体根据应用需求灵活而定。

鉴于上述考虑，在本申请实施例中，服务端设备101采用一种可配置的健康码引擎框架，用于生成健康码信息的多级健康服务运行在该健康码引擎框架中并且允许对多级健康服务进行动态配置。具体地，在本申请实施例中，允许基于健康服务需求动态配置生成健康码信息所需的多级健康服务。具体地，服务端设备101在调用多级健康服务之前，可获取基于健康服务需求动态配置的多级健康服务；之后，再调用多级健康服务为至少一个用户生成健康码信息。

在本申请实施例中，并不限定服务端设备101获取基于健康服务需求动态配置的多级健康服务的实施方式。例如，服务端设备101可以面向健康服务需求方提供一配置界面，健康服务需求方可以根据健康服务需求的变化，通过该配置界面动态配置与当前健康服务需求适配的多级健康服务；服务端设备101可以直接获取健康服务需求方在配置界面上配置的多级健康服务。可选地，该配置界面可以是web页面，则健康服务需求方可以通过其使用的终端设备打开该web页面，根据健康服务需求的变化，在该web页面上动态配置与当前健康服务需求适配的多级健康服务；在健康服务需求方配置完成后可点击web页面上的提交按钮，web页面可将动态配置的多级健康服务返回给服务端设备101。

除上述实施方式之外，如图1所示，本实施例的健康服务系统100还可以包括：配置设备102，用于基于健康服务需求在服务端设备101上动态配置生成健康码信息所需的多级健康服务。在该情况下，服务端设备101可以直接获取配置设备102动态配置的多级健康服务。在本申请实施例中，并不对配置设备102的实现形式进行限定，例如配置设备102可以是但不限于：常规服务器、云服务器、服务器阵列、虚拟机(VM)或容器等。对服务端设备101来说，可以调用配置设备102动态配置的多级健康服务为用户生成健康码信息。换句话说，用于生成健康码信息的多级健康服务发生变化时，服务端设备101为用户生成健康码信息的逻辑也会发生变化。在下面实施例中，以由配置设备102基于健康服务需求动态配置多级健康服务为例，对配置设备102与服务端设备101相互配合提供健康服务的过程进行详细说明。

其中，健康服务需求是指健康服务需求方对用户健康状态的服务需求，至少包括健康服务需求方所要求的生成健康码信息的服务逻辑以及生成健康码信息所依赖的数据维度。在生成健康码信息的过程包括多个阶段的情况下，健康服务需求方所要求的生成健康码信息的服务逻辑包含与多个阶段对应的服务逻辑。其中，健康服务需求方是指需要了解用户健康状态的一方，例如可以是社区、学校、办公大楼、公园、商场、超市、菜市场或者整个城市等各场所的安全管理部门。为了确保出入相应场所的人员安全，这些场所的安全管理人员需要了解出入人员的健康状态，而本实施例提供的健康服务系统100，服务端设备101可根据配置设备102动态配置的多级健康服务提供各用户的健康码信息，可满足各场所安全管理部分对用户健康状态的服务需求。

其中，根据需要健康服务的应用场景、地域属性和/或时间属性的不同，健康服务需求会有所不同，相应地，所配置的多级健康服务的服务逻辑也有所不同。可选地，配置设备102可以根据健康服务对应的地域属性、时间属性和/或应用场景，确定当前健康服务需求；获取与当前健康服务需求适配的多级健康服务，并在服务端设备101上配置与当前健康服务需求适配的多级健康服务。

在一可选实施例中，可以根据健康服务对应的地域属性确定当前健康服务需求。健康服务对应的地域属性指的是健康服务需求中指向的地域，也就是需要使用健康服务的地域，该地域可以是一个或多个城市，也可以是一个或多个省份，还可以是根据需要灵活定义的特定区域。特定区域可以是一个城市中的一个区，或者是部分小区，或者是某个大厦，或者是某个园区，或者某个市场，对此不做限定。若地域属性指向城市E，则可以确定当前健康服务需求为城市E中对用户健康状态的服务需求。假设城市E对用户健康状态的服务需求是：如果用户去过城市E中的特定区域，则确定用户为健康高风险等级；如果用户没去过城市E中的特定区域，但与去过该特定区域中的其它用户有密切接触，则确定用户为健康中风险等级；如果用户没有去过城市E中的特定区域，且也未密切接触过去过该特定区域中的其它用户，则确定用户为健康低风险等级。则与当前健康服务需求适配的多级健康服务，其服务逻辑为：获取用户的移动轨迹，并获取用户密切接触过的其它用户的信息以及其它用户的移动轨迹；根据用户的移动轨迹，判断用户是否去过城市E中的特定区域；并根据用户密切接触过的其它用户的移动轨迹，判断用户密切接触过的其它用户是否去过城市E中的特定区域；如果判断出用户去过城市E中的特定区域，则确定用户为健康高风险等级；如果判断出用户没去过城市E中的特定区域，但其密切接触过的其它用户中有用户去过该特定区域，则确定用户为健康中风险等级；如果判断出用户没去过城市E中的特定区域，并且其密切接触过的其它用户也没去过该特定区域，则确定用户为健康低风险等级。

在另一可选实施例中，可以根据健康服务对应的时间属性确定当前健康服务需求。时间属性指的是健康服务需求中指向的时间信息，该时间信息表示需要使用健康服务的时期。时间属性可以用日期来表示，例如在1月21日-2月21日之间，或者是自3月1日开始直至现在，对此不做限定。若时间属性指向自3月1日开始直至现在，则可以确定当前健康服务需求为全域范围内自3月1日之后对用户健康状态的服务需求。假设全域范围内自3月1日之后对用户健康状态是：如果用户在3月1日之后去过城市F，则确定用户为健康高风险等级；如果用户在3月1日之后没去过城市F，但与在3月1日之后去过城市F的其它用户有密切接触，则确定用户为健康中风险等级；如果用户在3月1日之后没有去过城市F，且也未密切接触过在3月1日之后去过城市F的其它用户，则确定用户为健康低风险等级。则与当前健康服务需求适配的多级健康服务，其服务逻辑为：获取用户在3月1日之后的移动轨迹，并获取用户密切接触过的其它用户的信息以及其它用户在3月1日之后的移动轨迹；根据用户在3月1日之后的移动轨迹，判断用户在3月1日之后是否去过城市F；并根据用户密切接触过的其它用户在3月1日之后的移动轨迹，判断用户密切接触过的其它用户在3月1日之后是否去过城市F；如果判断出用户在3月1日之后去过城市F，则确定用户为健康高风险等级；如果判断出用户在3月1日之后没去过城市F，但其密切接触过的其它用户中有用户在3月1日之后去过城市F，则确定用户为健康中风险等级；如果判断出用户在3月1日之后没去过城市F，且其密切接触过的其它用户在3月1日之后也没去过城市F，则确定用户为健康低风险等级。

在又一可选实施例中，可以根据健康服务对应的应用场景确定当前健康服务需求。应用场景指的是健康服务需求中指向的应用场景，即需要使用健康服务的应用场景。例如，健康服务需求中指向的应用场景可以是职业场景，可以包括但不限于：厨师、化妆师、家政、航空服务。又例如，健康服务需求中指向的应用场景可以是就医场景。假设在就医场景中对用户健康状态的服务需求是：如果用户看过发热门诊，则确定用户为健康高风险等级；如果用户没有看过发热门诊，但与看过发热门诊的其它用户有过密切接触，则确定用户为健康中风险等级；如果用户没有看过发热门诊，且也未与看过发热门诊的其它用户有过密切接触，则确定用户为健康低风险等级。则与当前健康服务需求适配的多级健康服务，其服务逻辑为：获取用户的就诊记录，并获取用户密切接触过的其它用户的信息以及其它用户的就诊记录；根据用户的就诊记录，判断用户是否看过发热门诊；并根据用户密切接触过的其它用户的就诊记录，判断用户密切接触过的其它用户是否看过发热门诊；如果判断出用户看过发热门诊，则确定用户为健康高风险等级；如果判断出用户没看过发热门诊，但其密切接触过的其它用户中有看过发热门诊，则确定用户为健康中风险等级；如果判断出用户没看过发热门诊，并且其密切接触过的其它用户也没看过发热门诊，则确定用户为健康低风险等级。

在又一可选实施例中，可以根据健康服务对应的地域属性、时间属性和应用场景确定当前健康服务需求。例如，当前地域属性指向城市H中的海鲜市场J，时间属性指向自6月1日之后的时期，应用场景指向厨师和快递这两个职业场景，则可以确定当前健康服务需求为城市H在6月1日之后对与海鲜市场J有过接触的厨师和快递员的健康状态的服务需求。假设城市H对用户健康状态的服务需求是：如果用户的职业是厨师或快递员，且在6月1日之后去过城市H中的海鲜市场J，则确定用户为健康高风险等级；如果用户的职业是厨师或快递员，且在6月1日之后没有去过城市H中的海鲜市场J，但密切接触过在6月1日之后去过城市H中的海鲜市场J的其它用户，则确定用户为健康中风险等级；如果用户的职业是厨师或快递员，且在6月1日之后没有去过城市H中的海鲜市场J，且没有密切接触过在6月1日之后去过城市H中的海鲜市场J的其它用户，则确定用户为健康低风险等级。则与当前健康服务需求适配的多级健康服务，其服务逻辑为：获取职业是厨师或快递员的用户在6月1日之后的移动轨迹，并获取职业是厨师或快递员的用户密切接触过的其它用户的信息以及其它用户在6月1日之后的移动轨迹；根据职业是厨师或快递员的用户在6月1日之后的移动轨迹，判断职业是厨师或快递员的用户在6月1日之后是否去过城市H中的海鲜市场J；并根据职业是厨师或快递员的用户密切接触过的其它用户在6月1日之后的移动轨迹，判断职业是厨师或快递员的用户密切接触过的其它用户在6月1日之后是否去过城市H中的海鲜市场J；如果判断出职业是厨师或快递员的用户在6月1日之后去过城市H中的海鲜市场J，则确定该用户为健康高风险等级；如果判断出职业是厨师或快递员的用户在6月1日之后没去过城市H中的海鲜市场J，但其密切接触过的其它用户中有用户在6月1日之后去过城市H中的海鲜市场J，则确定该用户为健康中风险等级；如果判断出职业是厨师或快递员的用户在6月1日之后没去过城市H中的海鲜市场J，且其密切接触过的其它用户在6月1日之后也没去过城市H中的海鲜市场J，则确定该用户为健康低风险等级。

无论是需要关注用户健康状态的地域发生变化(例如有新的城市需要关注用户健康状态)，还是需要关注用户健康状态的应用场景发生变化(例如需要增加新的应用场景)，还是需要关注用户健康状态的时期发生变化(例如从1月份调整为6月份)，配置设备102均可确定当前健康服务需求；获取与当前健康服务需求适配的多级健康服务，并在服务端设备101上配置与当前健康服务需求适配的多级健康服务。相应地，服务端设备101可以调用配置设备102动态配置的多级健康服务为至少一个用户生成健康码信息。其中，至少一个用户可以是与当前健康服务需求对应的用户群体，例如可以是处于或进入当前健康服务需求中指向的地域范围(如城市E或F)内的用户，或者是当前健康服务需求中指向的应用场景中的用户(如厨师、快递员等)。

无论生成健康码信息所需的多级健康服务如何变化，对用户来说其申请健康码信息的过程是相同的，且对不同用户来说，其申请健康码信息的过程也是相同的，基于此，以第一用户为例对申请健康码信息的过程进行说明，第一用户属于上述至少一个用户，或者说，上述至少一个用户包含第一用户。第一用户可以通过其终端设备103向服务端设备101发送第一服务请求，则服务端设备101可以接收来自第一用户的第一服务请求，并根据第一服务请求向第一用户返回其健康码信息，第一用户的终端设备103可以接收服务端设备101返回的第一用户的健康码信息并展示该健康码信息。其中，第一服务请求是指向服务端设备101请求健康码信息的服务请求。

在此说明，在本申请实施例中，服务端设备101可以预先调用多级健康服务为第一用户生成健康码信息，之后在接收到来自第一用户的第一服务请求的情况下，可以直接根据第一服务请求，获取预先生成的健康码信息并返回给第一用户。或者，服务端设备101也可以在接收到来自第一用户的第一服务请求的情况下，实时地调用多级健康服务为第一用户生成健康码信息，并将实时生成的健康码信息返回给第一用户。

无论是上述哪种实施方式，第一服务请求中包含第一用户的标识信息，服务端设备101从第一服务请求中解析出第一用户的标识信息，根据第一用户的标识信息，确定需要获取第一用户的健康码信息，而不是其它用户的健康码信息，进而向第一用户返回其健康码信息。第一用户的标识信息可以是第一用户的注册账号、手机号码或邮箱等任何可以唯一标识用户的信息。

在本申请各实施例中，并不对多级健康服务的级数进行限定，例如可以是2级、3级、5级等，可根据对生成健康码信息的过程的阶段划分而定。在一可选实施例中，将生成健康码信息的过程划分为两个阶段，一个阶段是数据获取阶段，一个是数据聚合阶段；其中，数据获取阶段负责获取生成健康码信息所需依赖用户在至少一个健康关联维度上的数据。数据聚合阶段主要负责根据数据获取阶段所获取的用户在至少一个健康关联维度上的数据记录对用户健康状态进行判断，根据判断结果生成健康码信息。其中，健康关联维度是指与对用户健康状态有影响的数据维度，例如可以是移动轨迹维度、就医维度、职业维度或居住地维度等。基于此，如图2所示，多级健康服务包括两级健康服务，第一级健康服务包括至少一个数据提供服务，第二级健康服务是级联于至少一个数据提供服务之后的数据聚合服务。在图2中，以5个数据提供服务a1-a5以及一个数据聚合服务b1为例进行图示，但并不限于此。其中，每个数据提供服务负责获取用户在一个健康关联维度上的数据记录，数据提供服务的数量由健康服务需求中要求的健康关联维度的数量而定；对应于不同健康关联维度的数据提供服务，其获取数据记录的服务逻辑会有所不同。在多级健康服务包括至少一个数据提供服务，以及级联于至少一个数据提供服务之后的数据聚合服务的情况下，服务端设备101为用户生成健康码信息的过程包括：对至少一个用户中的任一用户，服务端设备101可以通过至少一个数据提供服务获取用户在至少一个健康关联维度上的数据记录；由数据聚合服务根据用户在至少一个健康关联维度上的数据记录，生成用户的健康码信息。

在本实施例中，数据提供服务的实现形态可以是原子服务(atomic service)，也可以是合成服务(composite service)，对此不做限定。其中，原子服务指的是不能再分解为更细粒度的服务，指的是一个健康关联维度上的服务，例如单一提供就诊记录的服务或单一提供运动轨迹的服务等。合成服务指的是由其它服务组合而成的服务，指的是至少两个健康关联维度上的服务，例如即可以提供就诊记录又可以提供运动轨迹的服务。数据聚合服务指的是聚集并整合至少一个健康关联维度上的数据记录，将至少一个健康关联维度上的数据记录有机的结合在一起，用于生成健康码的服务，其实现形态可以是聚合服务。

在一可选实施例中，在数据提供服务为多个的情况下，一旦某一个或几个数据提供服务出现故障，可能导致用户申请健康码信息的服务请求堆积，耗尽服务端设备101的资源，进而致使整个健康状态提供服务不可用。为了避免发生前述问题，可以对多个数据提供服务进行资源隔离，数据提供服务之间彼此隔离，相互不受影响，一个数据提供服务故障不会影响其它数据提供服务，整个健康状态提供服务可正常运行。基于此，配置设备102还可以为多个数据提供服务配置资源隔离参数。相应地，服务端设备101可以根据资源隔离参数在多个数据提供服务之间实现资源隔离。其中，资源隔离参数是与实现资源隔离相关的参数。

在本申请实施例中，并不限定所采用的资源隔离方式，例如可以采用基于线程池的隔离方式，也可以采用基于信号量的隔离方式，或者也可以同时采用这两种资源隔离方式。其中，基于线程池的隔离方式会为每个数据提供服务分配一个线程池，将依赖同一数据提供服务的所有访问请求全部分配到该数据提供服务对应的线程池中，而不会去用其他线程池中的线程资源，实现资源隔离。基于线程池的隔离方式适合绝大多数场景，例如可应用于需要发起API调用请求的数据提供服务。基于信号量的隔离方式会为每个数据提供服务分配其能够同时处理的最大访问数量，当对某一数据提供服务的访问达到其能够同时处理的最大访问数量时，其它访问请求都会被拒绝，达到资源隔离和限流保护的目的。基于信号量的隔离方式内存开销较小，比较适合不需要发起API调用请求的数据提供服务。

进一步，在本实施例中，可以将本实施例中的数据提供服务划分为依赖第三方服务的数据提供服务和不依赖第三方服务的数据提供服务。其中，依赖第三方服务的数据提供服务指的是通过API调用第三方服务才能获取用户在某个或某些健康关联维度上的数据记录的服务形态。不依赖第三方服务的数据提供服务指的是无需通过API调用第三方服务即可获取用户在某个或某些健康关联维度上的数据记录的服务形态，例如可以直接从服务端设备101本地内存或硬盘上获取用户在某个或某些健康关联维度上的数据记录。可选地，配置设备102可以为不依赖第三方服务的数据提供服务配置基于信号量的隔离方式及其参数，并为依赖第三方服务的数据提供服务配置基于线程池的隔离方式及其参数。需要说明的是，若依赖第三方服务的数据提供服务的性能比较稳定，该数据提供服务也可以采用基于信号量的隔离方式，对此不做限定。

在本实施例中，基于信号量的隔离方式所需的参数可以是但不限于：信号量的数量n1、平均响应时间或超时比例等。信号量的数量指的是允许数据提供服务同时可并发处理的访问请求的数量，例如可以是5个、10个或20个等，对此不做限定。平均响应时间指的是数据提供服务处理n1个访问请求需要满足的平均响应时间，例如可以是100ms、200ms或300ms等，对此不做限定。超时比例指的是数据提供服务处理每个用户的访问请求所需要的时间超出平均响应时间的时间占平均响应时间的比例，例如超时比例可以是但不限于30％、40％或50％等。基于线程池的隔离方式所需的参数包括但不限于：线程池中线程的数量n2、平均响应时间或超时比例。线程的数量指的是线程池中可支持线程的最大数量，例如可以是5个、10个或20个等，对此不做限定。基于此，允许数据提供服务同时支持的访问请求的最大数量为数据提供服务线程池中线程的数量。平均响应时间指的是数据提供服务处理n2个访问请求需要满足的平均响应时间，例如可以是100ms、200ms或300ms等，对此不做限定。超时比例指的是数据提供服务处理每个用户的访问请求所需要的时间超出平均响应时间的时间占平均响应时间的比例，例如超时比例可以是但不限于30％、40％或50％等。在此说明，访问请求是指服务端设备101需要调用数据提供服务为用户生成健康码信息时向数据提供服务发起的访问请求，也可以称为对数据提供服务的调度请求。可选地，如果服务端设备101根据用户发起的服务请求为用户实时生成健康码信息，则该访问请求也可以是用户发起的服务请求。

进一步，在配置基于信号量或基于线程池的隔离方式的情况下，还可以为每个数据提供服务配置熔断降级处理参数，以便于在调度给数据提供服务的服务请求量达到配置的访问请求的最大数量时，通过对数据提供服务进行熔断或降级处理来缓解数据提供服务的压力。熔断指的是某个数据提供服务故障或异常，若特定条件被触发，则直接熔断该数据提供服务。例如，当某一数据提供服务处理访问请求的实际平均时长超过配置的平均响应时间，则针对该数据提供服务触发熔断机制，或者当某一数据提供服务处理访问请求的超时比例超过配置的超时比例，则针对该数据提供服务触发熔断机制。熔断时间指的是当某一数据提供服务发生异常或故障时，该数据提供服务从阻断状态到再次恢复正常状态所间隔的时长，熔断时间可以是但不限于2s、3s或5s等。降级指的是在数据提供服务需要处理的访问请求数量超过其所支持的最大访问请求数量阈值时，可以降级处理，以拒绝超过最大访问请求数量阈值的访问请求，以达到限流的目的。

例如，在图2中，以数据提供服务是5个为例，其中，数据提供服务a1采用基于线程池的隔离方式，隔离参数是线程池最多可支持的线程数量为10，平均响应时间为200ms，熔断时间是5s；数据提供服务a2采用基于线程池的隔离方式，隔离参数是线程的数量为20，超时比例为40％，熔断时间是3s；数据提供服务a3采用基于线程池的隔离方式，隔离参数是线程池最多可支持的线程数量为20，平均响应时间为300ms，熔断时间是5s；数据提供服务a4采用基于信号量的隔离方式，隔离参数是数据提供服务a4所支持的最大信号量的数量为20，超时比例为50％，熔断时间是5s；数据提供服务a5采用基于信号量的隔离方式，隔离参数是数据提供服务a5所支持的最大信号量的数量为10，平均响应时间为200ms，熔断时间是5s。具体地，服务端设备101会调用数据提供服务a1-a5为多个用户提供数据获取服务。

下面以数据提供服务a1和a5为例，对服务端设备101基于线程池或基于信号量的隔离方式利用数据提供服务a1和a5获取用户在2个健康关联维度上的数据记录的过程进行示例性说明。对于数据提供服务a1，在同一时间，数据提供服务a1最多可以为10个用户，获取与数据提供服务a1对应的健康关联维度上的数据记录。假设服务端设备101在接收到用户的服务请求时为用户生成健康码信息，则当有用户的服务请求到被调度到线程池K1中时，如果线程数量还未达到上限，则为该用户启动一个线程；如果线程数量达到上限，则对该线程池K1进行降级处理，即拒绝后续的服务请求。需要说明的是，对线程池K1进行降级处理，不会影响到其它数据提供服务中的线程池。

需要说明的是，在基于线程池的隔离方式中也支持熔断处理，即在某一数据提供服务的线程池出现异常或故障时，例如，当该线程池中所有线程处理服务请求的平均时长超过平均响应时间，或者实际超时比例超过设置的超时比例时，服务端设备101会对出现异常的线程池进行熔断处理。

对于数据提供服务a5，在同一时间，数据提供服务a5最多可以为10个用户获取与数据提供服务a5对应的健康关联维度上的数据记录，即允许数据提供服务a5同时处理用户服务请求的数量为10，服务端设备101通过监听数据提供服务a5同时处理的服务请求的数量(即信号量的数量)，当监听到的信号量的数量达到设定的信号量阈值(例如10)时，服务端设备101会对该数据提供服务a5进行降级处理，则数据提供服务a5会拒绝后续服务请求，以达到限流保护的作用。若此时服务端设备101维护的数据提供服务a5发生异常或故障，则在出现异常或故障5s后，服务端设备101对该数据提供服务a5进行熔断处理。

在本申请一些实施例中，至少一个数据提供服务包括本地内置服务和/或自定义服务。至少一个数据提供服务可以只包括本地内置服务，也可以只包括自定义服务，也可以同时包含本地内置服务和自定义服务。如图2所示，至少一个数据提供服务同时包含本地内置服务和自定义服务，其中数据提供服务a1和数据提供服务a2为本地内置服务，数据提供服务a3-a5为自定义服务。

其中，本地内置服务是指服务端设备101中默认存在的数据提供服务，即可以直接使用的数据提供服务，本地内置服务可以是与任何健康关联维度对应的服务，例如可以是提供医疗就诊记录的服务(简称为就医服务)、提供移动轨迹记录的服务或提供出入境记录的服务等，对此不做限定。自定义服务指的是健康服务需求方可以根据本端的健康服务需求，自定义的数据提供服务。自定义服务也可以是与任何健康关联维度对应的服务，例如可以是提供医疗就诊记录的服务、提供移动轨迹记录的服务、提供出入境记录的服务等，也可以是提供居住地信息的服务、提供是否接触过特定人群的服务，或者提供是否去过特定地点的服务等，对此不做限定。可选地，可以从健康关联维度中选择一些对不同健康服务需求方来说具有共性的目标健康关联维度，将与所选择的目标健康关联维度对应的服务实现为本地内置服务，将与未被选择的其它健康关联维度对应的服务实现为自定义服务，这些服务逻辑具体可由各健康服务需求方根据自身或本端的健康服务需求自行定义。需要说明的是，在同时包含本地内置服务和自定义服务的情况下，本地内置服务和自定义服务对应的健康关联维度不重叠。

无论是本地内置服务还是自定义服务，都可以是依赖第三方服务，也可以不依赖第三方服务的数据获取服务。第三方服务可以包含但不限于：就医查询服务、移动轨迹查询服务、居住信息查询服务、办公信息查询服务以及关联用户状态查询服务等。其中，就医查询服务用于查询用户的就诊记录，例如用户去过哪个医院、在哪个门诊挂过号以及用户的病例信息等。移动轨迹查询服务用于查询用户的移动轨迹，例如，通过用户终端设备上的定位功能可获取用户手机的移动轨迹，或者也可以通过定位服务提供商获取用户的移动轨迹。居住地信息查询服务用于查询用户的居住地信息，例如用户居住在哪个小区、小区位置等。办公信息查询服务用于查询与用户工作相关的信息，例如用户的办公地点或用户的同事等。关联用户状态查询服务用于查询与用户有关联的其它人的信息，例如与用户共同居住的室友信息或与用户共同居住的家人信息。

其中，本地内置服务和自定义服务的配置过程有差异，下面对本地内置服务和自定义服务的配置过程进行说明：

在本实施例中，在至少一个数据提供服务包含本地内置服务的情况下，本地内置服务可以是依赖第三方服务的，也可以是不依赖第三方服务的，对此不做限定。其中，若本地内置服务依赖第三方服务，则服务端设备101上内置有本地内置服务所依赖的第三方服务的服务器域名，这样当服务端设备101调用本地内置服务时，可以直接基于该服务器域名访问本地内置服务所依赖的第三方服务，从而获取用户在相应健康关联维度上的数据记录。若本地内置服务不依赖第三方服务，则指定数据库中存储有本地内置服务对应的脚本文件，且服务端设备101上配置有该脚本文本在指定数据库中的脚本ID，这样当服务端设备101调用本地内置服务时，可以直接基于该脚本ID调用指定数据库中本地内置服务对应的脚本文件，从而获取用户在相应健康关联维度上的数据记录。

其中，对于一些内存量占用较小，而访问量又很频繁的健康关联维度上的数据记录，可以预先生成用于获取这些健康关联维度上的数据记录的脚本文件，内置在本地数据库中。优选地，脚本文件可以实现为Groovy脚本，Groovy是一种基于Java虚拟机的开发语言，它结合了Python、Ruby和Smalltalk的许多强大的特性，Groovy代码能够与Java代码很好地结合，也能用于扩展现有代码。

可选地，对于本地内置服务，服务端设备101可以提供是否使用本地内置服务的配置功能，健康服务需求方可通过开启或关闭本地内置服务来配置是否使用本地内置服务。例如，服务端设备101可以提供一个配置界面，服务需求方可在其使用的终端设备上访问该配置界面，该配置界面上设有打开或者关闭的配置控件，通过该配置控件可以选择是否使用本地内置服务。若服务需求方选择打开该配置控件，则表示使用本地内置服务；若服务需求方选择关闭该配置控件，则表示不使用本地内置服务，对此不做限定。

在本实施例中，在至少一个数据提供服务包含自定义服务的情况下，一种配置自定义服务的实施方式，包括：若自定义服务依赖第三方服务，则在服务端设备上配置第三方服务的服务器域名，以供服务端设备通过API访问第三方服务；若自定义服务不依赖第三方服务，则上传自义定服务对应的脚本文件至指定数据库中，并在服务端设备上配置脚本文件在指定数据库中的脚本ID，以供服务端设备调用自定义服务。

进一步可选地，无论采用何种配置方式，在服务端设备上配置自定义服务之前，还可以接收健康事件发生方上报的服务配置请求，该服务配置请求中包括事件详情信息；进而，根据事件详情信息生成自定义服务；之后，可将该自定义服务配置在服务端设备上，以供服务需求方使用该自定义服务。其中，健康事件发生方是指发生健康事件的当事方或与健康事件紧密相关的人员，例如假设A地区发生疫情，则A地区的相关人员可作为健康事件发生方向其上级政府部门(相当于服务需求方)发送服务配置请求，以请求针对A地区发生的疫情提供健康服务；服务需求方接收到健康事件发生方上报的服务配置请求之后，从服务配置请求中解析出事件详情信息，根据事件详情信息确定需要哪些维度的数据记录以及如何处理等，据此生成自定义服务，将自定义服务配置在服务端设备上，由服务端设备针对A地区发生的疫情提供针对性地健康服务。其中，事件详情信息包括事件发生时间、发生地点、事件涉及的相关人员、事件的严重等级，等等。

进一步可选地，对于自定义服务，无论是通过服务端设备提供的配置界面进行配置，还是由配置设备102进行配置，一种自定义服务的详细配置过程包括如下操作：

响应于服务配置操作，展示服务配置界面，该服务配置界面上包含自定义服务是否依赖第三方服务的第一配置项；服务需求方可以通过第一配置项配置自定义服务是否依赖第三方服务。例如，第一配置项可以是下拉列表的形式，下拉列表中包括依赖和不依赖两个选项，服务需求方可以通过选择依赖或不依赖选项，从而配置自定义服务是否依赖第三方服务。又例如，第一配置项也可以是文本输入框，服务需求方可以在该文本输入框内输入文字依赖或不依赖，从而配置自定义服务是否依赖第三方服务。又例如，第一配置项也可以包括依赖和不依赖两个选项，用户可以通过勾选或点选的方式选择依赖或不依赖选项，从而配置自定义服务是否依赖第三方服务的。无论是何种方式，服务需求方都需要对第一配置项发起配置操作，基于此，可响应于对第一配置项的配置操作，获取自定义服务是否依赖第三方服务的配置信息。

进一步，若自定义服务依赖第三方服务，则显示用于配置第三方服务的服务域名的第二配置项；第二配置项用于供服务需求方配置第三方服务的服务器域名，其可以是文本输入框；服务需求方可以在文本输入框内输入第三方服务的服务器域名。基于此，响应于对第二配置项的配置操作，获取第三方服务的服务器域名，以供访问第三方服务，至此完成对依赖第三方服务的自定义服务的配置。

进一步，若自定义服务不依赖第三方服务，则显示脚本文件上传控件和脚本ID配置项；脚本文本上传控件用于供服务需求方上传自定义服务的脚本文件；脚本ID配置项用于供服务需求方配置自定义服务的脚本ID，以便于获取自定义服务对应的脚本文件。基于此，一方面可响应对脚本文件上传控件的触发操作，上传自定义服务对应的脚本文件至指定数据库中；另一方面可响应对脚本ID配置项的配置操作，获取脚本文件在指定数据库中的脚本ID，以供调用该自定义服务，至此完成对不依赖第三方服务的自定义服务的配置。

在本实施例中，配置设备102除了可以对至少一个数据提供服务进行动态配置以外，还可以动态配置数据聚合服务。可选地，数据聚合服务可以是本地内置的，也可以是健康服务需求方自定义的。另外，无论数据聚合服务是本地内置的还是自定义的，可以依赖第三方服务，也可以不依赖第三方服务。数据聚合服务所依赖的第三方服务是指可以进行聚合计算的服务，在功能上，与数据提供服务所依赖的第三方服务并不相同。其中，对数据聚合服务进行配置的过程，与对数据提供服务进行配置的过程相同或相似，具体内容可参见前述实施例，在此不再赘述。在数据聚合服务为自定义服务的情况下，其详细配置过程与自定义的数据提供服务的详细配置过程相同或相似，可参见前述实施例，在此不再赘述。

在配置好至少一个数据提供服务以及数据聚合服务之后，服务端设备101可以按照设定的健康码信息生成时间，例如每天晚上10点或每天凌晨1点等，或者，在接收到用户发起的第一服务请求时，调用至少一个数据提供服务获取用户在至少一个健康关联维度的数据记录；然后，调用数据聚合服务，由数据聚合服务根据用户在至少一个健康关联维度上的数据记录，生成用户的健康码信息。

在本实施例中，一种由数据聚合服务根据用户在至少一个健康关联维度上的数据记录，生成用户的健康码信息的实施方式，包括：由数据聚合服务根据至少一个健康关联维度上的健康状态判定条件和用户在至少一个健康关联维度上的数据记录进行聚合判断，得到用户的健康状态信息；根据用户的健康状态信息和用户的标识信息，生成用户的健康码信息。

在本实施例中，并不对至少一个健康关联维度上的健康状态判定条件进行限定，根据用户在至少一个健康关联维度上的数据记录的不同，该健康状态判定条件也有所不同。例如，在移动轨迹维度上，若用户在该维度的数据记录为用户的移动轨迹，则健康状态判定条件可以是判断用户是否去过某个城市，也可以是判断用户是否去过某一地区，还可以是判断用户是否去过某一小区等，对此不做限定。又例如，在就诊记录维度上，若用户在该维度的数据记录为用户的就诊记录，则健康状态判定条件可以是判断用户是否去过医院，也可以是判断用户是否去过某一特定门诊，对此不做限定。需要说明的是，健康状态判定条件可以按照不用的应用场景或者可以根据不同的需求灵活的设定。

在本实施例中，并不对数据聚合服务根据至少一个健康关联维度上的健康状态判定条件和用户在至少一个健康关联维度上的数据记录进行聚合判断，得到用户的健康状态信息的实施方式进行限定。例如，若用户在全部健康关联维度都符合健康状态判定条件，则用户的健康状态信息为健康低风险；若用户在一个健康关联维度不符合健康状态判定条件，则用户的健康状态信息为健康中风险；若用户在两个及以上的健康关联维度不符合健康状态判定条件，则用户的健康状态信息为健康高风险。又例如，若用户在全部健康关联维度都符合健康状态判定条件，则用户的健康状态信息为健康；若用户在一个及以上健康关联维度不符合健康状态判定条件，则用户的健康状态信息为不健康。

在本实施例中，一种根据用户的健康状态信息和用户的标识，生成用户的健康码信息的实施方式，包括：根据用户的健康状态信息确定用户的健康码颜色；生成包含健康码颜色和用户的标识信息的健康码信息。

在本实施例中，并不限定根据用户的健康状态信息确定用户的健康码颜色的实施方式。例如，若用户的健康状态信息为健康低风险，则健康码颜色可以为绿色；若用户的健康状态信息为健康中风险，则健康码颜色可以为黄色；若用户的健康状态信息为健康中风险，则健康码颜色可以为红色。又例如，若用户的健康状态信息为健康，则健康码颜色可以为蓝色；若用户的健康状态信息为不健康，则健康码颜色可以为黄色，对此不做限定。

在本实施例中，并不限定健康码的实现形态，例如可以是二维码形式，也可以是一个“箭头”的图案形式，还可以是带有用户健康状态信息的配置控件，对此不做限定。

在本实施例中，第一用户可以向服务端设备101发送第一服务请求，服务端设备101根据第一服务请求向第一用户返回健康码信息。一种根据第一服务请求向第一用户返回其健康码信息的实施方式，包括：从第一服务请求中解析出第一用户的标识信息和面部图像；根据第一用户的标识信息，从至少一个用户的健康码信息中获取第一用户的健康码信息；将第一用户的健康码信息和第一用户的面部图像组合后返回给第一用户。

可选地，将第一用户的健康码信息、第一用户的面部图像以及第一用户的标识信息组合后返回给第一用户并展示。在本实施例中，并不限定第一用户的健康码信息、第一用户的面部图像以及第一用户的标识信息的组合方式。例如可以是第一用户的面部图像位于最上方，第一用户的健康码信息位于中间，第一用户的标识信息位于最下方；还可以是第一用户的健康码信息位于最上方，第一用户的标识信息位于中间，第一用户的面部图像位于最下方，对此不做限定。进一步可选地，在展示用户的标识信息时，为了确保用户的信息安全，保护用户的隐私，在将第一用户的标识信息返回给第一用户时，会对第一用户的标识信息进行糊化或者隐藏处理。

进一步，在一些可选实施例中，服务端设备除了生成健康码颜色之外，还可以生成与健康码颜色对应的原因信息，并将该原因信息返回给第一用户的终端设备，以供该终端设备展示给用户。例如，在健康码颜色为红色的情况下，返回的原因信息可以是第一用户在过去14天内去过高风险地区如F城市；在健康码为绿色的情况下，返回的原因信息可以是第一用户在过去14天内未离开过居住的城市G；在健康码为黄色的情况下，返回的原因信息可以是第一用户在过去14天内离开过居住的城市G，但并未去过高风险地区如F城市，等等。这里的原因信息仅以第一用户的移动轨迹为例进行说明，但并不限于此，例如还可以结合第一用户的就医状况，以及其家庭相关人员的轨迹、就医状况等信息。

在服务端设备返回健康码信息以及与健康码信息中的健康码颜色对应的原因信息的情况下，从第一用户终端设备的角度来看，向服务端设备发送第一服务请求之后，可接收服务端设备返回的第一用户的健康码信息以及与该健康码信息中的健康码颜色对应的原因信息；之后，在健康码界面上展示健康码信息以及与健康码颜色对应的原因信息。其中，健康码信息包括健康码颜色和第一用户的标识信息，进一步，还可以包括第一用户的面部图像(即人脸图像)。

更进一步，在健康码界面上还可以包括：与上述原因信息对应的申诉控件，以供第一用户在发现该原因信息不准确或存在错误的情况下针对该原因信息发起申诉。在第一用户需要针对该原因信息发起申诉时，可以触发健康码界面上的申诉控件；终端设备可响应第一用户对申诉控件的触发操作，向服务端设备或健康服务需求方发送申诉请求，以针对该原因信息发起申诉。这有利于保证用户合法权益，便于提高用户体验和服务质量。该申诉控件可以是一个按钮，也可以是指向申诉页面的链接。进一步，第一用户点击该按钮或链接后，可展示申诉界面；第一用户可以在该申诉界面上输入申诉理由，并可提交相关证明材料等。进一步，健康服务需求方或服务端设备在审核通过的情况下，还可以更新或调整第一用户的健康码信息。

下面如图3a所示，以第三方服务是移动轨迹服务、居住地服务和就医服务为例，对提供健康码信息的整个服务过程进行详细描述。

在本实施例中，服务端设备101接收到来自第一用户的第一服务请求的情况下，实时地调用多级健康服务为第一用户生成健康码信息，并将实时生成的健康码信息返回给第一用户。其中，多级健康服务包括3个数据提供服务和1个数据聚合服务。3个数据提供服务中，移动轨迹服务和就医服务为依赖第三方服务的本地内置服务，居住地服务为不依赖第三方服务的自定义服务。服务端设备101可以调用移动轨迹服务、就医服务和居住地服务分别获取第一用户在3个健康关联维度上的数据记录，即第一用户的移动轨迹、第一用户的就诊记录以及第一用户的居住地信息。

在本实施例中，在这三个健康关联维度中，健康状态判定条件为用户的移动轨迹是否指示用户去过小区M、用户的就医记录是否指示用户去过发热门诊以及用户的居住地信息是否指示用户居住在小区N。若三个健康关联维度中，用户的健康状态判定条件全部为“否”，则确定用户的健康状态信息为健康低风险或无风险；若在三个健康关联维度中，用户的健康状态判定条件由一个为“是”，则确定用户的健康状态信息为健康中风险；若在三个健康关联维度中，用户的健康状态判定条件由两个或三个为“是”，则确定用户的健康状态信息为健康高风险。关于健康风险等级与判定条件之间的关系并不限于这里列举的一种。例如，若用户去过小区M，不论其他两个健康关联维度上的判断结果如何，可直接确定用户的健康状态信息为健康高风险；若用户没有去过小区M，且其他两个健康关联维度中一个判断结果为是，另一个判断结果为否，则确定用户的健康状态信息为健康中风险；若用户没有去过小区M，且其他两个健康关联维度上的判断结果均为否，则确定用户的健康状态信息为健康低风险或无风险。

在本实施例中，若用户的健康状态信息为健康低风险或无风险，则确定健康码颜色为绿色；若用户的健康状态信息为健康中风险，则确定健康码颜色为黄色；若用户的健康状态信息为健康高风险，则确定健康码颜色为红色。

另外，服务端设备101可以从第一用户发送的第一服务请求中解析出第一用户的标识信息以及面部图像，根据第一用户的标识信息获取第一用户的健康码信息，进一步，将该健康码信息、第一用户的标识信息以及第一用户的面部图像一起返回给第一用户，第一用户在终端设备103上展示健康码信息、第一用户的标识信息以及第一用户的面部图像。第一用户的标识信息可以是任何可唯一标识第一用户的信息，例如手机号码、邮箱或注册账号等。

在本申请实施例中，配置设备102除了可以基于健康服务需求在服务端设备101上动态配置多级健康服务之外，还可以根据健康服务需求，在服务端设备101上动态配置其它健康服务，如图3b所示。其它健康服务可提供的服务内容和服务形式是区别于多级健康服务的，例如，其它健康服务可以包括但不限于以下至少一种：健康码信息查询服务、健康码信息核验服务和健康状态上报服务等，如图3b所示。

其中，健康码信息查询服务指的是查询健康码信息的服务，健康码信息可以包含但不限于颜色信息、用户信息或用户头像信息等。健康码信息核验服务指的是对健康码信息进行核验的服务，例如，可以校验用户展示的健康码信息是否准确，检验有无存在健康码欺诈等行为。健康状态上报服务指的是供用户或相关人员上报健康状态及健康状态相关信息的服务，例如可以上报用户的移动轨迹、用户的就医记录、用户的健康状态和/或用户的健康码信息等，对此不做限定。

基于上述，服务端设备还可以接收来自第二用户的第二服务请求；第二服务请求区别于第一服务请求，是指用于请求其它健康服务的服务请求；调用其它健康服务对第二服务请求进行处理，并向第二用户返回第二服务请求对应的服务结果；其中，至少一个用户包含第二用户。在本实施例中，第一用户与第二用户可以是同一用户，也可以不是同一用户。另外，根据所需其它健康服务的不同，第二用户可以是需要提供健康状态的用户，也可以是健康服务需求方，对此不做限定

可选地，第二服务请求中包含第二用户的标识信息，服务端设备101从第二服务请求中解析出第二用户的标识信息，根据第二用户的标识信息，向第二用户返回第二服务请求对应的服务结果，对此不做限定。第二用户的标识信息可以是第二用户的邮箱、手机号码或注册账号等，对此不做限定。

在一可选实施例中，为了更加方便的使用其它健康服务，配置设备102可以动态配置其它健康服务的自定义前置操作和/或自定义后置操作，如图3b所示。相应地，服务端设备101还可以利用自定义前置操作对第二服务请求进行前置处理；和/或，利用自定义后置操作对第二服务请求对应的服务结果进行后置处理。

其中，自定义前置操作和自定义后置操作可以是数据提供服务和数据聚合服务不必执行的大量的、繁杂的或重复的操作。例如，假设其它健康服务只能识别编码后的数据，自定义前置操作可以是编码操作，用于将第二服务请求编码后提供给其它健康服务；相应地，自定义后置操作可以是解码操作，用于将第二服务请求对应的服务结果解码成第二用户可理解的服务结果。又例如，假设其它健康服务只能识别具有标准输入数据结构的数据对象，则自定义后置操作可以是输入数据格式转换操作，用于将第二服务请求转换为标准输入数据结构后提供给其它健康服务；相应地，自定义后置操作为输出数据格式转换操作，用于将服务结果转换为标准输出数据结构。

图4a为本申请示例性实施例提供的一种健康服务方法的流程示意图，如图4a所示，该方法包括：

41a、基于健康服务需求，动态配置生成健康码信息所需的多级健康服务；

42a、调用多级健康服务为至少一个用户生成健康码信息；

43a、接收来自第一用户的第一服务请求，至少一个用户包含第一用户；

44a、根据第一服务请求向第一用户返回其健康码信息。

在一可选实施例中，基于健康服务需求，动态配置生成健康码信息所需的多级健康服务，包括：根据健康服务对应的地域属性、时间属性和/或应用场景，确定当前健康服务需求；获取与当前健康服务需求适配的多级健康服务，并配置与当前健康服务需求适配的多级健康服务。

在一可选实施例中，配置与当前健康服务需求适配的多级健康服务，包括：配置与当前健康服务需求适配的至少一个数据提供服务；配置与当前健康服务需求适配的数据聚合服务；其中，数据聚合服务级联于至少一个数据提供服务之后。

在一可选实施例中，调用多级健康服务为至少一个用户生成健康码信息，包括：对至少一个用户中的任一用户，通过至少一个数据提供服务获取用户在至少一个健康关联维度上的数据记录；由数据聚合服务根据用户在至少一个健康关联维度上的数据记录，生成用户的健康码信息。其中，数据提供服务为多个的情况下，可并发执行。

在一可选实施例中，至少一个数据提供服务包括本地内置服务和/或自定义服务；在至少一个数据提供服务包含自定义服务的情况下，配置与当前健康服务需求适配的至少一个数据提供服务，包括：若自定义服务依赖第三方服务，则配置第三方服务的服务器域名，以供访问第三方服务；若自定义服务不依赖第三方服务，则上传自义定服务对应的脚本文件至指定数据库中，并配置脚本文件在指定数据库中的脚本ID，以供调用自定义服务。

进一步可选地，上述配置自定义服务的详细过程包括：响应服务配置操作，展示服务配置界面，该服务配置界面上包含自定义服务是否依赖第三方服务的第一配置项；响应对第一配置项的配置操作，获取自定义服务是否依赖第三方服务的配置信息；若自定义服务依赖第三方服务，则显示用于配置第三方服务的服务域名的第二配置项；响应于对第二配置项的配置操作，获取第三方服务的服务器域名，以供访问第三方服务。更进一步，若自定义服务不依赖第三方服务，则显示脚本文件上传控件和脚本ID配置项；响应对脚本文件上传控件的触发操作，上传自定义服务对应的脚本文件至指定数据库中；以及响应对脚本ID配置项的配置操作，获取脚本文件在指定数据库中的脚本ID，以供调用自定义服务。

进一步可选地，在服务端设备上配置自定义服务之前，还包括：接收健康事件发生方上报的服务配置请求，所述服务配置请求包括事件详情信息；根据所述事件详情信息生成自定义服务。

在一可选实施例中，本地内置服务也包括依赖第三方服务的本地内置服务和/或不依赖第三方服务的本地内置服务；对至少一个用户中的任一用户，通过至少一个数据提供服务获取用户在至少一个健康关联维度上的数据记录，包括：基于第一服务对应的脚本ID，加载指定数据库中与第一服务对应的脚本文件，以获取用户在与第一服务对应的健康关联维度上的数据记录；和/或基于第二服务对应的服务器域名访问服务器域名指向的第三方服务，以获取用户在与第二服务对应的健康关联维度上的数据记录；其中，第一服务是指不依赖第三方服务的本地内置服务和/或自定义服务；第二服务是指依赖第三方服务的本地内置服务和/或自定义服务。

进一步可选地，第三方服务包括以下至少一个：就医查询服务、移动轨迹查询服务、居住信息查询服务、办公信息查询服务以及关联用户状态查询服务。

在一可选实施例中，由数据聚合服务根据用户在至少一个健康关联维度上的数据记录，生成用户的健康码信息，包括：由数据聚合服务根据至少一个健康关联维度上的健康状态判定条件和用户在至少一个健康关联维度上的数据记录进行聚合判断，得到用户的健康状态信息；根据用户的健康状态信息和用户的标识信息，生成用户的健康码信息。

在一可选实施例中，根据用户的健康状态信息和用户的标识，生成用户的健康码信息，包括：根据用户的健康状态信息确定用户的健康码颜色；生成包含健康码颜色和用户的标识信息的健康码信息。

在一可选实施例中，根据第一服务请求向第一用户返回其健康码信息，包括：从第一服务请求中解析出第一用户的标识信息和面部图像；根据第一用户的标识信息，从至少一个用户的健康码信息中获取第一用户的健康码信息；将第一用户的健康码信息和第一用户的面部图像组合后返回给第一用户。

进一步，在一可选实施例中，在健康码信息包含健康码颜色的情况下，还可以生成与该健康码颜色对应的原因信息，并将该原因信息返回给第一用户，以供用户获知该健康码颜色对应的原因信息。

在一可选实施例中，本实施例方法还包括：根据健康服务需求动态配置其它健康服务；接收来自第二用户的第二服务请求；调用其它健康服务对第二服务请求进行处理，并向第二用户返回第二服务请求对应的服务结果。

进一步可选地，本实施例方法还包括：动态配置其它健康服务的自定义前置操作和/或自定义后置操作；相应地，在调用其它健康服务对第二服务请求进行处理之前，还包括：利用自定义前置操作对第二服务请求进行前置处理；和/或在向第二用户返回第二服务请求对应的服务结果之前，还包括：利用自定义后置操作对第二服务请求对应的服务结果进行后置处理。

在一可选实施例中，其它健康服务包括以下至少一种：健康码信息查询服务、健康码信息核验服务和健康状态上报服务。

在一可选实施例中，至少一个用户包括处于或进入健康服务需求中指向的地域范围内的用户，或者是健康服务需求中指向的应用场景中的用户。

本申请实施例提供一种健康服务方法，由配置设备基于健康服务需求动态配置生成健康码信息所需的多级健康服务，服务端设备可以调用动态配置的多级健康服务为用户生成健康码信息，用户可以通过终端设备向服务端设备发起获取健康码信息的服务请求，从服务端设备得到健康码信息，实现对用户健康状态的智能化管理。其中，基于健康服务需求动态配置生成健康码信息所需的多级健康服务，可满足不同应用场景、不同地域和/或不同时段对用户健康状态的差异化需求，解决多种服务需求下的健康状态智能化管理问题，极大地降低健康服务的开发成本。

本申请实施例还提供一种健康码信息展示方法，如图4b所示，该方法包括：

41b、向服务端设备发送服务请求，以请求用户的健康码信息，健康码信息包括健康码颜色和用户的标识信息。

42b、接收服务端设备返回的健康码信息以及与健康码颜色对应的原因信息。

43b、在健康码界面上，展示健康码信息以及与健康码颜色对应的原因信息。

进一步，如图4b所示，该方法在步骤43b之后，还包括：

44b、响应用户对健康码界面上与原因信息对应的申诉控件的触发操作，向服务端设备或健康服务需求方发送申诉请求，以针对原因信息发起申诉。

在本实施例中，用户可以通过其终端设备向服务端设备请求其对应的健康码信息，该健康码信息包括健康码颜色和用户的标识信息；服务端设备可以向用户返回其健康码信息，进一步还可以向用户返回与其健康码信息中的健康码颜色对应的原因信息，以供用户获知该健康码颜色对应的原因信息。

更进一步，健康码界面上还会设置与原因信息对应的申诉控件，以便于用户在发现该原因信息不准确或存在错误的情况下针对该原因信息发起申诉。在用户需要针对该原因信息发起申诉时，可以触发健康码界面上的申诉控件；终端设备可响应用户对申诉控件的触发操作，向服务端设备或健康服务需求方发送申诉请求，以针对该原因信息发起申诉。这有利于保证用户合法权益，便于提高用户体验和服务质量。

可选地，上述申诉控件可以是一个按钮，也可以是指向申诉页面的链接。进一步，第一用户点击该按钮或链接后，可展示申诉界面；第一用户可以在该申诉界面上输入申诉理由，并可提交相关证明材料等。进一步，健康服务需求方或服务端设备在审核通过的情况下，还可以更新或调整第一用户的健康码信息。

本申请实施例还提供一种服务配置方法，该方法主要用于对自定义服务进行配置，如图4c所示，该方法包括：

41c、响应服务配置操作，展示服务配置界面，服务配置界面上包含自定义服务是否依赖第三方服务的第一配置项。

42c、响应对第一配置项的配置操作，获取自定义服务是否依赖第三方服务的配置信息。

43c、若自定义服务依赖第三方服务，则显示用于配置第三方服务的服务域名的第二配置项。

44c、响应于对第二配置项的配置操作，获取第三方服务的服务器域名，以供访问第三方服务。

进一步，如图4c所示，该方法还包括：

45c、若自定义服务不依赖第三方服务，则显示脚本文件上传控件和脚本ID配置项。

46c、响应对脚本文件上传控件的触发操作，上传自定义服务对应的脚本文件至指定数据库中。

47c、响应对脚本ID配置项的配置操作，获取脚本文件在指定数据库中的脚本ID，以供调用自定义服务。

进一步，在一可选实施例中，在配置自定义服务之前，还包括：接收健康事件发生方上报的服务配置请求，服务配置请求包括事件详情信息；根据事件详情信息生成自定义服务。

在此说明，本申请上述实施例提供的在用户健康领域中，基于健康服务需求动态配置多级健康服务以按需提供用户健康码信息的技术原理还可以拓展到其它具有状态码信息需求的领域中。例如，可以拓展到交通健康管理领域中，面向交通信息需求方提供车辆或车主的交通健康码。又例如，可以拓展到社区管理领域中，面向社区管理方提供社区人员的社区码信息，社区码信息可以根据应用需求表示社区人员的年龄、居住等各种状态。又例如，可以拓展到应急事务场景中，面向应急管理方提供应急场景中涉及到的人员或物体等应急对象的应急码信息，应急码信息可根据应用需求表示应急对象的各种应急状态。又例如，还可以拓展到工业危废品追踪场景中，面向监管方提供工业危废品的追踪码信息，追踪码信息可以根据应用需求表示工业危险品的各种处理状态。又例如，还可以拓展到卫健跟踪场景中，面向卫健管理方提供相关人员的卫健码信息；卫健码信息表示人员的卫生、健康状态。又例如，还可以拓展到企业经营管理领域中，面向企业监管方提供企业的许可码信息，许可码信息表示企业的经营状态。

鉴于上述，本申请实施例还提供一种码信息处理系统，该系统包括：服务端设备和至少一个终端设备；服务端设备，用于获取基于状态码服务需求动态配置的多级状态码服务，调用多级状态码服务为至少一个数据对象生成状态码信息；以及接收来自第一终端设备的第一服务请求，并根据第一服务请求向第一终端设备返回第一数据对象的状态码信息，第一数据对象属于至少一个数据对象；第一终端设备，用于向服务端设备发送第一服务请求，以及接收服务端设备返回的第一数据对象的状态码信息并展示；第一终端设备属于至少一个终端设备。

在本申请实施例中，数据对象是指与状态码信息相关的对象，可以是上述社区人员、车辆、应急对象、危废品或其它涉及卫生健康状态的相关人员等。在本实施例中，通过状态码信息表示数据对象的状态信息，在不同领域或场景中，状态码信息所表示的数据对象的状态信息会有所不同。在本实施例中，将为数据对象生成状态码信息的过程划分为多个阶段，每个阶段采用独立的状态码服务完成，相邻阶段中的状态码服务之间级联，即上一阶段中状态码服务的结果汇聚后作为下一阶段中状态码服务的输入，依次执行下去，直至最后一阶段中的状态码服务生成状态码信息。在本实施例中，按照生成状态码信息的多个阶段之间的关系，将生成状态码所需的状态码服务划分为多级，称为生成状态码码信息所需的多级状态码服务。

具体地，由服务端设备基于生成状态码信息所需的多级状态码服务，为数据对象生成表示数据对象某种状态的状态码信息；状态码信息需求方在需要某个或某些数据对象的状态码信息的情况下，可以通过终端设备向服务端设备发起获取状态码信息的服务请求，从服务端设备得到相关数据对象的状态码信息，进而基于得到的状态码信息开展与该数据对象相关的后续操作，例如跟踪、排查或定位等。在此说明，本实施例并不限定服务端设备和终端设备的设备形态，例如服务端设备可以是但不限于：常规服务器、云服务器或服务器阵列等；终端设备可以是但不限于：智能手机、平板电脑，台式电脑或智能电视等。

在本实施例中，考虑到在不同应用场景中、在不同地域和/或在不同时期，对数据对象的状态信息的服务需求可能会有所不同。鉴于上述考虑，在本申请实施例中，服务端设备采用一种可配置的状态码引擎框架，用于生成状态码信息的多级状态码服务运行在该状态码引擎框架中并且允许对多级状态码服务进行动态配置。具体地，在本申请实施例中，允许基于状态码服务需求动态配置生成状态码信息所需的多级状态码服务。具体地，服务端设备101在调用多级状态码服务之前，可获取基于状态码服务需求动态配置的多级状态码服务；之后，再调用多级状态码服务为至少一个数据对象生成状态码信息。

在一可选实施例中，上述码信息处理系统还包括：配置设备，用于基于状态码服务需求，在服务端设备上动态配置生成状态码信息所需的多级状态码服务。在该情况下，服务端设备可以直接获取配置设备动态配置的多级状态码服务。在本申请实施例中，并不对配置设备的实现形式进行限定，例如配置设备可以是但不限于：常规服务器、云服务器、服务器阵列、虚拟机(VM)或容器等。对服务端设备来说，可以调用配置设备动态配置的多级状态码服务为数据对象生成状态码信息。换句话说，用于生成状态码信息的多级状态码服务发生变化时，服务端设备为数据对象生成状态码信息的逻辑也会发生变化。

其中，状态码服务需求是指状态码服务需求方对数据对象状态的服务需求，至少包括状态码服务需求方所要求的生成状态码信息的服务逻辑以及生成状态码信息所依赖的数据维度。在生成状态码信息的过程包括多个阶段的情况下，状态码服务需求方所要求的生成状态码信息的服务逻辑包含与多个阶段对应的服务逻辑。其中，根据需要状态码服务的应用场景、地域属性和/或时间属性的不同，状态码服务需求会有所不同，相应地，所配置的多级状态码服务的服务逻辑也有所不同。可选地，配置设备可以根据状态码服务对应的地域属性、时间属性和/或应用场景，确定当前状态码服务需求；获取与当前状态码服务需求适配的多级状态码服务，并在服务端设备上配置与当前状态码服务需求适配的多级状态码服务。

在本申请各实施例中，并不对多级状态码服务的级数进行限定，例如可以是2级、3级、5级等，可根据对生成状态码信息的过程的阶段划分而定。在一可选实施例中，将生成状态码信息的过程划分为两个阶段，一个阶段是数据获取阶段，一个是数据聚合阶段；其中，数据获取阶段负责获取生成状态码信息所需依赖数据对象在至少一个维度上的数据记录。数据聚合阶段主要负责根据数据获取阶段所获取的数据对象在至少一个维度上的数据记录对数据对象的状态进行判断，根据判断结果生成状态码信息。基于此，多级状态码服务包括两级状态码服务，第一级状态码服务包括至少一个数据提供服务，第二级状态码服务是级联于至少一个数据提供服务之后的数据聚合服务。其中，每个数据提供服务负责获取数据对象在一个维度上的数据记录，数据提供服务的数量由状态码服务需求中要求的维度数量而定；对应于不同维度的数据提供服务，其获取数据记录的服务逻辑会有所不同。在多级状态码服务包括至少一个数据提供服务，以及级联于至少一个数据提供服务之后的数据聚合服务的情况下，服务端设备为数据对象生成状态码信息的过程包括：对任一数据对象，服务端设备可以通过至少一个数据提供服务获取该数据对象在至少一个维度上的数据记录；由数据聚合服务根据该数据对象在至少一个维度上的数据记录，生成该数据对象的状态码信息。可选地，数据提供服务的实现形态可以是原子服务(atomic service)，也可以是合成服务(composite service)，对此不做限定。

进一步，在本实施例中，可以将数据提供服务划分为依赖第三方服务的数据提供服务和不依赖第三方服务的数据提供服务。其中，依赖第三方服务的数据提供服务指的是通过API调用第三方服务才能获取数据对象在某个或某些维度上的数据记录的服务形态。不依赖第三方服务的数据提供服务指的是无需通过API调用第三方服务即可获取数据对象在某个或某些维度上的数据记录的服务形态，例如可以直接从服务端设备本地内存或硬盘上获取数据对象在某个或某些维度上的数据记录。

进一步，从另一角度对数据提供服务进行分类，本实施例中的至少一个数据提供服务包括本地内置服务和/或自定义服务。至少一个数据提供服务可以只包括本地内置服务，也可以只包括自定义服务，也可以同时包含本地内置服务和自定义服务。其中，本地内置服务是指默认存在的数据提供服务，即可以直接使用的数据提供服务，本地内置服务可以是与任何维度对应的服务。自定义服务指的是状态码服务需求方可以根据自身需求，自定义的数据提供服务。自定义服务也可以是与任何维度对应的服务。需要说明的是，在同时包含本地内置服务和自定义服务的情况下，本地内置服务和自定义服务对应的维度不重叠。

综合来看，本实施例的数据提供服务可以是本地内置服务，该本地内置服务可以是依赖第三方服务的，也可以是不依赖第三方服务的；本实施例的数据提供服务还可以是自定义服务，该自定义服务可以是依赖第三方服务的，也可以是不依赖第三方服务的。在根据状态码服务需求动态地在服务端设备上配置好数据提供服务和数据聚合服务之后，服务端设备可依次调用数据提供服务和数据聚合服务为数据对象生成状态码信息；并且可根据状态码服务需求方通过第一终端设备发起的第一服务请求，获取该第一服务请求向第一终端设备返回第一数据对象的状态码信息，以供状态码服务需求方据此进行后续处理。

进一步地，配置设备还用于：根据状态码服务需求，在服务端设备上动态配置其它状态码服务。其它状态码服务可提供的服务内容和服务形式是区别于多级状态码服务的，例如，其它状态码服务可以包括但不限于以下至少一种：状态码信息查询服务、状态码信息核验服务和状态上报服务等。基于此，服务端设备还用于：接收来自第二终端设备的第二服务请求，调用其它状态码服务对第二服务请求进行处理，并向第二终端设备返回第二服务请求对应的服务结果，第二终端设备属于至少一个终端设备。第二服务请求区别于第一服务请求，是指用于请求其它状态码服务的服务请求。

需要说明的是，本实施例的码信息处理系统可应用于各种领域或场景中，在不同领域或场景中，状态码服务需求方、数据对象以及状态码信息的含义和内容都会有所不同，下面对此进行举例说明。

例如，在交通健康管理领域中，可以面向交通信息需求方(上述状态码服务需求方的一种具体实现)提供一种交通健康码服务系统，在该服务系统中，可基于交通健康码服务需求，动态配置多级交通健康码服务，服务端设备通过动态配置的多级交通健康码服务可以生成各车辆(上述数据对象的一种具体实现)的交通健康码，并可响应于交通信息需求方发起的服务请求，根据服务请求向交通信息需求方返回该服务请求所请求的目标车辆的交通健康码，以供交通信息需求方实时快速获取车辆的交通状态信息，解决车辆交通状态核查难、响应慢的问题，而且也可以帮助交通信息需求方统一规范化的管理，而快速的系统同步与反馈也可以帮助交通信息需求方节约巡查支出，节约人员管理的精力，避免一些公共治安问题的产生。其中，交通信息需求方可以是与交通信息相关的政府用户，例如各省市的交通厅/局和/或各地市交管局；也可以是与交通信息相关的企业用户，例如公交集团、网约车平台、巡游出租车公司、物流快递公司等。交通健康码表示车辆的交通状态，例如可以是畅行、拥堵中、发生交通事故等。进一步，交通健康码还可以包括一些附加信息，例如畅行时间、拥堵时间、拥堵程度以及发生交通事故的时间、路段等。

又例如，在社区管理领域中，可以面向社区管理方(上述状态码服务需求方的一种具体实现)提供一种社区码服务系统，在该服务系统中，基于社区码服务需求，动态配置多级社区码服务，服务端设备通过动态配置的多级社区码服务可以生成社区人员(上述数据对象的一种具体实现)的社区码信息，并可响应于社区管理方发起的服务请求，根据该服务请求向社区管理方返回该服务请求所请求的目标人员的社区码信息。其中，社区码信息反映社区人员的一种或几种状态信息，当然，根据社区码服务需求的不同，社区码信息所反映的社区人员的状态信息也会有所不同。例如，社区码信息可以反映社区人员的居住状态，例如可以反映社区人员是否居住在本社区；还可以反映社区人员的健康状态，例如是否到过高风险区或高风险城市或是否患有传染性疾病等；还可以反映社区人员的年龄状态，例如可以反映社区人员是否是老年人；还可以反映社区人员的安全状态，例如可以反映社区人员是否属于治安高危人员；等等。治安高危人员是指对社会治安有一定危害的人员。其中，社区管理方可以是社区居委会、社区物业、社区隶属街道政府等对社区具有管理权限和职责的人员。通过社区码服务系统，社区管理方可以根据需要了解社区人员的各种情况或信息，在一定程度上解决了社区人员流动复杂，难以真正监控避免风险的问题，也可以帮助社区管理方做好关于人口与人流的分层管理和预警，帮助社区更加好的做好社区身份登记，使得社区服务可以精确到人，更好的管控人口，更好的维护社区和社会治安。

又例如，在一些应急事务领域中，可以面向应急事务管理方(上述状态码服务需求方的一种具体实现)提供应急码服务系统，在该服务系统中，基于应急码服务需求，动态配置多级应急码服务，服务端设备通过动态配置的多级应急码服务可以生成应急对象(上述数据对象的一种具体实现)的应急码信息，并可响应于应急事务管理方发起的服务请求，根据该服务请求向应急事务管理方返回该服务请求所请求的目标应急对象的应急码信息。其中，应急码信息反应应急对象在应急场景中的应急状态。例如，在自然灾害应急场景中，应用对象可以是人或物品，应急码信息可以反映人或物品的受灾状态、是否急需救援等状态信息。又例如，在安全生产应急场景中，应急对象可以是应急所需的产品，应急码信息可以反映应急产品的生产进度、安全质量以及相关机器和人员的动向等状态信息。其中，应急事务管理方可以是为省应急厅，地市/区县应急管理局，或园区管委会等。通过应急码服务系统，应急事务管理方可以根据需要及时了解应急对象的相关状态，可解决应急场景中人员或物品核查复杂，动员响应慢的问题，在安全生产领域解决企业生产安全难以控制的问题。进一步，在自然灾害应急场景中，通过该应急码服务系统，可帮助应急事务管理方快速地进行人员分配，根据受灾群众的应急码快速分类安排，最大限度的减少自然灾害带来的影响和经济损失。在安全生产可以记录生产机器与人员动向，能最快速度做到通知与预警，降低损失和风险。

又例如，在工业危废追踪码领域中，可以面向危废品监管方(上述状态码服务需求方的一种具体实现)提供追踪码服务系统，在该服务系统中，基于危废品追踪服务需求，动态配置多级追踪码服务，服务端设备通过动态配置的多级追踪码服务可以生成危废品(上述数据对象的一种具体实现)的追踪码信息，并可响应于危废品监管方发起的服务请求，根据该服务请求向危废品监管方返回该服务请求所请求的目标危废品的追踪码信息。其中，追踪码信息反应危废品在危废品追踪场景中的处理状态，例如是否被回收、被填埋等。其中，危废品监管方可以是危废品监管部门、生产企业、运输企业、处理企业或收储企业等。通过追踪码服务系统，危废品监管方可以根据需要及时了解相关企业的危废品的处理状态，可以高效的对企业进行巡查，也能帮助生产企业合理分析和控制危废品的申报和处置，可解决危废品监管方无法核验企业的危废处理情况，无法监控、无法巡查的问题，也解决了生产企业手工记录危废品处理状态所产生的错误不可追溯的问题。

又例如，在卫生健康跟踪领域中，可以面向卫健管理方(上述状态码服务需求方的一种具体实现)提供卫健码服务系统，在该服务系统中，基于卫健跟踪服务需求，动态配置多级卫健码服务，服务端设备通过动态配置的多级卫健码服务可以生成相关人群的卫健码信息，并可响应于卫健管理方发起的服务请求，根据该服务请求向卫健管理方返回该服务请求所请求的目标人员的卫健码信息。其中，卫健码信息反应相关人员的卫健健康状态，例如是否被疫情感染、是否患有传染性疾病、是否就诊或就医等。其中，卫健管理方可以是地区卫健委、疾控中心或医院等与群众卫生健康相关的部门或企业。通过卫健码服务系统，卫健管理方可根据需要及时了解所有人员的健康信息，疾控中心可以即时通过卫健码信息的更新对一些疾控风险做出及时反馈，而且医院方也可以根据患者的即时状态和以往病历做出合理正确的诊断，减少医疗风险，解决了卫健委无法确认和把控群众的健康情况，无法针对可能产生的疫情传染做出反应，以及医院也无法获取患者以往就诊信息，无法做出正确的诊断等问题。

又例如，在食药企业监管领域中，可以面向企业监管方(上述状态码服务需求方的一种具体实现)提供许可码服务系统，在该服务系统中，基于企业经营许可服务需求，动态配置多级许可码服务，服务端设备通过动态配置的多级许可码服务可以生成各企业(尤其是食药类企业)的许可码信息，并可响应于企业监管方发起的服务请求，根据该服务请求向企业监管方返回该服务请求所请求的目标企业的许可码信息。其中，许可码信息反应企业的经营状态，例如是否正常经营，是否非法经营等。其中，企业监管方可以是全国企业和个体工商户、市场监督局等。通过许可码服务系统，可以将执法标准统一，做到针对性的对企业进行经营状态的核查处置，帮企业打通许可码，满足企业的安全生产和实时监督需求，进而解决企业经营状态不统一，同步慢，全流程监管能力弱，监管部门制度不统一等问题。

除上述系统实施例之外，本申请实施例还提供一种码信息处理方法，该方法包括以下步骤：基于状态码服务需求，动态配置生成状态码信息所需的多级状态码服务；调用多级状态码服务为至少一个数据对象生成状态码信息；接收来自第一终端设备的第一服务请求，第一服务请求用于请求第一数据对象的状态码信息；根据第一服务请求，向第一终端设备返回第一数据对象的状态码信息，第一数据对象属于至少一个数据对象。关于该方法的详细流程可参见前述码信息处理系统实施例，以及前述健康服务系统实施例中的相同或相似描述，在此不再赘述。

需要说明的是，上述实施例所提供方法的各步骤的执行主体均可以是同一设备，或者，该方法也由不同设备作为执行主体。比如，步骤41a至步骤43a的执行主体可以为设备A；又比如，步骤41a和42a的执行主体可以为设备A，步骤43a的执行主体可以为设备B；等等。

另外，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如41a、42a等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

图5为本申请示例性实施例提供的一种服务端设备的结构示意图。如图5所示，该服务端设备包括：存储器54、处理器55以及通信组件56。

存储器54，用于存储计算机程序，并可被配置为存储其它各种数据以支持在服务端设备上的操作。这些数据的示例包括用于在服务端设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器54可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器55，与存储器54耦合，用于执行存储器54中的计算机程序，以用于：调用生成健康码信息所需的多级健康服务为至少一个用户生成健康码信息；以及通过通信组件56接收来自第一用户的第一服务请求，并根据第一服务请求向第一用户返回其健康码信息，至少一个用户包含第一用户，多级健康服务是基于健康服务需求动态配置的。

在一可选实施例中，多级健康服务包括至少一个数据提供服务，以及级联于至少一个数据提供服务之后的数据聚合服务；处理器55在调用多级健康服务为至少一个用户生成健康码信息时，具体用于：对至少一个用户中的任一用户，通过至少一个数据提供服务获取用户在至少一个健康关联维度上的数据记录；由数据聚合服务根据用户在至少一个健康关联维度上的数据记录，生成用户的健康码信息。

在一可选实施例中，在数据提供服务为多个的情况下，处理器55还用于：获取多个数据提供服务对应的资源隔离参数；根据资源隔离参数在多个数据提供服务之间实现资源隔离。其中，多个数据提供服务对应的资源隔离参数是由配置设备为多个数据提供服务配置的。

在一可选实施例中，本实施例的服务端设备上还配置有其它健康服务，处理器55还用于：接收来自第二用户的第二服务请求；调用其它健康服务对第二服务请求进行处理，并向第二用户返回第二服务请求对应的服务结果；至少一个用户包含第二用户。其中，其它健康服务是配置设备根据健康服务需求，在服务端设备上动态配置的。

在一可选实施例中，处理器55还用于：利用自定义前置操作对第二服务请求进行前置处理；和/或，利用自定义后置操作对第二服务请求对应的服务结果进行后置处理。其中，自定义前置操作和/或自定义后置操作是配置设备为其它健康服务动态配置的。

进一步，如图5所示，该服务端设备还包括：电源组件58等其它组件。图5中仅示意性给出部分组件，并不意味着服务端设备只包括图5所示组件。可选地，服务端设备可实现为传统服务器、云服务器或服务器阵列等。

需要说明的是，本实施例的服务端设备，其处理器执行存储器中的计算机程序除了可以实现上述提供健康码信息的操作之外，还可以实现下述提供状态码信息的操作：

获取基于状态码服务需求动态配置的多级状态码服务；

调用多级状态码服务为至少一个数据对象生成状态码信息；

接收来自第一终端设备的第一服务请求，第一服务请求用于请求第一数据对象的状态码信息；

根据第一服务请求，向第一终端设备返回第一数据对象的状态码信息，第一数据对象属于至少一个数据对象。

其中，处理器实现上述与状态码信息相关的操作的详细过程，与其实现上述与健康码信息相关的操作的详细过程相同或相似，可参见前述实施例，在此不再赘述。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述健康服务方法实施例中可由服务端设备执行的各步骤。

图6为本申请示例性实施例提供的一种配置设备的结构示意图。如图6所示，该配置设备包括：存储器64和处理器65。

存储器64，用于存储计算机程序，并可被配置为存储其它各种数据以支持在配置设备上的操作。这些数据的示例包括用于在配置设备上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。

存储器64可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

处理器65，与存储器64耦合，用于执行存储器64中的计算机程序，以用于：获取健康服务需求；根据健康服务需求，在服务端设备上动态配置生成健康码信息所需的多级健康服务，以供服务端设备基于多级健康服务为至少一个用户生成健康码信息。

其中，健康服务需求是动态变化的，健康服务需求变化了，多级健康服务也会相应地发生变化。

在一可选实施例中，处理器65根据健康服务需求，在服务端设备上动态配置生成健康码信息所需的多级健康服务时，具体用于：根据健康服务对应的地域属性、时间属性和/或应用场景，确定当前健康服务需求；获取与当前健康服务需求适配的多级健康服务，并在服务端设备上配置多级健康服务。

在一可选实施例中，处理器65还用于：在数据提供服务为多个的情况下，为多个数据提供服务配置资源隔离参数，以供服务端设备根据资源隔离参数在多个数据提供服务之间实现资源隔离。进一步可选地，处理器65在为多个数据提供服务配置资源隔离参数时，具体用于：为不依赖第三方服务的数据提供服务配置基于信号量的隔离方式及其参数，并为依赖第三方服务的数据提供服务配置基于线程池的隔离方式及其参数。

在一可选实施例中，至少一个数据提供服务包括本地内置服务和/或自定义服务；基于此，处理器65在至少一个数据提供服务包含自定义服务的情况下，具体用于：若自定义服务依赖第三方服务，则在服务端设备上配置第三方服务的服务器域名，以供服务端设备通过API访问第三方服务；若自定义服务不依赖第三方服务，则上传自定义服务对应的脚本文件至指定数据库中，并在服务端设备上配置脚本文件在指定数据库中的脚本ID，以供服务端设备调用自定义服务。

进一步可选地，处理器65在配置自定义服务时，具体用于：

响应服务配置操作，展示服务配置界面，服务配置界面上包含自定义服务是否依赖第三方服务的第一配置项；响应对第一配置项的配置操作，获取自定义服务是否依赖第三方服务的配置信息；

若自定义服务依赖第三方服务，则显示用于配置第三方服务的服务域名的第二配置项；响应于对第二配置项的配置操作，获取第三方服务的服务器域名，以供访问第三方服务；

若自定义服务不依赖第三方服务，则显示脚本文件上传控件和脚本ID配置项；响应对脚本文件上传控件的触发操作，上传自定义服务对应的脚本文件至指定数据库中；以及响应对脚本ID配置项的配置操作，获取脚本文件在指定数据库中的脚本ID，以供调用自定义服务。

进一步可选地，处理器65在配置自定义服务之前，还用于：接收健康事件发生方上报的服务配置请求，服务配置请求包括事件详情信息；根据事件详情信息生成自定义服务。

在一可选实施例中，处理器65还用于：根据健康服务需求，在服务端设备上动态配置其它健康服务。

在一可选实施例中，处理器65还用于：动态配置其它健康服务的自定义前置操作和/或自定义后置操作。

进一步，如图6所示，该配置设备还包括：通信组件66、显示器67、电源组件68、音频组件69等其它组件。图6中仅示意性给出部分组件，并不意味着配置设备只包括图6所示组件。另外，图6中虚线框所示组件为可选组件，而非必选组件，具体可视配置设备的实现形态而定。如果配置设备实现为传统服务器、云服务器、服务器阵列等，可以不包含虚线框所示的组件。

需要说明的是，本实施例的配置设备，其处理器执行存储器中的计算机程序除了可以实现上述配置多级健康服务的操作之外，还可以实现下述配置多级状态码服务的操作：

获取状态码服务需求；在服务端设备上动态配置生成状态码信息所需的多级状态码服务，以供服务端设备基于多级状态码服务为至少一个数据对象生成状态码信息。

其中，处理器实现上述配置多级状态码服务的详细过程，与其实现上述配置多级健康服务的详细过程相同或相似，可参见前述实施例，在此不再赘述。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述健康服务方法实施例中可由配置设备执行的各步骤。

本申请实施例还提供一种终端设备，包括：存储器、处理器和通信组件；进一步，该终端设备还包括：显示器、电源组件、音频组件等其它组件。存储器，用于存储计算机程序；处理器，与存储器耦合，用于执行计算机程序，以用于：通过通信组件向服务端设备发送服务请求，以请求用户的健康码信息，健康码信息包括健康码颜色和用户的标识信息；接收服务端设备返回的健康码信息以及与健康码颜色对应的原因信息；在健康码界面上，展示健康码信息以及与健康码颜色对应的原因信息。

在一可选实施例中，健康码界面上包括与原因信息对应的申诉控件；基于此，处理器还用于：响应用户对申诉控件的触发操作，向服务端设备或健康服务需求方发送申诉请求，以针对原因信息发起申诉。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，计算机程序被执行时能够实现上述健康码信息展示方法实施例的各步骤。

上述图5和图6中的通信组件被配置为便于通信组件所在设备和其他设备之间有线或无线方式的通信。通信组件所在设备可以接入基于通信标准的无线网络，如WiFi，2G、3G、4G/LTE、5G等移动通信网络，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，所述通信组件还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

上述图5和图6中的显示器包括屏幕，其屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。所述触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与所述触摸或滑动操作相关的持续时间和压力。

上述图5和图6中的电源组件，为电源组件所在设备的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源，及其他与为电源组件所在设备生成、管理和分配电力相关联的组件。

上述图5和图6中的音频组件，可被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风(MIC)，当音频组件所在设备处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (44)

1.一种健康服务系统，其特征在于，包括：服务端设备和终端设备；

服务端设备，用于获取基于健康服务需求动态配置的多级健康服务，调用所述多级健康服务为至少一个用户生成健康码信息；以及接收来自第一用户的第一服务请求，并根据所述第一服务请求向所述第一用户返回其健康码信息，所述至少一个用户包含所述第一用户；

所述第一用户的终端设备，用于向所述服务端设备发送第一服务请求，以及接收所述服务端设备返回的所述第一用户的健康码信息并展示。

2.根据权利要求1所述的系统，其特征在于，还包括：

配置设备，用于基于健康服务需求在所述服务端设备上动态配置生成健康码信息所需的多级健康服务。

3.根据权利要求2所述的系统，其特征在于，所述配置设备具体用于：

根据健康服务对应的地域属性、时间属性和/或应用场景，确定当前健康服务需求；

获取与当前健康服务需求适配的多级健康服务，并在所述服务端设备上配置所述多级健康服务。

4.根据权利要求3所述的系统，其特征在于，所述多级健康服务包括至少一个数据提供服务，以及级联于所述至少一个数据提供服务之后的数据聚合服务；

所述服务端设备具体用于：对所述至少一个用户中的任一用户，通过所述至少一个数据提供服务获取所述用户在至少一个健康关联维度上的数据记录；由所述数据聚合服务根据所述用户在至少一个健康关联维度上的数据记录，生成所述用户的健康码信息。

5.根据权利要求4所述的系统，其特征在于，所述配置设备还用于：在所述数据提供服务为多个的情况下，为所述多个数据提供服务配置资源隔离参数；

所述服务端设备还用于：根据所述资源隔离参数在所述多个数据提供服务之间实现资源隔离。

6.根据权利要求5所述的系统，其特征在于，所述配置设备具体用于：为不依赖第三方服务的数据提供服务配置基于信号量的隔离方式及其参数，并为依赖第三方服务的数据提供服务配置基于线程池的隔离方式及其参数。

7.根据权利要求4所述的系统，其特征在于，所述至少一个数据提供服务包括本地内置服务和/或自定义服务；在所述至少一个数据提供服务包含自定义服务的情况下，所述配置设备具体用于：

若自定义服务依赖第三方服务，则在所述服务端设备上配置第三方服务的服务器域名，以供所述服务端设备通过API访问所述第三方服务；

若自定义服务不依赖第三方服务，则上传自定义服务对应的脚本文件至指定数据库中，并在所述服务端设备上配置所述脚本文件在指定数据库中的脚本ID，以供所述服务端设备调用所述自定义服务。

8.根据权利要求7所述的系统，其特征在于，所述配置设备还用于：在所述服务端设备上配置自定义服务之前，接收健康事件发生方上报的服务配置请求，所述服务配置请求包括事件详情信息；根据所述事件详情信息生成自定义服务。

9.根据权利要求1-8任一项所述的系统，其特征在于，所述配置设备还用于：根据健康服务需求，在所述服务端设备上动态配置其它健康服务；

所述服务端设备还用于：接收来自第二用户的第二服务请求；调用所述其它健康服务对所述第二服务请求进行处理，并向所述第二用户返回所述第二服务请求对应的服务结果；所述至少一个用户包含第二用户。

10.根据权利要求9所述的系统，其特征在于，所述配置设备还用于：动态配置所述其它健康服务的自定义前置操作和/或自定义后置操作；

相应地，所述服务端设备还用于：利用所述自定义前置操作对所述第二服务请求进行前置处理；和/或，利用所述自定义后置操作对所述第二服务请求对应的服务结果进行后置处理。

11.一种健康服务方法，其特征在于，包括：

基于健康服务需求，动态配置生成健康码信息所需的多级健康服务；

调用所述多级健康服务为至少一个用户生成健康码信息；

接收来自第一用户的第一服务请求，所述至少一个用户包含所述第一用户；

根据所述第一服务请求向所述第一用户返回其健康码信息。

12.根据权利要求11所述的方法，其特征在于，基于健康服务需求，动态配置生成健康码信息所需的多级健康服务，包括：

根据健康服务对应的地域属性、时间属性和/或应用场景，确定当前健康服务需求；

获取与当前健康服务需求适配的多级健康服务，并配置与当前健康服务需求适配的多级健康服务。

13.根据权利要求11所述的方法，其特征在于，配置与当前健康服务需求适配的多级健康服务，包括：

配置与所述当前健康服务需求适配的至少一个数据提供服务；

配置与所述当前健康服务需求适配的数据聚合服务；其中，所述数据聚合服务级联于所述至少一个数据提供服务之后。

14.根据权利要求13所述的方法，其特征在于，调用所述多级健康服务为至少一个用户生成健康码信息，包括：

对所述至少一个用户中的任一用户，通过所述至少一个数据提供服务获取所述用户在至少一个健康关联维度上的数据记录；

由所述数据聚合服务根据所述用户在至少一个健康关联维度上的数据记录，生成所述用户的健康码信息。

15.根据权利要求14所述的方法，其特征在于，所述至少一个数据提供服务包括本地内置服务和/或自定义服务；

在所述至少一个数据提供服务包含自定义服务的情况下，配置与所述当前健康服务需求适配的至少一个数据提供服务，包括：

若自定义服务依赖第三方服务，则配置第三方服务的服务器域名，以供访问所述第三方服务；

若自定义服务不依赖第三方服务，则上传自义定服务对应的脚本文件至指定数据库中，并配置所述脚本文件在指定数据库中的脚本ID，以供调用所述自定义服务。

16.根据权利要求15所述的方法，其特征在于，所述本地内置服务也包括依赖第三方服务的本地内置服务和/或不依赖第三方服务的本地内置服务；

对所述至少一个用户中的任一用户，通过所述至少一个数据提供服务获取所述用户在至少一个健康关联维度上的数据记录，包括：

基于第一服务对应的脚本ID，加载所述指定数据库中与所述第一服务对应的脚本文件，以获取所述用户在与所述第一服务对应的健康关联维度上的数据记录；

和/或

基于第二服务对应的服务器域名访问所述服务器域名指向的第三方服务，以获取所述用户在与所述第二服务对应的健康关联维度上的数据记录；

其中，第一服务是指不依赖第三方服务的本地内置服务和/或自定义服务；第二服务是指依赖第三方服务的本地内置服务和/或自定义服务。

17.根据权利要求16所述的方法，其特征在于，所述第三方服务包括以下至少一个：就医查询服务、移动轨迹查询服务、居住信息查询服务、办公信息查询服务以及关联用户状态查询服务。

18.根据权利要求15所述的方法，其特征在于，在所述服务端设备上配置自定义服务之前，还包括：

接收健康事件发生方上报的服务配置请求，所述服务配置请求包括事件详情信息；根据所述事件详情信息生成自定义服务。

19.根据权利要求14所述的方法，其特征在于，由所述数据聚合服务根据所述用户在至少一个健康关联维度上的数据记录，生成所述用户的健康码信息，包括：

由所述数据聚合服务根据所述至少一个健康关联维度上的健康状态判定条件和所述用户在至少一个健康关联维度上的数据记录进行聚合判断，得到所述用户的健康状态信息；

根据所述用户的健康状态信息和所述用户的标识信息，生成所述用户的健康码信息。

20.根据权利要求19所述的方法，其特征在于，根据所述用户的健康状态信息和所述用户的标识，生成所述用户的健康码信息，包括：

根据所述用户的健康状态信息确定所述用户的健康码颜色；

生成包含所述健康码颜色和所述用户的标识信息的健康码信息。

21.根据权利要求20所述的方法，其特征在于，根据所述第一服务请求向所述第一用户返回其健康码信息，包括：

从所述第一服务请求中解析出所述第一用户的标识信息和面部图像；

根据所述第一用户的标识信息，从所述至少一个用户的健康码信息中获取所述第一用户的健康码信息；

将所述第一用户的健康码信息和所述第一用户的面部图像组合后返回给所述第一用户。

22.根据权利要求20所述的方法，其特征在于，还包括：

生成与所述健康码颜色对应的原因信息，并将所述原因信息返回给所述第一用户。

23.根据权利要求11-22任一项所述的方法，其特征在于，还包括：

根据健康服务需求动态配置其它健康服务；

接收来自第二用户的第二服务请求；

调用所述其它健康服务对所述第二服务请求进行处理，并向所述第二用户返回所述第二服务请求对应的服务结果。

24.根据权利要求23所述的方法，其特征在于，还包括：动态配置所述其它健康服务的自定义前置操作和/或自定义后置操作；

相应地，在调用所述其它健康服务对所述第二服务请求进行处理之前，还包括：利用所述自定义前置操作对所述第二服务请求进行前置处理；

和/或

在向所述第二用户返回所述第二服务请求对应的服务结果之前，还包括：利用所述自定义后置操作对所述第二服务请求对应的服务结果进行后置处理。

25.根据权利要求23所述的方法，其特征在于，所述其它健康服务包括以下至少一种：健康码信息查询服务、健康码信息核验服务和健康状态上报服务。

26.根据权利要求12-22任一项所述的方法，其特征在于，所述至少一个用户包括处于或进入所述健康服务需求中指向的地域范围内的用户，或者是所述健康服务需求中指向的应用场景中的用户。

27.一种健康码信息展示方法，其特征在于，包括：

向服务端设备发送服务请求，以请求用户的健康码信息，所述健康码信息包括健康码颜色和所述用户的标识信息；

接收所述服务端设备返回的所述健康码信息以及与所述健康码颜色对应的原因信息；

在健康码界面上，展示所述健康码信息以及与所述健康码颜色对应的原因信息。

28.根据权利要求27所述的方法，其特征在于，所述健康码界面上包括与所述原因信息对应的申诉控件；所述方法还包括：

响应所述用户对所述申诉控件的触发操作，向所述服务端设备或健康服务需求方发送申诉请求，以针对所述原因信息发起申诉。

29.一种服务配置方法，其特征在于，包括：

响应服务配置操作，展示服务配置界面，所述服务配置界面上包含自定义服务是否依赖第三方服务的第一配置项；

响应对所述第一配置项的配置操作，获取所述自定义服务是否依赖第三方服务的配置信息；

若所述自定义服务依赖第三方服务，则显示用于配置第三方服务的服务域名的第二配置项；

响应于对所述第二配置项的配置操作，获取所述第三方服务的服务器域名，以供访问所述第三方服务。

30.根据权利要求29所述的方法，其特征在于，还包括：

若所述自定义服务不依赖第三方服务，则显示脚本文件上传控件和脚本ID配置项；

响应对所述脚本文件上传控件的触发操作，上传自定义服务对应的脚本文件至指定数据库中；以及

响应对所述脚本ID配置项的配置操作，获取所述脚本文件在指定数据库中的脚本ID，以供调用所述自定义服务。

31.根据权利要求29或30所述的方法，其特征在于，在配置所述自定义服务之前，还包括：

接收健康事件发生方上报的服务配置请求，所述服务配置请求包括事件详情信息；根据所述事件详情信息生成自定义服务。

32.一种服务端设备，其特征在于，包括：存储器、处理器以及通信组件；

所述存储器，用于存储计算机程序；

所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：获取基于健康服务需求动态配置的多级健康服务，调用所述多级健康服务为至少一个用户生成健康码信息；以及通过通信组件接收来自第一用户的第一服务请求，并根据所述第一服务请求向所述第一用户返回其健康码信息，所述至少一个用户包含所述第一用户，所述多级健康服务是基于健康服务需求动态配置的。

33.一种配置设备，其特征在于，包括：存储器和处理器；

所述存储器，用于存储计算机程序；

所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：

获取健康服务需求；

根据健康服务需求，在服务端设备上动态配置生成健康码信息所需的多级健康服务，以供服务端设备基于所述多级健康服务为至少一个用户生成健康码信息。

34.根据权利要求33所述的设备，其特征在于，所述多级健康服务包括至少一个数据提供服务，以及级联于所述至少一个数据提供服务之后的数据聚合服务；所述至少一个数据提供服务包括自定义服务；

所述处理器具体用于：

响应服务配置操作，展示服务配置界面，所述服务配置界面上包含自定义服务是否依赖第三方服务的第一配置项；

响应对所述第一配置项的配置操作，获取所述自定义服务是否依赖第三方服务的配置信息；

若所述自定义服务依赖第三方服务，则显示用于配置第三方服务的服务域名的第二配置项；

响应于对所述第二配置项的配置操作，获取所述第三方服务的服务器域名，以供访问所述第三方服务。

35.根据权利要求34所述的设备，其特征在于，所述处理器还用于：

若所述自定义服务不依赖第三方服务，则显示脚本文件上传控件和脚本ID配置项；

响应于对所述脚本文件上传控件的触发操作，上传自定义服务对应的脚本文件至指定数据库中；以及

响应于对所述脚本ID配置项的配置操作，获取所述脚本文件在指定数据库中的脚本ID，以供调用所述自定义服务。

36.根据权利要求34或35所述的设备，其特征在于，所述处理器还用于：

在所述服务端设备上配置自定义服务之前，接收健康事件发生方上报的服务配置请求，所述服务配置请求包括事件详情信息；根据所述事件详情信息生成自定义服务。

37.一种终端设备，其特征在于，包括：存储器、处理器和通信组件；

所述存储器，用于存储计算机程序；

所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：

通过所述通信组件向服务端设备发送服务请求，以请求用户的健康码信息，所述健康码信息包括健康码颜色和所述用户的标识信息；

接收所述服务端设备返回的所述健康码信息以及与所述健康码颜色对应的原因信息；

在健康码界面上，展示所述健康码信息以及与所述健康码颜色对应的原因信息。

38.根据权利要求37所述的终端设备，其特征在于，所述健康码界面上包括与所述原因信息对应的申诉控件；

所述处理器还用于：响应所述用户对所述申诉控件的触发操作，向所述服务端设备或健康服务需求方发送申诉请求，以针对所述原因信息发起申诉。

39.一种存储有计算机程序的计算机可读存储介质，其特征在于，当所述计算机程序被处理器执行时，致使所述处理器实现权利要求11-31任一项所述方法中的步骤。

40.一种码信息处理系统，其特征在于，包括：服务端设备和至少一个终端设备；

所述服务端设备，用于获取基于状态码服务需求动态配置的多级状态码服务，调用所述多级状态码服务为至少一个数据对象生成状态码信息；以及接收来自第一终端设备的第一服务请求，并根据所述第一服务请求向所述第一终端设备返回第一数据对象的状态码信息，所述第一数据对象属于所述至少一个数据对象；

所述第一终端设备，用于向所述服务端设备发送第一服务请求，以及接收所述服务端设备返回的所述第一数据对象的状态码信息并展示；所述第一终端设备属于所述至少一个终端设备。

41.根据权利要求40所述的系统，其特征在于，还包括：

配置设备，用于基于状态码服务需求，在所述服务端设备上动态配置生成状态码信息所需的多级状态码服务。

42.根据权利要求41所述的系统，其特征在于，所述配置设备还用于：根据状态码服务需求，在所述服务端设备上动态配置其它状态码服务；

所述服务端设备还用于：接收来自第二终端设备的第二服务请求，调用所述其它状态码服务对所述第二服务请求进行处理，并向所述第二终端设备返回第二服务请求对应的服务结果，所述第二终端设备属于所述至少一个终端设备。

43.一种码信息处理方法，其特征在于，包括：

基于状态码服务需求，动态配置生成状态码信息所需的多级状态码服务；

调用所述多级状态码服务为至少一个数据对象生成状态码信息；

接收来自第一终端设备的第一服务请求，所述第一服务请求用于请求所述第一数据对象的状态码信息；

根据所述第一服务请求，向所述第一终端设备返回所述第一数据对象的状态码信息，所述第一数据对象属于所述至少一个数据对象。

44.一种服务端设备，其特征在于，包括：存储器、处理器以及通信组件；

所述存储器，用于存储计算机程序；

所述处理器，与所述存储器耦合，用于执行所述计算机程序，以用于：

获取基于状态码服务需求动态配置的多级状态码服务；

调用所述多级状态码服务为至少一个数据对象生成状态码信息；

接收来自第一终端设备的第一服务请求，所述第一服务请求用于请求所述第一数据对象的状态码信息；

根据所述第一服务请求，向所述第一终端设备返回所述第一数据对象的状态码信息，所述第一数据对象属于所述至少一个数据对象。

Images