Shulou(Shulou.com)06/03 Report--

The knowledge points of this article include: the concept of micro-services, the advantages and disadvantages of micro-services, the architecture of micro-services and examples of the use of micro-services. I believe you will have some understanding of micro-services after reading the complete article.

What is a microservice?

Microservices is a style of software architecture that constructs an application as a collection of small autonomous services around a business.

Microservices are based on small functional blocks (Small Building Blocks) that focus on a single responsibility and function. Each service is independent and implements a single business function

Microservices compose large and complex applications in a modular way, and functional blocks communicate with each other using language-independent API sets.

Micro-service uses the design concept dominated by business function, and the application can be divided by business function or process design first, and each business function can be independently implemented into an individual service that can run independently. Then use the same protocol to combine all the services needed by the application to form an application.

Microservice example 1

Take the shopping cart application as an example. When you open the shopping cart application, all you see is a website. However, in the background, the shopping cart application has the ability to accept payment services, customer service, etc.

Assuming that the developer of this application uses a single framework, the architecture is as follows

As shown in the figure, in a single architecture, all functions are placed in a code base and under a basic database.

Now, suppose a new brand appears on the market, and the developer wants to put all the details of the upcoming brand into this application

At this point, not only do you need to deal with the new brand of services, but you also have to rebuild the entire system and deploy accordingly. To avoid such challenges, developers decided to transform their applications from monolithic architectures to microservices

Developers create separate microservices for search, recommendation, customer service, etc.

This micro-service architecture can not only help developers overcome all the challenges faced by previous architectures, but also easily build, deploy and extend shopping cart applications

Microservice example 2

Take the tourism industry application as an example

The overall service includes passenger relationship management, payment, news notification and other services.

Traditional monomers often adopt the integral architecture shown above and adopt the design pattern of MVC.

The details of the three-tier architecture (MVC) are as follows

Presentation layer (view): the parts that users see, hear, input, or interact with when using an application.

Business logic layer (controller): the part that performs logical calculations or business processing based on the information entered by the user.

Data access layer (model): focuses on parts that effectively manipulate raw data, such as storing data to storage media (such as databases, file systems) and

Reading data from the storage medium, etc.

Although the program is now divided into three layers, it is only a logical layer, not a physical layer. That is, for different layers of code, after compilation, packaging, and deployment, all the code ends up running in the same process.

The single architecture works well when the scale is relatively small, but with the expansion of the scale of the system, it exposes more and more problems, mainly as follows:

Complexity is getting higher and higher.

For example, some projects have hundreds of thousands of lines of code, and the differences between the modules are vague and the logic is confused. the more code, the higher the complexity, the more difficult it is to solve the problems encountered.

Technical debt is gradually rising.

The turnover of personnel in the company is perfectly normal. Some employees neglect the self-control of code quality before leaving, resulting in many pits left behind. Due to the astonishing amount of code of a single project, the pits left behind are difficult to be found. This brings a lot of trouble to the new employees. The greater the turnover, the more holes are left, that is, the so-called technical debt is more and more.

High maintenance cost

When the functions of the application become more and more and the team becomes larger and larger, the communication cost and management cost increase significantly. When bug appears, there are more and more combinations of reasons that may cause bug, resulting in an increase in the cost of analysis, location and repair, and in the absence of in-depth understanding of global functions, it is easy to introduce new bug when repairing bug.

Long continuous delivery cycle

Build and deployment time increases with the increase in functionality, and any minor modification triggers the deployment pipeline. Long training period for new recruits: new members spend more and more time knowing the background, business and configuration environment

High cost of technology selection

Monolithic architecture tends to adopt a unified technical platform or solution to solve all problems, and if you want to introduce new technologies or frameworks later, the costs and risks are high.

Poor scalability

With the increase of functionality, the cost of vertical scaling will become higher and higher, while for horizontal scaling, because all the code runs in the same process, there is no way to extend independently for some of the functions of the application.

