<h2>市场变局</h2>    <p>近年来，传统电信运营商正迎来一个最具挑战的时代。曾为电信运营商带来高利润收益的业务规模正不断缩水；曾以引为傲的管理模式、业务推广模式也渐渐成为运营商变革的核心。外有OTT厂商入侵，内有虚拟运营商竞争，随着一个业务应用上线时分秒必争来满足不同群体需求以此快速占领市场的新时代的到来，传统运营体系已然很难匹配这一市场变化，运营体系重构也必将重建。</p>    <p>语音业务逐渐被数据业务所代替。运营商的网络从90%以上都是语音业务，到今天变成了80%的业务被数据所主宰。但在这一过程中，运营商尚未建立行之有效的盈利模式;为运营商带来巨大利润的语音业务正从收费高的语音通道转向低价的数据通道，如微信等。运营商被“管道化”的趋势日益凸显。</p>    <p>语音为王的时代，三大运营商的竞争更多来自内部。移动互联网时代，运营商需要面对来自互联网厂商日益激烈的竞争。话音时代，运营商长期在围墙之内，进入移动互联时代，围墙一下子没有了，运营商如何直面和适应激烈的竞争环境是个全新的挑战。</p>    <p>此外，云计算和大数据时代来临， <strong>运营商的传统核心能力越来越边缘化</strong> 。目前，从云计算、大数据获得的收益仅占到中国运营商不到1%的收入，远远低于外国同行。这与中国运营商重电信而轻IT不无关系。以网络为主导的运营商内部存在着大量优秀的电信人才，但优秀的IT技术人才却是稀缺资源。导致运营商的IT系统仍局限于支撑功能的定位，无法为处在激烈的竞争环境中的运营商提供有效的转型战略支持。</p>    <p>行业趋势</p>    <p>电信公司在技术领域是一个保守和激进的综合体，在互联网巨头出现之前，电话通信交换网络及其计费系统已经承担了最大的任务量。电信公司对网络技术不断投入，以确保整个网络的高可用。这其实占据了大量的资金，并产生了许多闲置——低利用率的计算和存储资源，最终带来了整个运营的低效率。</p>    <p>我们认为，未来电信行业必然是一个IT、CT融合，电信运营商互联网化的趋势，IT所占比重会越来越大，电信行业的盈利模式也会从传统的提供通道到提供IT资源、提供服务的方向转变。近几年随着大数据、云计算、容器化、微服务、平台战略等新技术和新概念的层出不穷和快速发展，在业务支撑、架构能力、平台扩展性等方面对旧有的烟囱式建设的业务支撑系统提出了巨大的挑战。因此对现有业务和设备进行容器化改造，则成为了一个必然的选择。</p>    <h2>容器化的优势</h2>    <p>容器技术作为目前一项炙手可热的新技术，具有以下优势：</p>    <ul>     <li>极其轻量级的虚拟化技术，大大提高IT资源的利用率；</li>     <li>标准化的打包、封装、搬运机制，有效提高开发运维效率，降低成本；</li>     <li>秒级启动速度，保障业务的稳定性与高可用性；</li>     <li>类似于积木的分层机制，提供灵活组合微服务；</li>     <li>简化开发版本管理。</li>    </ul>    <p><img src="https://simg.open-open.com/show/770b51564c0612667bf275a777480178.jpg"></p>    <p>关于微服务</p>    <p>另外一个不得不提的概念是微服务。微服务架构是一种特定的软件应用程序设计方式——将大型软件拆分为多个独立可部署服务组合而成的套件方案。虽然这种架构风格的确切定义还未统一，但并不妨碍其在众多企业的实际应用中被实践，并体现出了具备通用特征的业务功能、自动化部署、端点智能化以及对语言与数据的离散化控制能力。</p>    <p>许多如Amazon、eBay、NetFlix等公司都采用微服务结构模式，都在尝试改进那些需要频繁更新的，通过网络提供到用户的PC、平板和智能手机上的应用程序和服务的持续交付，将应用分解为小的、互相连接的微服务，而不是开发一个巨大的单体式的应用。一个微服务一般完成某个特定的功能，比如下单管理、客户管理等等，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时每一个实例可能是一个云VM或者是Docker容器。这种微服务架构模式深刻影响了应用和数据库之间的关系，不像传统多个服务共享一个数据库，微服务架构每个服务都可能有自己的数据库。</p>    <p>Docker 作为一种开源的应用容器引擎，帮助开发者将他们的应用以及依赖打包到一个可移植的容器中，便于应用的部署和扩展。而随之产生的微容器概念和微服务正好相辅相成，通过 Docker 封装的应用可以轻松运行在以扩容能力见长的云计算平台上。</p>    <p>围绕着云托管环境的如此多的应用程序和服务部署活动，微服务架构已经深度依赖于容器化技术的使用。容器将微服务进程和应用程序隔离到更小的实例里，这些实例仅仅使用虚拟化了的操作系统，而不是整个虚拟机以及VM所包含的整个抽象硬件资源。</p>    <p>微服务不是Docker，但Docker天然是为实现微服务而存在，利用Docker技术可以很方便的对宿主机资源进行隔离、划分，同时因Docker本身极其轻量化的特点，可以做到宿主机的高密度、高可用性、高弹性的应用，从而做到IT资源利用价值的最大化。</p>    <h2>电信企业容器化改造的几点考量</h2>    <p>结合行业经验，我们认为电信企业容器化改造需要考虑的因素包括：</p>    <ol>     <li><strong>业务层面</strong> ：因运营商对业务的稳定性和连续性有比较高的要求，故容器化的演进路径必然是从边缘业务到核心业务，从简单应用到复杂应用，具体到业务，首先可以考虑在Web前端进行容器化迁移，第一步选择某些相对独立的，不涉及BOSS系统的模块，如网上商城等，第二步逐渐切入到一些涉及用户数据的非核心业务如积分兑换等，最后迁移与用户计费直接强相关的业务，如业务套餐办理等。</li>     <li><strong>技术层面</strong> ：目前原生Docker在服务发现、负载均衡、容器生命周期管理、容器间网络、存储等方面还存在诸多的不足，因此目前有许多第三方厂家提供的开源解决方案和商业化版本，如Google的Kubenetes、Apache的MESOS、Rancher等，各家方案各具特色，难分高下，当然仅从容器编排引擎的角度来看，Rancher可以兼容Kubenetes、MESOS和Docker SWARM着几种主流的编排引擎。是固定技术体系框架，还是选择灵活兼容的模式，是需要慎重考虑的因素之一。</li>     <li><strong>兼顾到成本效益</strong> ：综合考虑容器化付出的成本代价与未来收益之间的平衡。传统的短信、彩铃以及客服中心业务因本身业务在萎缩，因此不太建议进行容器化。</li>     <li>还要考虑 <strong>现有硬件的负载能力</strong> 问题，容器化并非包治百病的良药，某些对并发吞吐量要求更高的业务，直接运行在裸机上，通过系统调优提高性能，容器化未必是最好的选择。</li>    </ol>    <p><img src="https://simg.open-open.com/show/9f2ca1b917b3af13c435b2725dc9d937.jpg"></p>    <h2>容器化过程中的注意事项</h2>    <p>运营商传统业务网络经过多年建设运营，业务模式涵盖了交易、计费、服务等各种核心业务，系统功能各异复杂度高，并且多个厂商多种系统并存，这些成为容器化迁移的一大障碍。摸清这些系统之间的架构关系，避开不必要的坑，是容器化之前就需要做的工作。</p>    <p>在底层架构考虑方面主要需要考虑操作系统、数据库等平台软件之间的兼容性问题，另外需要考虑收费软件厂商的支持力度、License管理政策是否允许容器迁移。</p>    <p>虽然Docker以及微服务看起来很美，但是要真正的实施落地，除需要足够的人才技术储备，还对运维团队的自动化流程也提出了更高的要求和挑战。容器化改造之后，一台宿主机上运行的容器可以成千上万，如何对这些容器的故障进行维护，需要对原有的运维流程和团队进行更新升级以适应新的业务情况。所以选择专业的产品化的容器技术厂商不失为探索过程中的有力保障。</p>    <h2>答疑环节</h2>    <p>问：电信行业的容器化与其他行业有何区别？</p>    <p>张鑫：电信行业相对其他行业，IT信息化程度较高，在技术领域是一个保守和激进的综合体，在互联网巨头出现之前，电话通信交换网络及其计费系统已经承担了最大的任务量，但近年来，曾为电信运营商带来高利润收益的业务规模正不断缩水；曾以引为傲的管理模式、业务推广模式也渐渐成为运营商变革的核心。</p>    <p>外有OTT厂商入侵，内有虚拟运营商竞争，语音业务逐渐被数据业务所代替。运营商的网络从90%以上都是语音业务，到今天，80%的业务被数据所主宰。但在这一过程中，运营商尚未建立行之有效的盈利模式;为运营商带来巨大利润的语音业务正从收费高的语音通道转向低价的数据通道，如微信等。运营商被“管道化”的趋势日益凸显。</p>    <p>传统运营商长期在围墙之内，进入云计算、大数据、移动互联时代，围墙一下子没有了，运营商如何直面和适应激烈的竞争环境是个全新的挑战。</p>    <p>问：Rancher与同类容器管理平台相比有何优势？</p>    <p>张鑫：Rancher的解决方案设计时就考虑了同时支持虚拟机和容器，而这种实现方式在Google被验证过，并进行了大规模部署。从2015年4月开始，在 RancherVM项目中已经尝试了这个方案，并从很多用户那边得到了非常好的反馈。在容器中运行虚拟机的好处是可以使用相同的工具来同时管理虚拟机和容器。事实上由于虚拟机和容器的行为方式非常类似，Rancher 为Docker容器所开发的Rancher CLI 命令行和UI图形界面完全可以无缝地适用于虚拟机。</p>    <p>另一方面通过使用 RancherOS做为融合基础架构平台的基础操作系统。RancherOS的内核被编译成可以完美支持各种虚拟化平台。</p>    <p>问：Rancher是基于哪些技术实现，与k8s有何关系，相比其他容器集群管理技术有哪些优缺点？</p>    <p>张鑫：Rancher是基于Cattle调度编排框架，而K8S是一个Docker容器的编排系统，它使用label和pod的概念来将容器换分为逻辑单元。Pods是同地协作（co-located）容器的集合，这些容器被共同部署和调度，形成了一个服务，这是K8S和其他框架的主要区别。相比于基于相似度的容器调度方式（就像Swarm和Mesos），这个方法简化了对集群的管理。</p>    <p>由于Swarm的原生API，基本上实现了各家编排引擎的核心功能，尤其是内置到Docker Engine中的作用是巨大的。在集群维护和节点管理方面Swarm的确天生就比较优秀，毕竟是采纳百家之长，但是真正落到应用管理和服务编排方面，Swarm仍有一些路需要走，而Cattle与Rancher其他组件的融合已经达到了“开箱即用”的水准。</p>    <p>此外，Rancher与其他同类容器平台相比，部署比较简单，用户无需了解Mesos、K8S的架构和细节，Rancher可以快速方便的一键部署和升级；</p>    <p>Rancher和底层基础架构集成良好，如Rancher部署的K8S默认和Rancher的overlay网络，Rancher-dns，Rancher的负载均衡都进行了集成，方便用户使用；Rancher-catalog应用编排层面的集成也较好。</p>    <p>问：电信行业使用容器怎么做好安全？</p>    <p>张鑫：容器的确也存在不足，如无热迁移，网络隔离性、安全性支持比较薄弱，Docker发布libnetwork增强网络特性，很多项目也在致力改善容器网络。电信行业容器化的演进路径必然是从边缘业务到核心业务，从简单应用到复杂应用。</p>    <p>问：电信行业使用容器的自动化测试有什么实践？</p>    <p>张鑫：目前一些地方运营商正在做进一步POC测试和业务部署，相信很快从集团和地方层面就会有实际应用。</p>    <p>问：电信业务最终落地到Docker上的是什么业务？相对应的规模是怎样？</p>    <p>张鑫：因运营商对业务的稳定性和连续性有比较高的要求，故容器化的演进路径必然是从边缘业务到核心业务，从简单应用到复杂应用。具体到业务，首先可以考虑在Web前端进行容器化迁移，第一步选择某些相对独立的、不涉及BOSS系统的模块，如网上商城等；第二步逐渐切入到一些涉及用户数据的非核心业务如积分兑换等；最后迁移与用户计费直接强相关的业务。</p>    <p>问：电信行业一直在提NFV，容器化能够很好的支持NFV么，有没有相关的应用实例？</p>    <p>张鑫：NFV主要还是涉及到网络虚拟化，容器里目前涉及不是很多。</p>    <p>问：这会不会限制容器技术在电信业的应用？现在各家厂商貌似都在发力NFV，一旦相应的技术方案成型，会不会使得容器化很难做到电信的数据层面？</p>    <p>张鑫：一个新技术的兴起和发展，主要还是在于新技术本身的优势特点、以及给行业客户带来的价值，有些技术可能是并存，或者是作为补充。电信行业一般还是愿意创新和敢于尝试新技术，所以应该还是能做到电信数据层面的，当然也要看推进的方法。</p>    <p>问：容器化改造目前能够达到什么程度，稳定性怎么样？会不会容易与一些方面发生冲突，有没有一些更好的方法将bug控制在很小的范围？系统如果遭到攻击那么会不会导致数据丢失，有相关的安全措施吗，比如定制版本的安全软件？</p>    <p>张鑫：容器化改造目前还是提升客户系统效率，降低硬件采购成本，这一点对客户带来的价值还是很大的。由于是开源平台，参与贡献者较多，版本更新较快，一些bug也会很快解决。</p>    <p>容器只是一组进程，其隔离性不如虚拟机好，如果主机意外掉电有可能引起数据丢失，但是任何安全都是相对的，攻击的类型也有很多，不能一概而论。</p>    <p>问：运营商有没有在电信业务上使用容器的案例？电信业务的核心是管道、数据搬运，所以转发性能非常关键，容器技术在这方面有优势吗？</p>    <p>张鑫：目前主要是在poc阶段，很快就有案例。移动、电信都在推进，具体内容就不方便说了。转发性能应该是针对路由交换，容器强调的是并发性。</p>    <p> </p>    <p>来自：http://www.infoq.com/cn/articles/container-transformation-in-telecommunication-industry</p>    <p> </p>