An ex-employee planned a Microservice Architecture which is being implemented now. I've few question regarding the design and I'd highly appreciate your feedbacks.

Lengend :these are the legends used for designing the architecture.

Architecture

Explanation

Dematerialized UI has a matching dematerialized API.

Dematerailized API validates the user and generates token via SSO Library.

Flight API does the I/O validation & validate the request via validate request microservice

Flight API calls Booking API to get some bookings based on the UserId

Flight API calls Print Booking API to generate Messages using Generate Message Microservice

Print Booking API must call Data Access API to get data and then call Generate PDF microservices.

Data Access API calls the database for data.

My Project Structure

    FlightBookingsMicroserice.V1 //solution
    ApiGatways //folder
        DMZ.API/DMZ.API.csproj //Folder/project
    BuildingBlocks
        EventBus/EventBus.csproj
        EventBus/EventBusRabbitMQ
    Services 
        SSO
            SSO.API/SSO.csproj
            SSO.UnitTests
        Flight
            Flight.API/Flight.API.csproj
            Flight.UnitTets

        //Similar for all
        ValidationRequest
        Booking
        PrintBooking
            PrintBooking.API.csproj
        DataAccess
            DataAccess.API.csproj
        GeneratePDF
        GenerateMessage
    
    UI
        UI
    Docker-compose
    

Questions

1. Should I be using ocelot in DMZ.API.csproj, Flight API and Print Booking API.
2. Is my project structure a Microservice way of development
3. Should I continue to use ASP.NET Core Web API with .NET 6 for Dematerialized API in orange, Function API in blue and Microservice in purple projects.
4. For validation, since the SSO is passed from Dematerialized UI what if the token expires while CRUD operations is already performed for some stages [rolling back changes is a hassle]. Should each API access to an identidy server and validate the user passed and generate its own token for its services in purple.

Thank you in advance.

CodePudding user response：

The core question is if you really need all those services and if you perhaps are making things too complicated. I think the important thing is to really consider and really make sure you justify why you want to go through this route.

If you do synchronous API calls between the services, that creates coupling and in the long run a distributed monolith.

For question #4, you typically use one access token for the user to access the public service, and then you use a different set of internal tokens (machine-to-machine also called client credentials in OpenID Connect parlor) between services that have a totally different lifetime.

CodePudding user response：

q1: ocelot is an API GATEWAY which is the entry point for your requests. so it should be the first layer/service meet by user request in front of your services and it forwards the request to the service according to its configuration. so it is lay in the front for all services you have. some arch provide another api gateway for different reasons like specific api gateway for mobiles request for example.

q2: as looking separate services (i cant understand function api but i assume they are services also ) yes but the microservices development is not just about separating things, its about design and identifying the services from business context (Domain Driven Design).its very challenging to identify services and their size and the way they are communicate to each other (asynchronous communication and synchronous communication).

q3: microservices is not about languages and frameworks.one of benefits of microservices architecture is its not language or framework dependent. the may be multiple languages used in microservices. choosing languages it depends on organization policy or your own reasons. if you are .net developer then go for .net.

q4: all the services are registered with identity server and they validate the given token by it. the identity server generate token (there may be multiple tokens) with scopes . the request from identified users always has the token in the headers and the services validate incoming token by referring identity server. this tokens has lifetime and also identity server generates refresh tokens in case of expiry of current token. please look at Oauth docs and rfc. also this https://www.youtube.com/watch?v=Fhfvbl_KbWo&list=PLOeFnOV9YBa7dnrjpOG6lMpcyd7Wn7E8V may helped. you can skip the basic topics. i learned a lot from this series.