CN102158498B - 一种支持服务定制与扩展的网络节点结构实现方法 - Google Patents

Abstract

一种支持服务定制与扩展的网络节点结构实现方法，使用服务容器代替传统网络体系结构中的协议栈，使用可部署协议单元及其动态组合代替原来的一系列协议，服务容器向网络应用提供服务接口，接收网络应用对网络服务的定制请求，内部通过组织协议单元实现并提供对应的定制服务；服务容器向服务提供者提供部署接口，动态加载或卸载协议单元，通过协议单元的装卸实现网络功能的动态扩展。本发明中，网络应用既可以获得和传统网络体系结构中等价的网络服务，也可以通过向服务容器提出面向连接、服务质量、安全等方面需求的服务定制请求，获得更为灵活的服务支持，服务容器的服务可以进行灵活扩展。

Description

一种支持服务定制与扩展的网络节点结构实现方法

技术领域

本发明属于计算机网络技术领域，涉及网络节点系统，用于提供可定制和可扩展的网络传输服务，为一种支持服务定制与扩展的网络节点结构实现方法，可以部署在网络端节点或中间节点上。

背景技术

网络体系结构规定了网络设备和终端设备间的信息交互，存取控制，连接方式和拓扑结构等，体现为一系列的协议和标准。目前广泛应用的TCP/IP五层网络结构形成于20世纪70年代，其层次结构和基于尽力而为、分组转发的思想较好的解决的复杂通信协议的设计问题，并提供了一定的扩展性和较高的效率。

随着互联网应用的发展，网络应用对网络体系结构提出了新的要求，具体表现为：协调利益，提供信任和开放性，即新一代的互联网应该是可信可控可扩展的。

目前的网络系统中，网络应用要使用网络传输服务，一般要通过Socket等接口。这些技术是同传统TCP/IP协议栈紧密相连的，可以提供稳定，高效的传输服务。但这些服务不能满足目前和今后互联网应用对网络扩展性的要求。比如，当网络应用需要对连接的行为，或安全和服务质量的参数有特殊要求时，就不得不同各个层的其它协议交互，甚至要设计和重新部署自己的私有协议。具体来说，当应用程序在通过Socket提供的流类型套接字使用TCP服务时，如果对传输的数据安全性有要求，需要对数据进行加密和签名，则要么通过使用IPSec或SSL等协议代替直接使用TCP协议，要么自己在TCP协议之上自己实现加密和签名。无论哪一种方法应用程序都必须重新实现调用网络功能进行传输的代码，甚至要修改编译环境，这就大大增加了网络应用开发的难度以及网络服务部署的成本。分析其中的原因，一方面是目前网络体系结构中共存的完成不同功能的协议分布在不同的层次，有不同的调用规范和使用方法，另一方面用户在需要自己对网络功能进行扩展时除了要考虑如何实现自己需要的业务，还要考虑在哪一层扩展，要遵守哪些规范等信息。此外，在传统的堆栈式网络系统中，增加新的服务功能可能涉及多个层，或者会造成功能冗余的情况，扩展性问题也影响到互联网应用的进一步发展。

发明内容

本发明要解决的问题是：目前的网络系统中，网络应用使用的网络传输服务不能满足对网络服务的特别定制，以及对网络功能扩展性的使用要求。

本发明的技术方案为：一种支持服务定制与扩展的网络节点结构实现方法，将网络协议功能按连接、服务质量与安全三大逻辑域分解为多个原子功能，称之为元服务，在网络节点上部署若干服务容器，每个服务容器管理和组织一组具有相同接口的协议单元，每个协议单元对应一个元服务，完成对应的网络功能，用户通过向服务容器部署新的协议单元来增加服务容器提供的网络服务，部署时提供协议单元的二进制文件和所增加的网络服务的说明。服务容器收到新部署的请求后，将协议单元加载到内存运行，并根据网络服务的说明更新服务容器的服务请求解析模块，所述服务请求解析模块用于接收用户的服务请求，完成对服务请求的初步解析，并对协议单元进行配置和组织，产生服务实例；网络应用向服务容器提出网络服务需求，服务容器组织对应的元服务来满足网络应用的需求，网络应用使用服务容器提供的元服务，为最终用户提供其所需服务；其中，服务容器使用服务实例对协议单元进行管理和组织，每个服务实例对应每个接受的网络传输服务需求，服务实例的内容为提供某一网络传输服务需求所需要的一组协议单元的组织方式以及这些协议单元间的数据交换方式。

