电信BS架构系统迁移及云化研究

李书生，段 勇，石屹嵘，叶宇航

（中国电信股份有限公司上海研究院 上海200122）

1 引言

1.1 业界云计算的发展背景

云计算是近年来IT领域最为热门的话题，被认为是继微型计算机、互联网后的第3次IT革命。云计算的本质是通过虚拟化、分布式处理、在线软件等技术将数据中心的计算、存储、网络等基础资源以及其上的开发平台、软件等形成可运营、可管理的服务，通过网络的形式提供给用户，实现按需使用和按使用量付费。云计算可分为IaaS(infrastructure as a service，基础设施即服务)、PaaS(platform as a service，平台即服务)、SaaS(software as a service，软件即服务)3种服务模式。简而言之，IaaS是将计算、存储、网络等基础IT资源通过虚拟化技术以服务的形式提供给用户；PaaS提供的是满足特定需求的平台能力，屏蔽了底层复杂的操作，使得开发人员可以快速开发出基于平台的应用；类似的，SaaS通过在线软件技术将应用软件以服务的形式提供给用户[1]。

企业通过实施云计算，可以提高其IT系统服务质量和减少企业IT运营成本，云计算技术蕴含巨大的商机。国内外各大IT厂商都大力投入云计算，包括VMware、Microsoft、Amazon、Cisco、Citrix以及国内的华为、世纪互联、腾讯、盛大等。国内各大运营商也大力投入云计算，用其改进内部IT系统的服务质量和成本以及对外提供IDC、云存储等多项服务。

1.2 BS架构系统现状

随着移动通信技术和移动互联网的快速发展，移动用户数量也随之快速增长。为了给用户提供更好的服务保障，各大电信运营商都建设了大量的BS架构支撑系统，这些系统为提升公司的经营和管理水平发挥了巨大的作用。但由于这些系统都是“烟囱式”独立建设的，甚至部分系统是应急建设的，随着业务的发展和技术的进步，存在的诸多问题日益明显。

·传统BS架构系统“烟囱式”建设，各系统之间硬件资源孤立，无法动态调配与共享，资源浪费与紧缺现象并存，分配严重不合理。

·部分早期BS架构系统Web和应用服务器仍运行在小型机上，硬件资源分配不合理。

·系统硬件资源长期处于高负载运行状态，电力资源浪费严重。

·新系统上线部署周期长，无法快速响应需求。

·系统运维成本不断提升，对运维人员要求越来越高。

2 系统迁移方法和关键问题研究

2.1 技术可行性

从软件技术架构角度看，BS架构系统的Web和应用服务器基本部署在BEA、WAS等商业中间件上，少量BS架构系统为商业套件。对于商业套件的系统，可根据具体厂商的实际情况，制定专用的PC服务器迁移方案。对于大量中间件上的BS架构系统，由于中间件技术具有平台无关性，即其上运行的业务系统与底层运行的操作系统和硬件服务器无关，迁移至PC服务器时寻找合适的中间件版本，并将应用部署于新的中间件平台上即可，应用基本不用改动。总的来看，BS架构系统从小型机迁移至PC服务器在技术方面是可行的。

云计算技术分为IaaS、PaaS、SaaS 3个层次，针对BS架构系统的具体特性，研究发现IaaS和PaaS技术在电信BS架构系统中已具备实施条件，SaaS技术的具体实施有待进一步的探索。IaaS可以通过服务器端代理模式或者云管理平台模式实现，PaaS可以通过JavaEE Cloud实现对中间件平台能力的统一管理。

2.2 迁移实施方法论

BS架构系统的Web和应用服务器层从小型机迁移至PC服务器时，可参照数据收集与评估、设计与测试、实施迁移、运维与优化4阶段的实施方法论进行迁移，各阶段的关系如图1所示，其中数据的收集与评估最为重要，每阶段的具体工作描述如下。

（1）数据收集与评估

