一种Docker容器主动负载均衡装置及方法与流程

本发明关于互联网技术领域，特别是涉及一种Docker容器主动负载均衡装置及方法。

背景技术：

Docker是一个开源的应用容器引擎，单实例运行Docker容器无法满足生产需要，行业内一般会采用Docker集群的模式对外提供服务，目前较多采用开源容器集群管理的系统如kubernetes、mesos、swarm等并结合基础网络解决方案如flannel、weave、pipework等，解决Docker集群面临问题，但Docker容器集群的负载均衡一直未能有完美的解决方案。

Docker容器发现目标是将隐藏在Docker容器内部的服务展现出来，减少或消除Docker容器之间通信壁垒。

Docker容器集群负载均衡目的是通过Docker容器发现将运行正常的容器统一通过负载均衡器转发，调用者对负载均衡器后端的容器透明无感知。一种Docker容器主动负载均衡目的是当Docker容器启动成功时应用名称、Docker容器IP地址、应用端口等信息自动推送，并将Docker容器实例挂载到负载均衡器，从而使得该Docker容器实例提供服务能力，全程不需要人工干预。调用者在可以完全不用理会后端Docker容器运行细节包括Docker容器个数、ip及端口，还包括是否是在物理机还是虚拟机下运行，只要有一个正常运行的容器，便可对外提供服务，对用户完全透明。 同时对于异常的服务，整个系统要能及时响应处理，将异常Docker实例从负载均衡器列表剔出。

目前，常见的一种Docker集群的负载均衡方案如kubernetes提供有三种模式的负载均衡：1、使用宿主机IP+PORT的方式，这种方式需要将宿主机的IP暴露给调用者，特别是当宿主机宕机后，还需要调用者切换到其他宿主机；2、使用原生自带的Service的方式并以private IP对外提供服务，这种方式需要调用者必须也在kubernetes集群内部，否则privateIP无法访问；3、使用GCE、AWS等IaaS环境下专用负载均衡，这种方式大多数企业都不具备，所有这些都不能满足生产对高可用的需要。

显而易见地，基于常见的Docker集群负载均衡方案往往依赖于集群管理系统，集群管理系统的变化或升级会导致原有方法的失效；或存在多次时延性能较低，不仅监控Docker容器的启动、停止变化等信息，还要将信息同步刷新负载均衡器；或由于采用专用负载均衡器，对学习、维护成本要求较高，不适宜技术沉淀，增加企业成本；或当服务运行多种环境下如Docker环境、vmware、kvm或独立运行在宿主机环境时，无法满足异构环境的需要。

技术实现要素：

为克服上述现有技术存在的不足，本发明之目的在于提供一种Docker容器主动负载均衡装置及方法，以实现实时主动发现与注册机制，并采用通用的负载均衡器，为Docker容器集群提供服务，保证对应用无侵入，方便系统进行容器化改造。

为达上述及其它目的，本发明提出一种Docker容器主动负载均衡装置，包括：

镜像转换模块，用于提供包含应用管理器的Docker基础镜像并将待执行应用转换为Docker镜像；

应用管理器，用于启动该Docker镜像，并根据预设应用信息，解析并执行该待执行应用的启动命令，并发送注册请求，将该应用注册到分布式协调服务器；

分布式协调服务器，用于部署分布式协调服务；

探测器，用于对该分布式协调服务器上的应用变化情况进行监听，将应用变化情况发送至负载均衡代理器；

负载均衡代理器，将所述应用变化情况根据配置模版转换一定格式的配置数据并执行，并配置到通用负载均衡器；

通用负载均衡器，用于部署通用负载均衡服务。

进一步地，该镜像转换模块包括：

基础镜像， 用于预先存放该应用管理器与待执行应用需要的基础环境构建的Docker镜像，并将此镜像作为待执行应用的基础镜像，并存放在镜像仓库；

命令接收模块，用于接收该待执行应用的标识信息；

镜像构建模块，通过Dockerfile构建待执行应用镜像，并上传至镜像仓库。

进一步地，该应用管理器包括：

参数解析模块，用于解析预设的应用信息；

命令执行模块，用于接收该参数解析模块解析出的应用执行命令，执行该命令并获取命令执行结果，若执行结果若正常，则调用应用注册模块；

