CN109032758B - 容器集群智能生命周期管理方法及装置 - Google Patents
容器集群智能生命周期管理方法及装置 Download PDFInfo
- Publication number
- CN109032758B CN109032758B CN201810856574.7A CN201810856574A CN109032758B CN 109032758 B CN109032758 B CN 109032758B CN 201810856574 A CN201810856574 A CN 201810856574A CN 109032758 B CN109032758 B CN 109032758B
- Authority
- CN
- China
- Prior art keywords
- container
- starting
- cpu
- pod
- resource
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/485—Task life-cycle, e.g. stopping, restarting, resuming execution
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
- Stored Programmes (AREA)
Abstract
本发明提供一种容器集群智能生命周期管理方法及装置。所述方法包括:接收用户提交的启动容器所需的相关参数,所述相关参数包括选择镜像、运行节点、资源限制、启动策略和启动顺序;根据模板生成yaml文件;根据所述启动策略启动Pod;按照所述启动顺序依次启动容器。本发明能够简化用户的操作和对任务的维护,便于容器生命周期管理。
Description
技术领域
本发明涉及计算机应用技术领域,尤其涉及一种容器集群智能生命周期管理方法及装置。
背景技术
随着Docker技术的发展和广泛流行,云原生应用和容器调度管理系统也成为IT领域大热的词汇。事实上,云原生应用的思想,在Docker技术火爆之前,已经由云计算技术的领导者和分布式系统架构的推广者广泛传播,例如云原生应用的12要素早在2011年就由Heroku的工程师提出了;只不过以虚拟机技术作为云原生应用的基础实施,由于虚拟机镜像大、镜像标准不统一以及打包流程和工具不统一,业界广泛接受的云原生应用标准,限制了云原生应用的流行。而Docker的出现正好解决了这些限制云原生应用构建、交付和运行的瓶颈,使得构建云原生应用成为了使用Docker的开发者自然而然的选择。
单机的Docker引擎和单一的容器镜像只能解决单一服务的打包和测试问题。而要运行生产级的企业级应用,就需要容器调度管理系统。在这里面,Docker技术就仿佛运送系统零件的集装箱,把云原生应用的各个标准化零件交付到各个企业的不同码头,而容器调度管理系统就是企业应用的运行车间,把不同的零件组装、运行、维护起来。
现有的容器调度管理系统存在以下缺陷:
同一个Pod的多个容器定义中没有优先级,启动顺序不能保证,需要应用自己通过重试机制解决;kubernetes的Scheduler服务(kube-scheduler进程)负责实现Pod的调度,整个调度过程通过执行一系列的算法最终为每个Pod计算出一个最佳的目标节点,这一过程是自动完成的,无法知道Pod最终会被调度到哪个节点上;运行Pod中的服务不能指定是一次性服务还是长服务;运行Pod的时候,如果指定执行节点的资源不能满足Pod的运行,提交后的Pod是不会运行的,同时Pod中的容器也不会运行,或者不能全部运行。
发明内容
本发明提供的容器集群智能生命周期管理方法及装置,能够简化用户的操作和对任务的维护,便于容器生命周期管理。
第一方面,本发明提供一种容器集群智能生命周期管理方法,包括:
接收用户提交的启动容器所需的相关参数,所述相关参数包括选择镜像、运行节点、资源限制、启动策略和启动顺序;
根据模板生成yaml文件;
根据所述启动策略启动Pod;
按照所述启动顺序依次启动容器。
可选地,在所述接收用户提交的启动容器所需的相关参数之后,所述方法还包括:
对节点进行前处理,使得节点的标签和yaml文件中的nodeSelector属性相匹配。
可选地,所述根据所述启动策略启动Pod包括:判断所述资源限制是否超出集群可用资源,若不超出,则根据所述启动策略启动Pod;否则不启动Pod。
可选地,所述资源限制包括CPU和RAM资源的限制;
所述方法还包括:
当容器运行在节点上时,监测容器消耗的CPU和RAM资源,当容器消耗的RAM资源超出RAM资源的限制时,结束所述容器;当容器消耗的CPU资源超出CPU资源的限制时,将所述容器作为CPU节流的候选者。
可选地,所述启动策略包括重启策略,所述重启策略包括以下三种:容器失效时即重启;容器终止运行且退出码不为0时重启;不重启。
第二方面,本发明提供一种容器集群智能生命周期管理装置,包括:
接收单元,用于接收用户提交的启动容器所需的相关参数,所述相关参数包括选择镜像、运行节点、资源限制、启动策略和启动顺序;
生成单元,用于根据模板生成yaml文件;
第一启动单元,用于根据所述启动策略启动Pod;
第二启动单元,用于按照所述启动顺序依次启动容器。
可选地,所述装置还包括:
前处理单元,用于在所述接收单元接收用户提交的启动容器所需的相关参数之后,对节点进行前处理,使得节点的标签和yaml文件中的nodeSelector属性相匹配。
可选地,所述第一启动单元,用于判断所述资源限制是否超出集群可用资源,若不超出,则根据所述启动策略启动Pod;否则不启动Pod。
可选地,所述资源限制包括CPU和RAM资源的限制;
所述装置还包括:
监测单元,用于当容器运行在节点上时,监测容器消耗的CPU和RAM资源;
处理单元,用于当容器消耗的RAM资源超出RAM资源的限制时,结束所述容器;当容器消耗的CPU资源超出CPU资源的限制时,将所述容器作为CPU节流的候选者。
可选地,所述启动策略包括重启策略,所述重启策略包括以下三种:容器失效时即重启;容器终止运行且退出码不为0时重启;不重启。
本发明实施例提供的容器集群智能生命周期管理方法及装置,为启动容器提供相关提交参数的封装,达到用户启动提交一个启动容器的任务时,只需要填写相应参数就可以达到预期的目的,把一些在后台的操作拿到前台页面,并通过自动化来代替人工,让启动维护Pod变得简单。指定容器的启动顺序,指定容器的运行节点和资源,能够简化用户的操作和对任务的维护,便于容器生命周期管理。
附图说明
图1为本发明一实施例容器集群智能生命周期管理方法的流程图;
图2为本发明一实施例容器集群智能生命周期管理装置的结构示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
首先对本发明实施例涉及到的相关术语进行介绍。
Docker:一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上。
Kubernetes:Google开源的容器集群管理系统,其提供应用部署、维护、扩展机制等功能,利用Kubernetes能方便地管理跨机器运行容器化的应用。主要实现语言为Go语言。
Node:Kubernetes中的一个工作机器,可以是物理机或虚拟机。依据角色不同分类主控节点(Master)与从属节点(Minion)。其中Master提供调试与控制功能,负责整个集群的管理工作,而Minion则是集群的工作节点。
Pod:Kubernetes的基本操作单元,是最小的可创建、调试和管理的部署单元。把相关的一个或多个容器构成一个Pod,通常Pod里的容器运行相同的应用。Pod包含的容器运行在同一个Minion(Host)上,作业一个统一管理单元,共享相同的volumes和networknamespace/IP和Port空间。
Kubelet:主要工作是管理Pod和容器的生命周期,其包括Docker Client、RootDirectory、Pod Workers、Etcd Client、Cadvisor Client以及Health Checker组件。
Replication Controller:Kubernete的副本控制器,确保任何时候Kubernetes集群中有指定数量的Pod副本(replicas)在运行,如果少于指定数量的Pod副本,ReplicationController会启动新的Container,反之会杀死多余的以保证数量不变。ReplicationController使用预先定义的Pod模板创建Pods。对于利用Pod模板创建的Pods,ReplicationController根据label selector来关联。
Service:Kubernetes的基本操作单元,是真实应用服务的抽象,每一个服务后面都有很多对应的容器来支持。Kubernetes用于定义一系列Pod逻辑关系与访问规则,服务的目标是为了隔绝前端与后端的耦合性。通过服务Proxy的port和服务selector决定服务请求传递给后端提供服务的容器,对外表现为一个单一访问接口,外部不需要了解后端如何运行。
本发明实施例提供一种容器集群智能生命周期管理方法,如图1所示,所述方法包括:
S11、接收用户提交的启动容器所需的相关参数,所述相关参数包括选择镜像、运行节点、资源限制、启动策略和启动顺序。
S12、根据模板生成yaml文件。
S12、根据所述启动策略启动Pod。
S12、按照所述启动顺序依次启动容器。
本发明实施例提供的容器集群智能生命周期管理方法,为启动容器提供相关提交参数的封装,达到用户启动提交一个启动容器的任务时,只需要填写相应参数就可以达到预期的目的,把一些在后台的操作拿到前台页面,并通过自动化来代替人工,让启动维护Pod变得简单。指定容器的启动顺序,指定容器的运行节点和资源,能够简化用户的操作和对任务的维护,便于容器生命周期管理。
下面对本发明实施例容器集群智能生命周期管理方法进行详细说明。
首先,填写指定节点,提交之后,需要对该节点做前处理,通过节点的标签(Label)和yaml文件中的nodeSelector属性相匹配,来达到目的。
可以通过kubectl label命令给目标节点打上一个特定的标签,下面是此命令的完整用法:
然后,在Pod的配置文件中加入nodeSelector定义:
运行kubectl create-f命令创建Pod,scheduler会将该Pod调度到拥有<label-key>=<label-value>标签的节点上去,如果给多个节点都定义了相同的标签,则scheduler将会根据调度算法从这组节点中挑选一个可用的节点进行Pod调度。需要注意的是,如果指定了节点的nodeSelector条件,且集群中不存在包含相应标签的节点时,即使还有其他可供调度的节点,这个Pod也最终会调度失败。
在本发明实施例中,进行了资源判断,如果填写的资源限制超出集群可用资源,不允许提交该Pod。
可以在yaml文件中为运行在Pod中的容器请求CPU和RAM资源,还可以设置CPU和RAM资源的限制。
请求CPU和RAM资源,在配置文件yaml里面包含resources:rquests字段。设置CPU和RAM限制包含resource:limits字段。如果节点上具有足够的CPU和RAM资源可用于所有容器要求的CPU和RAM总和,Kubernetes将把Pod调度在上面。同样当容器运行在节点上时,Kubernetes不允许容器消耗的CPU和RAM资源超出指定的容器的限制。如果容器超出它的RAM限制,它将结束。如果CPU超出限制,它将成为CPU节流的候选者。
在本发明实施例中,把要启动的容器放在管道里面,然后for循环按照指定顺序逐一创建这个Pod里面的容器。
本发明实施例使用参数定义Pod的启动方式,重启策略应用于Pod内的所有容器,由Pod所在节点上的Kubelet进程进行判断和重启操作。重启策略有以下三种:
本发明实施例还提供一种容器集群智能生命周期管理装置,如图2所示,所述装置包括:
接收单元11,用于接收用户提交的启动容器所需的相关参数,所述相关参数包括选择镜像、运行节点、资源限制、启动策略和启动顺序;
生成单元12,用于根据模板生成yaml文件;
第一启动单元13,用于根据所述启动策略启动Pod;
第二启动单元14,用于按照所述启动顺序依次启动容器。
本发明实施例提供的容器集群智能生命周期管理装置,为启动容器提供相关提交参数的封装,达到用户启动提交一个启动容器的任务时,只需要填写相应参数就可以达到预期的目的,把一些在后台的操作拿到前台页面,并通过自动化来代替人工,让启动维护Pod变得简单。指定容器的启动顺序,指定容器的运行节点和资源,能够简化用户的操作和对任务的维护,便于容器生命周期管理。
可选地,所述装置还包括:
前处理单元,用于在所述接收单元11接收用户提交的启动容器所需的相关参数之后,对节点进行前处理,使得节点的标签和yaml文件中的nodeSelector属性相匹配。
可选地,所述第一启动单元13,用于判断所述资源限制是否超出集群可用资源,若不超出,则根据所述启动策略启动Pod;否则不启动Pod。
可选地,所述资源限制包括CPU和RAM资源的限制;
所述装置还包括:
监测单元,用于当容器运行在节点上时,监测容器消耗的CPU和RAM资源;
处理单元,用于当容器消耗的RAM资源超出RAM资源的限制时,结束所述容器;当容器消耗的CPU资源超出CPU资源的限制时,将所述容器作为CPU节流的候选者。
可选地,所述启动策略包括重启策略,所述重启策略包括以下三种:容器失效时即重启;容器终止运行且退出码不为0时重启;不重启。
本实施例的装置,可以用于执行上述方法实施例的技术方案,其实现原理和技术效果类似,此处不再赘述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,是可以通过计算机程序来指令相关的硬件来完成,所述的程序可存储于一计算机可读取存储介质中,该程序在执行时,可包括如上述各方法的实施例的流程。其中,所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory,ROM)或随机存储记忆体(Random AccessMemory,RAM)等。
以上所述,仅为本发明的具体实施方式,但本发明的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本发明揭露的技术范围内,可轻易想到的变化或替换,都应涵盖在本发明的保护范围之内。因此,本发明的保护范围应该以权利要求的保护范围为准。
Claims (6)
1.一种容器集群智能生命周期管理方法,其特征在于,包括:
接收用户提交的启动容器所需的相关参数,所述相关参数包括选择镜像、运行节点、资源限制、启动策略和启动顺序;
根据模板生成yaml文件;
根据所述启动策略启动Pod;
按照所述启动顺序依次启动容器;
在所述接收用户提交的启动容器所需的相关参数之后,所述方法还包括:对节点进行前处理,使得节点的标签和yaml文件中的nodeSelector属性相匹配;
所述资源限制包括CPU和RAM资源的限制;所述方法还包括:
当容器运行在节点上时,监测容器消耗的CPU和RAM资源,当容器消耗的RAM资源超出RAM资源的限制时,结束所述容器;当容器消耗的CPU资源超出CPU资源的限制时,将所述容器作为CPU节流的候选者。
2.根据权利要求1所述的方法,其特征在于,所述根据所述启动策略启动Pod包括:判断所述资源限制是否超出集群可用资源,若不超出,则根据所述启动策略启动Pod;否则不启动Pod。
3.根据权利要求1至2中任一项所述的方法,其特征在于,所述启动策略包括重启策略,所述重启策略包括以下三种:容器失效时即重启;容器终止运行且退出码不为0时重启;不重启。
4.一种容器集群智能生命周期管理装置,其特征在于,包括:
接收单元,用于接收用户提交的启动容器所需的相关参数,所述相关参数包括选择镜像、运行节点、资源限制、启动策略和启动顺序;
生成单元,用于根据模板生成yaml文件;
第一启动单元,用于根据所述启动策略启动Pod;
第二启动单元,用于按照所述启动顺序依次启动容器;
所述装置还包括:前处理单元,用于在所述接收单元接收用户提交的启动容器所需的相关参数之后,对节点进行前处理,使得节点的标签和yaml文件中的nodeSelector属性相匹配;
所述资源限制包括CPU和RAM资源的限制;所述装置还包括:
监测单元,用于当容器运行在节点上时,监测容器消耗的CPU和RAM资源;
处理单元,用于当容器消耗的RAM资源超出RAM资源的限制时,结束所述容器;当容器消耗的CPU资源超出CPU资源的限制时,将所述容器作为CPU节流的候选者。
5.根据权利要求4所述的装置,其特征在于,所述第一启动单元,用于判断所述资源限制是否超出集群可用资源,若不超出,则根据所述启动策略启动Pod;否则不启动Pod。
6.根据权利要求4至5中任一项所述的装置,其特征在于,所述启动策略包括重启策略,所述重启策略包括以下三种:容器失效时即重启;容器终止运行且退出码不为0时重启;不重启。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810856574.7A CN109032758B (zh) | 2018-07-31 | 2018-07-31 | 容器集群智能生命周期管理方法及装置 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201810856574.7A CN109032758B (zh) | 2018-07-31 | 2018-07-31 | 容器集群智能生命周期管理方法及装置 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109032758A CN109032758A (zh) | 2018-12-18 |
CN109032758B true CN109032758B (zh) | 2021-07-13 |
Family
ID=64647092
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201810856574.7A Active CN109032758B (zh) | 2018-07-31 | 2018-07-31 | 容器集群智能生命周期管理方法及装置 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109032758B (zh) |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110175077A (zh) * | 2019-05-27 | 2019-08-27 | 浪潮云信息技术有限公司 | 一种基于命令管理容器资源的方法及系统 |
CN110784347A (zh) * | 2019-10-18 | 2020-02-11 | 北京浪潮数据技术有限公司 | 一种容器集群的节点管理方法、系统、设备及存储介质 |
EP4185949A4 (en) * | 2020-09-18 | 2024-03-27 | Zte Corp | CONTAINER GROUP MANAGEMENT METHOD AND ASSOCIATED SYSTEM |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107766060A (zh) * | 2017-10-31 | 2018-03-06 | 新华三云计算技术有限公司 | 应用配置部署方法及装置 |
CN108009004A (zh) * | 2017-12-01 | 2018-05-08 | 广东电网有限责任公司佛山供电局 | 基于Docker的业务应用可用度测量监控的实现方法 |
CN108052333A (zh) * | 2017-12-11 | 2018-05-18 | 北京紫优能源科技有限公司 | 一种电力调度集控系统标准化自动化部署方法及架构 |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8433559B2 (en) * | 2009-03-24 | 2013-04-30 | Microsoft Corporation | Text analysis using phrase definitions and containers |
-
2018
- 2018-07-31 CN CN201810856574.7A patent/CN109032758B/zh active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107766060A (zh) * | 2017-10-31 | 2018-03-06 | 新华三云计算技术有限公司 | 应用配置部署方法及装置 |
CN108009004A (zh) * | 2017-12-01 | 2018-05-08 | 广东电网有限责任公司佛山供电局 | 基于Docker的业务应用可用度测量监控的实现方法 |
CN108052333A (zh) * | 2017-12-11 | 2018-05-18 | 北京紫优能源科技有限公司 | 一种电力调度集控系统标准化自动化部署方法及架构 |
Also Published As
Publication number | Publication date |
---|---|
CN109032758A (zh) | 2018-12-18 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11487536B2 (en) | System for automating user-defined actions for applications executed using virtual machines in a guest system | |
US9851989B2 (en) | Methods and apparatus to manage virtual machines | |
US9811369B2 (en) | Method and system for physical computer system virtualization | |
CN110532098B (zh) | 提供gpu服务的方法及系统 | |
CN109032758B (zh) | 容器集群智能生命周期管理方法及装置 | |
CN106708740B (zh) | 脚本测试方法及装置 | |
CN108376100A (zh) | 基于安全的容器调度 | |
CN112368678A (zh) | 用于应用程序的虚拟机容器 | |
CN115617364A (zh) | Gpu虚拟化部署方法、系统、计算机设备和存储介质 | |
Harichane et al. | KubeSC‐RTP: Smart scheduler for Kubernetes platform on CPU‐GPU heterogeneous systems | |
US10338891B2 (en) | Migration between model elements of different types in a modeling environment | |
CN117076096A (zh) | 任务流程的执行方法、装置、计算机可读介质及电子设备 | |
CN114265595B (zh) | 一种基于智能合约的云原生应用开发与部署系统和方法 | |
US20220350596A1 (en) | Computing node allocation based on build process specifications in continuous integration environments | |
CN114816662A (zh) | 应用于Kubernetes的容器编排方法和系统 | |
Mironov | DevOps pipeline with Docker | |
CN110377397B (zh) | 基于虚机复制的存量应用快速部署扩容的方法 | |
US20240152371A1 (en) | Dynamic re-execution of parts of a containerized application pipeline | |
US20220067502A1 (en) | Creating deep learning models from kubernetes api objects | |
US20230168918A1 (en) | Managing data access by communication protocols in continuous integration environments | |
CN118093105A (zh) | 一种算法调度方法、装置、设备及存储介质 | |
US9594654B2 (en) | Generating and detecting hang scenarios in a partially populated simulation environment | |
KR101776286B1 (ko) | 서버 관리 방법 | |
CN114070764A (zh) | 网络功能虚拟化nfv测试方法、装置和系统 | |
CN117008925A (zh) | 应用部署管理方法、装置、设备及计算机存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
GR01 | Patent grant | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right | ||
TR01 | Transfer of patent right |
Effective date of registration: 20220727 Address after: 100089 building 36, courtyard 8, Dongbeiwang West Road, Haidian District, Beijing Patentee after: Dawning Information Industry (Beijing) Co.,Ltd. Patentee after: DAWNING INFORMATION INDUSTRY Co.,Ltd. Address before: 100193 No. 36 Building, No. 8 Hospital, Wangxi Road, Haidian District, Beijing Patentee before: Dawning Information Industry (Beijing) Co.,Ltd. |