王颖 邹一荣 吴家隐

摘  要：随着通信业务的快速发展，运营商早已着眼于建立以客户为核心，以取得高质量的客户忠诚度为目标的企业发展策略。本课题的研究基于OpenStack架构设计，并实现对容器化改造后的运营商业务系统的容器管理系统的搭建。本课题主要采用OpenStack架构，搭建Kubernetes集群，采用Docker技术实现容器化改造，从而满足运营商对突发访问量的业务需求。容器化是一种轻量级的虚拟化方案。该方案不需要修改业务系统核心，主要通过Linux内核的功能进行虚拟化，使所有容器在同一内核中运行。本文的容器化试点应用系统是广东联通手机营业厅，为广东联通客户提供查询、处理、营销等快速自助客户端软件。

关键词：运营商业务系统;OpenStack;Kubernetes;容器化;容器管理系统

中图分类号：TP393.09      文献标识码：A 文章编号：2096-4706（2019）20-0001-07

Abstract：With the rapid development of telecommunication business，operators have already begun to focus on establishing enterprise development strategies with customers as the core and high quality customer loyalty as the goal. The purpose of this research is to design and implement the container management system of the operators business system after container transformation based on OpenStack architecture. This topic mainly adopts OpenStack architecture，builds Kubernetes cluster，and adopts Docker technology to realize container transformation，so as to meet the business needs of operators for sudden traffic. Containerization is a lightweight virtualization scheme. This solution does not need to modify the business system core，mainly through the function of the Linux kernel to virtualize，so that all containers run in the same kernel. The container pilot application system in this paper is the mobile phone business hall of Guangdong Unicom，which provides fast self-service client software such as inquiry，processing and marketing for Guangdong Unicom customers.

Keywords：operator business system;Openstack;Kubernetes;containerization;container management system

0  引  言

本文的研究内容包括以下三个方面：第一，从实际情况出发，提出从三个方面對原运营商业务系统进行应用改造，以及测试改造后的应用是否适应容器化部署;第二，分析多种容器化技术的优缺点，结合实际的运营商业务系统，从不同方案中选择合理且高效的容器化部署方案;第三，根据容器化部署方案，设计相应的容器管理系统ECP系统。

确认容器化改造效果，并顺利进行容器化部署工作，为基于容器化改造后的运营商业务系统开发出一个功能完整的容器管理系统，经测试该管理系统具有有效性。最后进行了全文总结，并对未来的研究做出展望。

1  绪论

1.1  课题背景及研究意义

随着通信业务的迅速发展，运营商早已着眼于建立以客户为核心，以取得高质量的客户忠诚度为目标的企业发展策略。目前，中国电信业的竞争方向发生了巨大变化。从价格竞争到服务竞争，服务已悄然成为影响竞争格局的主导因素。渠道是企业与客户沟通、完成产品和服务交流、对业务贡献的重要载体。其为客户和竞争对手提供市场信息，为双方交易提供便利，有效缓解供需矛盾。它也提供了符合用户需求的产品和服务，向客户传递产品和服务信息，实现市场以及服务目标。与此同时，互联网业务规模以及突发式的访问量的激增也成为常态。

随着运营商的业务能力的开放和业务互联网化，某些业务的波峰波谷现象也更加突出。本课题的研究基于OpenStack架构设计，并实现对容器化改造后的运营商业务系统的容器管理系统。为进一步满足运营商对突发访问量的业务需求，本课题主要依据OpenStack架构，建立了Kubernetes集群，并利用Docker技术实现了容器化改造。该方案使企业增加拥有200万注册用户，并满足100到50万用户并发访问的实际需求。在此基础上，研究容器化技术在业务支撑系统中的可应用场景;评估试点容器化技术相关开源产品的特性和成熟度;评估试点容器化迁移的可能性;完成不同部署和资源调度管理方案的差异分析;研究容器化改造后系统运营、运行维护及安全管控的实际问题。

1.2  运营商业务系统发展现状

