CN111258567B - 服务代码开发处理方法及装置 - Google Patents

Abstract

本申请实施例公开了服务代码开发处理方法及装置，所述方法为开发工具提供插件，通过所述插件执行以下处理：创建第一窗口以及第二窗口，其中，所述第一窗口用于进行代码编辑，所述第二窗口中包括用于确定服务代码类型并发起代码编辑的第一操作选项，所述服务代码类型包括：服务接口代码以及服务实现代码；通过所述第一操作选项接收到操作请求后，创建代码库，并将接收到的服务代码发布到服务器中，以便服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。通过本申请实施例，能够在灵活的支持业务场景，快速、低成本的进行新商家的接入的同时，更好的支持基于服务粒度的代码开发及发布。

Description

服务代码开发处理方法及装置

技术领域

本申请涉及服务代码开发技术领域，特别是涉及服务代码开发处理方法及装置。

背景技术

在“新零售”等线上线下相结合的业务模式下，零售商可以通过线上的应用程序(App)提供商品对象的信息，用户可以通过线上的App进行浏览、购买等行为。同时，零售商还可以开设线下的实体店铺，用户也可以通过线下的实体店铺进行商品对象的购买。同时，线上的订单也可以由线下的实体店铺进行发货等一系列的处理，并最终配送到用户指定的收货地址。但是，有些零售商可能受限于自身的资源或者能力，无法为用户提供完善的发货、配送等服务，甚至在具体进行商品的上架等处理时，也可能存在一些困难，导致效率低下，出错率高等情况。为了使得这种零售商也能够加入到“新零售”***中，“新零售”平台方可以为零售商提供一些服务，例如，标准化的流程处理服务，零售商可以通过采购平台方的服务，来完善线上线下相结合的销售链路。例如，某零售商可以采购“上架”服务，此时，平台方可以为该零售商提供相对应的解决方案，等等。

通常，具体业务链路上的服务可以是由平台方来提供，但是，随着***的发展，越来越多的外部商家需要与“新零售”平台进行合作。例如，某外部商家也能够提供“上架”服务，也希望加入到“新零售”***中，使得其他零售商也可以采购该外部商家提供的服务来解决某类问题，进而，使得这种外部商家也能够通过销售这种服务的方式，来作为另一种收入来源。

但是，能够提供上述业务链路上相关服务的商家，其内部通常也会使用具体的ERP***来实现各种信息、数据的管理。例如，商家A内部使用了一种ERP***，其内部在具体实现商品上架处理时，采用的具体方式方法，与“新零售”***平台方默认的上架处理的方法可能是不同的。此时，外部商家接入平台时，可能会希望继续沿用自己内部惯用的处理方式，而不是统一使用平台方的方案，后者需要对外部商家内部的软硬件***进行改造升级，成本会比较高。

因此，如何灵活的支持业务场景，快速、低成本的进行新商家的接入，成为需要本领域技术人员解决的技术问题。

发明内容

本申请提供了服务代码开发处理方法及装置，能够在灵活的支持业务场景，快速、低成本的进行新商家的接入的同时，更好的支持基于服务粒度的代码开发及发布。

本申请提供了如下方案：

一种服务代码开发处理方法，为开发工具提供插件，通过所述插件执行以下处理：

创建第一窗口以及第二窗口，其中，所述第一窗口用于进行代码编辑，所述第二窗口中包括用于确定服务代码类型并发起代码编辑的第一操作选项，所述服务代码类型包括：服务接口代码以及服务实现代码；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；

通过所述第一操作选项接收到操作请求后，创建代码库，并将接收到的服务代码发布到服务器中，以便服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

一种服务代码开发处理装置，所述装置为预置开发工具的插件，包括：

窗口创建单元，用于创建第一窗口以及第二窗口，其中，所述第一窗口用于进行代码编辑，所述第二窗口中包括用于确定服务代码类型并发起代码编辑的第一操作选项，所述服务代码类型包括：服务接口代码以及服务实现代码；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；

代码发布单元，用于通过所述第一操作选项接收到操作请求后，创建代码库，并将接收到的服务代码发布到服务器中，以便服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

创建第一窗口以及第二窗口，其中，所述第一窗口用于进行代码编辑，所述第二窗口中包括用于确定服务代码类型并发起代码编辑的第一操作选项，所述服务代码类型包括：服务接口代码以及服务实现代码；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；

通过所述第一操作选项接收到操作请求后，创建代码库，并在通过所述第一窗口接收到服务代码后，将所述服务代码发布到服务器中，以便所述服务器保存所述服务接口与所述服务实现之间的对应关系，服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，由于是通过将商品对象服务流程中的标准作业程序流程按照逻辑节点粒度进行拆分并抽象后进行定义的服务接口，然后针对该服务接口提供服务实现，使得流程中不同节点对应的服务实现之间实现相互独立，并提供了相应的流程引擎，可以路由到具体的服务实现层级，从而使得各个服务实现可以单独开发，单独部署，单独被调用，从而能够灵活的支持业务场景，快速、低成本的进行新商家的接入。同时，可以在集成开发工具中引入插件，该插件能够直接在集成开发工具界面内提供用于确定服务代码类型并发起代码编辑的第一操作选项，之后，开发者便可以在服务粒度上执行具体的开发工作，包括对新的服务接口的定义向服务接口提供服务实现代码，将已有的服务接口组合为新的服务接口，等等。之后，可以从开发工具直接将服务代码无缝发布到serverless平台，而无需在多个***或者平台之间来回切换，从而可以在更好地实现上述方案的落地。

