Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to correctly implement SOA in microservices. The content of the article is of high quality, so the editor will share it with you for reference. I hope you will have some understanding of the relevant knowledge after reading this article.

The ability to build, develop, and scale large applications is critical for an organization, but the challenges involved make it a daunting task. Because of this, microservices have become the main model for building modern cloud applications by being able to split individual components into independent services around specific business functions.

Micro-service architecture is a distributed system approach that promotes the use of fine-grained services with their own lifecycles. Because microservices are mainly modeled around a single business process / function, they avoid the problems of traditional hierarchical (multi-tier / n-tier) architectures such as single applications. Microservices also integrate technologies and emerging technologies that have emerged in the past decade, thus avoiding many of the shortcomings of service-oriented architecture implementation.

While using microservices has many benefits in making large applications easier to manage, building a reliable distributed system is challenging in any case because there are many factors to consider in dealing with failures, consistency, and performance.

Below, the implementation path of the micro-service architecture is introduced in detail, and the advantages and disadvantages of the model are analyzed. At the same time, it discusses the best way to help developers and application architects achieve their application goals.

About Domain SOA: service-oriented Architecture

Service-oriented architecture (SOA) is a method that can deploy, combine and use loosely coupled coarse-grained application components distributed through the network according to the requirements. Each service will achieve predefined business goals and perform separate units of work. These services are independent and do not depend on the context or state of other services. They work in a distributed system architecture.

In some ways, the SOA architecture is the evolution of distributed technologies (COM and CORBA). Similar to these, SOA emphasizes strict contracts between services and consumers (WSDL) and other aspects of specific service discovery (UDDI), transport (SOAP), mediation (WS-mediation), routing (WS- addressing), security (WS-security, WS-trust, WS- secure conversation, etc.), and distributed computing. In addition, SOA emphasizes service design, development, and operational governance through enterprise repositories, service lifecycle management, and service level monitoring tools

1 Introduction

Microservice is an architectural style. It is a way to develop a single application into a set of small services, each running its own process and communicating with lightweight mechanisms, usually HTTP API. These services are built around business functions and can be deployed independently.

The microservice model has significant benefits, especially in supporting agile development and delivery of complex enterprise applications.

The microservice architecture pattern decomposes the application into manageable blocks to achieve the execution module level, which in practice is extremely difficult to achieve through a single code base. As a result, individual services are developed faster and easier to understand and maintain.

In addition, this approach is more inclined to lightweight message bus. To put it simply, applications built on microservices are designed to be decoupled and aggregated as much as possible. They have their own single domain logic and act more as filters-- receiving requests, applying logic appropriately as needed, and generating responses.

The nature of micro-service architecture is not new, and the concept of distributed system has existed for a long time. The micro-service architecture is also similar to SOA. The idea behind microservices is to build large, complex, long-standing applications that evolve into a unified (organized or interconnected) set of services over time. The term "microservice" strongly indicates that services should be small.

However, while it is desirable to have small services, this should not be the primary goal. Instead, your goal should be to break down the system into services to solve development and deployment problems. Some services may indeed be small, while others may be quite large.

The evolution of applications

Single-tier application

In the early development process, the application was developed and deployed as a single entity. These single-tier applications are easy to deploy because they have only one code base and deployment configuration.

Scalability is a huge challenge for such an application because it can only be achieved by copying the entire application. This will directly increase the cost of the enterprise and cause a waste of resources with the increase of traffic and load.

Multi-layer (or n-tier)

The disadvantage of single-tier / holistic application leads to the emergence of multi-tier architecture. This new architecture decomposes the application into logical distribution layers, thus achieving efficient scalability. This approach usually separates the presentation layer, the data layer, and the business logic layer. Therefore, the extension method is applied to these layers alone, not to the application as a whole.

However, as the number of applications built using this pattern grows, it creates strain at the business logic layer and leads to many shortcomings of the single architecture. Similarly, as a single entity, scalability is challenging and costly.

Service oriented Architecture (SOA)

In the evolution of SOA, the idea is to realize the vision of the application as a business function.

As more and more enterprises move towards automation / digitization, IT has become the backbone of the business because it serves the rapidly changing business needs. These rapidly changing business requirements have led developers to think of their applications as a collection of business functions, so isolating components is more appropriate for their purpose than where they are on the stack. For example, developers can create a user service that handles user authentication, billing order services, or e-mail notifications because each service is smaller and more centralized, which provides more efficient scalability.

While this pattern provides a framework for building an effective application architecture, its practice is often ineffective because of unnecessary complex abstractions and legacy protocols. Developers will try to use SOA to connect a wide range of applications, all in different languages, requiring additional layers for the enterprise service bus. This leads to outdated and expensive configurations, unable to keep up with the development of technology and business environment.

