互联网化背景下运营商构建微服务IT架构的探讨

乔宏明+梁奂+姚文胜

编者按

自2015年李克强总理在政府工作报告中明确提出“互联网+”行动计划以来，“互联网+”已逐渐深入应用于各行各业中，如本期专题探讨的“互联网+现代农业”、“互联网+移动办公”等，可以说，“互联网+”正推动传统产业的变革。当然，在此进程中仍有不少关键点值得进一步探讨，包括物联网、云计算等技术该如何融合创新，电信运营商怎样借助“互联网+”构建微服务等。本期专题希望通过分析过去几年“互联网+”的相关技术研究和应用成果，对其未来的发展方向进行展望。

【摘 要】为了探讨互联网化背景下运营商如何构建微服务IT架构，结合电信运营商IT的特点，分析了电信运营商在互联网化背景下构建微服务IT架构的驱动力，并就其构建微服务IT架构可能面临的挑战进行探讨，最后就其实施IT架构微服务化给出了建议。

【关键词】微服务 信息系统 运营商

1 引言

近三年来，“微服务”取代了“SOA”，成为国内IT行业在IT架构方面的研讨热点，诸多互联网企业前期已经做了大量的实践。在互联网化背景下，电信运营商也在探讨能否将这一架构引入运营商的IT领域[1]，用微服务架构重构IT应用系统，从而更好地满足企业对IT服务能力在灵活性和高效响应方面的要求。

关于微服务架构的研究和实践在国外已经开展了10多年的时间，根据该概念的提出者James Lewis和Martin Fowler的意见[2]，微服务架构是一种架构风格（microservice architectural style），某種意义上引用了Unix的设计原则，是一种将单一应用开发为一组小服务（a suite of small services）的方法，每个小的服务都运行在自己的进程中，通过轻量级的机制（通常是一种HTTP资源API）互相通信。微服务架构风格有如下9个特征，即：基于服务的组件化、围绕业务能力组织团队、“做产品”而不是“做项目”、“智能端点”与“哑管道”、“去中心化”治理、“去中心化”管理数据、“基础设施”自动化、“容错”设计、“演进式”设计等，本文后续的讨论和分析将依照上述微服务架构的特点进行陈述展开。

2 运营商构建微服务架构的驱动力

电信运营商对微服务架构的研究和兴趣主要有以下4个方面的原因：

（1）现有IT系统的痼疾希望通过微服务架构得到缓解或解决

当前运营商业务形态和经营管理模式日益复杂：业务形态方面，从传统的通信服务向信息服务、内容服务、互联网金融、物联网业务等转型；经营渠道方面，从传统实体营业厅向多样化电子渠道的转移，从自有营业厅向外部电商、第三方伙伴渠道扩展；营销活动方面，互联网企业的各类玩法（流量包抢购、内容限时免费、免月租卡抢购等）都在试水；经营管理方面，依据国家政策进行了引入民营资本尝试，在虚拟运营方面也进行了探索和实践。

企业业务和管理的变革都需要IT系统予以支持，使支撑企业管理运营的IT系统日益复杂。当前中国电信运营商的转型还没有到尽头，后续电信运营商将进一步扩展经营手段，扩充生态圈，业务形态和商业模型都可能发生更大的变化。未来企业的发展需要更加灵活、快速响应的IT支撑能力。

运营商传统IT系统以单一系统（monolith）模式为主，其复杂度随着各项功能的叠加也日益增加，扩展性、可靠性、可维护性越来越差。另一方面业务部门对需求的交付周期要求越来越短。单一系统架构复杂度的提升和快速、灵活响应需求的矛盾日益突出。根据电信行业IT系统某主要供应商提供的一个案例[3]，某个仅仅需要短短十几行代码的需求，评估之后竟然需要9个星期才能上线，因为需要在9个不同的功能模块中修改，并新增900多个测试用例用来做全量的回归测试。近期部分运营商使用了一些互联网技术和方案（与分库分表、分布式缓存、公共服务平台化等）优化IT系统，但重点解决的是性能问题，系统本身的复杂度问题没有得到解决。从实践上看，前期采用SOA等架构总体效果也不甚理想。

