微服务、依赖项和事件
关于管理微服务之间的依赖关系，我已经做了大量的谷歌搜索。我们正试图从大型的单一应用程序转移到微服务，以便在组织上进行扩展，并能够更快地开发，并有多个团队并行工作。然而，当我们试图从功能上将整体划分为微服务时，我们看到了业务逻辑和数据实际上是如何交织在一起的。当我们坐在一个大型数据库之上，并且能够进行大型关系连接时，这不是问题。但对于微服务，这就成了一个问题。
一种解决方案是使微服务-A转到5-10个其他微服务以获取必要的数据(这相当于DB view with join)。另一种解决方案是让微服务-A监听来自5-10个其他服务的事件，并将相关内容填充到本地存储中(这相当于物化视图)。无论哪种方式，微服务-A与5-10个其他服务耦合，并且如果在微服务-A中需要新的信息，则它所依赖的一些服务可能需要在微服务-A之前被释放。请注意，微服务-A本身依赖于其他服务。归根结底，我们最终会得到分布式依赖地狱。
许多文章提倡第二种解决方案-即类似于事件采购、编排等的解决方案。
如果有任何分享的经验、建议和见解，我将非常感激。
菲罗梅托。
回答 1
Stack Overflow用户
发布于 2017-07-08 00:27:29
虽然从技术上讲不是一个“答案”，但我绝对可以分享一些我的观察和经验。您提出的关于服务调用其他服务进行数据库操作的问题让我想起了一个项目，其中一位架构师向高级管理人员推销了一种想法，即通过在一个非常大的企业数据库前实现数百个rest接口(本质上是分布式DAO模式)，将持久性与其他应用程序“分离”。这个项目的结果完全符合我的预测--一个惨淡的失败。
微服务并不是将单片应用程序转变为分布式单片应用程序。在我上面的示例项目中，巨石变成了一个炉子管道，脆弱，混乱的混乱，耦合只移动到服务合同，而不是Java类方法签名，并且由于性能受到如此糟糕的影响，应用程序无法使用。上一次我听说他们还在运行他们原来的巨石。
微服务应该更多地是应用程序的垂直分区，而不是水平分区。在我看来，最好从业务功能分区的角度来考虑，而不是“转换”现有的整体。没有规则来确定微服务必须有多大，但它应该足够大，以完成一个完整的同步功能，而不需要直接依赖(尽可能多地)外部服务来完成其工作。如果一个微服务执行一个影响50个表的复杂业务功能，那就这样吧！它拥有那么多表。理想情况下，如果服务宕机，它应该只影响它所负责业务功能，而不会直接影响其他服务。正如您所看到的，这种想法与在我的项目示例中产生分布式混乱的想法完全相反。
您不仅需要确保用微服务替换巨石背后的动机是合理的，而且您还需要走出巨石，重新审视实际的业务，并开始进行分区。像其他任何事情一样，小步走是可行的。从一个小的、完整的业务功能开始，并将其转换为单个微服务，而不是试图一次替换所有的巨石。
https://stackoverflow.com/questions/44949367
复制相似问题
腾讯云开发者