另外，还可以对服务代码进行全生命周期管理，整个过程中工程师只关注服务，不关注应用，并且，不需要关心代码管理。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的***的示意图；

图2是本申请实施例提供的方法的流程图；

图3-1至3-3是本申请实施例提供的界面的示意图；

图4是本申请实施例提供的装置的示意图；

图5是本申请实施例提供的电子设备的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

首先需要说明的是，在“新零售”等线上与线下相结合的服务模式下，业务场景复杂，业务链路很长，实现了一整套从供应链到用户端的中台***。在此过程中，服务平台中的业务方经常需要处理多种标准作业流程。例如，对于面向消费者的业务方，可能会涉及到处理下单流程，发货流程等。而对于面向商家的业务方，则可能更需要处理上架流程，仓调货流程，仓补货流程，仓配送流程，修改商品价格流程等等。其中，每个流程中都可能包括多个业务逻辑节点，例如，对于商品上架流程，其中包括了拣货->打包->装箱->上架等多个节点。

现有技术中，平台方是使用了基于应用的开发模式，开发者按照应用维度进行代码开发，使得一个应用中通常包含了一个具体流程中的多个节点的实现。例如，对于前述例子中的商品上架流程，其中包括了拣货->打包->装箱->上架等多个节点，在现有技术中，会将上述流程中各个节点上的实现代码组合在一起，绑定在同一个单元里，一起开发，一起部署，一起对外提供服务。此时，假设对于上述流程中的打包服务，除了平台方能够提供相应的实现之外，另外还有两个合作的商家A、B，也能够提供各自的实现，则需要加入到上述流程中时，但是原有的流程上的实现可能就无法满足新商家的需求。比如：原流程为Start->节点A->节点B->节点C->End。当有一个新商家需要加入流程时，“节点A”对应的服务实现是按照平台的默认方式来实现的，无法满足该商家A的需求，需要基于对节点A节点新增一个实现方式：“A服务的实现2”。此时，如果按照传统的流程引擎，可以有以下几种方案：方案1：重新定义一个新流程，依旧包含“Start->节点A->节点B->节点C->End”，修改“服务A”的实现方式为“A服务的实现2”。方案2：使用原流程，但需要修改流程对应的代码，在代码中写条件语句，用以判断选择哪个调用服务，也即硬编码方式。方案3：在原流程的基础上，新增分支流程，即新增选择节点，在选择节点上增加判断条件，同时，新增条件对应的选项，通过判断条件选择调用哪个服务。这三种方案各有缺陷：方案1，需要维护多套流程，维护成本高。一旦流程模板进行了修改，对应的所有流程均需要进行修改。方案2，业务逻辑依赖代码来实现，一旦有新流程接入，就需要对流程对应的代码进行修改，这是一种侵入式的实现方式，每次修改均需进行代码发布，发布风险高，且逻辑在代码中对于非技术人员不友好。方案3，一旦有新商家接入，都需要修改流程配置，无法保持一个相对稳态的流程。

而在本申请实施例中，为了能够更灵活地支持业务场景，快速、低成本的进行新商家的接入，如图1所示，首先可以将“新零售”等服务平台中的标准作业程序流程以节点为单位，抽象出标准服务接口(在本申请实施例中可以称为SPI)，并提供第一***101，可以用于对具体的服务接口进行定义，并进行注册；之后，可以将这种服务接口的定义信息提供给具体的服务提供方(例如，服务平台本身，或者其他的外部商家等，在本申请实施例中，称为第三***103)，服务提供方则可以按照具体的服务对应的标准作业接口规范，提供具体的服务实现(在本申请实施例中可以称为bundle)。也就是说，在本申请实施例中，具体流程上的业务逻辑节点不再对应某一个固定的具体实现，而是以接口的形式存在，在定义服务接口时，只需要定义其入参、出参、功能等，而无需提供具体的实现代码。换言之，一个服务接口只需要定义出对应何种功能，需要哪些入参，哪些出参，而不需要提供具体的实现代码。具体的服务提供方则可以为具体的服务接口提供多种不同的服务实现，例如，对于“拣货”这种服务接口，在服务接口级别，无需确定具体如何实现拣货功能，但是，商家A能够提供具体的拣货服务，则可以为该服务接口提供具体的服务实现代码，也即，由商家A根据该商家A的具体拣货实现逻辑，提供关于该拣货服务的服务实现代码。另外，如果商家B也能够提供具体的拣货服务，则也可以根据该商家B内部的具体拣货实现逻辑，提供对应的拣货服务实现代码。通过这种方式，使得业务流程中的不同节点之间实现相互解耦，不同节点上的服务实现可以独立开发，独立部署，独立对外提供服务。并且，对于同一服务接口而言，可以由多个不同的服务提供方提供多种不同的服务实现代码，分别注册到流程引擎子***中，使得同一个服务接口可以有“多态”实现。