Micro-service architecture

Transform the overall architecture above into the micro services shown in the figure above.

Different clients from different devices try to use different services, such as search, build, configuration, and other management functions

All services are separated according to their functions and further separated into a single microservice

These microservices have their own load balancing and execution environment to perform their functions and capture data in their own databases

Microservices communicate with each other through stateless servers (REST, GRPC, or message bus)

Microservices use service discovery to understand their communication paths and perform operational functions such as automation, monitoring and so on.

All functions performed by the microservice are communicated to the client through the API gateway

Characteristics of micro service

Decoupling

The services in the system are decoupled to a large extent. As a result, the entire application can be easily built, changed, and extended

Componentization

Micro services are treated as independent components and can be easily replaced and upgraded

Focus on business function

Business functions-microservices are very simple and focus on a single function

stand on one's own

Developers and teams can work independently of each other, increasing speed

Continuous delivery

Allow frequent software releases through automated build, testing, and deployment

Decentralized governance

The point is to use the right tools to do the right job. This means that there is no standardized model or any technical model. Developers are free to choose the most useful tools to solve their problems

Agile development

Micro services support agile development. Any new feature can be quickly developed and discarded

Advantages of microservices

Single responsibility

Each service in the micro-service architecture is a unit with business logic, which accords with the principles of high cohesion, low coupling and single responsibility. different services are flexibly combined in a "pipeline" way to build a huge system.

Lightweight communication

Services are interconnected through lightweight communication mechanisms, while the so-called lightweight usually refers to language-independent and platform-independent interactions.

For the format of lightweight communication, we are familiar with XML and JSON, which are language-independent and platform-independent; for communication protocols, they are usually based on HTTP, which makes the communication between services standardized and stateless. At present, the familiar REST (Representational StateTransfer) and GRPC is one of the lightweight communication mechanisms to realize the cooperation between services. Using lightweight communication mechanisms, teams can choose a more appropriate language, tool, or platform to develop the service itself.

Improve fault tolerance (fault isolation). Memory leaks from one service will not paralyze the entire system.

Independence.

Service independent testing, deployment, upgrade, release

In a single-block architecture, all functions are in the same code base, and the development of the function is not independent; when different teams complete multiple functions, they need to undergo integration and regression testing, and the testing process is not independent; when the test is completed, the application is built into a package, and if a function exists in bug, it will cause the entire deployment to fail or roll back.

With the application of new technology, the system will not be limited to a certain technology stack for a long time.

New business scenarios can be flexibly combined according to market demand.

Reduce code coupling

The service instance level expands, the service single responsibility, the function is independent. Ensure reliability and performance and improve resource utilization

Because the micro-service is business function-oriented, it will not be disturbed by the application. The administrator of the micro-service can configure the micro-service to different computing resources according to the needs of the computing resources, or build a new computing resource and configure it.

Improve development communication, each service is sufficiently cohesive, small enough to make the code easy to understand

Process isolation, fault isolation

In the monolithic architecture, the whole system runs in the same process. When the application is deployed, the currently running application must be stopped, and the process must be restarted after the deployment is completed. It is impossible to deploy independently. Sometimes we extract the duplicate code and package it into components. In the monolithic architecture, the component is usually called a shared library (such as jar package or DLL), but when the program is running All components will eventually be loaded and run in the same process.

In the micro-service architecture, the application consists of multiple services, each of which is a highly autonomous independent business entity that can run in separate processes, and different services can be easily deployed to different hosts.

Even if a service of the application does not work, the system can continue to run

Data partition, data independence, reliability guarantee

Disadvantages of microservices

Micro-service increases the complexity of the system.

Developers have to deal with the complexity of distributed systems

Distributed transaction between services

Registration and Discovery of Services

Report processing problems after data isolation

Difficulties in managing different service instances and requirements for continuous automated deployment

Higher requirements for operation and maintenance

