云原生时代，电信运营商的微服务架构适用性

Posted 2021-04-06 架构头条

作者 | 路宇浩

微服务作为目前主流系统架构模式之一，已获得多数企业青睐，其在一定程度上被业内视为单体架构演进的方向。本文通过分析微服务架构与单体架构的性能特点与适用性，并对运营商系统进行梳理研究，提出了微服务架构系统适用性评估体系，同时对云原生时代运营商微服务改造策略进行研究。

2015 年以来，微服务被认为是一种理想的架构模式，被主流互联网公司、传统企业大规模使用，但是很多单体应用（例如 J2EE）仍然占据着企业的核心业务，因此单体应用的微服务化改造一直以来是业界探讨的热点问题。虽然微服务改造是一个长周期的系统性工程，但应用微服之后，能够获得快速独立部署，灰度发布等等很多优势，在一定程度上提升了系统运行效率，同时也会产生大量的运维管理成本。

在云原生时代，微服务架构是否是最适合的架构模式并没有定论，需对微服务应用的价值，微服务产生的管理成本，尤其是微服务的系统适用性进行深入研究。对电信运营商内部庞大的 IT 系统而言，微服务既可以提升运营效率也会带来巨大的投入与管理成本。

1微服务成为当前主流系统架构形态

1. 微服务的概念与外延

目前业界所接受的微服务定义是由 Martin Fowler 与 James Lewis 于 2014 年共同提出的。在相当一段时间内，业内普遍认为“合久必分，分而治之”是系统架构发展导向，庞大的单体架构终究会拆解成小系统，微服务是架构发展的自然演变。

定义显示，微服务是架构层的一个概念，通过分解（业务单元），将项目拆解出多个单元，互相没有强依赖关系（解耦），服务自行准备需要的依赖条件，进而达到可以独立运行、独立部署，不再受环境与位置上的限制。其运行本质是使用小服务聚合形成单个应用，每个服务运行在独立的进程中，通常采用 HTTP 资源 API 类轻量的机制来相互通信，这些服务围绕业务功能进行构建，并能够通过自动化部署机制来独立部署，不同服务间可使用不同编程语言实现，以及不同数据存储技术，保持最低限度的集中式管理。

2. 微服务架构正在替代单体架构

从架构优化的视角研究审视，单体架构的缺点比较明显，任何一个细微修改都需要对系统进行重新部署，且随着应用愈加复杂，部署成本会指数级增长。并且项目初始开发语言很难进行模块间解耦，对其他语言和框架比较排斥。微服务架构可以很好地解决这些问题，每个模块被独立进行产品化开发，由独立团队负责各种逻辑持久层的开发。本文梳理了微服务架构与单体架构相比存在的优势：

• 故障隔离：单体架构为线程级，微服务架构为进程级，微服务独立运行，通过进程的方式隔离，使故障范围得到有效控制。

• 可靠性：微服务架构可靠性略高于单体架构，微服务架构由于故障得到有效隔离，整体可用性更高，有效降低了单点故障对整体的影响。

• 架构演进：微服务架构占显著优势，微服务的粒度更小，架构演进的影响面相应也更小，架构演进不需要大规模重构，只需调整个别微服务即可。

• 可用性：微服务架构优势明显，微服务架构可以实现以服务为粒度，通过接口共享重用。

• 系统扩展性：微服务架构可以根据服务对资源的要求以服务为粒度进行扩展，而单体应用只能整体进行扩展。

• 交付速度：单体架构交付周期长，服务拆分后，各个服务可以独立并行开发、测试、部署，交付效率大大提升，产品更新换代速度更快。

正是由于微服务展现出的诸多优势，其正在成为系统架构新的默认选项。O'Reilly 调查了全球 1283 个企业，其中 52％的受访者表示他们正在使用微服务进行软件开发，28％的受访者使用微服务超过三年，超过 55％使用微服务的时间为一到三年。O'Reilly 还指出目前企业对微服务的兴趣可能达到或接近顶峰。

2微服务并不是万能的

微服务也有其弊端和痛点，由于存在大量小服务以及复杂的服务交互关系，运行的核心变成服务治理，需要重度依赖微服务框架。

1. 微服务应用后产生的新问题

大部分企业在转为微服务后发展每多一个新服务，就会增加一些依赖的基础设施，比如 ECS 服务、Postgres 实例或 RabbitMQ 实例等，相应 CI/CD 的配置也会增加，还需要进行第三方服务（比如 Rollbar/Sentry）配置。因此，基础设施团队需付出大量精力为每一个服务重复着环境与依赖关系配置的工作。同时随着服务数量的不断增加以及业务属性的发展，服务间交互关系会变得异常复杂，服务的治理成为一项棘手的工作，甚至会降低系统运行效率。一致性与时延也是将面临的主要问题，由于程式逻辑、资料分散，导致大多数任务都需要跨服务沟通、同步和交换状态，这意味着状况总会发生。越来越多的企业发现采用微服务架构需要解决很多问题，而这些问题在单体系统中已经解决过了，例如日志、监控、异常处理、容错、回退、服务间通信、消息格式、容器化、服务发现、备份、遥测、警报、跟踪、容错等。

