在大型数据中心IT基础架构的演进和容器在微服务时代大型数据中心中的应用实践

在大型数据中心IT基础架构的演进和容器在微服务时代大型数据中心中的应用实践

目录

一、大型数据中心IT架构和演进......................................3

（一）大型数据中心的定义、流行架构的发展历程.........................3

（二）小架构到大集中一一传统大型数据中心IT架构形成..................3

（三）数据安全、业务连续性需求引发的多中心架构.......................5

（四）后“IOE”时代一一虚拟化资源池..................................5

（五）云计算热潮一一基于openstack的云计算管理平台架构..............6

（六）微服务兴起——基于容器的云计算架构.............................8

二、从虚拟化到容器云架构.........................................11

（一）物理机、虚拟机、容器的演化....................................11

（二）虚拟化Vs容器云................................................11

1.虚拟机是什么..................................................11

2.容器是什么....................................................12

3.容器技术主要有4个特点：......................................13

4.虚拟机vs容器................................................14

5.集中式vs分布式...............................................14

（三）Doker和Kunbernetes...........................................15

1.什么是Doker...................................................15

2.什么是Kubernetes..............................................17

3.Kubernetes的特点：............................................17

4.Kubcrnetes结构.................................................17

（四）基于kubernetes的容器云平台...................................19

1.容器云平台功能介绍............................................19

2.容器云架构解析................................................20

（五）容器云的业务场景和建设方法....................................22

1.适用的业务场景................................................22

2.应用容器化改造过程............................................22

3.应用容器化主要改造点..........................................23

4.容器云平台集成方法论..........................................24

5.容器云平台的应用发布..........................................24

三、某运营商容器云管平台的应用和运维实例.........................25

作者版本号更新日期描述

郭凯VI.02019-10-20创建、概要

郭凯VI.1、VI.22019-10-30修订、完善

郭凯VI.32019-11-3修订、完善

郭凯VI.42019-11-4校对

一、大型数据中心IT架构和演进

数据中心(DataCenter)是企业IT系统的核心，海量数据运算、交换、

存储的中心，关键信息业务应用的计算环境，集中管控各种基础设施、平台环

境。而在金融、安全、公共事'也、通讯、IT服务、云服务等行业都需要依赖庞

大的数据中心架构体系来支撑。

(-)大型数据中心的定义、流行架构的发展历程

L大型数据中心

一般企业数据中心具备基础CT网络、计算资源、存储资源，为企业提

供IT支持。数据中心由设备规模、业务规模和架构复杂度区分，我们可以

人为定义为小型数据中心和大型数据中心。

企业TT业务的支撑系统根据业务量大小就有所区别，小到一两台物理

服务器，或者儿台云主机，大道多个地域集中机房。在这里我们将体量相

对较大，架构相对复杂的IT环境称之为大型数据中心。而多个数据中心之

间可以形成互联关系，为企业提供高可用、分布式架构的IT解决方案。

2.主要架构发展历程

多年来的数据中心经历了独立环境-集中建设一虚拟化+多中心-云化-

微服务的演化进程。

(二)小架构到大集中一一传统大型数据中心IT架构形成

1.独立环境时代

2000年前后，各大型企业的IT是由分支部门或分公司独立建设，独立

交付本地化服务的。分散化IT建设是一个显著的特点：每个局点都是一个

局域网架构，属于小型数据中心，其中分别承担了本地化的几个'业务。

这就造成了一些不必要的投资和运维压力:

•重复的基础设施建设；

•重复的业务部署，但标准化不高，各地不统一；

•计算存储资源浪费；

•集中数据传输成本，各局点之间数据消费困难；

•各局点都需要有专业的运维人员和业务开发人员，运维成本高。

插入拓扑

2.集中建设时代

大家都意识到了资源和投资的浪费，IT企业开始尝试实践数据集中化

的解决方案。恰逢传输网络有了明显的速率提升，省内乃至国内数据短时

差传输不再是难以企及的了，此时有众多解决方案咨询公司以集中化改造

为需求，提供IT咨询、支持、实施服务。进入2005年前后，由各大运营

商、央企开始，陆续完成核心业务的改造。