也就是说，在本申请实施例中，可以由平台方抽象出具体的服务接口，然后由服务提供方提供具体的服务实现代码，每个服务提供方的服务实现代码都可以是按照服务提供方内部ERP(企业管理计划)***中的服务实现逻辑来进行开发的。另外，具体的服务提供方所提供的服务实现代码，可以直接保存在服务提供方自己的服务器上，后续在被具体的服务调用方调用时，这种服务实现代码也可以在服务提供方自己的服务器上运行，按照服务提供方内部的实现逻辑来执行具体的操作，并将处理结果返回给服务调用方。

在通过上述方式进行了服务接口的抽象及定义，并为具体的服务接口提供了至少一个服务实现之后，服务调用方(例如，具体的业务方，等等，在本申请实施例中，可以称为第二***102)则可以通过具体的服务接口调用该服务接口下的其中一个具体的服务实现，以此获得相应的服务。服务调用方在具体进行服务调用时，可以指定所需调用的服务的id或者名称，还可以对具体所需服务实现的信息进行指定，再由具体的流程引擎***将具体的调用请求路由到具体某个服务实现对应的服务地址。其中，具体在进行服务实现的指定时，可以在调用代码中设定具体的参数信息。为了便于服务调用方进行调用参数的设定，服务提供方在提供服务实现代码时，还可以设定具体的路由规则。例如，可以一种形式下，可以直接指定具体的服务实现的id或者名称等标识信息，使得流程引擎能够直接通过服务实现的id或名称定位到具体所需调用的服务实现代码。或者，另一种实现形式下，还可以通过正则运算等方式来进行指定，此时，具体传入的参数可以是一些间接的信息，例如，可以是仓库类型，仓库Id等信息，然后通过正则运算的方式定位到具体的服务实现代码。

例如，在某“新零售”模式的服务***中，为了能够在该***的标准业务链路上，为***的标准服务接入不同合作方的ERP***，实现某一服务节点的多样化，本申请实施例针对具体业务链路上的每一种服务进行抽象，定义服务的标准接口，可以称之为SPI，例如，包括拣货服务接口，打包服务接口，上架服务接口，等等。将服务的具体实现，称之为Bundle，一个SPI可以有多个Bundle实现，做到服务实现的多态化。比如，在前述商品上架流程中，包括的拣货，打包，装箱，上架这四个节点，则在本申请实施例中，可以抽象为四个服务接口，分别为拣货服务接口，打包服务接口，装箱服务接口，上架服务接口。其中，拣货服务接口这个SPI，可以由服务提供方1提供服务实现；打包服务接口这个SPI，可以有服务提供方A提供的默认实现(Default Bundle)，也可以有服务提供方2提供的实现(例如，DaRunFaBundle)，等等。

在进行了服务接口的抽象，并在服务粒度上开发了服务实现后，可以注册到服务***中，这样，具体的实体店铺中的服务调用方便可以通过对上述服务实现的调用，来获得某种具体的功能。例如，实体店铺A中的服务调用方可以对服务提供方1提供的打包服务的实现进行调用，实现打包功能，对服务提供方2的上架服务的实现进行调用，实现上架功能；实体店铺B中的服务调用方可以对服务提供方1提供的拣货服务的实现进行调用，实现拣货功能，对服务提供方2的上架服务的实现进行调用，实现上架功能，等等。也就是说，同一服务调用方客户端在实现标准作业流程的过程中，可以通过对多种不同服务对应的实现的编排，包括设定不同服务之间的调用关系等，使用多个不同的服务提供方提供的服务实现来共同解决实际业务场景中的具体问题。

其中，无论是服务接口的定义，还是服务实现的创建，都会涉及到一些代码编辑操作，例如，服务接口的定义代码，服务实现的实现代码，等等。在本申请实施例中，上述代码的开发可以通过Serverless架构来实现。其中，Serverless架构是近年来迅速兴起的一个技术概念，基于Serverless框架，开发者无需部署、配置或管理服务器服务，代码运行所需要的服务器服务皆由云端平台来提供。但是，在本申请实施例中，由于工作粒度从单体应用切换到单体服务/函数，从过去：“构建一个框架运行在一台服务器上，对多个事件进行响应”变为：“构建/使用一个微服务或微功能来响应一个事件”。对应的，以往按照应用维度的开发，由于将各个服务绑定在同一单元里，因此，在serverless架构下，需要进行服务和功能的拆分，而将一个应用拆分为解耦的微服务，进而拆分为函数，是个工作量巨大且不易的事情。

