MicroService Architecture

What is MicroService?

Providing a solution in Software world for any kind of requirements/problems,approach that we use common is divide and conquror technique.Breaking larger problem/domain into sub problem/domain and each sub domain represented as runnable service to achieve autonomous called MicroService.

Why MicroService?

Autonomous    - Scalability & Maintainability

Lously Coupled  - Service Integration is less spannning ,so it will become lously couple.Not tightly coupled with multiple domains/team.

Reusability   - API Level Modeling, SOA , Business Domains

Fault Tolerance - Continueal operational, even though service to service communication failure.

Composiablity  - Containeraization (Docker)

Discoverability - Service as Interface, service registry and dynamic configuration.

Design Principles in MicroService?

  DataBase Pattern

Private Tables per Service:

     Tables which associated with that Microservice should take responsible for read and write operation.And expose API to be used by other service.

   Tables should be in bounded context of sub domain.

   Advntage- Low Overhead

  Schema per Service:

Entire keysapce/databases will be owned by individual Microservice.

Advantage- Ownership Clearer

  Database Server per Service:

Entire DB Server dedicated for Microservice.

Advantage- High Throughput

 Above pattern DB should expose less classification and allows predicate's to support larger dataset.

 Note:- Data Owning should be derived from context / bound context of sub domain.

  SAGA Pattern

   Problem:-

    Service vise each microservices are independent and loosly structured but in business perspective service's are composed as integrated service.

      Eg:- OrderService,ProductService and CustomerService

   1.By Using productservice customer selected list of product

   2.Now Customer gonna place an order but order while placed based on customer credit limit.

   3.Now orderservice have to check the creaditLimit state of customer via customer service.

  Service to service communication can be done via API call but how to achieve atomicity & consistency.

  Above mentioned problem can occur in any business.

 Solution:-

   To achieve atomicity & consistency over communication between service to service called SAGA pattern.

Saga pattern uses sequence of local transaction perform at Single unit of transaction over multiple DB.

  Two Types of SAGA:-

     Choregraphy:-

    Each Local transaction publish message/event via even bus and perform local transaction on event subscribed by other service.

 Eg:

  1. CheckCreditLimit event triggered via event bus in OrderService

  2. On CustomerService event handler verifies creditLimit via Repo and result Success/Failure Event thrown in EventBus

  3.Now OrderService handle CreditLimitReponse.

     Orchestration:-

    Its iterate the instruction and intimate the participants (services) what local transaction to be performed.

 Eg

  1. CheckCreditLimit Command OrderService ,it replies checkLimitStatus

  2. OrderService will perform commit the transaction based out of result

  3. OrderService will perform Undo operation in CustomerService and its own.

  Event Sourcing & CQRS

    Maintaining state for an service via events called event sourcing.An event should update the database and send message/event via event bus.

 (Eg): Bank Statment of account holder.

   Events: Credit & Debit 

Each event represent sequence number, time, event name and amount.By aggregating the event's will get state of the account nothing but an accountbalance().

  Event Driven          Message Driven

• No acknowledgement     Proper acknowledgement
• Event has object       Message can hold events
• Dataloss Possible       No Dataloss

Command Query Response Segregation (CQRS)

     *The idea to separate read and write of the data is CQRS.

   *Command which will update the databases and send message/event.

  *Query just an read operation from update data from DataBases.

   Eg:- account_read_service[Query & Response operation] and account_write_service[Command Operation].

  1.Write and Read are synchronized by event bus

  2.Transaction Command will update account transaction credit/debit and send event Credited/Debited to Read

  3.Read service will handle AccountEvents [Credited & Debited] to persist in DB.

  4.checkBalance(),summary(),summary(costraints) service provided by read service.

  5.AccountTransact(from ,to,amount) will be served by write service

Advantage:- Easy to scale up number of reads based on requirements.

SAGA uses EventSourcing & CQRS pattern to achieve the atomicity & consistency.

  Transactional Outbox

     Its another approache to apply SAGA pattern, mostly event/message computation produced in SAGA participants.To avoid data lost event/message persisted.In order to serve single unit of transaction.

Each service process command and generate message/event to be persisted in message outbox on DB.Another end,Message Outbox will polled constantly onces event/message falls put into message broker / event bus.This process are called transactional outbox.

  API Composition

     Aggregating API's call nothing but API composition.Its basically transforming multiple API call response into single response.

  Eg:- Based on product rating retrieve the customer list who bought the products from last 6 months.

   Its requires OrderService,CustomerService and ProductService.

we can compose the API perform above operation in another service called API composition.

Its irrespective of Synchronous and Aysnchronous calls.

  Circuit Breaker

     In order to serve availability circuit breaker pattern is used.During the service request chaining,if one of the service is down its should return default result instead service down failure error.

In background should it wait for service to up, onces service its up service registry will perform service test then approve for join the chaining.

Architecture Diagram

Sample Software Recommendation

Language: Go, Java, Scala

Framework:go-kit,spring boot, spray , akka,Alpakka

Sql DB: MariaDB,PostgreSql,SqlServer

NoSqlDB: Cassandra,MongoDB,Redis

Message Broker: ActiveMq,RabbitMq,Kafka,kenesis

ServiceRegistry: Netflix , Akka,Eureka

API Gateway: Nginix, Apache, krakenD

Container: Docker

Cloud: AWS, Azure,Google Cloud.

CI/CD: Jenkins,Open Swift

Pros:

  1.Continuous development

 2.Scalability 

  3.Able to manage by small team

  4.Agility

  5.Easier in CI/CD pipeline

 6.Lously Coupled and Fault Tolerance

  7.Language Independent

 8.Cloud Computing

  9.Containeraization

Cons:

  1.Difficult to manage

  2.Needs more collaboration

  3.Harder for perform test and monitoring

  4.Harder to manitain the network

 5.Security Issues 

6.Its harder to implement transaction safety