共计 7275 个字符，预计需要花费 19 分钟才能阅读完成。
前 言
明天的中国互联网，正减速从生产互联网向产业互联网转型，数字化改革逐步渗透到每一个具体产业，弹性算力已变成各行各业的水电煤，从底层驱动产业改革。以区块链、IoT、人工智能、大数据等先进技术为代表，新的云原生基础设施曾经就绪并将持续演进，同时也会随同着与之配套的技术和治理范式的演进。DevOps 作为数字化时代 IT 研发和治理范式，是企业数字化转型重要的组成部分。
以后互联网组件生态中，DevOps 工具和零碎林林总总，令人目迷五色。选用与以后企业倒退阶段不适配的 DevOps 组件会导致：
工具能力溢出，大量性能闲置，同时减少应用人员的上手老本；
工具能力有余或性能过于泛化，无奈满足企业研发体量需要或无奈灵便定制细节；
工具自身品质欠佳，后续相应的社区反对或服务保障缺失，导致稳定性危险。
基于以上问题，本文致力于为企业提供 DevOps 工程效率和运维环节（后续简称效维）工具阐明及全景图，并联合典型中国互联网研发场景，提出适配不同体量和阶段的企业的效维工具链选型，心愿能帮忙企业疾速满足数字化改革的要求，减速业务倒退，引领业务翻新。
DevOps 及工具链概述
DevOps 是 Development 和 Operations 的组合词。它是一组过程、办法与零碎的统称，用于促成开发（应用程序 / 软件工程）、技术经营和品质保障（QA）部门之间的沟通、合作与整合。
图 1 DevOps 领域
它是一种器重“软件开发人员（Dev）”和“IT 运维技术人员（Ops）”之间沟通单干的文化、静止或常规。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、公布软件可能更加地快捷、频繁和牢靠，把麻利开发部门和运维部门之间的围墙买通，造成闭环。
在 DevOps 流程下，运维人员会在我的项目开发期间就染指到开发过程中，理解开发人员应用的零碎架构和技术路线，从而制订适当的运维计划。而开发人员也会在运维的初期参加到零碎部署中，并提供零碎部署的优化倡议。
残缺的 DevOps 生命周期个别包含以下六个阶段。
图 2 DevOps 生命周期
其中集成、部署、监控三个环节属于 DevOps 生命周期中外围环节，是本文次要关注点。贯通云原生 DevOps 整个生命周期的工具链全景图如下：
图 3 云原生 DevOps 工具全景图
继续集成 & 继续部署
继续集成能够帮忙开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或“骨干 ” 中。一旦开发人员对利用所做的更改被合并，零碎就会通过主动构建利用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对利用造成毁坏。继续集成的输出是代码，所以一个好的代码托管工具是必不可少的。
继续部署指的的是主动将开发人员的更改从存储库公布到生产环境，以供客户应用。它次要为了解决因手动流程升高利用交付速度，从而使运维团队超负荷的问题。部署过程中可能还会波及到平滑迁徙新老版本流量的过程，所以对服务发现工具也有肯定的依赖。
要实现继续集成和继续部署，自动化的流水线是根底。本节将从 代码托管工具、集成流水线工具、服务发现工具三个方面进行工具比照介绍。
代码托管工具
在抉择代码托管工具的时候，次要关注以下三点：
可协同：在性能层面要蕴含仓库治理、分支治理、权限治理、提交治理、代码评审等代码存储和版本治理等性能，让开发者更好的协同工作；
可集成：好的代码托管服务应该具备灵便和繁难的三方工具集成能力，升高 DevOps 的施行落地老本 ;
安全可靠：这是最重要的一点，对于集体开发者可能无感，然而对于企业而言，代码的安全性、服务的稳定性、数据是否存在失落的危险，是会最被优先考量的点。
罕用代码托管工具见下表：
表 1 代码托管工具对照表
集成流水线工具
集成流水线就像传统的工业流水线一样，在经验构建、测试、交付之后，生产出一代一代更新迭代的软件版本。实现了软件产品小步迭代、高频公布、适时集成、稳固的零碎演进线路图。在抉择集成流水线工具的时候，咱们须要关注：
版本控制工具的反对；
每个构建是否能够支 持指定多个代码源 URLS；
是否反对构建产物治理库，如私有云对象存储等；
是否反对部署流水线，相似于一个或多个构建实现后触发另一个构建；
是否反对并行构建；
是否反对构建网格，以及对网格内机器治理的能力。如是否将多个构建同时调配到多个构建机器上执行，以进步执行速度；
是否有良好的凋谢 API，比方触发构建 API、后果查问 API、规范的 Report 接口等；
账户体系，是否反对第三方账户接入，如企业 LDAP 等；
是否有良好的 Dashboard；
多语言反对；
与构建工具（如 Maven，Make，Rake，Nant、Node 等）和测试工具的集成。
罕用集成流水线工具如下表所示：
表 2 继续集成 & 继续部署组件对照表
服务注册发现工具
服务发现为 Deploy 的最初环节，缺一不可。无论是四七层负载平衡，还是微服务、RPC 服务框架，服务发现都是产品投产的临门一脚。服务注册发现工具选型须要从生态倒退、便利性、语言无关性等角度来综合考量。
罕用的组件工具如下表：
表 3 服务注册组件对照表
继续监控
服务的稳定性离不开监控零碎的保驾护航。监控零碎为服务稳固运行提供数据可视化、异样报警、异样定位、故障追踪等能力；同时监控零碎还为服务继续优化降级提供根据和考量规范。
监控零碎有三大基石：指标、日志、分布式追踪。
指标体系：聚焦于故障发现环节，服务以数字模式评估出服务 QPS、成功率、提早、容量等要害指标，搭配报警零碎能够保障当外围指标异样时及时告诉开发 / 运维人员。除了外围指标外，服务还能够将各模块 / 阶段的瓶颈点、内部依赖指标量化，建设更加欠缺服务状态概览，以便服务开发 / 运维人员疾速定位异样，实现根因剖析。指标零碎劣势是聚合能力，用较少的存储资源和计算资源表白零碎外部状态。
常用工具及性能对照如下：
表 4 指标组件对照表格
日志零碎：用于记录服务内产生的各类事件。日志零碎聚焦故障定位环节，与指标零碎相比，日志零碎具备更强的描述性，但也随同着更大的存储空间和计算存储资源要求。日志是罕用的监控办法，比方在具备内部依赖零碎的服务中，个别会将内部零碎产生的谬误和谬误起因以日志模式记录下来，以便在故障定位和复盘时复原异样现场环境。罕用计划为 ELK（Elasticsearch、Logstash 和 Kibana）。
分布式追踪零碎：用于剖析服务调用关系。在微服务流行的明天，服务之间调用关系越来越简单，微服务之间相互影响也更加难以定位和排查。分布式追踪零碎聚焦于故障定位环节，与指标体系和日志体系不同，分布式追踪零碎能够提供服务之间依赖拓扑信息，对于梳理零碎调用拓扑、追踪上游依赖导致的异样意义重大。
常用工具及性能对照如下：
表 5 分布式追踪组件对照表
企业评估模型
DevOps 成熟度
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 进行服务发现，这种形式简略又高效；3. 通过 Nginx 裸露服务，Nginx 挂载 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 开始搭建的过程。
体验有礼
为寻找优良的开发者参加到星汉将来的开源产品当中，特推出产品体验流动，胜利下载安装并运行 SchedulX 的开发者即可分割小助手获取星汉将来定制的礼品，给开源我的项目提 issue 或者 pr，经评估正当的处分 Cherry 键盘一个。GitHub 地址：https://github.com/galaxy-fut…
Cherry 键盘
体验征询请增加小助手
对于星汉将来
星汉将来（Galaxy-Future）是一家云原生根底引擎提供商，提供三大根底引擎：算力调度引擎 BridgX、数据物流引擎 DTExpress 和智能运维引擎 CudgX，基于这三大根底引擎提供了云原生综合运维平台 SchedulX。同时也为企业提供解决方案和咨询服务，心愿能帮忙企业在上云过程中实现老本升高 50%-80%，开发效率晋升 10 倍。官网地址：www.galaxy-future.com
相干产品 Github 地址
BridgX (GitHub) https://github.com/galaxy-fut…
CudgX (GitHub) https://github.com/galaxy-fut…
SchedulX (GitHub) https://github.com/galaxy-fut…
