mysql系统云结构图_腾讯梁定安解密织云系统！（附架构图）

● 4.1织云的核心模块

织云的技术架构，如图3所示。

图3  “织云”的技术架构

织云门户提供用户(开发、测试、运维)协作的管理操作页面，也是作为后续功能的入参来源，这部分配置信息无法自动获取，需要人工进行一次性的初始化环境配置。

决策系统，流程系统，是相互配合的两个功能模块，主要是根据一定的信息分析、判断，识别出异常，触发不同流程，全自动化地完成特定场景的运维操作功能。

工具库，继承织云平台之前运维工具/系统建设的成果，为流程引擎输出不同工具能力的支持，流程引擎则负责在不同的工具间传递参数，使工具间能够有效的配合，有顺序、有逻辑的进行拼接，从而自动化地完成运维预先定义好的操作流。

工具库调用的具体子系统有很多，图中只是列举了部分常用的系统。以权限中心为例，它是一个业务权限管理系统，负责按IP集群管理其对一些敏感业务权限的增、删、改、查功能。业务权限在腾讯服务中是个很普遍的需求，因为腾讯很多业务都是基于QQ平台而延伸出来的社交社区，这些社区/服务依赖于QQ关系链、QQ昵称、好友生日等等重要数据信息，腾讯内部对于不同的敏感数据都有权限管理，权限中心则负责实现权限管理的自动化。

命令通道，这是运维通用的一个管理服务器的传输和执行命令的关系，支持大批量文件传输、命令的远程解析和执行。

CMDB将运维预先定义的标准化管理对象作为标准配置项记录下来，为流程、工具、一致性监控提供配置接口，是所有自动化运维操作的数据源，底层支撑数据。

CMDB的数据来源分为基础配置和业务配置。基础配置相对是固定的，与运维操作关系不大的，如CPU、内存、硬盘等硬件信息，又如IP归属的机房、分布等地域分布信息，还如设备运营状态、响应级别等运营配置信息。业务配置包含了运维对生产环境操作时，相关的一些业务属性配置信息，可以理解为，包信息(进程端口)、业务、路由、域名等，又如相关的流程、相关的测试用例、相关的决策配置信息等。

一致性监控，负责对生产环境与CMDB中的配置记录进行对比，保障数据库中的配置和生产环境中的现场的一致性，从而确保每次变更都是准确无误的。

● 4.2 织云的工作原理

织云的工作原理由标准化-CMDB-流程系统-生产环境四部分构成。

标准化

腾讯SNG运维对上线服务的程序提出有可运维规范的要求，并以此作为衡量业务标准化程度。首先，我们要理清标准化涉及的对象有哪些。

图4  标准化涉及对象

图4列举有很多不同的对象(未枚举完)，以机型举例说明标准化的重要性。我们将不同的设备使用场景划分成为不同机型的使用需求，如CPU计算型，一般用于web、逻辑层，我们就统一用C1支持(配置：CPU8核内存16G硬盘200G)，其他的还有内存型设备，存储型设备(ssd、普通硬盘)等。统一设备可减少运维在生产环境的管理对象，降低设备在不同业务之间的复用难度，提高复用率，对企业的运营成本管理，资源的高效利用，都有很重要的意义。

其他不同的标准化对象也是一样的道理。设置标准化的出发点就是为了减少运维对象，降低运维管理生产环境的复杂度，更有利于运维抽象出共性的系统工具来管理这些标准的运维对象。

有了运维管理对象的范围后，便可以设置可运维规范了，如图5所示。

图5  可运维规范

这里规范很多，有流程性的要求，有操作配置的要求，但是所有的规范都要求在生产环境的运维活动中被严格执行(图6)，以保证生产环境的标准化。

图6  生产环境的运维活动

运维对象遵循可运维规范，落地到对应的运维工具系统中管理起来，最终被作为CMDB的配置项记录下来，为后续的自动化提供配置信息的支持，如图7所示。

图7  运维对象

CMDB

“模块”是CMDB众多配置项中很重要的一个管理节点。众所周知，不同的角色(开发、测试、运维)对程序的称呼和管理方法都是不一样的。

