有赞是如何高效管理本身的开发测试环境的?

环境对于一个迭代迅速的电商公司来讲,它的重要性无须赘述了;如何让环境高效,知足多项目并发对环境的需求,节约环境机器成本,创建环境标准体系,这不是几我的的事情,而是框架组、运维组、开发、测试、PM 你们共同努力的结果,其中的过程也不是一路顺风的,有赞在这条路上走过了不少坑,今天就给你们分享下咱们的经验。 1、有赞测试环境背景历程

有赞从最先到如今一共有过 Dev(已废弃),Daily,QA,Perf,Pre 等 5 套环境,其中 Perf 环境,是专门用来作性能测试的:

2、有赞测试环境多环境实现原理

刚才咱们讲了有赞环境的历程,提到了 SC 多环境方案,想必你们关注到了,如今就开始讲下 SC 多环境的解决方案。 有赞 SC 应用隔离解决方案是由框架组提出的解决方案,产生的背景是为了解决项目并行,你们抢占资源,开发 5 分钟,联调测试 1 小时的问题。 1)全链路标识透传弱隔离方案 全链路标识透传 Service Chain,简称 SC 方案,是一种弱隔离的环境方案,简单分析下两种主要的隔离方案:

两种隔离方案优缺点分明: 强隔离:优势,隔离性强,不用修改应用,对应用侵入性低;缺点,运维成本高 弱隔离:优势,全链路标识透传,下降没必要要的运维机器成本;缺点,隔离性弱,对应用侵入性高 最终咱们选择了弱隔离,缘由是有赞业务发展形态决定的。有赞零售等垂直业务的崛起,而垂直业务依赖了绝大多数的底层应用服务,为了下降运维服务器成本,因此咱们选择了弱隔离。 框架设计这个方案最初设定了 4 个目标:
  1. 按需隔离应用,只须要隔离需求中有变动的应用前端

  2. 全链路标识透传,为之后的全链路压测打下基础node

  3. 应用侵入低,更多的由应用框架和中间件来感知和担保,应用自身作到低侵入nginx

  4. 使用方便快捷,经过平台(基础保障平台)建立隔离的 SC(Service Chain)环境浏览器

最初的全链路设计方案:

面那条线咱们称为“基础环境”链路,下面那条线咱们称为“SC 环境”链路,当标识透传到下一个服务的时候,若是没有找到对应 sc 应用节点,会默认走标准环境,若是有对应的节点,走 sc 环境的应用节点,整个过程 SC 标识从一开始的 Web 端 http 请求传入,就一直透传下去。 此外还会遇到一些重要的细节点,好比消息 NSQ 中间件,咱们也作了隔离标识透传设计方案:

好比业务代码异步调用标识透传问题,能够自行定制 Runnable 或者定制线程池再或者业务方自行定制实现。 2)Service Chain 路由 全链路标识透传,那就要求入口发起的请求,不管是哪一种业务应用或者何种协议,何种框架,都必须将源端的 SC 标识透传下去,若是其中任何一个环节标识透传失败,就没有意义了;这里主要讲下两种主要协议的标识透传: 第一种,RPC 调用。 首先应用框架层面改造,实现 RPC SC 路由,再经过 Web 发布平台将应用带有 SC 标识服务信息写入 etcd,这样 RPC 调用的时候直接经过 RPC 路由将 SC 标识进行透传,若是没有匹配到 SC 标识,默认走到基础链路服务,RPC 路由实现原理以下:

第二种,REST调用。 规定 rest 调用必须经过域名调用,规范统一的域名命名方式,好比应用 A 提供 rest 调用,这样命名:http://A.qa.xxx.com:port/。 尽可能作到命名简单统一规范,再经过 Web 发布平台将应用带有 SC 标识的 rest 服务信息写入到 etcd;接下来很重要的一步,实现 rest sc 路由,作法是部署一台专门干这个活的机器, 这里称为 sc-nginx0 机器;rest 经过域名调用都会走到 sc-nginx0,sc-nignx0 再经过 Nginx 配置作全应用名称模糊匹配,从而转发到对应的应用 rest sc 服务节点,这样就实现了 rest 调用标识透传。须要注意的是若是路由不上,会走到兜底的 sc-nginx1 机器,sc-nginx1 会路由基础链路服务。链路图以下:

这里再给你们展现下,有赞的标识透传表现形式,仅供参考:

3)Service Chain 入口 前面讲了 SC 的总体和路由,sc 标识到底是怎么传递进来的呢,那就天然要讲 SC 入口了。 有赞业务业务入口,绝大多数是在 Iron 工程,由于历史包袱这是一个至关复杂冗余的 PHP 工程。后来随着业务发展,咱们将部分业务入口从 Iron 代码剥离出来,造成一个个独立的前端是 Node 的微服务,简单分别讲下两种不一样的入口实现 SC 方式。 第一种,Iron 入口。 首先针对不一样的环境,本地须要绑定 host,域名须要接入统一网关,接着经过 Web 代理页面,给浏览器 http 访问 header 头带上 Iron 访问多人路径名 who 信息、SC 标识信息必要信息,最后在代理页面选择入口机器(ps:多人 Iron 机器),就能够开始 SC 调用之旅了;Iron 服务咱们不一样环境只有一台服务,在机器上创建多人路径名,经过 who 信息由 Tengine 走到各自的路径 Iron 代码,这样咱们就解决了 Iron 入口的问题;接下来 Iron 调其余服务,会经过 rest 请求,前面咱们有讲过 rest 调用的路由,咱们在代理页面已经将 SC 标识带入了,因此 SC 标识会接着日后面透传了。绝大多数 Iron 调用服务化服务都是经过 rest 调用的,可是 Iron 复杂在历史有些业务还经过了 rpc(nova) 调用,咱们经过改造 tether 中间件给与了 SC 标识透传支持,这里有赞特点特别鲜明就不过多介绍了;这里还有一些 PHP 比较复杂的 Nginx,Tengine 代理也不讲了,有一样背景且感兴趣的伙伴能够私下交流。 第二种,Node 入口。 Node 入口,相似于前面介绍过的 rest 调用路由,须要申请浏览器访问的外部域名,同时外部域名要确保接入统一网关;再经过 Web 发布平台将带有 SC 的外部域名 rest 信息写入到 etcd,咱们经过浏览器域名访问的时候,入口经过 Web 代理页面选择 sc-nginx 路由机器,SC 路由机器会转到对应的 sc node 服务,这样就解决了 Node 入口的问题。 最后为了下降环境使用成本,咱们入口作了统一,将测试环境老的多人 Iron 入口使用姿式也改为了 sc-nginx 入口,同时兼容了多人 Iron 的访问实现;由于有赞鲜明特点很少说了,仅供参考,链路方案以下:

4)Service Chain 出口 对于内部业务来讲,没有 SC 出口一说,这里说的出口是指外部三方的调用。三方调用支持 SC 分为两种,一种是同步查询只要对接的第三方应用支持 SC 标识就能够了;还有一种是异步回调,能够经过给三方传回调地址加入 SC 标识实现,内部应用获取回到 url 的 SC 信息,这样能够实现 SC 标识涉及第三方透传,这种方法大多数状况下三方都是能够支持的。 至此 Service Chain 环境隔离技术层面的方案差很少这样了。

3、有赞环境推进

上一个环节已经大体的介绍了有赞 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个应用,这是很大的工做量。因此环境问题显得很是必要了,有了环境问题记录,当咱们再遇到相似的问题的时候,咱们能够有经验知道怎么快速定位问题以及解决。 环境推进方面大体这些,每一个公司都会有本身的制度,主要是但愿能够给你们借鉴。 4、有赞环境与持续交付

有赞 2018 年提高研发效率,很重要的一个动做就是 DevOps,为此咱们作了 CI/CD 平台帮助咱们更高效的进行平常项目管理。环境的稳定,与持续交付的推进是紧密联系的,标准规范方便使用的稳定环境是持续交付的基础。

项目的发起从 Daily(开发)环境发起,开发完成 Daily 环境的冒烟自测以后交付到 QA 环境,测试童鞋 QA 环境完成测试以后交付到 Pre 预发环境,预发验收以后就能够发布上线,这是一个完整的项目生命周期,开发和测试环境的隔离,可使得项目进行的更加顺利。 举例说明,xx 项目是一个很是大的项目,涉及到的业务方 7,8 个,涉及的应用 60 多个,若是测试和开发童鞋都在 QA 的 SC 环境测试,那么会出现测试在测试的同时开发修复 bug 重发服务,从而打断测试的状况,这样的大项目就没有办法进行下去了。若是按照交付的思路,开发在 Daily 环境完成自测,交付 QA 测试,你们互不影响,能够很好的提高项目效率。 经过 Web 平台,目前准备一个隔离的复杂的项目环境基本上能够控制在半个小时内。咱们还有很大的提高空间,好比在 Docker 容器服务化上还能够作不少改进,和 CI/CD 结合以后,整个项目的生命周期过程实现自动化。

5、个中得失感悟

到了这里有赞环境方面的分享差很少就结束了,由于有赞的历史包袱复杂性,致使咱们的环境相对复杂,从接手环境治理到取得阶段性结果,差很少半年时间。期间处理遇到不少的环境问题,也走了很多弯路,一点一滴的经验都是宝贵的。环境问题在大多数公司都是一个头痛的问题,因此不少时候心态上须要心平气和,遇到问题你们一块儿解决也是得到成长和友谊的过程。特别感谢运维和框架的兄弟们特别多的帮助和付出,有你有赞! 本文转载自公众号: 有赞coder, 点击查看原文
相关文章
相关标签/搜索