为了促进服务质量的提升，提高客户满意度和粘度，降低人工负荷压力，满足运维人员的日常经营需要，需要分析运营商的当前业务。运营商手机营业厅业务存在以下问题。

首先，现存的资源静态配置模式以单个应用为单位，因此无法实现跨应用的资源共享和动态调度，从而无法支撑应用快速扩容。也因此，应以天为单位来计算物理机的部署时间，以小时为单位来计算虚拟机的部署时间;其次，应用环境独立安装，无法自动扩展，中间件、数据库等运行环境需要分别部署，导致资源分配完毕后，仍无法快速使用;最后，资源独占，无法多应用共享。现有的静态配置模式应用环境需独立安装，无法自动扩展，应用及其依赖的操作系统、中间件、数据库等运行环境都是分别部署，这将导致资源分配好后，仍无法快速使用应用;最后，应用部署周期长，在资源充足且不考虑审批时间的前提下，目前从资源申请、应用申请、应用部署到生产环境（不含开发过程），这将需要一周的时间，如此效率根本无法满足快速启动业务的要求。带状态的应用无法自动加载和快速迭代，只能从现有的应用需要绑定内存和从数据库中获取状态信息，从而导致无法快速、自动注册到业务集群中，因此也无法自动进行业务分流，需手工配置，暂停业务后再上线。与此同时，现有的应用程序体系结构的任何更改都需要二次编译、集成、测试和部署整个应用程序，这将导致运营商业务系统的体积持续扩张，随之带来的影响是交付时间和反馈周期的延长，这无疑会在很大程度上影响业务上线速度。

1.3  本文研究思路及主要内容

本文主要研究目标是运营商业务系统容器化及其管理工作。因此，研究内容主要包括以下三个方面。

首先，分析现有的某运营商业务系统，为运营商业务系统的容器化提供技术支撑。本课题根据实际情况，提出从三个方面改造现有的运营商业务应用系统，使其适应容器化改造;其次，基于OpenStack架构构建Kubernetes集群方案，采用Docker技术对运营商业务系统进行容器化改造。该方案结合了OpenStack架构和Kubernetes集群，使得云计算平台机动性更好，同时高效利用了物理机、网络以及存储等资源。应用使用Docker技术，将其部署在Kubernetes集群上，充分提升了开发人员的开发效率，大幅度降低了运维人员的维护成本;最后，设计出一个基于容器化改造后的运营商业务系统的容器管理系统，对平台内部的容器实例开展管理工作。本课题设计的容器管理系统可以为现有运营商业务提供有效的编排服务，更加充分地利用容器资源，提高资源利用率。

OpenStack、Docker技术、云计算等均是近几年的新兴技术，相关技术仍处于不断的发展变化中。因此业界尚没有成熟的运营商级的网络部署案例可作参考。综上所述，本课题在实施的过程中仍面临一定的挑戰。

第一，从实际情况出发，提出从三个方面对原运营商业务系统进行应用改造，测试改造后的应用是否适应容器化部署;

第二，分析多种容器化技术的优缺点，结合实际的运营商业务系统，从不同方案中选择合理且高效的容器化部署方案;

第三，根据容器化部署方案，设计相应的容器管理系统ECP系统。本课题提出的ECP系统主要分为七个模块，分别对容器管理系统相关业务进行管理。

2  容器化改造及部署方案

2.1  应用的无状态改造

一般而言，状态分为三个过程，即分发、处理和存储。有状态服务是指在任何时候都可以备份服务实例的一部分数据。为实现数据持久化功能，在创建新的服务时，可以恢复备份数据。有状态服务不支持自动服务容量调节，即该服务仅拥有一个实例;而无状态服务是指服务运行的实例无需备份，这是为了在请求相同的情况下，任意实例对其响应结果是完全一致的。本文选择将应用改造为无状态，实现无状态后，集群的所有状态都可以聚集在一起，便于跨机房部署，实现跨机房的高可用性。无状态化后，实施容器化就会十分顺畅。

