具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对申请的具体技术方案做进一步详细描述。以下实施例用于说明本申请，但不用来限制本申请的范围。

本申请实施例可提供为业务处理方法及系统、装置、设备和存储介质。实际应用中，业务处理方法可由业务处理系统实现，业务处理系统中的各功能实体可以由计算机设备的硬件资源，如处理器等计算资源、通信资源(如用于支持实现光缆、蜂窝等各种方式通信)协同实现。

本申请实施例的业务处理方法可应用于图1所示的信息处理系统，如图1所示，该信息处理系统包括客户端10和服务端20；其中，客户端10中提供有能够访问服务端20的应用程序，并基于应用程序生成业务请求。服务端20承载有实现业务处理方法的业务处理系统，业务处理系统能够对业务请求进行处理，并将处理得到的输出数据发送至客户端10。客户端10和服务端20之间通过网络30进行交互。

本申请实施例中，如图2所示，服务端与多个第三方机构的业务服务端即第三方服务端40对接，第三方服务端40上承载有第三方机构的业务系统即第三方业务系统，其中，第三方机构可包括：医院、学校、政府单位等机构，对应的，第三方业务系统为：医院信息系统、学校信息管理系统、政府单位的信息管理系统等。

在一示例中，第三方机构为医院，服务端20与医院的服务端对接，即业务处理系统与医院信息系统(Hospital Information System，HIS)40对接，且对接的HIS40包括：A医院的HIS40-1、B医院的HIS40-2、C医院的HIS40-3和D医院的HIS40-4。

在实际应用中，服务端对接的第三方服务端的数量和所属机构的类型不进行任何的限定。

本申请实施例提供的业务处理系统，如图3所示，业务处理系统可包括：第一服务201、对接服务202、第二服务203，第一服务201为服务端自身提供的与第三方机构相关的服务，对接服务202用于对第三方业务系统进行管理的服务，第二服务203用于与第三方业务系统进行。

这里，业务处理系统可包括：内部服务层、对接服务层、和外部服务层，其中，第一服务201位于内部服务层，对接服务202位于对接服务层，第二服务202位于外部服务层。内部服务层可包括一个或多个内部服务，外部服务层可包括一个或多个外部服务。

本申请实施例中，客户端10向服务端20发送业务请求，对接服务202接收业务请求，并调用所述业务请求对应的目标服务；所述目标服务属于第一服务201或第二服务202；目标服务对所述业务请求进行处理，以获得所述业务请求对应的目标数据；对接服务202判断是否在设定的第一时长内获得所述目标数据，并根据判断的结果，确定响应所述业务请求的输出数据，并将确定的输出数据发送至客户端10。

这里，服务端可为一个服务器或多个服务器构成的集群。

结合图1、2或3所示的应用场景示意图，本申请实施例提出一种业务处理方法，能够保证业务处理系统的正常运行。

下面，结合图1所示的信息处理系统、图2所示的应用场景或3所示的业务处理系统的示意图，对本申请实施例提供的业务处理方法及系统、装置、设备、存储介质的各实施例进行说明。

本实施例提供一种业务处理方法，该方法应用于业务处理系统，业务处理系统可为服务端，其中，服务端可为计算机设备或计算机设备组成的集群系统。该方法所实现的功能可以通过计算机设备中的处理器调用程序代码来实现，当然程序代码可以保存在计算机存储介质中，可见，该计算机设备至少包括处理器和存储介质。

业务处理系统的结构如图2所示，包括：第一服务201、对接服务202和第二服务203。

图4为本申请实施例的一种业务处理方法的实现流程示意图，如图4所示，该方法可以包括如下步骤：

S401、所述对接服务接收业务请求，并调用所述业务请求对应的目标服务。

所述目标服务属于所述第一服务或所述第二服务。

本申请实施例中的业务处理系统可提供为为客户端提供业务服务的业务服务平台。

客户端中提供有应用程序，并基于应用程序接收用户的操作。在一示例中，应用程序为安装于客户端的业务服务平台的用户端，用户基于用户端的界面进行操作。在一示例中，应用程序为能够提供业务服务平台对应的小程序、公众号等免安装程序的社交应用，用户基于社交应用调取免安装程序，基于免安装程序的界面进行操作。在一示例中，应用程序为能够提供业务服务平台的信息页面的浏览器，用户基于浏览器提供的信息页面进行操作。

这里，业务请求可请求业务服务平台提供的业务服务，也可请求第三方业务系统提供的业务服务。

在一示例中，第三方机构为医院，业务请求可包括：问诊请求、挂号请求、候诊请求、检查结果查询请求、充值请求、支付请求、花费查询请求等。在一示例中，第三方机构为学校，业务请求可包括：课程查询请求、教师信息查询请求、选课请求、报名请求等。在一示例中，第三方机构为交通管理局，业务请求可包括：驾考报名请求、成绩查询请求、违章查询请求、违章处理请求等。

本申请实施例对第三方机构不进行限定，对业务请求也不进行类型的限定，用户可根据实际需求进行设定。

