CN115964021A - 一种需求发布方法、装置、电子设备及存储介质 - Google Patents

Abstract

本公开提供了一种需求发布方法、装置、电子设备及存储介质，涉及计算机领域，尤其涉及计算机开发技术领域。具体实现方案为：获取需求提供方在需求录入界面按照指定格式录入的需求信息；将审核通过的需求信息写入需求发布表；当接收到发布指令时，将需求发布表中的需求信息转换为需求配置文件；基于需求配置文件对日志中台中的服务进行需求发布。如此，减少了人力开销成本，降低了误操作的风险。

Description

一种需求发布方法、装置、电子设备及存储介质

5技术领域

本公开涉及计算机技术领域，尤其涉及计算机开发技术领域。

背景技术

日志中台是用于实现日志数据采集、传输、管理以及查询分析等功能0的服务架构，日志中台为支持整个移动生态的数据建设，会频繁产生日志

点位接入、日志点位变更等需求。需求提出方提出需求后，日志中台的研发工程师(Research and Development，RD)可以与需求提出方沟通确认需求，并将确认好的需求写成配置代码，然后利用配置代码将需求上线到日志中台中的各服务。

发明内容

本公开提供了一种需求发布方法、装置、电子设备及存储介质。

根据本公开的第一方面，提供了一种需求发布方法，包括：

获取需求提供方在需求录入界面按照指定格式录入的需求信息；0将审核通过的需求信息写入需求发布表；

当接收到发布指令时，将所述需求发布表中的需求信息转换为需求配置文件；

基于所述需求配置文件对日志中台中的服务进行需求发布。

根据本公开的第二方面，提供了一种需求发布装置，包括：5获取模块，用于获取需求提供方在需求录入界面按照指定格式录入的需求信息；

写入模块，用于将审核通过的需求信息写入需求发布表；

转换模块，用于当接收到发布指令时，将所述需求发布表中的需求信

息转换为需求配置文件；

0发布模块，用于基于所述转换模块转换的需求配置文件对日志中台中的服务进行需求发布。

根据本公开的第三方面，提供了一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面中任一项所述的方法。

根据本公开的第四方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行第一方面中任一项所述的方法。

根据本公开的第五方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现第一方面中任一项所述的方法。

应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。

附图说明

附图用于更好地理解本方案，不构成对本公开的限定。其中：

图1是本公开实施例提供的一种需求发布方法的方法流程图；

图2是本公开实施例提供的一种需求管理界面的示例性示意图；

图3是本公开实施例提供的一种需求管理过程的示例性示意图；

图4是本公开实施例提供的一种分级发布过程的示例性示意图；

图5是本公开实施例提供的一种需求发布界面的示例性示意图；

图6是本公开实施例提供的一种需求发布详情界面的示例性示意图；

图7是本公开实施例提供的另一种需求发布方法的流程图；

图8是本公开实施例提供的一种通过自助化平台完成需求发布的示例性示意图；

图9是本公开实施例提供的一种需求发布装置的结构示意图；

图10用来实现本公开实施例的需求发布方法的电子设备的框图。

具体实施方式

以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本5领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。

本公开实施例提供一种需求发布方法，该方法应用于电子设备，电子设备可以为终端、服务器等设备，如图1所示，该方法包括：0S101、获取需求提供方在需求录入界面按照指定格式录入的需求信息。

其中，需求提供方为提出需求的日志中台用户，需求录入界面为具有指定格式的需求录入界面，需求提供方需要按照需求录入界面中限定的指定格式录入需求。

S102、将审核通过的需求信息写入需求发布表。

5其中，需求提供方录入需求信息后，日志中台的RD可以对需求信息进行审核，审核通过后，服务器可以将审核通过的需求信息写入需求发布表。需求发布表位于数据库中，例如，该数据库可以为MySQL数据库。

S103、当接收到发布指令时，将需求发布表中的需求信息转换为需求配置文件。

0其中，需求配置文件为代码能够识别的格式，本公开实施例对所使用的代码语言不作限制。

S104、基于需求配置文件对日志中台中的服务进行需求发布。