应用注册模块，用于获取该参数解析模块解析出的数据以及获取待执行应用的状态信息，并与该分布式协调服务器建立临时会话链接，将该应用的状态详情注册到该分布式协调服务器；

健康检查模块，用于根据预设的健康检查命令轮询应用的健康情况，并将结果通知该应用注册模块。

进一步地，当该Docker容器通过该应用注册模块注册到该分布式协调服务器时，判断该分布式协调服务器目录有无该应用相对应的目录，若无，则在分布式协调服务器创建新的目录并同时在该目录创建一个新的节点。

进一步地，该探测器包括：

监听模块，用于对在该分布式协调服务器上的应用变化情况进行监听，若应用对应的Docker容器实例状态发生变化则触发第一发送模块；

第一发送模块，用于将应用变化情况发送至负载均衡代理器。

进一步地，该负载均衡代理器包括：

第一接收模块，与该第一发送模块进行连接并维持心跳，该第一接收模块接收该第一发送模块发来的指令，并调用数据解析模块；

数据解析模块，根据此时的配置模版模块的格式解析该指令，并传入第二命令执行模块；

配置模版模块，其模版数据根据负载均衡代理器所代理的负载均衡器不同；

第二命令执行模块，将数据写入该通用负载均衡器配置文件目录，执行该通用负载均衡器的重启命令。

为达到上述目的，本发明还提供一种Docker容器主动负载均衡方法，包括如下步骤：

步骤一，接收待执行应用文件，预设待执行应用详情；

步骤二，将所述待执行应用文件转换为Docker镜像；

步骤三，执行所述Docker镜像中应用启动命令；

步骤四，发送注册请求，将该应用注册到分布式协调服务器；

步骤五，从分布式协调服务器中获取所述注册信息，获取应用实例对应容器的变化数据，并将该数据进行解析，通过配置模版，更新配置文件到通用负载均衡器。

进一步地，步骤五进一步包括：

监听应用在分布式协调器的目录节点，并将目录节点的变化信息发送到负载均衡代理器；

根据配置模版将变化信息同步到通用负载均衡器。

进一步地，于步骤二中，将该待执行应用文件的标识信息按照规范写入Dockerfile，将待执行应用基础镜像与待执行应用通过Dockerfile构建待执行应用镜像。

进一步地，于步骤四中，该待执行应用的Docker容器与该分布式协调服务器维持临时会话，当应用异常时，立即断开与该分布式协调服务器的链接，并自动退出。

与现有技术相比，本发明一种Docker容器主动负载均衡装置及方法，通过应用管理器向分布式协调服务器发起连接并进行注册应用容器信息，并对应用容器健康信息实时监控，并主动同步反馈到分布式协调服务器，利用探测器根据分布式协调服务器的信息主动更新到负载均衡器，成功的将Docker容器挂载到负载均衡器，充分利用通用负载均衡器成熟的生产和运维经验，对于传统应用Docker容器化改造，有效地降低改造成本，本发明由容器主动向负载均衡器发起连接并进行注册，利用成熟稳定的负载均衡器，该过程无需预先配置均衡配置文件且不需要重新启动负载均衡器，自动实现负载均衡，克服目前的容器中负载均衡方法难以适应云计算系统中用于提供后端服务的、动态变化的容器集群的问题。

附图说明

图1为本发明第一实施例之一种Docker容器主动负载均衡装置的系统架构图；

图2为本发明第二实施例之一种Docker容器主动负载均衡装置的系统架构图；

图3为本发明第三实施例之一种Docker容器主动负载均衡方法的步骤流程图；

图4为本发明具体实施例提供的一种Docker容器主动负载均衡方法的流程图。

具体实施方式

以下通过特定的具体实例并结合附图说明本发明的实施方式，本领域技术人员可由本说明书所揭示的内容轻易地了解本发明的其它优点与功效。本发明亦可通过其它不同的具体实例加以施行或应用，本说明书中的各项细节亦可基于不同观点与应用，在不背离本发明的精神下进行各种修饰与变更。

图1为本发明第一实施例之一种Docker容器主动负载均衡装置的系统架构图。如图1所示，本发明一种Docker容器主动负载均衡装置，包括：镜像转换模块101、应用管理器102、分布式协调服务器103、探测器104、负载均衡代理器105以及通用负载均衡器106。