另外，利用现有技术中的代码开发工具所开发的代码，需要通过本申请实施例提供的服务平台对应的Web页面等方式进行提交，或者发布等操作。也就是说，代码的开发操作与代码的提交，构建，部署等操作之间的割裂的，开发者需要在多套***之间来回切换，工作效率低，并且，无法实现对代码的全生命周期的管理操作。

为此，本申请的优选实施例中，还可以为现有的开发工具提供插件，通过本申请实施例提供的开发框架，可以直接以服务维度进行注册、开发、部署和管理，从而天然支持Serverless框架。也就是说，通过这种插件工具，可以帮助本申请实施例中提供的对服务的定义、服务实现的提供等更方便的实现落地提高开发效率。

具体的，在本申请实施例中，无论是服务接口的定义方，还是服务实现的提供方，只要想要加入到本申请实施例提供的服务平台，都可以在其开发工具中安装本申请实施例中提供的插件。在开发工具的展示窗口(explorer)内，还可以创建该插件对应的展示窗口，在该展示窗口中则可以展示出服务平台中已有的服务接口的列表，并且可以分类进行展示。另外，还可以提供用于新建服务接口，或者用于查看服务接口详情，用于为指定服务接口提供服务实现等操作的操作选项。在通过所述新建服务接口或者提供服务实现的操作选项接收到操作请求后，则可以自动创建代码库，并创建出用于进行代码编辑的窗口，开发者可以直接在该窗口内进行代码的编辑等操作，另外还可以进行一键式的代码构建、部署、发布等操作。另外，在本申请实施例中，为了进一步降低开发者的工作量，还可以预先提供模板，在提供所述用于进行代码编辑的窗口时，还可以同时进行代码库的初始化，提供初始代码，并且，由于本申请实施例中直接将服务平台的插件安装到开发工具中，因此，初始代码中可以包括除了具体业务代码之外的全部依赖关系信息。这样，开发者在代码编辑窗口中只需要对具体的业务代码进行编辑即可，其他的初始化工作等都无需关注。

也就是说，在本申请实施例中，由于开发者天然的按照原子化服务的维度，在代码开发工具下进行服务版本的新增，这就决定了基于本开发框架进行的开发，天然就是FAAS(Function As A Service)，无需再进行服务拆分；并且，由于服务拆分的粒度足够小，小到一个工程师可以负责一个服务，那么基于变更的代码分支就没有必要。故在本申请实施例中，开发模式默认是主干开发模式，通过对代码开发工具(例如，IDEA等)和代码管理工具(例如，gitlab等)进行集成，默认完成代码库创建和检出到本地，并使用主干开发模式，也即，每个服务实现都属于主干代码，不再需要进行创建多个分支的操作。具体实现时，首先可以按服务/接口级别，在代码开发工具上新增服务版本，之后，代码开发工具可以自动创建代码库，并创建主干分支，还可以基于自动检出到本地的代码进行开发，以及代码提交。在进行构建以及部署时，还可以使用集成到开发工具的插件中的功能，进行一键构建和部署到serverless平台。可见，本申请实施例中的开发框架，与传统的开发框架的不同点在于：由于按照原子化服务的方式进行开发、部署和管理，无需再将应用拆分为服务粒度，天然支持serverless框架；并且，可以基于代码开发工具和代码管理工具的功能做了集成，插件可以自动生成代码库并检出到本地，并且可以进行一键构建和部署到serverless平台。

这样，在本申请实施例中，可以提供完整的从零开始新建服务(以服务维度进行代码开发，而非传统的以应用维度进行开发)，并且无缝发布到serverless平台的全生命周期管理。这个过程中工程师只需要关注服务，而不需要关注应用，并且，他们不需要关心代码管理，因为代码库会被自动创建，并按照服务的版本规则自行进行分支管理，工程师只需在代码开发工具中双击一个服务进行代码开发即可。

具体实现时，参见图2，本申请实施例提供了一种服务代码开发处理方法，参见图2，该方法为开发工具提供插件，

其中，具体的集成开发工具可以有多种，具体实现时，针对不同的集成开发工具可以提供不同的插件，这种插件的功能相同，只是为了适应具体的集成开发工具，在相关接口等方面可能会有所不同。或者，在另一种实现方式下，也可以提供统一一种集成开发工具的插件，需要加入流程的开发者可以使用这种指定的集成开发工具进行代码的开发。

在代码开发工具中安装了上述插件后，则可以通过所述插件执行以下处理：

S201：创建第一窗口以及第二窗口，其中，所述第一窗口用于进行代码编辑，所述第二窗口中包括用于确定服务代码类型并发起代码编辑的第一操作选项，所述服务代码类型包括：服务接口代码以及服务实现代码；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；

在本申请实施例中，具体需要编辑的服务代码具体可以包括服务接口的定义代码，服务实现的实现代码，等等，多种不同类型的代码都可以通过安装有上述插件的代码开发工具进行开发，并进行一键式的发布。因此，在本申请实施例中，将具体的服务代码区分为服务接口代码，以及服务实现代码两种类型。对于两种不同类型的代码，在具体进行发布等处理时，可以采用不同的处理方式。

