阿里巴巴在微服务系统下架构可视化方面的探索

导读：采用微服务架构后，了解服务之间的关系及依赖是一个比较有挑战的问题。微服务改造后的实际架构模型可能与预想的架构已经存在很大的差异，架构师或系统运维人员需要精确地了解资源实例的构成和交互情况。阿里巴巴在管理微服务方面具有丰富经验，本文总结了阿里巴巴工程师在微服务可视化方面探索。

作者简介：严明明(花名：心远)，阿里巴巴集团安全生产高可用架构组高级开发工程师，阿里云『应用高可用服务AHAS』研发负责人。曾创业开发跨境电商系统，2011年加入淘宝，长期关注Chaos Engineering 混沌工程。

为什么需要架构可视化

随着企业进行微服务架构改造，系统架构复杂度越来越高，架构变化日益频繁，微服务改造后的实际架构模型可能与预期已经产生了巨大差异，架构师或系统运维人员很难准确记忆所有资源实例的构成和交互情况；其次，系统架构在动态演化过程中可能引入了一些不可靠的因素，比如弱依赖变强依赖、局部容量不足、系统耦合过重等，给系统的稳定性带了极大的安全隐患。所以我们每次在面对系统改造、业务大促以及稳定性治理工作之前，都会通过梳理架构图的方式，呈现系统架构中个组件之间的交互方式，架构可视化能够清晰的协助我们识别架构中存在的问题以及建立高可用的系统。

（Daniel Woods 在讲微服务时时的一张架构图）

架构可视化后，可以给我们带来以下几点但不局限于此的优势：

• 确定系统边界

  一张好的架构图，应该明确系统所包含的各个组件以及各个组件之间的核心调用关系，这些组件的集合就是系统的处理边界，系统架构的边界在一定程度上也反映了业务域的边界。

• 架构问题识别

  基于高可用的架构准则，结合可视化的架构图，可以评估架构可能存在的安全风险，比如系统在容灾、隔离以及自愈维度下的健壮性。其次，一些架构链路可视化工具(比如鹰眼)在实际工作中确实大大提高了开发者排查与定位问题的效率。

• 提高系统可用性

  有了系统架构的上下游依赖关系图，在故障发生时，开发人员可以借助依赖数据快速定位到问题的来源，极大缩短问题修复时间（MTTR）。借助架构图，我们还可以梳理出系统中存在的强弱依赖，在业务高峰期对弱依赖进行降级，或者针对系统依赖的各个组件进行故障模拟，以评测系统整体在面对局部故障的可靠性。

常见架构可视化的做法

我们熟知的架构图是静态的停留在PPT上的，很多时候我们的架构已经发生了非常大的变化，但是我们还在使用那张看上去很经典却早已过时的架构图。长时间使用与实际架构不符的架构图对线上架构的认知的危害是巨大的，我们需要在脑海中不断更新对系统架构的视图，以保持对系统架构的敏感度。每年的大促或者重大系统改造成为我们梳理系统架构、对架构进行重新认知的机会，此刻我们需要通过各种 工具 查看系统的各个组件分布以及不同组件的内部与外部的依赖关系，这种梳理架构图的方法是最常用的方式，权且称之为“手工绘制法”。

手工经常干的事情，就有追求效率的同学使用计算机系统带来的自动化手段帮助自己做这件事情，比如我们常常看到的基于数据埋点的微服务可视化解决方案，这类架构可视化手段通常在分布式追踪、APM等监控领域使用较多，下图为某APM产品提供的应用维度架构可视化方案：

我们称这种可视化方式为“埋点式感知法”，架构组件的识别是依赖关键的核心类检测与埋点，此种方案存在以下弊端：

• 语言相关性：只要是系统埋点，与语言相关的特征基本就拜托不了，需要针对不同语言提供不同的依赖包；
• 不易维护：因为是对核心类的检测，当组件包做了重大变更时，需要同步变更；
• 不易扩展：因为是客户端识别方案，客户端一旦开放出去，新组件的支持只能等待用户更新组件；
• 规模受限：客户端识别的另一个缺点是算法受限，服务端进行识别，可以借助大数据分析等手段更有效准确的识别；

还有一种自动化架构感可视化方法，我们称之为“无界架构感知”，是一种语言无关性的架构识别方案，其采用采集用户主机上的进程和容器的元数据、监控数以及网路数据的最最基础的数据，在服务端构建架构图。