For a single architecture, we only need to maintain this project, but for a micro-service architecture, because the project is made up of multiple micro-services, problems with each module will cause abnormal operation of the whole project. It is often not easy to know which module is causing the problem, because we cannot track it step by step through debug. This puts forward high requirements for operation and maintenance personnel.

Distributed complexity

For a single architecture, we do not have to use distribution, but for a micro-service architecture, distribution is an almost inevitable technology. Because of the complexity of distribution itself, the micro-service architecture becomes more complex.

High cost of interface adjustment

For example, the user micro-service is called by the order micro-service and the movie micro-service. Once the interface of the user's micro-service changes greatly, then all the micro-services that depend on it have to be adjusted accordingly. Because there may be a lot of micro-services, then the cost of adjusting the interface will be significantly increased.

Communication and event broadcasting of micro-services

The planning of microservices is very different from that of monolithic applications, in which each service needs to avoid being implicated with other services, be autonomous and undisturbed when other services go wrong.

If there is communication, asynchronous communication should also be used to avoid close dependency problems. This can be achieved in the following two ways:

Event Storage Center (Event Store)

This allows you to broadcast events in the service cluster and monitor and handle them in each service, so that there is no close dependency between services, and these events are stored in the event storage center. This means that all events can be replayed (Replay) when the microservice is back online and deployed. As a result, the database of micro-service can be deleted and destroyed at any time, and there is no need to obtain data from other services.

Message queuing (Message Queue)

The ability to broadcast messages in a service cluster and deliver them to each service

Well-known message middleware such as NSQ, RabbitMQ, Nats, Kafka

A service broadcasts an event that can be accompanied by some data. The B service can listen for this event and handle it after receiving it. These processes are handled asynchronously.

A service does not need to wait until B service has finished processing the event, which means that A service cannot obtain the processing result of B service.

Unlike the event storage center, message queuing does not save events. Once the event is digested (received), it disappears from the queue.

Service discovery

When a single microservice is launched, it registers its IP location and service content with the service registry.

When the service needs to invoke another service, it will ask the service discovery center for the IP location of the service, and after getting the location, it can directly initiate the call to the target service.

The intention is to centralize the location of all services so that they will not be scattered among each micro-service.

The Service Discovery Center can conduct health checks on microservices at regular intervals (TCP calls, HTTP calls, Ping).

If the service does not respond within time, remove it from the service center to prevent other microservices from invoking an unresponsive service

Even if microservices are redeployed on other ip, other services are not aware

The more commonly used service discovery is: etcd,consul, which generally adopts distributed algorithms such as raft.

Other factors to be considered in micro-service

Network delay

Distributed transaction

Current limit

For example, after a service is hung up, the upstream service or user will habitually retry the access. As a result, as soon as the service returns to normal, it is likely to die immediately because of excessive network traffic.

Therefore, the service needs to be able to protect itself-- current limit. There are many current-limiting strategies, the simplest of which is to discard redundant requests when there are too many requests per unit time. In addition, zoning current restriction can also be considered. Deny only requests from services that generate a large number of requests

Fuse break

When a service stops responding for various reasons, the caller usually waits for a period of time and then times out or receives an error return

If the calling link is long, it may cause requests to pile up, and the whole link takes up a lot of resources and has been waiting for the downstream response. Therefore, when multiple access to a service fails, the circuit breaker should be used to mark that the service has stopped working and return an error directly. Re-establish the connection until the service returns to normal

Service degradation

When Service A calls Service B and the failure reaches a certain threshold many times, Service A will no longer call Service B, but will execute the local degradation method.

To downgrade a service is to sacrifice some logical processing or stop requests that depend on the service. To ensure that services can provide key capabilities

Authority control

API Gateway

Distributed tracking

Distributed logging

Configuration center

This is the end of the Guanwei service. I hope the above content can be helpful to you and learn more knowledge. If you like this article, you might as well share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.