举个例子。一个程序tnginx部署了100个IP。在开发人员的视角中，这100个IP是一个整体，但是运维对这100个IP还会跟进设备的分布或者支撑不同地域的用户，划分为25个IP支持华北，35个IP支持华东，40个IP支持华南。于是，这100个IP被划分成3个不同的整体，它们的业务量、容量、变更频繁度、机房内网带宽等均有差异。在生产环境管理中，这些都是很重要的考虑要素。我们就以“模块”这个管理节点提升为所有角色都要统一的管理节点，开发、运维、测试、工具系统，都是以节点为操作单位的。

这么做既减少了运维对象(100个IP->3个模块)，也能满足对生产环境的运维要求。并且所有的运维标准化都会被收拢到这个管理节点，如图8所示。

图8  模块管理

以模块为统一的管理节点，开发、运维、测试共同维护模块对应的业务资源配置，开发和运维在织云中管理模块依赖的包、配置文件、权限等资源配置，开发和测试可维护模块对应的测试用例、测试工具等。这样的分工都是为了更好的把三种角色间关注的不同维度通过织云平台承载起来，并记录、落地到cmdb中，为后续的流程和工具提供数据支持，为自动化铺垫。

有了CMDB的配置管理数据库，同时还有一份生产环境的真实存在，如何保证配置管理数据库记录的内容能够准确无误的push到生产环境，如何管控生产环境的真实存在与数据库中的记录完全一致，这就是织云平台通过技术化的手段达到的管理目标，如图9所示。

图9  CMDB配置管理数据库

流程系统

流程系统(流程引擎)是所有自动化的驱动器，负责传递自动化操作中依赖的相关参数，负责关联调用自动化操作中相关的工具系统。流程系统的工作原理将工具通过一定的逻辑组装成一个标准化的流程，同样标准化的操作，只需要通过输入不同的执行参数，流程即可交付相同的操作结果，如图10所示。

图10  流程系统

流程配置的步骤：定义数据类型，用于数据在整个流程中的传递。如IP是一种数据类型、返回码、二维表等又都属于不同的数据类型，具体按流程的场景和工具系统的要求而定。

定义工具配置，通俗讲就是配置工具的内容和用途。如重启进程的工具，工具作者就会开发相应的工具逻辑，如进程名、目录、IP、端口号等参数，工具执行完成，输出结果的执行状态码等其他信息。

流程定义，配置一个流程的开始、过程、结束，依赖的初始化参数、过程中调用工具等信息。

流程系统的架构通过消息队列+worker的模型提升吞吐并发能力，每个worker都会去消息队列中取到单个流程执行，利用monitor对全局的任务进行监控，对每个工具的状态码进行识别，写日志到mysql来将串行的流程变成并行，这样就可以更高效，并发量更大。

图11为一键扩容的实例。用户只需要在织云前台对标准化的模块点击扩容，标准化的扩容流程就会一步步的执行、传递参数，直到流程完成。

图11  自动一键扩容

生产环境

实现流程系统后，就离自动化不远了，整个自动化运维平台只差几个功能模块，便可以实现无人值守智能化，如图12所示。

图12  实现无人值守智能化

决策系统便是这样关键的一个环节，它的作用是识别出标准化的模块需要上线或下线设备，及如何设置最优的判断策略。

我们采用了白名单的形式管理着无人值守的标准化模块，如图13所示，打开织云中的开关控制，容量系统会对白名单的设备进行监控，当识别到一些指标异常时(如CPU、流程等)，容量系统就会调用决策系统的接口，触发决策分析。

图13  决策系统

决策分析其实就是一个决策树(checklist)。为了防止一些错误决策，或者一些波动、锯齿影响决策的准确性，我们事先定义好了一棵决策树，检查完对应场景决策树上的检查点，我们便可以相信这个容量异常点是需要触发自动流程来解决的。继而决策系统便会调用对应的流程来完成一系列自动化的运维操作。

有了无人守值的决策系统和自动流程系统后，我们距离设备的自动上线只差一个灰度测试的环节，如图14所示，这个环节我们提供了ATT和QIA两种方式。这两种方法都是腾讯质量部(测试团队)维护的测试系统。

图14  灰度测试

总结

以上是生活随笔为你收集整理的mysql系统云结构图_腾讯梁定安解密织云系统！（附架构图）的全部内容，希望文章能够帮你解决所遇到的问题。

如果觉得生活随笔网站内容还不错，欢迎将生活随笔推荐给好友。