很多人认为，在微服务架构下，可视化变得不重要了，因为发生问题时，服务会自动降级、熔断，容器会自动隔离、重生，似乎一切都可以自动化。然而很多实施了微服务改造的IT组织发现，随着应用和服务数量的不断增加，调用关系越来越复杂，遇到疑难杂症还是需要运维强力支持，而且运维好微服务这个庞然巨兽，可视化至关重要。

本文将探讨在分布式、微服务环境下的各种可视化实践以及我们在这个领域的探索和成果，全文分为四个部分：

1. 什么是微服务
2. 微服务环境下运维的挑战
3. 微服务可视化的最佳实践
4. 全新的探索：IT数字地图

全文约8千字，阅读需要20分钟。

1 什么是微服务

很多人了解微服务都是从Martin Fowler的这篇文章开始的：

在这篇文章中，Martin Fowler首次提出了微服务概念，并给出了简单易懂的阐述：“微服务是一种架构模式，将一个大型应用程序划分成一组小的服务，服务之间互相协调、互相配合。每个服务运行在独立的进程中，服务与服务间采用轻量级通信协议，并能被独立和自动化部署。”

简而言之，微服务应用要具备三个特征：Small，Independently 和Automated。这三个特征所支撑的核心目标是：快！让应用迭代更快、部署更快、发布更快！

2 微服务环境下，运维的挑战

然而马克思辩证唯物主义告诉我们，为解决某个问题而诞生的新事物，在流行并占据统治地位后，必然会出现它的负面影响。软件开发同样遵循这个规律。随着企业进行微服务架构改造，单体式应用被打碎，传统泾渭分明的垂直应用架构逐渐演变成一张巨大的服务调用网络，应用的边界变得模糊，调用关系也越来越复杂。

在微服务环境下，运维面临更大的压力：

• 调用链条变长，系统出现问题时，如何在复杂的服务调用关系中快速定位到出错的节点？
• 应对突发流量需求，应对哪些服务扩容？
• 单服务容量变更后，如何评估对系统整体性能容量的影响？
• 微服务拆分导致故障点增多，如何进行故障预防和故障演练？

如何应对？浏览CNCF发布的云原生产品工具全景图，我们发现有一类名叫“Observability”（“可观察性”）的工具种类，包含prometheus、Grafana、Dynatrace、Datadog、Graphit、Librato等众多工具。它们的主要职责，就是让运维团队更容易理解和驾驭微服务环境，即使服务集群的组成节点、依赖关系、流量分布以及外部边界等都在快速变化，运维团队依然能够通过高度可视化系统，准确掌握系统的运行状态。因为Observability贯串整个云原生体系，足以证明“可观察性”在云原生体系中极高的地位。

本文不打算熬述这些工具的全部功能和技术原理，只挑选了一些可视化方面的优秀实践进行剖析，并从中总结出管理微服务所需的可视化方案。

3 微服务可视化的最佳实践

3.1 调用链路图

在一次800多人的开发者调研中，当回答“构建一个高可用的分布式系统，您遇到的三个最大的难题是什么？”时，57%的开发者选择了链路追踪。为什么呢？

举个简单的例子，有一天我发财了，一高兴给海春转100亿，但是在转账时，我的手机银行卡死了！于是我给银行客服打电话，客服一听也慌了，立即call后台运维。

运维人员怎么排查呢？对分布式系统的一次请求往往要调用多个服务，每个服务可能由不同的团队开发，使用不同的编程语言，部署在不同的主机或容器上，分布在不同的数据中心。要查清楚一次访问请求失败到底是哪个服务导致是非常复杂的事情。

但再难查也得查啊，100亿啊。怎么查？用链路图！

所谓调用链路图，就是从单笔交易请求视角，将该请求经过的所有服务接口以链路形式展现出来，同时展示每个服务接口调用的耗时和处理结果。最常见的可视化形式是瀑布流，以Zipkin为例：

通过这张图，运维人员能够清晰看到我这笔巨额转账请求的总耗时、调用了哪些服务接口、先后顺序是怎样的、每个服务接口的耗时和返回结果，这样就能快速判断出是卡在哪个接口了。

