找回密码
 会员注册
查看: 15|回复: 0

云原生架构下的持续交付实践

[复制链接]

2万

主题

0

回帖

7万

积分

超级版主

积分
72245
发表于 2024-10-6 17:59:33 | 显示全部楼层 |阅读模式
全文约6100字,预计阅读时间15分钟导读随着虚拟化技术的成熟和分布式框架的普及,在容器技术、可持续交付、编排系统等开源社区的推动下,以及微服务等开发理念的带动下,应用上云已经是不可逆转的趋势。微服务架构下服务数量爆炸式增长,对应的交付基建工作量暴增,且服务间拓扑复杂,又导致了升级影响难评估、问题定位困难、单独测试环境成本极高等问题给高效能交付带来了极大挑战。另一方面,云原生带来了标准化、松耦合、易观测、易扩展的特性,为交付基建与业务解耦、更灵活的环境管理和、无损发布带来新机遇。爱番番产品从 20 年 4 月 全面云化,在云化时代,我们如何克服上述效能挑战,同时利用云原生的技术红利实现产品的高效能交付呢?1. 微服务架构下效能体系面临的挑战爱番番是典型的 toB 型业务,具有以下特点:从产品形态上,产品战线长,涵盖 ( 拓、聊、追、洞察 ) 等核心产品能力。从市场环境上,市场环境环境竞争异常激烈,对产研的效率与质量提出更高的要求。从研发模式上,产品与研发采用敏捷思维研发,需要不断的创新与试错,快速完成 PoC及 MVP 产品的研发上线。从部署形态上,除了提供 SaaS 服务外,同时具有多样化售卖的诉求。团队以业务领域划分的多个?scrumTeam,如下图:团队持续交付面临的挑战:服务爆炸导致的基础设施成本剧增。活跃模块数 200+,月均新增模块 8个,每个模块需要接入的基础设施如下图,导致需要大量人力进行流水线、监控等基础设施接入管理维护。复杂拓扑导致的问题定位困难和回归范围难以评估。服务间拓扑复杂,导致升级影响难评估、回归漏测多、线上问题定位困难、环境规模庞大,联调测试成本高等问题。越来越高频的发布需求和随拓扑复杂度提升的发布成本的矛盾。模块众多且复杂拓扑,而且模块间上线有依赖关系,每次上线 100+ 模块,人工控制流程,风险高而且效率越发低下,但业务上发布的需求愈发频繁,在高频次的发布下,如何保障发布过程的高效、安全也是一项极大的挑战。2. 云原生架构下的持续交付实践为实现团队高效的价值交付,我们从敏捷机制改进和全流程持续交付能力提升两方面开展了建设:流程机制层面:?用户价值,流动效率提升为核心的敏捷体系建设,包含以下几个方面:敏捷迭代机制:以用户价值流动效率为核心理念,保障团队目标一致,信息透明。需求拆分管理:标准化、可视化、自动化的管理机制,在成本可控的前提下达成小批量需求加速流动,快速验证价值。分支模式和环境管理:基于云原生强大的流量管控能力,实现基于 istio 的全链路灰度环境能力,实现简洁、灵活、低风险的分支模式。全流程的数据度量体系:通过目标指标度量了解现状,过程指标度量挖掘问题,问题自动创建任务,协同 peer 推动问题闭环。技术层面:全流程环节自动化智能化提升,包含以下几个方面:基础设施:建设与业务解耦的基础设施服务,解决服务爆炸带来的成本问题。自动化:微服务下合理分层自动化体系,可控投入下保障有效质量召回,解决复杂拓扑带来的回归漏测问题。发布能力:一键操作高效执行、过程可视、可感知、可控的极致发布体验,解决高频发布需求下的发布成本问题。工具赋能:丰富的工具能力赋能研发测试各效能痛点环节,为人员赋能(建设中,本文暂不详细介绍)。下面主要从技术层面的 3个 方向逐一进行方案说明。2.1 基础设施:与业务解耦的 Devops 基础设施服务什么是与业务解耦的基础设施?这里的与业务解耦其实是借鉴了serverless 的思路,是指把基础设施服务化,独立运维。以前,我们的业务团队研发和 QA,除了需要进行业务的开发和测试工作之外,有大量的时间都花费在了新应用、日志、配置的接入以及环境、流水线、监控维护等等和核心业务无关的事项上,就像下面这个图的左边,而且,任意基础设施服务要升级,比如日志平台 SDK 升级、流水线需要统一增加一项安全检测环节等等,都需要各个业务团队配合升级,落地推广困难。如果我们把这些基建内容通过服务化的形式提供给业务团队使用,就能让业务研发和 QA 聚焦于业务的关键事项,从而大幅度提升团队效能。就像下面的右边这个图。同时基础设施的升级业务无感知,再也不会有基础设施能力落地推广困难的问题。上文已经提到,基础设施面临的最大问题是,由于爆炸的服务个数带来的暴增的 Devops 基础设施接入和维护成本问题。如果能打造服务化的基础设施,就可以实现基础设施的 0 成本接入和运维。那么如何打造与业务解耦,服务化的基础设施呢?2.1.1 基础设施标准化与业务解耦的第一步是基础设施的标准化,只有标准化的过程才有可能规模化,从而实现技术设施服务化。我们主要针对以下几部分内容进行了标准化改造:模块标准化:代码结构、打包流程、标准容器、镜像管理、部署过程。标准流水线标准的基础服务:APM组件、配置中心、发布平台、资源管理。研发模式:2.1.2 声明式基础设施与业务解耦的第二步,是基于标准化的基础上,建立声明式的基础设施能力。这里的声明式是指给业务团队声明式的基础设施体验。业务团队只需要在标准配置中声明一些基础属性,即可自动完成所有基础设施的接入,且后续维护上业务 0 成本。主要分为两个环节的建设:接入时:分钟级的一键接入我们的做法是通过脚手架为抓手来构建基础设施的一键接入能力。如下图所示:脚手架:自动生成框架代码,包含基础 apm 组件、api 管理平台等的接入。configMap:自动生成应用标准配置并基于配置新增/变更主动触发接入服务。接入服务:拉取 configMap 配置并解析,根据配置内容调度不同的基础设施服务完成接入初始化。脚手架是我们这边新模块创建的入口。所有新代码库都是通过脚手架创建,他会帮助开发自动生成一整套集成了标准组件的代码框架。在脚手架创建新模块的时候,根据业务声明的模块属性,如是否接入 apm、模块代码类型、模块服务类型等等自动完流水线创建、基础组件接入、集群环境申请、配置文件生成等操作。一个新的服务,从创建代码库到服务全套基础设施接入完成,服务可直接部署到测试集群的时间
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 会员注册

本版积分规则

QQ|手机版|心飞设计-版权所有:微度网络信息技术服务中心 ( 鲁ICP备17032091号-12 )|网站地图

GMT+8, 2025-1-11 07:52 , Processed in 1.176590 second(s), 26 queries .

Powered by Discuz! X3.5

© 2001-2025 Discuz! Team.

快速回复 返回顶部 返回列表