镜像转换模块101，用于提供包含应用管理器的Docker基础镜像并将待执行应用转换为Docker镜像。

具体地说，镜像转换模块101为一个部署成功的Docker环境，其包括基础镜像301、命令接收模块302以及镜像构建模块303，在该模块已预先存放了应用管理器与待执行应用需要的基础环境构建的Docker镜像，并将此镜像作为待执行应用的基础镜像301，同时也存放在镜像仓库。使用ftp、tftp、scp、wget等方式将待执行应用将存放到镜像转换装置相应的目录。命令接收模块302接收用户输入将待执行应用的标识信息，该待执行应用的标识信息包括应用名、应用启动、停止命令、端口、应用附加信息以及健康检查命令等信息，并解析与本地预存Dockerfile模版，形成新的Dockerfile，镜像构建模块303通过Dockerfile构建待执行应用镜像，并上传至镜像仓库，此时该应用镜像至少包括了应用管理器、待执行应用以及相应的参数。

应用管理器102，用于启动该Docker镜像，并根据预设应用信息，解析出待执行应用的启动命令，并执行该命令，并发送注册请求，将该应用注册到分布式协调服务器。

具体地，应用管理器102包括参数解析模块311、命令执行模块312、应用注册模块313、健康检查模块314。其中参数解析模块311负责解析预设的应用信息，该预设的应用信息包括：应用名、应用启动、停止命令、端口、应用附加信息等，将应用执行命令包括应用启动命令、应用停止命令传递给命令执行模块312；命令执行模块312，用于接收参数解析模块311解析出的应用执行命令，执行该命令并获取命令执行结果，若执行结果若正常，则调用应用注册模块313；应用注册模块313获取参数解析模块311解析出的数据以及获取待执行应用的状态信息，并与分布式协调服务器103建立临时会话链接，将该应用的状态详情：容器状态信息、容器IP、端口、应用名、应用附加信息注册到分布式协调服务器103，当发现应用异常比如宕机等现象，自动断开与分布式协调服务器103的链接。其中，当所述Docker应用启动时，所述参数解析模块312解析出所代理的应用的预设信息，调用命令执行模块312执行应用启动命令，并由应用注册模块313通知所述分布式协调服务器103，在所述文件目录下创建与所述待执行应用对应的文件夹。每当一个执行应用的Docker容器启动成功后，应用注册模块313就会将应用信息注册到分布式协调服务器103对应应用下的文件夹作为应用节点实例。

详细地，当Docker容器通过应用注册模块313注册到分布式协调服务器103时，判断分布式协调服务器103目录有无该应用相对应的目录，若无，则在分布式协调服务器103创建新的目录并同时在该目录创建一个新的节点，容器的IP和应用端口即是该节点的名称。当该应用有新的Docker实例产生，新的Docker实例都将注册在该目录下。当该应用的某个Docker实例宕机，则应用注册模块313自动断开与分布式协调服务器103的连接，同时分布式协调服务器103删除该Docker实例的注册信息。

健康检查模块314主要并根据预设的健康检查命令轮询应用的健康情况，并将结果通知应用注册模块313。健康检查模块314主要检查是否存在失效容器，失效容器可以是指不能提供正常服务的容器。例如，当健康检查模块314检测容器发生了异常如容器与健康检查模块314不能健康心跳、容器进程意外停止等现象，即该容器不能提供服务，此时可以认为该容器为失效容器。可选的，对于任意一个容器，可以监测该容器与健康检查模块314的通信连接是否断开，若健康检查模块314监测到该容器为失效容器。健康检查模块314通知应用注册模块313将自动与分布式协调服务器103断开链接，从而使分布式协调服务器103将该失效容器节点删除。