2. 部分团队正在放弃微服务

近年来无数的中小团队在微服务上陷入了挣扎，即期望于微服务有好处但也承受着弊端和风险，最典型的是随着业务不断发展，微服务更加复杂。一些企业权衡利弊后选择了退回单体架构，或者将多个微服务合并成较大的服务。例如 Uber 支付体验平台放弃了微服务，转而使用了合理规模服务（Uber 内部称为宏服务）。

Uber 在发展早期通过构建微服务来实现很小的需求或功能，以至于出现了很多由一个人构建维护的微服务。这些微服务的存在给带来了新的复杂性和挑战，例如监控、测试、持续集成 / 持续交付（CI/CD）、服务级别协议（SLA）、跨所有微服务的库版本（安全和时区问题）等。因此 Uber 正在将聚焦于一项服务改变为聚焦于一项业务功能，被称为宏服务。

3微服务成为运营商“IT 化转型”主要路径

电信运营商涉及的系统类型比互联网公司更加复杂，按照业务类型可以分为支撑类（如 CRM/BOSS）、业务类（如 CDN/ 短信）、网络管理运营类（如 OMC/SDN 编排）、网元类（如 NFV）四类，按照系统属性可以分为 IT 架构与 CT 架构，两种划分模式间存在复杂的对应关系。

由于运营商系统存在诸多历史遗留问题，因此同一运营商内部可能运行着涵盖单体架构到微服务架构的全部架构类型系统。同时近年来主流运营商推动 CT 系统云化，致使 CT 架构与 IT 架构的边界也愈加模糊。AT&T、Telefónica、中国移动等大型运营商在多类系统中规模部署微服务架构体系，可以将其架构升级的驱动概括为以下 6 方面：

第一，应对日益复杂的经营管理模式。运营商经过数十年发展，受业务范围、管理诉求复杂化影响，内部堆积了大量“烟囱”系统，省级运营商系统数可达千级。应用微服务可以化繁为简，对冗余系统集中收敛。

第二，微服务已成为 CT 云化事实标准。微服务发源于 IT 领域，在 IT 领域的成熟度也远高于 CT 领域。但是在 CT 云化改造的过程中，3GPP、ETSI 等主流标准化组织已将微服务作为行业标准，应用于 NFV 等框架设计中。最典型的是 5G 技术体系，完全按照服务化进行设计。

第三，集约化管理趋势影响。国内三大运营商一直在加强集约化管理，并构建集中的 IT 系统满足不同业务以及不同省间访问需求，微服务因具有独立部署、快速迭代等优势，成为集约化管理最佳选择。

第四，业务多元化发展诉求。运营商经营方向已从传统的通信服务向信息服务、内容服务、互联网金融、物联网业务等转型，渠道经营也走向多样化电子渠道，从自有营业厅向外部电商、第三方伙伴渠道扩展，同时引入了互联网化运营模式（如流量包抢购、内容限时免费、免月租卡抢购等)。因此，内部系统的复杂度随着各项功能的叠加也日益增加，交付需求不断加速。单体系统已无法承受业务复杂度的提升和快速、灵活响应需求。

第五，运营商技术自主把控意愿愈加强烈。IT 自主研发工作已得到运营商充分重视，但存量单体系统主要由外部合作伙伴提供的，技术栈固化，自主研发团队无法切入。从软件工程的角度，推动合作伙伴构建微服务架构，实现接口层交互更有利于双方的独立发展，基于契约驱动的模式可以为自主研发提供更大空间。

第六，微服务架构技术条件已经成熟。配套技术生态环境（如容器化、DevOps 工具链、开发语言的框架、设计开发方法论等) 已经比较成熟，诸多互联网企业和政府组织也验证了微服务架构在提高应用交付速度的独特优势。

4微服务架构适用场景研究

本文基于微服务架构特性与实施部署要求，以系统复杂度、一致性、时延要求、可用性要求、交付周期、弹性需求、团队力量、架构生态 8 个维度为标准建立微服务架构适用性评估体系。基于评估体系对电信云运营商主要系统微服务适用性进行研究。

1. 微服务架构适用性评估体系

简单系统不建议应用微服务。简单不仅指业务逻辑简单，还包括周边关系，也就是与其他系统交互少。在一项业务运行或者设计初期，尤其是在业务量不大且复杂性不高，并且追求快速响应、开拓服务、节省成本、提高效率时，单体架构是最优选择。但当业务进入扩展期，系统架构开始向服务架构转型，业务不断扩大，业务系统复杂性不断提高，使效率在不断下降时，再考虑微服务。

