Explain the choice and practice of microservices architecture in a simple way

Microservice architecture has attracted wide attention due to its advantages of high convenience and extensibility. However, many teams often encounter confusion when choosing microservice architecture.

In TechDay recently held a series of online technical Sharon, push a high platform architecture ShiWuKong teddy boy, a senior infrastructure development engineer with “micro service architecture practice” as the theme, simple to explain the characteristics of the micro service architecture, choice and practical points, share their years of practical experience in the field of deep micro service.

The following is an excerpt of the micro – service special

(Link to the video at the end of the article & PDF download shared by the lecturer)

Micro-service Chatter

This paper mainly introduces microservices from four aspects:

Introduction to Microservices

Advantages and disadvantages of microservices

Supporting facilities for microservices

Microservice options

In 2014, Martin Flowler and his colleagues gave an accurate description of the basic concept of microservices, the core point of which is:

1. It’s a small set of services.

2. It is deployed independently and runs in its own process.

3. Each service is developed independently;

4. Distributed management (decentralization).

The difference between microservices and monomers is that monomers run all business logic in a service process and have been divided into functional modules during development. Microservices, on the other hand, are separated from each functional module and then deployed independently. The microservices architecture is closely focused on the business domain, forming a high degree of cohesive autonomy. Related services can be independently expanded as needed, and the responsibilities are single.

