Su的技术博客

  • 首页
  • Java
  • MySQL
  • DDD
  • 事故复盘
  • 架构方案
  • Other
  • 工具
  • 打赏
  • 关于
  1. 首页
  2. 架构方案
  3. 正文
                           

【八戒】猪八戒十年DevOps演进之路

2023-02-19 34点热度 0人点赞 0条评论

前言

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

猪八戒devops演进之路

1、初创期

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

那一年猪八戒网仅有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)技术架构

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

图片

对于云原生的一些看法

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

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


 

标签: 八戒 云原生 研发 演进 devops 架构
最后更新:2023-02-19

coder

分享干货文章,学习先进经验。

打赏 点赞
< 上一篇
下一篇 >
最新 热点 推荐
最新 热点 推荐
殷浩详解DDD 第四讲:领域层设计规范 既生@Resource,何生@Autowired? Go整洁架构实践 接口优化的常见方案实战总结 QQ音乐高可用架构体系 构建一个布隆过滤器 —— Building a Bloom filter
殷浩详解DDD 第四讲:领域层设计规范Redis为什么这么快?构建一个布隆过滤器 —— Building a Bloom filterQQ音乐高可用架构体系接口优化的常见方案实战总结Go整洁架构实践
记一次升级MySQL驱动包引发的事故 猪八戒网DevOps之Java组件安全检测 Eureka源码剖析之七:架构&面试题【总结】 殷浩详解DDD 第三讲 - Repository模式 这些MQ概念你都懂吗:死信队列、重试队列、消息回溯等 笔记 | 5种网络IO模型

@Autowired (1) @Resource (1) API网关 (1) ddd (6) DP (1) ElasticSearch (1) eureka (7) go (1) HTTP (1) IDEA (1) iOS (1) Java (8) JSR (1) QQ音乐 (1) repository (1) Spring (1) SQL优化 (1) 代理 (1) 依赖注入 (1) 同城双活 (1) 垃圾回收 (1) 定时任务 (1) 容灾 (1) 布隆过滤器 (1) 异地双活 (1) 接口优化 (1) 故障转移 (1) 数据库 (2) 整洁架构 (1) 文件网关 (1) 方案 (2) 服务续约 (1) 注册中心 (7) 流水账 (1) 流量 (1) 第五 (1) 线上案例 (1) 线上问题 (2) 缓存 (1) 缓存击穿 (1) 编译 (3) 网络 (3) 聊聊 (1) 订单 (1) 设计规范 (1) 详解 (1) 连接池 (1) 限流 (1) 领域驱动设计 (4) 高可用 (1)

COPYRIGHT © 2014-2023 verysu.com . ALL RIGHTS RESERVED.

Theme Kratos Made By Seaton Jiang

粤ICP备15033072号-2