一致性要求高的业务系统慎重选择微服务。微服务的本质是分布式系统，业务对数据的一致性要求决定了系统是否可以采用分布式架构进行构建。需要评估微服务所产生的大量服务调用与服务间通信所带来的数据一致性的影响是否能满足业务场景的需求，同时评估服务治理框架能否应对大量的服务间通信。

实时性要求高的业务系统慎重选择微服务。分布式系统相较单体系统会带来额外的网络开销。需要评估目标业务在分布式架构下，网络带来的延迟能否满足业务需求，若时延容忍度高于毫秒级，微服务会严重应用运行性能。

微服务可以提升系统整体可用性。通过集群的方式可以提升服务的可用性，但取决于服务化的模块是否易于进行水平扩展。无状态的服务容易扩展到多个实例，而有状态的服务则成本较高。

微服务可以帮助团队优化交付周期。快速的交付有利于缩短获取用户反馈的周期，有利于团队实现敏捷开发及降低发布的风险。因此在进行架构改造前需要充分评估业务需求的快速变化以及交付周期的缩短是否可以显著提升业务竞争力。

微服务架构具有良好的可伸缩性。针对具有弹性伸缩能力需求的业务系统，而且水平伸缩模型可进行预测的场景适合进行微服务改造。

项目人员团队力量薄弱期不建议应用微服务。微服务是一项系统性工程，架构师需要构建微服务、前端、后端、测试等多个模块。另外要考虑是否有能力维护大量分布式的复杂服务，尤其当不同的服务采用不同的技术栈，服务间通信机制、认证、鉴权、证书管理也会异常复杂。

生态尚未完全开放且专业性强的系统不建议应用微服务。具有较高专业特性的系统、不适合使用微服务，因为微服务大量依赖公共组件或者开源基础产品，对专业性高的系统产品进行微服务改造要进行大量的定制化开发，工作量甚至大于进行完全重构。并且即使重构成为微服务架构，系统升级、更新也得不到支持。

除了上述技术问题，还要解决更多的全局性问题。如让企业内不同团队独立负责不同业务是否符合企业现状，如何在业务领域和微服务之间对功能进行清晰划分，如何协同服务设计与服务治理工作间多维度关系等。

2. 电信运营商应用微服务架构面临的挑战

电信运营商进行微服务改造会面临交互复杂性提升、通信机制难以管理、组织架构不匹配等共性挑战，同时也存在供应商依赖、电信生态发展滞后等运营商特有难题。

在共性挑战方面。第一，微服务部署在分布式计算环境下，必须要面对分布式计算的复杂性，比如网络因素对性能的影响、负载均衡、故障定位、单独故障雪崩等。第二，微服务管理复杂性性的提升，版本关系、服务间协作、边界控制都对系统稳定性至关重要，因此需要搭建成熟的服务管控框架。第三，微服务需要完善的基础设施技术生态环境，如建立 DevOps 机制才能更好发挥微服务快速迭代、快速响应需求的优势，具备 K8s 才能实现服务基础设施的管理闭环，但技术环境大多依赖多类开源、闭源的解决方案，平台本身的选型、安装、管理维护也需要很大的资源投入。

另一方面，运营商在应用微服务架构时面临的独特挑战是架构适用性研究的关键。第一，微服务架构与运营商现有 IT 应用架构差异很大，传统 IT 架构主要由合作伙伴提供，微服务化改造需要重构 IT 的研发管理机制和相关配套工具，运营商与合作伙伴都要克服“路径依赖”。第二，现有的单体应用的维护管理组织、机制和流程已经根深蒂固，微服务架构“去中心化治理、去中心化管理数据”的特点要求相应的组织和职责进行调整重构。第三，由于运营商大多不具备端到端技术研发能力，微服务改造依然依赖合作伙伴，难以形成真正的自主把控能力，仅是从多个单体架构生态陷阱跳入某个伙伴的单一生态陷阱中。第四，CT 类标准框架（如 NFV）虽然采用微服务体系进行构建，但其开放程度、接口规范程度等云原生属性尚未成熟，微服务大多数性能优势不能实现。

5电信运营商云原生时代微服务实施建议

微服务的实施是一个涉及组织、架构、工程等多方面的演进过程，对于业务背景、系统复杂度、技术体系、团队规模不尽相同的电信运营商，有效地实施微服务并平滑演进需要完成大量的工作。本文从技术实施、宏观条件等多个方面提出运营商落地微服务的建议。