客户端将基于用户操作生成的业务请求发送至业务处理系统，业务处理系统中的对接系统接收到业务请求后，判断业务请求的业务类型，并根据业务请求的业务类型判断该业务请求的业务功能由业务处理系统内部实现的内部业务，还是由对接的第三方业务系统实现的第三方业务。

当判断当前接收到的业务请求的业务功能由业务处理系统内部实现，则调用该业务请求对应的第一服务即内部服务；当判断当前接收到的业务请求的业务功能由第三方业务系统实现，则调用该业务请求对应的第二服务即外部服务，通过第二服务与第三方业务系统对接。这里，将调用的第一服务或第二服务称为目标服务。

在一示例中，业务处理系统提供的内部业务包括：药品信息查询、药品购买、医生问诊、医院信息查询，业务处理系统提供与医院A的医院信息系统、医院B的医院信息系统对接。当业务请求为药品信息查询，则调用的目标服务为第一服务，当业务请求为查询在医院A的花费记录，则调用的目标服务为医院A的医院信息系统对应的第二服务。

在实际应用中，业务处理系统中包括多个第二服务，且各第二服务分别用于对接不同的第三方业务系统对接。在一示例中，基于图2所示的场景，业务处理系统对接的HIS40包括：A医院的HIS40-1、B医院的HIS40-2、C医院的HIS40-3和D医院的HIS40-4，则业务处理系统中包括：第二服务A、第二服务B、第二服务C和第二服务D，其中，第二服务A用于业务处理系统与HIS40-1对接，第二服务B用于业务处理系统与HIS40-2对接，第二服务C用于业务处理系统与HIS40-3对接，第二服务D用于业务处理系统与HIS40-4对接。当接收的业务请求为在请求在医院A挂号，则对接服务调用第二服务A。

S402、所述目标服务对所述业务请求进行处理，以获得所述业务请求对应的目标数据。

对接服务调用目标服务后，目标服务对业务请求进行处理。其中，目标服务可为第一服务或第二服务。

以目标服务为第一服务为例，第一服务对业务请求进行处理，得到业务请求对应的目标数据。这里，目标服务在得到目标数据后，可将目标数据发送至对接服务。这里，第一服务可从业务处理系统中的数据库中调用数据得到目标数据。

以目标服务为第二服务为例，第二服务对业务请求进行数据模型转换，将业务请求的数据模型转换为第二服务对接的第三方业务系统的目标数据模型。这里，当目标服务为第二服务，S402的实施包括：

S4021、对所述业务请求进行数据模型转换，得到转换后的业务请求；

S4022、调用与所述第三方业务系统进行对接的接口，并通过所调用的接口将所述转换后的业务请求转发至所述第三方业务系统，以获取所述第三方业务系统发送的所述目标数据。

业务处理系统与多个第三方业务系统对接，且各个第三方业务系统之间独立，存在不同的第三方业务系统的数据模型不同。因此，第二服务接收到业务请求后，对业务请求进行数据模型的转换，将业务请求的数据模型转换为该第二服务对应的第三方业务系统支持的数据模型即目标数据模型，得到转换后的业务请求。

在实际应用中，对接服务接收到一业务请求后，可根据该业务请求对应的目标数据模型，将该业务请求转换为多个目标业务请求，此时，转换后的业务请求包括多个目标业务请求。在一示例中，当前业务请求为针对A医院的挂号请求，而在A医院需要发起三次请求才能获取到全部数据，因此，通过A医院的目标数据模型的转换，将针对A医院的挂号请求转换为A医院的业务系统能够进行处理的三个目标业务请求。在一示例中，当前业务请求为针对B医院的挂号请求，而在B医院需要发起四次请求才能获取到全部数据，因此，通过B医院的目标数据模型的转换，将针对B医院的挂号请求转换为B医院的业务系统能够进行处理的三个目标业务请求。

在一示例中，业务请求为针对A医院的挂号请求，则目标服务为第二服务A，A医院的HIS的数据模型为数据模型A，则第二服务A将接收到的挂号请求的数据模型转换为数据模型A。

业务处理系统中支持的数据模型可称为统一的数据模型，且统一的数据模型能够转换为第二服务对应的第三方业务系统支持的目标数据模型。这里，统一的数据模型和目标数据模型中的属性的数量可不同，且同一属性所定义的字段可不同。

在一示例中，业务处理系统支持的统一数据模型的属性包括：用户身份信息、用户会员等级、预约医院、预约科室、预约医生和预约时间，目标数据模型中属性包括：用户身份信息、预约科室、预约医生和预约时间，且统一数据模型中属性用户身份的字段为patientId，目标数据模型中属性用户身份的字段为UserId，则第二服务将业务请求中的属性用户会员等级和预约医院删除，且将patientId转换为UserId。

本申请实施例中对业务系统支持的统一数据模型和第三方业务系统支持的目标数据模型所包括的属性不进行任何的限定，且对各属性定义的字段不进行任何的限定。

在实际应用中，不同第三方业务系统支持的目标数据模型可不同。在一示例中，医院A支持的数据模型包括三个属性，医院B支持的数据模型包括四个属性。