架构可视化还能怎么做

为了最大限度上降低用户进行架构可视化的成本，我们采用了应用无侵入的方式对微服务进行可视化，通过采集进程数据与网络调用数据，构建进程间的网络调用关系，构建微服务的架构信息。

如何让架构可视化更有效？

我们同样认为架构可视化的有效性跟人的认知层次有关，架构可视化的重点是确定该工具是否更好的支持自顶向下方法、自下而上方法或者两者的结合。开发者更关心应用维度上的架构，架构师或者管理者更关心整体系统架构。所以需要针对不用的使用者提供不同层次的架构可视化视角。理想的架构图需要支持宏观维度以及不断下钻下的微观视角，我们对架构进行了分层设计，目前分为进程层、容器层和主机层，后期我们可能会继续上扩或者下钻支持地域层或者服务层。

下图为一台阿里云ECS上实现架构可视化后的三层架构界面：

应对架构的可变性

没有哪家科技公司的系统架构是一成不变的，系统架构会随着系统的版本迭代不断进行演化。所以对架构可视化操作，还需要具备随着时间的推移可对架构信息进行自动更新已经回溯的能力。在我们提供的架构感知产品中默认架构图会随着时间自动刷新，同时支持对历史的回溯，你可以选择历史中的某一刻查看架构信息，比如，重大版本的变更时，发布前与发布后的系统架构是否发生了违背一些高可用原则的问题，抑或排查是否出现了不该有的依赖问题。

架构可视化的核心

软件架构可视化的核心点是寻找在软件体系结构中有意义和有效的元素视图以及这些元素之间的关系。我们认为一款优秀的软件架构可视化产品应该帮助用户排除掉不重要的信息，给用户呈现出对他们有价值的视图，特别是在微服务架构下庞大而复杂的调用关系链场景中。这里面的核心点是有意义和有效，要做到这两点，首先需要识别什么是有意义和有效的元素和关系，我们在此领域做的事情归纳起来就是“识别”，识别机器上的每个进程是什么，发生的网络调用远端是什么，唯有知晓了这些元素是什么我们才有理由和依据来判断是否对用户有意义以及其在用户架构中的重要程度。

架构可视化中的元素识别

在梳理了大量架构图，我们发现用户关心的架构元素主要分为三类：

1. 自己的应用服务；

2. 应用对外部的资源依赖；

3. 服务器本身的信息。

应用对外部资源的依赖通常以其它应用和通用中间件或者存储服务两种形式存在。故我们将需要识别的进程分为：应用服务和常见的组件服务（比如 Redis 、 MySQL 等），这些组件服务又分为用户自建的服务和使用公有云提供的服务，特别是对于Cloud Native应用来说，云服务的识别显得格外重要。

目前，我们已经实现了包含Redis、MySQL、Tomcat等常见的21种三方服务组件的识别，此组件库还在不断扩张中，目的就是最大限度的知晓架构中的元素到底是什么。

（图中展示了节点详情的请求流向以及节点的监控等基本信息）

(图中展示了识别的主机上的部分进程信息)

有了架构可视化还能做什么

架构可视化不是目的，只是实现系统高可用性的手段。借助架构感知采集到的架构数据，在识别了使用的组件（我们对MySQL、Redis、MQ等的统称)后，我们借助这些组件以及与组件匹配的故障库，会自动发现这些组件可能遇到的故障，从而更方便地对组件进行各种故障的模拟与演练，以提高系统的健壮性。其次，通过架构感知识别Java Application 应用，如果发现其负载较高，配合一些限流降级组件，可以提高服务的可用性。

（如何借助架构感知进行系统限流配置）

架构可视化是我们给用户提供的高效运维和管控的窗口，我们期望通过丰富的云原生数据体系配合架构图的可视化以及可操作性，建立起以应用为中心的运维一体化平台。在未来，我们会在架构可视化上加入监控和容器服务，以丰富架构感知的数据维度；其次，会在数据的深度挖掘和智能化消费上投入更多精力，真正让数据成为企业的核心价值，让数据成为保障业务的稳定性的利器。

转载本文请注明出处，技术原创及架构实践文章，欢迎通过公众号菜单「联系我们」进行投稿。

高可用架构改变互联网的构建方式

长按二维码 关注「高可用架构」公众号