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返回结果里进行标识)。

软件设计随想-上下游系统集成问题