Abp: Microservices communication Confirmation

[khinhvuphiduong]

Dear all, dear ABP team
I'm sorry for my dumb question (and my English),

I'm very confused about Microservices communication with other in ABP Framework, in my view I understand the followings:

1. InternalGateway is used for another backend app call to Microservice? Not for Microservice Communication?

2. If Microservice A want communication with Microservice B, it's must publish a message to Bus, and Microservice B will subs this message?

My Question is: I understand correctly? and how Microservice A know and confirm Microservice B completed to return message to front-end, and how to Microservice B return a result for Microservice A?

Best regard!
Thanks you,

[khinhvuphiduong]

In this doc https://docs.abp.io/en/abp/latest/Samples/Microservice-Demo
Description about InternalGateway:
InternalGateway.Host: Used for inter-service communication (the communication between microservices).

But I can't find any demo for Microservice call directly Microservice via InternalGateway..

[xewn]

I think abpframework is still very inadequate in terms of microservice architecture. A more appropriate description of the current abpframework should be a modular solution based on .net core.
There may be incorrect understanding, sorry

[colinin]

The HttpClient(in Volo.Abp.Http.Client) is used for synchronous communication between services, and the AbpRemoteServiceOptions that the HttpClient module relies on is defined in the configuration file (appsettings.JSON), where the address of InternalGateway is specified

While asynchronous calls require microservice subscriptions, which are then implemented through Volo.abp.EventBus, distributed events have no waiting to return

[khinhvuphiduong]

The HttpClient(in Volo.Abp.Http.Client) is used for synchronous communication between services, and the AbpRemoteServiceOptions that the HttpClient module relies on is defined in the configuration file (appsettings.JSON), where the address of InternalGateway is specified

While asynchronous calls require microservice subscriptions, which are then implemented through Volo.abp.EventBus, distributed events have no waiting to return

Thanks you sir, it's exactly answer I expected. ABP framework is really fantastic architect.
Best Regard!

[cocosip]

I think InternalGateway is not a good solution.Always faces several problems while using InternalGateway.

• 1.How to avoid InternalGateway Single Point Problem?
• 2.InternalGateway is just a tool like nginx, when InternalGateway run on k8s, the services address will change after pod restart.
• 3.InternalGateway was based on Ocelot, it only support http protocols ,how to support other protocols?
• 4.Volo.Abp.Http.Client how to support other development language? Such as java, go ?

[khinhvuphiduong]

I think:

• Ocelot gateway is work at deeper layer than nginx and integrated identity server for authorization and authentication check.
• We're in Asp.net Core context, and Volo.Abp.Http.Client is support for auto generate HTTP proxy to call API.

[colinin]

I think InternalGateway is not a good solution.Always faces several problems while using InternalGateway.

• 1.How to avoid InternalGateway Single Point Problem?
• 2.InternalGateway is just a tool like nginx, when InternalGateway run on k8s, the services address will change after pod restart.
• 3.InternalGateway was based on Ocelot, it only support http protocols ,how to support other protocols?
• 4.Volo.Abp.Http.Client how to support other development language? Such as java, go ?

1. You can solve the pod change problem by exposing the external port of the internal server in the container, and the internal service will generally link the corresponding container in docker-compose.yml, so the container name can be used to replace the container IP address
2. Ocelot supports HTTP and WebSocket protocols, which are sufficient for abp framework, and Ocelot can take over important facilities such as identity authentication, authorization, flow limits, circuit breakers and downgrades
   3, Java also has a similar HttpClient library, you can follow the Volo.Abp.Http.Client to encapsulate a, they are not very different

[colinin]

I think InternalGateway is not a good solution.Always faces several problems while using InternalGateway.

• 1.How to avoid InternalGateway Single Point Problem?
• 2.InternalGateway is just a tool like nginx, when InternalGateway run on k8s, the services address will change after pod restart.
• 3.InternalGateway was based on Ocelot, it only support http protocols ,how to support other protocols?
• 4.Volo.Abp.Http.Client how to support other development language? Such as java, go ?

1. You can solve the pod change problem by exposing the external port of the internal server in the container, and the internal service will generally link the corresponding container in docker-compose.yml, so the container name can be used to replace the container IP address
2. Ocelot supports HTTP and WebSocket protocols, which are sufficient for abp framework, and Ocelot can take over important facilities such as identity authentication, authorization, flow limits, circuit breakers and downgrades
   3, Java also has a similar HttpClient library, you can follow the Volo.Abp.Http.Client to encapsulate a, they are not very different

Of course, you can replace Ocelot with Kong by simply changing the BaseUrl in the RemoteService that depends on it, which is defined in appsettings.json，None of this is a problem