What are microservices

Microservices is an architectural style in which a large complex software application consists of one or more microservices. Each microservice in the system can be deployed independently, and each microservice is loosely coupled. Each microservice is focused on doing just one task and doing that task well. In all cases, each task represents a small business capability.

The concept of micro service from March 2014 an article written by Martin Fowler “Microservices” (martinfowler.com/articles/mi…). .

Although the architectural style of “microservices” is not precisely defined, it has some common features, such as organizing services around business capabilities, automated deployment, smart endpoints, “decentralized” control of language and data, and so on. Thinking about microservices architecture comes from the contrast with overall applications.

Typically, as a company evolves (natural growth) as business needs grow, the system is organized early on in a monolithic architecture. The single-block architecture approach is the easiest and most efficient for early software construction. But over the years (or even months), it becomes increasingly difficult to add new functionality to an existing monolithic software system due to the inherent coupling within the system.

A single piece of software

Enterprise applications, because they serve many business needs, have many functions provided by specific software applications, and the general practice is to stack these functions in a single monolithic application. For example, ERP, CRM, and various other software systems are planned to be built as a whole with hundreds of functions. Once deployed, such a cratered application can be a nightmare after nightmare in subsequent troubleshooting, scaling, and upgrade scenarios.

Service-oriented Architecture (SOA) aims to overcome these limitations by introducing the concept of “services,” which are aggregations and groupings extracted from similar capabilities provided by applications. Therefore, with SOA, software applications are designed as a collection of “coarsely grained” services. However, the wide range of services in SOA leads to complex and large services with a large set of operations (functions) and incredibly complex message formats and standards (such as the WS * standard).

In most cases, the services in an SOA are independent of each other, but they are deployed at the same runtime as all the other services (just consider multiple Web applications that will be deployed to the same Tomcat instance). Similar to monolithic software applications, these services have a habit of accumulating work over time. Figure 1 is a very good example of a monolithic architecture, showing a retail software application that includes multiple services, all of which can be deployed to the same application.

After all that, are you a little confused? I’ve summarized some of the highlights, and here are some of the features of applications based on a single fast software architecture:

  • Monolithic applications are designed, developed, and deployed as a single unit.
  • Monolithic applications are relatively complex, making maintenance, upgrades, and new features difficult.
  • It is difficult to practice agile development and delivery methods with a monolithic architecture.
  • If you want to update a part, you will most likely have to redeploy the entire application.
  • In the case of conflicting scale requirements, be prepared to multiply resources or even redo A single point of scaling (for example, if you want to give A more CPU to A service, B service may have to redo it or add two or three times the memory).
  • Reliability: An unstable service can slow down overall application performance.
  • Difficult to innovate: Adopting new technologies and frameworks is difficult because all functionality must be built on a uniform technology/framework.

Microservice-oriented architecture

A microservice-oriented architecture has several characteristics. Large and medium-sized companies of any size will crave these features if they want to keep their IT systems flexible and scalable at all times.

Why is microservice-oriented architecture better

Microservices Architecture (MSA) is based on the development of monolithic applications as a set of small, standalone services that are developed, deployed, and run independently in their own space. In most definitions of microservices architecture, it is generally interpreted as the process of isolating a large number of available services into a set of independent services.

But microservice-oriented architecture is not the holy grail of unengineering. Flexibility, composability, and flexibility are key principles of microservice-oriented architecture design. If you don’t, you’ll lose out on a perfect solution and end up with a lot of problems when a single application is split across multiple machines.

Deficiency in

Nothing is absolute, microservices will also have a few problems:

  • Network latency: The distributed nature of microservices makes network latency inevitable
  • O&m burden: More servers mean more maintenance work
  • Final consistency: In a transactional system, given the limitations of the implementation, data inconsistency may occur between nodes at a given time

Key Design principles

In general, we can identify design principles:

  • Single Responsibility Principle (SRP) : Providing a limited and focused business scope for microservices helps us meet agility in developing and delivering services.
  • In the design phase of microservices, we should find the boundaries of each service and align them with business capabilities (also known as bounded environments in domain-driven design).
  • Microservices are designed to ensure the smooth stability of agile/independent development and deployment services.
  • Our focus should be on the scope of microservices, not making them “smaller”. The size of a service should refer to the scope size required to facilitate a given business capability.
  • Unlike services in SOA, a given microservice should have few operations/capabilities and a simple message format.
  • Over time, it is a good practice to start with relatively broad service boundaries and refactor to smaller service boundaries (based on business requirements).

Key benefits

Now let’s look at a few key benefits.

The elastic

Wikipedia defines resilience as the ability of a system to handle change. My understanding of resilience is the ability of a system to gracefully recover from an abnormal state or period of stress after a problem has been resolved without affecting system performance.

This may seem simple, but when building microservice-oriented software, the problem sources are magnified by the distributed nature of the system, and it is sometimes difficult to prevent all exceptions.

