一篇文章带你了解运维重器 Tencent Hub

5 月 23-24 日，以“焕启”为主题的腾讯“云+未来”峰会在广州召开，广东省各级政府机构领导、海内外业内学术专家、行业大咖及技术大牛等在现场共议云计算与数字化产业创新发展。

腾讯云 PaaS 产品总监邹辉在腾讯“云+未来”峰会的「开发者专场」做了主题为“新时代运维重器 Tencent Hub 最佳实践”的技术内容分享，针对 DevOps 产品的一些设计理念和思考。

以下内容整理自演讲：

邹辉：因为工作关系，我会在日常工作中跟很多企业和运维人员打交道，协作他们做容器化和 DevOps 化的一些工作。在过程中，我们发现大家对于 DevOps 的价值，以及如何实现 DevOps 还有一些疑问。所以今天先简单介绍我们为什么要去做 DevOps，以及怎么样去做 DevOps。

从技术的角度来看，随着业务的发展，业务的场景越来越多，越来越复杂，我们的系统架构也会越来越庞大，开发人员也会越来越多，同时对系统的稳定性要求也会越来越高。所以这些场景催生了我们的技术架构的变革，由此会带来微服务架构设计理念的产生。

微服务架构设计理念的产生能够解决这些问题，但是微服务也带来很多的问题，微服务导致我们的系统模块越来越多，而这些模块运维管理复杂度也会增加，同时微服务会让我们的开发速度得到增加，我们的开发人员对我们发布的效率会有一个明显的诉求。所以在运维人员对系统的质量把控，以及开发人员对系统效率的追求上有矛盾，这就是我们 DevOps 需要解决的一些问题，由此催生了 DevOps。

所以 DevOps 实际上就是我们需要通过 DevOps 来保证质量的同时，平衡开发效率，本质上来说 DevOps 实际上就是一个流程化和工具化的过程，通过工具来固化流程，通过流程来保证运维发布和研发质量，同时降低人工进行操作时候的一些误操作引发的故障，也提高了整个研发效率。所以基于这一点，如何去实现我们的 DevOps，实际上非常清晰，因为 DevOps 就是一个流程规范制定和工具自动化的过程，所以作为 DevOps，我觉得关键在于两步：

1、把我们的流程梳理清楚，把我们的软件开发过程中的一些步骤，我们有有哪些步骤，比如我们有代码提交、发布测试化，静态扫描，把我们研发过程梳理清楚。我们也需要把我们团队的关系梳理清楚，这个软件开发过程中有开发，有测试，有运维，还有一些管理者，需要哪些步骤需要哪些人审核，在哪些步骤需要通知哪些人。接下来我们就需要进步第二步；

2、通过工具化把所梳理的流程实现自动化的过程。如何去选择一个合适的 DevOps 工具体系，把流程规范给自动化起来，接下来就是我今天分享的一个重点，给大家分享一下，我们腾讯云在 DevOps 工具体系这方面的实践。

整个腾讯云在 DevOps 这里实际上推出了一款工具，叫 Tencent Hub。Tencent Hub 是第一款涵盖了 DevOps 整个体系的工具体系，主要分成三部分，从代码的开发阶段到代码的构建阶段，一直到代码的发布阶段。在代码开发阶段，我们可以提供 TAPD 的开发平台，我们也推出了一个 Tgait 的代码仓库，基于这个构建组件，我们很方便的可以把整个 DevOps 流程给串起来，同时也提供了一个全面的仓库，在这个仓库里面，我们可以存储任何的代码，DevOps 任何的一个存储，最终我们也会跟运行环境里面的一些服务打通，来支持各种发布，提供各种各样的查检。这就是整个腾讯云在 tencent hub 整体的一个体系图。

在 CD 环节，我们有一个核心组件，叫 Work Flow，大家可以简单理解为它就是一个工厂的流水线，通过这个流水线，我们可以把 DevOps 环节开发、测试、发布、代码自动测试，这所有的环节很简单的串联起来。因为不同的公司研发流程不一样，并且随着业务的发展，流程可能也会在不断的变更，所以我们再去设计 Work Flow 这款组件的时候，一个核心考量就是能否快速的去适应多样化的流程体系，以及快速的适应流程的变更。