采用上述技术方案，需求提供方在需求录入界面按照指定格式录入需

求信息，如此，通过指定格式对需求录入进行约束，规范化了需求的内容，5且需求提供方可直接录入需求信息，无需日志中台的RD频繁与需求提供

方进行沟通，降低了需求沟通阶段的人力开销。并且审核通过的需求信息可以被写入需求发布表，进而当接收到发布指令时，将需求发布表中的需求信息转换为需求配置文件，无需人工编辑，降低了误操作的风险，且进一步降低了人力开销。

0在本公开的一些实施例中，可以通过需求录入界面限制需求提供方录入的需求信息的格式，上述S101、获取需求提供方在需求录入界面按照指定格式录入的需求信息，具体可以实现为：

获取需求提供方在需求录入界面填入的应用身份标识(applicationidentification，APP ID)和日志ID，以及通过菜单栏选择的目标需求类型，菜单栏中包括预设的多种需求类型；响应于需求提供方选择的目标需求类型，在需求录入界面显示目标需求类型对应的需求详情填写模板；基于需求提供方在需求详情填写模板中填写的信息生成目标需求详情。

进而，即可将需求提供方填入的APP ID和日志ID、目标需求类型以及目标需求详情作为一个需求信息。

其中，APP ID用于表示需求所属的产品线信息，一个产品线信息可以为一个应用，即APP ID也可用于表示需求所属的应用。针对于同一个应用提出的需求信息的APP ID是相同的。例如需求a、需求b均属于应用A的需求信息，那么需求a和需求b的APP ID相同。

日志ID用于表示上报日志的场景。例如，上报日志的场景为应用A内每天发起电话会议的次数，该场景对应的日志ID可以为001。

需求类型用于表示需求的目标，需求类型可以包括：原始信息落盘、实时流转发和推荐流转发等类型。

需求详情用于描述需求的详细信息，不同的需求类型对应的需求详情的格式不同。本公开实施例中，可以为不用需求类型的需求详情分别设置一套填写模板，以供需求提供方按照填写模板填写需求信息。

例如，针对实时流转发，需求详情中记录实时流的目标下游节点；针对推荐流转发，需求详情中记录推荐流的格式类型等信息。

此外，在本公开实施例中，需求提供方仅需要在菜单栏选择目标需求类型，进而在目标需求类型对应的需求详情填写模板中填写需求信息，最终目标需求详情是服务器综合需求详情填写模板和需求提供方填写的信息生成的。例如，针对实时流转发类型的需求，需要需求提供方在需求详情填写模板中填写目标下游节点等信息，进而服务器可将需求提供方填写的下游节点等信息与需求详情填写模板组合成需求详情。

本公开实施例中的需求录入界面可以为浏览器中的网页的形式，如图2所示，图2为本公开实施例提供的一种需求管理界面的示例性示意图。

该需求管理界面可作为需求提供方录入需求信息时使用的需求录入界面，也可作为日志中台RD审核需求信息时使用的需求审核界面，日志中台RD对各需求信息进行其他管理时，也可使用该界面。不同身份的用户可利用不同的账号登录该需求管理界面。

图2中示出了日志ID和APP ID的填写框，以及功能分类选择框，用户点击功能分类选择框中的“请选择”后，即可显示预先设置的需求类型，进而用户可从中选择需求类型。

在用户点击查询按钮时，即可显示出与用户填写的日志ID、APP ID以及选择的需求类型匹配的需求信息。图2下方的每一行都是一条需求信息。图2中示例性地示出了每条需求信息的日志ID、APP ID、修改人、创建时间和状态，并且每条需求信息右侧还包括操作按钮，比如查看按钮、编辑按钮、测试通过按钮、申请发布按钮和查看发布记录按钮。若点击查看按钮，该需求管理界面即可展示该条需求信息的需求详情。

若用户点击新增按钮，即会显示与用户选择的需求类型匹配的需求详情填写模板，以供需求提供方录入需求信息。

此外，日志中台的RD可以选择图2下方的需求信息，点击发布按钮，即可对选择的需求信息进行发布。