（2）运营商集约化管理的要求可以通过IT架构微服务化更容易地落地

为更有效地应对行业内外的竞争，电信运营商近年来一直在加强集约化管理，与其相配套的，IT系统集约和集中一直在路上，三大运营商都在总部构建了越来越多生产性质的IT系统，且越来越多的服务能力（如物联网业务支撑）采用了集中化部署的模式。

相对而言，省公司的IT系统集中相对进展缓慢，这一方面有管理方面的原因，也有技术方面的难度。如果省公司的IT系统能借助微服务架构进行改造，实现相关服务能力的独立部署、快速迭代，就可以为未来IT最终的集中集约奠定更坚实的技术基础。

（3）微服务架构可以为运营商开展IT自主研发奠定良好基础

借鉴互联网企业经验，运营商都在开展IT自主研发工作，有借助企业内部的研发单位专职开展自主研发，也有鼓励各个省公司自己组建小团队的尝试。很多自主研发工作都采用了新的系统或数据应用做切入点，但都不可避免的要跟原有的IT系统有交互。目前运营商IT系统主要是外部第三方合作伙伴提供的，一般技术栈固化，自主研发团队很难切入，从软件工程的角度，把交互放到接口层更有利于双方的独立发展，如果现有第三方提供的核心系统能提供微服务化服务接口，实现契约驱动，就能为自主研发提供更大的助力。另一方面，IT团队自主研发的系统，未来趋势也是自主运营（DevOps），这也符合微服务“做产品”而不是“做项目”的典型特征，自主研发从技术架构上采用微服务架构，也有利于长期的发展。

（4）采用微服务IT架构符合互联网化技术演进的趋势和企业长远利益

当前微服务IT架构的配套技术生态环境（如容器化技术、DevOps工具链、各种开发语言的框架、设计开发方法论等）已经比较成熟，诸多互联网企业和政府组织[1]（如亚马逊、Netflix、英国卫报、英国政府数字化服务中心）也验证了微服务架构在提高应用交付速度的独特优势。“API经济”概念[4]的提出，标志着基于IT开放服务的业务生态已经逐步成熟，其生态圈必定将从互联网应用领域逐步渗透到传统企业的IT领域，而微服务架构正是当前乃至未来支撑IT开放服务的核心技术架构。具体到电信行业，电信管理论坛（TMF）是电信行业IT相关规范标准制定方面的权威组织，在其框架规范体系中，已经在TMF6XX系列规范中将IT服务能力用REST风格的API进行了标准化，可见运营商IT系统的微服务化也已经有了广泛的共识和标准基础，企业在这方面的投入未来会有显著回报。

3 运营商实现IT架构微服务化的风险

虽然运营商采用微服务IT架构有显著的驱动力，也是未来的发展趋势，但短时间内并不具备全面实现IT系统全面微服务化的条件，其面临的主要风险包括两个方面：

（1）采用微服务架构面临的一般风险

采用微服务架构的应用必须部署在分布式计算环境下，必须要面对分布式计算的复杂性，比如：分布式应用开发的复杂性要考虑网络因素对性能的影响、异步处理的难度、权衡服务粒度的大小等；为应对可靠型风险增加，需要更强的容错设计；要面对分布式环境下的负载均衡、故障难以定位、单点故障雪崩效应的问题；要面对多个分布式应用的协同问题；要面对分布式计算环境下数据一致性和处理性能方面的权衡等，这些分布式计算面临的挑战，微服务架构都要处理。

此外，微服务架构还有一些特定的技术难题，比如微服务架构相比单体架构意味着引入更多的系统实体，必然会带来管理的复杂性。一般而言，微服务的数量会很大，在版本管理和服务间协作方面需要投入更多的关注。微服务的边界控制和管理至关重要，这需要开发团队对自己的产品和业务有足够的了解，定义好服务契约，把握好耦合度。微服务架构的良好运作需要更精细的监控能力和手段，一般需要專有的平台。

