Getting Started with micro-services for Beginners

This is a creation in Article, where the information may have evolved or changed.

Introduction

: MicroServices are a vague term, often referred to as small, independent services that collectively form an application. MicroServices architecture In contrast to monolithic architectures, its applications are a large system. We will discuss how to start as a beginner and choose the right tool to build a microservices architecture.

A rapidly rising micro-service

As a result of the Google Trend Index, microservices have become more popular recently:

Before you begin, let's start by understanding why a mini-server is gaining popularity, even if it's not a new concept. This can be explained by Conway's Law:

The organization of the

design system, the resulting design and architecture are equivalent to the communication structure between organizations.

Why Micro Services?

Less compromises in the technology stack

The choice of technology stack is always a difficult task, team skills, scalability, maintainability are important factors in this choice. But a lot of the time is good for some part of the application, but not for the rest.

For example, a trading platform requires PostgreSQL because it supports transactions, and user-specific data must be stored in Dynamodb, which in general requires compromise. But in a microservices architecture, each micro-server has a set of business logic and related data in its best form, and provides an interface to interact with it. As a result, transactions and user microservices can be provided for data hosted by PostgreSQL and DynamoDB, allowing access to external services only through that interface. As a result, compute-intensive microservices can be written in Python, while API Server remains in NodeJS, and so on.

The example schema is shown below

Team Independence

In a single application, most people in the development team need to know all the parts of the application even if they develop a small feature. They have to work with other teams on deployment planning, versioning, data migration, and more. On the other hand, in a microservices architecture, the team only needs to know the interface provided by other services and stick to the interface it provides, and each microservices should be deployed independently. CI/CD tools like Circlci,travis and Heroku are very helpful in developing microservices, and a small team is enough to develop/maintain a service.

Just do one thing and do it well

The microservices architecture is similar to the principles of Unix philosophy, doing one thing and doing it well. This is a proven principle and one of the reasons why Unix systems will not become obsolete in the next few decades. MicroServices should be designed to do one thing, be tested to handle all possible situations, and then form a robust and flexible application through "pipelines".

Fault Isolation

Imagine the error in the "Report generation" module, shutting down the entire trading application, which is scary and unnecessary. If the application is based on a micro-server, the report generation module will fail with only that particular feature. Users who do not generate reports will not even notice that the key parts of the application still work. This is the result of loose coupling between micro servers, which can now be implemented through this architecture.

How to develop micro services

In node. JS, Seneca is a widely used framework for developing microservices. But if you want to go deeper, read on.

API Gateway

MicroServices can be deployed without a major central service, but sometimes the middle tier retains the shared library and sometimes it can be used as an API gateway. API gateways are used to provide a consistent API to clients, regardless of the backend service or vice versa. This is helpful when you have a variety of microservices for clients such as mobile, web, and other servers. In addition, it can prevent a client from making requests to multiple services by abstracting it as a request.

Inter-business communication

How should these services communicate with each other? Well, there are many options.

• HTTP: The most straightforward is to use HTTP/HTTPS, and the interface can be used as a RESTful API. However, HTTP makes service discovery difficult and not dynamic enough. That's why I don't like it.
• Message Queuing: Message Queuing protocols such as Amqp,stomp and MQTT allow for communication between microservices using the Publish subscription pattern, and services such as RabbitMQ and Apache Kafka are widely used for this purpose. I personally prefer to use Message Queuing because they are fault-tolerant and support message persistence.

Microservice-template is the basic template we use in MicroServices-based projects. It is in Node, and MongoDB is configured as a data store. It communicates between business through Servicebus to RabbitMQ, which is its minimum appearance:

There are other concepts, such as Event Sourcing and CQRS, which complement the microservices architecture. Event Sourcing is basically a change in the storage of data, not a change in the state of the data. In a highly concurrent environment, Event Sourcing brings a higher level of consistency.

But the fact is that microservices architectures are not silver bullets, and the use of microservices for fairly small applications can lead to a loss of productivity, as shown in.

Original: MicroServices for beginners, how to get started with right Tools | Codebrahma

Extended reading: Security Checklist for WEB developers-the column of knowledge

Welcome attention:

• The column "Aurora Daily", makers three high-quality English articles for the daily reading.
• Aurora Github Project: "aurora UI, a generic IM chat UI component.