云原生业务全流程DevOps配置预研与实践

背景

我在一个二线城市（山东济南），相对与北上广深杭这些IT业发达的城市来说，济南IT业对于业内新技术的接受度是有点慢的，国内很多一线大厂早先几年前就开始实践使用的技术，我们这边也是近两年才开始慢慢兴起。
我本人是在21年开始正式接触云原生。我们当时的CTO是一个比较有超前意识（相对而言），且是一个敢于尝试的领导。当时公司的平台系统，平时虽然运行的挺好，但每年的那几个关键集中业务期，因并发量大，总会崩溃几十分钟。客户对此非常不瞒，公司上下从业务部门到研发部门都面临着巨大的压力。
解决问题的方法无非就那么几种：

• 优化服务性能，提升业务并发，治标治本。但是要能做，也不至于拖了这么长时间了
• 扩容集群，用预算换并发，治标不治本。超额预算对高层无法交代
• 引入新技术，多方位对问题进行缓解或解决

然后经过种种决策，我们决定上马K8S+Istio，来解决我们所面临的“难题”。
过程中我们肯定会遇到很多新的难题，比如：

• 新知识的学习与应用，每个团队成员都需要更新自己的知识体系
• 新框架的使用与老框架之间转换的时间成本把控
• 团队成员对新体系的接纳
• 新体系的初体验是否会给团队带来效率问题等等。

为了使团队能够更快的接受，并且不给团队带来因为新体系而造成的额外问题。我们的CTO提出了一系列要求：

• 提升产品交付质量！但是，需要整体组织协作起来，并且有技术指导及平台支撑
• 提高产研效率和价值产出！但是，希望避免无效的加班加点和无效的工作产出
• 尽量不要增加个体的工作复杂和繁重度，如果能简化、便利化就更好
• …

基于以上要求，作为先头部队，我开始了一系列的预研工作。本篇我将讲一讲基于DevOps的自动化流水线的实践工作

预研

如何减轻团队负担、提升效率？

自动化！让重复性的工作全部自动化，让流程性的东西自动化，让不需要主观判断的东西自动化！

如何全流程自动化？

流水线！从开发到上线，中间需要经历检测、构建、测试、部署等等多个步骤，使用流水按将这些步骤串联起来，通过各种条件判断，完全可以解放出更多的人力。

整个自动化流水线需要哪些工具？下面我们来聊一聊。

配置

CI/CD平台

要跑流水线，我们首先得有一个CI/CD平台，那我们平时会用到哪些CI/CD工具呢？

• Jenkins

老牌流水线平台，做软件的大部分人应该都知道

部署方式：宿主机直接部署、容器化部署、K8S部署都可以

优点很多，社区强大、插件丰富等等。但是缺点页比较明显，只能单master部署，虽然可以通过slave扩展，但是一旦master挂掉，队列就失败了。

参考地址：https://www.jenkins.io/zh/

• Jenkins X

Jenkins X是基于Kubernetes的持续集成、持续部署平台。也是Jenkins的子项目。Jenkins X旨在使程序员在研发过程中能够轻松遵循DevOps原理和最佳实践。

Jenkins X 基于松耦合架构的 DevOps 模型，被设计用来支持在多个团队间，部署大量可重复、可管理的分布式微服务。在Jenkins X的设计中，整合了Tekton，Helm，Draft，GitOps，以及Nexus，Chartmuseum，Monocular，Skaffold等诸多系统和工具，从而实现自动构建编译环境，生成容器镜像，流水线，自动化部署，并通过简单的Review实现不同环境间的自动发布

参考地址：https://www.jenkins.io/zh/projects/jenkins-x/

• Tekton

Tekton 是一个基于 Kubernetes 的云原生 CI/CD 开源框架，属于 CD 基金会的项目之一。Tekton 通过定义 CRD 的方式，让用户以灵活的自定义流水线以满足自身 CI/CD 需求。

Tekton 引入了几个新的 CRD，包括 Task、Pipeline、TaskRun 和 PipelineRun

参考地址：https://tekton.dev/

• ArgoCD

ArgoCD从名字就能看出它是一个CD工具，不具备CI能力。Argo CD 是一个为 Kubernetes 而生的，遵循声明式 GitOps 理念的持续部署（CD）工具。Argo CD 可在 Git 存储库更改时自动同步和部署应用程序。

