转载

开发过程中的第三方依赖

“聪明”的本地模拟服务

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

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

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

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

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

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

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

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

部署

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