Software design thinking
软件设计随想
Service agent (SA) 这个项目与service manager (SM) 集成经历过两种方案,一种是直接与SM的数据库进行集成交互;另外一种就是面向服务的集成,通过SM提供的SMRWS API服务进行交互集成。
我概括地称之为直接面向基准数据源的集成设计(SA->SMDB) 和面向服务的集成设计(SA->SMRWS->SMDB)。
今天遇到一个面向服务的集成设计的问题,SMRWS的主从web servers的cache数据出现同步了问题,导致SA连接SMRWS获取的信息不准确,有一个场景就是我们通过SMRWS来验证user 权限,因为获取的信息不准确导致我们误判用户不再存在于SM源系统,进而删除了用户在SA系统的权限。
作为下游系统的SA这种情况下显得格外尴尬,用户抱怨SA系统的可用性和稳定性。
反思就是:作为面向服务的下游系统,必须考虑外接服务的不稳定性,提前做好准备,进行一些异常应对, 比如当对方服务无法连接,要让本系统通过本地缓存保持"off-line" 继续工作。
当然对于上述的那个因上游系统的问题,导致本系统逻辑上的误判 (到底是用户真的不存在于上游系统背后的数据库了,还是因为上游系统出现了同步问题,这个需要和上游系统就关键逻辑场景进行标志,比如当上游系统的cache出现同步问题时候,需要在API返回结果里进行标识)。