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

在大型数据中心IT基础架构的演进和容器在微服务时代大型数据中心中的应用实践目录一、 大型数据中心IT架构和演进 3(一) 大型数据中心的定义、流行架构的发展历程 3(二) 小架构到大集中——传统大型数据中心IT架构形成 3(三) 数据安全、业务连续性需求引发的多中心架构 5(四) 后“IOE”时代——虚拟化资源池 5(五) 云计算热潮——基于openstack的云计算管理平台架构 6(六) 微服务兴起——基于容器的云计算架构 8二、 从虚拟化到容器云架构 11(一) 物理机、虚拟机、容器的演化 11(二) 虚拟化Vs容器云 111. 虚拟机是什么 112. 容器是什么 123. 容器技术主要有4个特点： 134. 虚拟机vs容器 145. 集中式vs分布式 14(三) Doker和Kunbernetes 151. 什么是Doker 152. 什么是Kubernetes 173. Kubernetes的特点： 174. Kubernetes结构 17(四) 基于kubernetes的容器云平台 191. 容器云平台功能介绍 192. 容器云架构解析 20(五) 容器云的业务场景和建设方法 221. 适用的业务场景 222. 应用容器化改造过程 223. 应用容器化主要改造点 234. 容器云平台集成方法论 245. 容器云平台的应用发布 24三、 某运营商容器云管平台的应用和运维实例 25作者版本号更新日期描述郭凯V1.02019-10-20创建、概要郭凯V1.1、V1.22019-10-30修订、完善郭凯V1.32019-11-3修订、完善郭凯V1.42019-11-4校对大型数据中心IT架构和演进数据中心（DataCenter）是企业IT系统的核心，海量数据运算、交换、存储的中心，关键信息业务应用的计算环境，集中管控各种基础设施、平台环境。而在金融、安全、公共事业、通讯、IT服务、云服务等行业都需要依赖庞大的数据中心架构体系来支撑。大型数据中心的定义、流行架构的发展历程1.大型数据中心一般企业数据中心具备基础CT网络、计算资源、存储资源，为企业提供IT支持。数据中心由设备规模、业务规模和架构复杂度区分，我们可以人为定义为小型数据中心和大型数据中心。企业IT业务的支撑系统根据业务量大小就有所区别，小到一两台物理服务器，或者几台云主机，大道多个地域集中机房。在这里我们将体量相对较大，架构相对复杂的IT环境称之为大型数据中心。而多个数据中心之间可以形成互联关系，为企业提供高可用、分布式架构的IT解决方案。2.主要架构发展历程多年来的数据中心经历了独立环境-集中建设—虚拟化+多中心-云化-微服务的演化进程。小架构到大集中——传统大型数据中心IT架构形成独立环境时代2000年前后，各大型企业的IT是由分支部门或分公司独立建设，独立交付本地化服务的。分散化IT建设是一个显著的特点：每个局点都是一个局域网架构，属于小型数据中心，其中分别承担了本地化的几个业务。这就造成了一些不必要的投资和运维压力：重复的基础设施建设；重复的业务部署，但标准化不高，各地不统一；计算存储资源浪费；集中数据传输成本，各局点之间数据消费困难；各局点都需要有专业的运维人员和业务开发人员，运维成本高。插入拓扑集中建设时代大家都意识到了资源和投资的浪费，IT企业开始尝试实践数据集中化的解决方案。恰逢传输网络有了明显的速率提升，省内乃至国内数据短时差传输不再是难以企及的了，此时有众多解决方案咨询公司以集中化改造为需求，提供IT咨询、支持、实施服务。进入2005年前后，由各大运营商、央企开始，陆续完成核心业务的改造。集中化架构的业务模式特点是，核心业务后台服务部署于集中域，分支机构仅使用业务平台。集中域处理数据请求、分析数据、提供业务服务；前端业务话单仅提供数据采集和上传。集中化架构的IT架构特点是体量庞大，资源调度灵活。企业集中建设了能满足区域内的所有业务的IT设施，包括计算资源（X86服务器、小型机、大型机）、存储资源（大体量集中式存储）、网络资源（本地数通网络和异地传输网络）、中间件软件（软负载均衡、web服务、代理服务等）、数据库资源（oracle、DB2等大型数据库）插入拓扑此时，由于需要满足集中化带来的庞大计算和存储压力，企业通常曹勇小型机+FC集中存储+大型数据库的架构。这也就是我们后来所说的“IOE”——IBM小型机+EMC存储+Oracle数据库。数据安全、业务连续性需求引发的多中心架构2001年9月11日，爆发了举世震惊的9·11事件，异地容灾，业务可持续访问的概念再次被提及，并提升到一个新的高度。此前虽已有此类的概念提出，但是迫于庞大的投资和闲置资源的维护成本，企业和机构仅处于观望研究状态。随着国内数据集中的演进，核心业务和核心数据大多存在于一个大型数据中心，这就对数据安全和业务持续性提出了重大挑战，备份、容灾、双活被提上建设日程。备份原则：多种备份手段复合，热备冷备兼顾。存储快照—在集中式存储上进行快照策略配置，用于满足测试开发环境的需求，以及对人为误操作造成的逻辑错误的故障恢复。集中备份—在一个数据中心内，采用NBU等统一备份平台和软件，对数据中心内所有对象进行周期性备份，包括系统、数据库数据、数据库结构、文件系统数据等。用于面临某个资源故障造成数据破坏时的数据恢复。异地复制备份—将数据备份至异地的数据中心，有同步和异步两种模式，通常用于大面积数据破坏和数据中心级别故障的恢复。冷备份—通常指磁带库等可拆卸存储介质的备份手段。备份磁带被检测有效后存放于特殊环境保障的储存点，是数据保障的最后一道屏障。容灾和高可用原则：分级对待，分标准建设。基础业务：本地高可用重要业务：本地双活高可用核心业务：本地双活高可用+异地容灾数据中心：两地三中心，基于同城双活+异城灾备的ICT解决方案插入两地三中心拓扑后“IOE”时代——虚拟化资源池去“IOE”背景：自2013年棱镜门事件之后，我国政府已经意识到政府数据安全的重要性，也加强了政府数据安全方面的工作，有报道称，思科、IBM、谷歌、高通、英特尔、苹果、甲骨文、微软并称为美国的“八大金刚”，他们一方面与美国政府、军队保持着紧密的联系；另一方面在中国长驱直入，占据众多关键领域，导致美国情报部门通过这些设备、软件、网络获取信息，给中国的信息安全带来巨大威胁。“去IOE”与设备采购国产化、自主研发等口号挂钩，带有一定的政治色彩。如去年win8也未进入中央机关政府采购名单。在去“IOE”浪潮下，小型机、集中存储、大型核心数据库逐步退出舞台，机关和企业面临的是X86化、分布式存储、大型库拆分的改造之路。此时x86虚拟化架构（kvm、阿里ECS、vmware等）+分布式存储解决方案（CephSDS）+轻量级数据库（mysql等）+核心数据库一体机的解决方案占了较大的比例。同时业务改造也呈现出庞大的需求和紧锣密鼓的工程状态。虚拟化技术在此时进入成熟期，众多机构和企业以虚拟化为主要的IaaS层架构模式。其优势是：能够出色的协调各业务之间的资源需求，避免资源浪费；能够满足高可用集群需求，保障业务持续性；能够快速扩容、部署、回收，提升维护效率；系统硬件解耦，开源工具支持，减弱对供应厂商的依赖性；全球IT社区化，技术演进提升快。云计算热潮——基于openstack的云计算管理平台架构随着虚拟化资源池的越来越庞大，原生的管理平台已经无法纳管过多的虚拟化节点，此时需要一个管理平台来实现统一纳管、统一配置分发、统一资源计费、统一告警分析等一些列的管理功能和服务功能。且该平台必须是开放的，可维护更新的，多接口的，兼容性强的，它就是openstack。同时，在初创型和小型企业乃至IT爱好者中，有对少量计算资源的需求，或者数据库、应用软件等PaaS、SaaS层的实际需求。公有云的出现解决的这一些的需求。2010年Openstack项目成立，此后逐渐有众多IT厂商和解决方案厂商参与共同建设，形成了openstack社区。由于其开源的技术结构，在互联网、政务管理、运营商中开始实践基于openstack架构的云管理平台，用于纳管已有的虚拟化资源池，这就是我们所说的私有云。同时公有云环境在阿里、腾讯、电信等领军企业的带领下走向繁荣。Openstack是一个云管操作平台，用于编排云资源。其是由控制节点，计算节点，网络节点，存储节点四大部分组成。控制节点负责对其余节点的控制，包含虚拟机建立，迁移，网络分配，存储分配等等。计算节点负责虚拟机运行网络节点负责对外网络与内网络之间的通信存储节点负责对虚拟机的额外存储管理等等Openstack包含了众多的组件模块，来实现一系列的服务功能，最终实现对底层资源的同意调度和对外交付。模块名称提供服务功能描述HorizonDashboard提供了一个基于web的自服务门户，与OpenStack底层服务交互，诸如启动一个实例，分配IP地址以及配置访问控制NovaCompute在OpenStack环境中计算实例的生命周期管理。按需响应包括生成、调度、回收虚拟机等操作。NeutronNetworking确保为其它OpenStack服务提供网络连接即服务“Quantum”–>NeutronKeystoneIdentityManagement为其他OpenStack服务提供认证和授权服务，为所有的OpenStack服务提供一个端点目录。SwiftObjectStorage通过一个RESTful,基于HTTP的应用程序接口存储和任意检索的非结构化数据对象。它拥有高容错机制，基于数据复制和可扩展架构。它的实现并像是一个文件服务器需要挂载目录。在此种方式下，它写入对象和文件到多个硬盘中，以确保数据是在集群内跨服务器的多份复制TroveDatabaseService提供管理数据库即服务配置关系和非关系数据库引擎节点的Trove相关，同时提供Trove在Horizon中的管理面板IronicBareMetalProvisioning提供裸金属管理服务，NovaBaremetal驱动程序HeatOrchestration提供了基于模板来实现云环境中资源的初始化，依赖关系处理，部署等基本操作，也可以解决自动收缩,负载均衡等高级特性。SaharaDataProcessingService使用用户能够在Openstack平台上便于创建和管理Hadoop以及其他计算框架集群，微服务兴起——基于容器的云计算架构在openstack云管平台下，运行的业务本质没有变化，仍然是集中式的应用架构。然而市场和业务需求的变化日新月异，这就造成了后端应用系统开发部署跟不上市场需求，于是敏捷开发的概念被提出。同时业务模块之间的关联关系时有依赖性的，强耦合的，一旦某个业务模块的故障，可能造成整个业务的崩溃。此时容器技术日趋成熟，为业务解耦带来新的方向。那么怎么才能把业务部署快起来，业务依赖性弱下来？我们从业务维度找到了解决方案，将集中式的中大型业务应用拆分成多个微型服务，各个微服务可被独立部署，各个微服务之间是松耦合的。什么是微服务简单的说，微服务架构就是以业务域或业务功能为边界，将一个大而全的应用拆分为可以独立开发，独立部署，独立测试，独立运行的一组小的应用，应用之间使用轻量级通信机制互联，并且他们可以通过自动化方式部署。微服务特征单一负载小职责少，轻量级通讯，业务数据独立，技术多样性。正是因为小，所以每个微服务的逻辑相对简单，代码量也小很多，进而修复问题及修改变更会快很多；而多个微服务可以并行演进，从而可以缩短测试，部署和发布的时间；同样是因为独立，每个微服务都可以根据实际情况，单独的横向拓展；因为轻量级通讯，每个微服务才可以独立起来，贯彻高内聚低耦合的架构思想。单体服务架构图微服务架构图微服务的优点每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。微服务能够被小团队单独开发，这个小团队可以是2到5人的开发人员组成。微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。微服务能使用不同的语言开发。微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins,bamboo。微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。微服务允许你利用融合最新技术。微服务能够即时被要求扩展。微服务能部署中低端配置的服务器上。易于和第三方集成。每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。微服务的缺点运维开销及成本增加：单体服务可能只需部署至一小片应用服务区集群，而微服务架构可能变成需要构建/测试/部署/运行数十个独立的服务，并可能需要支持多种语言和环境。隐式接口及接口匹配问题：把系统分为多个协作组件后会产生新的接口，这意味着简单的交叉变化可能需要改变许多组件，并需协调一起发布。分布式系统的复杂性：作为一种分布式系统，微服务引入了复杂性和其他若干问题，例如网络延迟、容错性、消息序列化、不可靠的网络、异步机制、版本化、差异化的工作负载等，开发人员需要考虑以上的分布式系统问题。异步机制：微服务往往使用异步编程、消息与并行机制，如果应用存在跨微服务的事务性处理，其实现机制会变得复杂化。可测性的挑战：在动态环境下服务间的交互会产生非常微妙的行为，难以可视化及全面测试。微服务的IT解决方案各个微服务运行的环境就是容器。我们通过容器管理平台对容器进行编排，来实现服务的负载均衡和高可用，来优化服务间的关联关系。目前的主流容器引擎是docker，容器管理平台中kunbernetes则独树一帜。由于Kubernetes本身就是微服务架构，而且相较更加适合微服务和DevOps的设计，目前主流的解决方案为X86服务器（+VM虚拟机）+Doker+Kunbernetes的架构，我们将在下文进行展开论述。从虚拟化到容器云架构物理机、虚拟机、容器的演化物理机->虚拟机：以前构建应用程序时使用的是宿主操作系统提供的资源，在部署应用程序时也使用了相同的模式。但如果想扩展应用程序可能需要另一台硬件服务器。而随着数量不断增加，成本和其他资源（如硬件和能源消耗）也会随之增加。随着基础设施的不断增加、硬件资源使用效率低、操作系统复杂多样这些问题促成了硬件虚拟化的发展，于是虚拟机（VM）出现了，我们通过虚拟机来优化IT基础设施。虚拟机具有自己的客户操作系统，运行在单个物理机或宿主操作系统中。我们因此能够运行多个应用程序，而无需安装大量物理机。虚拟机->容器：宿主操作系统可以确保在不同虚拟机之间进行系统性的资源分配和负载均衡。虚拟机降低了软件维护的难度和成本，不过仍然可以进一步优化。例如，并非所有的应用程序在客户操作系统环境中都会按预期运行。此外，即使是运行简单的进程，客户操作系统也需要大量资源。这些问题促成了下一个创新：容器化。与特定于操作系统的虚拟机不同，容器特定于应用程序，因为更加轻量级。此外，虚拟机可以运行多个进程，而容器作为单个进程运行。虚拟化Vs容器云虚拟机是什么虚拟机是物理机的抽象，其中每个VM都有自己的客户操作系统。这意味着初始化每个虚拟机需要创建物理机的虚拟抽象层，然后设置完整的OS启动。因此，就存储，RAM和CPU而言，每个VM将消耗大量系统资源。PhysicalHardware：基础硬件，包括CPU、内存、磁盘、IO设备等。Hypervisor：虚拟化技术的核心,负责虚拟化硬件设备，分配资源，并加载所有虚拟机的客户操作系统PhysicalHardware：基础硬件，包括CPU、内存、磁盘、IO设备等。Hypervisor：虚拟化技术的核心,负责虚拟化硬件设备，分配资源，并加载所有虚拟机的客户操作系统VirtualHardware：由Hypervisor虚拟出来的硬件设备，提供给虚拟机使用，对于虚拟机而言它就是真实的物理设备VirtualMachines：根据虚拟出来的设备创建的逻辑计算机，相互独立的OS和应用容器是什么容器是英文单词Container的直译。LinuxContainer它是一种内核轻量级的操作系统层虚拟化技术。LinuxContainer主要由Namespace和Cgroup两大机制来保证实现。容器是应用层的抽象，它将代码和依赖关系打包在一起。多个容器可以在同一台机器上运行，并与其他容器共享操作系统内核，每个容器在用户空间中作为独立进程运行，相互之间不会有任何接口（类似iPhone的app）。容器占用的空间比VM少（容器镜像的大小通常为几十MB），可以处理更多的应用程序，并且需要更少的硬件资源。Infrastructure：基础硬件设备OperationgSystem：操作系统DockerEngine：使用Docker的组件和服务构建和运行容器，包括Dockerdaemon、CLI和RESTAPI等Bins/Libs:各种依赖系统文件以及库文件，应用的所有依赖都打包在Docker镜像中APP：应用的源代码与它的依赖都打包在Docker镜像中容器技术主要有4个特点：极其轻量：只打包了必要的Bin/Lib；秒级部署：根据镜像的不同，容器的部署大概在毫秒与秒之间（比虚拟机强很多）；易于移植：一次构建，随处部署；弹性伸缩：Kubernetes、Swam、Mesos这类开源、方便、好使的容器管理平台有着非常强大的弹性管理能力。虚拟机vs容器容器和虚拟机具有类似的资源隔离和分配优势，但功能不同，因为容器是虚拟化操作系统而不是虚拟化硬件。相对虚拟机而言，容器不携带操作系统，只包含应用相关的依赖，共享操作系统的内核，直接运行在物理设备上，体积更小，更便携高效，启动速度更快。Docker的理念是隔离单个应用程序，而不是整个系统，还是运行在同一个系统上。而VM则是整个系统的之间的隔离，所以相对来说Docker的隔离性要差一点。优点：同样都是提高资源的使用率，docker相对虚拟机来说，体积更小，更便携高效，启动速度更快，并且迁移更方便，容器内有完整的应用相关的环境和依赖。缺点:隔离性较差，容器共享内核，如果需要调整内核参数可能会影响到当前运行的所有容器，虚拟机则是独立运行的。集中式vs分布式集中式部署的问题：依赖服务器环境，需要各服务器资源统一。无法充分利用服务器等资源，使用率一般仅能达到70%。无法或很难做到容灾恢复。需要人工进行服务扩容，修改服务配置。服务资源散乱(域名，服务器，负载，数据库)，无法做集中管理。时间消耗较多，增加运维成本。需要借助第三方工具进行资源监控，较为麻烦。需要对开发、测试、生产环境进行区别管理。分布式部署的好处：增大了系统的容量，可以将分布在各处的资源综合利用。而这种利用对用户而言是透明的；可以将负载由单个节点转移到多个，从而提高效率；分布式技术可以避免由于单个节点失效而使整个系统崩溃的危险，加强了系统的可用性；使系统模块化，可以提高模块的重用度，同时系统的扩展性也更高了；提高了开发和发布速度，因为软件服务模块被拆分，开发和发布都可以并行。Doker和Kunbernetes什么是DokerDocker是PaaS提供商dotCloud开源的高级容器引擎，Docker自2013年以来日益热门，至今已经是业界主要选择。Docker快速敏捷（启动、停止都是以秒或毫秒为单位的），隔离轻量级（不添加额外的操作系统），这些实际上是Linux内核提供的能力，Docker是沿用了这些特性，Docker最大的创新点在于Docker镜像的设计，下面是张Docker镜像的层次图，分层的文件系统，一层层地搭建出一个完整的容器运行环境。一个docker镜像由多个可读的镜像层组成，然后运行的容器会在这个docker的镜像上面多加一层可写的容器层，任何的对文件的更改都只存在此容器层。因此任何对容器的操作均不会影响到镜像。这样一来，我们可以像乐高玩具一样搭建各式各样的镜像，同时Docker提供了一整套镜像存储方案（DockerRegistry），可以非常方便地获取想要的镜像，然后快速地启动运行，而不必像以前那样安装各种麻烦的软件依赖。Docker解决了应用的发布、构建和运行，创建了很多想象空间，所以基于Docker衍生出了很多新的解决方案，特别是PaaS容器管理平台，这些PaaS平台更加灵活，更加适应企业，Kubernetes是其中最具代表性的一员。什么是KubernetesKubernetes一个用于容器集群的自动化部署、扩容以及运维的开源平台。通过Kubernetes,你可以快速有效地响应用户需求;快速而有预期地部署你的应用;极速地扩展你的应用;无缝对接新应用功能;节省资源，优化硬件资源的使用。为容器编排管理提供了完整的开源方案。Kubernetes的特点：网络模型kubernetes采用了三层网络模型，分为PodIP,ClusterIP,NodeIP。用简单的话来说，kubernetes在内部使用自己的网络进行通讯，这样做一个最直接的好处是我们不用再担心端口冲突的问题。对象在kubernetes中，万物皆对象。路由(Ingress)、服务(Service)、部署(Deployment)、存储(Storage/PV/PVC)、容器(Pod)、角色(Role)、账户(Accoutn)、配置(ConfigMap)等等。通过管理这些对象来管理整个kubernetes集群。声名式管理Kubernetes不在使用命令式语言，转为采用声名式进行资源管理。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（CVI）和网络（CNI）的管理；kube-proxy负责为Service提供cluster内部的服务发现和负载均衡；kube-dns负责为整个集群提供DNS服务，通过Service名称访问相应的服务基于kubernetes的容器云平台容器云平台功能介绍容器云平台，是一个基于docker容器，借助Kubernetes进行容器编排调度，提高资源利用率，并通过自研系统实现业务划分、应用操作、弹性扩缩、实例自愈、服务监控等功能的Paas容器云平台。借助容器云平台，租户无需登录后端实例主机可以进行应用发布，应用暂停、启动、重启、参数修改，代码包下载等操作。并且配置健康检测之后，平台可以直观反应出应用各实例的运行状态。同时，容器云平台也提供性能监控图线，让业务维护人员更加方便的查看和分析业务的实时运行情况。容器云平台是为整个数据中心提供分布式调度与协调功能，实现数据中心级弹性伸缩能力的软件堆栈，它将所有数据中心的资源当做一台计算机来调度。容器云平台提供网页界面和CLI，实现资源自动化管理、进程调度、内部进程通讯、简化分布式服务的安装和管理，方便对集群和其中的服务远程地管理和监控，使企业像使用一台主机一样使用分布式数据中心的多个集群资源，进行应用的创建、发布和资源的弹性扩容与缩容。容器云架构解析功能模块架构系统环境：搭建在Linux基础上，拥有企业级的安全性、稳定性和可靠性容器API：Docker编排管理：Kubernetes容器云平台核心功能树管理平台：定制自主开发，运维和开发的统一入口Dashboard

