0
0
此设计方案虽因为微服务间直接的远程调用, 而不存在著各微服务间数据库藕合的问题, 但是, 也存在著其它需注意的地方:
当 customer information 微服务, 删去了自身数据库中的 Customer ID: ABC001 的数据后, customer information 微服务便必需要知道, 它需远程调用哪些的微服务? 假如, customer information 微服务少调用了一个微服务, 则将使得整体微服务的数据, 很难再维持一致性; 因为, 这样的缺陷, 有时在数百, 甚至是数千个的微服务当中, 是相当不容易被定位到的。
customer wish list 微服务与 customer preference 微服务都有著重复的代码, 处理著自身数据库上相同的事务。
customer wish list 微服务与 customer preference 微服务, 将必需要负责处理自身数据库上的事务; 如：回退、确认是否有回传数据库处理确认的信息给 customer information 微服务…等等。这将增加 customer wish list 微服务与customer preference 微服务在开发与测试上的复杂度。
当 customer information 微服务同步调用 customer wish list 微服务与 customer preference 微服务时, customer information 微服务将必需等待 customer wish list 微服务与 customer preference 微服务回传数据库处理确认的信息, 才能向其外部的使用者介面确认 Customer ID: ABC001 的数据已被成功的删除。而这将使得 customer information 微服务的外部使用者介面必需花费时间等待; 在性能上可能会产生不好的使用者体验。
