Events 微服务、依赖关系和事件

我在谷歌上搜索了很多关于管理微服务之间依赖关系的信息。我们正试图从大型单一应用程序转向微型服务，以便在组织上进行扩展，并能够更快地开发多个团队并行工作的应用程序。 然而，当我们试图从功能上将整体划分为微服务时，我们看到了业务逻辑和数据是多么的相互交织。当我们坐在一个大数据库上，能够进行大型关系连接时，这不是问题。但对于微服务，这就成了一个问题

一种解决方案是让microservice—转到5-10个其他microservice以获取必要的数据（这相当于使用join的DB视图）。另一个解决方案是使microservice-A侦听来自5-10个其他服务的事件，并使用相关的into填充本地存储（这相当于物化视图）。无论哪种方式，microservice-A都与5-10个其他服务相结合，如果microservice-A中需要新的信息，则它所依赖的某些服务可能需要在microservice-A之前发布。请注意，microservice-A本身由其他服务所依赖。归根结底，我们最终会遇到分布式依赖地狱

许多文章主张采用第二种解决方案，即事件来源、编排等

我希望大家能分享我的经验、建议和见解

尽管从技术上讲这不是一个“答案”，但我可以肯定地分享我的一些观察和经验。您关于为数据库操作调用其他服务的问题让我想起了一个项目，在该项目中，一位架构师向高级管理层推销了“解耦”的思想通过在一个非常大的企业数据库前面的分布式DAO模式中实现数百个rest接口，从其余的应用程序中获得持久性。这个项目的结局和我预测的一模一样——惨败

微服务并不是将单片应用程序转变为分布式单片应用程序。在我上面的示例项目中，monolith变成了一个炉管式的、脆弱的、混乱的烂摊子，耦合只转移到服务契约而不是Java类方法签名，并且由于性能下降，应用程序无法使用。上次我听说他们还在运行他们原来的巨石

微服务应该更多地是应用程序的垂直分区，而不是水平分区。在我看来，最好从业务功能划分的角度考虑，而不是“转换”现有的整体。没有规则决定微服务必须有多大，但它应该足够大，可以完成一个完整的同步功能，而不需要直接依赖外部服务（尽可能多地）来完成其工作。如果一个微服务执行一个影响50个表的复杂业务功能，那就这样吧！它有那么多桌子。理想情况下，如果一个服务宕机，它应该只影响它负责的业务功能，而不直接影响其他服务。如您所见，这种想法与我的项目示例中产生分布式混乱的想法完全相反

---

您不仅需要确保用微服务替换巨石背后的动机是合理的，而且还需要走出巨石，重新审视实际业务，并开始对其进行分区。像其他事情一样，婴儿步是一条路要走。从一个完整的小型业务功能开始，并将其转换为一个单一的微服务，而不是试图一次替换一个整体。

感谢您提供的详细解释和相关经验。在我的情况下，上层管理层已经在出售脱钩的大巨石的想法。微服务被认为是解决缓慢发布周期、缺乏业务敏捷性等问题的解决方案。就微服务之间的依赖性而言，我们不仅考虑解耦持久性，还考虑将相关业务规则封装在单独的微服务中。以电子商务为例：订单、目录、用户、，支付不仅仅是DB表上的薄表面，而是封装了处理这些数据的业务规则，同时，它们相互依赖——这就是我担心的依赖性。不，我不认为它们相互依赖。“创建客户”如何依赖于“检索客户订单历史记录”或“处理付款”或“搜索产品目录”？当然，您需要知道您正在为哪个客户处理付款，但在输入该用例之前，您需要知道这些信息。您需要抛弃关系受限的巨型企业单一数据库的整个概念。我不会愚弄你，这样做会使你失去一些便利，但你会获得灵活性和孤立性。这是一种权衡。