如果应用程序在PaaS平台上动态扩展，则需要对应用程序进行无状态化改造。以手机APP架构为例，Web层负责向用户呈现内容，APP层负责处理业务逻辑和数据库交互工作。Web层使用负载平衡进行请求分发，而APP层的Web层以多种方式调用。

因此，应用的无状态化改造需要分为Web层应用的无状态改造和APP层应用的无状态改造，如图1所示。

2.1.1  Web层应用的无状态改造

首先，Web层应用需要去Http Session，即不再使用传统的http会话作为会话保持的方案;其次，采用http与JSON相结合的方式作为客户端与Web端的交互手段;最后，使用缓存服务器为用户存储会话信息。改造后的结构如图2所示。

通过上述改造，现存的应用系统完全能够达成应用的状态数据与应用成功分离的目的，Web实例的启动和停止都不会导致用户会话数据的丢失。

2.1.2  APP层应用的无状态改造

APP层需要支持动态收缩，这不仅取决于APP层的无状态实现，还取决于从Web层到APP层的RPC调用模式。ZooKeeper保存应用实例的实时分布数据，平台监控应用实例的运行状态。当状态发生变化时，通知ZooKeeper修改应用实例的分布数据。Web层根据分组策略获取一组应用实例的分布信息，并根据该信息对调用组中的应用实例进行轮询。

2.2  配置中心化改造

在分布式环境中的大多数情况下，同一类型的服务将有许多实例部署在其上。待部署的实例利用某些固定的配置方式。为了高效运用及维护这些变化极少的配置方案，配置管理服务应运而生。绝大部分的服务实例配置问题都可以通过该服务得到便捷的管理。统一配置系统为应用系统提供配置获取服务。该应用程序不仅可以在启动时从统一配置系统获取相关配置，而且支持对感知运行状态下配置数据的变化的感知。随后，该配置系统将获得更改后的配置数据。

ADConf统一配置系统是一个用于管理持久配置的系统，具有简单、可靠、易于使用等优势。简单性是指整体结构十分简单，这就有效降低了错误概率。可靠性意味着应用程序应该在任何情况下都能使用。易用性是指客户端的接口十分简单，方便开发人员的理解和使用。本文提出配置中心化改造方案，ADConf总体架构图如图3所示。

ADConf作为配置中心，将统一配置系统的功能分为发布和订阅两部分。统一配置系统存储持久化数据，这些数据的变化频率很低，因此发布采用手工配置的形式，并通过统一配置系统的后台管理接口发布，订阅是统一配置系统的核心功能。订阅由统一配置系统客户端API执行。

統一配置系统服务端以MySQL与本地文件相结合的形式存放配置数据。发布数据时，先将数据写入数据库，然后写入本地文件;订阅数据时，不需要查询数据库，直接从本地文件获取数据即可，这样可以最大限度地减少数据库的压力。

统一配置系统服务端实际上是同一个集群，集群中的任何机器都连接到同一个MySQL数据库。同时，集群间的数据同步有两种方式：一是每台服务器定期去MySQL将数据转储到本地文件;二是一台服务器负责接收数据发布请求，当MySQL和本地文件同步数据完成后，将HTTP请求（通知）发送到其他几个服务器，待其他服务器收到通知后，将MySQL内刚刚更新的数据转储到本地文件。同时，每台服务器前端都需要配置相对应的Nginx来做流量控制。

2.3  日志中心化改造

互联网系统在运行和运营的过程中产生了大量的日志。因此，日志的处理能力是Internet应用系统必须具备的关键能力之一。处理系统产生的大量日志主要依靠采集日志和分析技术。Logstash是一个完全开源的分布式海量日志聚合系统，以其可靠性和高可用性受到用户的青睐。Logstash支持在系统中定制各类数据发送方。Logstash收集和分析日志，这些日志也可以存储和重用。Logstash支持系统日志、Web Server日志、错误日志和应用日志。同时Logstash还有一个用于搜索和显示所有日志的Web界面。