Argo CD 是通过一个 Kubernetes 控制器来实现的，它持续 watch 正在运行的应用程序并将当前的实时状态与所需的目标状态（ Git 存储库中指定的）进行比较。已经部署的应用程序的实际状态与目标状态有差异，则被认为是异常状态，Argo CD 会报告显示这些差异，同时提供工具来自动或手动将状态同步到期望的目标状态。在 Git 仓库中对期望目标状态所做的任何修改都可以自动应用反馈到指定的目标环境中去。

参考地址：https://argo-cd.readthedocs.io/en/stable/

关于他们的详细对比，知乎上有一篇文章：https://zhuanlan.zhihu.com/p/613527858 供大家参考，此处就不再赘述了。

代码检测

代码检测可以初步判断研发人员提交的代码是否符合相关规范，比如bug数、单元测试覆盖率等等，满足编码规范才能进入下一流程，如果连团队制定的编码规范都无法满足，则直接终止流水线继续进行。

常用的工具有sonarqube，因为他有社区版，免费。社区版缺点是某些语言不支持，需要自己找第三方的插件包。商业版的收费比较贵。
参考地址：https://www.sonarsource.com/

详细介绍文档：https://zhuanlan.zhihu.com/p/617789712

自动化测试

现在比较成熟的自动化测试一般是指API测试，前端的UI虽然也有自动化测试，但是没有特别成熟和方便的工具，这里推荐国内飞致云开发的开源持续测试平台MeterSphere。

MeterSphere 是一站式的开源持续测试平台，遵循 GPL v3 开源许可协议，涵盖测试管理、接口测试、UI 测试和性能测试等功能，全面兼容 JMeter、Selenium 等主流开源标准，有效助力开发和测试团队充分利用云弹性进行高度可扩展的自动化测试，加速高质量的软件交付。

参考地址：https://metersphere.io/

它虽然带有UI测试，但那是企业版功能，收费。metersphere带有jenkins插件，可以对接jenkins，完成流水线自动化测试。

开源地址：https://github.com/metersphere

结果通知

流水线的运行结果需要通过有效途径及时通知责任人，现在大众的办公软件都有基于webhook或者自开发应用的通知方式，比如飞书、钉钉、企业微信等，如果没有自开发应用机器人的经验，可以直接使用这些工具的群机器人，自带webhook，将流程相关人员集合到一个群里，不通的流程@不同的责任人即可。详情请参考各工具官方开发文档。
企业微信：https://open.work.weixin.qq.com/
钉钉：https://open.dingtalk.com/
飞书：https://open.feishu.cn/

版本管理

首选还是gitlab，功能齐全，方便实用。但是这个根据各公司具体规定执行，不做讨论。

sql版本管理

sql的版本管理是各难点，项目上经常会因为sql与代码关系的管理出现问题，最好是能有一个sql版本管理工具，比较推荐的是国外的一款开源工具Liquibase,这款工具支持多款数据库，大家有兴趣的可以去了解一下。
相关介绍：https://zhuanlan.zhihu.com/p/660238054
开源地址：https://github.com/liquibase/liquibase

多集群功能架构图示例

根据以上工具，大概绘制了一个多集群下的功能架构图

这里是在大业务量，预算充足或者对性能要求较高的情况下，做的一个规划，在预算不足的情况下，可以将一些集群功能合并，比如将构建集群放到开发或者测试集群里。

自动化的核心就是构建集群，CI/CD的所有功能都集中在这个集群上。这个集群的构建需要有以下几个关键点：

1. 选定合适的CI/CD工具，这个是基座。之前写过一篇文章，介绍如何使用Jenkins对接K8S的，有兴趣的可以参考一下：https://blog.csdn.net/Mrheiiow/article/details/131421444
   其他CI/CD工具网上都有相关教程，我在后边也会慢慢整理相关部署过程。
2. 各功能平台对接CI/CD工具。这个网上或者官方也有相应的教程，可以惨开，我们当时主要实践的是Jenkins，所以后期我也会整理一份各种工具对接Jenkins的流程文档
3. 如果有条件，最好是基于部署好的这一套，开发一个前端控制界面，并做好权限划分，最主要的是针对流水线的的控制的，不是针对这些工具使用的，这样方便对整个发版流程进行控制，经验之谈。

在云原生领域，还有一个更受大家倾向的GitOps,他倡导IaC（Infrastructure as Code）：基础设施即代码，我个人觉得他比传统的部署方式更方便，之前写过一篇博文：https://blog.csdn.net/Mrheiiow/article/details/130106620，有兴趣的可以看一下