电信行业的容器化改造之道

本文来自东网科技与Rancher labs合资公司网澈技术有限公司资深售前主管张鑫在“细说云计算”企业上云系列上的分享。转载请先获取授权。

近年来，传统电信运营商正迎来一个最具挑战的时代。曾为电信运营商带来高利润收益的业务规模正不断缩水；曾以引为傲的管理模式、业务推广模式也渐渐成为运营商变革的核心。外有OTT厂商入侵，内有虚拟运营商竞争，随着一个业务应用上线时分秒必争来满足不同群体需求以此快速占领市场的新时代的到来，传统运营体系已然很难匹配这一市场变化，运营体系重构也必将重建。

语音业务逐渐被数据业务所代替。运营商的网络从90%以上都是语音业务，到今天，80%的业务被数据所主宰。但在这一过程中，运营商尚未建立行之有效的盈利模式;为运营商带来巨大利润的语音业务正从收费高的语音通道转向低价的数据通道，如微信等。运营商被“管道化”的趋势日益凸显。

语音为王的时代，三大运营商的竞争更多来自内部。移动互联网时代，运营商需要面对来自互联网厂商日益激烈的竞争。话音时代，运营商长期在围墙之内，进入移动互联时代，围墙一下子没有了，运营商如何直面和适应激烈的竞争环境是个全新的挑战。

此外，云计算和大数据时代来临，运营商的传统核心能力越来越边缘化。目前，从云计算、大数据获得的收益仅占到中国运营商不到1%的收入，远远低于外国同行。这与中国运营商重电信而轻IT不无关系。以网络为主导的运营商内部存在着大量优秀的电信人才，但优秀的IT技术人才却是稀缺资源。导致运营商的IT系统仍局限于支撑功能的定位，无法为处在激烈的竞争环境中的运营商提供有效的转型战略支持。

电信公司在技术领域是一个保守和激进的综合体，在互联网巨头出现之前，电话通信交换网络及其计费系统已经承担了最大的任务量。电信公司对网络技术不断投入，以确保整个网络的高可用。这其实占据了大量的资金，并产生了许多闲置——低利用率的计算和存储资源，最终带来了整个运营的低效率。

所以我们认为，未来电信行业必然是一个IT、CT融合，电信运营商互联网化的趋势，IT所占比重会越来越大，电信行业的盈利模式也会从传统的提供通道到提供IT资源、提供服务的方向转变；近几年随着大数据、云计算、容器化、微服务、平台战略等新技术和新概念的层出不穷和快速发展，在业务支撑、架构能力、平台扩展性等方面对旧有的烟囱式建设的业务支撑系统提出了巨大的挑战。因此对现有业务和设备进行容器化改造，则成为了一个必然的选择。

容器技术作为目前一项方兴未艾、炙手可热的新技术，具有以下优势：

1、极其轻量级的虚拟化技术，大大提高IT资源的利用率；

2、标准化的打包、封装、搬运机制，有效提高开发运维效率，降低成本；

3、秒级启动速度，保障业务的稳定性与高可用性；

4、类似于积木的分层机制，提供灵活组合微服务；

5、简化开发版本管理。

另外一个与Docker伴随而来不得不提的概念是微服务。微服务架构是一种特定的软件应用程序设计方式——将大型软件拆分为多个独立可部署服务组合而成的套件方案。虽然这种架构风格的确切定义还未统一，但并不妨碍其在众多企业的实际应用中被实践，并体现出了具备通用特征的业务功能、自动化部署、端点智能化以及对语言与数据的离散化控制能力。

许多如Amazon、eBay、NetFlix等公司都采用微服务结构模式，都在尝试改进那些需要频繁更新的，通过网络提供到用户的PC、平板和智能手机上的应用程序和服务的持续交付，将应用分解为小的、互相连接的微服务，而不是开发一个巨大的单体式的应用。一个微服务一般完成某个特定的功能，比如下单管理、客户管理等等，都有自己的业务逻辑和适配器。一些微服务还会发布API给其它微服务和应用客户端使用。其它微服务完成一个Web UI，运行时，每一个实例可能是一个云VM或者是Docker容器。这种微服务架构模式深刻影响了应用和数据库之间的关系，不像传统多个服务共享一个数据库，微服务架构每个服务都可能有自己的数据库。

Docker作为一种开源的应用容器引擎，帮助开发者将他们的应用以及依赖打包到一个可移植的容器中，便于应用的部署和扩展。而随之产生的微容器概念和微服务正好相辅相成，通过 Docker 封装的应用可以轻松运行在以扩容能力见长的云计算平台上。

围绕着云托管环境的如此多的应用程序和服务部署活动，微服务架构已经深度依赖于容器化技术的使用。容器将微服务进程和应用程序隔离到更小的实例里，这些实例仅仅使用虚拟化了的操作系统，而不是整个虚拟机以及VM所包含的整个抽象硬件资源。

微服务不是Docker，但Docker天然是为实现微服务而存在，利用Docker技术可以很方便的对宿主机资源进行隔离、划分，同时因Docker本身极其轻量化的特点，可以做到宿主机的高密度、高可用性、高弹性的应用，从而做到IT资源利用价值的最大化。

结合行业经验，我们认为电信企业容器化改造需要考虑的因素包括：

1、业务层面：因运营商对业务的稳定性和连续性有比较高的要求，故容器化的演进路径必然是从边缘业务到核心业务，从简单应用到复杂应用，具体到业务，首先可以考虑在Web前端进行容器化迁移，第一步选择某些相对独立的，不涉及BOSS系统的模块，如网上商城等，第二步逐渐切入到一些涉及用户数据的非核心业务如积分兑换等，最后迁移与用户计费直接强相关的业务，如业务套餐办理等。

2、技术层面：目前原生Docker在服务发现、负载均衡、容器生命周期管理、容器间网络、存储等方面还存在诸多的不足，因此目前有许多第三方厂家提供的开源解决方案和商业化版本，如Google的Kubenetes，Apache的MESOS，Rancher等，各家方案各具特色，难分高下，当然仅从容器编排引擎的角度来看，Rancher可以兼容Kubenetes、MESOS和Docker SWARM着几种主流的编排引擎。是固定技术体系框架，还是选择灵活兼容的模式，是需要着重考虑的因素之一。

3、兼顾到成本效益原则，综合考虑容器化付出的成本代价与未来收益之间的平衡。传统的短信、彩铃以及客服中心业务因本身业务在萎缩，因此不太建议进行容器化。

4、还要考虑现有硬件的负载能力问题，容器化并非包治百病的良药，某些对并发吞吐量要求更高的业务，直接运行在裸机上，通过系统调优提高性能，容器化未必是最好的选择。

容器化过程中的注意事项：

1、运营商传统业务网络经过多年建设运营，业务模式涵盖了交易、计费、服务等各种核心业务，系统功能各异复杂度高，并且多个厂商多种系统并存，这些成为容器化迁移的一大障碍。摸清这些系统之间的架构关系，避开不必要的坑，是容器化之前就需要做的工作；

2、在底层架构考虑方面主要需要考虑操作系统、数据库等平台软件之间的兼容性问题，另外需要考虑收费软件厂商的支持力度、License管理政策是否允许容器迁移。

3、虽然Docker以及微服务看起来很美，但是要真正的实施落地，除需要

足够的人才技术储备，还对运维团队的自动化流程也提出了更高的要求和挑战。容器化改造之后，一台宿主机上运行的容器可以成千上万，如何对这些容器的故障进行维护，需要对原有的运维流程和团队进行更新升级以适应新的业务情况。所以选择专业的产品化的容器技术厂商不失为探索过程中的有力保障。