主机性能展示、容器性能展示、应用性能展示、集成指标展示、事件指标展示等监控告警模块

监控数据采集、日志管理、告警管理和事件管理编排调度模块

基于CPU使用率、内存使用率、服务并发数、响应时间等容量数据，通过定制的调度算法实现服务的自动弹性扩缩容和迁移。日志中心

采用Elasticsearch、Logstash、Graylog构建，实现对容器日志的统一存储及检索资源管理模块

及时发现容器云内的资源、服务的变更，动态实现配置中心数据实时更新，为平台调度提供数据支持。服务目录管理、规则管理、CMDB信息安全管理

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

镜像构建、集成测试、流程管理和上线管理技术架构：开发人员上传代码到git或SVN上，jenkins会自动发现代码更新并构建为docker镜像包，上传到镜像仓库，同时把版本信息同步到容器管理平台；应用管理用户通过容器管理平台手动或者自动的方式发布更新后的版本，由kubernetes的master节点调度相应容器到最优的node节点中，被调度的node节点收到任务后，由node节点中的kubelet组件启动相应的容器；外部用户访问业务时通过我们的硬负载均衡器（array或者F5）做代理，路由到NODE节点，在由kubernetes的proxy组件作为为软负载到达最终要访问的容器上，保证业务的持续可用，避免了容器随机漂移，IP地址变化的问题容器云的业务场景和建设方法适用的业务场景容器云平台支持各类应用（包括前端无状态、前端有状态应用和后台进程类系统）的快速集成上云。无状态的应用（所谓无状态指的是应用实例中无session信息或者无特定的配置信息）；（强烈推荐）有状态的应用：前端类WEB应用，依然需要会话保持等负载均衡策略，session、共享文件等存放在本地。后台进程类系统：后台进程类应用，进程服务间的调用通过配置中心的方式实现。目前适合上云的应用类型：纯java应用、tomcat应用、weblogic应用、nginx、php、apache、python类应用。应用容器化改造过程POC测试通常我们尝试做业务改造前，要进行POC测试。我们建议挑选应用结构分布式、无状态；业务类型面向互联网，访问集中，突发量大，业务更新快的。注：无状态应用意思是在应用的访问中没有必然的上下文关系，即这个应用不会保存任何信息，当前会话访问的服务器如果宕机不会影响任何应用以及下一次的访问一般对于有状态的应用的做法是让sessionid保存在客户端cookies，通过redis内存数据库保存会话状态信息达到即使每次访问请求的不是同一个web服务器也不会需要用户重新登录等操作。应用容器化改造过程(tomcat)应用容器化主要改造点热点数据缓存建议应用在设计时将热点数据存放到缓存服务器（如Redis、Memcached）中，在启动时避免执行加载缓存动作，提高应用系统启动速度。无状态化改造建议应用开发设计时将用户的会话信息保存到缓存服务器（如Redis、Memcached）中，根据用户的唯一标识session_id来对缓存服务器进行存取用户的会话信息，会话信息与应用实例分离，实现应用无状态化。定时任务与应用分离建议将定时任务与应用分开，不要封装到一个应用包中。数据库连接池设置如果连接池的初始值设置过大会造成数据库无法及时响应大量并发连接而导致数据异常，建议初始值设置不宜太大。不要在容器中存储数据容器是一次性的，当容器被停止、销毁或替换时，应用在容器中存储的数据同样会被销毁。不要依赖IP地址容器IP是不固定的，如果应用或微服务需要与其他容器通讯，可以选择更合适的方式与其他容器进行通讯。容器云平台集成方法论调研及需求分析了解系统现状明确业务影响范围理解运营现状风险评估需求分析平台集成规划与设计平台架构设计平台资源规划业务系统部署规划系统割接规划系统演进规划平台集成实施与测试平台部署平台能力测试配合应用改造联调测试割接、上线平台优化及维护平台监控平台性能分析评估平台优化调整平台维护容器云平台的应用发布发布流程：业务提供符合上云标准的应用代码包；选择容器云平台提供的基础镜像及中间件版本；租户通过平台发布，自动创建业务镜像，通过发布业务镜像后替换当前镜像，完成业务的发布或滚动升级；某运营商容器云管平台的应用和运维实例近年来，**移动一直致力于网管支撑系统能力中心化改造，以公司大IT中台战略为背景，推进业务中台O域支撑能力的建设，实现架构的云化、微服务化、中心化。8月7日，**移动云计算支撑中心和网管中心共同协作，推进性能中心业务实现了异构双平面的部署架构，至此浙江首个OSS4.0系统在容器云平台ARM架构和X86架构下正式商用落地。基于ARM的容器云平台架构相对于X86架构，ARM架构下的计算平台能够使用精简指令和纵核架构带来更强的整体性能、单核面积小可以取得较高的能耗比、拥有开放架构和灵活的IP授权机制容易实现自主可控；在ARM架构授权上，通过优化分支预测算法、提升运算单元数量、改进内存子系统架构等一系列微架构设计，大幅提高处理器核性能。本次系统上线硬件采用了华为Taishan系列2280V2（2个鲲鹏920处理器，64核，2.6Ghz）均衡型ARM服务器，OS选用CentOS7.6.1810-aarch64位操作系统，中间件k8s版本选用1.13.5，借助鲲鹏ARM处理器整机方式的对外提供服务，实现容器云管理平台对X86和ARM架构的同时纳管，支持IT系统国产化演进。OSS4.0及性能中心介绍面向OSS4.0架构，**移动启动了网管能力中心化改造，并将微服务平台管控延伸到了O域。启动了性能中心和编排中心的建设，其中性能中心业务系统为满足集团四轮驱动业务全覆盖需求，围绕移动业务、家庭业务、政企业务和新业务的设备管理、业务管理和流程管理展开，主要包括：移动业务子中心，无线网优子中心，有线业务子中心。为充分验证ARM架构下服务的可用性，本次ARM商用选用性能中心的家客业务的3个应用模块和5个能力模块做功能调测。业务改造适配上云为配合性能中心业务的迁移上线，**移动云计算支撑中心容器云平台对平台适配性、引擎调度、基础镜像等方面进行了改造。容器云平台适配性改造容器云管理平台具备统一管理“多”运行平面的能力，因此可在不影响现有x86运行平面承载业务的基础上增加一个ARM运行平面，借助容器云管理平台的快速扩展能力，纳管ARM运行平面，使平台应用实例在异构双平面平滑切换调度引擎和基础镜像改造**移动云计算支撑中心容器云平台采用K8S开源调度引擎，介于ARM服务器指令集不同，需要对K8S组件以及docker等组件进行ARM服务器集群适配部署集成。基础镜像中包含了应用运行的依赖环境。由于x86和ARM的指令集的差异，需要重新在ARM服务器上通过Docker