目标服务得到转换后的业务请求，调用与第三方业务系统对接的接口，并通过调用的接口将换后的业务请求发送至第三方业务系统。在实际应用中，得到转换后的业务请求后，可将转换后的业务请求进行编排后发送至第三方业务系统。

第三方业务系统接收到转换后的业务请求，对转换后的业务请求进行处理，得到目标数据，并将目标数据发送至第二服务。

本申请实施例中，通过统一数据模型向业务请求对应的第三方业务系统的目标数据模型的转换，使得业务处理系统提供了向不同数据模型的转换能够，保证了业务处理系统能够向多个不同的第三方业务系统的对接，且保证了业务处理系统与第三方业务系统对接的扩展性。

S403、所述对接服务判断是否在设定的第一时长内获得所述目标数据。

对接服务在调用目标服务后，获取第一时长，在检测是否接收到目标服务发送的目标数据的同时，确定当前时间与接收业务请求的接收时刻之间的时长是否达到第一时长，以判断是否在设定的第一时长内获得目标数据。第一时长可包括：3秒、5秒等根据用户实际需求设置的时长。

对接服务判断的结果包括以下两种结果之一：

结果一、在第一时长内获得目标数据；

结果二、在第一时长内未获得目标数据。

如果对接服务一直未接收到目标数据，且当前时间与接收时刻之间的时长达到第一时长，则判断的结果为结果一。

如果对接服务接收到目标数据，且接收到目标数据的时刻与接收业务请求的接收时刻之间的时长小于第一时长，则判断的结果为结果二。

S404、所述对接服务根据判断的结果，确定响应所述业务请求的输出数据。

对接服务根据判断的结果确定相应所述业务请求的输出数据为目标服务返回的目标数据还是数据库中存储的缓存数据。

在判断的结果为结果一的情况下，对接服务输出目标数据，将目标数据作为响应业务请求的输出数据。

在判断的结果为结果二的情况下，对接服务输出缓存数据，将缓存数据作为响应业务请求的输出数据。

本申请实施例可应用于以下场景：

业务处理系统与医院1的HIS对接，客户端基于用户的查询医院1的儿科的排班信息的查询操作生成信息查询请求，将信息查询请求发送至业务处理系统，业务处理系统的对接服务接收到信息查询请求后，调用业务系统中与医院1的HIS对接的外部服务1，以获取医院1的儿科的排班信息；对接服务判断在5秒内未接收到医院1的儿科的排班信息，则将缓存的医院1的儿科的排班信息发送至客户端，对接服务如果在5秒内接收到外部服务1返回的医院1的儿科的排班信息，则将外部服务1返回的医院1的儿科的排班信息发送至客户端，以响应信息查询请求。

客户端基于用户的查询药品A的药品信息查询请求，将药品信息查询请求发送至业务处理系统，业务处理系统的对接服务接收到药品信息查询请求后，调用业务系统中实现药物管理功能的内部服务即药品管理服务，药品管理服务对药品信息查询请求进行处理，以得到药品A的药品信息，对接服务3秒内未接收到药品A的药品信息，则将缓存的药品A的药品信息发送至客户端，如果在3秒内未接收到药品管理服务返回的药品A的药品信息，则将药品管理服务返回的药品A的药品信息发送至客户端，以响应信息查询药品A的药品信息查询请求。

本申请实施例中，所述业务处理系统包括至少一个第一服务、至少一个第二服务和对接服务，所述第一服务为所述业务系统提供的内部服务，所述第二服务用于所述业务处理系统与第三方业务系统进行对接，所述方法包括：所述对接服务接收业务请求，并调用所述业务请求对应的目标服务；所述目标服务属于所述第一服务或所述第二服务；所述目标服务对所述业务请求进行处理，以获得所述业务请求对应的目标数据；所述对接服务判断是否在设定的第一时长内获得所述目标数据，并根据判断的结果，确定响应所述业务请求的输出数据；从而在接收业务请求的时长达到第一时长之前，确定响应业务请求的输出结果，无需等待业务请求的目标数据的返回，及时对业务请求进行响应，使得业务请求不会在业务处理系统中堵塞，保证业务处理系统的正常运行。

在一些实施例中，如图5所示，对接服务203包括调度子服务2031和数据延时子服务2032。调度子服务2031接收业务请求，并调用所述业务请求对应的目标服务；数据延时子服务2032判断是否在设定的第一时长内获得所述目标数据；数据延时子服务2032根据判断的结果，确定响应所述业务请求的输出数据。

这里，调度子服务中注册有所有第一服务和第二服务的信息，并能够根据接收的业务请求判断需要的目标服务第一服务和第二服务中的哪一个服务。

数据延时子服务具有计时监测功能，并能够根据计时监测结果控制响应业务请求的输出数据是从调度的目标服务接收的数据还是缓存数据。

在实际应用中，对接服务中还可包括以下子服务之一：熔断子服务、服务编排子服务、数据监控子服务、白名单子服务、容灾子服务等。其中，

