ducter运维平台_专访运维管理开源平台负责人刁文波：Ducter能帮你！

专访运维管理开源平台负责人刁文波：Ducter能帮你！

发表于2015-02-11 14:11| | 来源CSDN

【编者按】广大的运维朋友肯定常常会在工作中遇到各种和产品发布与管理有关的问题，对于解决办法，我想经验会比较重要。那要是经验不够可怎么办？如何实时的登记各个服务分布在哪些服务器？如何快速在几十、几百甚至几千台服务器上发布产品？如何快速的完成已发布产品的退回？如何不让开发人员登录线上服务器又能收集服务信息等等问题，一定会让你头大。

作为国内已在多个公司投入使用的一款开源产品运维管理系统，刁文波想对你说：Ducter 能帮你！

请您为广大的读者作个自我介绍吧！

有17年的 IT 从业经验，其中互联网从业经验有十年，先后在华为、网易、爱帮、新浪、万达工作，经历了后台系统开发、系统架构师、系统运维的职业演进。作为爱帮的后台负责人，从零开始构建了包括搜索、贴吧、防抓取、监控、cache 等后台服务系统。

在新浪系统架构部，是I4系统架构师，先后设计并领导开发了新浪的新闻池平台、新浪微博开放平台的发布系统。2012年加入万达，是万达电商的云平台副总，负责万达电商基础业务平台的设计与开发，构建了万达电商的整套运维平台，完成了万达广场上百个 WIFI 系统的统一后台的架构设计及实时数据收集、分析平台的建设。

现在负责包括万达院线在内的万达集团的所有信息系统的系统运维。从2009年开始，一直在利用业余时间从事开源软件开发，开源了应用与通信框架：Cwinux(Ducter就是基于 Cwinux 开发的)；消息系统：cwx-mq 及产品发布系统：Ducter。

Ducter 服务器从创建到开源经历了哪些过程？这其中有没有什么故事可以分享一下？

Ducter 的前身起源于新浪。2011年微博经历了爆发式的发展，随着访问量的暴增及新产品的不断推出，微博后台系统的规模也飞速扩张。此时以 JAVA 开发的后台系统的发布与回退遇到了问题。

当时的 JAVA 系统的发布与回退是依赖以 gearman 为平台开发的一套发布系统。随着服务器与业务规模的扩大，此套发布系统在性能、稳定性及交互性上出现了问题，在200台左右的服务器集群上发布或回退产品，需要2~3小时才能完成，而且发布过程不可控。对于发布，2~3小时还可以勉强接受，对于回退来说那简直是灾难，当时微博高层针对此问题，提出了5分钟必须完成回退的要求。

2011年10月份，我一个人接手这个任务。11月份一人2011年10月份，我接手了这个任务，同时于11月份基于 Cwinux 的通信框架开发了微博平台服务发布与回退系统：dispatch。。经过多轮反复测试验证后，3分钟可以实现微博产品的可靠发布与回退，满足了微博产品发布与回退的需求。2012年3月，dispatch 逐步完成了微博平台服务产品发布系统替换。现在，dispatch 已管理着微博平台2000多台服务器、100多个产品产品发布与回退工作，而且还担负着微博产品的服务降级任务。

dispatch 本质是一个分布式命令交互平台，而产品发布只是其一个具体的应用。其在已有的类似开源产品方面是独树一帜的，因此在完成 dispatch 时，就产生了将其开源的想法。

2013年中，开始了 dispatch 开源版本的 dcmd(Distributed Command的缩写)开发，此版本采用全新的控制逻辑及通信协议(Protobuf)，并于2013年底完成了开发，但由于缺少 Web 端的合作伙伴，因此一直没有开源，产品处于暂停状态。2014年中，由于 Web 新团队成员邓磊的加入，项目又重新启动。同时，由于 CMDB 的名字太绕口，而且对 CMDB 定位的改变，项目更名为 Ducter。

Ducter 的未来将以产品管理与发布为中心，通过与其他开源产品的集成，实现 CMDB、服务器配置管理、产品发布、产品监控的一体化。

Ducter 高可用的分布式架构具体指的是什么？有什么特别之处？

Ducter 的高可用的分布式架构是指整个系统没有单点。此没有什么特别之处，都是常用的技术。

如何快速在几十、几百甚至几千台服务器上发布产品？

