有赞从最早到现在一共有过 Dev(已废弃),Daily,QA,Perf,Pre 等 5 套环境,其中 Perf 环境,是专门用来做性能测试的:
二、有赞测试环境多环境实现原理
刚才我们讲了有赞环境的历程,提到了 SC 多环境方案,想必大家关注到了,现在就开始讲下 SC 多环境的解决方案。 有赞 SC 应用隔离解决方案是由框架组提出的解决方案,产生的背景是为了解决项目并行,大家抢占资源,开发 5 分钟,联调测试 1 小时的问题。 1)全链路标识透传弱隔离方案 全链路标识透传 Service Chain,简称 SC 方案,是一种弱隔离的环境方案,简单分析下两种主要的隔离方案: 两种隔离方案优缺点分明: 强隔离:优点,隔离性强,不用修改应用,对应用侵入性低;缺点,运维成本高 弱隔离:优点,全链路标识透传,降低不必要的运维机器成本;缺点,隔离性弱,对应用侵入性高 最终我们选择了弱隔离,原因是有赞业务发展形态决定的。有赞零售等垂直业务的崛起,而垂直业务依赖了绝大多数的底层应用服务,为了降低运维服务器成本,所以我们选择了弱隔离。 框架设计这个方案最初设定了 4 个目标:
-
按需隔离应用,只需要隔离需求中有变更的应用
-
全链路标识透传,为以后的全链路压测打下基础
-
应用侵入低,更多的由应用框架和中间件来感知和担保,应用自身做到低侵入
-
使用方便快捷,通过平台(基础保障平台)创建隔离的 SC(Service Chain)环境
三、有赞环境推动
上一个环节已经大致的介绍了有赞 Service Chain 全链路标识透传隔离方案的技术实现,这个环节开始介绍我们在确定技术实现方案之后,做的一些列推动的措施。 1)推动应用框架升级接入SC 前面我们说了 RPC 调用是通过框架实现 sc 路由的,所以推动应用框架、NSQ 客户端升级,这一步非常重要;因为很多业务链路很长,如果某些业务线没有升级,整个 SC 链路就会卡在某个应用没法透传标识;这点在一开始的时候,我们没有做好,因为前期的宣传力度不够,推动不足,导致有些业务线接入 SC 升级比较快,有些业务线相当滞后,项目试点之后才发现还不支持 SC,给后面的试点带来了很大的阻力和困难;所以建议,如果一旦确定好适合自己的隔离方案之后,开始推动的时候,做好充分的准备,定好时间,并指定各业务线的跟进 owner。 2)推动应用接入配置平台 因为经常会发现某个应用因为环境依赖的基础服务配置不对,导致应用的测试环境服务各种问题,排查的时候要去 code 里看配置,非常的耗时与不便;所以为了方便管理应用环境配置,我们做了应用配置平台,推动应用平台配置化,把一些基础的配置模板固化,这样我们环境配置的问题基本就能解决了。 3)推动基础环境整治 这一步非常核心,因为只有基础环境稳定,大的测试环境才会稳定。核心是维护基础环境服务,下掉多余的基础环境机器(ps:服务不带标识信息的机器)及服务,基础环境的应用服务只保留一个,这样保证了我们基础环境服务链路简单清晰,方便了问题定位,也方便控制基础环境发布权限。还可以从以下几点考虑来治理基础环境:1,测试环境基础链路服务发布权限管控,只允许发布 master 代码,不允许轻易发布,保证基础链路服务稳定;2,基础链路服务当天生产环境有代码变更,凌晨自动更新 master 代码等。 4)Web 应用发布管理平台 前面有说过,SC 应用服务信息写入 etcd,是通过 Web 发布平台,所以我们需要一个方便便捷的 SC 环境应用发布管理平台。 创建 SC 环境: SC 环境应用管理: 这里值得一提的是,SC 服务的机器可以申请虚拟机,也可以用 Docker,从成本而言,我们默认是使用更加节约成本的 Docker。 5)推动项目试点 在准备工作做好之后,可以选试点项目试行了,因为环境方案问题的复杂性,建议不要一开始就推行全公司,可以找一些项目先做试点;在试点的过程中,我们会发现各种明显坑,等把这些明显的坑解决一圈之后,再推全公司实行。 6)共性问题解决方案跟进 共性问题有哪些,比如有提到过的测试环境调用第三方支持 SC、卡门支持 SC 等等,在环境使用的过程中,会遇到大家都会遇到的问题,这类问题影响是大范围的,那就必须拉群及时跟进响应解决,如果不能及时解决就会降低大家使用推动环境优化的积极性;处理完问题,需要及时总结记录,大的问题还要及时通知,以及在培训过程中给大家举例讲解;有赞在环境推动的过程中,我们大大小小的建了 40 多个问题跟进的群,制定了 10 多个共性问题解决方法,这些方案有着很鲜明的我厂特色,这里就不给大家分享了。 7)环境基础保障 测试环境使用的便捷稳定,必然会要求我们做一些环境基础保障的工作,比如开发测试环境数据 mock 平台、服务监控平台。 环境数据 mock 平台---测试团队目前开发覆盖了包括大数据,交易,支付等 14 块业务 mock 场景,大大提升了测试环境的高效便捷;比如测试环境有些特殊的场景是需要数据构造的,店铺没钱了,e卡支付账号没钱了,添加店铺管理员等,都可以通过测试平台自己实现。 基础环境服务监控平台---测试环境基础环境链路的服务稳定直接影响了环境的稳定性,如果基础环境服务异常,会影响到所有人测试环境使用,为此开发了环境服务监控平台,覆盖了 Daily、QA、Pre 90% 以上的核心应用的服务;每隔 10 分钟监测一次 etcd 应用的 Dubbo 服务,一但发现某环境服务异常,就会给应用的测试角色发送邮件告警、以及内部工具告警,测试童鞋收到服务异常告警,及时处理,避免测试环境服务长时间影响大家使用。 服务异常告警: 环境监控平台非常重要,我做过统计,环境问题至少降低 70% 以上,提升环境排查解决效率至少 80%,很多时候服务异常了我们第一时间就解决了,避免了大家感知,还有其他的一些环境保障的工具这里就不多说了。 8)环境方案规范制定 对于环境使用者来说,很多时候他可能不需要详细了解环境隔离方案的实现,更多时候比较关心环境究竟怎么使用。所以在方案之后,我们需要制定环境使用规范,有赞针对入口变化,前后制定过两个版本的使用规范 ppt,大致的内容如下:有赞环境介绍,应用接入 SC 规范,环境使用规范,测试环境交付规范,移动端使用规范,环境保障,环境发布权限规则,很多内容在前面也都讲过了。 9)环境培训 有了环境方案规范之后,对于一个已超过 600 技术人员的公司来说,还需要通过一系列的环境培训,这样才能确保每个人都知道如何做如何使用。在有赞是通过各业务线组一个个宣讲进行的,还有新人入职技术大学培训,前后组织了接近 20 场培训,除此之外还反复强调老人要帮扶指导新来的童鞋环境的使用,通过这些努力才能保证绝大多数人知道怎么使用环境。 10)环境故障定级 在我们做了大量的培训、宣导之后,还是会有童鞋将测试环境基础环境服务弄出问题,这是很难避免的,毕竟使用的人多,大家对环境的学习理解程度又不一样。对于这种情况就需要制定惩罚措施了,给环境故障定级,分为 p1(影响阻塞基础环境主链路的故障),p2(影响非主链路或者非基础环境的故障),对于故障多的业务组,予以通报tl。 11)环境问题记录 环境的问题各式各样,多而繁杂,需要组织专门的老司机,负责排查环境问题,尤其在当下微服务越来越细化的背景下,一个环境问题出现了,需要查好几个业务线N个应用,这是很大的工作量。所以环境问题显得非常必要了,有了环境问题记录,当我们再遇到类似的问题的时候,我们可以有经验知道怎么快速定位问题以及解决。 环境推动方面大致这些,每个公司都会有自己的制度,主要是希望可以给大家借鉴。 四、有赞环境与持续交付
有赞 2018 年提升研发效率,很重要的一个动作就是 DevOps,为此我们做了 CI/CD 平台帮助我们更高效的进行日常项目管理。环境的稳定,与持续交付的推动是紧密联系的,标准规范方便使用的稳定环境是持续交付的基础。 项目的发起从 Daily(开发)环境发起,开发完成 Daily 环境的冒烟自测之后交付到 QA 环境,测试童鞋 QA 环境完成测试之后交付到 Pre 预发环境,预发验收之后就可以发布上线,这是一个完整的项目生命周期,开发和测试环境的隔离,可以使得项目进行的更加顺利。 举例说明,xx 项目是一个非常大的项目,涉及到的业务方 7,8 个,涉及的应用 60 多个,如果测试和开发童鞋都在 QA 的 SC 环境测试,那么会出现测试在测试的同时开发修复 bug 重发服务,从而打断测试的情况,这样的大项目就没有办法进行下去了。如果按照交付的思路,开发在 Daily 环境完成自测,交付 QA 测试,大家互不影响,可以很好的提升项目效率。 通过 Web 平台,目前准备一个隔离的复杂的项目环境基本上可以控制在半个小时内。我们还有很大的提升空间,比如在 Docker 容器服务化上还可以做很多改进,和 CI/CD 结合之后,整个项目的生命周期过程实现自动化。
五、个中得失感悟
到了这里有赞环境方面的分享差不多就结束了,因为有赞的历史包袱复杂性,导致我们的环境相对复杂,从接手环境治理到取得阶段性结果,差不多半年时间。期间处理遇到很多的环境问题,也走了不少弯路,一点一滴的经验都是宝贵的。环境问题在大多数公司都是一个头痛的问题,所以很多时候心态上需要心平气和,遇到问题大家一起解决也是获得成长和友谊的过程。特别感谢运维和框架的兄弟们特别多的帮助和付出,有你有赞! 本文转载自公众号: 有赞coder,点击查看原文。