vlambda博客
学习文章列表

今天的中国互联网，正加速从消费互联网向产业互联网转型，数字化变革逐渐渗透到每一个具体产业，弹性算力已变成各行各业的水电煤，从底层驱动产业变革。以区块链、IoT、人工智能、大数据等先进技术为代表，新的云原生基础设施已经就绪并将继续演进，同时也会伴随着与之配套的技术和管理范式的演进。DevOps 作为数字化时代 IT 研发和管理范式，是企业数字化转型重要的组成部分。

当前互联网组件生态中，DevOps 工具和系统林林总总，令人眼花缭乱。选用与当前企业发展阶段不适配的 DevOps 组件会导致：

• 工具能力溢出，大量功能闲置，同时增加使用人员的上手成本；

• 工具能力不足或功能过于泛化，无法满足企业研发体量需求或无法灵活定制细节；

• 工具本身质量欠佳，后续相应的社区支持或服务保障缺失，导致稳定性风险。

基于以上问题，本文致力于为企业提供 DevOps 工程效率和运维环节（后续简称效维）工具说明及全景图，并结合典型中国互联网研发场景，提出适配不同体量和阶段的企业的效维工具链选型，希望能帮助企业快速满足数字化变革的要求，加速业务发展，引领业务创新。

DevOps 是 Development 和 Operations 的组合词。它是一组过程、方法与系统的统称，用于促进开发（应用程序 / 软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。

图 1 DevOps 范畴

它是一种重视“软件开发人员（Dev）”和“IT 运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠，把敏捷开发部门和运维部门之间的围墙打通，形成闭环。

在 DevOps 流程下，运维人员会在项目开发期间就介入到开发过程中，了解开发人员使用的系统架构和技术路线，从而制定适当的运维方案。而开发人员也会在运维的初期参与到系统部署中，并提供系统部署的优化建议。

完整的 DevOps 生命周期一般包括以下六个阶段。

图 2 DevOps 生命周期

其中集成、部署、监控三个环节属于 DevOps 生命周期中核心环节，是本文主要关注点。贯穿云原生 DevOps 整个生命周期的工具链全景图如下：

图 3 云原生 DevOps 工具全景图

持续集成可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或“主干"中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。持续集成的输入是代码，所以一个好的代码托管工具是必不可少的。

持续部署指的的是自动将开发人员的更改从存储库发布到生产环境，以供客户使用。它主要为了解决因手动流程降低应用交付速度，从而使运维团队超负荷的问题。部署过程中可能还会涉及到平滑迁移新老版本流量的过程，所以对服务发现工具也有一定的依赖。

要实现持续集成和持续部署，自动化的流水线是基础。本节将从代码托管工具、集成流水线工具、服务发现工具三个方面进行工具对比介绍。

在选择代码托管工具的时候，主要关注以下三点：

1. 可协同：在功能层面要包含仓库管理、分支管理、权限管理、提交管理、代码评审等代码存储和版本管理等功能，让开发者更好的协同工作；

2. 可集成：好的代码托管服务应该具备灵活和简易的三方工具集成能力，降低 DevOps 的实施落地成本 ;

3. 安全可靠：这是最重要的一点，对于个人开发者可能无感，但是对于企业而言，代码的安全性、服务的稳定性、数据是否存在丢失的风险，是会最被优先考量的点。

常用代码托管工具见下表：

表 1 代码托管工具对照表

集成流水线就像传统的工业流水线一样，在经历构建、测试、交付之后，生产出一代一代更新迭代的软件版本。实现了软件产品小步迭代、高频发布、适时集成、稳定的系统演进线路图。在选择集成流水线工具的时候，我们需要关注：

1. 版本控制工具的支持；

2. 每个构建是否可以支持指定多个代码源 URLS；

3. 是否支持构建产物管理库，如公有云对象存储等；

4. 是否支持部署流水线，类似于一个或多个构建完成后触发另一个构建；

5. 是否支持并行构建；

6. 是否支持构建网格，以及对网格内机器管理的能力。如能否将多个构建同时分配到多个构建机器上执行，以提高执行速度；

7. 是否有良好的开放 API，比如触发构建 API、结果查询 API、标准的 Report 接口等；

8. 账户体系，是否支持第三方账户接入，如企业 LDAP 等；