其中，在开发工具启动后，如图3-1所示，可以创建出第一窗口301以及第二窗口302，其中，所述第一窗口301具体就可以用于进行代码编辑，所述第二窗口302中则可以用于展示与本申请实施例中相关服务接口、服务实现等相关的信息，其中可以包括用于发起代码编辑的第一操作选项。

其中，关于相关服务接口、服务实现等相关的信息具体可以是保存在服务端，例如，以履约类别的服务接口为例，具体的保存方式可以如表1所示：

表1

在初始状态下，可以在第二窗口中展示出已定义的服务接口列表。其中，具体在对服务接口列表进行展示时，还可以进行分类展示，例如，在图3-1所示的例子中，主要展示的就是服务接口的类别信息，点击每个类别名称后，如图3-2所示，可以展开展示该类别下包括的具体服务接口列表，等等。其中，具体的服务接口列表信息可以是从服务配置平台中拉取得到的，也就是说，在定义了具体的服务接口后，可以向流程引擎子***服务端进行注册，并且可以记录在服务配置平台中。这样，服务配置平台中就会记录下已经定义的全部服务接口的信息。相应的，可以通过开发工具中的插件展示给代码编辑方。

其中，在本申请实施例中，具体的代码编辑方可以是进行服务接口定义的平台方，或者，还可以是需要提供服务实现代码的服务提供方，甚至，还可以是服务调用方，例如，某服务调用方在实际调用服务的过程中，需要将某两个或者多个服务组合成另一个新的服务，则也可能需要进行代码编辑的方式组合出该新的服务接口，等等。因此，所述服务代码包括服务接口的定义代码，或者为指定服务接口提供的服务实现的实现代码，或者用于将至少两个已有服务接口组合为新的服务接口的组合代码，相应的，具体的第一操作选项可以有多种。

例如，其中一种可以是用于定义新的服务接口的第一操作选项，此时，可以通过所述第一窗口接收关于所述服务接口的服务定义代码。具体的，该服务定义代码中具体可以包括用于定义服务接口的入参、出参、功能的代码。

或者，所述用于发起代码编辑的第一操作选项包括：用于为指定服务接口提供服务实现的第一操作选项，以便通过所述第一窗口接收关于所述服务实现的实现代码信息。

其中，具体在提供用于为指定服务接口提供服务实现的第一操作选项时，可以是在前述图3-2的基础上，选择查看某服务接口的详情信息之后提供。例如，如图3-3所示，在服务提供方具体点击查看某个服务接口时，还可以展示出该服务接口对应的已有的服务实现的列表信息，另外还可以包括关于该服务接口的上一次修改人，上一次修改时间，总调用次数，变更次数，当前版本中含有的方法数量等信息。另外，还可以在该界面中提供上述第一操作选项，例如，如图3-3中所示的“新建Bundle”字样的按钮，等等。其中，在图3-3所示的例子中，服务接口具体为“履约作业者协同服务-作业者”，此时，该服务接口对应的信息具体可以如以下表2所示：

表2

另外，所述用于发起代码编辑的第一操作选项包括：用于通过定义至少两个已有服务接口之间的调用关系的方式，将所述至少两个已有服务接口组合为新的服务接口的第一操作选项，以便通过所述第一窗口接收关于所述新的服务接口的组合代码信息。

例如，某服务A调用服务B，能够实现某种功能，而该功能是***中比较常用的功能，因此，在定义服务的过程中，还可以通过将该服务A与服务B进行打包，组合成另一个服务C。这样，后续再需要实现该功能时，直接调用服务C即可，而不必先调用服务A，再在服务A中调用服务B。

S202：通过所述第一操作选项接收到操作请求后，创建代码库，并将接收到的服务代码发布到服务器中，以便服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

在接收到代码编辑请求后，本申请实施例中的插件可以自动执行创建代码库的操作，而不需要开发者进行手动的创建，之后，可以通过所述第一窗口接收服务代码。另外，在优选的实施方式中，还可以在通过所述第一操作选项接收到操作请求后，根据预置的模板，通过所述第一窗口提供初始化代码。这种初始化代码具体可以包括一些依赖关系的定义，等等。也就是说，在本申请实施例中，可以自动生成一些初始化代码，这样，开发者不再需要关注这种初始化代码的实现，因此，可以提高效率。甚至，在具体实现时，除了与具体的业务逻辑相关的代码之外，都可以在初始化代码中自动提供，这样，开发者只需要关注与具体业务逻辑相关的代码实现即可，而不需要关注其他的依赖关系等信息。在完成服务代码的编辑等工作后，便可以直接在当前的开发工具中发布到本申请实施例中的服务配置平台，并且可以完成向流程引擎子***服务端的注册等操作。也就是说，可以在同一个开发工具内完成对具体代码的编辑以及发布等操作，而不必在多个工具或者***之间来回切换。

