微服务不适合业务领域？

作者: 小鬼
发布时间: 2025-03-04 05:00:49 (19小时前)
转自：

3 条回复

0#
回复此人
一瓶泡沫 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 首先，上述答案是正确的，建议您需要以更好的方式对您的微服务进行调整。 现在如果可扩展性是您的关注点（微服务之间的许多api调用）。 我强烈建议您验证在第一级确实需要多少约束，以及您可以以异步方式执行多少约束。我的意思是在分布式环境中我们实际上不需要同时验证所有的东西。 有时这些东西不是直接可见的，例如：假设有两个服务订单服务，客户服务和订单服务公开一个api，即为客户ID下订单。而且业务人员说你不能为不知名的顾客下订单 一个实现来自您同时调用客户服务的订单服务----在这种情况下，客户服务停止将影响您的服务，现在让我们确实需要问题。 因为客户只是下订单并且有人从客户服务中删除了该客户，所以我们有一个不属于客户的订单。不能保证一致性。 在新的溶胶。我们说允许订单服务下订单而不检查客户ID并执行以下操作之一： 使用ProcessManager检查客户有效性并将订单状态更新为无效，并在使用ProcessManager删除客户时将订单状态更新为无效或执行业务逻辑根本不检查，因为下订单不算数，当这个订单将在发货过程中，服务无论如何都会检查客户状态 通过这种方式，您的API命中率会降低，并且会产生更好的独立服务 </DIV>

编辑
1#
回复此人
至此 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”> 首先，您不必拥有微服务架构。我真心的！如果你是 有序 由管理层/建筑师来做，它并没有解决你遇到的任何实际问题，你可能正好回击。 话虽如此，并且免责声明我不知道您的申请的确切要求，的 把“事物”当作有限的背景是一种气味 </强> 。因此，将“客户”，“应用程序”，“文档”等作为服务很可能是错误的方法。 有界上下文不应该是特定实体的CRUD操作。它们应该完全独立（或尽可能独立）整个应用程序的“垂直”部分。最好有自己的数据库 和 GUI。它们也应该相互独立地运作，不需要其他服务的输入来做出自己的决定。 它与以数据为中心的设计完全相反，其中表/字段和关系是核心概念。在这里，功能是核心概念。您必须按功能拆分应用程序才能实现良好的分离。 我可以想象一个文档管理系统具有这些独立的有界上下文/服务： 搜索 ， 工作流程 ， 编辑 等 以下是您将如何思考它： 搜索 不需要任何其他服务的任何（同步）输入。它可以使用新文档接收定期甚至近期更新，但这不会影响它的主要功能：搜索已编入索引的文档。 GUI也是独立的，类似于一个像搜索框一样的谷歌页面。它可以独立地提供结果，并且可以 链接 回到了 工作流程 要么 编辑 单击结果时的应用程序。 其他人同样是独立的。同样，重点是以一种使它们独立工作的方式拆分服务。如果你没有这个，你只会让微服务变得更糟。 </DIV>

编辑

登录后才能参与评论