Kibana也是一个开源和免费的工具，用于总结、分析和搜索重要的数据日志，并提供方便用户使用的操作接口，也可用于Logstash和ElasticSearch的日志分析的Web界面。本文提出的日志中心化改造后架构如图4所示。

日志系统的具体工作流程：Logstash agent负责监控并过滤日志，过滤后的日志内容将被发送给Redis（此处的Redis只处理队列不做存储）;Logstash index收集日志并将其提供给全文搜索服务;ElasticSearch搜索用于自定义搜索;Kibana用于页面显示和自定义搜索。

2.4  容器化系统架构

当前运营商手机营业厅系统的总体架构包括业务展现层（SaaS）、能力运营层（OPaaS）、业务能力层（APaaS）、技术平台层（IPaaS）和基础设施层（IaaS）。以此为基础提出的容器化后的系统架构如图5所示。

每一个RC（代表一个受Replication Controller控制的集群，可以在RC的控制下完成这个集群的弹性伸缩）。接入层使用硬件防火墙对外。Nginx集群容器化后作为服务接入负载均衡，每个Nginx独立部署于一个Pod之上，不做扩缩容，出现问题手工维护;Redis等容器化后注册为缓存服务保存服务Session等信息;业务Web层容器化后以Pod形式部署，通过RC控制扩容、缩容;不同的Nginx对应不同组的Web集群。Web层弹性服务的发现由PAAS平台Service机制来完成，Nginx服务需要分发到Service上去。

Zookeeper作为服务连接到Kubernetes集群。Web层APP作为服务消费者注册到Zookeeper（使用Dubbo客户端Jar），采用RPC协议动态连接各种微服务APP。各种微服务APP使用Dubbo服务端（Jar）连接Zookeeper注册服务实例。

最终整个平台运行于IPaaS平台之上。目前IPaaS平台构建的主流容器技术基于Docker和容器管理系统。

3  基于OpenStack的容器管理系统总体设计

3.1  总体架构设计

根据需求分析情况，再结合OpenStack和Kubernetes这两大开源项目，设计出相应容器管理系统的架构。容器管理系统整体由五部分组成，其整体架构如图6所示。

（1）物理层。物理层主要由服务器、网络连接设备、存储设备等实际存在的基层设施组成，是容器管理系统的最底层的硬件条件;

（2）基础设施层。基础设施层是塔建于实际设备之上的OpenStack管理系统，由计算资源池、存储资源池以及网络资源池共同组成。用于管理底层基础设施，为容器管理系统虚拟机提供计算资源、存储资源以及网络资源;

（3）业务管理层。该层主要包括用户管理、应用管理、镜像管理、基础设施管理、告警管理、存储管理、网络管理、日志管理等容器管理系统的主要功能模块;

（4）交互层。交互层主要负责业务管理层和用户访问层的数据交换过程。该层遵循RESTful风格进行两层之间的通讯行为，以便用户调用可视化页面;

（5）用户访问层。该层是用户直观可见的一层，用户通过UI页面可以极简单地作整个容器管理系统。

3.2  功能模块设计

本课题基于容器化改造后的运营商业务系统，设计出一个面向企业级的容器管理、容器化应用管理系统ECP（Elastic Computing Platform，弹性计算平台，简称ECP）。ECP为用户提供轻量级的、稳定的、可靠的容器，具有开箱即用的特性。其目标是提供增强的容器、容器化应用的全生命周期管理，同时基于其丰富的特性可以与企业已经存在的业务系统和管理系统进行集成。容器管理系统ECP的功能结构图如图7所示。

