DevOps系列(1)-总体架构

标签：服务   pull   失败   企业   证明   文章   net   图片   技术   

扯闲淡

在进入正式话题之前，先扯个淡，这算是第一篇我正式在博客上发布的随笔吧，之前也一直有想写点什么，将自己多年的工作经验分享出来，供大家参考点评，但是奈何一直对自己的文字功底不自信（其实也确实比较烂，上学期间，语文永远是拖后腿的），当然，最主要还是因为自己的懒惰，导致一直没有付出行动。

细算下来，到目前为止，我从事.Net开发已经差不多八年了，也算是一只见证了.Net从兴起到衰落（不知道这么说会不会被打）再到逐渐有复苏迹象的老鸟了。在这个过程中，带过团队，也担任过架构师（当时为了证明自己并非野路子，2018年还专门拿下了软考《系统架构设计师》认证）。在企业内部Wiki上也写过不少文章，做过不少技术分享，但毕竟是小群体，文章写得再烂(甚至只有提纲，或者只字片语，或者只有一张图)，也可以通过沟通解释清楚，就算真的写错了，也会有很多补救措施，不会产生什么不良影响。而对外发布，对内容的完整性，严谨性以及文字组织能力的要求就要高得多，而这正是我不得不花精力填补的短板。

2020年注定是不平凡的一年，对于我们这些.Neter来说更是如此，我不确定能否通过文字完整的出自己的思想，但是我会尽力，希望我的文字不会带偏你的思路，当然，如果你能赞同我的观点，并能从中得到一点点启发，那将是我莫大的荣幸。

好了，闲淡扯完了，进入今天的正题吧！

总体架构

在这里，我准备结合自己的工作经历和个人理解，针对当前比较火热的DevOps话题出一个文章系列。但是，在这之前，有必要从整体上梳理一下思路，圈定一下范围，以保证整体思想的一致，并方便后续文章的展开。

这个系列并没有涵盖DevOps的全部内容，例如，没有包含服务的链路追踪、日志监控、健康检查等微服务相关的部分，也没有包括集群和容器的监控、管理、健康检查、报警等更偏向运维的部分，而是更多的聚焦在CI/CD上。微服务相关的部分后面可能单会独写一个系列详细探讨，而运维相关部分则不会过多涉及，即使是K8S容器编排也只会点到为止，因为这部分我自己接触的也比较少，不敢瞎写。

概览

注意，这里的Jenkins并非部署了多套，而是在同一套Jenkins中根据部署环境的不同划分了多个分组，每个分组有各自不同的权限和功能。

流程说明

1. 开发人员每次写完代码之后，Push到源代码仓库（企业中一定会有自己SVN或者Git等私有仓库，这是即使没有DevOps或CI/CD概念也会存在的最基本的基础设施，我后续会直接使用GitHub，因此不会单独介绍这部分内容），自动（或者定时轮询）触发Jenkins构建，完成Nuget包还原，静态代码审查，单元测试，上传报告到SonarQube服务器，如果构建失败，或者代码审查和单元测试报告不达标（实际工作中，由于各种原因，这个目标比较难以达到），则反馈开发修复，如果达标则构建镜像并发布到开发环境的Docker容器中；
2. 开发人员功能开发完成，并通过开发环境容器测试通过后，将Dev分支合并到Master分支，并发送提测通知到测试人员；
3. 测试人员（可以在分支合并的时候自动触发，或者定时轮询）构建Master分支，大体流程跟开发分支相同，不同点就是会发布到尽量贴近生产环境的Docker集群，同时将镜像Push到Harbor镜像仓库；
4. 测试人员测试通过后，通知运维人员安排上线；
5. 运维人员通过手动触发Jenkins的方式，先从Harbor上Pull对应版本的镜像，并逐步分阶段完成到生产环境Docker集群的部署。
6. 剩下的就是生产环境α测试和β测试及一系列的监控了。

总结

DevOps更多体现的是一种思路和流程，可能每个团队做法都不一样，例如，有的团队可能在Dev分支上测试，而在Master分支上构建生产环境镜像；有的团队可能因为环境隔离的原因，不得不部署多套Jenkins环境等，但归根结底目的是一样的，就是达到全程自动化，减少人力劳动（不知道算不算自己砸自己饭碗）以及各种人力，环境等因素导致出错的概率。

后续的文章我会按照这个思路展开，如果存在考虑不周，或者可以改进的地方，希望各位大佬们能够及时指出，大家一起探讨，共同进步！

最后，希望.Net生态越来越好！

DevOps系列(1)-总体架构

标签：服务   pull   失败   企业   证明   文章   net   图片   技术   

原文地址：https://www.cnblogs.com/FindTheWay/p/13172260.html