服务容器的结构包括：

1)用户接口：包括应用数据接口和服务请求解析模块，用户数据接口用于接收用户的服务请求数据，并进行打包，查询服务实例；服务请求解析模块用于接收用户的服务请求，并完成对服务请求的初步解析，然后选择适当的协议单元进行配置和组织，产生服务实例；

2)服务实例库：保存生成的服务实例，提供查询服务，服务实例中保存三类信息，一是服务请求的XML原文，用于用户在使用服务中或调试时反查用户正在使用的服务，二是XML原文对应的经过初步解析的结构体变量，用于服务容器内部获取服务信息，三是经过配置和组织协议单元后生成的报文流程信息，即报文处理时的上下文，这部分信息用来指导报文进入系统后如何按照一定的流程在协议单元中进行交换；

3)网络接口：用于直接访问网络；

4)交换模块：负责服务容器内的报文的交换，包括网络接口、用户接口和协议单元之间的报文交互收发；

5)基本服务功能模块：提供基础服务，包括报文管理、定时器、日志与输出管理。

协议单元的输入和输出以报文为单元，服务容器的交换模块负责在属于同一服务实例的协议单元间交换报文；在服务容器内交换的报文包括服务容器和协议单元使用的控制部分、控制网络传输行为的协议部分和来自网络应用的数据部分，服务容器使用基本服务功能模块中的报文管理模块对报文进行内存存储管理：所有报文按一个统一的结构进行存储和交换，所述结构中按服务容器控制部分、协议控制部分和数据部分将报文分为不同的块，并提供预留内存空间用于读取，修改和扩充操作，同时提供访问各个块的接口；每个协议单元维护自身的状态，所述自身的状态仅与协议单元自身对应的元服务相关，而与服务容器的状态无关，协议单元根据自身的状态操作报文的内容来完成业务，对于需要协议单元间进行交互的情况，交互信息体现在报文中的控制部分。

本发明具体步骤如下：

第1步：服务容器安装

服务容器安装在网络节点上，服务容器的设置包括运行时需要的文件和网络应用开发时使用的头文件、库文件；

第2步：部署协议单元

根据网络节点的需要，在服务容器中部署具有相应元服务的协议单元，通过提供协议单元的二进制文件和增加的服务说明，协议单元的二进制文件由服务容器加载进入内存运行，完成元服务的部署及维护；

第3步：接收网络应用的网络服务请求

网络应用将自己对网络服务的需求以XML形式提交给服务容器，服务容器的服务请求解析模块对这些网络请求进行分析并生成对应的服务实例，然后向网络应用返回这个服务实例的访问点；

第4步：网络应用使用服务容器提供的服务

网络应用得到服务容器返回的访问点后，通过这个访问点使用网络服务，网络应用将自身的数据通过访问点提供的接口交给服务容器，由服务容器组织协议单元对数据按预定制的服务要求进行处理；同时网络应用通过用户数据接口从访问点获得其它网络节点发送到本节点的数据；

第5步：网络应用撤销网络服务请求

当网络应用不再需要已请求的网络服务时，通过访问点向服务容器提出撤销对应的服务实例，以节省资源，服务容器收到撤销的命令后，删除服务实例，并回收对应的访问点；

第3步至第5步为网络应用使用网络服务的一个周期，网络应用撤销网络服务后，如需使用同样的定制服务，需要重新请求服务容器才能继续使用网络服务。

本发明能够提供可自由定制的接口和部署接口，使网络应用可以按需灵活定制所需的网络服务，服务容器中的元服务可以随时按照需要进行扩展部署，由于元服务是原子功能，便于按照需求进行个性化的组织。比如，可以直接定制有安全保障的点到点有连接传输服务，以及可以按应用的需要进行灵活的服务扩展，即当系统不能提供某个服务时，可以很方便地对它进行扩展。因此，本发明可以大大减少应用开发的难度及网络服务部署的成本。

与现有技术相比，本发明具有如下优点及有益效果：