9. 是否有良好的 Dashboard；

10. 多语言支持；

11. 与构建工具（如 Maven，Make，Rake，Nant、Node 等）和测试工具的集成。

常用集成流水线工具如下表所示：

表 2 持续集成&持续部署组件对照表

服务发现为 Deploy 的最后环节，缺一不可。无论是四七层负载均衡，还是微服务、RPC 服务框架，服务发现都是产品投产的临门一脚。服务注册发现工具选型需要从生态发展、便利性、语言无关性等角度来综合考量。

常用的组件工具如下表：

表 3 服务注册组件对照表

服务的稳定性离不开监控系统的保驾护航。监控系统为服务稳定运行提供数据可视化、异常报警、异常定位、故障追踪等能力；同时监控系统还为服务持续优化升级提供依据和考量标准。

指标体系：聚焦于故障发现环节，服务以数字形式评估出服务 QPS、成功率、延迟、容量等关键指标，搭配报警系统可以保证当核心指标异常时及时通知开发 / 运维人员。除了核心指标外，服务还可以将各模块 / 阶段的瓶颈点、外部依赖指标量化，建立更加完善服务状态概览，以便服务开发 / 运维人员快速定位异常，完成根因分析。指标系统优势是聚合能力，用较少的存储资源和计算资源表达系统内部状态。

常用工具及功能对照如下：

表 4 指标组件对照表格

日志系统：用于记录服务内发生的各类事件。日志系统聚焦故障定位环节，与指标系统相比，日志系统具有更强的描述性，但也伴随着更大的存储空间和计算存储资源要求。日志是常用的监控方法，比如在具有外部依赖系统的服务中，一般会将外部系统发生的错误和错误原因以日志形式记录下来，以便在故障定位和复盘时恢复异常现场环境。常用方案为 ELK（Elasticsearch、Logstash 和 Kibana ）。

分布式追踪系统：用于分析服务调用关系。在微服务盛行的今天，服务之间调用关系越来越复杂，微服务之间相互影响也更加难以定位和排查。分布式追踪系统聚焦于故障定位环节，与指标体系和日志体系不同，分布式追踪系统可以提供服务之间依赖拓扑信息，对于梳理系统调用拓扑、追踪下游依赖导致的异常意义重大。

常用工具及功能对照如下：

表 5 分布式追踪组件对照表

DevOps 成熟度是评估效维工具选择的首要参考维度。不同企业 DevOps 发展阶段不一，为了更好地选择适配企业实际情况的效维工具，我们需要从多维度进行评估：

• 组织与文化：DevOps 需要文化与组织的变革，包括研发与运维、IT 与业务之间的隔阂及部门墙的打破。组织支持 DevOps 的力度，以及现阶段文化与 DevOps 的匹配程度是这个维度的关键。

• 敏捷开发：DevOps 是敏捷开发理念的更科学的实践体系，因此前期敏捷做得好不好直接影响到 DevOps 的效果，两者是相辅相成的。

• CI/CD：CI/CD 不仅仅是工具或流程，更是一种方法论，“持续"是其核心。CI/CD 管控从代码提交那一刻到代码运行在生产环境的整个过程。

• 可视化与自动化：可视化是让 DevOps 人性化的重要一环，通过良好的可视化看板，可以快速发现 DevOps 流程中的阻塞点和风险点。自动化一方面是为了更快推动价值流从左向右流动，另一方面也为了将人为失误的风险降到最低。

• 运维监控与预警：开发与运维紧密合作，甚至是一个团队，对于运维的监控和预警对所有相关方可见。

• 持续度量与改进：DevOps 的效果也是需要度量的，“如果你无法度量它，你就无法改进它”。DevOps 提倡更频繁的直面问题，度量则是一种很好的方式帮助我们发现问题，并持续改进。

几乎没有尝试任何 DevOps 实践，或只做了一些基础的 DevOps 工作的企业，适合选取更低门槛甚至是一站式的工具，功能可以比较单一，但主要注重价值流的流转效率。而对于能成熟运用各种 DevOps 实践的企业，适合根据自己的实际需求选取特定环节的组件，并根据团队和组织情况进行修改或定制。

