常见微服务架构问题

本篇文章向大家介绍《常见微服务架构问题》，主要包括，具有一定的参考价值，需要的朋友可以参考一下。

我对微服务架构存在一些疑问，例如采用以下服务：

订单， 帐户， 沟通 & 管理

问题 1：根据我的阅读，我了解到每个服务都应该拥有与该服务相关的数据的所有权，因此订单将有一个订单数据库。数据所有权有多重要？如果微服务都从一个传统数据库进行调用，以便与服务相关的所有数据都存在于一个数据库中，那么微服务是否有意义？如果是这样，以这种方式构建服务是否会产生影响？

问题 2：服务应该能够相互通信。该语句与简单地卷曲现有 API 有什么不同？ ＆基于该响应的逻辑？调用服务比简单地调用 API 更高效吗？

问题3：值得吗？现在我明白这是一个巨大的普遍性，它从根本上取决于业务的需求。但当讨论结束后，重建值得吗？以及您预计将面临哪些挑战

解决方案

我会尽力回答所有问题。

1. 尊重使用同一数据库的所有服务。如果你这样做，你就会遇到两个主要问题。首先，数据库将成为瓶颈，因为所有请求都将到达同一点。其次，您将耦合所有服务，因此如果数据库出现故障或需要更新，您的所有服务都将受到影响。 （数据库会成为单点故障）

2. 服务之间的通信可以是您的服​​务需要的任何通信（同步、异步、通过消息传递（消息代理）等），这完全取决于您必须支持的用例。避免暂时解耦的推荐方法是使用像 kafka 这样的消息代理，这样做您的服务不必相互了解，并且万一其中一些出现故障，其他服务仍然可以工作。当它们再次启动时，它们可以继续处理待处理的消息。但是，如果您的服务需要以同步方式响应，您可以定义服务之间的同步通信，并使用断路器在被调用方服务关闭时正常运行。

3. 微服务架构的工作、监控和调试比传统的整体架构要复杂得多，因此，只有当您对可扩展性和可用性有非常大的要求和/或系统非常大，需要多个团队在系统的不同部分工作，建议避免它们之间的依赖关系。因此每个团队都可以按照自己的节奏部署自己的服务

理论要掌握，实操不能落！以上关于《常见微服务架构问题》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！