(1)将原本以TCP/IP协议栈为基础的分层网络变成了应用-服务容器的宏观分层，网络功能的扩展也由原来的在协议栈中通过静态方式添加协议变为了通过动态方式向服务容器中添加协议单元。由于这种扩展方式将由容器来维护协议单元的运行及其内部数据交换，协议单元只需完成对应的功能，使得扩展更加灵活和方便；

(2)现有网络节点上网络应用只能通过Socket等接口获得已定义好的网络服务，而在本发明提出的网络系统节点中，网络应用可以通过XML文本描述定制服务的请求，获得其所需要的服务。根据协议单元能提供的服务，服务请求可以包括所需服务的各个细节。以连接管理协议单元为例，XML文本除了包括是否有连接、连接的目的端、本端的连接中的角色是服务器还是客户端等，还可以包括连接创建的时间：立即、延时或按需、连接持续的方式：是否有超时时间等、是否需要高级连接特性：比如连接转发等。应用程序通过这种机制，仅仅只要编写一个服务请求文档，向服务容器提交这个请求，就可以获得原来可能需要调用多个不同层次不同协议才能实现的网络传输服务。因此，本发明可以使网络服务得到更加灵活的部署，具有良好的扩展性，从而更好的满足最终用户的服务定制应用需求。

附图说明

图1是本发明服务容器结构示意图。

图2是本发明服务定制与扩展的流程图。

图3是本发明报文收发与转发的流程图。

图4是本发明报文管理模块用来对报文进行存储、交换和管理的结构。

具体实施方式

本发明将网络协议功能按连接、服务质量与安全三大逻辑域分解为多个原子功能，称之为元服务，在网络节点上设置若干服务容器，每个服务容器管理和组织一组具有相同接口的协议单元，每个协议单元对应一个元服务，完成对应的网络功能，用户通过向服务容器部署新的协议单元来增加服务容器提供的网络服务，部署时提供协议单元的二进制文件和所增加的网络服务的说明，服务容器收到新部署的请求后，将协议单元加载到内存运行，并根据网络服务的说明更新服务容器的服务请求解析模块，所述服务请求解析模块用于接收用户的服务请求，完成服务请求的初步解析，并对协议单元进行配置和组装，产生服务实例；网络应用向服务容器提出网络服务需求，服务容器组织对应的元服务来满足网络应用的需求，网络应用使用服务容器提供的元服务，为最终用户提供其所需服务，其中服务容器使用服务实例对协议单元进行管理和组织，每个服务实例对应每个接受的网络传输服务需求，服务实例的内容为提供某一网络传输服务需求所需的一组协议单元以及这些协议单元间的数据交换方式。

协议单元的输入和输出以报文为单元，服务容器负责在属于同一服务实例的协议单元间交换报文，在服务容器内交换的报文包括服务容器和协议单元使用的控制部分、控制网络传输行为的协议部分和来自网络应用的数据部分，服务容器使用“缓存/SDU”模块对报文进行管理，所有报文按一个统一的结构进行存储和交换，这个结构如图4所示。这个结构中按容器控制部分、协议控制部分和数据部分将报文分为不同的块，并提供了预留空间方便这些块的操作，如读取，修改和扩充，同时提供访问各个块的接口；每个协议单元维护自己的状态，这些状态仅与协议单元自己的业务相关，而与服务容器的状态无关，如连接管理协议单元中需要维护连接控制块列表和每个控制块的状态，协议单元根据这些状态操作报文的内容来完成自己的业务，具体的操作根据不同的状态和具体的业务而定。如连接管理协议单元中可以根据控制块的状态发送握手报文，或是修改报文的序号等。对于需要协议单元间进行交互的情况，交互信息体现在报文中的控制部分。

如图1，本发明服务容器结构为：本图表示容器系统内部包含的基本模块及其相互之间的关系，以及外部接口。本图对应容器实现的具体方案。容器的基本结构包括：

1.用户接口：包括应用数据接口和服务请求解析模块，主要任务是接收用户的服务请求，进行解析和组装各个协议单元。这一部分包含两个模块，一是用户数据接口，用于接收用户的数据，并进行打包，查询服务实例，复用/解复用等操作。二是服务请求解析模块，用于接收用户的服务请求，并完成服务的初步解析，以及对协议单元进行配置和组装，产生服务实例。