图2仅为需求管理界面的一种示例，本申请实施例对需求管理界面的形式不作限定。

采用上述方法，需求提供方录入APP ID和日志ID后，可以在菜单栏选择目标需求类型，之后服务器响应于需求提供方选择的目标需求类型，在需求录入界面显示与选择的目标需求类型对应的需求详情填写模板，进而，需求提供方可以根据需求详情填写模板录入需求。可见，通过该方法可以使得需求提供方采用相对规范的格式录入需求信息，通过为每种需求类型预设需求详情填写模板，可以规范录入需求信息的格式，且简化需求提供方录入需求的操作。相较于由日志中台的RD和需求提供方沟通需求，该方法节约了沟通成本，同时便于需求提供方的操作，且降低了需求信息录入出错的概率。

在本公开的一些实施例中，在将审核通过的需求信息写入需求发布表之前，可以将需求提供方录入的需求信息存储至需求编辑表中，当接收到对需求编辑表中的需求信息的审核请求时，在审核界面显示待审核需求信息。进而，日志中台的RD可以在审核界面对待审核需求信息进行审核。

其中，需求编辑表用于存储需求提供方录入的需求信息，需求编辑表位于数据库中，例如，该数据库可以为MySQL数据库。

审核界面可以为浏览器中的网页的形式，例如可以为图2所示的界面。

需求提供方可以与日志中台的RD约定更新需求信息的时间段，需求提供方可以随时录入需求信息，日志中台的RD也可以在约定时间段内对需求信息进行审核。例如，可以每周审核一次，也可以随时主动查询是否存在需要审核的需求信息。

此外，在审核界面可以查询到需求编辑表中所有的需求信息，日志中台的RD可以选择需要审核的待审核需求信息。

进而，服务器将审核通过的需求信息写入需求发布表，具体可以实现为：当接收到对待审核需求信息的审核通过指令时，将待审核需求信息写入需求发布表。

例如，图3是本公开实施例提供的一种需求管理过程的示例性示意图，包括日志中台用户(即需求提供方)、日志中台的RD、需求管理模块以及MySQL数据库，其中MySQL数据库中包括需求编辑表和需求发布表。

需求提供方可以按照指定格式录入需求信息，需求管理模块在接收到需求提供方录入的需求信息后，在需求编辑表中存储需求信息。

当需求管理模块接收到日志中台的RD对需求编辑表中的需求信息的审核请求时，需求管理模块可以从需求编辑表中读取待审核的需求信息，进而RD可以查看待审核的需求信息并进行审核，对于审核通过的需求信息，需求管理模块将需求信息写入需求发布表。

采用上述方法，服务器将需求提供方录入的需求信息存储在需求编辑表中，当日志中台的RD对需求信息进行审核时，服务器接收到对需求编辑表中的需求信息的审核请求后，服务器会在审核界面显示待审核需求信息，以便日志中台的RD完成审核工作，对于审核通过的需求信息，将审核通过的需求信息写入需求发布表中，等待发布。如此，通过RD对需求信息的审核，保证了后续发布的需求信息的安全性，且无需RD手动编辑需求信息，减少了日志中台RD的工作量，且可以降低误操作的风险。

在本公开实施例的一种实施方式中，服务器可以直接将需求发布表中的所有需求信息转换为需求配置文件。

在公开实施例的另一种实施方式中，将需求发布表中的需求信息转换为需求配置文件，具体可以实现为：

将需求发布表中具有相同APP ID的需求信息作为一个需求信息集合。针对每个需求信息集合，对该需求信息集合中具有相同需求类型和需求详情的多个需求信息聚合为一个需求信息组，进而基于所有需求信息组生成需求配置文件。

其中，由于相同APP ID的需求信息的需求详情和需求类型可能是相同的，为了避免后续生成的需求配置文件过于冗余，可以对需求类型和需求详情进行聚合，以使需求类型和需求详情相同的多个需求信息，使用一个需求信息组。

需求信息组中包括APP ID、多个需求信息的日志ID、多个需求信息中的单个需求信息的需求类型和需求详情，服务器可以基于需求信息组，自动生成代码形式的需求配置文件。