基于这一点，我们在用 Work Flow 的时候，把 Work Flow 分成了三块，一个是 Engine 环境，一个是插件层，还有一个是 Work Flow 插件库，主要是管理调度功能，真正实现任务实行是在下面 Work Flow 的插件去实现这个功能。

在 Work Flow Engine 这一层我们可以看到也是分成多个阶段，我们将一个 DevOps 完整阶段拆分成多个不同的，这些串行执行，也可以并行执行，我们可以定义任何 DevOps 的流程，同时在执行过程中，我们也可以暂停这个 stage，也可以启动这个 stage，在完成以后，我们也可以根据反馈结果来定义这个流程是该继续走下去，还是该终止。当我们把代码构建完成之后发布到自动化测试系统中做测试，发现某个自动化测试用力跑不过，这个时候我们可以设计一个终止的环节，然后把这个系统结果到开发运维人员，或者测试人员。同时 Work Flow Engine，同时也写好亚码文件，把完整的流程导入到 Engine 里面执行。这就是在 Engine 方面我们的一些设计和思考。

在这一层，我们能够做的一个调度方式，大家可以看这张图，第一种调度方式是 Engine 可以通过 AP 调动任务，Engine 层可以执行指定的一个任务，实际上以容器绩效的方式定义和运行这个插件，也是我们在 Work Flow 做的一个比较大的革新。为什么这样说？因为我们发现把容器引入到 DevOps 里面去做会带来很多的好处，首先我的 DevOps 流程里面会有执行各种各样的任务，如果把这个任务通过容器化固化下来，通过容器绩效我们可以很方便的传播，这个时候大家看的可能不是跟 Engine 相关的插件，而就是一个容器绩效。一旦把插件分装到容器里面之后，我们公司里面可以根据大家的喜好和专业程度，根据自己的一个喜好去开发容器。这就是我们在 Work Flow 插件这一块实现的机制。

另外，如果说是用户想要自定义自己的插件，完成一些功能，也只是需要定义好简单的输入和输出即可，输入值可以从前面任何流程获取，制定本质的输出参数，输出参数也可以反馈回来，供后面的流程使用。用户也可以很简单的去遵守这个输入和输出的规范，开发自己的绩效插件。

另外，除了 Work Flow 之外，刚才也提到了 Registry，我们发现在 Work Flow 会产生很多中间产物，比如说我构建一个 Zaar 程序，或者发布一些配置文件，这些配置文件发布在哪些地方，包括发布机制，它这个存在的地方或者最终绩效存在的地方等等，我们发现在 DevOps 环节中会产生各种各样的中间产物，而这些中间产物往往会存储到不同的地方，使用不同的协议去获取。

我们也针对一些常见的语言库和流程提供一些通用的插件库，比如说里面的代码检查、构建，这些绩效可以统统在这一层获取到。这就是我们在 Work Flow 这里面的一些设计理念。

基于这一点，我们开发了一个叫 Registry 的一个通用仓库，可以实现通用存储，使用这个通用存储可以很方便的把 DevOps 里面中间产物，各种中间产物给管理起来。

Registry 也提供了多层管理机制，从组织到用户团队，到个人，这样一个分级管理机制，通过权限的方式去统计，也提供各种各样的日记，静态扫描的功能，让用户能够更方便的使用这些 Registry 功能。这就是 Registry 这边的一些设计。

除此之外，其实我们还把腾讯内部的一些研发实践，通过服务的方式分装起来给开发者，让开发者不光可以使用 Work Flow，使用既定插件，同时还可以使用腾讯内部一些比较好的经验，更好的去支撑他们的 DevOps，比如我们自动化运维、代码托管、自动化测试，以及我们最近推出的一个 OTFA 这样的安卓平台，后面是我们基于 APP 而开发的测试平台。

今天我这边的演讲就到这里结束了谢谢大家。

本文转载自公众号云加社区（ID：QcloudCommunity）。

原文链接：

https://mp.weixin.qq.com/s/k4N-Qt550cSzjt0GEn2EkQ