首先要认真思考是否需要拆分单体系统。架构改造是为了更好的支撑运行，而不是单纯的趋向技术迭代，因此微服务改造不能是盲目的，要进行深入评估，例如遗留系统为以下状态则不需要微服务。第一，大多数功能的开发已经在新系统中进行了，遗留系统只负责不需要大量迭代的事情；第二，遗留系统仍然可以满足可伸缩性需求，即使不是使用最新技术开发的，但仍然可以处理现有的负载；第三，只有少数可以调度的开发团队，在人员不足的情况下进行重构可能会导致开发管道超载，并造成开发瓶颈；第四，单体遗留系统具有良好架构设计，虽然不同部分之间有紧密的耦合难以理解，但现实中已很好的解决这些问题。

1、按照服务架构需求进行团队调整

以服务为核心，按照业务领域划分全功能团队，改变原有的研发流程、决策机制。同时，在采用微服务架构之前，应该先进行微服务架构的选型、学习和试用。整个团队要对微服务的基本概念、微服务框架的实现原理，微服务治理与监控等知识需要有一定的储备。

2、优先完成基础设施建设

基础设施即代码，部署基础设施环境是微服务改造必要条件（如 Kubernetes、CI/CD、镜像和依赖库、网络环境、日志采集分析平台、调用链采集分析平台等），同时需要明确依赖管理工具、配置管理工具、代码审核工具、API 定义管理工具，建立自动化测试、自动化部署、自动化监管体系。

3、微服务需要逐步进行拆分

应尽量避免在设计系统的时候直接划分微服务。因为面对一个新的业务和领域，很难在开始阶段就对业务梳理得很清晰，需要经过模块反复调整后，业务内部架构才能逐渐清晰起来。如果项目前期直接划分微服务，服务很容易拆分不合理，大大影响整个调用流程的性能，甚至可能需要花费很大的精力去处理分布式事务，最后不得不再将多个微服务整合成一个单体。只有当业务复杂度达到一定的程度后，微服务架构消耗的成本才会体现其优势，这个时候就可以开始设计微服务架构、进行微服务划分了。微服务设计应该优先尊崇垂直划分优先原则，垂直划分服务可以让团队自上而下地关注业务实现，端到端负责，避免跨服务多次调用引起的性能与沟通成本。

4、关注微服务监控与治理

管理维护大量的服务与实例，需要构建一套监控系统，能够监控所有服务日常运行状态，并且需要在服务出错的时候给对应负责人发出报警信息。在出现故障时，能够通过调用链查询以及服务拓扑图等功能进行分析查看，也可以进一步查看到全息日志等具体信息。除了监控，服务治理也至关重要，可以通过 SDK/Sidecar 手段提供服务高可用的治理策略，这些策略往往对业务是非侵入或者弱侵入的，能够让绝大多数服务轻松实现服务高可用。

5、选择合适的微服务框架

主流的微服务框架分为侵入式与非侵入式两类。主流的开源侵入式框架包括 Spring Cloud、Dubbo、brpc 等，社区和文档的成熟度都比较高。虽然 Spring Cloud 这样的传统侵入式微服务框架大多具有版本碎片化严重、升级成本高等问题，但功能相对成熟，可以满足绝大部分服务治理的需求。反而非侵入式框架选型越来越重要，如服务网格技术（ServiceMesh）。Istio 作为一个开源的 Service Mesh 开源框架可以不再需要其他的微服务框架，只要把网络层委托给 Istio，由 Istio 提供服务治理能力。此外，Istio 还提供完善的可观察性方面的能力，包括对所有网格控制下的流量进行自动化度量、日志记录和追踪。

6、首先明确微服务定义原则和管理标准

架构改造前需要对服务管控原则进行规范化定义，比如统一的服务版本管理策略和流程、统一的服务 QoS/SLA 实施方案 (如流量控制、服务降级、防止雪崩的控制策略、熔断标准、超市控制、优先级方案、容错方案等)、统一的通信方案 (同步异步选择、交互协议类型等)、统一的跨服务控制调用方案等。

6总结

云原生时代微服务架构存在诸多优势，但没有任何一种技术可以作为“银弹”，微服务也不例外，运营商拥有庞大的 IT/CT 系统，改造过程要警惕软件工程中存在的“陷阱”，微服务应用需充分探讨目标系统需求与特性，制定完善的架构规划，选择最优系统设计方案分阶段进行演进。

作者简介

路宇浩，现任中国移动设计院高级咨询师，研究方向为云原生体系下云计算、边缘计算等领域，主要负责中国移动省级公司网络建设规划咨询项目。参与过运营商内部各个层级组织的云能力、云平台及微服务架构改造架构规划与建设实施项目，拥有大型微服务管控体系的设计与实施经验。多年来一直致力于 IT 与 CT 多类技术栈体系微服务改造建设工作。

点个在看少个 bug