microservice-pattern

Concept

This crate advocates the use of in-process microservice pattern.

The typical modern system is consist of bunch of gRPC microservices that communicates each other. The gRPC microservice is a process whose internal is consist of logics and data structures.

To develop the internal, in-process microservices is a very helping layer because you can modularize the internal in the same way the gRPC services does in the inter-process layer.

graph LR
  SYSTEM(System)
  GRPC(gRPC Microservice)
  subgraph In Process
    MICRO(Microservice)
    DATA(Data Structure)
	LOGIC(Logic)
  end
  SYSTEM -->|1..| GRPC -->|1..| MICRO
  MICRO -->|1..| DATA
  MICRO -->|1..| LOGIC

Loading

Ticking

A processing of in-process micro services is triggered by either gRPC request or internal tick.

To make a internal tick you can use tools in tokio::time or tokio-cron-scheduler for more flexible control of the ticks.

graph LR
  S(Service)
  T(Ticker)
  T -->|call| S

Loading

Dependency loop

Dependency loops are not allowed in this library because it is a vicious way of designing micro services but it is sometimes inevitable. To work around, queue can be used to invert the dependency. You may use actor framework to implement this.

graph LR
  S1(Service1)
  S2(Service2)
  S1 -->|1. call_A| S2
  S2 -->|2. call_B| S1

Loading

==

graph LR
  S1(Service1)
  S2(Service2)
  EX(Executor)
  Q(Queue)
  S1 -->|1. queue task| Q
  Q -->|2. dequeue task| EX
  EX -->|3. call_A| S2
  EX -.->|dependency| Q
  S2 -->|4. call_B| S1

Loading

This is quite similar to sidecar pattern.

graph LR
  S1(Service1)
  S2(Service2)
  S3(Queue Service)
  S1 -->|1. queue task| S3
  S2 -->|2. find new task| S3
  S2 -->|3. call| S1

Loading