分布式协调服务器103，用于部署分布式协调服务。在本发明具体实施例中，分布式协调服务器103可以有一个或多个，当有多个分布式协调服务器103时，该多个分布式协调服务器103用于形成分布式协调服务组，并且可以从该多个分布式协调服务器103中选出一个leader(领导者)，其中，分布式协调服务器103用于部署分布式协调服务。本实施例中部署zookeeper作为分布式协调服务器，zookeeper是一个开源的分布式协调服务器。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等等。特别注意的是当zookeeper目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个功能是zookeeper对于应用最重要的特性，通过这个特性可以实现的功能包括配置的集中管理，集群管理，分布式锁等等。此处，主要使用了zookeeper中的配置维护和分布式同步这两项功能，其中，在所述分布式协调服务器103中维护一个文件目录，该文件目录中存在与所述多个应用分别对应的文件夹。即，该文件目录下存在多个文件夹，每个文件夹对应一个应用，每个文件夹下至少有一个节点，每个节点对应一个Docker容器实例。从而可以通过zookeeper的文件夹和节点来管理应用以及应用的Docker实例，就可以实现对Docker容器状态变化管理，即实现对Docker容器的发现。

例如，预设/apps/catalog为所有应用的父目录，若预设信息中应用名为helloworld，端口为8080，该应用对应一个Docker实例，且该容器IP为172.17.0.2，则该应用对应zookeeper的目录为/apps/catalog/helloworld，该Docker实例对应的zookeeper节点为/apps/catalog/helloworld/172.17.0.2：8080，若该应用又新增一个Docker实例且Docker容器IP为172.17.0.3，则该应用zookeeper节点目录为/apps/catalog/helloworld/172.17.0.2：8080和/apps/catalog/helloworld/172.17.0.3：8080。若所述IP为172.17.0.3的Docker容器宕机，则该应用对应的节点变为/apps/catalog/helloworld/172.17.0.2：8080。借助于zookeeper的文件目录和节点与应用和Docker实例的对应关系，可以实现一个应用对应一个目录，一个Docker容器对应一个目录节点的对应关系。

探测器104，用于监控分布式协调服务器103中对应的所有应用文件夹。该文件夹的文件夹名称对应应用名称，每一个应用唯一对应一个以应用名为文件夹名称的文件夹。探测器104包括监听模块331以及第一发送模块，在本具体实施例中，在启动待执行应用的Docker实例后，可以将该Docker实例详情注册到该分布式协调服务器103，监听模块331检测到应用目录/apps/catalog发生了变化，并读取应用目录/apps/catalog的节点详情，由第一发送模块332发送相应的指令通知负载均衡代理器105新增一个应用实例信息，对通用负载均衡器106更新配置。可选地，当待执行应用的其中一个Docker实例停止或宕机，健康检查模块314检测到该实例发生异常，通知应用注册模块313断开与分布式协调服务器103的链接，分布式协调服务器103删掉此目录节点信息，此时监听模块331立即检测到应用目录/apps/catalog目录发生了变化，通知负载均衡代理器105删除一个，对通用负载均衡器106更新配置。

负载均衡代理器105，用于通过配置模版，更新配置文件到通用负载均衡器106。

具体地，负载均衡代理器105包括第一接收模块341、数据解析模块342、配置模版模块343、第二命令执行模块344。负载均衡代理器105和通用负载均衡器部署106在同一服务器。第一接收模块341通过TCP协议与第一发送模块332进行连接并维持心跳，第一接收模块341接收第一发送模块332发来的指令，并调用数据解析模块342。数据解析模块342根据此时的配置模版模块343的格式解析该指令，配置模版模块343中模版数据根据负载均衡代理器105所代理的负载均衡器不同，模版数据各有不同，比如nginx适用的配置与lvs、keepalived适用的配置各不相同，数据解析模块342按模版数据成功将指令解析后，放入临时内存区域，调用第二命令执行模块344。第二命令执行模块344预设通用负载均衡器106配置文件路径、启动、停止、重启命令并赋予执行通用负载均衡器106控制权限，当数据解析模块342将解析出的数据传入第二命令执行模块344后，第二命令执行模块344读取上述临时内存区域将数据写入通用负载均衡器106配置文件目录，执行通用负载均衡器106的重启命令。

通用负载均衡器106，用于部署通用负载均衡服务。在本实施例中，通用负载均衡器106可以位于独立的服务器中，也可以位于由若干服务器构成的服务器集群中。比如nginx和lvs是开源的软负载均衡器，目前行业已积累较多的生产经验，对于企业的研发、运维及学习成本大大降低。nginx与lvs不同之处，lvs在处理四层流量时有显著的性能表现但对网络要求比较高，nginx常用于七层负载均衡，对网络环境要求较低。由于通用负载均衡器106是本领域技术人员熟悉的，在此不再赘述。

