微服务架构，数字时代信息化建设的解药还是毒药？

智能、互联时代已经来临，应用并发量激增，业务流程更加复杂，新技术迭代落地速度更快。采用传统单体应用架构开发，控制代码复杂度，保障系统可扩展性难度越来越大。微服务架构通过将独立业务流程解耦的设计理念快速赢得了大量架构师的关注。更加灵活的部署方式和便捷的服务拼装都使人眼前一亮。大量企业客户，特别是互联网企业基于微服务架构建设信息系统获得了成功。然而，微服务是否适合所有类型的应用系统呢？是否是治愈日益膨胀数字系统开发、管理难题的解药？

我们总是希望有完美的技术方案，然而，放之四海而皆准的应用架构并不存在。微服务架构是一把双刃剑，一方面能大幅度缓解单体系统开发、部署复杂性问题；另一方面，为客户数字体验保障，应用性能稳定性保障带来了新的挑战。不能解决负面影响，微服务就是一剂毒药。

单体架构应用系统

微服务架构应用

微服务架构应用的主要特点是业务功能模块松耦合，分布式部署。大部分业务功能模块都是单独部署运行的，彼此通过数据总线交互，基本都是无状态的服务，以确保能够灵活扩展。在这种架构下，从前台到后台的业务流程会经过多个服务节点，其中可能包括多台物理、虚拟机，容器和很多微服务进行处理、调用和传递。这种方式的主要优点是：

1、 业务逻辑复杂，系统庞大的应用系统能够持续交付、持续部署；

2、 服务业务逻辑独立，易于开发；

3、 服务之间相互耦合度低，可以独立部署；

4、 服务可以独立集群扩容；

5、 使应用能够快速引入新技术，支持多种语言开发的服务协同工作；

然而，微服务节点数量增速与业务复杂度成正比，微服务应用的复杂度使得通过手动管理维护应用拓扑结构已不现实。建设自动化、智能化程度更高的运维系统，首先要找到人工运维困难、耗时的问题点。微服务架构应用系统在业务处理，出现性能、稳定性或业务异常排查的过程中经常遇到的问题主要包括：

1、 应用节点数快速增加，复杂度急剧膨胀，导致测试、运维成本增加；

2、 业务流程处理链路变长，保障客户数字体验难度增加；

3、 业务逻辑和中间件解耦，动态性提升，日常管理难度增加；

4、 监控目标类型多，数据来源分散，故障定位分析困难。

要解决或缓解这些问题对企业运维体系的影响，首先需要具备微服务节点自动探查发现能力，所有节点信息和运行状态自动扫描录入系统，所有服务节点运行状态基于全景监控视图统一展现。全景监控视图重点突出风险探查、发现能力，发生风险第一时间重点突出显示风险点和相关服务节点，过滤海量无用信息（正常状态节点）。

总的来说，微服务应用运维运维难点主要有：1、服务节点众多；2、部署模式多样；3、故障定位困难；4、监控数据量激增；5、基础组件众多；6、代码调用路径变长。

微服务运维难点总结

目前开发运维团队解决问题经常使用的主要手段是采用 Prometheus、ElasticSearch、Skywalking、Zipkin、Zabbix 等代码链路追踪、埋点、日志分析、运行期应用指标监控开源工具自建设微服务应用监控系统。但实践结果显示，这种方式不但不能降低微服务监控运维成本，由于需要搭建多种监控系统协同工作，反而增加了系统复杂度，从多个系统接收告警，查询相关数据使得故障定位分析成本更高。额外增加的监控系统维护、管理和定制开发成本反而让事情变得更复杂。应对这些新技术带来的问题与挑战，解决问题的思路和方向需要转变。运维微服务应用需要转变的核心流程和建设方式，总结起来主要有以下四点：

建设关键点

业务优先一体化监控，提升系统可靠性

微服务应用运维，首先要转变的是将以基础设施、服务节点、接口可用性保障为主的运行期监控维护工作，转变为以保障客户数字体验，探查、处理已发生或将要发生的潜在全局风险为核心。将监控中心从指标、告警、工单转移到服务质量目标、用户体验指标等反映整体态势的聚合指标。这样会大幅度降低快速复杂化的微服务应用日常监控、管理工作量。结合网络、应用配置、部署结构等多种数据源监控数据拼接完整应用拓扑结构，能够自动探测网络拓扑、服务调用、部署依赖等多种应用拓扑关系，链路。进而围绕客户数字体验保障服务质量目标，打造业务优先的全景监控系统，提升系统可靠性。