2.服务实例库：保存生成的服务实例，提供查询等服务。实际应用中，为了方便服务实例中保存了三类信息，一是服务请求的XML原文，用于用户在使用服务中或调试时反查用户正在使用服务，二是原文对应的经过初步解析的结构体变量，用于容器内部获取服务信息，三是经过配置和组装协议单元后生成的报文流程信息，即报文处理时的上下文，这部分信息用来指导报文进入系统后如何按照一定的流程在协议单元中进行交换。

3.网络接口：直接访问网络，例如在实施中采用IP层或Ethernet层作为隧道。

4.交换模块：负责各个协议单元间报文的交换。网络接口，用户接口和其它协议单元等需要处理报文的单元都通过与交换模块交互收发报文。

5.基本服务功能：提供如内存管理，定时器，日志与输出管理等基本服务，这些功能虽然彼此没有联系，也不承担具体的业务功能，但是它们为容器其它部分和协议单元提供最基础的服务，是容器中重要的组成部分。

本发明实施包括以下步骤：

第1步：服务容器安装

服务容器安装在网络节点上，服务容器的设置包括运行时的二进制文件和网络应用开发时使用的头文件、库文件；

第2步：部署协议单元

根据网络节点的需要，比如是否需要安全或者服务质量保证，以及需要什么样的安全和服务质量保证等需求，在服务容器中部署相应协议单元，如安全协议单元等，通过提供协议单元的二进制文件和增加的服务的说明，协议单元的二进制文件由服务容器加载进入内存运行，完成元服务的部署及维护；

第3步：接收网络应用的网络服务请求

网络应用将自己对网络服务的需求以XML形式提交给服务容器，服务容器对这些网络请求通过服务请求解析模块进行分析并生成对应的服务实例，然后向网络应用返回这个服务实例的访问点；

第4步：网络应用使用服务容器提供的服务

网络应用得到服务容器返回的访问点后，通过这个访问点使用网络服务，网络应用将自身的数据通过访问点提供的接口交给服务容器，由服务容器组织协议单元对数据按预定制的服务要求进行处理；同时网络应用通过用户数据接口从访问点获得其它网络节点发送到本节点的数据。

第5步：网络应用撤销网络服务请求

当网络应用不再需要已请求的网络服务时，通过访问点向服务容器提出撤销对应的服务实例，以节省资源，服务容器收到撤销的命令后，删除服务实例，并回收对应的访问点；

第3步至第5步为网络应用使用网络服务的一个周期，网络应用撤销网络服务后，如需使用同样的定制服务，需要重新请求服务容器才能继续使用网络服务。

图2是本发明服务定制与扩展的流程图。对应上述的第2步和第3步，服务容器中的服务请求解析模块在接收到用户的服务定制和扩展要求时所执行的流程，具体实现服务的定制和扩展功能，是本发明的核心之一。下面对这个流程进行说明：

其中，服务定制流程如下：服务容器收到来自用户的服务请求后，首先将服务请求解析成内部格式，之后根据初步处理过的服务请求中的服务类型信息判断容器内是否有可以完成这些服务的协议单元，如果没有的话，则向用户返回无法提供这些服务，否则将服务请求进行进一步解析，把由各个协议单元的服务需求分解，并交给相应的元服务进行处理。之后等待所有的协议单元处理完成，当所有协议单元配置完成返回成功后，服务容器生成服务实例，正式向用户提供他所请求的服务，如果至少有一个协议单元配置失败，则也向用户返回无法提供这些服务。

其中，服务扩展的流程如下：服务容器收到服务扩展请求后，首先也是对请求进行解析，提取扩展的描述信息，包括扩展的类型，协议单元的扩展还是协议单元内部的扩展，以及扩展所涉及的文件等，之后根据扩展的类型做不同的处理。如果是协议单元内部的扩展，则将扩展信息发给对应的协议单元，由协议单元进行扩展操作；如果是协议单元的扩展，则由服务容器自己根据扩展请求提供的文件安装协议单元，同时更新服务解析模块以便用户使用新服务。

图3是报文收发与转发的流程图。对应上述的第4步，表示服务容器在为用户生成服务实例之后，用户通过服务容器的数据接口和网络接口使用这个服务实例所代表的定制服务时的流程，是本发明中最基本工作流程。下面对这个流程进行说明：