在本发明中，应用管理器与待执行应用也可以运行在非Docker容器环境，或在容器环境下一起实现应用集群的负载均衡。如图2所示为本发明第二实施例之一种Docker容器主动负载均衡的装置的系统架构图，其中，应用管理器203预先设置应用信息：应用名、应用启动、停止命令、端口、应用附加信息等，应用管理器203启动后，由参数解析模块解析应用详情，并启动待执行应用204，当待执行应用204启动成功后，由应用管理器203将应用实例的状态信息、宿主机IP、端口、应用名、应用附加信息注册到分布式协调服务器205。不同的是：1、应用实例由容器IP变成宿主机IP，2、同一个宿主机运行的应用实例端口不能相同，之后各模块的处理过程与第一实施例基本一致，不再赘述。

图3为本发明第三实施例之一种Docker容器主动负载均衡方法的步骤流程图。如图3所示，本发明一种Docker容器主动负载均衡方法，包括如下步骤：

步骤301，接收待执行应用文件，预设待执行应用详情。其中所述待执行应用详情包括应用启动命令、停止命令、应用名称，版本号，应用附加信息（TCP/HTTP），以及应用端口信息。

步骤302，将所述待执行应用文件转换为Docker镜像。具体地，将待执行应用文件的标识信息，例如应用名称、应用启动命令、停止命令、端口、应用附加信息以及健康检查命令等按照规范写入Dockerfile，将待执行应用基础镜像与待执行应用通过Dockerfile构建待执行应用镜像，即Docker镜像。

步骤303，执行所述Docker镜像中应用启动命令。也就是说，当待执行应用已成功构建为Docker镜像时，启动该镜像，并根据预设应用信息，解析出待执行应用的启动命令，并执行该命令。

步骤304，发送注册请求，将该应用注册到分布式协调服务器。所述注册请求中携带有所述Docker容器中应用信息的容器IP、应用端口信息、应用名称、应用附加信息等。在本发明具体实施例中，此时分布式协调服务器创建一个以应用名为名称的目录，并在该目录下创建一节点，其中该节点的名称为容器IP和端口，如172.17.0.2:8080，其他信息如应用附加信息存储在该节点内。待执行应用的Docker容器与分布式协调服务器维持临时的session会话，当应用异常时，立即断开与分布式协调服务器的链接，并自动退出。由于与分布式协调服务采用临时的session会话，该临时会话一旦断开，分布式协调服务器并即刻删除该节点所有信息。

步骤305，从分布式协调服务器中获取所述注册信息，即应用实例对应容器的变化数据 ，并将该数据进行解析，通过配置模版，更新配置文件到负载均衡器。具体地，步骤305进一步包括：

步骤S1，监听应用在分布式协调器的目录节点，并将节点的变化信息发送到负载均衡代理器。根据上述步骤S304得知，新增应用已成功在分布式协调服务器注册为一个目录，主动读取该目录下的节点信息，一旦检测该目录下有新增节点注册，发送指令给下游模块即负载均衡代理器，所述指令携带目录名（也即是应用名），该目录下所有节点名称（也即是节点实例地址）及附加信息；

步骤S2，根据配置模版将变化信息同步到负载均衡器，如nginx、lvs。根据上述步骤S1得知，负载均衡器代理器接收步骤S1发送的指令包括了应用下所有节点信息，则负载均衡代理器根据配置模版相关参数即转化为负载均衡器识别的参数，并写入相应的配置文件，其中负载均衡代理器应预设负载均衡器配置文件路径、启动、停止、重启命令。在本发明具体实施例中，所述配置模版根据选用的负载均衡器而各有差别。

图4为本发明具体实施例提供的一种Docker容器主动负载均衡方法的流程图，如图4所示，该方法可以包括：

步骤S401，预设应用信息，将待执行应用构建为一个新的镜像。具体地，将待执行应用的标识信息：应用名、应用启动、停止命令、端口、应用附加信息以及健康检查命令按照规范写入Dockerfile，将待执行应用基础镜像与待执行应用通过Dockerfile构建待执行应用镜像。

