开发过程中的第三方依赖

“聪明”的本地模拟服务

现在,越来越多的应用都开始面向服务架构,这意味这更好的重用性;一个设计良好的服务,不仅可以被网站使用,也可以被各种移动应用使用。但是世界上没有免费的午餐,在网站的开发过程中,如果依赖于第三方服务,很可能存在这样的问题:另一个团队正在开发这些第三方服务,他们也在不断的部署这些服务,服务经常不可达。

这会导致两个问题,首先功能测试失败,build失败,代码无法提交;其次,很多前端的功能需要依赖数据,这些服务不可达,就意味着没有数据,那么前端的功能开发也被阻塞了。

这种情况下,一般的做法是在项目中构建一些假的服务(以下统称本地模拟服务),直接返回静态的数据,稳定可靠;

然后,所有的测试都依赖于本地模拟服务, 不稳定的第三方服务就被隔绝了,程序员们就可以无忧无虑的提交代码,但好景不长,随着时间的推移,新的问题又来了。

前面我们已经假定,第三方服务也在开发中,在不断的变化中,一段时间后,那些本地模拟服务返回的数据已经失效。无奈地程序员们手动的更新了本地的静态数据,没过多久随着第三方服务的变更,这些静态数据有失效了。

写到这里,大家肯定在想,如果本地的静态数据能能够随着第三方服务的变更而更新,就不会向上面那样痛苦了,也就是说,我们需要的不是简单的静态数据,而是一种更加“聪明”本地模拟服务,它能够:

  1. 在第三方服务失效的时,返回本地静态数据。
  2. 如果第三方服务可用,它就变成代理,负责转发请求和响应;然后更新本地的静态数据。

这样“聪明”的本地模拟服务,不仅能够有效的隔离真实服务的不稳定,还能够依据这些不断变化的第三方服务,自动的更新本地静态数据。

部署

使用了这样的“聪明”的本地模拟服务,貌似一切都完美了。它完美的隔离了第三方服务,但是,有个新的问题来了,怎么知道第三方服务真的不可达了,很多情况下,我们需要及时的得知第三方服务的状态,以便于尽快的通知其他团队来修复这些问题。在我们的项目里,我们专门这对这些第三方服务创建了集成测试,这些继承测试在build阶段不跑,而是在build跑完以后触发,这样一旦功能测试过了,也就是build是好的,但是集成测试失败了,我们就能立即得出结论,第三方服务不可达了,关于部署和pipeline,将在接下来的文章中描述,这里先挖个坑:)。

实现

事实上,早就有 VCR ,能够用来缓存http请求和应答,以key-value的方式存储,key是request.

受VCR的影响,在java的世界里,有 Betamax, 通过annotation的方式来缓存http交互。基于Betamax,我们只需要少量的代码,就实现了上面的“聪明”的本地模拟服务。

本站部分文章源于互联网,本着传播知识、有益学习和研究的目的进行的转载,为网友免费提供。如有著作权人或出版方提出异议,本站将立即删除。如果您对文章转载有任何疑问请告之我们,以便我们及时纠正。

PS:推荐一个微信公众号: askHarries 或者qq群:474807195,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

转载请注明原文出处:Harries Blog™ » 开发过程中的第三方依赖

赞 (0)
分享到:更多 ()

评论 0

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址