另外，在本申请实施例中，还可以提供关于具体服务代码全生命周期的其他相关操作。例如，可以对新定义的服务接口是否定义成功进行测试，获得测试结果，并提供用于对服务接口是否定义成功进行查看的第二操作选项；该第二操作选项可以通过鼠标右键选项的方式进行提供，或者，还可以通过其他快捷键的方式进行提供，等等。通过所述第二操作选项接收到操作请求后，可以提供所述测试结果。例如，某用户在完成一个服务接口的定义后，可以右键点击该服务接口的名称等信息，查询是否定义成功，等等。

另外，还可以记录服务接口与服务实现之间的对应关系；并提供用于查看服务实现所属的服务接口信息的第三操作选项；通过所述第三操作选项接收到操作请求后，还可以提供所述服务实现所属的服务接口信息。例如，具体实现时，可以查询某个条目是否对应一个bundle，属于哪个服务接口，等等。

由于本申请实施例中能够实现服务的多态化，也即，对于同一个服务接口，可以由多个不同的服务提供方为其提供多个不同的服务实现，因此，在本申请实施例中，还可以通过所述第二窗口提供指定服务接口对应的服务实现列表信息，使得用户可以查询每个服务接口对应的服务实现情况，等等。

另外，在具体实现时，还可以提供用于对所述接收到的服务代码进行构建、部署及发布的第四操作选项，通过所述第四操作选项接收到的操作请求后，可以实现对服务代码的一键式构建、部署，之后还可以进行发布。其中，所谓的构建也就是说可以将服务代码中的开发语言进行编译，生成机器可识别的语言，并生成指令包。部署的过程主要是将具体的指令包部署到具体的服务器中。其中，对于服务实现代码，具体可以部署在服务提供方的服务器中，并且在具体实现时，这种服务提供方的服务器可能是以分布式服务器集群的形式存在，因此，还可以将服务实现代码保存到多个不同的服务器中，后续在具体进行调用时，可以通过一定的负载均衡算法，从中选择出一个服务地址，为服务调用方提供具体的服务。

再者，具体实现时，还可以提供用于对已发布的服务代码进行版本更新的第五操作选项，这样，可以使得开发者能够直接在开发工具内对已经发布的代码进行版本更新等操作。

可见，在本申请实施例中，可以在集成开发工具中引入插件，该插件能够直接在集成开发工具界面内创建出用于展示具体服务接口信息的列表，之后，开发者便可以在服务粒度上执行具体的开发工作。包括对新的服务接口的定义向服务接口提供服务实现代码，将已有的服务接口组合为新的服务接口，等等。之后，可以从开发工具直接将服务代码无缝发布到serverless平台。另外，还可以对服务代码进行全生命周期管理，这个过程中工程师只关注服务，不关注应用，并且，他们不需要关心代码管理。

与前述方法相对应，本申请实施例还提供了一种服务代码开发处理装置，所述装置为预置开发工具的插件，参见图4，该装置可以包括：

窗口创建单元401，用于创建第一窗口以及第二窗口，其中，所述第一窗口用于进行代码编辑，所述第二窗口中包括用于确定服务代码类型并发起代码编辑的第一操作选项，所述服务代码类型包括：服务接口代码以及服务实现代码；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；

代码发布单元402，用于通过所述第一操作选项接收到操作请求后，创建代码库，并将接收到的服务代码发布到服务器中，以便服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

具体实现时，该装置还可以包括：

代码初始化单元，用于在通过所述第一操作选项接收到操作请求后，根据所述服务代码类型对应的模板，通过所述第一窗口提供初始化代码。

其中，所述初始化代码包括除业务逻辑代码之外的全部依赖关系代码，以便仅通过所述第一窗口接收与业务逻辑相关的代码信息。

其中，所述第一操作选项包括：用于定义新的服务接口的第一操作选项，以便通过所述第一窗口接收关于所述服务接口的服务定义代码，所述服务定义代码中包括用于对服务接口的入参、出参以及功能进行描述的代码。

此时，该装置还可以包括：

测试单元，用于对新定义的服务接口是否定义成功进行测试，获得测试结果，并提供用于对服务接口是否定义成功进行查看的第二操作选项，通过所述第二操作选项接收到操作请求后，提供所述测试结果。

另外，所述第一操作选项包括：用于为指定服务接口提供服务实现的第一操作选项，以便通过所述第一窗口接收关于所述服务实现的实现代码信息。

此时，该装置还可以包括：

信息提供单元，用于提供用于查看服务实现所属的服务接口信息的第三操作选项；通过所述第三操作选项接收到操作请求后，提供所述服务实现所属的服务接口信息。

另外，所述第一操作选项也可以包括：用于通过定义至少两个已有服务接口之间的调用关系的方式，将所述至少两个已有服务接口组合为新的服务接口的第一操作选项，以便通过所述第一窗口接收关于所述新的服务接口的组合代码信息。

其中，同一服务接口对应多个服务实现；

