然而,当我们试图从功能上将整体划分为微服务时,我们看到了业务逻辑和数据实际上是如何交织在一起的。当我们坐在一个大型数据库之上,并且能够进行大型关系连接时,这不是问题。但对于微服务,这就成了一个问题。一种解决方案是使微服务-A转到5-10个其他微服务以获取必要的数据(这相当于DB view with join)。另一种解决方案是让微服务-A监听来自5-10个其他服务的事件,并将相关内容填充到本地存储中(这相当于物化视图)。无论哪种方式,微服务-A与5-10个其他服务耦合,并且如果在微服务-A中需要新的信息,
to the databaseActivityA的读取任务非常小(参考读取所需的时间),但是服务对数据库的写入非常长(,有时需要5-10分钟的)。现在,当服务运行时,我单击通知,必须从数据库读取的ActivityA无法执行其读取,因为已经有一个服务正在写入该数据库。
因此,activityA必须等待(5-10分钟)才能从数据库读取。那么,如何使该方法在api 10中工作,或者是否有其他方式可以