例如，若需求信息1、需求信息2和需求信息3的APP ID均为100、需求类型均为推荐流转发，且需求详情均相同。需求信息1、需求信息2和需求信息3的日志ID分别为001、002和003。则可生成一个需求信息组，该需求信息组中包括APP ID：100；日志ID：001、002和003；需求类型：推荐流转发；以及具体的需求详情。

可以理解的是，需求详情占用的存储空间较大，每条需求信息中的需求详情占用的存储空间可达到100Byte，若直接将需求信息转换为需求配置文件，需求文件占用的内存空间将达到MB的级别，若同时为日志中台的多个服务实例下发需求配置文件，对网络的带宽需求将会过高。例如，若需对3000个服务实例下发需求配置文件，对网络的带宽需求将达到3GBps。

本公开实施例中通过对相同APP ID的需求信息进行分类，并对同类需求信息中相同需求类型和需求详情的需求信息进行进一步聚合处理，得到需求详情组，然后再用需求详情组生成需求配置文件，如此可以使得需求配置文件中没有大量冗余的需求详情，可以大幅度降低需求配置文件的大小，可以降低对网络的带宽需求。经试验，采用该方法可以将需求配置文件的大小从MB级别降低到50KB以内。

在得到需求配置文件后，本公开实施例中，可以采用灰度发布的方式进行需求发布，需求发布的过程具体包括：

步骤1、从云端获取服务实例列表。

其中，服务实例列表中包括需要被进行需求发布的服务实例，服务器可以从云端获取服务实例列表，服务实例列表中的服务实例可能会发生动态变化的，原本服务实例列表中的服务实例可能会被迁移走，也有一些服务实例被创建出来并被加入该服务实例列表，所以服务器每次进行需求发布前，均可以重新从云端获取最新的服务实例列表。

该云端具体可以为百度命名服务器(Baidu Naming Service，BNS)。

步骤2、按照预设发布比例从服务实例列表中选择待发布服务实例。

其中，预设发布比例可以为日志中台的RD在触发发布指令时，同时下发的预设发布比例，具体可以配置每整数分钟发布预设发布比例的服务实例。例如，每一分钟发布10％的服务实例。

根据预设发布比例，从服务实例列表随机选择预设发布比例的待发布实例，例如，服务实例列表中包含100个服务实例，预设发布比例为10％，则从服务实例列表随机选择10个服务实例作为待发布实例。

步骤3、按照需求配置文件对待发布服务实例进行需求发布。

当接收到待发布服务实例拉取需求配置文件的请求时，向待发布服务实例发送需求配置文件，以使得待发布服务实例基于需求配置文件进行热更新。

其中，各服务实例会周期性请求拉取需求配置文件，若服务器确定请求拉取需求配置文件的服务实例属于此次需要进行需求发布的待发布实例，则会向该服务实例下发需求配置文件。进而通过热更新的方式进行需求发布，无需频繁对各服务进行重新上线，可以解决上线频繁的问题，提高日志中台的稳定性。

间隔预设时长后，返回步骤1，直至完成对最新获取到的服务实例列表中所有服务实例的需求发布。

其中，日志中台的RD在触发的发布指令可以携带该预设时长，预设时长可以为整数分钟。例如预设时长可以为1分钟。

基于需求配置文件进行需求发布的过程如图4所示，在需求发布阶段，可以对各服务实例进行分级灰度发布。具体的，在控制模块，定时任务被预先设定为每一分钟检查一次是否有上线发布操作。当检测到上线发布操作后，定时任务触发，控制模块从云端获取服务实例列表，并生成或者更新活跃服务实例列表。该云端具体可以为BNS，控制模块可以查询BNS获取服务实例列表。若控制模块是首次获取服务实例列表，则在控制模块中生成活跃服务实例列表；若不是首次获取，则基于此次获取到的服务实例列表更新活跃服务实例列表。

控制模块从下发执行模块的发布进度表中获取发布进度，并计算当前发布进度。例如，若需要给100个服务实例下发配置，当前已为10个服务实例下发需求配置文件，则计算得到的发布进度为10％。