数据收集和评估阶段是实施过程中最重要的一个阶段，依次包括以下几方面的内容：建立业务目标、收集和分析环境数据、风险评估、创建应用迁移路线图、运维规划。

其中，收集和分析环境数据主要包括收集Unix机器的CPU、内存、磁盘和网络的使用情况。风险评估时，主要从技术和组织两方面进行评估，包括可能引起的功能变化、重新编码以及建立应用迁移过程中的实验站点等，将影响/风险控制在可接受范围内。制定应用迁移线路图，需要将潜在迁移目标分类并划分优先级来制定，包括评估迁移带来的商业价值和开销、评估资源利用率、评估潜在风险（运维转型、技术转型）、应用依赖关系、评估迁移影响（应用可承受什么级别的离线窗口）。运维规划主要包括现有管理流程（变更、问题、事件、生命期）、现有管理系统（监控、自动化创建、安全、身份）、现有身份和访问控制以及安全事件响应流程、部门内沟通和问题升级流程。

（2）设计与测试

在系统迁移前，应当先搭建Linux开发和测试环境，做好迁移设计和系统测试工作，以确保迁移后的系统能可靠运行。首先对系统代码进行分析，确定是否存在必要的代码修改等，设计详细的迁移方案，之后再进行开发和测试工作，BS架构系统迁移测试工作尤为重要，测试应包括功能测试、性能测试、压力测试和疲劳测试以及高可用性测试。

（3）实施迁移

该阶段完成应用迁移到生产环境Linux服务器，依次包括以下几方面的工作内容：根据性能测试调整Linux服务器配置、迁移应用到生产环境Linux服务器、完成割接前验证测试和正式割接上线。

（4）运维与优化

该阶段依次包括以下几方面的工作内容：与现有管理流程集成（变更、问题、事件、生命期）、与现有管理系统集成（监控、自动化创建、安全、身份）、收集资源利用率数据、检查服务级别遵从性、建立新基准（调整监控工具告警阈值）、培训运维人员、更新运维文档。

2.3 迁移相关问题及解决方案

2.3.1 如何确定硬件资源需求量

（1）问题描述

迁移后的系统运行在x86平台上，相比于迁移前的小型机环境，需要重新估算服务器CPU、内存、存储和网络带宽等硬件资源，以满足业务系统的需求。但迁移前后服务器体系结构存在差异，需要寻找合适的估算维度和方法。

（2）解决方案

迁移后CPU处理能力的需求按照TPMC值进行估算，即根据系统高峰时刻用户数、单位时间每用户处理业务数、每笔业务平均处理事务数以及每个事务应用服务器性能消耗TPMC值进行估算。需要注意的是，不同的系统，每个事务的TPMC值消耗也不一样。内存主要依据每秒并发事务数、每个应用服务器可承载的并发事务数以及每个应用服务器按照经验应该配置的内存大小进行估算。存储估算时，一般包括应用程序文件、业务服务应用程序文件、接口服务应用程序文件、日志文件等。网络带宽按照业务高峰用户数以及每个业务流程的数据量大小、每个业务流程的权重占比进行计算，若迁移时服务器机房位置未变化，则无需重新估算网络带宽。需要注意的是，对于上述计算出的硬件资源量，在实际采购时需要考虑一定的系统冗余量。

2.3.2 业务系统运行失败

（1）问题描述

迁移前应用系统中可能存在JNI调用、调用操作系统命令、用到OCI数据库驱动等，迁移后由于操作系统发生变化，原先的调用代码和调用命令失效，影响业务系统的正常运行。

（2）解决方案

由于调用的代码是平台相关性的，JNI调用同调用操作系统相关命令一样，需要针对迁移后的Linux平台重新进行开发。如果是OCI驱动，在迁移后的平台上安装Oracle客户端驱动即可。

2.3.3 部署脚本无法运行

（1）问题描述

系统迁移前，主机上一般存在自动执行的部署脚本，用于日常的应用更新和维护。迁移后，由于主机操作系统从Unix更换至Linux，部署脚本中的命令将失效，部署脚本无法运行。