不过调用链路图也不一定非长成瀑布流的样子，比如Rocketbot就觉得瀑布流有很多问题，比如在时间线中显示接口名就不行，因为如果时间线较长，则上下游接口隔的很远，调用顺序就不直观，而如果时间线太短，又显示不下接口名。另外瀑布流也无法体现接口调用的协议类型。

为了解决这些问题，Rocketbot结合了瀑布流和树状图的特点，提供了一种更现代化的UI界面。具体做法是将服务接口与时间线剥离，效果如下：

这种效果已经非常棒了，不过Skywalking的最新版本中，又出现了一种更奇葩的展现形式。总体思路与Rocketbot类似，但采用了上下布局。这样的好处是顶部的时间线更长，因此能显示更大的时间窗口，中部的拓扑图让服务接口调用顺序更加清晰。同时用不同的颜色标识不同的服务类型，让人更容易理解服务接口的依赖关系，具体效果如下：

Skywalking的可视化好不好见仁见智，不过有些实用功能还是不错的，比如，可以高亮出最慢的五个span（点击Top 5 of slow span按钮）：

还可以高亮出children最多的五个span（子children越多，服务调用就越慢）：

在这个截图中，有一个包含13个children的span，这些children都是数据库访问，所以难怪这么慢！

总结一下：

从上面的例子我们会发现，如果要做单笔交易追踪，那么调用链路图是不可或缺的可视化工具，但由于数据粒度较细，需要一定的开发经验，而且还要有traceId才能生成链路图，所以使用起来不是很方便。它就像一个精致的外科手术刀，主要面向软件开发或测试人员做交易追踪及链路优化，不太适用于运维人员。

3.2 调用拓扑图

运维人员需要什么图呢？与外科手术不同，一线运维更像门诊，他们每天都要面对大量告警，虽然大部分告警不用特别关注，可一旦有疑似业务交易问题时，就必须尽快完成故障确认和定界，为二、三线团队做进一步诊断和处置留出时间（金融机构普遍要求30分钟内解决故障）。因此，一线运维不用手术刀，他们需要更简单、更直接（甚至粗暴）的故障诊断工具，而服务调用拓扑图就是他们最重要的工具之一。

所谓调用拓扑图，就是从更宏观的交易类型视角，将涉及的服务组件、组件调用关系以及外部依赖以有向图的形式展示出来，同时呈现每个服务的聚合指标（如，每分钟的交易量和成功率、平均响应时间等），从而帮助运维人员定界故障。

举一个相对真实的例子，有一天我给海春转200块钱，不幸的是我的手机银行被卡住了，于是我给银行客服打电话，银行客服很淡定，让我等几分钟后再试。后来钟宏、任磊、大圣、王导、娜姐等众人在转账时都出现挂死现象，这时银行客服觉得不对劲了，向IT服务台报警。一线运维接到告警后，会在第一时间打开“跨行转账”服务拓扑，我们以Appdynamics为例：

这个调用拓扑图非常简单直接，不需要交易流水和traceId，也不需懂代码调用逻辑，只需要输入交易类型（比如，跨行转账、网银登陆），就能获得完整的服务拓扑和每个服务的业务统计指标。比如上图我们发现Transfer-Fulfillment服务发生了交易成功率告警，那么就有可能是这个服务异常导致大量用户转账失败。

总结一下：

虽然调用链路图和调用拓扑图都用于分布式链路追踪，但调用链路图更像手术刀，能够从单笔交易视角展现服务接口的调用顺序和处理时长。而调用拓扑图更像门诊，直接从交易类型的宏观角度展现服务的调用顺序和统计指标。所以，它们有各自的适用场景和用户群体。

不过，不管是门诊还是外科手术，都是事后排查。这肯定不够，我们还需要定期对应用进行全方位的大保健，从而在问题发生前识别安全风险和故障隐患，这就需要更全局性的视图，一个能够体现分布式、微服务系统的整体架构和运维保障状态的视图。

3.3 应用架构可视化

应用架构图是指从应用系统视角，展示应用系统包含的所有服务节点、部署单元、依赖的外部服务。

通过在应用架构图上叠加管理和运行数据，能够帮助我们开展监控覆盖率分析、安全纳管率分析、架构高可用分析、性能瓶颈分析、故障演练等各项运维保障工作。

