微服务架构可视化平台实践

为何须要架构可视化

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

架构可视化后，能够给咱们带来如下几点但不局限于此的优点：

• 肯定系统边界
  一张好的架构图，应该明确系统所包含的各个组件以及各个组件之间的核心调用关系，这些组件的集合就是系统的处理边界，系统架构的边界在必定程度上也反映了业务域的边界。
• 架构问题识别
  基于高可用的架构准则，结合可视化的架构图，能够评估架构可能存在的安全风险，好比系统在容灾、隔离以及自愈维度下的健壮性。其次，一些架构链路可视化工具(好比鹰眼)在实际工做中确实大大提升了开发者排查与定位问题的效率。
• 提升系统可用性
  有了系统架构的上下游依赖关系图，在故障发生时，开发人员能够借助依赖数据快速定位到问题的来源，极大缩短问题修复时间（MTTR）。借助架构图，咱们还能够梳理出系统中存在的强弱依赖，在业务高峰期对弱依赖进行降级，或者针对系统依赖的各个组件进行故障模拟，以评测系统总体在面对局部故障的可靠性。

常见架构可视化的作法

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

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

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

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

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

咱们设计架构可视化的理念

为了最大限度上下降用户进行架构可视化的成本，咱们采用了无界架构感知-应用无侵入的方式微服务进行可视化，经过采集进程数据与网络调用数据，构建进程间的网络调用关系，构建微服务的架构信息。用户只须要安装咱们AHAS Agent探针，便可完成架构可视化操做；对于阿里云云原生系统，咱们提供了自动化安装方式，而无需登陆机器。

核心本质

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

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

1. 本身的应用服务；
2. 应用对外部的资源依赖；
3. 服务器自己的信息。 
   应用对外部资源的依赖一般以其它应用和通用中间件或者存储服务两种形式存在。故咱们将须要识别的进程分为：应用服务和常见的组件服务（好比redis、mysql等），这些组件服务又分为用户自建的服务和使用公有云提供的服务，特别是对于Cloud Native应用来讲，云服务的识别显得格外重要。

目前，咱们提供了20种阿里云云服务的识别以及包含mysql、redis、Tomcat等常见的21种三方服务组件，此组件库还在不断扩张中，目的就是最大限度的知晓架构中的元素究竟是什么。

架构分层

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

架构回溯

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

可见可得

架构可视化解决了可见的问题，但当咱们从架构图中发现了问题须要解决时，架构图还应该给咱们提供便利的可交互操做入口，让咱们能够完成问题发现与解决的闭环。好比经过架构感知监控到了某个应用的流量很是大，咱们须要对应用进行限流或者预案，那么经过架构图，咱们应该是能够完成咱们指望执行的操做。在架构图中融入能够交互的运维操做，让咱们从看到到操做，再到问题恢复后体如今图中，这就像计算机发展史上从命令行视图到窗口视图的转变。

咱们对架构可视化的定位

__架构可视化不是目的，只是实现系统高可用性的手段__。借助架构感知采集到的架构数据，在识别了用户使用的组件（咱们对mysql、redis、mq等的统称)后，咱们借助这些组件以及与组件匹配的故障库，能够给用户自动推荐这些组件可能遇到的故障，配合咱们提供的评测服务让用户更方便地对组件进行各类故障的模拟与演练，以提升系统的健壮性。其次，经过架构感知识别Java Application 应用，若是发现其负载较高，配合咱们提供的限流降级（阿里巴巴开源的Sentinel商业版）功能，为服务的持续可用性保驾护航。

咱们对AHAS的定位是一款数据分析型的高可用保障产品，帮助云原生架构系统实现高可用能力的提高。架构可视化是咱们给用户提供的高效运维和管控的窗口，咱们指望经过丰富的云原生数据体系配合架构图的可视化以及可操做性，创建起以应用为中心的运维一体化平台。在将来，咱们会增强与其它云服务的集成，好比监控、容器服务，以丰富架构感知的数据维度；其次，会在数据的深度挖掘和智能化消费上投入更多精力，真正让数据成为企业的核心价值，让数据成为保障业务的稳定性的利器。

---

本文做者：心远

阅读原文

本文为云栖社区原创内容，未经容许不得转载。