（2）解决方案

由于部署脚本是依赖具体操作系统的，因此需根据迁移后的Windows或Linux系统，对比之前小型机上的脚本，重新编写同等功能的新平台脚本，并进行相应的测试。

2.3.4 系统日志如何追踪

（1）问题描述

应用系统迁移后由集中处理变成分散处理，系统日志也将分布于多台x86服务器上。需要跟踪和定位日志信息时，日志信息的搜索便变得很复杂，且部分x86服务器可能出现短暂故障，导致部分日志信息缺失，将给日志的定位带来更大的难度。需要寻找合适的办法，以管理这些分布式的日志信息，便于日后跟踪和定位。

（2）解决方案

对于迁移后的日志分散状况，建议将应用程序中日志模块剥离出来，发送到一个集中的地方进行统一管理，形成统一的日志服务，以便日后跟踪和定位日志信息。

2.3.5 配置文件如何保持一致性

（1）问题描述

应用系统中都存在一定量的配置文件，以便将一些系统变量配置在其中。迁移后，若按照之前的配置信息加载方式，由于PC服务器数量较多，在更新配置文件时，多个PC服务器之上的配置文件容易不一致，从而影响系统的运行。同时，针对多个PC进行更新，也容易出现手工操作失误，影响一致性。

（2）解决方案

对于迁移后配置文件多且分散分布的问题，建议将配置文件信息获取模块独立剥离出来进行集中存放，通过服务调用的方式来进行配置信息的获取。这种改造的好处是：更新配置文件只需要一次发布不需要分别针对不同的PC进行更新，同时也避免了操作上的疏忽带来的配置信息不一致。

3 云化部署模式研究

3.1 IaaS部署方案

3.1.1 简单代理模式部署

BS架构系统一般都通过负载均衡设备分发用户请求，因此可以对整体用户请求数、每台服务器负载状况、资源池负载信息进行截取和分析，以判断需要减少或增加新的应用服务器，实现基础IaaS弹性方案。

对于在x86物理机和虚拟化软件上部署的应用服务器，其IaaS弹性方案实现方式略有不同。物理机上部署的系统，一般通过在物理机上安装代理脚本，以实现远程服务器性能监控、负载状况感知、待机、唤醒等基础功能，再通过信息截取和控制端进行决策，以决定是否执行待机和唤醒功能。对于虚拟化软件部署的系统，由于虚拟化软件有统一的管理控制中心，因此无需在每个具体的应用服务器上安装代理，可以由控制端直接与虚拟化软件中心交互，进行远程服务器性能监控、开启和关闭虚拟机，从而实现IaaS弹性扩展方案。代理模式IaaS逻辑架构如图2所示。

3.1.2 云管理平台部署

区别于提前部署配置好应用服务器的代理模式方案，云管理平台方案则是将手工新增或减少服务器的各个步骤，固化到流程模板中，实现实时部署弹性扩展，进一步提高基础资源利用率。云管理平台解决方案一般包括资源管理、可视化部署管理、配置和流程管理、自动化部署引擎、服务监控管理5个模板。这些模块之间的关系如图3所示。

其中，各个模块包含的主要功能如下。

（1）资源管理

管理在应用服务部署中需要的所有基本单元，并且将这些基本单元之间的硬连接转换为动态连接。资源管理模块具备了以下的特性：管理所有的物理设备资源；管理和维护不同的平台和应用软件；实现物理设备资源的动态连接；管理资源的划分，包括存储空间、服务器、软件平台选择分类、网络端口和带宽等资源管理；对于可视化部署管理提供统一封装接口，实现可视化部署中资源有效性的检查。

（2）可视化部署管理

