代码编织梦想

 devops是什么


DevOps维基百科定义 DevOps(Development和Operations的组合词)是一种重视“软件开发人员(Dev)”和“IT运维技术人员(Ops)”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程,来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。


这里先给出维基百科的定义,没指望你一下子看懂,先有个概念了解一下。

devops概念提出

单体架构+瀑布模式

单体应用架构

 

瀑布开发模式
以电商系统为例,单体应用架构为 LNMP,这个时候只有 DEV 没有 OPS,DEV 就是全栈,就跟我们上大学玩的 demo 一样,项目开发好,找台服务器安装好环境,把 jar 包 scp 到远程服务器,放上去开启服务就可以。

这个时候服务监控也简单,服务出了问题,直接去线上看一下运行日志,为了解放双手监控服务,开发者会写一些脚本分析日志,服务器少,部署简单,通常开发就可以完成运维的工作,不需要专门的运维来做部署,所以开发模式很简答,直接按照瀑布流方式开发就可。

分布式架构+敏捷开发模式

分布式架构

敏捷开发模式
随着业务体量发展越来越大,一台机器扛不住,那么就加机器,单机变多机,业务架构也开始加入了 nginx,cdn,缓存等通用基础服务,业务变多肯定会招人,就涉及到多人协同开发,多人多机器模式。

多人协同开发问题:

先说说多人协同开发问题,人员一多,为了更好的分工,大多会将项目进行拆分,每个人负责专注于一部分,有点包干到户的感觉,敏捷开发的核心理念就是既然我们无法充分了解用户的真实需求是怎样的,将一个大的目标不断拆解,把它变成一个个可交付的小目标,然后通过不断迭代,以小步快跑的方式持续开发。。另外,一个项目是很大的,为了保证项目质量,测试环节不可减少,为了加快速度增大开发效率,QA的工作最好是和开发同步交替进行的,需要将测试环节从后面注入到整个开发环节当中,每次可交付的都是一个可用的功能集合,对开发交付的内容进行持续验证。这样开发产品的可控性也更强,遇到了sb甲方的时候,阶段性的让他检验一下项目成果,防止画鸡成鸭。


打架吗?
多机器问题:

再说说多机器问题,之前机器很少架构简单的时候,开发就可以干运维的活,就算加了几台服务器,那也是脚本将 JAR 包同时发布到这些机器上,好像也挺简单,但是会有两个人同时上线部署被覆盖的问题,所以大家在上线之前可能会去群里吆喝一声,”我要上线了,大家先别上线哈“,可想而知这样效率也很低下。

公司业务一大,像大公司的动不动就是几千台服务器,就需要专门的运维介入了,一方面是因为开发分工每个人都专注于自己的事情,不会那么用心进行维护,另一方面是运维的学习成本确实变高了,开发人质量参差不齐,服务器要是每个人都可以上估计领导每天晚上都要做噩梦。但是这个时候也不是 DEVOPS,而是 DEV+OPS,这时 Ops 的主要职责就是:硬件维护、网络设备维护、DBA 、基础服务维护、数据监控等,运维们擅长写各种部署,监控脚本,减少机械的重复工作,开发模式变成了敏捷开发模式。

开发和运维角色的天生对立问题:

加入运维,就要协调人员配合,运维的宿命就是维稳,他们是很讨厌变动的;开发的天职确是不断地推代码上线,进行代码变动,更替迭代,这两个工种天生就是对立的。

很多大公司有那种,开发人员想要上线,需要提交各种审批,层层签字画押,多少人的上线激情被一句冷冰冰的‘还没到窗口发布期’给泼的透心凉。所以,敏捷开发解决了协同开发和多机器部署开发问题,但是没有解决内部人员的矛盾,留着这个矛盾在公司,开发和运维随时都可能约‘生死架’。

微服务架构+DEVOPS

 

微服务架构

 

DEVOPS

wiki定义微服务: 微服务(英语:Microservices)是一种软件架构风格,它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模块化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic)的API集相互通信。


上面是我摘自wiki对微服务的定义,注意几个关键词:软件架构风格,小型功能区块,模块化,语言无关。

第一,公司发展到BAT这种体量,会招很多人,JAVA,PHP,GO 技术栈都会有,需要协调技术栈;第二,项目到后期往往会变得很大,全部都兑到一个项目里,最直接的后果就是项目变得很大,上线项目启动时间变长,一个BUG可能导致整个业务全线崩溃,最终的后果就是项目变得越来越难以维护,加一个改一个东西几乎搞不动,而且还越来越难重构,牵一发而动全身。

所以,拆分解耦是最终的出路,将项目拆成一个个小的服务单独部署,以电商项目为例如图,将整个项目拆分为用户服务,商品服务,订单服务,积分服务......每个服务单独部署,之间通过互相调用的方式来交互,而且可以将一些基础服务例如上传图片,发送短信等很多服务都需要的基础东西,抽象到一个单独的服务,也就是前些年鼓吹的很厉害的‘中台服务’。

