SpringCloud-based Microservices Architecture Practical Case - Architecture Disassembly

It has been almost half a year since the first " SpringCloud-based Microservices Architecture Practical Case - Preface " was published, and it has not been split. Just like reading this book, it also needs an opportunity, but it is still unfinished. After the work is completed, although it is not a classic application, it is necessary to disassemble the formation process of simplemall to facilitate the understanding of this case.

There is no unified standard in the industry for how detailed the service splitting is. Of course, it cannot be split for the sake of splitting, but also depends on the application of specific business scenarios. Friends who have read "Taobao Technology This Decade" believe that Taobao's technological evolution has a very intuitive feeling. Although the concept of microservices was not as hot as it is today, it has actually been running in production environments.

The business background of the simplemall project is based on a simple shopping scenario, which is a common e-commerce business. Realizing a complete e-commerce business process is very complex and huge. In this project, only five basic basic services are split, namely, user module, order module, payment module, product module, and message module. In actual business applications, it may be dismantled in more detail. For example, products and services can also be subdivided into inventory, promotion, price, product classification, recommendation, etc. This project is only presented with the simplest services to achieve a simple understanding and use. The purpose of spring cloud components.

All modules are based on SpringBoot and use maven for project management.

The project structure diagram is as follows:

Basic business services are divided into:

account-service user subservice
product-service product sub-service
payment-service payment sub-service
order-service order sub-service
msg-service message subservice
front-app business front-end display

Each business service has its own separate DB, the data storage is based on mysql 5.6+, and the basic initialization script is stored under the sql folder, which can be executed directly. The configuration of each service connection db is subject to the local configuration.

Basic support services are divided into:

admin-server service monitoring
conf-server configuration center
eureka-server service registry
hystrix-dashborad service fuse monitoring panel
sleuth-server link tracking monitoring
turbine-server service fuse collection monitoring
zuul-server gateway server
common-module base module

The required service is eureka-server, which is used for service registration and discovery. The rest of the basic service modules are gradually evolved and optimized.

The common-module module stores the connection configuration of redis and the entities of related modules. A friend asked why entities are stored in the common module. This approach has advantages and disadvantages. The advantage is that all submodules directly depend on this common module, and can get all module-related entities and interfaces. The disadvantage is that when the number of services increases, there are many Java classes, and a lot of irrelevant code will be introduced. In a common practice, there is an independent api module in each sub-service module to store entities and external api interfaces. As shown below:

In a subsection: This article introduces the code structure of the simplemall project, focusing on the storage of the entity and interface code of the sub-service, and then goes into the specific modules for a detailed introduction.

Source address: https://github.com/backkoms/simplemall

SpringCloud-based Microservices Architecture Practical Case - Architecture Disassembly

Guess you like