从资源管理中获取的资源可以利用可视化工具搭建需要的应用体系架构，并且该体系架构中包含了一定的部署流程和配置，部署引擎从可视化的体系架构中实现自动部署能力。因此，该模块具备了以下的特点：可以区分全省不同业务或者不同地区的特性；实现管理应用服务中各个资源模块的逻辑部署关系，并且需要从配置和流程管理模块中读取相应应用服务流程组合；提供审核部署关系、系统框架、资源使用等流程流转关系；提供对于应用软件进入资源管理模块的审核，包括可发布软件的版本管理、可发布服务的架构定义、应用服务上线的预约服务等；审核资源使用均衡性，并且可以提供服务调整的评估。

（3）配置和流程管理

提供在服务中需要涉及的流程和步骤以及对于不同业务或全省各个地区的区分配置，从而可以针对不同的配置定制出相关的部署流程；同时还可以从服务监控管理平台获得触发条件，从而定义相应的处理流程。该模块具备了以下的特点：定制不同的部署流程，并且对于流程中的各个步骤和步骤的异常提供下一个步骤的处理过程（相当于一个自动机）；可以将流程导出，提供给自动部署引擎使用，也可以提供给可视化部署管理使用，作为部署的应用逻辑；提供流程中的稽核点，并且提供稽核流程从而验证系统部署的应用逻辑；在流程可以定义部署或执行过程的并行、串行、分支和嵌套等基本流程流转功能，满足业务逻辑和部署需求；支持自动执行流程和手动流程管理的互换（类似单步跟踪能力）；支持针对不同版本的配置文件区分以及针对不同配置文件的流程对应关系管理；支持无差异化的扩展能力。

（4）自动化部署引擎

根据可以发布的部署架构和对应的流程，在约定的时间内实现对于服务的自动部署、服务的调整、补丁的分发等流程的自动化和手动执行流程，并且根据执行的结果进行流程中各个步骤的检查和监控。因此，这个执行模块应当具备以下特性：从资源池中根据部署架构找到资源；识别和执行有效的流程；执行各个步骤的状态监控；自动执行引擎可以是面向多种平台环境的集成工具。

（5）服务监控管理

提供对于业务的监控功能，并且根据监控数据和已知的业务优先级，提供触发自动化流程的资源整合或调整流程，实现从服务质量到资源分配的智能化流程。因此，该模块应当具备以下特性：对于应用服务响应时延（服务质量）的采集和定义，确定触发条件；对于触发流程的数据导入，确定触发流程；对于全系统中响应时延的鉴别，确认和定位应用服务的服务质量和服务质量关系；可拓展到CTMBOSS的全业务流程，即可以适应复杂环境而不是目前单一的应用服务环境。

3.2 PaaS部署方案

BS架构系统一般运行在BEA、WAS、TUXEDO等商业中间件平台上，因此可采用JavaEE Cloud平台对中间件平台能力进行统一管理，实现PaaS云计算。JavaEE Cloud平台包含完整的JavaEE应用基础运行环境，并基于虚拟化技术、自动化及自优化技术，为JavaEE应用提供了动态、弹性和智能化的运行环境，其逻辑架构如图4所示，各组件功能描述如下。

3.2.1 应用路由控制组件

应用路由控制组件是JavaEE Cloud环境接收客户端请求的统一接入点，该组件依据预定义的策略及运行时应用负载和JavaEE Cloud的状态，动态地控制应用请求的路由和负载分派，其主要功能包括以下部分。

（1）环境感知

应用路由控制组件可以感知到JavaEE Cloud环境中的应用相关信息，包括应用服务接口（URL）、起停状态、部署状况、支持应用运行的应用服务器实例的运行状态以及硬件资源的负载状况等，同时，该组件还可以感知应用请求的相关信息，这些信息是应用路由控制组件进行动态路由和负载分派的基础。

（2）智能路由

应用路由控制组件以感知到运行时状态信息（应用请求及应用运行状况）为基础，依据预定义的路由策略，在运行时动态决定应用请求的路由目标。路由策略可以基于应用请求及应用运行状况的相关信息进行定义。同时，智能路由还满足会话亲和原则，支持负载分派策略和流量控制策略。

（3）动态负载均衡

