Please enable JavaScript.

Coggle requires JavaScript to display documents.

Microservices - Coggle Diagram

- - - - Keeps persistent data private to a service and accessible only through that service
      - If RDBS is used, some tables can be made private to a service or Schema per service or DB Server per service.
    - - Within the respective Domains of the service, the DB can be shared by multiple services
      - Data is accessed as Async Service
    - - Command and Query Responsibility Segregation Pattern
      - Data Models are kept separate for reads and writes. Command Model and Query Model are kept separate.
      - Two DBs are maintained. In first DB, Command Models does Write operation against fully normalized DB while Query model does write operation against the second DB.
      - This model is beneficial in really high volume scenario.
      - Whenever write DB is modified an event is triggered which propagates changes to the read DB.
    - - Any event triggered will be stored in Event Store and no direct update or delete operations are performed on Data.
      - This structure enables 1. create Event-Driven Architecture, helps publish event whenever state changes, 2. Maintains Audit Logs of Records and 3. solves atomicity problems
      - CQRS and Event Sourcing pattern can be combined to get maximum benefits
    - - When a sequence of local transactions across Microservices occurs, each transactions update data and publishes a message over a event to trigger next local transaction in Saga.
      - First Transaction in Saga is trigger by external system and subsequent events are triggered.
      - Two types of Transactions can happen in Saga -
        
        Choreography Based and
        
        Orchestration Based.
      - Choreography Based transaction
        
        There is no central System which controls the Transactions. Each service produces and listens to the events triggered by other Service and the last service generates the output or response. Services are connected over Message Queue.
      - Orchestration Based transaction
        
        There is a central system called an Orchestration service which controls the flow and event data is aggregated by Orchestration service.
  - - - This gives permission to retrieve logs from individual service log store and write to the Central Log store.
      - Decentralised helps in audit and issue debugging
      - Log Structure - 1. Log Time-Stamp, 2. Container ID, 3. Container Name, 4. Source Id, 5. Event Type, 6. Event Name, 7. Client Type etc..
    - - Continuously monitor services for Performance. Data Dog in Azure the monitoring.
    - - Use a Message Broker to collect the Log data and Zip-kin is widely used tool. It maintains the log using Unique Trace ID or Correlation ID.
    - - Newly deployed service might not be ready to accept request, it would be pointless for Deployment Orchestration Architecture to route the request to service until it is ready to process them. DB conn timeout can a reason for failure.
      - If service doesn't recover this service should be terminated and new instance should be deployed.
  - - - Designing a multiple and complex Microservices with multiple client Apps, would need a single entry point. API Gateway is responsible for 1. Request Routing, 2. API Composition and 3. Protocol Translation.
      - API Gateway acts as Reverse Proxy.
      - API-Gateway Features
        
        Authentication and Authorization
        
        Service Discovery Integration
        
        Response Caching & Response Aggregation
        
        SSL Termination
        
        Retry Policies, Circuit Breaker and Quality-Of-Service
        
        RateLimiting and Throtling
        
        Logging, Tracing and Correlation
        
        Headers, Query Strings, and Claims Transformation
      - Backend for Frontend Pattern
      - https://www.nginx.com/resources/glossary/reverse-proxy-server/
    - - Since, services are small, Client calls the Aggregator Service which calls all the small services, aggregates the response and sends to the client App
    - - Proxy is variation of Aggregator model. This is just an extra layer on top of services and enhances security.
    - - Provides abstraction to the backend services to client and any changes in endpoint wouldn't affect the client apps
    - - Microservices are arranged in a way that output of one service is set as input to other
      - All these calls between microservices are synchronous and Client is blocked till all services are done. Recommended to keep the length of chain as small as possible.
    - - Extended version of Aggregator and Chain Pattern. Here, each service will communicate with all other services concurrently.
    - - UI Page with multiple-sections that gets data from multiple sources or microservices.
      - UI Team is responsible to implement the page skeletons that is built by composing data from multiple services. The complexity in UI is dependent on the UI Technologies used to build the UI application.
  - - - Changes to configuration requires redeployment causing downtime.
      - This patterns enables to move the configurations out of the Service and provides an Interface through which configurations can be read, updated without affecting actual service
      - Can be put on External storage or centralised location. Enables efficient reading and configuration setup. Can be read as Typed values, Collections or Key-Value Pairs. Access can be restricted. Preferred to be cloud based storage scenario.
      - In a Containerised Env like K8s, a native configurations resources are provides for regular and confidential data. e.g., ConfigMap and SecretObjects. Files are mounted to a volume on POD.
    - - The Network location of the Services are not static and tend to change due to Auto-Scaling or Service Recovery. These Network location becomes dynamic.
      - SDP will have DB for network location for all the running instances and this is achieved using registry mechanism. All running instances register themselves in the registry and update there status periodically. This is called Service Self Registration Pattern.
      - a. Client Side Service Discovery
        
        Client First queries Service Registry - Gets the Network Location - Client then queries service through Load Balancing model.
        
        Client is aware of Service Registry component. This is helpful when some services are on K8s and some on other legacy Envs. Service side will have to explicitly maintain this registry.
      - b. Server Side Service Discovery or Deployment Side Service Discovery
        
        All modern deployment orchestration Env gives this feature. A DNS name or Virtual IP Address is given, request to this IP is automatically routed by the deployment Env to the available service.
        
        Service Registration, Service Discovery and Routing are entirely handled by the Deployment Orchestration Platform. Services deployed in this cluster can only be registered here.
    - - Partial Failure of Microservices is handled in this Pattern. Service might be Overloaded, under Maintenance, not ready to server request or not respond in timely way.
      - Client is blocked during failures and Failures would cascade and cause problem for entire Environment.
      - API Gateway should return a Fall-back value. i.e., it could be cached version of data or an error message.
      - Status could be Closed, Half-Open and Open. This Pattern helps create a Fault Tolerant system and handles failures gracefully.
    - - This is technique of running two identical Production environments Blue and Green.
      - Switch the Env to Blue or Green when other is in deployment or down.
    - - This is technique of releasing new version of software to a small subset of users to avoid the risks. Doesn't require downtime and can be easily rolled back.
      - This is staged release process. Strategies to select the subset of users could be employees of company, users based on there profiles or users based on there interest and take the feedback, Later release to all the users.
      - Two types of deployment
        
        Rolling Deployment - Changes are rolled out in few instances at a time - Observe the performance and then roll out to other service instances. Single instance is POD and Replica-set is the multiple instances. This is also called Capacity Testing.
        
        Side-by-Side Deployment
  - - - Identified by analysing Business Purpose, Structure and Capabilities
    - - Subdomain specified different parts of Business
    - - The Strangler Application grows larger over time. Functionalities in Monolith application are replaced by a Microservice. This is specially useful when transforming Monolith Appln to Microservices.
    - - Bulkhead creates sections in Cargo ship restricting flood and fire to specific section. Each service works in it's penury and Failure in one service is restricted to a specific service
    - - Resembles Sidecar attached to a motorcycle. Sidecar implements peripheral features such as 1. Platform abstraction, 2. Proxy to remote services, 3. Logging and 4. Configuration, while Primary Application implements Core Functionality.