Questions regarding new microservice design #2268

6 Answer(s)

• 

  0

  gterdem created 3 years ago

  Senior .NET Developer

  Hello,

  Why was it removed in this version? Actually i am not sure what was the internal gateway was doing on the previous version. was it only a gateway that is publishing the events from rabbitmq and do the communication between all micro-services?

  Internal gateway was working as a service locator when microservices make synched (http) communication. It was not related with publishing events but only related with synched communication between microservices. I would suggest reading guide communication between microservices to learn more about it.

  And if it was doing all the communication between all microservices before right now how it has been solved?

  We were using dynamic proxy which resolves endpoint configurations in runtime. This required api-gateways to be dependent on other microservices' Http.Api layer. There were some problems related with design like having difficulty to change Ocelot to any other gateway (like envoy etc).

  And i believe only "administration service" needs to make a call to "identity service", is there any other microservice making a call to other microservices?

  Yes, specifically when you request User Permissions, AdministrationService makes a request to IdentityService. As default, there is no other synched inter-service communication.

  But what i don't understand is why administrationservice needs to depend on 5 contractsmodule which are

  Because of permissions. Each microservice has their own permissions but AdministrationService hosts the Permission Management module. Also for api-configuration see this issue.

  ps: still on the doc it mentions about internal gateway which is not present probably it would be modified when the v5 is released.

  Thanks, we'll update docs.

  Save Cancel
• 

  0

  cangunaydin created 3 years ago

  Allright i think it is more clear in my mind now, thank you for the answer.

  So to summarize, you removed internal gateway because there was only one synched (http) communication which is between administration service and identity service.

  All the permissions are defined in application contracts, so this brings us to the conclusion, whatever microservice that implements permission manager module needs to define every microservice application contracts module, so permission manager can do crud operations on the permissions?

  And as the last thing if i want to create a communication for ex between productservice and saas service

  • I need to create productservice as a client in identity server give the scope as "saasservice"
  • configure productservice by changing appsettings.json in the project like sth similar that has been made in administration service config.

  "AuthServer": { "Authority": "https://localhost:44322", "RequireHttpsMetadata": "true" }, "RemoteServices": { "AbpIdentity": { "BaseUrl": "https://localhost:44388/", "UseCurrentAccessToken": "false" } }, "IdentityClients": { "Default": { "GrantType": "client_credentials", "ClientId": "Adzup_AdministrationService", "ClientSecret": "1q2w3e*", "Authority": "https://localhost:44322", "Scope": "IdentityService" } },

  • And as the last step i need to have the "HttpApiClientModule" of the "saas microservice" in the "productservice module" and i don't need any contracts module since "HttpApiClientModule" also have a reference to the "Saas Contract Module" and this microservice doesn't manage permissions.

  Further Questions:

  • So as i understand identityclients options are configured in AbpHttpClientIdentityModelWebModule but in the docs it has been used AbpHttpClientIdentityModelModule can you clarify the difference between 2?

  • Also if i am planning lots of communications between different microservices internally isn't the internal gateway with ocelot is better approach maybe it is not very efficient if one microservice needs to call another but overall can we say that if we have many communcations between our microservices isn't it better to configure an internal gateway instead of configuring all the microservices one by one? What i am asking is are you planning to replace back internal gateway with another solution than ocelot or is it gonna be gone for good?

  Thank you so much for the help and assistance

  Save Cancel