建设目标：

1、 全景化监控，简化问题溯源

2、 业务状态可视化，简化定位分析

3、 全局态势分析，实时感知潜在风险

4、 故障溯源，海量数据溯源分析

建设效果参考：

全景化监控视图，故障风险一目了然

业务优先的全景化微服务应用

自动探查复杂应用架构，生成全景监控视图

划清责任边界，有序运维管理

微服务应用依赖中间件、运行环境资源类型众多。相关责任人职责明确，但指标告警和业务错误无法关联，责任边界难以界定。基于各自需求搭建分散监控系统，缺少全景化监控平台，出现风险将导致问题排查认责困难。因此，需要在一体化监控平台基础上，通过场景化运维仪表盘、看板或报表，将微服务开发、基础运维、应用运维、网络运维、SRE 等责任人围绕风险发现、定位、处理将工作流程和数据关联，从而实现责任清晰、运维有序。

建设目标：

1、 可视化层级视图管理，明确职责边界

2、 整合业务和监控指标，辅助风险根源定位

3、 有序关联运维场景，简化故障处理流程

建设效果参考：

开发运维一体化微服务监控管理

微服务应用代码定位分析

业务流程复杂，故障排查耗时

微服务应用业务耦合度低，请求处理链条更长，部署方式多样。导致故障追踪、排查难度增加。常用监控工具，如 zabbix、prometheus、grafana 结合使用可以实现在开发期通过 prometheus SDK 定义业务指标，zabbix 采集运行期环境状态指标，并通过 grafana 可视化监控仪表盘关联的方式实现。但是，这种方式需要开发人员介入做大量前期指标定义和代码修改工作，运维人员排查特定业务流程运行期相关中间件、环境依赖资源非常困难。实际应用，需要转变为对开发影响更小，运维人员容易部署，能够快速关联业务流程和监控指标的监控系统。基于 Google 提出的 Dapper 理论，借助海量数据关联分析和人工智能算法，运行期定义业务流程，映射代码链路，并自动关联业务相关资源和指标将是大势所趋。

建设目标：

1、 核心业务全景监控，一站管理业务状态

2、 实时监控业务，业务故障自动发现

3、 打通业务和技术指标，压缩故障分析过程

建设效果参考：

业务流程导向的微服务系统监控

微服务业务流程代码调用链路

微服务业务流程代码调用链路监控

监控数据分散，定位分析困难

采用过多监控、运维工具全量覆盖微服务应用运行期指标，势必造成多种监控数据采集工具采集的监控数据分散、告警独立，定位分析问题需要查询多个平台数据，难度增加。有效的解决方案是围绕业务，通过定制融合所有异构监控指标、代码链路、网络报文、日志等数据为一个运维数据中台。通过统一的风险探查、定位系统从业务角度发现、定位海量监控数据中的问题。

建设目标：

1、 运维数据融合存储，业务技术指标联动

2、 应用全链路监控，方便故障关联定位

3、 智能检测定位异常，支撑运维提效减负

建设效果参考：

支持各种微服务基础组件

海量数据快速检索

智能根源问题分析定位

企业需要能够精准应对微服务应用运维难点的智能化平台，支持以全景化监控视图整合应用监控数据，通过场景化仪表盘应对客户数字体验保障、业务流程监控、应用性能稳定性保障等场景，化繁为简，为企业落地微服务保驾护航。总的来说，建设落地智能化运维平台，需要考虑重点实现的核心能力项包括：

平台核心功能

综上所述，需要驯服微服务架构为企业所用，必需要有行之有效的客户体验保障、微服务应用监控运维系统。RealSight APM 产品为基础的微服务应用全景监控解决方案对症下药，在宝马中国、蒙牛集团、中国航空、宜昌三峡云、北京东城区等客户现场上线应用，运维效率显著提升，保障微服务架构发挥应有的价值。

作者介绍：

许 力，教授级高工，工学博士。2015 年毕业于大连理工大学计算机应用专业；国家软件架构新技术重点实验室 研究员；现任东软集团基础软件事业部 技术总监，兼任东软智能化运维产品 RealSight APM 产品经理。十余年平台产品研发经验，美国硅谷工作轮岗。大连理工大学企业特聘客座讲师；大连海事大学信息科学技术学院教学指导委员会委员。中国计算机学会（CCF）高级会员；中国计算机学会大数据专委通讯委员；美国计算机学会（ACM）高级会员； 美国电子电气工程协会（IEEE）会员。