效维团队的人员规模，也会影响 CI/CD 及监控工具链的选择。我们把 20 人以下的效维团队定义为中小团队，20 至百人以上定义为大型团队。正常来说，效维团队的规模也同比研发团队的规模。对于中小团队来说，选择学习曲线低、能快速搭建且有较完备社区或官方服务提供后续支持的工具为主，容忍功能相对单一。大型团队因为有较充足的人力及技术实力，有条件选用有一定上手成本，但功能全面且支持深度定制甚至重构的工具。

业务对运维服务质量的要求，也深度影响效维工具链的选择和搭建。比如金融业务，对稳定性和精确性有极高的要求，并且面临外部强合规性的监管，效维质量要求较高。而其它类似推荐的业务，即使出现问题也只是降低客户体验，比如展现相关度不高的商品或新闻，整体并不造成灾难性的后果，效维质量就相对要求不高。

针对于效维质量要求较高的项目，工具链的选择倾向于功能覆盖率较全，有大厂背书或业界口碑，历史 bug 率不高的工具，整个的效维流程的时延以及效率相对较重。针对要求较低的项目，工具链的选择倾向于能快速搭建，能覆盖基本功能的工具链条。

企业的服务治理标准化程度也会影响效维工具链的选择。服务治理标准化包括硬件的标准化、OS 的标准化、语言栈的标准化、通信协议的标准化、框架的标准化等。标准化程度较高的企业，效维工具功能可以相对比较聚焦，不需要覆盖各层级多种标准导致的技术复杂度。标准化程度较低的企业，效维工具的体系和结构会比较庞杂，甚至在有些链路环节无法做到完全统一和自动化，需要效维人员深度参与修改与定制。

结合以上的评估维度，我们认为典型的公司型态包括以下三种：

创业型企业一般选择此种模型，此时公司以快速迭代服务、提升开发效率为第一个原则，运维能力有限。

这种模型推荐使用如下方式搭建 DevOps 工具链：

图 4 建议工具链

如上图所示：

• 推荐使用 GitLab 代码管理，GitLab 是企业级的开源代码托管软件、生态成熟、稳定、社区庞大、使用简单。DevOps 代码托管流程描述如下：

  1.Zadig 完成 CI/CD 流程，提供开发 / 运维友好的 Web UI；

  2.构建服务镜像，将镜像推送到 Harbor，完成镜像和服务版本管理；

  3.将服务部署于 Kubernetes，完成服务升级。

• 推荐使用 Kubernetes 服务部署，Kubernetes 是 Google 开源的服务部署平台，它具有开源、高效、稳定、社区庞大的优点。目前 Kubernetes 已经成为了云原生的标准服务部署平台，它大大减少了运维人员工作负担。在团队人数较少时采用 Kubernetes，不仅节省人力、服务部署升级效率高，还具有强大的系统可扩展性。采用 Kubernetes 部署服务流程描述如下：

  1.使用 Kubernetes Deployment，YAML/Helm chart 部署服务；

  2.使用 Kubernetes NodePort Service 进行服务发现，这种方式简单又高效；

  4.Kubernetes 可以使用 BridgX 搭建，BridgX 支持管理公有云和私有云计算资源，基于 BridgX 搭建的运维系统可扩展性更高；

  5.使用公有云计算资源底座，成本低，运维难度低。

• 推荐使用 CudgX + Grafana 搭建监控系统

  1.使用 CudgX 建立指标体系，CudgX 是源代码开放的智能诊断平台，具有高可用、高性能、服务负载评估、服务冗余度保持等功能特点，采用 CudgX 存储核心指标为服务自动扩缩容提供更高的可扩展性，同时 CudgX 兼容 Prometheus 生态，已有基于 Prometheus 的监控系统可以平滑迁移到 CudgX 系统。

  2.Grafana 是目前最为流行的监控视图软件，并提供了简单易用的报警功能，团队规模较小时采用，既不会浪费太多运维时间，又能保证服务质量，还可以保证系统的可扩展性。

采用此种监控方案总结如下：

• 使用 CudgX 业务打点，同时也能使用 Prometheus + CudgX 的组合；

• 基于 Grafana 搭建视图和报警功能。