最后，微服务架构的实施需要搭建一个技术生态环境，最主要是建立DevOps机制才能更好发挥微服务快速迭代、快速响应需求的优势。为此，需要建立面向DevOps的开发方法和团队文化；需要建立面向DevOps的技术平台，比如服务接口管理、标准化的开发环境、自动化部署测试环境、企业内共享的镜像管理平台、依赖包管理平台等。上述技术平台都有多种开源、闭源的解决方案，平台本身的选型、安装、管理维护（特别是采用微服务架构的初期）也需要很大的管理、人员、设备资源投入。

（2）电信运营商在应用微服务架构时面临的独特挑战

除了一般的风险，电信运营商由于自身行业及IT系统的特点，还要面临一些特有的挑战。

首先是微服务IT架构与运营商现有IT应用架构差异很大，且主要由第三方合作伙伴提供，双方都需要克服“路径依赖”。对于众多第三方合作伙伴，需要按照面向微服务架构重构IT的研发管理机制和相关配套工具，应对从单一架构应用向微服务架构迁移带来的一系列问题[5]，乃至重新组织研发团队。对于运营商，现有的单体应用的维护管理组织、机制和流程更多是基于ITIL指导思想配置和指定的，相关职责划分也一般参考了传统应用分层架构，微服务IT架构“去中心化治理、去中心化管理数据”的特点要求相应的组织和职责也要调整，运维流程也需要在ITIL最佳实践的基础上优化；运营商开展自主研发，需要多个第三方合作伙伴和自身研发队伍在软件开发流程和标准、研发测试环境、项目管理机制等方面进行协同，采用DevOps机制也意味着相关团队人员能力、考核机制、管理流程必须做必要的调整。没有足够的内外部驱动力，想改变这些路径依赖非常困难。

另一方面，相比互联网企业，电信业务的复杂度很高，特定场景对数据一致性的要求很高，不同运营单位的管理运营思路也可能有很大的差异，微服务的划分虽然有标准组织的规范可供参考，但不可能直接拿来“开箱即用”，需要IT部门及业务部门协同，需要参与人员在业务领域、技术领域的个人能力和经验积累，无法一步到位得到最优化的设计。

最后，传统上对运营商的IT系统，稳定运营和快速支撑是两个主要的考核指标，稳定运营的重要性往往更甚于快速支撑，对IT架构进行全面的微服务化改造如果短期内给客户部门带来的成效不显著，往往难以在内部获得足够的支持，从而难以开展改造工作。

4 运营商微服务架构实施建议

综上分析，运营商采用微服务IT架构既有驱动力，也面临一系列现实的风险，这一局面是有普遍性的：包括微服务架构的提出者Ames Lewis和Martin Fowler在内，很多微服务架构布道者也提出，传统的单体系统维护体系和人才能力已经成型，要转变成微服务架构需要多方面的配合和深入的转型，除非面对的是一个复杂到难以维系的单体应用，否则不能轻易采用微服务架构。对于单体应用过于复杂、难以维护的问题，如果评估相关团队能力具备，也可以优先采用一些折中的方法（比如单体应用自身的模块化改造），而非强制用微服务架构将系统进行“物理性”的分割。

总体而言，对于大型的复杂系统来说，微服务架构是一种可适用的技术架构。对运营商来说，其向微服务IT架构的演进也有客观的驱动力。运营商要构建微服务IT架构，有以下建议：

（1）对实施IT架构微服务化转型要有思想准备。微服务架构的实施是一个长期摸索的过程，需要以为企业运营管理和业务运营提供价值为基础，制定实施微服务架构的效能评估指标，一方面期望得到领导层的长期支持，另一方面便于随时自我评估，改进实施策略和方案。考虑到当前的IT系统供应商格局，在相当长时间内将是传统架构和微服务架构并存的形态，需要迭代演进，不能追求一蹴而就。