此时，所述装置还可以包括：

列表展示单元，用于通过所述第二窗口提供已定义的服务接口列表，并在其中一指定服务接口被选中后，提供指定服务接口对应的服务实现列表信息。

第四操作选项提供单元，用于提供用于对所述接收到的服务代码进行构建、部署及发布的第四操作选项；

所述代码发布单元具体用于，根据通过所述第四操作选项接收到的操作请求，对服务代码进行构建、部署后发布。

其中，代码发布单元具体用于：

将所述服务代码进行构建后，生成指令包，并将所述指令包部署到指定的服务器中，确定用于保存所述服务代码的服务地址；

根据所述服务代码对应的服务地址信息，对所述服务代码进行发布。

其中，所述服务器包括分布式服务器集群；所述服务代码部署到所述分布式服务器集群中的多个服务器中。

另外，该装置还可以包括：

版本更新单元，用于提供用于对已发布的服务代码进行版本更新的第五操作选项。

另外，本申请实施例还提供了一种电子设备，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

创建第一窗口以及第二窗口，其中，所述第一窗口用于进行代码编辑，所述第二窗口中包括用于确定服务代码类型并发起代码编辑的第一操作选项，所述服务代码类型包括：服务接口代码以及服务实现代码；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；

通过所述第一操作选项接收到操作请求后，创建代码库，并在通过所述第一窗口接收到服务代码后，将所述服务代码发布到服务器中，以便所述服务器保存所述服务接口与所述服务实现之间的对应关系，服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

其中，图5示例性的展示出了计算机***的架构，具体可以包括处理器510，视频显示适配器511，磁盘驱动器512，输入/输出接口513，网络接口514，以及存储器520。上述处理器510、视频显示适配器511、磁盘驱动器512、输入/输出接口513、网络接口514，与存储器520之间可以通过通信总线530进行通信连接。

其中，处理器510可以采用通用的CPU(Central Processing Unit，中央处理器)、微处理器、应用专用集成电路(Application Specific Integrated Circuit，ASIC)、或者一个或多个集成电路等方式实现，用于执行相关程序，以实现本申请所提供的技术方案。

存储器520可以采用ROM(Read Only Memory，只读存储器)、RAM(Random AccessMemory，随机存取存储器)、静态存储设备，动态存储设备等形式实现。存储器520可以存储用于控制电子设备500运行的操作***521，用于控制电子设备500的低级别操作的基本输入输出***(BIOS)。另外，还可以存储网页浏览器523，数据存储管理***524，以及代码开发处理***525等等。上述代码开发处理***525就可以是本申请实施例中具体实现前述各步骤操作的应用程序。总之，在通过软件或者固件来实现本申请所提供的技术方案时，相关的程序代码保存在存储器520中，并由处理器510来调用执行。

输入/输出接口513用于连接输入/输出模块，以实现信息输入及输出。输入输出/模块可以作为组件配置在设备中(图中未示出)，也可以外接于设备以提供相应功能。其中输入设备可以包括键盘、鼠标、触摸屏、麦克风、各类传感器等，输出设备可以包括显示器、扬声器、振动器、指示灯等。

网络接口514用于连接通信模块(图中未示出)，以实现本设备与其他设备的通信交互。其中通信模块可以通过有线方式(例如USB、网线等)实现通信，也可以通过无线方式(例如移动网络、WIFI、蓝牙等)实现通信。

总线530包括一通路，在设备的各个组件(例如处理器510、视频显示适配器511、磁盘驱动器512、输入/输出接口513、网络接口514，与存储器520)之间传输信息。

另外，该电子设备500还可以从虚拟资源对象领取条件信息数据库541中获得具体领取条件的信息，以用于进行条件判断，等等。

需要说明的是，尽管上述设备仅示出了处理器510、视频显示适配器511、磁盘驱动器512、输入/输出接口513、网络接口514，存储器520，总线530等，但是在具体实施过程中，该设备还可以包括实现正常运行所必需的其他组件。此外，本领域的技术人员可以理解的是，上述设备中也可以仅包含实现本申请方案所必需的组件，而不必包含图中所示的全部组件。

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

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于***或***实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的***及***实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的服务代码开发处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。

Claims (12)

1.一种服务代码开发处理方法，其特征在于，为开发工具提供插件，通过所述插件执行以下处理：

创建第一窗口以及第二窗口，其中，所述第一窗口用于进行代码编辑，所述第二窗口中包括用于确定服务代码类型并发起代码编辑的第一操作选项，所述服务代码类型包括：服务接口代码以及服务实现代码；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；其中，所述第一操作选项包括：用于定义新的服务接口的第一操作选项，以便通过所述第一窗口接收关于所述服务接口的服务定义代码，所述服务定义代码中包括用于对服务接口的入参、出参以及功能进行描述的代码；或者，用于为指定服务接口提供服务实现的第一操作选项，以便通过所述第一窗口接收关于所述服务实现的实现代码信息；或者，用于通过定义至少两个已有服务接口之间的调用关系的方式，将所述至少两个已有服务接口组合为新的服务接口的第一操作选项，以便通过所述第一窗口接收关于所述新的服务接口的组合代码信息；