应用路由控制组件基于感知到JavaEE Cloud环境中应用服务器运行状况（包括CPU和内存的利用率，请求的平均响应时间等），动态计算每个应用服务器分派负载的权重，同时基于请求对应的URL，并结合会话亲和原则，路由策略和流量控制策略实现动态负载均衡。

（4）流量控制

应用路由控制组件可以基于预定义策略和运行时状况动态控制分派到JavaEE Cloud环境的应用访问流量。当出现资源竞争或服务器过载时，应用路由控制组件将基于相关策略，通过流量控制，进行有效的调节，确保应用的服务质量和可用性。

3.2.2 运行时核心组件

JavaEE Cloud运行时核心组件是Java Cloud提供服务的主体，该组件实现了具备虚拟化和动态特性的JavaEE应用运行环境，该组件提供的主要服务包括以下几种。

（1）JavaEE应用服务器基础服务

运行时核心组件提供完整的JavaEE应用基础运行环境，支持JavaEE 5标准，提供必要的应用容器服务，提供安全控制、管理监控等基础服务，并支持Web服务等开放标准，支持主流数据库。该组件应广泛支持主流的操作系统和硬件平台，并可部署于物理或逻辑服务器上。

（2）JavaEE应用服务器虚拟化服务

基于运行时核心组件构建的JavaEE Clould环境提供虚拟化的应用运行环境，用户在配置JavaEE Cloud环境时，仅需指定该环境包含的物理或逻辑服务器，而无需定义具体应用服务器实例及其固定的负载均衡权重。应用部署于该环境时，不再对应固定的物理或逻辑服务器。在运行时，JavaEE Cloud环境将依据预设策略及运行时的状态动态地决定支持应用运行的应用服务器实例数等，从而实现弹性、虚拟的运行环境，实现应用与运行环境之间的松耦合。

（3）动态计算资源调度服务

运行时核心组件可以基于运行时应用的运行状态和预定义的相关策略，通过动态控制应用服务器的启动停止实现动态调度计算资源，由此，支持应用运行的应用服务器实例数量，可在运行时动态决定，并可进行灵活调整，为计算资源共享和应用服务质量管理提供了基础。

（4）应用服务质量管理服务

运行时核心组件支持应用服务级别（包括基于性能指标和优先级的定义）的定义。运行时核心组件将依托动态计算资源调度服务，保证应用的服务质量。当运行时核心组件监控到应用的服务级别不能得到满足时，运行时核心组件将自动为该应用启动额外的应用服务器实例，保证服务质量。反之，则可以自动停止空闲应用服务器实例，以释放计算资源供其他应用使用。

（5）自动化智能运维服务

运行时核心组件支持对应用服务器实例运行状态的自动监控，并可配置系统异常状态条件以及处理策略。运行时核心组件将会基于预设条件，监控应用服务器实例的运行状态，当应用服务器实例出现异常状况时，运行时核心组件可以基于预订处理策略自动处理系统异常。自动化智能运维服务还支持不中断服务的系统运维，包括在线的应用程序版本间的无缝切换，不中断服务的中间件、操作系统和硬件的维护等。

3.2.3 管理组件

管理组件指JavaEE Cloud平台的管理和监控工具，通过该工具可定义和配置运行时核心组件和应用路由控制组件，部署并管理应用系统，并可监控各个组件及应用的运行状态。

3.3 部署模式比较

BS架构系统Web及应用层在实施云化时，可结合系统实际状况，选择3种云化方式中的一种进行实施，3种部署方案的优缺点比较见表1。

表1 3种部署方案的优缺点比较

3.3.1相关研究工作

云计算概念自提出以来，各大电信运营商和诸多高校研究机构以及IT厂商等都纷纷投入该领域，研究IaaS、PaaS和SaaS的具体实现方案和方式，包括电信运营商如何推进云计算的研究探索、云计算相关技术研究以及研究公有云能力开放平台的实现方案，具有代表性的研究工作主要有以下内容。