2 Microservices--Artefacts

Why is it microservice-the new model?

The development of IT has greatly changed the prospects of global business. In the early days, IT was seen as a helping hand for businesses / organizations to reduce the manual work of business functions / units.

Today, IT is being used to transform the business and generate more revenue. So now IT is not just a supporting function, but a major business function.

"in order to respond quickly to the rapidly changing needs of digital services and scale systems, computing must move from static to dynamic," Gartner said in its top 10 strategic technology trends in 2015. Rules, patterns, and code can be dynamically assembled through applications, as well as all the elements needed to configure the network. "

This change of thinking in the application architecture has also brought about a change in practice. Gartner's further predictions indicate that "for many organizations, the first step towards the future of Web-Scale IT should be DevOps-combining development and operations in a coordinated manner to promote rapid and continuous incremental development of application services."

Using Web-Scale IT, enterprises can more easily build applications and infrastructure similar to those provided by Amazon, Google, and Facebook. Web-Scale IT enables enterprises to further embrace the cloud in their IT settings, providing internal users with the capabilities of large service providers.

Differentiate from SOA

The micro-service pattern is clearer than SOA in defining features and provides a framework that meets the architectural requirements of modern applications. Microservices are often referred to as: properly implemented SOA.

SOA focuses on independent technical systems, while microservices focuses on independent business systems.

The goal of the micro-service model is not to connect various applications together, but to create a single, aggregated application composed of independently developed and independently deployed services, each of which follows the principle of single responsibility. However, the expression "micro" can be a bit deceptive about the characteristics of microservices, because size is not a feature of microservice definitions. Although microservices are usually small, it is more important that each service's own encapsulated process can be developed and deployed independently. By limiting the scope of what a service can do, developers ensure that those services do not inadvertently end up with many decoupled monomers.

As with modern clouds, communication between services is done through REST-based API, through HTTP, passing JSON data, usually through message queues to ensure reliability. A single microservice is usually handled asynchronously, triggered by events such as API calls, push queues, scheduling, or webhook. A lightweight and efficient framework around communication and processing that further distinguishes microservices from SOA.

Decompose an application into multiple services

There are also some other architectural styles that can be extended. The Art of scalability describes a very useful 3D scalability model: Scale Cube, as shown in the following figure.

In this model, the way to scale an application by running multiple copies of the application after the load balancer is called X-axis scaling. This is a good way to increase application capacity and availability.

When using Z-axis contraction, each server runs the same copy of the code. In this respect, it is similar to X-axis scaling. The biggest difference is that each server is responsible for only a subset of the data. Like X-axis scaling, Z-axis contraction increases application capacity and availability.

However, neither approach can solve the problem of increased development and application complexity.

In order to solve these problems, we need to apply Y-axis scaling.

Z-axis scaling splits similar services, while Y-axis scaling splits different services. At the application layer, Y-axis scaling splits an overall application into a set of services.

Each service implements a series of related functions, such as order management, customer management and so on.

As a pattern, microservices improve the scalability of the Y-axis by decomposing functional elements into individual services, rather than through traditional replication.

Ideally, each service should have only a small portion of responsibilities. SRP (single responsibility principle) defines the responsibility of a class as the reason that needs to be changed, and the class should have only one reason to change. It also makes sense to apply SRP to service design.

Micro-service architecture-communication mechanism

In the micro-service architecture, the communication mode between the client and the application and between the application components is different from that of the single application. Let's first look at how the application client interacts with the microservice. After that, we will examine the communication mechanism in the application.

Call directly

Application clients, such as native mobile applications, can issue REST-based HTTP requests for individual services, as shown in the following figure.

API of a single service

There may be a significant granularity mismatch between the granularity and the data required by the client.

For example, displaying a Web page may require calling a large number of services. For example, Amazon.com describes how some pages need to invoke more than 100 services. Even if so many requests are made on high-speed Internet connections, not to mention low-bandwidth, high-latency mobile networks, this will be very inefficient and lead to a poor user experience.

API gateway mode

This is a better approach because the client will make a small number of requests per page, perhaps only one request, to the front-end server called the API gateway on the network.

The API gateway is located between the application client and the micro-service, and it provides an API tailored to the client. The API gateway provides coarse-grained API for mobile clients and fine-grained API for desktop clients using high-performance networks. In this example, the desktop client makes multiple requests to retrieve information about the product, while the mobile client issues a single request.