集中化架构的业务模式特点是，核心业务后台服务部署于集中域，分

支机构仅使用业务平台。集中域处理数据请求、分析数据、提供业务服

务；前端业务话单仅提供数据采集和上传。

集中化架构的IT架构特点是体量庞大，资源调度灵活,企业集中建设

了能满足区域内的所有业务的IT设施，包括计算资源（X86服务器、小型

机、大型机）、存储资源（大体量集中式存储）、网络资源（本地数通网

络和异地传输网络）、中间件软件（软负载均衡、web服务、代理服务

等）、数据库资源（oracle.DB2等大型数据库）

插入拓扑

此时，由于需要满足集中化带来的庞大计算和存储压力，企业通常曹

勇小型机+FC集中存储+大型数据库的架构。这也就是我们后来所说的

“I0E”——IBM小型机+EMC存储+Oracle数据库。

（三）数据安全、业务连续性需求引发的多中心架构

2001年9月11日，爆发了举世震惊的9・11事件，异地容灾，业务可

持续访问的概念再次被提及，并提升到一个新的高度。此前虽已有此类的

概念提出，但是迫于庞大的投资和闲置资源的维护成本，企业和机构仅处

于观望研究状态。随着国内数据集中的演进，核心业务和核心数据大多存

在于一个大型数据中心，这就对数据安全和业务持续性提出了重大挑战，

备份、容灾、双活被提上建设日程。

备份原则：多种备分手段复合，热备冷备兼顾。

•存储快照

一在集中式存储上进行快照策略配置，月于满足测试开发环境的需

求，以及对人为误操作造成的逻辑错误的故障恢复。

•集中备份

一在一个数据中心内，采用NBU等统一各份平台和软件，对数据中心

内所有对象进行周期性备份，包括系统、数据库数据、数据库结构、文件

系统数据等。用于面临某个资源故障造成数据破坏时的数据恢复。

•异地复制备份

一将数据备份至异地的数据中心，有同步和异步两种模式，通常用于

大面积数据破坏和数据中心级别故障的恢复。

•冷备份

一通常指磁带库等可拆卸存储介质的备份手段。备份磁带被检测有效

后存放于特殊环境保障的储存点，是数据保障的最后一道屏障。

容灾和高可用原则：分级对待，分标准建设。

•基础业务：本地高可用

・重要业务：本地双活高可用

•核心业务：本地双活高可用+异地容灾

•数据中心：两地三中心，基于同城双活+异城灾备的ICT解决方案

插入两地三中心拓扑

（四）后“I0E”时代一一虚拟化资源池

去“IOE”背景:自2013年棱镜门事件之后,我国政府已经意识到政府数据安全的重要

性,也加强了政府数据安全方面的工作,有报道称，总科、IBM、谷歌、高通、英特尔、

苹果、甲骨文、微软并称为美国的“八大金刚”，他N1一方ifii与美国政府、军队保持着紧

密的联系:另一方面在中国长驱直入,占据众多关键领域,导致美国情报部门通过这些设

备、软件、网络获取信息,给中国的信息安全带来巨大威胁。“去IOE”与设备采购国产

化、自主研发等口号挂钩,带有一定的政治色彩。如去年*n8也未进入中央机关政府采

购名单。

在去“IOE”浪潮下，小型机、集中存储、大型核心数据库逐步退出舞

台，机关和企业面临的是X86化、分布式存储、大型库拆分的改造之路。

此时x86虚拟化架构（kvm、阿里ECS、vmware等）+分布式存储解决方案

（CephSDS）+轻量级数据库（mysql等）+核心数据库一体机的解决方案占

了较大的比例。同时业务改造也呈现出庞大的需求和紧锣密鼓的工程状

态。

虚拟化技术在此时进入成熟期，众多机构和企业以虚拟化为主要的

laaS层架构模式。其优势是：能够出色的协调各业务之间的资源需求，避

免资源浪费；能够满足高可用集群需求，保障业务持续性；能够快速扩

容、部署、回收，提升维护效率；系统硬件解耦，开源工具支持，减弱对

供应厂商的依赖性；全球IT社区化，技术演进提升快。

（五）云计算热潮一基于openstack的云计算管理平台架构