电信运营商主要集中于内外部的云化方案和推进方式研究，内部主要针对电信IT支撑系统和业务系统，外部主要有IDC云计算，IT支撑系统包含的系统较多。中国移动通信集团（以下简称中国移动）的涂艳丽重点对云计算核心技术（分布式并行计算）的原理进行了研究[2]，并结合移动IT支撑系统现状，提出了云计算技术在IT支撑系统中的应用思路和建设方案的方向性建议，但没有对各阶段的实现方式进行研究。中国移动的詹义通过分析IT支撑系统的现状[3]，重点研究了服务器虚拟化和存储虚拟化技术现状，探讨了在电信IT支撑系统中引入云计算的途径及带来的挑战和相应的策略。中国电信股份有限公司（以下简称中国电信）的陈捷分析了IT支撑系统引入云计算的驱动力[4]，给出了电信企业级云计算的参考技术架构及与IT支撑系统云的关系，重点阐述了基于IaaS服务的IT支撑系统应用、基于PaaS服务的IT支撑系统应用、相应的网络和终端情况，并提出了从IaaS入手，循序渐进和先实施后评估的实施原则。

国内高校一些学者的研究多数在开源软件如Hadoop、Eucalyptus等平台的基础上进行研究，与本文比较相关的工作主要有：南京理工大学的孙伟龙[5]利用开源软件Eucalyptus搭建了IaaS云计算平台，在此基础上实现了不确定度计算的Web系统，该系统使用Hadoop平台实现了不确定度的分布式计算，并通过性能测试验证了Hadoop在处理大数据集时的优势，主要面向数据处理类应用。华南理工大学的曾述青将PaaS技术应用到电信的业务交付平台(SDP)[6]，采用Web Service技术将底层服务封装，对外以接口形式发布。开发者在该Web平台上可以调用电信及非电信的业务，方便快速地满足开发人员的需求，极大地提高了业务开发的效率和灵活性。北京理工大学的肖家立[7]分析了SOA和SaaS的区别及联系，并对SOA和SaaS未来的结合发展做出了展望。

一些IT厂商研究机构和开发者，围绕如何实现共有云计算平台做了一定的研究。新浪资深架构师丛磊介绍了Sina App Engine（SAE）[8]，国内首个共有云 计算平台，SAE选择PHP作为首选的支持语言，Web开发者可以在Linux/Mac/Windows上通过SDK或者Web版在线SDK进行开发、部署、调试，团队开发时还可以进行成员协作，不同的角色将对代码、项目拥有不同的权限。南京工程学院的刘枫[9]讨论了Google云计算服务体系架构、实现机制和算法流程，给出了如何利用集成环境设计部署一个Web应用服务，并通过一个Web应用服务实例,提出了Google App Engine for Java应用程序的基本开发流程，为今后实现信息化建设的云计算应用系统提供了参考。

3.3.2 本文解决方案的特点

本文提到的2种IaaS部署方案和1种PaaS部署方案，主要针对电信运营商内部IT支撑系统中的BS架构系统，其一般运行在WAS、BEA等J2EE中间件平台上。对比上述相关研究工作，文中提到的解决方案对运营商而言，可推广性较强、风险较低、成本投入较少、实用性较强，具体包括以下几点。

对电信BS架构系统从小型机迁移至PC服务器的关键问题进行了深入研究。

以电信BS架构系统现状为出发点，研究其实现IaaS和PaaS的具体方案。对比相关研究工作，本文解决方案无需改动应用系统代码，对电信实际生产系统而言具有较好的风险控制，此外云化成本投入较少，无需重新开发代码等大量工作。

简单代理模式IaaS解决方案，不仅可以用于BS架构系统，还可用于流媒体等其他电信系统，该解决方案可以作为电信推进IaaS云计算的初级阶段，方案成本投入少且易实现，对现有系统部署无需进行任何改动，只需部署代理客户端即可。

云管理平台IaaS解决方案，给出了采用云管理平台实现BS架构系统IaaS云计算的功能架构关系，对于云计算在IT支撑系统中的大规模落地，具有较好的参考意义。