Resilience is the ability to gracefully recover from mistakes. But it also brings new complexity to the system: if a microservice goes wrong, can we prevent the system from failing in general? Ideally, we should build the service in such a way that it only degrades the service response rather than allowing the system to fail in general, and even that is not easy.

scalability

A common problem for companies today is scalability. Typically, these issues do not cover every level or subsystem of the application. Often only a single subsystem or service will be visible to the rest of the application, and failing to address capacity issues can cause the entire application to fail.

The following figure describes how to extend the microservice (to two mail services) without dragging in the rest of the system:

Diversity of technology

The software world updates systems every few months. There is a pause in the pace at which new languages enter the industry and become de facto standards for certain types of systems.

  • Golang: A current trend because it combines powerful performance with elegant and concise syntax that anyone with experience in a programming language can learn in a matter of days.
  • Java: Since the release of Sping Boot, it has become an attractive technology stack for writing agile services.
  • DJango: A powerful Python framework for writing microservices, much like Ruby on Raile.
  • Node.js: Takes advantage of the well-known JavaScript to create a new server-side technology stack that changes the way engineers write new software.

So what’s the problem with combining stacks of technologies for these languages? To be fair, this is an advantage: we can choose the right tools to do the right job. As long as the technologies to be integrated are standardized, a microservice-oriented architecture can help you do this.

The following figure shows how microservices hide the data access logic. The two services share the same point of communication for accessing data, thus being well decoupled from each other:

Node.js is not a good language for doing parallel tasks. For microservices that are under stress, we can choose a more appropriate language for development, such as Erlang, to manage concurrency in a more elegant way.

replaceability

Replaceable is the ability to replace a component of a system without affecting the behavior of the system. When we talk about software, replaceability is often associated with low coupling. When writing a microservice, you cannot expose the internal logic to the calling service. The service implementation is transparent to the client, and all the client needs to know is the interface.

independence

All services should be independent and interact through interfaces. In addition to agreeing to identify interfaces, different teams of engineers can complete the development of services without having to communicate.

Easy to deploy

Microservices should be easy to deploy for the following reasons:

  • Less business logic, resulting in easier deployment.
  • Microservices are autonomous units of work, so upgrading a service is a locally controllable issue for complex systems. There is no need to redeploy the entire system.
  • The infrastructure and configuration in the microservices architecture should be as automated as possible (such as Docker to deploy microservices).

SOA vs. microservices

Microservice-oriented architecture (SOA) and microservice architecture are very imaginative. So what is the difference between them?

Microservices are fine-grained SOA components. In other words, a single SOA component can be broken down into multiple microservices, and these microservices can work together to provide the same level of functionality as the original SOA component, as shown below:

Another difference between microservices and SOA is the technology used to connect services and write them. Microservices, on the other hand, tend to enforce standards (such as HTTP) that are widely understood and shared. We can reap the key benefits of technical diversity by choosing the right language or work to build a component (microservice).

In addition to the technology stack and service scale, there is an even bigger difference between SOA and microservices: the domain model. In an opportunity microservice software, each microservice should store its own management data locally and isolate the domain model into a single service. In SOA-oriented software, data is often stored in a single large database, and domain models are shared between services.

Why choose Node.js

Node.js is a new stack of technologies, and for many, it’s just a trend, not a real tool for solving problems.

Let’s focus on Node.js. Node.js is an excellent choice for building microservice-oriented architectures for several reasons:

  • Low learning threshold (if you want to master or have a certain threshold)
  • extensible
  • Test friendly
  • Easy to deploy
  • You can manage dependencies through NPM
  • There are a number of libraries that integrate with mainstream standard protocols

API polymerization

API aggregation is an advanced technique for combining different functions (plug-ins, methods, and so on) into a single interface. Example:

const express = require('express');
const app = express();

app.get('/sayhello'.function (req, res) {
  res.send('Hello World! ');
});
app.get('/saygoodbye'.function(req, res) {
  res.send('Bye bye! ');
}

const server = app.listen(3000.function () {

  let host = server.address().address;
  let port = server.address().port;

  console.log('Example app listening at http://%s:%s', host, port);

});

Copy the code

The previous example uses Express, a Popular Web framework in the Node.js technology stack. The framework is also built around API aggregation.

Let’s look at the fourth and seventh rows. In this code, the developer registered two methods. When someone requests the URLS: / sayHello and /saygoodbye, respectively, as GET requests, the corresponding methods are executed. In this case, the interface is an app listening on port 3000.

summary

In this article you learned about some of the key benefits of a microservice-oriented architecture, such as the ability to choose the right language for the corresponding service (linguistic diversity); And some of the misconceptions that can add to our burden, such as the operational overhead associated with the distributed nature of a microservices-oriented architecture.

Finally, we discussed how Node.js is a powerful tool for building microservices, and how to build high-quality software components by leveraging technologies like API aggregation to benefit from JavaScript.