控制模块将待发布服务实例更新进发布计划表，其中发布计划表中包含活跃服务实例列表中的所有的服务实例，控制模块可以将发布计划表中此次将要进行发布的服务实例更新为待发布服务实例。

进而，下发执行模块从发布计划表中获取发布计划，即可以获取此次的待发布服务实例，且各服务实例会实时请求拉取需求配置文件，下发执行模块可以根据发布计划判断为各服务实例发布的版本。

若请求拉取需求配置文件的服务实例为待发布服务实例，且该待发布实例的当前版本不是最新版本，则可向该待发布服务实例下发需求配置文件。否则告知该服务实例仍以自身的当前版本运行。

将发布情况更新至发布进度表中，并在上述定时任务再次被触发时，再次执行上述过程，直至所有服务实例完成热更新。

如图5所示，图5是本公开实施例提供的一种需求发布界面的示例性示意图，上线单列表中包括各需求配置文件的版本号、上线单类型、发布说明、业务功能明细、负责人、状态、上线时间以及操作按钮等信息。以上线单列表的第一行为例，版本号为0.1.0，上线单类型为日常业务上线，发布说明为add sid，业务功能明细为{“tcbox”:[736,1384,1381,1470],“ubc-deilver”：[736,1384,1381,1470]}，负责人为A，状态为已完成，上线时间为开始时间：2022-09-06 16:56:38，结束时间：2022-09-06 16:57:23，可进行的操作包括查看diff(Difference，差别)、查看上线情况以及回滚此配置。

此外，日志中台的RD还可以查看需求发布详情，如图6所示，在需求发布过程中，服务器会向各个服务实例逐个下发需求配置文件，每个服务实例在接收到需求配置文件后，日志中台的RD还可以在需求发布详情界面对每个服务实例的需求发布进行暂停、跳过、继续和下一步等操作，图6中顶部每个圆圈用于表示一个服务实例是否完成需求发布，带有对勾的圆圈表示已完成需求发布，例如图6中服务实例A-G已完成需求发布，最后一个服务实例H未完成需求发布。

日志中台的RD还可以通过设置开始时间、结束时间、当前比例以及服务实例名来搜索相应的需求发布详情。同时在图6下半部分的上线详情中，会显示每个实例名以及每个实例名对应的服务实例的生效状态。例如以上线详情中的第一行为例，实例名为bdapp-ubc-deliver-hnb_0001000000，生效状态为false，即未生效。

采用上述方法，服务器从云端获取服务实例列表后，根据预设发布比例从服务实例列表中选择待发布服务实例，如此，根据预设发布比例选择待发布服务实例，采用分级灰度发布的方式，每次仅对一部分服务实例进行热更新，当需求信息短时间内再次更新时，无需再次对所有的服务实例重新进行需求发布，提高了日志中台的稳定性。

在上述实施例的基础上，本公开实施例还提供一种需求发布方法的流程图，如图7所示，包括：

S701、发布。

S702、是否有“上线流程中的上线单”。

若是，执行S712，若否，执行S703。

上线流程中的上线单表示在当前的上线流程中正在发布其他需求配置文件。

S703、待审核。

同时，可以设置生效模式，该生效模式用于对服务实例进行分级灰度发布或者用于对全局所有服务实例进行同时发布。例如，所有需要发布的实例数量为100个，生效模式为“10％1分钟”，该生效模式表示，对于100个实例，每一分钟向10个实例发布配置文件。

此外在待审核阶段，可以由日志中台的RD手动撤销发布。

S704、审核。

S705、审核是否通过。

若是，执行S706，若否，执行S711。

其中，在需求发布时，可以对日志中台的RD审核过的需求进行二次审核，如果日志中台的RD审核过的需求信息仍然存在错误，例如需求信息的格式存在错误，则可以撤销发布。

S706、上线中。

对于审核通过的需求信息，日志中台可以根据需求信息自动生成需求配置文件，并根据生成的需求配置文件，对各服务实例进行分级发布。