熔断子服务用于提供包含服务降级、限流功能等熔断功能。

服务编排子服务提供多线程异步处理能力，以提高数据的处理能力。满足相同业务在不同的对接医院需要请求不同数量的接口才能获取到业务数据模型。比如：对于挂号业务，A医院需要三个请求接口完成业务流程；B医院需要四个请求完成业务流程。

数据监控子服务中注册有业务系统中需要监控的服务的信息，以对需要监控的服务进行监控。这里，在需要监控的服务中设置有埋点，埋点被触发的情况下，数据监控子服务能够进行告警。

白名单子服务中设置有白名单列表，白名单子服务能够基于白名单列表对操作业务处理系统的用户的操作权限进行识别，从而保证系统的安全性。

本申请实施例中，在白名单列表中设置测试用户与线上使用用户对应不同的操作权项，从而保证测试与线上的隔离。

容灾子服务能够提供第三方业务系统的备用系统的地址，使得第三方业务系统异常情况下所提供的服务异常时，通过备用系统实现自动降级查询。

需要说明的是，本申请实施例中，对接服务中包括多个子服务，且不同的子服务提供不同的管理功能，用户可根据实际需求在对接服务中设置子服务。

在一些实施例中，在S403之前，如图6所示，所述方法还包括：

S405、所述对接服务获取所述业务请求的业务类型，根据所述业务类型确定所述业务请求的实时要求等级；

对应的，S403实施为：所述对接服务在确定的实时要求等级满足异步条件的情况下，判断是否在设定的第一时长内获得所述目标数据。

业务请求根据业务类型的不同，实时要求等级不同。实时要求等级可根据业务请求的业务类型的实时性要求确定。在一示例中，业务请求的业务类型为：挂号，则实时性要求高。在一示例中，业务请求的业务类型为医生排班信息查询，则实时性低。在一示例中，业务请求的业务类型为药品价格查询，则实时性低。在一示例中，业务请求是互联网问诊，则实时性低，在一示例中，业务请求的业务类型为药品交易，则实时性高。

本申请实施例中，当一业务类型的实时要求等级满足异步条件，则表征属于该业务类型的业务请求能够进行延时处理。

在一示例中，实时要求等级包括以下两个等级：能够延时、禁止延时等。当业务类型的实时要求等级为能够延时，则确定实时要求等级满足异步条件。

在一示例中，实时要求等级包括以下三个等级：高等级、中等级、第等级，高等级表征实时要求高，可要求在1秒内返回输出结果，中等级表征实时要求一般，可要求在3秒内返回输出结果，低等级表征不进行实时要求，可要求在5秒内返回输出结果。业务类型的实时要求等级为中或低，则确定实时要求等级满足异步条件。

本申请实施例中，实时要求的等级的划分以及对应的异步条件可根据实际要求来确定。

当业务类型的实时要求满足异步条件，则判断是否在设定的第一时长内获得所述目标数据，当业务类型不满足异步条件，则等待目标数据的返回，并将目标数据作为响应业务请求的输出数据。

本申请实施例中，当业务类型的实时要求满足异步条件，判断是否接收到目标数据的第一时长可根据业务类型的实时要求确定。

本申请实施例中，在业务请求的实时要求等级满足异步条件的情况下，将目标数据或缓存数据作为响应业务请求的输出数据，从而依据业务请求的实时要求对业务请求进行响应，在保证业务处理系统不堵塞的情况下，保证返回数据的正确性。

在一实施例中，S404的实施包括：

在判断的结果为在设定的第一时长内获得所述目标数据的情况下，将所述目标数据作为响应所述业务请求的输出数据；在所述判断的结果为在所述第一时长内未获得所述目标数据的情况下，获取所述业务请求对应的缓存数据，将所述缓存数据作为响应所述业务请求的输出数据。

在S403中判断的结果为结果一的情况下，将目标服务返回的目标数据直接作为响应业务请求的输出数据。

在S403中判断的结果为结果二的情况下，不再等待目标服务是否返回目标数据，而是从缓存中获取针对业务请求的缓存数据，将获取的缓存数据作为响应业务请求的输出数据。

本申请实施例中，缓存数据的缓存时机在S401之前，且包括以下两种情况：

缓存时机一、，业务处理服务接收到相同的业务请求，将该业务请求的目标数据作为缓存数据存储在数据库中。

缓存时机二、业务处理请求周期性地触发目标服务获取目标数据，且将目标服务获取的目标数据存储在数据库中。

在一些实施例中，所述对接服务记录接收所述业务请求的时刻与当前时刻之间的第二时长，根据所述第一时长和所述第二时长设置超时标识；所述目标服务在得到所述目标数据的情况下，根据所述超时标识对所述目标查询数据进行数据处理。

本申请实施例中，对接服务在判断是否在第一时长内接收到目标数据的同时，设置超时标识，以标识当前是否超时，并将超时标识发送至目标服务，以指示目标服务对得到的目标数据进行处理。其中，对接服务根据接收业务请求的时刻至当前时刻之间的时长即第二时与第一时长之间的关系设置超时标识。