架构可视化做的不错的是阿里云的AHAS产品，根据不同角色对架构的关注重点不同，AHAS将架构可视化分为三个层次，从上到下依次为：进程层、容器层、主机层。

第一层：进程层（也可以理解为服务层）

进程层可以查看：

• 进程状态：CPU、内存占用情况
• 进程类型：主要分为Java应用、Webf服务、消息队列、数据库、云服务等
• 网络连接：包括入口连接（调用该进程的所有进程及端口）、出口连接（该进程调用的所有进程及其端口）

第二层：容器层

容器层可以查看：

• 容器信息：容器名称、状态、CPU、内存占用情况、重启次数、IP地址、容器端口、所属主机等
• 网络连接：包括入口连接（调用该容器的所有容器及端口）、出口连接（该容器调用的所有容器及端口）

第三层：主机层

主机层可以查看：

• 主机状态：CPU、内存占用情况
• 主机信息：主机名、OS版本
• 入口连接：调用该主机的所有主机及及端口
• 出口连接：该主机调用的所有主机及端口
• 容器镜像：主机上存放的容器镜像

不得不说，AHAS架构可视化是一款优秀的产品，很大程度解决了分布式环境下应用系统架构的混沌不可知问题。尤其在下面两个方面要点赞：

1. 分层设计原则：软件架构可视化的核心点是寻找在软件体系结构中有意义的元素及关系，一款优秀的软件架构可视化产品应该帮助用户排除掉不重要的信息，给用户呈现出对他们有价值的元素，特别是在微服务架构下庞大而复杂的调用关系链场景中。所以，阿里云将架构分为进程层、容器层、主机层是很有必要的。
2. 架构感知能力：为了最大限度上降低架构图的绘制和维护成本，阿里云通过采集用户主机上的进程和容器的元数据、监控数据以及网路数据，实现架构图的自动构建。不过要使用这个功能就必须将应用部署在阿里云上，还要安装AHAS Agent。

当然，再优秀的产品也有瑕疵，我认为这款产品最大的问题是架构布局能力较弱。毕竟架构图是给人看的，要符合人的视觉习惯。但AHAS在这方面做的不够，比如，无法体现两地三中心的地理结构、无法按Web-App-DB的逻辑结构组织架构元素、没有网络分区、无法体现非云化组件、无法换图标等。

在这方面，客观上说优锘的DMV在架构布局方面就非常强，其绘图的灵活性和便捷性甚至可以和Visio相媲美。比如下面是优锘DMV绘制的网络拓扑图和应用部署图。

上面两张图，架构元素可以根据需要显示在任意位置，以符合各种布局需求。多个架构元素可以组合成集群。另外，DMV还提供丰富的架构模板，只要输入应用系统名称，就能根据模板的布局规则自动生成架构图。

3.4 全景应用墙

应用架构图较好的满足了单个应用系统的运维管控需求，但格局还是不够。因为运维不仅关注个别应用的状态，也要掌握所有应用系统的保障和运行状态，这就需要全景应用墙了。

所谓全景应用墙，就是在一张巨大的“墙”上展示数据中心所有应用系统及其运行状态。比如Servicenow的应用墙：

这个应用墙由一个个方块组成，每个方块表示一个应用系统。方块的颜色表示该应用是否发生告警，方块的大小则代表应用使用的资源规模，规模越大，方块的面积越大。

全景应用墙常用来判断是否出现全局性故障，如果互联网出口、共享存储、ESB等公共服务出现故障，应用墙往往呈现祖国山河一片红的“盛况”，此时千万别慌，不要花时间逐个检查应用系统，赶紧排查网络和共享服务。

ServiceNow的应用墙是我见过的第二棒的应用墙，虽然如此优秀，但也有几个问题：

1. 当应用系统量太多的时候不好显示，尤其是大型金融机构动辄几百个应用系统的环境下
2. 业务领域和重要级别是比较重要的信息，但没有很好的体现出来
3. 当应用有告警时，无法呈现告警应用的业务指标，也看不到与其他应用的关联关系

针对这些问题，我们尝试做了一些改进：