• 

  0

  gterdem created 3 years ago

  Senior .NET Developer

  So to summarize, you removed internal gateway because there was only one synched (http) communication which is between administration service and identity service.

  Not really. We didn't want gateways to be dependent on Http.Api layers of microservices so that developers can easily switch to an other gateway stack (like envoy etc).

  All the permissions are defined in application contracts, so this brings us to the conclusion, whatever microservice that implements permission manager module needs to define every microservice application contracts module, so permission manager can do crud operations on the permissions?

  Pretty much, yes.

  Your sample about synched communication between porudct service and saas service seems right. Also you can check this answer about Client Credential Flow.

  So as i understand identityclients options are configured in AbpHttpClientIdentityModelWebModule but in the docs it has been used AbpHttpClientIdentityModelModule can you clarify the difference between 2?

  AbpHttpClientIdentityModelWebModule is used for UI involved flows when http context accessor is used while AbpHttpClientIdentityModelModule doesn't use the http context. AbpHttpClientIdentityModelWebModule already implements AbpHttpClientIdentityModelModule.

  Also if i am planning lots of communications between different microservices internally isn't the internal gateway with ocelot is better approach maybe it is not very efficient if one microservice needs to call another but overall can we say that if we have many communcations between our microservices isn't it better to configure an internal gateway instead of configuring all the microservices one by one? What i am asking is are you planning to replace back internal gateway with another solution than ocelot or is it gonna be gone for good?

  Surely. If you want to use dynamic proxy and keep using ocelot you can use an internal gateway and set

  "RemoteServices": { 
      "Default": { 
          "BaseUrl": "https://localhost:44388/" // Internal Gateway url
      }
  }
  

  in other microservices.

  However, keep in mind that you are tightly coupling the microservices by making synched inter-communication. If you have lots of communications between different microservices, I would suggest differentiating them and decide which ones should be synched communication (with http requests) and which ones can be async over eventbus.

  Save Cancel
• 

  0

  cangunaydin created 3 years ago

  Hello again, I really understand now, also i read this doc from microsoft, which is not a good practice to do synced communications between microservices as they say https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/communication-in-microservice-architecture

  https://docs.microsoft.com/en-us/dotnet/architecture/microservices/architect-microservice-container-applications/media/communication-in-microservice-architecture/sync-vs-async-patterns-across-microservices.png

  So this brings me another question Isn't there anyway to get users without being coupled to identity service. For ex first thing that comes to my mind is to make identityservice not being a seperate microservice and include it in administration service? But probably it is the most used service? Why did you choose to make it a seperate service if it is gonna be coupled to administration service? or how do i need to do decisions when i am seperating monolith project to microservices? Is there any guide or docs or any book to read to learn more about it?

  I really appreciate your help, and thank you for answering my questions.

  Save Cancel
• 

  0

  gterdem created 3 years ago

  Senior .NET Developer

  So this brings me another question Isn't there anyway to get users without being coupled to identity service.

  What makes you think you have to be coupled to identity service for identity user? I would suggest digging more on Domain Driven Design to see how to handle these kind of coupling (using data duplication etc).

  For ex first thing that comes to my mind is to make identityservice not being a seperate microservice and include it in administration service? But probably it is the most used service? Why did you choose to make it a seperate service if it is gonna be coupled to administration service?

  IdentityService, AdministrationService and SaasService are infrastructural services. Their dependency to each will not change when you develop your business services. Think of a case where you have to make a synced call (http request) to user list endpoint. Wouldn't it make more sense to be dependent on to only IdentityService instead of a merged AdministrationService where its main functionality is managing existing modules?

  or how do i need to do decisions when i am seperating monolith project to microservices? Is there any guide or docs or any book to read to learn more about it?

  Deciding how to seperate monolith into microservices is a very popular question that you can find many related answers to that from google. I mostly favor the answer: experience. Hardest part of DDD is deciding bounded contexts (henceforth, dividing monolith context into bounded contexts) which requires domain experts or high knowledge about DDD and experience.

  There is a great free-ebook Domain Driven Design with the ABP Framework i would suggest. And also Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans.

  Save Cancel
• 

  0

  cangunaydin created 3 years ago

  Hello again thank you for the answer.

  What makes you think you have to be coupled to identity service for identity user? I would suggest digging more on Domain Driven Design to see how to handle these kind of coupling (using data duplication etc).

  Actually i was talking about it from the administration microservice perspective, I was looking at the problem like "reduce the number of intersynched communications if it possible". So that was my intuition at the first place but i understand your point.

  There is a great free-ebook Domain Driven Design with the ABP Framework i would suggest. And also Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans.

  Thanks for the suggestions i have already read the Domain Driven Design book from Abp, i will check the Eric Evans's Book also.

  Thanks for the assistance.

  Save Cancel