在上线中，可以人工选择跳过上线中的某一服务实例，或者暂停该上线流程。

S707、已暂停。

当该上线流程暂停后，可以由日志中台的RD手动启动，继续该流程。

S708、上线进度协同更新。

上线进度协同更新的过程此处不再赘述，参考上述图4实施例中的相关描述。

S709、上线完成。

S710、发布成功。

S711、已撤销。

S712、发布失败。

采用上述方法，在待审核阶段可以根据实际的业务需要设置生效模式，如此，使上线过程更加的灵活，此外，对于审核通过的需求信息，服务器可以根据需求自动生成代码格式的配置文件，相较于由日志中台的RD将需求信息转换为需求配置文件，该方法降低了误操作的风险，在上线中，还可以人为的对上线流程进行跳过、继续和暂停等操作，便于日志中台的RD及时调整上线流程，提高了应对突发情况的灵活性。采用分级灰度发布进行热更新，无需频繁的上线，提高了日志中台的稳定性。

在上述实施例的基础上，在上述实施例的基础上，图8为本公开实施例提供的一种通过自助化平台完成配置发布的示例性示意图，图8中包括日志中台用户、日志中台的RD、自助化平台、数据库、服务1、服务2和服务3。

需求提供方可以在自助化平台按指定格式录入需求，日志中台的RD需要审核需求，即对需求提供方录入的需求信息进行审核，若审核通过，则在自助化平台中进行配置发单，自助化平台所在的服务器将根据需求提供方录入的需求信息，自动生成需求配置文件并将生成的需求配置文件存储在数据库中，进而对服务1、服务2和服务3进行分级发布。其中，分级发布的具体过程参考图4实施例，此处不再赘述。图8示例性示出了三个服务，本公开实施例对服务的数量不做具体限制。

本公开实施例提供的配置自主化平台，支持需求提供方的用户自主化录入需求信息，且具有基于需求提供方录入的需求信息自动生成需求配置文件的能力，并且还支持各版本需求配置文件的持久化存储和版本切换功能。在需求发布过程中，支持分级发布，且支持通过接口、Redis中间件等形式的对服务实例进行分级发布，本公开实施例对发布方式不做具体限定。在权限管理方面，还支持各种维度的权限管理，可以支持日志ID、产品线等维度的权限管理，且可以将需求录入权限下放给日志中台用户，即需求提供方，使得日志中台能够满足定制化需求，更加灵活。

基于相同的构思，图9是本公开实施例提供一种需求发布装置的结构示意图，包括：

获取模块901，用于获取需求提供方在需求录入界面按照指定格式录入的需求信息；

写入模块902，用于将审核通过的需求信息写入需求发布表；

转换模块903，用于当接收到发布指令时，将所述需求发布表中的需求信息转换为需求配置文件；

发布模块904，用于基于所述转换模块903转换的需求配置文件对日志中台中的服务进行需求发布。

可选的，所述获取模块901，具体用于：

获取所述需求提供方在需求录入界面填入的APP ID和日志ID，以及通过菜单栏选择的目标需求类型，所述菜单栏中包括预设的多种需求类型；

响应于所述需求提供方选择的所述目标需求类型，在所述需求录入界面显示所述目标需求类型对应的需求详情填写模板；

基于所述需求提供方在所述需求详情填写模板中填写的信息生成目标需求详情；

将所述需求提供方填入的APP ID和日志ID、所述目标需求类型以及所述目标需求详情作为一个需求信息。

可选的，所述装置还包括：

存储模块，用于将需求提供方录入的需求信息存储至需求编辑表中；

显示模块，用于当接收到对所述需求编辑表中的需求信息的审核请求时，在审核界面显示待审核需求信息；

所述写入模块902，具体用于：

当接收到对所述待审核需求信息的审核通过指令时，将所述待审核需求信息写入所述需求发布表。

可选的，所述转换模块903，具体用于：

将所述需求发布表中具有相同APP ID的需求信息作为一个需求信息集合；