The API gateway processes incoming requests by making requests to some microservices on a high-performance LAN. In this example, fine-grained requests from desktop clients are simply proxied to the corresponding services, while each coarse-grained request from a mobile client is processed by aggregating the results of invoking multiple services.

3 Advantages of Microservices

The separation of components provides a more efficient environment for building and maintaining highly scalable requirements. Smaller services that are independently developed and deployed are easier to maintain, repair, and update, providing more agile capabilities in response to today's changing environment.

Modularization

Microservices are based on services; each service has its own boundaries, and you can't simply bypass them so that you can develop, deploy, and extend services independently.

Service-specific database

Microservices are loosely coupled and have their own databases, so services do not block other services by holding database locks.

Fault isolation

The microservice architecture has better fault isolation; problems with one service will not affect other services, and other services will continue to work normally.

Scalability

Expansion in the level of personal services has become more cost-effective and on demand. You can process individual tasks concurrently without affecting the rest of the application.

Separating the components of the application reduces the likelihood that a single error or hardware failure will paralyze the entire system (eliminating a single point of failure). Failed processes can be quarantined and can exit the endpoint until they arrive.

Technical / language flexibility

Each individual service can be based on the developer's preferences, task applicability, or a different language that matches a library.

In addition, the following are the main advantages of microservices:

The microservice architecture allows developers the freedom to develop and deploy services independently.

Small teams can develop micro-services.

Code for different services can be written in different languages.

Easy to integrate and deploy automatically (using open source continuous integration tools such as Jenkins, Hudson, etc.).

Developers who are easy to understand and modify, which can help a new team become efficient and fast.

Api can be versioned more effectively because individual services can follow their own scenarios. Major versions can be executed at the application level, while services can be updated as needed.

By separating the components of the application, it is less likely that a single error or hardware failure will paralyze the entire system. Failed processes can be isolated, and downward endpoints can be retired until they arrive (eliminate a single point of failure).

Developers can use the latest technology.

Code around business functions.

It is faster to start the web container, so it is faster to deploy.

When a part of the application needs to be changed, only the related services can be modified and redeployed-- there is no need to modify and redeploy the entire application.

Better fault isolation: if one microservice fails, the other will continue to work (although a problem area of an overall application may endanger the entire system).

Easy to extend and integrate with third-party services.

There is no long-term commitment to the technology stack.

4 Drawbacks of Microservices

Separating the application into separate services means that there are now more active components to maintain. This also brings some challenges.

Complex business processes

While one of the main advantages of microservices is streamlined orchestration capabilities, more services mean maintaining more deployment flows. DevOps plays a more important role in this pattern because each service must be configured correctly throughout its lifecycle.

Inter-service communication

Separate services require a reliable and efficient way to communicate without slowing down the entire application. Delivering data over the network can cause delays and potential failures, which can affect the user experience. A common approach is to introduce message queuing as a reliable transport layer.

test

While keeping code and dependencies tight means providing a simpler development environment for specific services, it does pose testing challenges related to the entire application. Services usually need to communicate with each other or rely on data sources or API. Testing a service independently will require a complete test environment to be effective.

Micro-service architecture brings a lot of operational overhead.

DevOps skills are required.

Distributed systems are complex to manage.

Due to distributed deployment, tracking problems by default. With the increase of the number of services, the management of the whole product becomes more and more complex.

5 conclusion

Monolithic applications are common patterns for building enterprise applications. It works fairly well in small applications: it is relatively easy to develop, test, and deploy small monolithic applications.

However, for large, complex applications, a single-block architecture becomes an obstacle to development and deployment. Continuous delivery is difficult to achieve, and you are often permanently locked in your initial technology choices. For large applications, it makes more sense to use a micro-service architecture that decomposes the application into s-group services.

Micro-service architecture has many advantages. For example, a single service is easier to understand and can be developed and deployed independently of other services. It is also much easier to use new languages and frameworks because you can try new technologies for one service at a time.

The micro-service architecture also has some obvious flaws. In particular, the application is much more complex and has more active parts. You need a high degree of automation, such as PaaS, to use microservices effectively.

When developing micro-services, we also need to deal with some complex distributed data management problems. Despite these shortcomings, the microservices architecture makes sense for fast-growing large and complex applications, especially SaaS-style applications.

There are many strategies that can gradually evolve an existing monolithic application into a micro-service architecture. Developers should implement the new functionality as a separate service and write glue code to integrate the service with the monomer.

It also makes sense to iteratively identify components to extract from the whole and transform them into services. Although this improvement is not easy, it is better than developing and maintaining a bulky, monolithic application.

This is the end of the SOA on how to implement microservices correctly. I hope the above content can be of some help to you and learn more knowledge. If you think the article is good, you can 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.