随着虚拟化资源池的越来越庞大，原生的管理平台已经无法纳管过多的虚

拟化节点，此时需要一个管理平台来实现统一纳管、统一配置分发、统一资源

计费、统一告警分析等一些列的管理功能和服务功能。且该平台必须是开放

的，可维护更新的，多接口的，兼容性强的，它就是openstack。

同时，在初创型和小型企业乃至IT爱好者中，有对少量计算资源的需求,

或者数据库、应用软件等PaaS、SaaS层的实际需求。公有云的出现解决的这

一些的需求。

2010年Openstack项目成立，此后逐渐有众多IT厂商和解决方案厂商参

与共同建设，形成了openstack社区。由于其开源的技术结构，在互联网、政

务管理、运营商中开始实践基于。penstack架构的云管理平台.用于纳管已有

的虚拟化资源池，这就是我们所说的私有云。同时公有云环境在阿里、腾讯、

电信等领军企业的带领下走向繁荣。

Openstack是一个云管操作平台，用于编排云资源。其是由控制节点，计

算节点，网络节点，存储节点四大部分组成。

•控制节点负责对其余节点的控制，包含虚拟机建立，迁移，网络分配，存

储分配等等。

•计算节点负责虚拟机运行

•网络节点负责对外网络与内网络之间的通信

•存储节点负责对虚拟机的额外存储管理等等

计费

HorizonCeilometer

模板制作

Heat

■S59收掘库赧务

Trove

计算网络

ComputeNeutron律机部■胭努

Ironic

NovaQuantum工作流服务

Convection

Glance

Hadoop服务

Sahara

SiHiAuEKeystone

Openstack包含了众多的组件模块，来实现一系列的服务功能，最终实现

对底层资源的同意调度和对外交付。

模块名

提供服务功能描述

称

提供了一个基于web的自服务门户，与

HorizonDashboarcOpenSlack底层服务交互，诸如启动一个实

例，分配1P地址以及配置访问控制

在OpenStack环境中计算实例的生命周期管

NovaCompute理。按需响应包括生成、调度、回收虚拟机等

操作。

确保为其它OpenStack服务提供网络连接即服

NeutronNetworking

务"Quantum”->Neutron

为其他OpenStack服务提供认证和授权服务，

KeystoneIdentityManagement

为所有的OpenStack服务提供一个端点目录。

通过一个RESTful，基于HTTP的应用程序接口

存储和任意检索的非结构化数据对象。它拥有

高容错机制，基于数据复制和可扩展架构。它

SwiftObjectStorage的实现并像是一个文件服务器需要挂载目录。

在此种方式下，它写入对象和文件到多个硬盘

中，以确保数据是在集群内跨服务器的多份复

制

提供管理数据库即服务配置关系和非关系数据

TroveDatabaseService库引擎节点的Trove相关，同时提供Trove在

Horizon中的管理面板

BareMetal提供裸金属管理服务，NovaBaremetal驱动程

Ironic

Provisioning序

提供了基于模板来实现云环境中资源的初始

HeatOrchestration化，依赖关系处理，部署等基本操作，也可以

解决自动收缩,负载均衡等高级特性。

DataProcessing使用用户能够在Openstack平台上便于创建和

Sahara

Service管理Hadoop以及其他计算框架集群，

（六）微服务兴起——基于容器的云计算架构

在openstack云管平台下，运行的业务本质没有变化，仍然是集中式的应

用架构。然而市场和业务需求的变化日新月异，这就造成了后端应用系统开发

部署跟不上市场需求，于是敏捷开发的概念被提出。

同时业务模块之间的关联关系时有依赖性的，强耦合的，一旦某个业务模块的

故障，可能造成整个业务的崩溃。此时容器技术日趋成熟，为业务解耦带来新

的方向。

那么怎么才能把业务部署快起来，业务依赖性弱下来？我们从业务维度找到了

解决方案，将集中式的中大型业务应用拆分成多个微型服务，各个微服务可被

独立部署，各个微服务之间是松耦合的。

1.什么是微服务

简单的说，微服务架构就是以业务域或业务功能为边界，将一个大而全的

应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，

应用之间使用轻量级通信机制互联，并且他们可以通过自动化方式部署。

