某银行基于容器云的应用服务架构实践

字数 6967阅读 5055评论 2赞 14

内容摘要：

银行基于容器云架构，通过SkyWalking和CMDB建模实现应用链路数据全局拓扑关系，提高运维效率和准确性。自动化处理数据并调用CMDBAPI接口完成资源和关系创建，未来可加入性能数据、回撤功能等。

当前摘要为AI生成

# 1 研究背景

## 1.1 发展现状 
**1.1.1 容器云平台 **
我行生产环境使用的永定云平台是一个基于 K8S 开源软件自研的管理平台，承载了分布式核心、柜面等九十余个容器化应用系统，通过集成 SkyWalking、ELK 等云原生开源组件，实现了日志、监控等基础运维能力，但是微服务之间的调用关系不能一目了然。

**1.1.2 SkyWalking **
目前我行容器云APM监控工具采用SkyWalking，可以提供分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案。下图是SkyWalking 追踪到的链路图示例，它可以展示出应用之间的关系及一些性能指标，但是单个微服务和其他服务之间的拓扑关系只能显示一层，所以这些服务的从属关系和依赖关系不能清晰地展示。

![](/home/attachment/202302/27/1239753_167749189284070.png)
** 1.1.3 CMDB配置管理库 **
我行的综合数字运营平台是定位于支撑运营中心数字化转型的核心平台，存储了从应用系统到各类软硬件资源的运维主数据。下图是平台上的CMDB配置管理库中的一个拓扑关系图，图中可以看到，CMDB中可以展现出容器上的各种资源信息以及这些资源间的关联关系。虽然能展示CMDB已有的资源数据，但本平台却无法聚合链路追踪等其他数据，比如应用之间的关系。
![](/home/attachment/202302/27/1239753_167749191622205.png)

##  1.2 存在问题
在对以上平台和工具的学习和调研过程中，本研究发现运维工作中存在一个比较普遍的问题：在跨领域、跨业务的运维工作中，很容易会不清楚一个服务的上下游服务是什么，服务依赖了哪些基础设施，这些基础设施的运行状态如何等等的问题。 比如在柜面系统的运维工作中，新入职的运维人员在永定云平台发现pod异常，在判断影响范围的时候，因为不熟悉这个架构，也许会去SkyWalking进行查找。但是从 SkyWalking 只能看到当前一个微服务的链路，如果想知道链路里的某个数据库的具体信息，比如维护人员是谁，还要再去CMDB配置管理库中进行查找。所以这个问题增加了跨领域、跨业务之间的工作难度，因为它只能依赖于运维人员的个人能力和经验积累，而对于一个团队来说，仍然是一个难点。 再加上我行容器云技术覆盖的业务越来越多，微服务、开源中间件等新一代技术架构不断演进；容器化后的应用软件、部署组件数量急剧增长，而且部署架构分散。如果每次都如上述那样去操作，会增加很多工作量，所以基于云原生和CMDB理念的数字化运营需求越来越明显。

## 1.3 研究目标
 （1） 采集行内现有容器云平台的开源链路追踪工具中应用链路数据的拓扑关系；
 （2）结合现有CMDB平台缺失的拓扑关系，进行CMDB建模；
 （3）将应用链路数据注入CMDB模型，生成应用系统的全局拓扑关系 。

##  1.4 研究架构
 本研究的架构如图所示：
![](/home/attachment/202302/27/1239753_167749194297938.png)

（ 1） 从SkyWalking中采集数据，得到应用链路数据；
 （2）将拿到的链路数据，一方面通过数据加工，进行数据格式转换；
 （3）另一方面通过数据分析，进行CMDB模型设计，然后在EASY平台的模型管理模块去构建模型，在构建模型的时候，也要依赖于加工好的数据格式；
 （4）在建立好数据模型之后，将加工好的数据注入到模型中，得到链路层数据；
 （5）结合CMDB配置管理库中已有的资源层数据，一起生成应用架构全景图。

##  1.5 技术路线
 本研究的技术路线分为获取应用链路数据、搭建模型和创建资源，建立关系三部分，具体如图所示：
 ![](/home/attachment/202302/27/1239753_167749200779384.png)
 
# 2 技术实现 
## 2.1 获取SkyWalking中应用链路数据 
从SkyWalking获取应用链路数据的实施方案设计基于SkyWalking底层架构，如下图所示。
![](/home/attachment/202302/27/1239753_167749203336242.png)

SkyWalking OAP（Observability Analysis Platform）接收链路追踪数据Tracing与服务性能监测数据Metric，之后这些数据交由Analysis Core进行分析处理后并存储至可配置的存储介质中，如ElasticSearch、MySQL等。OAP中的QueryCore组件从存储介质中读取数据，并暴露出基于GraphQL的查询接口供OAP外部应用来查询。

### 2.1.1 Query Protocol 
 Query Protocol是Sky Walking基于GraphQL设计的查询协议，即根据GraphQL语法规则定义的一组API，使得SkyWalking原生的可视化界面或第三方系统能够进行对链路数据的查询和实现与SkyWalking进行交互的功能。如下图所示所示为拓扑关系的查询API。