（2）技术基础准备方面，要就微服务架构下的一些技术决策点尽早给出明确的意见。比如微服务定义原则和管理标准、统一的服务版本管理策略和流程、统一的服务QoS/SLA实施方案（如流量控制、服务降级、防止雪崩的控制策略、熔断标准、超市控制、优先级方案、容错方案等）、统一的通信方案（同步异步选择、交互协议类型等）、统一的跨服务控制调用方案等。此外还要实现统一的基础设施管理（如共用镜像和依赖库、网络环境、服务日志标准化采集分析平台、服务调用链标准化采集分析平台等），明确依赖管理工具、配置管理工具、代码审核工具、API定义管理工具，建立自动化测试、自动化部署、自动化监测技术手段。

（3）生态环境准备方面，要从企业层面推进微服务化架构不仅在IT，也在业务平台、网络平台等各个层面的实践，指定企业级的相关标准，以标准为引导。在企业内部，需要结合自主研发逐步开展DevOps理念的宣贯，完善现有的基于ITIL的服务管理机制，使IT运维从“稳态管理”向“稳态管理”和“敏捷运营”并重转变。需要结合微服务应用的特点调整IT组织架构和相应的考核标准，并对人员技能结构做相应的调整。在自主研发能力有限的情况下，微服务架构落地中，外部第三方合作伙伴的配合是成功的关键：这既有赖于各个省级层面的协调，也有赖于集团层面的推动和指导。面向外部第三方面合作伙伴，一方面需调整采购标准和考核要求来推动，另一方面也从双方企业的长远利益着手，明确IT架构微服务化给第三方带来的效益，拉动第三方合作伙伴主动求变。

在上述準备的基础上，选择好实施切入点也很重要。在具体的应用切入点上，Infosys Limited的Nikhil Mohan和Ansoo Susan Thomas给出了很好的方法论和建议[6]，可供参考。

5 结束语

通过本文分析可知，电信运营商推进IT微服务化有客观的驱动力，也面临诸多风险因素，需要有打持久战的准备，协同第三方合作伙伴共同探索。在实施微服务IT架构前，需要从思想、技术、生态环境等多个方面进行考虑和准备，找准痛点、选好切入点，稳步推进。

参考文献：

[1] 孙盛婷，朱奕健. 基于运营商能力开放的能力编排及微服务架构研究[J]. 工业和信息化教育， 2016（3）： 53-54

[2] James Lewis， Martin Flower. Microservices[EB/OL]. （2014-03-25）[2017-04-17]. https：//martinfowler.com/articles/microservices.html.

[3] 王华超. 新形势下运营商移动业务经营策略研究[J]. 移动通信， 2015，39（1）： 22-23.

[4] 蔺海荣. ICT时代运营商电渠系统的研究与设计[J]. 移动通信， 2016，40（14）： 89-92

[5] 李林锋. 华为实施微服务架构的五大军规[EB/OL]. （2016-08-29）[2017-04-17]. http：//chuansong.me/n/605616624542.

[6] 黄罡. App经济已停滞 API才能让大数据释放更多价值[EB/OL]. （2017-04-08）[2017-04-17]. http：//www.gog.cn/zonghe/system/2017/04/07/015570863.shtml.

[7] 蒋勇. 基于微服务架构的基础设施设计[J]. 软件， 2016（37）： 94-95.

[8] 王健，李冬睿. 从单一模式系统架构往微服务架构迁移转换技术研究[J]. 学科探索， 2016（27）： 44.

[9] 张清辉. 从SOA到微服务的技改之路[EB/OL]. （2016-11-09）[2017-04-17]. http：//www.infoq.com/cn/presentations/transformation-of-the-road-from-soa-to-micro-service-technical.

[10] Nikhil Mohan， Ansoo Susan Thomas. Transforming BSS/OSS Systems to Microservices Architecture[J]. TMForum， 2015（8）： 11-14.