通过所述第一操作选项接收到操作请求后，创建代码库，并将接收到的服务代码发布到服务器中，以便服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

2.根据权利要求1所述的方法，其特征在于，

在通过所述第一操作选项接收到操作请求后，还包括：

根据所述服务代码类型对应的模板，通过所述第一窗口提供初始化代码。

3.根据权利要求2所述的方法，其特征在于，

所述初始化代码包括除业务逻辑代码之外的全部依赖关系代码，以便仅通过所述第一窗口接收与业务逻辑相关的代码信息。

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

在所述第一操作选项用于定义新的服务接口时，对新定义的服务接口是否定义成功进行测试，获得测试结果，并提供用于对服务接口是否定义成功进行查看的第二操作选项；

通过所述第二操作选项接收到操作请求后，提供所述测试结果。

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

在所述第一操作选项用于为指定服务接口提供服务实现时，提供用于查看服务实现所属的服务接口信息的第三操作选项；

通过所述第三操作选项接收到操作请求后，提供所述服务实现所属的服务接口信息。

6.根据权利要求1所述的方法，其特征在于：

同一服务接口对应多个服务实现；

所述方法还包括：

通过所述第二窗口提供已定义的服务接口列表，并在其中一指定服务接口被选中后，提供指定服务接口对应的服务实现列表信息。

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

提供用于对所述接收到的服务代码进行构建、部署及发布的第四操作选项；

根据通过所述第四操作选项接收到的操作请求，对服务代码进行构建、部署后发布。

8.根据权利要求7所述的方法，其特征在于：

所述对服务代码进行构建、部署后发布，包括：

将所述服务代码进行构建后，生成指令包，并将所述指令包部署到指定的服务器中，确定用于保存所述服务代码的服务地址；

根据所述服务代码对应的服务地址信息，对所述服务代码进行发布。

9.根据权利要求8所述的方法，其特征在于：

所述服务器包括分布式服务器集群；

所述服务代码部署到所述分布式服务器集群中的多个服务器中。

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

提供用于对已发布的服务代码进行版本更新的第五操作选项，以用于对所述服务代码的版本进行更新。

11.一种服务代码开发处理装置，其特征在于，所述装置为预置开发工具的插件，包括：

窗口创建单元，用于创建第一窗口以及第二窗口，其中，所述第一窗口用于进行代码编辑，所述第二窗口中包括用于确定服务代码类型并发起代码编辑的第一操作选项，所述服务代码类型包括：服务接口代码以及服务实现代码；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；其中，所述第一操作选项包括：用于定义新的服务接口的第一操作选项，以便通过所述第一窗口接收关于所述服务接口的服务定义代码，所述服务定义代码中包括用于对服务接口的入参、出参以及功能进行描述的代码；或者，用于为指定服务接口提供服务实现的第一操作选项，以便通过所述第一窗口接收关于所述服务实现的实现代码信息；或者，用于通过定义至少两个已有服务接口之间的调用关系的方式，将所述至少两个已有服务接口组合为新的服务接口的第一操作选项，以便通过所述第一窗口接收关于所述新的服务接口的组合代码信息；

代码发布单元，用于通过所述第一操作选项接收到操作请求后，创建代码库，并将接收到的服务代码发布到服务器中，以便服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

12.一种电子设备，其特征在于，包括：

一个或多个处理器；以及

与所述一个或多个处理器关联的存储器，所述存储器用于存储程序指令,所述程序指令在被所述一个或多个处理器读取执行时，执行如下操作：

创建第一窗口以及第二窗口，其中，所述第一窗口用于进行代码编辑，所述第二窗口中包括用于确定服务代码类型并发起代码编辑的第一操作选项，所述服务代码类型包括：服务接口代码以及服务实现代码；其中，所述服务接口是按照商品对象服务流程中的节点进行定义的，所述服务实现是根据所述服务接口的定义信息提供的；其中，所述第一操作选项包括：用于定义新的服务接口的第一操作选项，以便通过所述第一窗口接收关于所述服务接口的服务定义代码，所述服务定义代码中包括用于对服务接口的入参、出参以及功能进行描述的代码；或者，用于为指定服务接口提供服务实现的第一操作选项，以便通过所述第一窗口接收关于所述服务实现的实现代码信息；或者，用于通过定义至少两个已有服务接口之间的调用关系的方式，将所述至少两个已有服务接口组合为新的服务接口的第一操作选项，以便通过所述第一窗口接收关于所述新的服务接口的组合代码信息；

通过所述第一操作选项接收到操作请求后，创建代码库，并在通过所述第一窗口接收到服务代码后，将所述服务代码发布到服务器中，以便所述服务器保存所述服务接口与所述服务实现之间的对应关系，服务调用方通过所述服务接口发起对所述服务实现的调用，以获得对应节点上的服务。

Images