此模型适合于业务稳定性要求较高的企业，此时企业一般有稳定的服务和客户群体，服务质量至关重要，需要完善的 DevOps 流程保障服务更新 / 发布过程中稳定性要求，并满足提高开发效率的诉求。

此时推荐使用如下所示的方式搭建 DevOps 工具链：

图 5 建议工具链

如上图所示：

• CI/CD 推荐使用 GitLab ，同时搭配 Zadig 提供易于用户操作的 UI。采用此种代码管理方式流程描述如下：

  1.使用 Zadig 持续集成，Zadig 提供了用户友好的 WebUI，使用 Sonar 完成代码检查，完成单元 /C2C 测试流程，当所有验证通过后触发部署；

  2.构建服务镜像，将镜像推送到 Harbor，完成镜像和服务版本管理；

  3.自动灰度流量到 SchedulX 。

• 推荐使用 SchedulX 服务部署，原因为 SchedulX 具有完善的金丝雀发布功能，同时支持物理机和容器化部署。对于服务质量要求较高，代码发布、服务更新应该有完善的灰度到全量更新流程，并且当核心指标异常时，应该阻断变更，SchedulX 配合 CudgX 可以实现金丝雀发布、变更阻断、动态扩缩容等功能，最大程度上保证服务质量。在服务质量要求较高的场景下，部分服务可能由于网络或者资源隔离的原因，希望将服务部署在独立的物理机中，SchedulX 既支持 Kubernetes 又支持物理机部署。采用 SchedulX 服务部署流程描述如下：

  1.服务更新请求提交至 SchedulX；SchedulX 根据服务部署类型，将服务灰度部署于物理机或者 Kubernetes；

  2.SchedulX 监控核心指标，滚动发布，金丝雀发布，当指标异常时回滚更新操作；

  3.按照服务规模和复杂程度不同，用户可能使用微服务架构，此时服务发现可以基于 Consul ；

  4.向外暴露服务可以通过 Nginx，向内暴露服务可以通过 LVS；

• 推荐使用 CudgX + Nightingale + ELK + Jaeger + Grafana 搭建监控系统。基于 CudgX 建立业务指标体系，具有高可用、高性能、高扩展性的特点，同时搭配 SchedulX 可以完成变更阻断和服务自动扩缩容，大大提供服务稳定性。基于 Nightingale 完成基础指标监控，可以尽早预测 / 捕获宿主机异常，避免或降低异常影响。基于 ELK 完成日志收集，服务异常时快速定位故障环节，降低故障影响。基于 Jaeger 搭建分部署追踪系统，快速定位系统瓶颈点，定位故障服务。基于 Grafana 搭建监控视图和报警，为服务稳定性保驾护航。

基于此方案搭建监控系统总结如下：

• 使用 CudgX 完成业务指标打点与指标收集，完成业务指标监控；

• 使用 Nightingale 完成基础指标打点与收集，完成物理机基础指标（如 CPU/Memory/ 网卡等）监控；

• 使用 ELK 搭建日志系统；

• 使用 Jaeger 搭建分布式追踪系统；

• 使用 Grafana 搭建视图和报警系统。

此模型企业内各服务和组件都趋于成熟，企业有高稳定性要求的核心服务，有专业的运维团队，需要完善的 DevOps 平台来保障复杂的微服务体系下的服务质量。企业更关注于系统平台化，将各类组件分门别类组合成为系统平台，并搭建 CMDB 管理服务元数据，按组织架构管理服务。

此模型下平台化成为主题，各组件有独立部门负责平台支持和运维，从微服务、监控平台、服务部署平台三个平台角度看，推荐系统架构如下所示:

图 6 建议工具链

本文针对不同 DevOps 成熟度的企业，量身推荐了持续集成、持续部署以及持续监控的工具集合，希望能帮助广大互联网企业，尤其是中小企业，快速搭建起自己的效能及运维的平台，助力企业快速交付，在日益激烈的行业竞争中收获技术红利。

本文大部分内容来自《星汉未来综合运维解决方案》白皮书，适合各公司收藏以备技术选型时参考，感兴趣的可以点击【阅读原文】链接下载。

作者介绍

田良智，星汉未来资深技术专家，曾就职于新浪等公司，拥有十多年运维经验，参与过多个运维系统从 0 开始搭建的过程。

点个在看少个 bug 👇