其中数据服务的下行流程，即发送数据的流程是：服务容器收到来自用户访问点的数据后，首先将数据分段，使用报文管理模块提供的功能把数据封包，包装成服务容器内部的模式，然后根据数据来自的访问点的信息查找对应的服务实例，查找成功后根据服务实例设置报文状态，即初始化报文结构的控制部分，将报文需要由哪些协议单元处理、处理的流程是什么，以数组的形式写在报文结构的控制部分中。之后报文被送到交换模块，根据上一步写的处理信息，由交换模块将报文在不同协议单元中进行交换，处理报文。这一流程走完后，报文会被送到网络接口，在这里报文被重新封装，去掉了内部的控制信息，只留下协议单元相关的协议信息和处理过的数据，之后加上根据报文控制部分生成的自定义报头，这一部分的主要内容是服务实例的编号，还用来表明报文是由服务容器生成的，再加上隧道头或下层网络的报头，发向网络。

同样的，上行流程，即接收数据的流程如下：服务容器从网络接口收到报文，首先判断报文是否合法，即根据报文是否有自定义报文头判断这是不是由容器发出的报文，之后将报文去掉隧道或下层网络头部，将报文的协议单元生成的部分和数据重新封装成服务容器的内部格式，根据自定义报文头的服务实例编号重新生成控制部分，将再根据控制部分中的服务实例信息在服务实例库中查找对应的服务实例。之后与下行流程类似，首先根据服务实例的内容填写控制部分中的报文处理流程，再把报文交到交换模块，由交换模块交给各个协议单元进行处理。处理完成后，如果这个报文是到本机的报文(服务实例中会注明这一信息)则报文会交给用户数据接口，去掉各种控制头，留下用户数据等待用户处理。若本机是转发节点，报文会放到网络接口重新发送出去。

下面通过具体实施例来说明本发明的实施。

假设用户需要这样的一种网络服务：指定特殊连接需求、服务质量需求和安全性需求。则：

1、通过XML将这些需求描述出来：

在试验中，我们采用如下的形式来描述服务需求：

2、将XML递交给服务容器，伪代码如下：

应用提交请求后，等待服务容器的处理。

3、服务容器处理请求：

服务容器对XML进行解析。首先，将它转化为内部的数据结构，然后根据内部协议单元的信息生成将要参与到服务实例中的协议单元列表，再将之前得到的请求分解，把对应各个协议单元的细节请求交给协议单元进行配置。当各个协议单元配置完成后，容器生成服务实例，并向应用返回一个访问点。如果容器发现拥有的协议单元暂时无法满足服务请求，或者协议单元在配置过程中发生错误，刚向应用返回失败信息。

4、网络应用使用服务：

应用得到访问点后，可以使用访问点来使用网络服务。伪代码如下：

ap1-＞APSend(buff，&n)；

5、网络应用撤销服务：

应用不再需要这个服务时，向容器提出撤销该服务实例。伪代码如下：

container.WithdrawService(ap1)

本发明使用服务容器代替传统网络体系结构中的协议栈，使用可部署协议单元及其动态组合代替原来的一系列协议，服务容器向网络应用提供服务接口，接收网络应用对网络服务的定制请求，内部通过组织协议单元实现并提供对应的定制服务；服务容器向服务提供者提供部署接口，动态加载或卸载协议单元，通过协议单元的装卸实现网络功能的动态扩展；同时，服务容器控制协议单元的运行、管理等。本发明中，网络应用既可以获得和传统网络体系结构中等价的网络服务，也可以通过向服务容器提出面向连接、服务质量、安全等方面需求的服务请求，获得更为灵活的服务支持。相对于传统的网络节点结构，本发明可以向网络应用提供可定制的服务，而在传统网络体系结构中这可能需要应用同协议栈中多个协议进行交互；同时，服务容器的服务能力可以通过协议单元的动态部署进行灵活扩展，而不需要重新部署新协议。

Claims (4)