1、取消了用面积表达IT资源规模，因为对一线运维而言，首要关心的是应用有没有告警，而不是资源的规模。同时，采用曲面屏设计，让屏幕能够容纳更多的应用。

2、引入了“重要性”和“业务领域”等多个信息维度，用于快速筛选出关键应用系统。同时提供了多种呈现形式，比如应用星系图就能很好的表达核心应用和外围应用的关系。

3、在全景应用墙上，悬浮可显示应用的关系，点击应用就能查看应用的APM数据和CMDB数据。

可视化的四个层次

CNCF告诉我们，在分布式微服务环境下，可视化将在运维中扮演更重要的作用。通过分析国内外优秀的产品和实践，我们发现可视化有脉络可循，从微观到宏观可以分为四个层次，每个层次都有其适用场景和用户角色：

这就是前面讲述的所有内容。到这儿本应该结束了，但不知道大家发现没有，有个地方似乎不太对？

理想上，这四层的可视化UI应该合成一个整体，但现在每个工具（不管是开源或商业）都是独立的，可视化模块与数据采集、分析紧耦合，比如，你要用Appdynamics的拓扑图，就得用他的Agent，你喜欢AHAS的架构图，就得上阿里云，你想用ServiceNow的应用墙，就要用它的SaaS服务。而且不同工具的数据无法互通，界面难以跳转。原本我们希望引入可视化工具来提升运维效率，却建设了一大堆分散独立的工具，以及由此带来的更多的数据孤岛和操作手册。

能否在这些工具之上构建一个统一的可视化界面，为用户提供更加一致、方便和人性化的使用体验呢？

4 IT数字地图

IT数字地图是我们构建统一IT管理界面的一个重要尝试，这个想法最初来源于地图。

在远古时代，人类渺小，世界辽阔。有了地图，人类才得以认知和征服了这个世界。现代社会，数字地图在人们日常生活中发挥着日益重要的作用。每天我们都会使用地图定位位置、探索周边、规划路径，地图已成为人们获取各类生活信息的核心工具。

既然地图在人们生活中能够扮演如此重要的作用，那么在IT的世界，我们能否利用IT数字地图来帮助我们更好的认知和管理这个世界呢？基于这个想法，我们开展了IT数字地图的尝试。

IT数字地图充分借鉴了谷歌和百度地图的设计思想，比如，分层设计、无缝缩放、局部加载、线路规划和兴趣点等等。

4.1 分层设计

我们知道，电子地图是有层级的，一般分为：国家级、省级、市级和街道级。这种分层的好处不言而喻，信息简洁易懂。

所以IT世界地图也借鉴此设计，我们将IT地图分为四大层级：业务架构层、应用架构层、部署架构层、资源运行层。

我们以金融行业为例：

第一层：业务架构层

业务架构是业务与IT的桥梁，定义了应用系统的业务能力，从概念层面帮助IT人员了解应用系统的定位、用途和重要性，在叠加APM监控数据后，也可以用来做多应用告警时的故障定界，因此我们将其作为IT世界地图最顶层图层。

业务架构图的主要元素是业务领域、应用系统以及应用系统间的调用关系，示意如下：

第二层：应用架构层

应用架构用来描述应用系统的功能边界，定义了应用系统由哪些服务组件构成，以及它们之间如何分工、协作。

应用架构图一般有两种风格，一种是按功能处理顺序将系统分为Web前端、中间服务、后台数据存储，常见于传统单体式应用架构。另一种是按业务类型划分，比如支付服务、对账服务、额度控制服务等，一般微服务应用是这种风格。

第三层：部署架构层

部署架构定义了应用程序如何安装、部署到现实的IT环境中，以及数据如何在网络中传递和保存。

部署架构图应该体现部署的物理位置、网络分区、部署单元、集群模式、访问协议等等。

第四层：资源运行层

资源运行层用于展示应用程序部署完成后形成的资源实例，包括容器、主机、DB实例、MQ实例、NAS存储实例、FW实例、SSL实例等等。

4.2 无缝缩放和局部加载