2.微服务特征

单一负载小职责少，轻量级通讯，业务数据独立，技术多样性。

正是因为小，所以每个微服务的逻辑相对简单，弋码量也小很多，进而修复问

题及修改变更会快很多；

而多个微服务可以并行演进，从而可以缩短测试，部署和发布的时间；同样是

因为独立，每个微服务都可以根据实际情况，单独的横向拓展；因为轻量级通

讯，每个微服务才可以独立起来，贯彻高内聚低耦合的架构思想.

单体服务架构图

微服务架构图

3.微服务的优点

•每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。微服务

能够被小团队单独开发，这个小团队可以是2到5人的开发人员组成。

•微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段

都是独立的。

•微服务能使用不同的语言开发。微服务允许容易且灵活的方式集成自动部

署，通过持续集成工具，如Jenkins,bamboo0

•微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自

己的工作成果。无需通过合作才能体现价值。

•微服务允许你利用融合最新技术。微服务能够即时被要求扩展。微服务能

部署中低端配置的服务器上。易于和第三方袈成。

•每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数

据库。

4.微服务的缺点

•运维开销及成本增加：单体服务可能只需部署至一小片应用服务区集群，

而微服务架构可能变成需要构建/测试/部署/运行数卜个独立的服务，并可

能需要支持多种语言和环境。

•隐式接口及接口匹配问题：把系统分为多个协作组件后会产生新的接口，

这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。

•分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他

若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机

制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统

问题。

•异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨

微服务的事务性处理，其实现机制会变得复杂化。

•可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以

可视化及全面测试。

5.微服务的IT解决方案

各个微服务运行的环境就是容器。我们通过容器管理平台对容器进行编

排，来实现服务的负载均衡和高可用，来优化服务间的关联关系。

目前的主流容器引擎是docker,容器管理平台中kunbe门ietes则独树一帜。由

于Kubernetes本身就是微服务架构，而且相较更加适合微服务和DevOps的

设计，目前主流的解决方案为X86服务器（+VM虚拟机）+Doker+

Kunbernetes的架构，我们将在下文进行展开论述。

二、从虚拟化到容器云架构

（一）物理机、虚拟机、容器的演化

物理机-＞虚拟机：以前构建应用程序时使用的是宿主操作系统提供的资

源，在部署应用程序时也使用了相同的模式。但如果想扩展应用程序可能

需要另一台硬件服务器。而随着数量不断增加，成本和其他资源（如硬件

和能源消耗）也会随之增加。随着基础设施的不断增加、硬件资源使用效

率低、操作系统复杂多样这些问题促成了硬件虚拟化的发展，于是虚拟机

（VM）出现了，我们通过虚拟机来优化IT基础设施。虚拟机具有自己的

客户操作系统，运行在单个物理机或宿主操作系统中。我们因此能够运行

多个应用程序，而无需安装大量物理机。

虚拟机容器：宿主操作系统可以确保在不同虚拟机之间进行系统性的资

源分配和负载均衡。虚拟机降低了软件维护的难度和成本，不过仍然可以

进一步优化。例如，并非所有的应用程序在客户操作系统环境中都会按预

期运行。此外，即使是运行简单的进程，客户操作系统也需要大量资源。

这些问题促成了下一个创新：容器化。

与特定十操作系统的虚拟机不同，容器特定「应用程序，因为更加轻量

级。此外，虚拟机可以运行多个进程，而容器作为单个进程运行。

（二）虚拟化Vs容器云

1.虚拟机是什么

虚拟机是物理机的抽象，其中每个VM都有自己的客户操作系统。这意味着

初始化每个虚拟机需要创建物理机的虚拟抽象层，然后设置完整的OS启动。因

此，就存储，RAM和CPU而言，每个VM将消耗大量系统资源。

Virtual

Machines

Virtual

咽。0西叵❷

QS30@00eHardware

Virtualization

Hypervisor

Layer

•PhysicalHardware:an硬件,包括CPU、内存、磁盘、I。设备等.

•Hypervisor:虚拟化技术的核心，负责虚拟化硬件设备,分配资源,并加载所有虚拟机的客户耍作系统

