本发明属于信息融合技术与公安信息化指挥调度系统、云计算、大数据等技术领域，涉及一种微服务技术架构与公安行业指挥调度系统的结构融合方式，用于指挥调度信息系统。
背景技术：
在企业互联网+发展下企业竞争加剧，个性化产品、市场需求快速多变、应用系统流量不可预期，这要求信息化系统具备移动化、敏捷创新、低成本的特点，越来越多业务系统选择将应用从线下向云上迁移。传统信息化应用系统云化改造会面临架构改造、复杂应用的部署和运维困难等问题。成熟的系统应用借助微服务框架和云中间件产品，可以降低单体应用架构改造的难度，并简化应用部署和运维复杂性，适应业务持续发展。
随着新需求的不断增加，传统的单体式应用系统变为大而复杂的架构体系，软件开发面临诸多发展壁垒；复杂耦合的单体式应用需求增量开发困难、且修改量与测试量庞大，按需扩展困难；系统体系的健壮性越来越差；所有模块运行在一个进程中，任何一个模块中的一个bug，比如内存泄露，将有可能弄垮整个进程。随着云计算、互联网公司大量开源轻量级运行技术、云化基础设施、标准化代码管理等日趋成熟，devops、持续交付等概念深入人心，为传统it系统的微服务云化扫清了技术和文化障碍。在实施传统单体应用向微服务转变后，可以借助云化基础设施、借鉴更好的开发框架、更合适的编程语言和开源部件、轻量级协议、轻量级运行时技术，一解上述单体应用和传统开发运维模式的困境。
技术实现要素：
本发明的目的在于针对目前烟囱式系统、资源独占导致资源利用率低下、配置项复杂易错、升级难度高、运维困难等技术壁垒，提供一种利用微服务架构的指挥调度系统，在接处警体系中应用微服务与docker容器技术实现了原有传统系统等功能提升，优化原有接处警系统的整体部署、应用功能绑定、所有客户端需现场配置等实施方式。
本发明的技术方案如下：
一种利用微服务架构的指挥调度系统，其特征在于包括：
(1)pod：若干相关容器的组合，pod包含的容器运行在同一host上，这些容器使用相同的网络命令空间、ip地址和端口，相互之间能通过localhost来发现和通信；
(2)rc：rc是用来管理pod的，每个rc由一个或多个pod组成；在rc被创建之后，系统将会保持rc中的可用pod的个数与创建rc时定义的pod个数一致，如果pod个数小于定义的个数，rc会启动新的pod，反之则会杀死多余的pod；
(3)label：label是用于区分pod、service、rc的key/value键值，对pod、service、rc可以有多个label，但是每个label的key只能对应value整个系统都是通过label进行关联，得到真正需要操作的目标；
(4)service：用来将浮动的资源与后端真实提供服务的容器进行关联，对外表现为一个单一的访问接口，外部不需要了解后端的规模与机制；当一个service资源被创建后，将会分配一个唯一的ip，这个ip将存在于service的整个生命资源，service一旦被创建，整个ip无法进行修改。
本发明充分引入微服务技术、docker容器技术，实现功能模块的升级与云化部署，可以便于应用系统与功能的迁移，实现虚拟化，并且利用沙箱机制，实现整体接处警系统内的多个应用服务数据通讯更加便利与快捷，为每个服务(功能模块)提供独立的生产环境，便于处于同一物理服务器中的多个服务进行内部相互访问与信息流转。
具体实施方式
kubernetes是google开源的容器集群管理系统，提供应用部署、维护、扩展机制等功能。本发明一种利用微服务架构的指挥调度系统，利用kubernetes管理跨集群运行微服务架构的docker容器化的应用。具体包括：
(1)pod：若干相关容器的组合，pod包含的容器运行在同一host上，这些容器使用相同的网络命令空间、ip地址和端口，相互之间能通过localhost来发现和通信。另外，这些容器还可共享一块存储卷空间。在k8s中创建，调度和管理的最小单位就是pod，而非容器，pod通过提供更高层次的抽象，提供了更加灵活的部署和管理模式；
一个pod由一个或多个容器组成，通常pod里的容器运行的相同的应用；
同一pod包含的容器运行在同一host上，作为统一管理单元：
同一pod共享着相同的volumes，network命名空间。
(2)rc(replicationcontroller)：rc是用来管理pod的，每个rc由一个或多个pod组成；在rc被创建之后，系统将会保持rc中的可用pod的个数与创建rc时定义的pod个数一致，如果pod个数小于定义的个数，rc会启动新的pod，反之则会杀死多余的pod。
rc通过定义的pod模板被创建，创建后对象叫做pods(也可以理解为rc)，可以在线修改pods的属性，以实现动态缩减、扩展pods的规模
rc通过label关联对应的pods，通过修改pods的label可以删除对应的pods在需要对pods中的容器进行更新时，rc采用一个一个替换原则来更新整个pods中的pod。
(3)label：label是用于区分pod、service、rc的key/value键值，对pod、service、rc可以有多个label，但是每个label的key只能对应value整个系统都是通过label进行关联，得到真正需要操作的目标。
(4)service：service也是k8s的最小操作单元，是真实应用服务的抽象；service通常用来将浮动的资源与后端真实提供服务的容器进行关联；service对外表现为一个单一的访问接口，外部不需要了解后端的规模与机制；service是定义在集群中一组运行pod集合的抽象资源，它提供了所有相同的功能。当一个service资源被创建后，将会分配一个唯一的ip(也叫做集群ip)，这个ip地址将存在于service的整个生命资源，service一旦被创建，整个ip无法进行修改。
pod可以通过service进行通信，并且所有的通信将会通过service自动负载均很到所有的pod中的容器。