对接服务获知超时标识的方式不进行任何的限定。

在一示例中，对接服务和目标服务周期性的进行超时标识的传输，使得目标服务能够获知当前超时标识的情况。

在一示例中，对接服务在超时标识为第二值的情况下，将超时标识发送至目标服务。此时，当目标服务未接收到对接服务的超时标识的情况下，可确定超时标识为第一值。

在一示例中，目标服务在得到目标数据的情况下，从对接服务获取超时标识，并识别获得的超时标识为第一值还是第二值。

在一些实施例中，在所述第二时长未达到所述第一时长的情况下，设置所述超时标识为第一值；所述第一值表征未超时；在所述第二时长达到所述第一时长且未接收到所述目标数据的情况下，设置所述超时标识为第二值；所述第二值表征超时。其中，第一值和第二值为不同的值。在一示例中，第一值为0，第二值为1。在一示例中，第一值为1，第二值为0。

当超时标识为第一值，对接服务在未接收到目标数据的情况下，继续等待目标数据的返回。

当超时标识为第一值，对接服务在接收到目标数据的情况下，将目标数据作为输出数据发送至客户端。此时，对接服务可将超时标识删除。

当超时标识为第二值时，则对接服务获取缓存数据，将缓存数据作为响应业务请求的输出数据，此时，对接服务不再等待目标服务的目标数据。

在一些实施例中，所述根据所述超时标识对所述目标查询数据进行数据处理，包括：在所述超时标识为第一值的情况下，将所述目标查询数据发送至所述对接服务；所述第一值表征未超时；在所述超时标识为第二值的情况下，将所述目标查询数据缓存至数据库中；所述第二值表征超时。

在超时标识为第一值的情况下，表征对接服务还未将缓存数据作为响应业务请求的输出数据，则目标服务直接将获得的目标数据发送至对接服务，以将目标数据作为输出数据发送至客户端。在超时标识为第二值的情况下，表征对接服务已将缓存数据作为响应业务请求的输出数据，则目标服务将获得的目标数据存储至数据库中，以对缓存中的目标数据进行更新。

本申请实施例中，对接服务设置超时标识，以指示目标服务当前是否已将响应业务请求，目标服务根据超时标识对目标数据进行发送处理或缓存处理，保证对接服务与目标服务之间的数据配合。

下面，以第三方机构为医院为例，对本申请实施例提供的业务处理方法进行进一步说明。这里，将业务处理系统中第三方业务系统构成的系统成为服务融合系统，其中，当第三方机构为医院，则将服务融合系统成为多医院服务融合系统。

相关技术中，多医院服务融合系统的架构包括以下几种：

第一种、单一服务架构。

如图7所示，包括：第三方业务系统701和业务处理系统702，其中，业务处理系统包括：接口转发服务721和内部服务722。

第三方业务系统701：提供医院信息系统(Hospital Information System，HIS)服务、电子病历(Electronic Medical Record，EMR)服务、系统监管平台服务、医保服务等第三方机构服务。

接口转发服务721：包括对接接口7211和医院逻辑实现7222。对接接口7221用于将内部服务请求转发到对应的第三方机构服务层701，医院逻辑实现7222用于实现针对对应医院的个性化对接逻辑，比如：数据模型转换。其中，不同的医院逻辑实现对应不同的医院。

内部服务722：提供内部服务。

第二种、微服务架构。

如图8所示，包括：第三方业务系统801和业务处理系统802，其中，业务处理系统802包括：外部服务层821、接口转发服务层822和内部服务层823。

第三方业务系统801：提供HIS服务、EMR服务、系统监管平台服务、医保服务等第三方机构服务。

外部服务层821提供医院服务8211即外部服务，进行各医院的服务向各个第三方机构数据模型的转换和院内服务请求的转发。

接口转发服务层822，提供有接口转发服务8221，接口转发服务8221根据第三方业务系统801的ID，将业务请求映射到外部服务层821中对应的医院服务8211。

内部服务层823，提供有内部服务8231，提供多医院对接服务已有的服务或者新开发的服务等内部服务。其中，内部服务层可提供多个不同的内部服务。

第二种架构相对于第一种架构，将与第三方业务系统的交互拆解成一个个的微服务。而接口转发服务层只是负责将请求转发，从而将请求转发和数据模型转换进行了解耦。

上述第一种架构存在以下技术缺陷：

(1)、扩展性不好，不利于服务管理。

每一次需求迭代和持续性交付，都需要对已有耦合逻辑进行验证，没有实现服务间的隔离与解耦。

(2)、扩展性差。

项目前期可以快速迭代，但是随着接入医院服务越来越多，接口服务越来越抽象，各个业务线耦合严重。随后的每次迭代，测试回归上线就不得不关注所有的模块。

(3)、不同服务之间的耦合性强。

各个医院的服务向第三方机构服务的转换都在一个服务中实现，导致为新医院打包的应用不得不包含其他医院的功能。而且在开发过程中，因为在一个应用服务内，如果前期没有做很好的模块隔离，那么后期进行拆分也将是非常困难的，在推行过程中也不能保证业务和数据的完全隔离性，会造成一定安全问题。