•VirtualHardware:由Hypervisor虚拟出来的硬件设备,提供给虚拟机使用,对于虚拟机而言它就是真实

的物理设卷

•VirtualMachines:根据虚拟出来的设备创建的逻辑计算机,相互独立的OS利应用

2.容器是什么

容器是英文单词Container的直译。LinuxContainer它是一种内核轻最

级的操作系统层虚拟化技术。LinuxContainer主要由Namespace和Cgroup两

大机制来保证实现。

容器是应用层的抽象，它将代码和依赖关系打包在一起。多个容器可以在同一

台机器上运行，并与其他容器共享操作系统内核，每个容器在用户空间中作为

独立进程运行，相互之间不会有任何接口（类似iPhone的app）0容器占用的

空间比VM少（容器镜像的大小通常为几十MB）,可以处理更多的应用程序，并

且需要更少的硬件资源。

OperatingSystem

Infrastructure

Ho

•Infrastructure：基础硬件设备

•OperationgSystem；操作系统

•DockerEngine：使用Docker的组件和服务构建和运行容器,包括

Dockerdaemon.CLI和RESTAPI等

・Bins/Libs:各种依赖系统文件以及库文件,应用的所有依赖都打包在

Docker镜像中

・APP：应用的源代码与它的依赖都打包在Docker镜像中

3.容器技术主要有4个特点：

・极其轻量：只打包了必要的Bin/Lib；

•秒级部署：根据镜像的不同，容器的部署大概在毫秒与秒之间（比虚拟机

强很多）；

•易于移植：一次构建，随处部署；

•弹性伸缩：Kubcrr.ctcs^Swam、Mcsos这类开源、方便、好使的容器管理

平台有着非常强大的弹性管理能力。

4.虚拟机vs容器

•容器和虚拟机具有类似的资源隔离和分配优势，但功能不同，因为容器是

虚拟化操作系统而不是虚拟化硬件。

•相对虚拟机而言，容器不携带操作系统，只包含应用相关的依赖，共享操

作系统的内核，直接运行在物理设备上，体积更小，更便携高效，启动速

度更快。

•Docker的理念是隔离单个应用程序，而不是整个系统，还是运行在同一个

系统上。而VM则是整个系统的之间的隔离，所以相对来说Docker的隔离

性要差一点。

•优点;同萍都是提高资源的使用率，docker相对虚拟机来说，体积更小，

更便携高效，启动速度更快，并且迁移更方便，容器内有完整的应用相关

的环境和依赖。

•缺点：隔离性较差，容器共享内核，如果需要调整内核参数可能会影响到

当前运行的所有容器，虚拟机则是独立运行的。

Virtualization

5.集中式VS分布式

集中式部署的问题：

•依赖服务器环境，需要各服务器资源统一。

•无法充分利用服务器等资源，使用率一般仅能达到70%0

•无法或很难做到容灾恢复。

•需要人工进行服务扩容，修改服务配置。

•服务资源散乱（域名，服务器，负载，数据库），无法做集中管理。

•时间消耗较多，增加运维成本。

•需要借助第三方工具进行资源监控，较为麻烦。

•需要对开发、测试、生产环境进行区别管理。

分布式部署的好处：

•增大了系统的容量，可以将分布在各处的资源综合利用。而这种利用对用

户而言是透明的；

•可以将负载由单个节点转移到多个，从而提高效率；

•分布式技术可以避免由于单个节点失效而使整个系统崩溃的危险，加强了

系统的可用性；

•使系统模块化，可以提高模块的重用度，同时系统的扩展性也更高了；

•提高了开发和发布速度，因为软件服务模块被拆分，开发和发布都可以并

行。

值总值

WEBWEBWEB

普通硬件普通硬件普通硬件

去状态化

APPAPPAPPRedis

普通财普通硬件状态雌

——二

状态数据

DB

强大硬件

or

分布式

（三）Doker和Kunbernetes

1.什么是Doker

Docker是PaaS提供商dotCloud开源的高级容器引擎，Docker自2013

年以来日益热门，至今已经是业界主要选择。

•容器.Kubernetes

JGoogleOCICNCF

Docker开源宣布支持宣布支持'Kubernetes'

