导航菜单
路很长,又很短
博主信息
昵   称:Cocodroid ->关于我
Q     Q:2531075716
博文数:356
阅读量:1648475
访问量:205681
至今:
×
云标签 标签球>>
云标签 - Su的技术博客
Tags : DevOps发表时间: 2021-11-12 08:16:00

哪吒 八戒技术团队

前言

时间先回退到2011年,那时候我刚加入猪八戒,加入公司之前我还不知道svngit是什么东西,连发布代码也是用的最传统的FTP上传方式。而早在2009年,来自Flickr员工在一场会议中所揭露了如何改善DevOps的合作,达到了单日10次发布的高速度,催生了后来的DevOps运动。(题外话FTP的方式几秒就能发一次代码)所以DevOps到底解决了什么问题呢?接下来结合猪八戒的不同阶段给大家介绍一下我们的DevOps演进之路。

猪八戒devops演进之路

1、初创期

虽然2009年就提出了DevOps,但国内很少人听说过这个名称,但是这并不代表我们没有去解决devops的协作问题。

那一年猪八戒网仅有4台物理机,托管在某IDC机房,总的工程数20左右,均为PHP工程,技术人员20左右,由于迭代的频率很高,每天发布30+次,公司仅有2个运维人员,所以如果没有自动化的方式是很难完成这么高频率的发布的,所以有了公司第一版的“DevOps”

如下图:

图片

上图的流程特别简单,使用svn管理代码,有两个固定的分支,一个用于发布到测试环境,一个用于发布到线上环境。研发提交代码后,通过svn自带的hooks功能配合rsync将代码分发到对应的服务器,由于当时所有应用都是部署在一台物理机,所以只需要全量pull即可完成发布。通过这套简单的流程即可实现研发合并并提交代码即可发布上线。解决了快速发布的问题。

2、业务增长期

时间到了2013年,业务也快速增长服务器、应用、研发人员都出现了很大规模的增长,伴随着很多问题也出现了,随意的发布让线上环境变得很不稳定,配置文件变更不当导致全站500频频出现。虚拟机的引入也让之前的发布方式变得难以支持。所以此时急需对之前的发布方式进行升级,来满足现阶段的需求。

如下图:

图片

这个阶段最大的变化是大量使用虚拟化,并对应用进行了独立部署,同时为了控制发布取消了svn hooks引入了SYN系统(我们内部取名)。

SYN主要解决以下几个问题

1、权限控制(可以控制到工程、环境、发布时间)

2、引入exclude_list来解决配置文件变更的问题

3、工程代码映射关系(CMDB1.0维护工程和机器的关系)

4、代码分发

通过SYN系统的引入,线上的稳定性开始变好,配置文件研发提交申请由运维人员统一进行维护,出现配置异常的情况也大幅下降,然而发布的效率也相对之前减少了很多。

3、多语言

时间到了2015年,业务规模和人员规模再次出现了大幅增长,开发语言也由以前的纯PHP到大量引入JAVA语言,显然之前的SYN系统已经不能满足需求。这时我们开始引入Jenkins来解决CI的事情。其他结构基本没有多大的变化。

如下图:

图片

我们继续沿用了之前的SYN系统来控制权限,但是CI部分全部交给了Jenkins,这个阶段我们的CMDB也完成了代码、工程、资源的100%关联。所以CD部分也变得非常方便,有一个短暂的阶段为了解决多部门联调的问题,出现了10套测试环境,得益于CMDB信息完善以及一些自动化的能力,所以在资源足够的情况下可以很快速的完成一套环境的搭建。

4、微服务、容器

时间到了2016年,这个时候公司也引入了很多大厂的大牛,微服务、容器、DevOps也进入了我们世界,于是就有了长达2年的DevOps研发之路。

先看一个图:

图片

这种架构我相信了解过DevOps的都不会陌生,这里我重点介绍3个不一样的地方。

(1)基于JIRA的研发流程管控。通过JIRA管理研发流程,发布的时候严格校验状态,确保所有发布均符合研发规范。

(2)SDL和流水线结合(DevSecOps),从创建工程的安全评审,到每次提交代码的自动扫描,再到发布的安全测试,确保每一次发布的代码都是安全的。

(3)猪八戒容器云,完美实现了流水线和多个K8S集群的封装,解决了跨机房部署等问题,目前猪八戒网90%的工程均运行在容器中,较之前使用虚拟机部署减少资源60%以上,大幅减少了IT成本,同时服务发现、滚动发布、动态扩容等也让业务更加稳定。

附容器云项目核心组件(如果大家对容器云感兴趣可以在评论区留言):

图片

目前我们的流水线每天支持业务发布150+次,发布成功率99.8%+,完成一次从测试环境到线上发布平均耗时595s

5、一站式研发平台

DevOps只是研发过程中的一部分,所以我们需要有一套新的平台来解决工程的全生命周期管理。去年10月份我们开始以需求为出发点,围绕工程全生命周期管理的平台打造。底层架构和上面的没有什么区别,只是对产品做了大量减法,让产品的用户体验更好,下面从功能角度简单介绍一下我们的一站式研发平台。

(1)重新定义工程类型,对历史所有工程进行盘点最终梳理出6大类型便于研发准确的创建工程。根据类型不同最小化的让用户输入信息。

图片

(2)本着谁定义,谁负责的DevOps理念,一站式研发平台把所有权限交给了工程负责人。工程负责人可以完成配置、发布,接收告警等所有工程管理配置功能。

图片

图片

(3)需求发布

前面已经提到,我们对研发流程管控是较为严格的,任何需求的发布都需要经过严格的流程审批,每个流程可以发布的内容也是严格限制的。为此我们引入需求管理,把每次交付串联起来。

图片

图片

(4)技术架构

一站式研发平台围绕项目全生命周期,以场景化的方式把可能用到的研发工具串联起来,各个功能仍然由不同的子系统完成。整体架构如下图。

图片

对于云原生的一些看法

我个人是比较拥抱云的,特别是云原生,我们目前业务虽然都在云上,但是全都是使用的云的基础设施,其他服务全都是内部团队在做,从投入的角度来说确实很大,而且期间也不乏走了很多弯路,我也听到很多关于拥抱云原生应用后的一些担忧,确实有利有弊,自建对于技术团队来说更加灵活因为技术相对可控,一旦拥抱云就会有很多限制,毕竟云上都是通用能力,如果有大量定制化的需求很难得到满足。另外如果企业已经投入了大量的成本有一套自有的能力,上云短期也会有很大的适应、改造和资金成本。

引用孙子兵法开篇的第一句话兵者,国之大事,死生之地,存亡之道,不可不察也。是否拥抱亦是如此。


本篇文章主要是整体介绍,不涉及过多技术实现细节,如果各位对哪方面感兴趣可以在文末留言,后续我们的技术大牛输出相关技术细节文章。


...阅读原文
推荐文章