(4)、系统容易阻塞。

当一个接口服务出现问题时，可能会造成整个应用的阻塞，最终导致服务不可用。

例如，有N个业务服务接口需要依赖HIS服务接口，会共用服务容器内的50个工作线程。如果依赖的HIS服务出现网络抖动，也就是接口超时(假设超时时间设置为5秒)，而该接口的QPS每秒查询率(QPS，Queries-per-second)为20的情况下，很快所有的工作线程都会阻塞到这个HIS服务接口请求超时的等待上，进而造成整个服务的不可用。

第二种架构方案虽然实现了外部服务间的隔离和解耦，增加整个架构的可扩展性和维护性。但是并没有解决以上缺陷中问题(2)、(3)和(4)。

另外，上述架构对于服务可用性、容错机制都没有考虑，从长期来看，并不能稳定、快速、持续性的交付多家医院。

本申请实施例提供的多医院服务融合系统的架构如图9所示，包括：

第三方业务系统901和业务处理系统902，业务处理系统902包括：外部服务层921、网关层922、对接服务层923、内部服务层924、数据存储层925。

其中，

第三方业务系统901：提供HIS服务、EMR服务、系统监管平台服务、医保服务等第三方机构服务。

外部服务层921，提供医院服务即外部服务9211，进行各医院的服务请求向各个第三方机构数据模型的转换和医院的院内服务请求的转发。

这里，由于医院服务基于内网环境实现，因此，针对各医院服务，提供有一内部接口，用于对相应医院以外的服务请求的转发。每一个医院服务注册到对接服务层923，由对接服务层923统一派发内部服务的请求。各医院服务提供业务数据模型的转换，以能满足对接服务层923的统一的服务接口和业务服务模型。

网关层922，包括反向代理9221和负载均衡9222。反向代理9221提供鉴权服务和防刷服务。负载均衡9222提供负载均衡服务。

对接服务层923，提供对接第三方机构的管理平台。提供的服务为对接服务9232，其中，对接服务9232包括：熔断子服务、服务编排子务、数据监控子服务、白名单子服务、数据延时子服务、容灾子服务、调度子服务、动态配置管理子服务等。

内部服务层924，提供内部服务9241和异步数据通知服务9242，内部服务9241对外提供远程过程调用(Remote Procedure Call，RPC)接口。异步数据通知服务9242能够对接服务对业务请求的处理状态，并将处理状态返回至其他服务。这里，业务请求的处理状态包括：开始处理、正在处理和完成处理，其中，开始处理指示接收到业务请求准备处理业务请求，正在处理指示对接收到的业务请求进行处理中，完成处理指示对接收到的业务请求完成处理。

数据存储层925，提供数据库9251，对各服务进行数据存储。可采用关系型数据库，比如mysql。

在一示例中，在业务请求为HIS药品详情/京东药品详情，对应的接口耗时较长，不能在规定的时间处理结果，对接服务则将该业务请求定义为可延时处理的业务请求，通过数据延时子服务配置为该业务请求可接受的延时数据即缓存数据。当接收到该业务请求时，对接服务将该业务处理场景的处理状态设置为开始处理。当超过规定时间不能返回处理结果，则设置业务状态为处理中，且返回旧版本的数据即缓存数据。当对接服务接到异步数据通知服务发送的业务状态为处理中，则对接服务中的数据延时子服务与客户端建立长连接。当对接服务完成业务请求，将业务状态更新为已完成。异步消息通知服务获取到该请求已完成，即时通知对接服务。对接服务中的延时数据子服务，作为消息的消费者，而且也是与前端建立长链接的子服务，接收到消息后，即时将刚才接收的旧版本数据显示为最新的新版本数据发送至客户端。

本申请的外部服务层、对接服务层、内部服务层和数据存储层构成一个对接服务平台，对接服务平台的结构如图10所示，其中，对接服务平台在职能上有熔断功能、对服务流程编排功能、可延时数据处理功能、数据监控/异常报警功能、容灾切换功能、动态配置管理功能等。

对接服务平台实现的功能包括：

1、服务注册和接口注册功能，由调度子服务实现，保证包括针对HIS开发的外部服务，和内部开发的提供RPC接口的内部服务的注册，以为接下来的服务请求的转发调度提供基础；提供各个服务的接口配置注册功能，为服务请求的转发提供基础。

2、服务编排功能，由服务编排子服务实现。服务编排功能是一个多线程异步处理能力，提高数据的处理能力。满足相同服务请求在不同的对接医院请求不同数量的接口才能获取到业务数据模型。本申请实施例中，根据业务，对所有的业务请求进行流程编排，不区分内外，以业务需求为背景，统一整理编排。

3、数据监控功能，由数据监控子服务实现。

由于各个内部服务和各个外部服务的接口都已经注册到该对接服务层上，对接服务层的能够在各服务之间埋点，对各服务进行统一管理和统一监控报警。