JavaEE Cloud实现的PaaS方案，特点主要在于不再以基础资源利用率等作为弹性，而以应用响应时间等作为平台资源弹性伸缩KPI指标，在更高的层次实现了PaaS方案，同时无需改动任何应用服务器代码，具有较好的可推广性，方案的成本和风险较小，对电信运营商意义较大。

本文解决方案不是以宏观层面作为切入点，而是以运营商中大量BS架构系统为着手点，研究IaaS和PaaS实际落地的具体解决方案，研究工作较细致深入。

4 演进路径及建议

电信BS架构系统迁移及云化演进策略建议如下。

（1）BS架构系统选取路径

建议先从电信MBOSS中选择业务逻辑相对简单的系统，如CRM、网上营业厅、计费/10000接口等，再逐步渗透至电信MBOSS中的BS架构，可以采用负载均衡设备水平分担的应用进行迁移，逐步实现整体BS架构系统Web及应用服务器层PC化。

（2）部署方案推进建议

应用系统从Unix机器迁移部署至PC服务器以及PC服务器部署系统实施云化时，在选择部署方式上，可以根据自身情况采用物理机或者虚拟机部署。云化方案可以直接采用JavaEE Cloud实现PaaS云，也可以先采用代理模式IaaS方案，再进一步升级至云管理平台模式。BS架构系统迁移及云化分阶段推进演进路径如图5所示。

5 迁移风险及防范

系统迁移后在系统代码、系统日志、部署脚本以及系统部署架构方面都存在一定的变化，主要的风险需要通过迁移前的测试来避免，需主要关注以下几方面。

·颗粒度细化后系统模块间的交互，通常由迁移前的本地调用转换成远程调用，需要测试其相关的服务调用是否成功。

·迁移后系统由原来统一的Web根目录分散成不同的Web根目录，因此类似JSP、JS、CSS、图片等资源调用是否正常也需要进行测试。

·系统迁移后EJB调用也需要进行分别测试通过。

·还需要考虑不同的一级域名间相互访问是否存在问题的测试。

·建议采用分阶段模块迁移方式进行，以降低迁移过程的风险。

·系统迁移过程存在一定风险，需要准备回退方案。建议通过4层交换机进行手工切换，保证迁移后的系统若在试运行过程中发现异常，可立即切换到迁移前的生产环境上。

6 结束语

通过实施BS架构系统Web和应用层迁移及云化，可以降低电信IT系统服务器拥有成本和运营成本，错峰利用服务器资源，提高服务器利用率，提升电信IT系统服务质量，增强系统可靠性，同时也是电信内部推进云计算的先行实践。BS架构系统一般包含Web层、应用层和数据库层，目前的云化方案主要针对Web和应用层，可以进一步探索数据库层的云化方案，进一步降低电信IT系统成本。从云计算层面来说，目前的方案主要是IaaS和PaaS层面的，可以进一步探索SaaS层面的实现方案，进一步提高电信云计算技术能力水平。

1 石屹嵘，段勇.云计算在电信IT领域应用初探.电信科学，2009，25(8)

2 涂艳丽.云计算及在IT支撑系统中的应用.中国通信学会第六届学术年会论文集，2009

3 詹义，段伟希，胡晓彦.云计算在电信IT支撑系统中的应用.电信科学，2011，27(10A)

4 陈捷.云计算在电信IT支撑系统应用的研究.2011年信息通信网络技术委员会年会征文，2011

5 孙伟龙.基于IaaS云计算的Web应用技术研究.南京理工大学硕士学位论文，2011

6 曾述青.基于PaaS平台电信互联网融合业务的研究.华南理工大学硕士学位论文，2011

7 肖家立.企业级应用架构研究：SOA架构融合SaaS模式.价值工程，2011（33）

8 丛磊.Sina App Engine架构—云计算时代的分布式Web服务解决方案.程序员，2010（11）

9 刘枫.基于Google云计算的Web应用与开发.电脑开发与应用，2011（5）