1.一种支持服务定制与扩展的网络节点结构实现方法，其特征是将网络协议功能按连接、服务质量与安全三大逻辑域分解为多个原子功能，称之为元服务，在网络节点上部署若干服务容器，每个服务容器管理和组织一组具有相同接口的协议单元，每个协议单元对应一个元服务，完成对应的网络功能，用户通过向服务容器部署新的协议单元来增加服务容器提供的网络服务，部署时提供协议单元的二进制文件和所增加的网络服务的说明；服务容器收到新部署的请求后，将协议单元加载到内存运行，并根据网络服务的说明更新服务容器的服务请求解析模块，所述服务请求解析模块用于接收用户的服务请求，完成对服务请求的初步解析，并对协议单元进行配置和组织，产生服务实例；网络应用向服务容器提出网络服务需求，服务容器组织对应的元服务来满足网络应用的需求，网络应用使用服务容器提供的元服务，为最终用户提供其所需服务；其中，服务容器使用服务实例对协议单元进行管理和组织，每个服务实例对应每个接受的网络传输服务需求，服务实例的内容为提供某一网络传输服务需求所需要的一组协议单元的组织方式以及这些协议单元间的数据交换方式。

2.根据权利要求1所述的一种支持服务定制与扩展的网络节点结构实现方法，其特征是服务容器的结构包括：

1）用户接口：包括应用数据接口和服务请求解析模块，用户数据接口用于接收用户的服务请求数据，并进行打包，查询服务实例；服务请求解析模块用于接收用户的服务请求，并完成对服务请求的初步解析，然后选择适当的协议单元进行配置和组织，产生服务实例；

2）服务实例库：保存生成的服务实例，提供查询服务，服务实例中保存三类信息，一是服务请求的XML原文，用于用户在使用服务中或调试时反查用户正在使用的服务，二是XML原文对应的经过初步解析的结构体变量，用于服务容器内部获取服务信息，三是经过配置和组织协议单元后生成的报文流程信息，即报文处理时的上下文，这部分信息用来指导报文进入系统后按照统一的结构在协议单元中进行交换；

3）网络接口：用于直接访问网络；

4）交换模块：负责服务容器内的报文的交换，包括网络接口、用户接口和协议单元之间的报文交互收发；

5）基本服务功能模块：提供基础服务，包括报文管理、定时器、日志与输出管理。

3.根据权利要求2所述的一种支持服务定制与扩展的网络节点结构实现方法，其特征是协议单元的输入和输出以报文为单元，服务容器的交换模块负责在属于同一服务实例的协议单元间交换报文；在服务容器内交换的报文包括服务容器和协议单元使用的控制部分、控制网络传输行为的协议部分和来自网络应用的数据部分，服务容器使用基本服务功能模块中的报文管理模块对报文进行内存存储管理：所有报文按一个统一的结构进行存储和交换，所述结构中按服务容器控制部分、协议控制部分和数据部分将报文分为不同的块，并提供预留内存空间用于读取，修改和扩充操作，同时提供访问各个块的接口；每个协议单元维护自身的状态，所述自身的状态仅与协议单元自身对应的元服务相关，而与服务容器的状态无关，协议单元根据自身的状态操作报文的内容来完成业务，对于需要协议单元间进行交互的情况，交互信息体现在报文中的控制部分。

4.根据权利要求2或3所述的一种支持服务定制与扩展的网络节点结构实现方法，其特征是具体步骤如下：

第1步：服务容器安装

服务容器安装在网络节点上，服务容器的设置包括运行时需要的文件和网络应用开发时使用的头文件、库文件；

第2步：部署协议单元

根据网络节点的需要，在服务容器中部署提供相应元服务的协议单元，通过提供协议单元的二进制文件和增加的服务说明，协议单元的二进制文件由服务容器加载进入内存运行，完成元服务的部署及维护；

第3步：接收网络应用的网络服务请求

网络应用将自己对网络服务的需求以XML形式提交给服务容器，服务容器的服务请求解析模块对这些网络请求进行分析并生成对应的服务实例，然后向网络应用返回这个服务实例的访问点；

第4步：网络应用使用服务容器提供的服务

网络应用得到服务容器返回的访问点后，通过这个访问点使用网络服务，网络应用将自身的数据通过访问点提供的接口交给服务容器，由服务容器组织协议单元对数据按之前定制的服务要求进行处理；同时网络应用通过用户数据接口从访问点获得其它网络节点发送到本节点的数据；

第5步：网络应用撤销网络服务请求

当网络应用不再需要已请求的网络服务时，通过访问点向服务容器提出撤销对应的服务实例，以节省资源，服务容器收到撤销的命令后，删除服务实例，并回收对应的访问点；

第3步至第5步为网络应用使用网络服务的一个周期，网络应用撤销网络服务后，如需使用同样的定制服务，需要重新请求服务容器才能继续使用网络服务。

Images