步骤S402，在分布式协调服务器中部署分布式协调服务器,如zookeeper。分布式协调服务器可以是单节点或集群模式。特别地，当分布式协调服务器一旦出现诸如目录、子节点、数据等变化，可以主动通知监听客户端，通过这个特性可以实现当应用实例节点发生变化可立即通知下游模块进行及时处理。

步骤S403，通过上述步骤S401中所述，待执行应用已成功构建为Docker镜像，启动该镜像，并根据预设应用信息，解析出待执行应用的启动命令，并执行该命令，然后根据预设应用健康检查语句定期检查应用健康度。

步骤S404，当待执行应用成功启动后，将该应用的状态详情包括：容器状态信息、容器IP、端口、应用名、应用附加信息注册到上述步骤S402已经部署成功的分布式协调服务器，此时分布式协调服务器创建一个以应用名为名称的目录，并在该目录下创建一节点，其中该节点的名称为容器IP和端口，如172.17.0.2:8080，其他信息如应用附加信息存储在该节点内。待执行应用的Docker容器与分布式协调服务器维持临时的session会话，当应用异常时，立即断开与分布式协调服务器的链接，并自动退出。由于与分布式协调服务采用临时的session会话，该临时会话一旦断开，分布式协调服务器并即刻删除该节点所有信息。

步骤S405，在通用负载均衡器部署负载均衡服务如nginx、lvs。负载均衡器与各个节点、各个节点容器网络保证互联互通，基于容器互通的网络方案可以采用端口映射、直接路径或覆盖网络的方式，所述网络方案是本领域技术人员熟悉的，在此不再赘述。

步骤S406，监听应用在分布式协调器的目录节点，并将节点的变化信息发送到负载均衡代理器。根据上述步骤S404得知，新增应用已成功在分布式协调服务器注册为一个目录，主动读取该目录下的节点信息，一旦检测该目录下有新增节点注册，发送指令给下游模块即负载均衡代理器，所述指令携带目录名（也即是应用名），该目录下所有节点名称（也即是节点实例地址）及附加信息。

步骤S407，根据配置模版将变化信息同步到负载均衡器如nginx、lvs。根据上述步骤S406得知，负载均衡器代理器接收步骤S406发送的指令包括了应用下所有节点信息，则负载均衡代理器根据配置模版相关参数即转化为负载均衡器识别的参数，并写入相应的配置文件。其中负载均衡代理器应预设负载均衡器配置文件路径、启动、停止、重启命令。

上述方法使应用在Docker环境下的运行情况时刻反馈到负载均衡系统上，通过采用了通用的负载均衡器和主动注册的机制，从而将应用调用者从多变、复杂Docker容器地址转换为访问固定的负载均衡器地址，全程自动发现、自动注册，对调用者无感知，而且应用管理器同时也可以与待执行应用在宿主机或虚拟机环境下同样适用。

相对与上述实施例，进一步地，本实施例中S401中在该装置已预先将程序管理器与待执行应用需要的基础环境构建为新的Docker镜像作为待执行应用的基础镜像步骤之前还包括：从镜像仓库中获取待执行应用需要的基础环境。具体地，镜像仓库用于存储镜像文件，包括待执行应用需要的基础环境、待执行应用的基础镜像、待执行应用镜像，新构建镜像统一存储到镜像仓库。本实施例中，镜像转换装置、各节点与镜像仓库建立通讯连接。

综上所述，本发明一种Docker容器主动负载均衡装置及方法，利用应用管理器主动将容器变化信息注册，同时利用探测器与分布式协调服务器采用临时会话机制，无需通过心跳方式实时对分布式协调服务器进行监听，一旦容器发现变化，通过利用负载均衡代理器将所述容器的变化信息写入通用负载均衡器，本发明可适用于应用容器化改造，对现有应用无约束和限制；能及时监听容器变化情况而不需要采用心跳机制，从而避免了心跳造成的超时问题；选用通用工业化软负载均衡器，对学习、使用、运维的成本要求较低，节省企业的研发和运维成本，本发明实施例中还阐述了在非容器环境下，通过应用管理器将待执行应用的变化情况同步到负载均衡器上，满足应用在异构环境运行的需要。

上述实施例仅例示性说明本发明的原理及其功效，而非用于限制本发明。任何本领域技术人员均可在不违背本发明的精神及范畴下，对上述实施例进行修饰与改变。因此，本发明的权利保护范围，应如权利要求书所列。