iQ&l

发布kuberneteskubernetes从CNCF毕业

Kubernetesfitiz

2013201420152015201/

dnrtorLCLOUDNATIVE

ICOWUTWCFCUKMnOM

Docker快速敏捷（启动、停止都是以秒或毫秒为单位的），隔离轻量级

（不添加额外的操作系统）,这些实际上是Linux内核提供的能力，Docker是

沿用了这些特性，Docker最大的创新点在于Docker镜像的设计，下面是张

Docker镜像的层次图，分层的文件系统，一层层地搭建出一个完整的容器运行

环境。

一个docker镜像由多个可读的镜像层组成，然后运行的容器会在这个

docker的镜像上面多加一层可写的容器层，任何的对文件的更改都只存在此容

器层。因此任何对容器的操作均不会影响到镜像。

供了一整套镜像存储方案（DockerRegistry）,可以非常方便地获取想要的镜

像，然后快速地启动运行，而不必像以前那样安装各种麻烦的软件依赖。

Docker解决了应月的发布、构建和运行，创建了很多想象空间，所以基于

Docker衍生出了很多新的解决方案，特别是PaaS容器管理平台，这些PaaS平

台更加灵活，更加适应企业，Kubcrnctcs是其中最具代表性的一员。

2.什么是Kubernetes

Kubernetes一个月于容器集群的自动化部署、扩容以及运维的开源平台。

通过Kubernetes,你可以快速有效地响应用户需求;快速而有预期地部署你的应

用；极速地扩展你的应用；无缝对接新应用功能;节省滨源，优化硬件资源的使

用。为容器编排管理提供了完整的开源方案。

3.Kubernetes的特点：

网络模型

kubernetes采用了三层网络模型,分为Pod二P,ClusterIP,NodelP。用简单

的话来说，kubewetes在内部使用自己的网络进行通讯，这样做一个最直接的

好处是我们不用再担心端口冲突的问题。

对象

在kubernetes中,万物皆对象。路由(Ingress)、服务(Service)、部署

(Deployment)>存储(Storage/PV/PVC)、容器(Pod)、角色(Role)、账户

(Accoutn)配置(Confi冲ap)等等。通过管理这些对象来管理整个kubernetes

集群。

声名式管理

Kubernetes不在使用命令式语言，转为采用声名式进行资源管理。

4.Kubernetes结构

Kubernetes由Master节点和Worker节点组成。master节点是

Kubernetes的大脑，而woker节点则是kubernetes中实际运行服务的劳动

者。Master主要由ETCD/ControllerManager/ApiServer/Schedular能成,

ETCD

主要负责存储各个woker节点的状态和其它相关数据，可以理解为

kubernetes的数据库。

ControllerManager

负责维护集群的状态，比如故障检测、自动寸展、滚动更新等

Scheduler

负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上

Worker主要由kubelet和kube-proxy组成，一般还会安装kube-dns组件。

kubelet

负责维护容器的生命周期，同时也负责Volume(CV1)和网络(CN1)的管

理；

kube-proxy

负责为Service提供cluster内部的服务发现和负载均衡；

kube-dns

负责为整个集群提供DNS服务，通过Service名称访问相应的服务

J

（四）基于kubernetes的容器云平台

1.容器云平台功能介绍

•容器云平台，是一个基于docker容器，借助Kubernetes进行容器编排调

度，提高资源利用率，并通过自研系统实现业务划分、应用操作、弹性扩

缩、实例自愈、服务监控等功能的Paas容器云平台。

•借助容器云平台，租户无需登录后端实例主机可以进行应用发布，应用暂

停、启动、重启、参数修改，代码包下载等操作。并且配置健康检测之

后，平台可以直观反应出应用各实例的运行状态。同时，容器云平台也提

供性能监控图线，让业务维护人员更加方便的查看和分析业务的实时运行

情况。

•容器云平台是为整个数据中心提供分布式调度与协调功能，实现数据中心

级弹性伸缩能力的软件堆栈，它将所有数据中心的资源当做一台计算机来

调度。

•容器云平台提供网页界面和CLT,实现资源自动化管理、进程调度、内部

进程通讯、简化分布式服务的安装和管理，方便对集群和其中的服务远程