ECP系统内置丰富的容器镜像及大量经过验证的微服务集群应用，结合强大的应用编排功能，可以使用户在已有的IT基础架构之上快速构建大规模具有弹性的应用系统。容器管理系统提供的持续集成服务可以实现应用编译、构建、测试、打包、发布的自动化流程，可保障业务的快速上线。ECP系统可提高业务效率，降低IT成本，摆脱繁杂的基础架构管理。ECP以Kubernetes为核心，整合了企业应用所必须的监控能力、数据存储能力、网络管理能力以及用户管理、权限管理等，形成企业级可用的产品。ECP在Kubernetes的基础上实现了应用管理、用户管理、采集、监控、应用QoS保证等容器管理系统必备的功能。

3.2.1  应用容器管理

应用管理模块主要提供集群管理、资源调度、应用管理、应用协调、容器扩展和收缩、容器网络/持久存储、应用负载均衡、灰色发布、应用监控和检查等核心功能。利用Kubernetes增强了容器和应用程序管理的核心功能，提供了应用部署、维护、扩展机制等功能。该系统的应用可以方便地对运行的应用进行管理。其主要功能如下：首先，Docker用于打包、实例化和运行应用程序;其次，以集群方式运行和管理跨机器容器;再次，解决Docker的跨机器容器之间的通讯问题;最后，容器集群的自愈机制使容器集群始终在用户期望的状态下运行。此外，Kubernetes是一个主从式集中系统，master主要组件如下所述，组件构成如图8所示。

（1）API Server：作为Kubernetes系统的入口，它封装了核心对象的添加、删除和重新检查操作，并提供外部客户和内部组件调用的静态风格接口。它维护的REST对象将持久化到ETCD（一个分布式的、高度一致的密钥/值存储）;

（2）Scheduler：负责集群的资源调度，将机器分配给新的Pod;

（3）Controller-Manager：负责各种控制器的实现。目前有两种类型，一是端点控制，主要负责服务和Pod的定期关联（相关信息由端点对象维护），确保服务到pod的映射始终是最新的;二是复制控制器，主要负责定期关联复制控制器和Pod，以确保复制控制器定义的拷贝数始终与实际运行Pod的拷贝数相同，并且通过设备运行两个组件;

（4）kubelet：负责对容器进行控制，如启动/停止、监控运行状态等。它定期从ETCD获取分配给本地机器的Pod，并根据Pod信息启动或停止相应的容器。同时，它还能收到API Server的HTTP请求，并报告Pod的运行状态。

容器管理系统的应用是由在逻辑上具备依赖关系的多组服务构成的。应用中的每个部分都由一个或多个容器组成，在应用内部形成一种能力（微服务）。多个微服务的组合形成一种对用户有价值的服务能力。ECP系统以应用整体的管理和服务保障为核心。例如，典型的LAMP应用WordPress提供了基于PHP的博客功能，通常WordPress应用由数据库、PHP Web层、LB访问控制层组成。在ECP系统中，这三层可分别使用应用市场中的“MySQL数据库”服务、多个同构的PHP Web容器形成的服务以及一个负载均衡器。在ECP系统中，应用将整个构成WordPress的各部分看成一个整体，整体地对它们进行操作和管理。应用管理业务逻辑如图9所示。

3.2.2  用户管理模块

用户管理模块主要对容器管理系统中的用户、租户和角色三个概念实例进行管理。用户管理模块整体架构如图10所示。

容器管理系统选择复用的能力实现ECP系统的用户、租户和角色管理。其中，容器管理系统ECP中某些概念与OpenStack中相应概念的映射如表1所示。

用户管理模块主要基于OpenStack体系中的KeyStone组件开发，并与其他子系统集成，包括底层IaaS平台。KeyStone组件主要负责用户权限认证工作。该组件主要提供通用的用户管理、多租户管理及权限管理功能。除此之外，该组件还负责提供OpenStack体系中的其他组件的认证工作。当用户希望使用系统中某个实例时，用户会向租户发送请求，该租户会为用户提供一个token。接下来，KeyStone会为用户返回系统可提供的所有可供使用的服务列表，而用户则根据自身需求向目标服务发送token，待使用服务将验证token。若验证通过，KeyStone认为用户具备访问和操作权限，服务才会执行用户发出的请求，最后用户将收到服务执行结果。反之，KeyStone将拒绝用户发出的请求。