4、熔断功能，由熔断子服务实现，包含服务降级、限流功能等，由熔断服务实现。

对接服务层可集成Hystrix等熔断器，以提供熔断服务

5、白名单功能，由白名单子服务实现。

白名单服务所提供的白名单中配置白名单用户和各白名单用户的操作权限，保证不同用户具备不同的操作权限。在一示例中，测试人员和线上操作人员具有不同的操作权限，从而保证测试与线上的隔离。

6、动态配置管理功能，由动态配置管理子服务实现，进行动态参数配置，使对接服务层的可操作性和可扩展性得到更好的应用，并便捷的为研发或者是运营人员提供帮助。

7、容灾切换功能，由容灾子服务实现，提供第三方机构备用服务地址的配置管理功能，使得服务异常情况下服务的自动降级查询。

8、异步服务功能，由数据延时子服务实现。

在以下场景中，用户对数据的实时性要求并不高：

场景1.用户就医过程中查看检验检查结果，用户会在一段时间内持续关注，不断刷新查询结果。

场景2.获取医生的排班记录；医生排班的更新频率并不会很高，所以排班记录是可以接受可延时的。

异步处理服务针对可延时的服务请求做异步处理。

异步处理服务获得可延时的服务请求对应的请求数据，通知对接服务层，在对接服务层判断当前没有达到设置的超时时间，则直接返回请求数据；如果已经超时返回，则将请求数据缓存至数据库中，用于用户的下一次查询。

对接服务层在设置的超时时间内等待请求数据的返回，如果在超时时间内有请求数据返回则直接返回该请求数据。如果没有请求数据返回，则返回数据库中的请求数据。

在数据库中配置数据刷新的定时任务，定时在数据库中更新医生排班记录等数据，这样接口请求时，可直接返回缓存的数据，增加接口的稳定性，提高吞吐量。

异步处理服务能够保证在网络抖动等网络不稳定情况或者HIS请求链路复杂、耗时长的情况下的服务可用性，提供接口的吞吐量。

本申请实施例提供的信息融合系统，具有以下特点：

(1)、提供了多家医院入驻，服务的横向扩展方式，保证了服务的高可用。在一示例中，当一个服务变成两个服务，则提供的数据处理能力提升为2倍。

(2)、提供了多家医院类似业务场景下的服务编排能力，保证了接口请求的高效性。

(3)提供了多家机构不同服务数据模型的转换能力，保证了平台的扩展性。这里，通过统一的数据模型，实现医院内部服务调用接口转发服务成功。

本申请实施例提供一种业务处理系统，如图3所示，所述业务处理系统包括至少一个第一服务201、至少一个第二服务203和对接服务202，所述第一服务为所述业务系统提供的内部服务，所述第二服务用于所述业务处理系统与第三方业务系统进行对接；

对接服务202，接收业务请求，并调用所述业务请求对应的目标服务；所述目标服务属于第一服务201或第二服务203；

所述目标服务，对所述业务请求进行处理，以获得所述业务请求对应的目标数据；

对接服务202，判断是否在设定的第一时长内获得所述目标数据，并根据判断的结果，确定响应所述业务请求的输出数据。

在一些实施例中，所述对接服务包括调度子服务和数据延时子服务；

所述调度子服务接收业务请求，并调用所述业务请求对应的目标服务；

所述数据延时子服务判断是否在设定的第一时长内获得所述目标数据；

所述数据延时子服务根据判断的结果，确定响应所述业务请求的输出数据。

在一些实施例中，在所述目标服务数据所述第二服务的情况下，所述目标服务还执行以下处理：

对所述业务请求进行数据模型转换，得到转换后的业务请求；

调用与所述第三方业务系统进行对接的接口，并通过所调用的接口将所述转换后的业务请求转发至所述第三方业务系统，以获取所述第三方业务系统发送的所述目标数据。

在一些实施例中，所述对接服务获取所述业务请求的业务类型，根据所述业务类型确定所述业务请求的实时要求等级；

对应的，所述对接服务在确定的实时要求等级满足异步条件的情况下，判断是否在设定的第一时长内获得所述目标数据。

在一些实施例中，在判断的结果为在所述第一时长内获得所述目标数据的情况下，所述对接服务将所述目标数据作为响应所述业务请求的输出数据；在所述判断的结果为在所述第一时长内未获得所述目标数据的情况下，所述对接服务获取所述业务请求对应的缓存数据，将所述缓存数据作为响应所述业务请求的输出数据。

在一些实施例中，所述对接服务记录接收所述业务请求的时刻与当前时刻之间的第二时长，根据所述第一时长和所述第二时长设置超时标识；所述目标服务在得到所述目标数据的情况下，根据所述超时标识对所述目标查询数据进行数据处理。

在一些实施例中，在所述第二时长未达到所述第一时长的情况下，所述对接服务设置所述超时标识为第一值；所述第一值表征未超时；在所述第二时长达到所述第一时长，且未接收到所述目标数据的情况下，所述对接服务设置所述超时标识为第二值；所述第二值表征超时。