![](/home/attachment/202302/27/1239753_167749205578745.png)
 本研究主要使用到Query Protocol的getGlobalTopology以获取SkyWalking捕获到的全局拓扑关系数据。

**2.1.2 全局应用链路数据获取 **
 在经过对Query Protocal和GraphQL的学习之后，通过Postman模拟给SkyWalking发送查询全局拓扑的请求。下图则是Postman模拟发送请求的界面。query是GraphQL的操作类型，queryServices是操作名称，topo为Query Protocal API的getGlobalTopology的别名。nodes和calls是描述需要从QueryCore中获取服务节点的对象和节点之间关系的关系对象的格式。右侧的duration是getGlobalTopology的参数。
![](/home/attachment/202302/27/1239753_167749207898914.png)

本研究搭建了基于SpringBoot的定时任务工程，并于每日凌晨三点获取应用链路数据。下图是获取应用链路数据的核心代码的展示，可见构建了OAPClient类，并将它作为组件注入到Spring容器中，同时对需要访问的SkyWalking的接口地址做了统一配置。在queryGlobalServiceTopo这个方法中，用一个字符串定义了适配SkyWalking的请求体，之后通过HttpClient发送Post请求完成查询。
 ![](/home/attachment/202302/27/1239753_167749210557546.png)
 
** 2.1.3 应用链路数据——以niu-aase-te-composite为例**
获得到的数据如下两图所示，这里也是以柜面系统中niu-aase-te-composite这个服务为例，在这里对展示的数据做了一定的删减。获得到的应用链路数据的核心数据结构是nodes数组和calls数组，nodes中的每一个node都具有自己的id，名称和类型，本研究后续的分析和建模主要需要name和type属性，calls数组中每一个call对象描述了节点之间的关系，source代表一个调用关系的起始节点的id，target代表目的节点的id，这两个属性是后续构建关系的重要依据。
![](/home/attachment/202302/27/1239753_167749212636346.png)

##  2.2 搭建模型   
现有CMDB配置及服务间的依赖关系基本体现在容器云架构及资源上，不能完整地展现服务的上下游依赖关系。为了生成相对完整的服务全局拓扑关系，打通CMDB与SkyWalking之间的连接，需要在CMDB平台中建立与SkyWalking对应的模型，从而可以提供全局浏览链路数据的渠道，快速定位链路中存在的问题；大幅度减少问题响应的时间，提高运维效率和准确性。 通过调研，课题组发现利用SkyWalking可以清楚地观察到服务节点及其之间的关系，可以应用这些数据建立节点与关系，补充云上资源配置与云下设备的关系，以及服务与服务之间的连接，使CMDB的配置资源关系更加完整。 所以课题组的工作目标是在CMDB平台原有资源关系的基础上，建立模型将SkyWalking的应用链路数据补充进CMDB平台，进一步提高CMDB配置资源关系的完整性。 为了将SkyWalking中的服务节点与CMDB平台中的资源配置产生关联，建立模型的工作主要分为以下三个步骤进行： 
**（1）建立新增服务节点类型 **
首先对下图中给出的SkyWalking中柜面服务节点的链路关系图进行分析，将其中的服务节点抽象为三种类型。
![](/home/attachment/202302/28/301729_167755001151072.png)

下图给出了服务节点的分类结果，分别为K8SService服务节点、K8SIngress服务节点和ojdbc服务节点，并分别定义其类型名称和类型编码等资源属性。
![](/home/attachment/202302/27/1239753_167749239279251.png)

** （2）建立不同服务节点类型之间的关系 **
如下图所示，通过对SkyWalking中链路关系的分析，在K8SService服务节点的下游分别建立了与ojdbc服务节点、K8SIngress服务节点和K8SService服务节点的N:N连接关系。

![](/home/attachment/202302/27/1239753_167749241430852.png)
** （3）建立服务节点与已有资源之间的关系 **
如下图所示，K8SService服务节点与K8SIngress服务节点分别以N:1归属于K8SService与K8SIngress资源节点，另外ojdbc服务节点同样以N:1归属于Oracle数据库实例。通过这一步可以将新增服务节点与CMDB平台中的原有资源产生联系，从而追踪到范围更广，节点更多的拓扑关系。

![](/home/attachment/202302/27/1239753_167749243184932.png)

完成上述三个步骤之后，可以得到下图所示的拓扑关系图，其中绿色节点和绿色连接线为新增的服务节点和新增关联关系；红色节点和红色连接线表示已有的资源节点和已存在的关系。可见通过新增的服务节点和关系，可以实现K8S容器云资源和云下数据库的连接与关联。

![](/home/attachment/202302/27/1239753_167749244996006.png)

## 2.3 创建资源建立关系 
 上述章节已经对SkyWalking中的niu-aase-te-composite的应用链路数据和相应的CMDB建模工作进行了详细的介绍。由于两个系统独立运行，在成功获取SkyWalking的应用链路数据并 完成CMDB建模的基础上 ，还需要手动建立数据字典，将SkyWalking和CMDB的数据相关联，然后将SkyWalking的数据存入到CMDB平台中。