▲ Single architecture (left) vs. microservices architecture (right

Single architecture, also known as “Onion architecture”, has the following advantages: simple structure and easy to understand; Relatively low requirements for developers; Simple and convenient deployment; Efficient operation.

The disadvantages of single architecture are also obvious, such as poor isolation and easy coupling; It is difficult to expand, easy to reach the limit, can not be extended for some high-frequency interface deployment, increasing the test cost; Stability is difficult to guarantee, a problem, the whole service paralysis.

To sum up, the monolithic architecture is suitable for small and medium-sized application development.

▲ Monomer Architecture

Microservices architecture emphasizes “micro”, which can be created and destroyed quickly. They can combine with each other, and they can take apart quickly. The purpose of microservices is to effectively split applications for agile development and deployment. Its main advantages are: reduced complexity; Easy to understand code, improve development efficiency; Good isolation type, easy to expand; Microservices are independent of each other, and a problem will not affect the global service; Easy delivery of a single service, etc.

However, there are some disadvantages: microservices are more technically demanding on the team; High cost of distributed management and communication; Data consistency and performance complexity are high. When the entire link becomes longer, the interface performance deteriorates and upgrade compatibility is complicated.

▲ Microservices Architecture

The main supporting facilities for microservices are service discovery, load balancing, service gateways, distributed configuration, service fuses, and APM service monitoring. Here WE will focus on CI/CD, DevOps, and containerization.

CI/CD: The lack of continuous integration and continuous delivery processes prevents teams from having the agility necessary to support microservices development and delivery. To put it simply, after services are split, there are many services to be developed and tested in parallel. At this time, if there is no automatic process, only manual work is very inefficient, so CI/CD support is needed.

Bring about CI/CD process

DevOps: Literally means operation by development and embodies the concept of agile development.

Containerization: Containerization isolates microserver processes and applications into smaller instances, increasing resource utilization. Containerization and microservice are combined with each other. Containerization of microservice effectively achieves the purpose of lightweight and high efficiency.

There are three main considerations on how to choose microservices:

The first is business complexity. Single architecture is recommended for simple businesses. Microservice architecture can be considered in consideration of rapid business development in the later period.

The second is team size. The management cost of microservices itself is very high, so it is suitable for teams with a certain size.

The third is the accumulation of technology. In the absence of perfect technological accumulation, the hasty use of micro-services will lead to a decline in production efficiency curve that may be more serious than that of single units. Therefore, a special person or team is needed to provide the guarantee of infrastructure at the beginning.

▲ Production efficiency graph of monomer and microservice architecture

The best practices for microservices architecture are summarized as follows:

1. Data is independent and uncoupled. Data of microservices should be independent as far as possible. If all back-end storage is stored in a database and only the front-end business logic is split into different service processes, such microservices without split storage are “pseudo” services.

2. If business permits, try not to use distributed transactions. Because distributed transactions are relatively inefficient and difficult to implement, problems that can be solved at the business level should not be solved by technology.

3. Caching and asynchronization. Issues such as cache penetration and avalanches need to be considered in the cache. Asynchronism can be divided into business and technical levels. On the business level, we need to consider whether we can respond to the end as quickly as possible without making users wait. On the technical level, we can adopt some asynchronous non-blocking technologies, such as coroutines and message queues.

4. Consider fault recovery > Fault avoidance.

5. It is recommended to unify the development language.

In general, micro-service is not a silver bullet that can not solve all problems. It is a method of service separation to achieve efficient and agile implementation when dealing with large and complex application systems. In terms of microservices thinking, technology itself is not a big problem, and awareness is more important than tools.

Architecture Practice of Getuomicro Service Gateway

On the basis of microservice architecture, we further explain the practice of Individual push in microservice gateway architecture, mainly from the role of microservice gateway, design elements, technology selection, concrete implementation of these aspects.

Microservice gateway is a key component of microservice architecture, and its functions are mainly reflected in the following aspects:

1. Provide a unified service entrance. All traffic accessing background services passes through the microservice gateway and is routed through the microservice gateway in a unified manner.

2. Implement identity authentication, permission management, and traffic control for all access to reduce redundant construction.

3. Centralized traffic control, such as link tracing and traffic monitoring, facilitates O&M and troubleshooting.

1. High availability: mature and proven technologies should be selected to support distributed expansion and avoid single point of failure;

2. High performance: no performance problems, should not become the bottleneck of the whole system, traffic to achieve load balancing;

3. Security: To implement identity authentication and authentication for traffic, security filtering can be implemented for requests and traffic limiting is supported.

4. Dynamic routing: as a unified gateway for micro services, traffic can be dynamically routed.

5. Centralized traffic control: supports link tracing, logging, and traffic monitoring.

6. Easy to expand functions: it is convenient to expand functions.

As shown in the figure above, Openresty has four major phases for requests:

1.Initialization Phase

2.Rewrite/Access Phase

3.Content Phase

4.Log Phase

During the Initialization phase, the gateway instance is initialized, and the request processing occurs in six sub-phases of the following three phases:

set_by_lua*

rewrite_by_lua*

access_by_lua*

header_filter_by_lua*

body_filter_by_lua*

log_by_lua*

The specific design refers to the design of Kong and Orange, and is implemented through the mechanism of plug-ins, so that it is convenient to expand the functions of the gateway, and different combinations of plug-ins can be selected according to the traffic characteristics. At the same time, each plug-in can be developed independently without affecting each other.

In the concrete implementation, we take products as the dimension to limit the combination and function order of plug-ins. The traffic requests of each product can only be processed by the combination of fixed plug-ins in a fixed order, as shown in the figure below. We will specify the plug-in and order used by product1 and ProducT2 through the following configuration:

product1={‘rewrite_uri’,’dyups’,’auth’},

product2={‘rewrite_uri’,’dyups_svc’,’zipkin’}

For example, the rewrite_URI plug-in is used to rewrite the URI of the request. The set_by_lua* and rewrite_by_lua* subphases are configured and are responsible for implementing the specific processing logic of each phase.

Each plug-in implements its own filtering rules and logic. For example, the rewrite_URI plug-in configures the following rule:

pattern=[^/api/demo/(\w+)/(\w+)\?(.*)$],

tmpl=’/demo/$1/$2? $3 ‘

Any request that matches a regular expression in pattern will be processed by the plug-in, rewriting it to /demo/$1/$2? In the form of $3.

After such a request reaches the gateway, we can first select the corresponding plug-in combination based on its subordinate products, then filter the matched plug-in according to the filtering rules of each plug-in, and finally process the request according to the configured plug-in sequence.

This design ensures that different products can use different combination of plug-ins, facilitating the extension of gateway functions, while preserving the flexibility of plug-in implementation. Each plug-in can customize its own filtering rules.

The above mainly introduces the architecture design and concrete implementation of the Micro-push service gateway, which is summarized as follows:

1. Microservice gateway plays an important role in microservices and is the unified entrance of microservices;

2. Before the design of micro-service gateway, we confirmed the design elements and functional requirements of micro-service gateway according to our specific business scenarios;

3. For specific technology selection, we refer to mature open source solutions Kong and Orange, combined with our own actual situation;

4. In order to ensure the flexibility and expansibility of the gateway, the architecture adopts the plug-in mechanism and gives each plug-in the freedom to define its own filtering rules.

How to obtain PDF

Follow the wechat official account of [Individual Push Institute of Technology]

(wechat id: Getuitech)

Reply keywords “micro services”

You can receive the full version of the micro service session instructor share PDF!