3.2.3  日志管理模块

在容器管理系统ECP系统环境中，容器和主机产生的日志分散在整个环境中，并没有统一的方式进行查看和管理，这种情况对企业监控应用的运行情况非常不利。因此，需要一个统一的日志管理系统来对日志的查询、备份进行控制。日志管理模块主要提供面向主机、资源管理、应用、容器及各种系统服务的日志统一收集、存储和检索功能。容器管理系统日志主要分为三种。日志管理架构如图11所示。

第一，系统日志，主要指容器管理系统各种服务、模块组件的日志的收集、存储和查询功能;

第二，容器级日志，即通过Docker的日志管理功能来收集各个容器的日志，采用Logstash将日志收集到统一的ElasticSearch Cluster集中存储并进行分析;

第三，应用日志，是基于ElasticSearch及应用元信息实现面向应用的日志管理和分析功能。

日志管理主要基于目前主流的EFK日志框架部署而成。EFK分别是Fluentd日志收集容器、Elasticsearch日志存储容器和Kibana日志展示容器三大架构的合称。日志管理模块采用SpringMVC技术来实现，其健康检查等接口由StatissticContrller實现，日志的查询、导出等功能由CanesController实现。CanesManager将传递来的请求转换为合适的ElasticSearch查询，并将结果进行处理后返回。并在需要时将日志输出到与FileServer共享的数据卷中，以便实现日志文件的导出。同时CanesManager还将自动定时清理ElasticSearch中的日志，自动将一个月前的所有日志清理掉。日志管理业务架构如图12所示。

4  结  论

本文根据容器管理系统ECP系统的不足之处进行了进一步分析，对容器管理系统的进一步完善提出未来展望。

4.1  本文总结

发展是互联网时代中唯一不变的准则。随着时间的推移，大型项目会不断增加，企业需求也将持续变更。与此同时，Docker技术的出现标志着颠覆以往构建和交付方式的技术已经成熟。本文设计的容器管理系统证实了容器化技术给应用管理、部署和管理带来的变化。将OpenStack和Kubernetes集成起来构建容器管理系统具有重要的现实意义和研究意义。

本课题基于运营商业务系统，首先分析了原有业务系统的体系结构及功能等实际状况，充分考虑到运营商的硬件支持情况，结合新型的轻量级虚拟化计算Docker，经过几番考量提出了一套容器化改造方案，并将该方案成功实施，为接下来的工作奠定基础;然后着手设计并实现了与容器化改造后已经转变为无状态化运营商业务系统相配套的容器管理系统，提出了容器管理系统的整体架构;最后，本课题的研究表明了容器化技术和云计算技术与运营商业务系统相融是可行的，这为接下来的进一步云化打下了坚实基础。

4.2  未来展望

目前，云计算已越来越被各行业所接受并应用。因其为企业带来的高效率转化而成的高收益吸引许多传统行业也开始向此方向转变。然而，云计算和容器化技术的发展从未停歇。因此，本文还存在一些有待改进和探索的方向。下一步的计划研究工作如下所述。

（1）在容器管理系统设计和开发过程中，选择将资源管理的功能、代码逻辑等都放在同一个项目中。随着业务需求的增加，系统往往会产生冗余，给容器管理系统的开发和维护带来极大的不便。因此，提出进一步优化方案，即为了实现快速开发和部署，系统分为多种形式的微服务。分析各个功能和模块，集成了一系列相关的功能和模块构建一个微服务项目来执行某些特定的功能。本文提出的在容器管理系统中引入微服务，可以大大提高容器管理系统的可维护性和可扩展性，有效地简化业务逻辑之间的耦合。

（2）系统基于OpenStack云平台提供云服务，用户可以使用虚拟机、容器和其他资源，然而云服务可供使用的资源类型仍然有限。下一步，我们可以研究和实现更多类型的云服务，比如为用户提供缓存、消息队列、通用网站解决方案和其他服务，为用户提供更多的云服务资源。

