[架构模式实践]如何不让第三方服务/组件的故障阻碍开发和测试进度

今天起床后发现阳光明媚. 平日里钻在暗无天日的办公室里, 是没有机会体会到这冬日正午的暖阳, 是多么的让人流连.

靠在床头, 伸了个懒腰, 慵懒地捧起了一直无暇去读的企业应用架构模式. 那一刻, 阳光照在书本上, 虽然有些晃眼, 但是不妨碍一种细小的满足感默默诞生.

前日和一名同事闲聊, 提到了一段时间来一起参与的一个项目, 这个项目的一个特点是用到了数量较多形式各异的第三方接口, 算是"传说中的"企业级应用吧:) 在前面的一轮测试过程中, 由于其中一些接口的测试环境频频当机或服务中断, 导致测试和修改bug的过程都耽搁了不少时间, 于是同事提议, 做一些这些接口的替代品, 来在开发和测试的某些阶段, 取代对第三方接口的测试环境的依赖.

因为这次谈话还未从大脑中完全溜走, 于是我琢磨着在书中找一些相关的内容. 先是找到了Chapter 18 Base Patterns, 第一节Gateway, 即是讲, 对待一些第三方服务和资源, 应该以Gateway 模式将其封装. 书中举了将向消息队列中发送具体的业务消息的例子, 旨在阐明Gateway 模式带来了简化调用, 明确调用的好处.

所谓简化调用, 因为服务/资源的使用者无需关心原始API的细节, 一律以一种统一的, 够用为原则的API来访问一类服务/资源, 如XML, 如关系数据库, 以及各种消息中间件, 等等.

所谓明确调用, 以发送消息到消息队列为例, 一般消息队列中间件的API, 为了提供通用性, 通常接口足够抽象, 接口本身不包含任何特定的业务含义和指示. 但对于调用发送消息API的使用者, 一个具备明确示意的方法名, 一些类型化, 数量明确的方法参数, 进而在方法中针对传入参数做范围检查的方法, 确实提供了一种更好的编程体验, 既有利于在开发阶段快速选择适合的方法, 也有利于进行单元测试, 一如示例中提及的 sendConfirmation(id, amount, symbol).

因为Gateway模式将服务/资源的提供方和使用方进行了解耦, 因此可用于在开发/测试的某些阶段, 绕开对第三方接口测试环境的依赖. 为了实现此目的, 同样出现在Chapter 18中的 Service Stub模式, 有了用武之地.

在下周的工作中, 我会花一些时间, 将目前系统中使用的第三方接口进行分类, 为不同类型的接口寻找适合的Stub方式. 因此进一步关于Service Stub模式的介绍, 我希望在经过自己一些实践之后, 能总结出多一点价值的东西, 再来成文.