针对每个需求信息集合，对该需求信息集合中具有相同需求类型和需求详情的多个需求信息聚合为一个需求信息组，所述需求信息组中包括APP ID、所述多个需求信息的日志ID、所述多个需求信息中的单个需求信息的需求类型和需求详情；

基于所有需求信息组生成所述需求配置文件。

可选的，所述发布模块904，具体用于：

从云端获取服务实例列表，所述服务实例列表中包括需要被进行需求发布的服务实例；

按照预设发布比例从所述服务实例列表中选择待发布服务实例；

按照所述需求配置文件对所述待发布服务实例进行需求发布；

间隔预设时长后，返回所述从云端获取服务实例列表的步骤，直至完成对最新获取到的服务实例列表中所有服务实例的需求发布。

可选的，所述发布模块904，具体用于：

当接收到所述待发布服务实例拉取需求配置文件的请求时，向所述待发布服务实例发送所述需求配置文件，以使得所述待发布服务实例基于所述需求配置文件进行热更新。

本公开的技术方案中，所涉及的用户个人信息的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。

根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。

图10示出了可以用来实施本公开的实施例的示例电子设备1000的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。

如图10所示，设备1000包括计算单元1001，其可以根据存储在只读存储器(ROM)1002中的计算机程序或者从存储单元1008加载到随机访问存储器(RAM)1003中的计算机程序，来执行各种适当的动作和处理。在RAM 1003中，还可存储设备1000操作所需的各种程序和数据。计算单元1001、ROM 1002以及RAM 1003通过总线1004彼此相连。输入/输出(I/O)接口1005也连接至总线1004。

设备1000中的多个部件连接至I/O接口1005，包括：输入单元1006，例如键盘、鼠标等；输出单元1007，例如各种类型的显示器、扬声器等；存储单元1008，例如磁盘、光盘等；以及通信单元1009，例如网卡、调制解调器、无线通信收发机等。通信单元1009允许设备1000通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

计算单元1001可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1001的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。计算单元1001执行上文所描述的各个方法和处理，例如需求发布方法。例如，在一些实施例中，需求发布方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1008。在一些实施例中，计算机程序的部分或者全部可以经由ROM1002和/或通信单元1009而被载入和/或安装到设备1000上。当计算机程序加载到RAM 1003并由计算单元1001执行时，可以执行上文描述的需求发布方法的一个或多个步骤。备选地，在其他实施例中，计算单元1001可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行需求发布方法。

本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、复杂可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD-ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。

