微服务是否应该可重用？
微丝网应该可重复使用吗？对于可重用，我并不意味着共享特定于域的模型。
我的意思是，为一个应用程序创建的微服务是否应该在另一个应用程序中重用？如果它们可以在应用程序中重用，是否足够？
分离微服务的最佳方法是什么。从我的观点来看，一旦一个微服务调用另一微服务，它就会紧密耦合，这意味着它不容易（无需修改）被提取并放入另一个没有它所引用/来自的相同服务的微服务应用程序中。
在我看来，要使它们脱钩，有以下几种方法:
-
< li >微服务A需要通过标准合约(例如特定协议)与另一个微服务B通信。 < li >另一个微服务C充当网关，向微服务B请求数据，并将其作为输入传递给微服务a。
第2项的一个具体例子是：
耦合:
客户端-
解耦：
客户-
假设这一切都归结于微服务的目标，我说得对吗？没有对错？
我还缺少其他策略来解耦微服务吗？
共有2个答案
这完全取决于你在构建什么样的微服务。对于ex；假设您正在构建一个电子邮件通知服务。可以被不同的应用程序重用。另一个例子说你正在建立一个推荐系统。它对于单个应用程序来说非常具体。将它设计成可以在不同的应用程序中重用是没有意义的。
根据上下文选择。没有正确的方法。这完全取决于应用程序。
我认为你可能得到的回答更多的是观点，而不是答案，但是我会继续给出我的答案！
微服务的文献早就说过，“解耦，解耦，解耦”，但坦率地说，我不认为这是现实。当有人创建了一个有用的 API 来增强您自己的功能（身份验证、支付，显然还有数据库）时，建议这些需要与您的功能一起运行是错误的吗？大多数人不会为了通过 Stripe 付款或通过 Twilio 发送短信而通过复杂的、充满逻辑的网关，那么为什么私有托管的 API 会有所不同呢？
将自己的服务设计成一个可重用、易于使用/部署的组件是很棒的。这不应该意味着它不能有依赖项，而是我们应该注意这些依赖项带来的膨胀。这种正念是开发人员在引入依赖项时应该练习的，无论它们是应用程序包还是依赖服务/API。
* *披露:我构建并运行了一个框架/平台Architect.io，以帮助云原生团队协作并构建彼此的服务。我亲眼目睹了像脸书这样的公司如何使用类似的策略来实现服务重用和消费，并希望为公众构建一个微服务依赖解决方案。
-
假设我们有两个微服务和,如果我们的用户想上传一个头像。请求应该由网关直接路由到还是？从cohesion的角度来看，所有其他信息都是由服务处理的，处理上传请求并将请求转发到更有意义。从性能的角度来看，这完全是对带宽和CPU的浪费。
-
问题内容： 我正在编写一个将异步检索数据的服务（$ http或$ resource）。我可以通过返回一个最初为空但最终将填充的数组来隐藏它是异步的事实： 或者我可以通过返回一个承诺来暴露异步性： （Plunker-如果有人想尝试上述两种实现。） 暴露异步性的一个潜在优势是，我可以通过向方法中添加错误处理程序来处理控制器中的错误。但是，我很可能会在应用程序范围的拦截器中捕获并处理$ http错误。
-
AccessibilityService在系统的内存管理方面与普通服务有何不同？ 我想问的是：系统可以为了节省内存而关闭AccessibilityService吗？如果可以，当您进入AccessibilityService时，您会看到它打开还是关闭？用户是否必须再次手动打开？ 使用startForeground是否有助于使AccessibilityService保持活动状态？ 在一个类似的问题中，
-
给定我有两个微服务：服务A和服务B。 服务A拥有完整的客户数据，服务B需要该数据的一小部分（例如，它通过一些批量加载从服务A获得）。 这两种服务都将客户存储在自己的数据库中。 如果服务B随后需要与服务A交互，例如获取额外数据（例如get/customers/{id}），那么它显然需要在两个服务之间共享的唯一标识符。 由于ID是GUID，我可以在服务B中创建记录时简单地使用服务A中的PK。因此两个P
-
问题内容： REST API-是否有DTO？ 我想在微服务的背景下再次提出这个问题。这是原始问题的报价。 我目前正在为一个项目创建REST- API，并且一直在阅读有关最佳实践的文章。许多人似乎反对DTO，只是公开域模型，而其他人似乎认为DTO（或用户模型或任何您想称呼的东西）是不好的做法。我个人认为这篇文章很有道理。 但是，我还了解了所有其他映射代码，域模型与其DTO对应对象100％相同的DTO
-
Spring Boot 2.3.0.Release（带有启动程序:Data、JPA、web、mysql) 轴突Spring启动器-4.2.1 每个服务在mysql服务器中使用不同的模式。 当我在激活axon框架的情况下启动spring boot服务时，在每个应用程序的数据库模式中创建了一些令牌、SAGA等表。