OskaDev

OskaDev

Microservice

Did you know, microservice can be different when using different of structure?

What is Microservice

Microservice is a Service-Oriented Architecture styles mean every service have their role to do. As of experience one of the company have work on service mesh and unable to maintain well on monitoring.

Example

Example in this article we go with UserService, PaymentService and ItemService. Example code will be using NodeJS.

UserService is using PostgreSQL. ItemService is using MongoDB and Redis for caching. PaymentService is using MySQL and 3rd party payment gateway.

Request Flow of Service Mesh

Normally the flow would be like this but not really a good choice because when monitoring you will hard to check performance, issues. May sometimes will break at half of the service before the request complete and you cant track back. Personally i dont suggest go with service mesh because of the issues stated above. I have think about a new idea for my own if go for microservices.

Client ---> UserService ---> PaymentService ---> ItemsService ---> PaymentService ---> UserService ---> Client

How it works & What issues may meet

IMO microservices not really mean service have to move out into pieces. What i have look is just multiple Http Transport exposing different API only. If only this, why wouldn't we create own shared high-level library ( depends on your choice ).

Shared Library

Shared library should contains 3rd party services, database connection, database model or repository, some service related method. Depends on your choice to make the library with high-level api or not etc. You may also make all of them independent and make them modularize, easier to plug and play later on.

const { UserDatabase, UserService, PaymentService, ItemService } = require('shared-library');

const database = new UserDatabase(process.env.DATABASE_URL);
const service = new UserService(database);

service.getUser(1);
service.getUsers();
service.updateUser({ name: 'Oska' });

Http Framework

Http framework should just contains exposing API using the shared library method. For monitoring just from receiving request until outgoing response.

const express = require('express');
const { UserDatabase,  UserService } = require('shared-library');

const database = new UserDatabase(process.env.DATABASE_URL);
const service = new UserService(database);

const app = express();

app.get('/users', function (req, res) {
    res.json(service.getUsers());
});

app.listen(process.env.PORT);

Customize

If you really need to have customized response from shared library, you may apply hooks / lifecycle when requesting and make the hooks apply from http framework side.

Issues

Because of shared library, if more than one microservices trying to update or create users at same database and same time, may have concurrency issues on AUTO_INCREMENT fields and update conflict. For this issues some of the database have handled well or have some method to solve like LOCK TRANSACTION. Other than that, you may try go with REDIS, RABBIRMQ or any others communication tools to centralize the database call and ordering it one by one but i personally think this would cause performance issues?

When to use Microservice

If you have monolith app that really big, you may migrate slowly by cutting services out and build into microservice. If your app quite small just go for monolith, because microservices will have some latency between request to communication tools like redis and microservice may costly than a monolith app.

 
Share this