地管理和监控，使企业像使用一台主机一样使用分布式数据中心的多个集

群资源，进行应用的创建、发布和资源的弹性扩容与缩容。

2.容器云架构解析

功能模块架构

系统环境：搭建在Linux基础上，拥有企业级的安全性、稳定性和可靠性

容器API：Docker

编排管理：Kubernetes

容器云平台核心功能树

•管理平台：

定制自主开发，运维和开发的统一入口

•Dashboard

主机性能展示、容器性能展示、应用性能展示、集成指标展示、事件指

标展示等

•监控告警模块

监控数据采集、日志管理、告警管理和事件管理

•编排调度模块

基于CPU使用率、内存使用率、服务并发数、响应时间等容量数据，通

过定制的调度算法实现服务的自动弹性扩缩容和迁移。

•日志中心

采用Elasticsearch、Logstash、Graylog构建,实现对容器日志的统一

存储及检索

•资源管理模块

及时发现容器云内的资源、服务的变更，动态实现配置中心数据实时更

新，为平台调度提供数据支持。服务目录管理、规则管理、CMDB信息

•安全管理

用户管理、权限策略管理和统一认证接口

•持续集成

镜像构建、集成测试、流程管理和上线管理

主机和集群资源管理

资源管理Dashboard资源状态统一展示

应用发布

提供公共镜像库和私有镜像库

具备身份验证

应用统一日志

平台日志查询、下我等日志管理

提供基于单机版的四虱、redis

有状态服等有状态服务

应用、平台、容器的性能监控

监控告警

及告警

权限管理

角色管理

对容器间的交互进行编排应用例

&：

网络管理、定时任务、安全扫描、一键部署etc.

管理平台

Dashboard应用管理应用编排日志中心持续集成平台

主机用户

监控管理

容器权限

监控kubernetes管理

应用docker安全

监控扫描

AppbcationAp0»cat>onAwMcatxxi

监控告警bin/libsbin/ht»安全管理

物理机

虚拟机

云主机

技术架构：

开发人员上传代码到git或SVN±,jcnkins会自动发现代码更新并构

建为docker镜像包，上传到镜像仓库，同时把版本信息同步到容器管理平

台；

应用管理用户通过容器管理平台手动或者自动的方式发布更新后的版

本，由kubernetes的master节点调度相应容器到最优的node节点中，被

调度的node节点收到任务后，由node节点中的kubelet组件启动相应的

容器；

外部用户访问业务时通过我们的硬负载均衡器（array或者F5）做代

理，路由到NODE节点，在由kubernetes的proxy组件作为为软负载到达

最终要访问的容器上，保证业务的持续可用，避免了容器随机漂移，IP地

址变化的问题

（五）容器云的业务场景和建设方法

1.适用的业务场景

容器云平台支持各类应用（包括前端无状态、前端有状态应用和后台

进程类系统）的快速集成上云。

•无状态的应用（所谓无状态指的是应用实例中无session信息或者无特

定的配置信息）；（强烈推荐）

•有状态的应用：前端类WEB应用，依然需要会话保持等负载均衡策略，

session、共享文件等存放在本地。

•后台进程类系统：后台进程类应用，进程服务间的调用通过配置中心的

方式实现。

•目前适合上云的应用类型：纯java应用、tomcat应用、weblogic应

用、nginx、php>apacheNpython类应用。

2.应用容器化改造过程

P0C测试

通常我们尝试做业务改造前，要进行POC测试。我们建议挑选应用结

构分布式、无状态；业务类型面向互联网，访问集中，突发量大，业务更

新快的。

注:无状态应用意思是在应用的访问中没有必然的上下文关系,即这个应用

不会保存任何信息,当前会话访问的服务器如果宕机不会影响任何应用以及下一

次的访问

是

一般对于^11"状态的应用的做法是让sessionid保存在客户端cookies,通

过redis内存数据库保存会话状态信息达到即使每次访问请求的不是同一个

web服务器也不会需要用户重新登录等操作。

应用容器化改造过程（tomcat）

编写8*市I。根据应用需求修改lookercommit通过由期£run