参考文献：

[1] OpenStack Installation Guide for Ubuntu 12.04 （LTS）–HAVANA [EB/OL].（2016-11-24）.http：//docs.openstack.org/havana/install-guide/install/apt/content/.

[2] 2018 OpenStack User Survey Report [EB/OL].（2018-11-13）.https：//www.openstack.org/user-survey/2018-user-survey-report/.

[3] 张新朝.基于云平台虚拟集群的设计与实现 [D].漳州：闽南师范大学，2015.

[4] 王小军，朱祎.虚拟化技术在云计算数据中心中的应用研究 [J].电脑知识与技术，2014，10（4）：677-679.

[5] Opsahl J M G. Open-source virtualization：Functionality and performance of Qemu/KVM，Xen，Libvirt and VirtualBox [D/OL].Oslo：University of Oslo （2013-10-25）.https：//www.duo.uio.no/bitstream/Handle/10852/37427/1/Opsahl_Master.pdf.

[6] Muhammad Siraj Rathore，Markus Hidel，Peter Sj？din. KVM vs. LXC：Comparing Performance and Isolation of Hardware-assisted Virtual Routers [J].American Journal of Networks and Communications，2013，2（4）：88.

[7] Roy Thomas Fielding. Architectural Styles and the Design of Network-based Software Architectures [D].American：University of California，2000.

[8] 管江華.大数据管理系统在云平台上自动部署关键技术研究 [D].北京：中国科学院大学，2015.

[9] 马建辉，赖涛.基于SOA架构的异构系统集成平台的设计 [J].数字技术与应用，2018，36（2）：158-159.

[10] OpenStack Services [EB/OL].（2018-7-15）.https：//www.openstack.org/software/project-navigator/openstack-components# openstack-services.

[11] 张炎华.私有云系统的实现及性能分析 [D].北京：北京邮电大学，2012.

[12] 周祥.私有云构建中资源和数据管理的研究 [D].北京：北京工业大学，2012.

[13] 周洪波.云计算：技术、应用、标准和商业模式 [M].北京：电子工业出版社，2011.

[14] John W. Rittinghouse，James F. Ransome.云计算实现、管理与安全 [M].田思源，赵学锋，译.北京：机械工业出版社，2010.

[15] 杜军.基于Kubernetes的云端资源调度器改进 [D].杭州：浙江大学，2016.

[16] 杨海锋.浅谈云计算PaaS的发展及对IT产业的影响 [J].福建电脑，2012，28（11）：78-79.

[17] 程文迪，刘德民.Openstack云主机管理的敏捷开发技术 [J].现代防御技术，2019，47（1）：169-175.

[18] 秦怀国.辽宁邮储中间业务系统设计与开发 [D].成都：电子科技大学，2014.

[19] Feng X，Shen J，Fan Y. REST：An Alternative to RPC for Web Services Architecture [C].//International Conference on Future Information Networks. IEEE，2009：7-10.

[20] 朱智强，林韧昊，胡翠云，等.基于数字证书的openstack身份认证协议 [J].通信学报，2019，40（2）：188-196.

[21] 邱晨，陈亚峰，周伟，等.基于容器化OpenStack云平台及Ceph存储的私有云实施案例 [J].邮电设计技术，2018（8）：51-56.

[22] 冯轩.基于Docker技术的Hadoop性能优化研究 [D].南京：南京邮电大学，2018.

[23] 赵然，朱小勇.微服务架构评述 [J].网络新媒体技术，2019，8（1）：58-61+65.

作者简介：王颖（1963.11-），男，汉族，河北唐山人，计算机科学与技术专业副教授，本科，研究方向：计算机网络、云计算技术与应用;邹一荣（1982.09-），男，汉族，广东惠州人，通信工程师，研究生，研究方向：云计算技术与应用;吴家隐（1984.12-），男，汉族，广东雷州人，毕业于中山大学，硕士，研究方向：云计算、半导体光电子。