为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，CRT(阴极射线管)或者LCD(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。

可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(LAN)、广域网(WAN)和互联网。

计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。

应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。

上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。

Claims (15)

1.一种需求发布方法，包括：

获取需求提供方在需求录入界面按照指定格式录入的需求信息；

将审核通过的需求信息写入需求发布表；

当接收到发布指令时，将所述需求发布表中的需求信息转换为需求配置文件；

基于所述需求配置文件对日志中台中的服务进行需求发布。

2.根据权利要求1所述的方法，其中，所述获取需求提供方在需求录入界面按照指定格式录入的需求信息，包括：

获取所述需求提供方在需求录入界面填入的APPID和日志ID，以及通过菜单栏选择的目标需求类型，所述菜单栏中包括预设的多种需求类型；

响应于所述需求提供方选择的所述目标需求类型，在所述需求录入界面显示所述目标需求类型对应的需求详情填写模板；

基于所述需求提供方在所述需求详情填写模板中填写的信息生成目标需求详情；

将所述需求提供方填入的APPID和日志ID、所述目标需求类型以及所述目标需求详情作为一个需求信息。

3.根据权利要求1或2所述的方法，

在所述将审核通过的需求信息写入需求发布表之前，所述方法还包括：

将需求提供方录入的需求信息存储至需求编辑表中；

当接收到对所述需求编辑表中的需求信息的审核请求时，在审核界面显示待审核需求信息；

所述将审核通过的需求信息写入需求发布表，包括：

当接收到对所述待审核需求信息的审核通过指令时，将所述待审核需求信息写入所述需求发布表。

4.根据权利要求1所述的方法，其中，所述将所述需求发布表中的需求信息转换为需求配置文件，包括：

将所述需求发布表中具有相同APP ID的需求信息作为一个需求信息集合；

针对每个需求信息集合，对该需求信息集合中具有相同需求类型和需求详情的多个需求信息聚合为一个需求信息组，所述需求信息组中包括APP ID、所述多个需求信息的日志ID、所述多个需求信息中的单个需求信息的需求类型和需求详情；

基于所有需求信息组生成所述需求配置文件。

5.根据权利要求1所述的方法，其中，所述基于所述需求配置文件对日志中台中的服务进行需求发布，包括：

从云端获取服务实例列表，所述服务实例列表中包括需要被进行需求发布的服务实例；

按照预设发布比例从所述服务实例列表中选择待发布服务实例；

按照所述需求配置文件对所述待发布服务实例进行需求发布；

间隔预设时长后，返回所述从云端获取服务实例列表的步骤，直至完成对最新获取到的服务实例列表中所有服务实例的需求发布。

6.根据权利要求5所述的方法，其中，所述按照所述需求配置文件对所述待发布服务实例进行需求发布，包括：

当接收到所述待发布服务实例拉取需求配置文件的请求时，向所述待发布服务实例发送所述需求配置文件，以使得所述待发布服务实例基于所述需求配置文件进行热更新。

7.一种需求发布装置，包括：

获取模块，用于获取需求提供方在需求录入界面按照指定格式录入的需求信息；

写入模块，用于将审核通过的需求信息写入需求发布表；

转换模块，用于当接收到发布指令时，将所述需求发布表中的需求信息转换为需求配置文件；

发布模块，用于基于所述转换模块转换的需求配置文件对日志中台中的服务进行需求发布。

8.根据权利要求7所述的装置，其中，所述获取模块，具体用于：

获取所述需求提供方在需求录入界面填入的APP ID和日志ID，以及通过菜单栏选择的目标需求类型，所述菜单栏中包括预设的多种需求类型；

响应于所述需求提供方选择的所述目标需求类型，在所述需求录入界面显示所述目标需求类型对应的需求详情填写模板；

基于所述需求提供方在所述需求详情填写模板中填写的信息生成目标需求详情；

将所述需求提供方填入的APPID和日志ID、所述目标需求类型以及所述目标需求详情作为一个需求信息。

9.根据权利要求7或8所述的装置，

所述装置还包括：

存储模块，用于将需求提供方录入的需求信息存储至需求编辑表中；

显示模块，用于当接收到对所述需求编辑表中的需求信息的审核请求时，在审核界面显示待审核需求信息；

所述写入模块，具体用于：

当接收到对所述待审核需求信息的审核通过指令时，将所述待审核需求信息写入所述需求发布表。

10.根据权利要求7所述的装置，其中，所述转换模块，具体用于：

将所述需求发布表中具有相同APP ID的需求信息作为一个需求信息集合；

针对每个需求信息集合，对该需求信息集合中具有相同需求类型和需求详情的多个需求信息聚合为一个需求信息组，所述需求信息组中包括APP ID、所述多个需求信息的日志ID、所述多个需求信息中的单个需求信息的需求类型和需求详情；

基于所有需求信息组生成所述需求配置文件。

11.根据权利要求7所述的装置，其中，所述发布模块，具体用于：

从云端获取服务实例列表，所述服务实例列表中包括需要被进行需求发布的服务实例；

按照预设发布比例从所述服务实例列表中选择待发布服务实例；

按照所述需求配置文件对所述待发布服务实例进行需求发布；

间隔预设时长后，返回所述从云端获取服务实例列表的步骤，直至完成对最新获取到的服务实例列表中所有服务实例的需求发布。

12.根据权利要求11所述的装置，其中，所述发布模块，具体用于：

当接收到所述待发布服务实例拉取需求配置文件的请求时，向所述待发布服务实例发送所述需求配置文件，以使得所述待发布服务实例基于所述需求配置文件进行热更新。

13.一种电子设备，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-6中任一项所述的方法。

14.一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行根据权利要求1-6中任一项所述的方法。

15.一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据权利要求1-6中任一项所述的方法。

Images