选择基础镜像脚本文件Tomcat配置文件生成应用镜像运行应用容器

下载应用所需的生成Tomcat镜像根据应用需求编写拷贝应用包到

JDK和TomcatTomcat启动脚本指定目录下

3.应用容器化主要改造点

热点数据缓存

建议应用在设计时将热点数据存放到缓存服务器（如Redis、Memcached）中，

在启动时避免执行加载缓存动作，提高应用系统启动速度。

无状态化改造

建议应用开发设计时将用户的会话信息保存到缓存服务器（如Redis、

Memcached）中，根据用户的唯一标识session_id来对缓存服务器进行存取用

户的会话信息，会话信息与应用实例分离，实现应用无状态化。

定时任务与应用分离

建议将定时任务与应用分开，不要封装到一个应用包中。

数据库连接池设置

如果连接池的初始值设置过大会造成数据库无法及时响应大量并发连接而导致

数据异常，建议初始值设置不宜太大。

不要在容器中存储数据

容器是一次性的，当容器被停止、销毁或替换时，应用在容器中存储的数据同

样会被销毁。

不要依赖IP地址

容器IP是不固定的，如果应用或微服务需要与其他容器通讯，可以选择更合

适的方式与其他容器进行通讯。

4.容器云平台集成方法论

调研及需求分析平台集成规划与设计平台集成实施与测试平台优化及维护

调研及需求分析

•了解系统现状

•明确业务影响范围

•理解运营现状

•风险评估

•需求分析

平台集成规划与设计

•平台架构设计

•平台资源规划

•业务系统部署规划

•系统割接规划

•系统演进规划

平台集成实施与测试

•平台部署

•平台能力测试

•配合应用改造

•联调测试

­割接、上线

平台优化及维护

.平台监控

•平台星能分析评估

•平台优化调整

•平台维护

5.容器云平台的应用发布

发布流程：

•业务提供符合上云标准的应用代码包;

选择容器云平台提供的基础镜像及中间件版不；

租户通过平台发布，自动创建业务镜像，通过发布业务镜像后替换当前镜

像，完成业务的发布或滚动升级；

应用代码包要蹴像（中间件版本）业像

三、某运营商容器云管平台的应用和运维实例

近年来，**移动一直致力于网管支撑系统能力中心化改造，以公司大

IT中台战略为背景，推进业务中台0域支撑能力的建设，实现架构的

云化、微服务化、中心化。8月7日，**移动云计算支撑中心和网管中

心共同协作，推进性能中心业务实现了异构双平面的部署架构，至此

浙江首个0SS4.0系统在容器云平台ARM架构和X86架构下正式商用落

地。

（-）基于ARM的容器云平台架构

相对于X86架构，ARM架构下的计算平台能够使用精简指令和纵核

架构带来更强的整体性能、单核面积小可以取得较高的能耗比、拥有

开放架构和灵活的IP授权机制容易实现自主可控；在ARM架构授权

上，通过优化分支预测算法、提升运算单元数量、改进内存子系统架

构等一系列微架构设计，大幅提高处理器核性能。

本次系统上线硬件采用了华为Taishan系列2280V2（2个鱼昆鹏

920处理器，64核，2.6Ghz）均衡型ARM服务器，0S选用CentOS

7.6.1810-aarch64位操作系统，中间件k8s版本选用1.13.5,借助鲸

席ARM处理器整机方式的对外提供服务，实现容器云管理平台对X86

和ARM架构的同时纳管，支持IT系统国产化演进。

0SS4.0及性能中心介绍

面向0SS4.0架构，**移动启动了网管能力中心化改造，并将微服务平

台管控延伸到了。域。启动了性能中心和编排中心的建设，其中性能

中心业务系统为满足集团四轮驱动业务全覆盖需求，围绕移动业务、

家庭业务、政企业务和新业务的设备管理、业务管理和流程管理展

开，主要包括：移动业务子中心，无线网优子中心，有线业务子中

心。为充分验证ARM架构下服务的可用性，本次ARM商用选用性能中

心的家客业务的3个应用模块和5个能力模块做功能调测。

JRB他

«Q

<M

安

全

I

I…管

fbtfr

WSX理

—"]

Iw

0$$系

-1