最近,我一直在阅读有关微服务的很多文章,这是到目前为止我得出的一些结论(如果我在任何时候错了,请更正我)。
- 微服务架构与域驱动设计配合得很好。通常一个MS代表一个有界上下文。
- 如果微服务A需要驻留在微服务B中的功能,则我的模型可能是错误的,并且A和B 实际上应该是一个微服务/ BC。
- 微服务之间的同步通信(直接HTTP请求)很糟糕,导致它违背了微服务的目的,并引入了组件之间的耦合。
- 服务之间的异步通信是可取的。服务应将事件发布到消息队列,以便其他服务可以订阅和处理事件的一部分,或使用它复制上下文所需的部分数据。这样,服务可以处理请求,甚至其他服务也已关闭,而在同步通信中则不会。
- 如果微服务A发布事件,微服务B订阅该事件并产生一个新事件作为结果,则微服务A不应是一个正在处理的新创建事件,因为这将是循环依赖性。在这种情况下,我们应该引入第三种微服务,或者将A和B合并到AB微服务中。
- 微服务实际上是一个误导性术语。我们应该为小环境而努力,但这不是必须的。术语不应该是“微服务”,而是“ 足够大以进行工作服务 ”。
- 微服务使我们可以更轻松地引入新功能,而不必担心会破坏整个系统。可以通过引入新服务或重构现有服务之一来完成。
- 每个微服务都应具有自己的数据存储。数据复制/复制是此体系结构中的理想行为。
除了证实我对这种体系结构的理解之外,问题的其他部分主要与服务发现有关。如果服务异步通信,并使用亚马逊SQS之类的中央事件队列,这是否意味着服务发现在这样的体系结构中没有位置?
服务不应对系统中的其他服务有任何了解。他们只知道应该发布或订阅的上下文和事件吗?