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

Evolution of microservices architecture

The technical system and community of microservice architecture are becoming more and more mature. In the initial system architecture construction, or when the existing architecture has reached the bottleneck and needs to be evolved, many architects and operation engineers will consider whether to build a microservice architecture system. Although many articles say that microservices architecture is complex and brings many distributed problems, once we understand these problems and find solutions, there will be a sense of clearing the clouds. Before sharing, I still want to recommend the big data learning exchange I created myself Qun: 710219868 Enter Qun Chat Invitation Code Fill in Nanfeng (required) I will know it is you

Microservice architecture is not perfect, there is no perfect architecture in the world, microservice architecture is also evolving with the growth of business and team. At the beginning, there may be several or more than a dozen microservices, each of which is divided into libraries, and service data is merged and forwarded in parallel through API Gateway. As the business expands, search engines, cache technology, distributed message queues, data replication, partitioning, and sub-tables of the data storage layer are added.

Microservice is a distributed architecture that is loosely coupled between services, highly autonomous between each service, and communicates using lightweight protocols for sustainable integration deployment. What is the difference between microservices architecture and other architectures? The following is a comparison of some common architectures.

monolithic architecture

Monolithic architecture is the simplest software architecture and is commonly used in traditional application software development as well as traditional Web applications. Traditional Web applications generally deploy and run all functional modules packaged (jar, war) in a Web container (JBoss, Tomcate). As business complexity increases and technical team size expands, maintaining code in a single application will reduce development efficiency. Even if it is to handle a small requirement, it is necessary to deploy all applications on all machines once, increasing the complexity of operation and maintenance.

SOA architecture

When one day it is difficult to promote the development of demand and accumulated technical debt using single architecture, many enterprises will start to split single services, which generally includes horizontal split and vertical split. Vertical split is to split an application into multiple independent applications that are loosely coupled, so that applications can be deployed independently and maintained by independent teams; horizontal split is to split some common modules that will be called by many upper services independently to form a shared basic service. This split can optimize and operate some performance bottleneck applications separately, and also to a certain extent prevent duplication of vertical split.

SOA is also called service-oriented architecture. The evolution from single service to SOA requires a combination of horizontal and vertical decomposition. SOA emphasizes the use of unified protocols for communication between services, services run on independent hardware platforms but need to cooperate with each other through unified protocol interfaces, that is, application systems are service-oriented. For an easy example, if a single service is equivalent to a fast food restaurant, all the waiters have the same responsibilities. They are also responsible for cashier settlement, hamburger making, plate serving and cleaning. There is no need for communication between waiters. After the user comes, the waiters are responsible from front to back. SOA is equivalent to giving waiters a division of responsibilities, cashiers are responsible for cashier, cooks are responsible for hamburgers, aunt ×× is responsible for cleaning, etc. All waiters need to communicate in the same language to facilitate work coordination.

Microservices and SOA

Microservice is also a service, but it is also different from the service concept of SOA architecture, which can be understood from the following keywords:

Loose coupling: Each microservice can use DDD (Domain Driven Design) to design the domain model, minimize synchronous calls between services, and use messages to decouple domain events between services.

Lightweight protocols: Dubbo is one of the open source standard implementations of SOA, as are gRPC, Thrift, etc. Microservices tend to use Restful-style APIs, lightweight protocols can support cross-language development services well, some microservices may be implemented in Java language, some in Go language, some in C++, but all languages can support Http protocol communication, all developers can understand the meaning of Restful-style APIs.

High autonomy and continuous integration: From the perspective of the bottom layer, SOA tends to be deployed based on virtual machines or servers, each application is deployed on a different machine, and the general continuous integration tools are more written by the operation and maintenance team and provide development and deployment pages based on common protocols (such as Dubbo management pages). Microservices can be well integrated with container technology, which is later than microservices, but the emergence of container technology makes microservice implementation easier, and Docker has become the basic container for many microservice practices. Because of the nature of containers, dozens or hundreds of different microservices can be deployed on a single machine. If one microservice has higher traffic pressure than others, you can allocate more container instances of that microservice on a single machine without adding machines. At the same time, as Docker's container orchestration community matures, technologies like Mesos, Kubernetes, and Docker's official Swarm can be used as technology options for continuous integration deployments.

In fact, from the perspective of architecture evolution, the overall evolution is towards more and more lightweight and flexible applications, and even to the Serverless (no service) architecture that has matured in the past two years. From monolithic services to layered services, to service-oriented, to microservices, and even to no services, the challenges to architecture are growing.

Distribution in microservices

Is microservices architecture a distributed system? The answer is yes. Both microservices and SOA are typical distributed architectures, except that microservices are more granular in deployment and more flexible in service scaling.

How do you understand distribution in microservices? Give an example of a classmate who came to interview during a recruitment. Student A said that the company is currently doing the work of migrating from single application to microservice architecture, which has almost been completed. When it comes to microservices, I feel that there is a topic to talk about, so I ask: "Can you briefly describe the deployment structure after service splitting, the splitting and migration scheme of the underlying storage?" "So Student A said that he only split the code engineering structure, or the original deployment method, the database or the library, all the microservices use a library, the distributed transaction processing method is" avoid ", try to synchronize calls... so I smiled and said goodbye to this classmate.

The distribution of microservices is not only the distribution of container application level, but also the underlying storage system should be independent of each other in order to be highly autonomous, and not all microservices need persistent storage services. A "mobile phone Captcha" microservice may require only one Redis for underlying storage; a "marketing campaign building page" microservice may require only one MongoDB for underlying storage.

In addition to service discovery and Load Balancer, distributed scenarios in microservices also include distributed scenarios for underlying storage on which microservices depend: replication and partitioning of databases need to be handled for high availability and performance, and microservices need to ensure consistency of distributed transactions in the case of storage partitioning.

How to learn distributed microservices architecture

The technical system and community of microservice architecture are becoming more and more mature, so when choosing to use microservices in the initial stage or transforming the enterprise technical system, you need to understand the distributed problems in microservice architecture:

How do you get better performance when all services are deployed in smaller units and a request requires more service resources?

When the business scale increases and geographically distributed microservice clusters are needed, is the underlying data storage cluster multi-data center or single data cluster? How does data storage replicate data?

How to partition data when business data reaches large volume? How do distributed transactions ensure consistency? What is the difference between different levels of consistency? What about container-based service discovery?

What RPC technologies and distributed message queues should be used to accomplish service communication and decoupling? So many distributed technology frameworks, algorithms, services should choose which is suitable for the business scenario of the enterprise?

"Detailed explanation of distributed microservice architecture system" starts from the distributed problems that microservices have to face and solve, including a series of theories of distributed technology and the introduction of architecture models and algorithms, and at the same time, combining technology selection and practical application, provides a series of solutions. I believe that after reading the entire course, you will have a systematic understanding of the distributed problem of microservices. This course will break down the distributed scenario problems of microservices one by one and provide you with solutions. In addition, this course allows engineers to view the knowledge map of microservices through systematic sorting of distributed problems and comparison and selection of some solutions.

If you are a development engineer, I believe that after reading this series of courses, you will understand a lot of theoretical knowledge of distributed systems, as well as some principles of distributed storage and middleware technologies, and have a clear understanding of the distributed architecture at work.

If you are an architect, this series of courses provides a comprehensive review of distributed system problems, as well as the theory behind some technologies, combined with practice and current industry-advanced solutions, for technology selection and architecture to provide a reference.

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.