拆分部署催生出DEVOPS 再看看这种架构下的开发模式DEVOPS,运维需要做的上线工作,主要就是将代码部署到对应的机器里面,微服务有那么多的服务,每个大点的公司几百个服务不算多,而且还可能随时搞一个服务出来,如果还按照原始的脚本部署方式,可能最后连是哪个脚本都找不到。而且,如果每个服务上线都需要运维来同意,开发也太卑微了,估计要天天求着运维同意发布,运维也会烦不胜烦。

那么为何不能再远程部署一些机器,专门用来管理代码,进行上线工作,由运维事先把上线的规则都给定义好了,开发只要按照他的规则都访问这台服务器进行各自的代码合成和发布,自己上线呢,能用代码自动完成的事情就绝不要手动解决,这是每个开发人员都在想的东西。运维需要做的事情,慢慢的都沉淀到了各个平台上面,例如监控,有专门的监控组件和可视化,基础服务例如服务器,CDN,负载均衡等基础服务可以外包到云服务厂商,日志也有专门的日志工具,链路追踪也有专门的组件和可视化,还有网关等,渐渐的,只要这些都配置好了,开发也可以做运维的部分工作,毕竟开发才是最了解代码的人,哪里出了问题看看监控日志,可以最快速度定位到问题,于是DEVOPS开发模式诞生了,开发也是运维。

devops深度理解
我们知道,一个软件从零开始到最终交付,大概包括以下几个阶段:产品规划、开发编码、构建、QA测试、发布、部署和维护。

最初大家说到DEVOPS,都是指的‘开发运维一体化’,如下图: 

 

现在大家说的 DevOps 已经是扩大到“端到端”的概念了,如下图:

 


广义上的DevOps
DevOps 的三大支柱之中,即人(People)、流程(Process)和平台(Platform)。即

DevOps = 人 + 流程 + 平台

人 + 流程 = 文化

流程 + 平台 = 工具

平台 + 人 = 赋能

devops实现相关工具
人自然不用多说,开发前后中涉及到的所有人,流程前期是产品出原型,UI出设计,然后前后端代码开发,QA测试,最终部署上线,下图是部分流程图:

 


流程图
这里重点来看看devops平台搭建工具,工具很多,组件很多,百家争鸣,这里我列举的大多数是我公司用的,也是大部分公司都在用的。

devops平台搭建工具
项目管理(PM):jira。运营可以上去提问题,可以看到各个问题的完整的工作流,待解决未解决等;

代码管理:gitlab。jenkins或者K8S都可以集成gitlab,进行代码管理,上线,回滚等;

持续集成CI(Continuous Integration):gitlab ci。开发人员提交了新代码之后,立刻进行构建、(单元)测试。根据测试结果,我们可以确定新代码和原有代码能否正确地集成在一起。

持续交付CD(Continuous Delivery):gitlab cd。完成单元测试后,可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题,可以继续手动部署到生产环境中。

镜像仓库:VMware Harbor,私服nexus。

容器:Docker。

编排:K8S。

服务治理:Consul。

脚本语言:Python。

日志管理:Cat+Sentry,还有种常用的是ELK。

系统监控:Prometheus。

负载均衡:Nginx。

网关:Kong,zuul。

链路追踪:Zipkin。

产品和UI图:蓝湖。

公司内部文档:Confluence。

报警:推送到工作群。

有了这一套完整的流程工具,整个开发流程涉及到人员都可以无阻碍的进行协调工作了,开发每天到公司,先看看jira,看看线上日志,出了问题看看监控日志,运营同学反馈问题不着急的去JIRA,着急的群里吆喝,产品和UI的图直接蓝湖看,运维关注监控着大盘,改革春风开满地,互联网人民真高兴~

这一篇有点姗姗来迟的意味,之前一直陷入了迷茫不知道该写什么,于是低调的修炼,有了这一篇,有问题欢迎指正,关注我的公众号’阿甘的码路‘,即可联系到我,很开心你能看到这里,共同努力,共同进步。
 

 

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/m0_72780301/article/details/127002479

什么?还没听说过prometheus,或许你需要了解这些知识点_linux云计算网络的博客-爱代码爱编程

阅读本文大概需要 6 分钟。 福利:文末留言送 3 本《Prometheus监控实战》,豆瓣评分高达 9.0 分,希望大家积极留言,每个人都有机会。 导语:Prometheus是一个开源的监控系统,它从应用程序中实时获取时间序列数据,然后通过功能强大的规则引擎,帮助你识别监控环境所需的信息。

史海峰:构建产业互联网金融系统的正确姿势-爱代码爱编程