Ducter 管理的产品的服务，可以配置任意数量的服务池，而服务的服务池子就是产品服务的服务器集合，每个服务池子可以有任意数量的服务器。

产品的上线发布是通过 Ducter 的任务完成的。在创建上线任务的时候，通过 Web 界面选择要上线的服务池(还可以选择某个服务池中的某些服务器)，同时指定每个服务池产品同时发布的最大服务器比率。任务启动后，Ducter 的后台根据用户设置的并发上线比率，自动调度产品服务的上线过程，实现产品的发布。无论是几十、几百还是几千台服务器，对于 Ducter 来说都是一样的过程。

如何解决产品在不同服务器上配置不同的问题？

Ducter 通过【服务池】来组织产品安装的服务器。对于服务器的服务池划分，Ducter 要求产品在同一个服务池中的代码、配置是完全一样的，而不同的服务池代码与配置可以不一样。对于配置的信息，Ducter 是通过服务池的【环境版本】的属性来标记的。

【环境版本】的属性会传递给上线脚本，由上线脚本根据此属性值来决定采用的具体配置信息。此属性值可以指向一个具体的配置文件，也可以指向一个具体的配置目录。Ducter 提供了标准的产品上线脚本就利用了此属性值获取产品的配置信息。

如何解决产品的测试、预发布、线上环境的平滑发布问题？

对于一个标准的产品发布流程，产品发布前需要打包代码，首先提交测试组测试、测试通过后可能会进入预发布环境再测试验证，没有问题后再发布上线。

在上面的这个流程中，各个阶段的代码是一样的，但在各个环境中的配置文件往往是不同的。由于Ducter 支持基于服务池的配置文件配置，因此，可以在 Ducter 中为产品建立【测试服务池】、【预发布服务池】、【生产服务池】，通过服务池的【环境版本】指定各自的配置文件，实现同一份软件包的多环境自动安装，平滑的实现测试、预发布、上线的过程。

如何实现产品发布的过程中不影响线上业务的可用性？

产品发布的过程由 Ducter 控制，而产品在一台服务上的发布过程，则是有上线任务脚本完成的。对于上线过程，Ducter 保证同一时刻只有不超过指定比率的服务器同时执行产品发布操作，确保其他服务器上的服务可以正常提供服务。而产品的上线脚本，则用户可以基于自己的产品特点及生产环境，自己开发。

在保证业务可用性方面，上线脚本典型的处理过程如下：

下载软件包并解压。

下载配置文件

标记当前服务器的服务不可用，并确保当前服务器上的服务已经没有访问流量。

停止服务

更新服务软件包及配置。

启动服务

检查服务状态正常

标记服务可用

检查服务流量是否正常

当前服务器上线成功

在以上10步过程中，若任何一步出现问题，任务脚本都返回失败，Ducter 会获取脚本返回的信息，并纳入到产品上线的任务调度控制中。

当前服务器市场种类杂多，那么 Ducter 服务器有哪些可以战胜众多对手的优势呢？

Ducter 是一个全新的思路，是以产品为中心实现各种类型服务的上线、运维与管理。像 puppet 这类系统也可以实现产品的发布管理，但这些系统的核心思想是配置保持，而 Ducter 是面向交互的，二者面对的问题域不一样。Ducter 日后准备集成像 puppet 这样的产品，实现服务器的配置管理。

如果受到外部攻击，Ducter能做哪些有效的防护措施呢？

Ducter 采用【控制中心/Agent】的架构，而且是 Agent 主动连接控制中心的。

当 Agent 连接到控制中心后，会报告自己的身份信息，此时，控制控制会验证 Agent 的合法性，只有在控制中心注册的服务器才允许连接。

对于未注册的 Agent，控制中心会 block 其再一次连接，直到超过控制中心配置文件中指定的时间，此时控制中心会再一次发起 Agent 的认证过程。

Ducter 今后的用户群体是哪些？

所有产品的管理与发布，都可使用 Ducter(Ducter 当前只支持 Linux 平台)，因此所有互联网公司都是其目标用户群。

Ducter 是面向所有的用户群体，那么在他们的使用过程中有没有向您反馈过什么问题？是怎样解决的？

当前刚开源不久，用户遇到的问题基本都是安装上的问题，当前是通过微博私信或QQ 沟通解决的。随着用户的增多，会建立常见问题的 know-how，放到www.ducter.net上，供用户故障排除使用。下载Ducter介绍PPT。