用过谷歌地图的同学都知道可以通过缩放操作实现图层切换，体验是那么的顺畅、自然。但只有看过《Google Maps的故事》才知道，这背后依靠的技术是Clipmapping。Clipmapping能把不同分辨率的图像合并起来，在用户进行缩放操作时提供“无缝”的体验。1999年，Michael Jones、Chris等人首次将Clipmapping技术应用到地图上（他们称其为City-Fly），当时所有人都震惊了，原来地图还可以做得这么炫！不过，除了炫酷外，City-Fly还实现了地图数据的局部加载功能，即，用户不必下载所有的数据就可以看到自己感兴趣的内容，这就是“弱水三千，只取一瓢”。对于地图这样的海量数据而言，这项技术再合适不过了。

受到谷歌地图的启发，我们也投入大量精力研究如何将Clipmapping技术应用到IT数字地图上。但现实地图和IT地图有一个巨大的差别，那就是现实世界中的物体有真实坐标且相对固定，所以不同比例的图像可以事先绘制好。而IT世界的物体没有坐标，还随时在变！所有物体的位置都要用算法自动生成！在经过大量的实验和挫折后，我们改变了Clipmapping的实现方法，将现实世界“下层坐标决定上层布局”的逻辑改成了IT世界“上层布局决定下层坐标”的逻辑。后来又经过无数次验证，终于研发出适用于IT数字地图的无缝缩放和局部加载技术，我们称其为IT-Fly。

4.3 线路规划 vs. 链路追踪

只有无缝缩放和局部加载还不够，为了增加IT数字地图的使用价值，我们实现了链路追踪功能。

链路追踪的设计参考了数字地图的路径规划功能。在数字地图中，我们只要输入目的地，数字地图就会自动规划出行路线。同样，在IT数字地图中，我们只要输入交易码或TraceId，就能在地图中现实完整的调用路径。

4.4 兴趣点(POI)

光有路径还不够，我们在排障时还需要查看路径中每个节点的信息。

借鉴数字地图中POI（Point of Interest）的设计思想，一个POI可以是一栋房子、一个商铺、一个邮筒、一个公交站等。每个POI包含四方面信息，名称、类别、坐标。

我们在IT数字地图中也引入了POI。每个POI都是一个IT管理对象，它包括四类信息：配置信息、指标信息、告警信息和工单信息。这些信息对于链路追踪、性能优化、变更分析非常重要。

4.5 IT数字地图的边界

要在日常工作中使用IT数字地图，就必须满足不同管理场景的数据和功能需求。这就引出一个新问题，你的功能边界在哪里？

我们认为，IT数字地图应该定位成开放的地图服务，就像百度、高德地图一样，既能独立使用，也能嵌入到美团外卖、滴滴打车等应用中，这是IT数字地图与其他运维可视化工具最大的区别。

对此，我们给出了三条产品原则，以确保IT数字地图能够按照既定的设想成长：

1. IT数字地图只做数据可视化，不介入数据采集、处理和分析（这些能力由专业的运维工具提供）；
2. 为了降低构建成本、提升地图效用，应重点打造的辅助功能包括：数据建模、数据接入、数据整合及大数据存储能力，只有打通各个专业运维工具的数据孤岛，才能实现一站式的数据可视化服务；
3. IT数字地图应提供丰富的可视化API和URL调用能力，以方便其他运维工具使用并在此基础上开发定制化功能。

基于这个设计原则，IT数字地图的功能架构如下：

具体功能就不多说了，这是我们在IT数字地图方面的一些实践，目前还处于起步阶段，还有很大的优化空间，欢迎大家批评指正。

写在最后的话

在IT管理领域，IT数字地图是全新的探索，国内外没有类似产品可以借鉴。我们为什么要做这种前无古人的事情？

正如任正非所言：“我们对客户需求的理解不能狭窄,不要以为客户说出来的是需求. 其实客户需求是一种逻辑学和哲学,是人性的持续激活与成长,是人类文明发展的必然趋势。”

我们认为，IT数字地图能够给枯燥、繁琐、危险的运维环境中带来一丝人性，符合运维发展的必然趋势。虽然现在只是一个遥远的梦想，但优锘愿意为此奉献自己的智慧和青春。可视化是一个伟大的事业，路漫漫其修远兮，吾等上下而求索。