史海峰 IT民工闲话 读完需要 12分钟 速读仅需 5 分钟 引言     互联网下半场从 ToC 进入 ToB 阶段,玩法不再是烧钱拉流量转化变现,而是深入产业核心领域,通过技术提升生态链整合能力,优化生产要素配置,从而改变生产关系,创造新的业务模式,建设产业互联网,推动产业转型升级。在产业互联网领域,技术的价值在于赋能商业本质,成为

一文彻底读懂DevOps与SRE来龙去脉-爱代码爱编程

若是把运维当作一门学科来看,是有难度的.不仅因为如何很好的运行系统这种普遍问题未得到解决外,现存的最佳实战也因高度依赖环境,而未得到广泛使用;另外一个未解决的问题就是如何更好的管理运维团队。详细分析这些问题通常被认为起源于致力运筹学的研究,在第二次世界大战期间用于改善盟军的进程和产出,但事实上,几千年来,我们一直在思考如何更好的运营然而,尽管有这

【Yaml】了解yaml文件格式-爱代码爱编程

目录 一、简介二、基本语法三、数据类型四、数据结构 一、简介 YAML 是一种较为人性化的数据序列化语言,可以配合目前大多数编程语言使用。 YAML 的语法比较简洁直观,特点是使用空格来表达层次结构,其最大优势在于数据结构方面的表达,所以 YAML 更多应用于编写配置文件,其文件一般以 .yml 为后缀。 二、基本语法 1. 大小写敏感

一文读懂微服务架构设计-爱代码爱编程

一、前言 微服务(MicroServices)是一种架构风格,一个大型复杂软件应用由多个微服务和前端展示层组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下,每个任务代表着一个小的业务能力。以往我们开发应用程序都是单体应用(可以理解为一个部署包包含了项目的所有功能),虽然开

智领云CTO 宋文欣: 云原生是数据中台的必经之路-爱代码爱编程

当今商业已迈入了数据的时代、算法的时代。企业在面对政治、经济、技术、市场等各方面不确定因素的挑战下,亟待以客户为中心,满足客户的个性化需求。通过数字化、智能化能力提升企业经营水平、提高创新能力,寻求可持续发展之路。此时,数据中台战略则成为企业数智化转型的重要举措。 随着企业业务不断上云,微服务、容器化架构的不断应用,兼顾了DevOps标准,满足持续

一文说清DevOps与敏捷的区别与联系-爱代码爱编程

如果要讨论敏捷和DevOps之间的区别与联系,首先看一下他们产生的背景。在软件开发的整体流程之中,存在着很多环节,这些环节之间,也都存在着很多障碍。 如图所示,在客户/用户、业务部门、开发部门、运维部门之间,都有各自不同的工作目标。 对于客户/用户而言,他追求的目标就是降本增效。无论是ToB还是Toc类产品,他们都希望产品使自己的业务或者生活越来越

k8s集群安装devops_凌晨里的无聊人的博客-爱代码爱编程

以 admin 身份登录控制台,点击左上⻆的平台管理,选择集群管理。 2. 点击⾃定义资源 CRD,在搜索栏中输⼊ clusterconfiguration ,点击搜索结果查看其详细⻚⾯。 信息 ⾃定义资源定义(CR

一文讲透低代码-爱代码爱编程

目录 一、低代码的定义与发展二、低代码的特点三、低代码的技术路线1、行业观点2、低代码的技术路线 四、低代码开发者有哪些五、低代码赋能业务人员六、低代码对业务开发者的价值七、低代码的应用价值八、低代

想进大厂, jira 管理平台你会用么?_jira平台-爱代码爱编程

作为一名测试工程师,管理bug的生命周期是每天必备的日常工作;所以缺陷管理流程,以及缺陷如何记录并完成跟踪,都是测试必须要掌握的技能,然而管理缺陷需要借助缺陷管理平台。 目前比较主流和常见的一些缺陷管理平台有如下几款:

软件公司如何提升效能?研发团队的北极星指标_研发人效分析-爱代码爱编程

本文作者:汤雪 孟黎明 目录 前言 Kyligence 探索与实践 先进的技术架构——一切工作的基石 规范的研发流程——保证效率和质量 可信的指标数据——管理、追踪、改进的抓手 数字化管理工具——提升人效、决策闭环 结语 前言 近年无论是国内还是国外,ToB 行业赛道都十分火热,但国内市场到目前还没有巨头出现。对于 ToB 企业

如何摆脱数据孤岛问题?_解决多系统数据孤立的方案-爱代码爱编程

某银行有着良好的信息化基础与数字化积淀,已建成了以综合业务系统、CM2006信贷管理系统、国际结算系统为主体的业务处理系统,以及以统计数据集中管理系统、债券核算系统、人力资源管理系统等为主体的信息管理系统。 但随着内部管理和外部监管要求的不断提高,以及面向数据分析的管理应用需求日益增加,在银行对数据的应用提出了更高的要求的背景下,原有的数据整体建设方