在一些实施例中，在所述超时标识为第一值的情况下，所述目标服务将所述目标查询数据发送至所述对接服务；所述第一值表征未超时；在所述超时标识为第二值的情况下，所述目标服务将所述目标查询数据缓存至数据库中；所述第二值表征超时。

本申请实施例还提供一种业务处理装置1100，如图11所示，包括：

接收单元1101，用于通过对接服务接收业务请求，并调用所述业务请求对应的目标服务；所述目标服务属于第一服务或第二服务；所述第一服务为内部服务，所述第二服务用于与第三方业务系统进行对接；

处理单元1102，用于通过所述目标服务对所述业务请求进行处理，以获得所述业务请求对应的目标数据；

判断单元1103，用于通过所述对接服务判断是否在设定的第一时长内获得所述目标数据；

输出单元1104，用于通过所述对接服务根据判断的结果，确定响应所述业务请求的输出数据。

在一些实施例中，接收单元1101，还用于通过调度子服务接收业务请求，并调用所述业务请求对应的目标服务；

判断单元1103，还用于通过数据延时子服务判断是否在设定的第一时长内获得所述目标数据；

输出单元1104，还用于通过所述数据延时子服务根据判断的结果，确定响应所述业务请求的输出数据。

在一些实施例中，处理单元1102，还用于：

在所述目标服务数据所述第二服务的情况下，通过所述目标服务对所述业务请求进行数据模型转换，得到转换后的业务请求；通过所述目标服务调用与所述第三方业务系统进行对接的接口，并通过所调用的接口将所述转换后的业务请求转发至所述第三方业务系统，以获取所述第三方业务系统发送的所述目标数据。

在一些实施例中，所述装置还包括：

等级判断单元，用于通过所述对接服务获取所述业务请求的业务类型，根据所述业务类型确定所述业务请求的实时要求等级；

对应的，判断单元1103还用于：通过所述对接服务在确定的实时要求等级满足异步条件的情况下，判断是否在设定的第一时长内获得所述目标数据。

在一些实施例中，输出单元1104，还用于：

在判断的结果为在所述第一时长内获得所述目标数据的情况下，通过所述对接服务将所述目标数据作为响应所述业务请求的输出数据；

在所述判断的结果为在所述第一时长内未获得所述目标数据的情况下，通过所述对接服务获取所述业务请求对应的缓存数据，将所述缓存数据作为响应所述业务请求的输出数据。

在一些实施例中，所述装置还包括：记录单元和数据处理单元，

所述记录单元，用于通过所述对接服务记录接收所述业务请求的时刻与当前时刻之间的第二时长，根据所述第一时长和所述第二时长设置超时标识；

所述数据处理单元，用于通过所述目标服务在得到所述目标数据的情况下，根据所述超时标识对所述目标查询数据进行数据处理。

在一些实施例中，记录单元，还用于：

在所述第二时长未达到所述第一时长的情况下，通过所述对接服务设置所述超时标识为第一值；所述第一值表征未超时；

在所述第二时长达到所述第一时长，且未接收到所述目标数据的情况下，通过所述对接服务设置所述超时标识为第二值；所述第二值表征超时。

在一些实施例中，所述数据处理单元，还用于：

在所述超时标识为第一值的情况下，通过所述目标服务将所述目标查询数据发送至所述对接服务；所述第一值表征未超时；

在所述超时标识为第二值的情况下，通过所述目标服务将所述目标查询数据缓存至数据库中；所述第二值表征超时。

需要说明的是，本申请实施例提供的业务处理系统和业务处理装置包括所包括的各单元，可以通过电子设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(CPU，Central Processing Unit)、微处理器(MPU，Micro Processor Unit)、数字信号处理器(DSP，Digital Signal Processor)或现场可编程门阵列(FPGA，Field-Programmable Gate Array)等。

以上系统实施例、装置实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请系统实施例、装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的业务处理方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read OnlyMemory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

对应地，本申请实施例提供一种电子设备，包括存储器和处理器，所述存储器存储有可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述实施例中提供的业务处理方法。其中，该电子设备可为客户端，也可为服务端。

对应地，本申请实施例提供一种存储介质，也就是计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中提供的业务处理方法中的步骤。

这里需要指出的是：以上存储介质和设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，图12为本申请实施例电子设备的一种硬件实体示意图，如图12所示，所述电子设备1200包括：一个处理器1201、至少一个通信总线1202、至少一个外部通信接口1204和存储器1205。其中，通信总线1202配置为实现这些组件之间的连接通信。在一示例中，电子设备1200还包括：用户接口1203、其中，用户接口1203可以包括显示屏，外部通信接口1204可以包括标准的有线接口和无线接口。

存储器1205配置为存储由处理器1201可执行的指令和应用，还可以缓存待处理器1201以及电子设备中各模块待处理或已经处理的数据(例如，图像数据、音频数据、语音通信数据和视频通信数据)，可以通过闪存(FLASH)或随机访问存储器(Random AccessMemory，RAM)实现。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一些实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

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

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(Read Only Memory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。