问题描述
对于整个微服务浪潮来说，我还是一个新手.我一直在研究良好的微服务环境背后的体系结构和原理.
I'm fairly new to the whole micro-services bandwagon. I have been doing some research into the architecture and principles behind a good micro-services environment.
定义微服务的主要内容之一应该是每个服务的松散耦合性质. 微服务A 绝对不要直接调用微服务B ，否则您实际上是在创建一个单片系统，从而失去了架构模式所提供的可伸缩性.
One of the main things that defines a micro-service is supposed to be the loosely coupled nature of each service. Micro Service A should never call Micro Service B directly, or you're effectively creating a monolithic system that looses the scalability offered by the architecture pattern.
问题/示例
如果我开发了一个返回GUID的微服务(例如)，则可以合理地建议环境中的其他微服务可以在需要时直接调用GUID服务.
If I develop a micro-service that returns a GUID (for example), it's reasonable to suggest that other micro-services in the environment might call the GUID service directly when one is required.
我知道可以使用多种排队系统将数据从一项服务传递到另一项服务，但是在我看来，它们主要用于插入，删除或更新.
I understand that a variety of queuing systems can be used to pass data from one service to the next, but in my mind they're for inserting, deleting or updating primarily.
我不知道如何将队列用于简单读取(例如我的GUID示例)，以及为什么您不只是直接从另一个微服务调用GUID服务.
I can't get my head round how a queue would be used for a simple read (like my GUID example) and why you wouldn't just call the GUID service directly from another micro-service.
注意:返回GUID只是一个例子，我知道大多数语言都可以在内部生成它们
对此有些澄清，将不胜感激.
Some clarity on this would be much appreciated.
推荐答案
您不应遵循所有规则.
此规则有很多例外，许多系统的实践证明它不适用于每种情况或系统.
There are many exceptions to this rule and the practices of lot of systems has proven it not to be correct for every case or system.
我不同意这种限制，即微服务A绝不应该将微服务B称为一般规则，因为它不适用于所有情况.我已经使用了多个系统微服务，而我们不遵循这一点.
I disagree with this restriction that micro-service A should never call micro-service B as a general rule as it does not apply to all cases. I have worked with multiple systems usingmicro-services and we where not following that.
微服务之间的通信:
您可以使用多种方式在微服务之间进行通信，例如:
You can use multiple ways to communicate between micro-services like:
-
事件(使用队列)
Events (using queue)
命令-通过API直接调用另一个微服务(这是对微服务的某种指令)需要进行更改(创建，更新，删除).
Commands - direct call over API to another micro-service (which is some kind of instruction to the micro-service) whichrequires a change to happen(Create, Update, Delete).
查询-通过API直接调用另一个微服务(例如获取GUID的示例).再次有人会说这也是一个司令部.当您同时使用 CQRS 时，通常会结合使用查询作为术语.
Queries - direct call over API to another micro-service (like your example of getting GUID).Again some people will say that this is a Command as well.Using Query as term is often combined while you use CQRS as well.
共享Db(大多数在线资源会告诉您不要这样做由于多种原因)通常，不建议使用此方法.
Shared Db's (most of the online resources will tell you not to do thisfor multiple reasons)In general this is not recommended approach.
一般
您应该根据自己的需求来使用系统，而不是基于固定的规则，例如微服务A绝不能呼叫微服务B".
You should work with your system based on your needs and not based on set in stone rules like"Micro Service A should never call Micro Service B".
我将举例说明为什么:
示例:
假设您拥有微服务A"和微服务B".您的微服务B"正在使用微服务A"通过Kafka发布的事件.消费事件时，微服务B"正在其自己的数据库中存储一些相关的外部"数据(复制该数据).这是一种常见的方法，它在每次需要一些数据时都不调用微服务A".例如，这很常见如果微服务A"是某些具有系统配置设置或类似设置的服务.
Lets say you have "micro-service A" and "micro-service B". Your "micro-service B" is consuming events which "micro-service A" publishes through Kafka. "Micro-service B" when consuming the events is storing some relevant "External" data in its own database(duplicating it).This is common approach not to call the "micro-service A" each time you need some of its data. This is common for exampleif "micro-service A" is some service having the system configuration settings or similar.
让我们说您有灾难的场景，其中数据库和微服务B"中的所有数据都被破坏或损坏.为了解决该问题，您可以只还原备份并应用从最近1小时开始的应用最新事件，其中您的微服务B"已关闭并解决了问题(如果将事件处理实现为幂等).在这种情况下，一切都很好.
Lets say you have scenario of disaster where your database and all the data from your "micro-service B" is destroyed or corrupted.In order to solve the problem you could just restore your backup and apply the apply latest events from lets say last 1h whereyour "micro-service B" was down and solve the problem(If your event handling is implemented to be Idempotent). All good in this case.
另一方面，如果您的系统在生产中运行了一段时间.经过一段时间，您开发了微服务C"并决定部署到生产中.事实证明，您需要一些微服务A"产生的数据.您需要在微服务C"上存储这些数据作为外部数据，类似于您在微服务B"中获得的数据.您如何获得这些数据?您是否消耗了微服务A"中的所有事件?在理想世界中，您将永远将所有活动保留在卡夫卡.在这种情况下，您会只需订阅事件并应用所有事件即可将所需的所有数据保存在微服务C"中.实际上，您需要设置一些保留让您的Kafka停留 5天.如果您的系统运行时间超过5天，则无法通过事件重新创建数据.
On the other hand if you have a system running for a while on production. After some point you develop "micro-service C" and decideto deploy it to production. It turns out that you need some data that "micro-service A" produces. You need that data on your "micro-service C"as External data similar as you had it with "micro-service B". How do you get that data?You consume all the events from "micro-service A"? In ideal world you would keep all the events in Kafka forever. In this case you wouldjust subscribe for events and apply all of them to save all the data you need in "micro-service C".In reality you need to set some Retention Period to your Kafka for lets say 5 days. If you have a system running longer then 5 days you can not recreate your data from events.
在这种情况下，您需要直接使用Command/Query调用服务并填充微服务C"数据库.
In this case you need to call the service directly with Command/Query and populate the "micro-service C" database.
这只是一个边缘案例，您需要直接致电.
This is just one edge case example for which you will need to have a direct call.
摘要:
还有许多其他示例，这种方法也有效.例如，很多时候您将需要同步调用另一个微服务，并且您将要等待响应(取决于您的业务场景).最好的方法是直接使用Command/Query调用另一个微服务.
There are many other examples where this approach is valid as well.Very often you will for example need to call another micro-service synchronously and you will want to wait for the response(depending of your business scenario). The best way to do this is calling another micro-service directly with a Command/Query.
这篇关于微服务架构松耦合问题的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！