### 2.3.1 建立数据字典 
 为了将SkyWalking服务节点名称与CMDB资源相关联，需要预先建立两个字典。第一个字典为SkyWalking中的服务节点名称到CMDB中现有资源的唯一映射。其中柜面系统的字典如下表所示。
![](/home/attachment/202302/27/1239753_167749250095564.png)

第二个字典为SkyWalking中的节点名到CMDB目标类型构成的字典。即根据SkyWalking的数据去CMDB中新建服务节点时所对应的类型编码，该类型编码为CMDB建模时指定。其中柜面系统的字典如下表所示。

![](/home/attachment/202302/27/1239753_167749252327125.png)

### 2.3.2 数据转换与保存 
 对于拿到的SkyWalking数据，本研究通过程序完成了对应用链路数据的自动化处理，并通过调用CMDB平台所提供的API接口，完成资源和关系的创建。

当前在CMDB中已经存在与柜面系统相对应的应用资源，从CMDB中可以看到该应用资源及其背后的基础设施情况，如该应用运行在哪台服务器上、服务器在哪个机柜中，但是无法查看应用之间的访问关系。需通过以下三步来创建相应的资源及关系。对应的各阶段链路信息如下图所示。
 
![](/home/attachment/202302/28/301729_167754989594694.png)

** （1）服务节点创建 **
首先需要根据从SkyWalking中获取的节点数据，在CMDB中创建一个新的服务节点。根据name和classCode这两个属性就可以完成创建一个新的服务节点。创建完成后，CMDB会返回资源id，即所创建的服务节点在CMDB中的唯一标识符。

**（2）创建服务节点与现有资源的关系 **
为了使新创建的服务节点与CMDB已有的资源相关联，要在二者之间创建“归属于”的关系。需先根据字典数据，向CMDB查询目标资源的id，然后与上一步的所返回的id构建关系。二者之间的关系为新创建的服务节点归属于原有资源，此编码为在CMDB平台中建模时由系统随机生成的编码。

**（3）创建服务节点之间的关系**
 最后，根据SkyWalking中的应用链路数据，构建CMDB中新创建的服务节点之间的访问关系。可以根据SkyWalking中的id间接获取到它所对应的资源在CMDB中的id。最终完成链路关系的建立。

其中整体的关系创建图如下图所示。
![](/home/attachment/202302/27/1239753_167749261643413.png)

# 3 成果展示
 下图是课题最终得到的全局拓扑图。这些灰色节点 是 CMDB 中原有的资源和关联关系，根据 SkyWalking 中采集到的链路数据， 本研究 在 CMDB 中对这些资源进行创建 （红色节点），最后再创建这些红色节点之间的关联关系，以及红色节点与灰色节点之间的关联关系。

![](/home/attachment/202302/27/1239753_167749263633697.png)

# 4 总结与展望

##  4.1 总结
 （ 1 ） **采集拓扑关系** ：本研究在现有 CMDB 配置数据建模的基础上，采集开源链路追踪工具中应用链路数据的拓扑关系。
 （ 2 ） **生成全局拓扑关系**：对现有 CMDB 服务、中间件以及底层物理设备的依赖关系进行分析，结合新采集的拓扑关系，生成服务的全局拓扑关系。
 （ 3 ） **提升了运维效率和准确性**：解决了运维过程中的 “ 盲人摸象 ” 问题，实现当选择一个服务后，可以看到这个服务的上下游依赖关系，还能看到服务所关联的容器、虚拟机、中间件、数据库以及底层物理设备机房环境的信息以及运行状态。

##  4.2 展望
 在研究过程中发现了很多待优化的方面，比如：
 （ 1 ） **加入性能数据**：把 SkyWalking 工具中捕捉到的监控网络通信间的性能数据也保存在我们构建的资源中，比如响应时间和吞吐量。
 （ 2 ） **加入回撤功能**：对已经创建好的模型、资源以及关联关系，通过编程实现一键回撤的功能。
 （ 3 ） **拓展关系类型**：对于资源之间的关联关系，后续会继续创建更多的类型。
 （ 4 ） **数据动态更新**：实现服务节点运行状态的更新功能。
 （ 5 ） **自动更新数据字典** ：致力于实现从 SkyWalking 到 CMDB 数据字典的自动化更新。
 （ 6 ） **对接其他监控平台**：对接 SkyWalking 和听云的链路追踪数据，结合 CMDB 信息统  一展示。
 （ 7 ） **接入一体化监控平台**：可以结合 aiops 技术，创建数据分析模型，将聚合的数据进行自动化分析，提取有用数据。

在以后的工作中，如果有机会继续完善这个课题，我们会结合实际工作，更好的落实这些想法。也希望这次课题经历，可以为我行的运营工作数字化转型提供一些新的思路和经验。

skywalking 容器云监控 Kubernetes

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！