陕西省城乡建设网站,手机制作3d动画,做 淘宝客最大的网站是叫什么,seo公司怎样测试环境对于任何一个软件公司来讲#xff0c;都是核心基础组件之一。转转的测试环境伴随着转转的发展也从单一的几套环境发展成现在的任意的docker动态环境docker稳定环境环境体系。期间环境系统不断的演进#xff0c;去适应转转集群扩张、新业务的扩展#xff0c;走了一些… 测试环境对于任何一个软件公司来讲都是核心基础组件之一。转转的测试环境伴随着转转的发展也从单一的几套环境发展成现在的任意的docker动态环境docker稳定环境环境体系。期间环境系统不断的演进去适应转转集群扩张、新业务的扩展走了一些弯路但最终我们将系统升级到了我们认为的终极方案。下面我们介绍一下转转环境的演进和最终的解决方案。
1 测试环境演进
1.1 单体环境 转转在2017年成立之初5台64G内存的机器搭建5个完整的测试环境。就满足了转转的日常所需。一台分给开发几台分给测试。通过沟通协调就能解决多分支并行开发下冲突问题。 1.2动态环境稳定环境 随着微服务化的进行转转的服务数量是急速扩充的。分支并行开发增多共用环境造成的互相影响也逐渐增多。单体环境已经不能满足我们的需求。新的组织形式被提了出来。动态环境部署修改的服务和一些必要服务。稳定环境部署和线上一致的服务。同时我们开发了一个环境平台去管理环境的申请到回收的整个生命周期。阶段性的满足了我们诉求。 存在问题请求进入到稳定环境之后调用将会在稳定环境中无法调用到动态环境的服务。导致被测服务之前的所有服务、mq的生产方都要部署到当前测试机上即使这些服务没有任何变化随着集群规模的继续扩大对资源的消耗飞速增加。
1.3 动态环境稳定环境ip路由 对于上面的问题我们期望能做成请求的流量是动态环境下优先如果没有的情况下再请求到稳定环境上这样测试机上只部署发生了变化的服务和入口服务必需就可以了。随后和架构运维一起实现了ip路由的功能就是将ip作为泳道名称向下传递。 这个方案上线后资源使用量下降30%左右。在2019年上线后的两年内转转经历了和找靓机合并芯片供应紧张导致机器长时间无法采购到在这个背景下保证了转转环境的应用。但是问题也日益的凸显。
2 环境使用中的问题 从大的方面来讲系统稳定性资源成本使用效率三个方面互相制衡。在成本包括采购困难这个限制下旧机器无法淘汰导致稳定性问题。资源不足现存的测试机使用率就降不下来稳定环境就无法保持内存30%空闲率的下限稳定性就会成问题。测试环境就需要严格的回收策略导致用户的使用体验和使用效率下降如到期回收和资源空闲回收肯定会导致部分使用中的环境被回收掉尤其是大的内存环境对应大的项目恢复起来慢影响也大。已有的架构下不能做到三者兼得或者说不能做到我们希望的妥协。具体的问题如下
2.1 资源的不足 业务的增长和集群数量的增长叠加服务器采购不到的情况机器资源很紧张。测试资源池3.8T, 高峰占用率80%。剩余资源散落在20几台物理机上导致超过40G内存的机器都是比较难申请的。
2.2 资源的浪费 在机器资源不足的情况下还存在机器资源浪费的情况现有的方案机器申请下来内存是固定的不能自动的扩容和缩容随着环境中被测服务的逐渐上线最新版本会被同步到稳定环境中动态环境和稳定环境中重复的服务会越来越多。但是无法将测试资源回收到资源池之中。
2.3 稳定性问题 机器的稳定性 众所周知测试环境的机器基本都是线上过保的机器年龄不一但是一般比较大损坏是常有的事情我们高峰期一个月损坏了5台物理机。对业务产生直接影响。 部署过程简要介绍
先简单介绍下机器启动部署过程 系统的稳定性 整个初始化部署流程7-8步各个环境都可能出现问题日常稳定性不足。 在上面3个方案的历史迭代中积累了大量的历史包袱。每次部署都要要对测试配置文件中的数据库、redis、mq、zk等配置进行替换易出错不易维护工程规范化不足。 在环境的构成中环境中每次添加删除服务都要重新计算nginx和host依赖长容易出错。 日常使用中内存不足的情况下无法自动扩容只能重新申请环境时间成本高。 Kvm资源方案生态差维护成本高。 以上这些过程中的问题每周会有25个左右环境问题反馈我们每周都需要8h左右的运维时间。为了解决上面的问题我们开发了系统错误分析工具虚拟机重启工具、机器资源报警工具、机器存活监控、稳定环境整体迁移工具等众多管理员工具帮助用户和我们解决日常问题。整体来讲日常的维护成本是很高的。用户用着有很多问题也很不爽。
3 解决方案动态环境稳定环境标签路由
3.1 解决方案 系统底层架构修改 由于以上的问题我们和架构运维重新设计了环境平台的方案。我们最终采用了docker 稳定环境的方案。ip路由变成了标签路由一个环境不再是一台机器上部署多个服务而是一个环境下多个docker组成多个ip组成如下环境yyy由服务B和D组成ip分别为192.168.5.1和192.168.6.1。 这样镜像初始化、agent初始化过程被干掉。环境的大小限制不再是一个宿主机大小决定极限情况下一个环境可以包含转转所有的服务。单个环境容量不再是问题。 通过k8s的特性部署时会新启动一个节点并且新节点启动成功之后下线旧节点。保证了服务在部署过程中服务不中断。 工程规范化
推动rd升级服务将测试配置修改为正常的配置从而下掉平台的配置替换。 nginx中心化
去掉每个环境上的nginx消灭ng部署生成过程的问题。通过系统联动使用运维的中心化nginx。 host配置
推动删除不必要的公共host在服务升级的过程中推动RPC的host调用方式升级为服务管理平台剩余公共host采用内部dns能力进行解决。 新问题
在制定新方案的过程中一个目标是解决之前的依赖问题一个就是尽量减少新方案带来的使用方式上变动减少用户使用成本。环境docker化之后最大的影响是什么呢一、ip变成了标签不再是唯一ip。
二、服务每部署一次ip变一次。
ip没了那么入口host怎么配置ip变了那么如何登录到机器上如何查看历史日志如何进行单元测试解决方案 转转之前有泛域名解析的能力,如app.zhuanzhuan.com带标签可以写为app-${tag}.zhuanzhuan.com。 请求whistle配置中 增加192.xxx.xxx.xxx app.zhuanspirit.com excludeFilter://*/api reqHeaders://(Global-Route-Tag:test1234)。注192.xxx.xxx.xxx为中心化nginx。 增加webshell 解决ip变动带来的登录成本增加。 增加历史日志查询功能解决ip销毁后历史日志查询问题。 增加本地化标签路由的功能解决单元测试每次输入ip的问题。变成标签设置。注在后面的docker推广过程中我们发现方案中我们漏掉了远程debug场景下ip变动的问题。最后通过开发了一个idea插件和环境平台联动解决。 新的运营方式 新的技术方案中资源的最小管理节点由之前的一个kvm变为标签中的一个服务。在测试服务上线之后环境平台会自动同步最新代码到稳定环境之后将测试标签中刚刚上线的服务删除回收资源。从而避免资源的浪费。 成果
部署过程缩减为服务镜像启动 ng配置同步。步骤极大的缩减。稳定性、效率提高。在宿主机挂掉的情况下k8s自动调度到新的节点。进一步保证稳定性。资源成本、稳定性和使用效率三方的制衡被打破。三方面充分的得到了提高。目前 用户问题减少95%并且大项目测试中环境问题消失了。 申请时间由28分钟到5分钟以内。 资源占用3200G到1200G。
总结
在制定了这个方案之后转转在架构、运维和工程效率三个部门互相配合情况下1个月内完成开发3个月内完成了服务升级。1年内完成了整体功能的推广。取得了丰硕的成果。 docker化之后改变了整个环境的使用生态。现在要用一个测试环境申请则立即可用。过程中不再有任何心力消耗不再有中断。并且资源管理的最小节点变为一个服务。环境系统的底层技术架构在我们看来处于业内目前的最优的方案在系统、用户层面上做到了资源性能和效率三者的整体性提升和平衡。整个系统是相对成熟的可以预见的是在未来很长一段时间内系统不需要再进行系统结构上的升级。
更多技术实现细节 关于作者 陈秋转转工程效率负责人主要负责配置管理和devops体系建设。欢迎大家留言、交流互相学习。 转转研发中心及业界小伙伴们的技术学习交流平台定期分享一线的实战经验及业界前沿的技术话题。 关注公众号「转转技术」综合性、「大转转FE」专注于FE、「转转QA」专注于QA更多干货实践欢迎交流分享~
