Microservice Development Series: The Beginning

1 opening

Microservices are now a concept familiar to most developers.

Various microservice development series emerge in an endless stream on the Internet, and various microservice frameworks are also numerous.

However, at such a time when it seems that there is no need to introduce microservices, I still want to give a series of my understanding of microservice development.

These understandings are not esoteric, these practices you may be doing every day, and some places you may think are very basic.

But in my understanding, these are very important, and there are no fancy ways of implementation. The purpose of technology is not to achieve simple purposes with cumbersome methods, but to achieve all purposes with simple methods.

Therefore, the framework I want to introduce is all for convenience, easy investigation, easy deployment, and easy development. It is just a convenient system.

These simple techniques and simple practices not only provide beneficial design methods for microservice frameworks, but also help some developers in their development habits and understanding of development.

2 Source address

great-microservice-gradle-kotlin

The source code of the above project is built and continuously improved by the author himself, and all subsequent "Microservice Framework Series" are written based on this.

The source code is developed using kotlin, but can be seamlessly converted to java.

I will write a separate article on why I use kotlin later.

3 System structure

This is a microservice architecture based on gradle.

 \--- server
    +---framework
    +---gateway
    \---business
        +---business-foundation
        +---business-web

The project with sub-nodes is a management project without code, which manages the construction and dependencies of the following sub-projects.

4 The role of each module

4.1 server

The top-level project in the entire microservice architecture does not contain any code itself and is the top-level project of all projects.

Has the following functions:

1. Dependency versions required for managing projects
2. 定义了所有项目必须拥有的依赖，比如所有项目都需要依赖framework ， hutool ， spring-security ， spring-cloud ， spring-admin-client ， spring-redisson ， spring-alibaba-nacos-config ， spring-alibaba-nacos-discovery ， caffeine
3. Define the files that need to be included or excluded from the package
4. Define how individual projects are built
5. gradle dependency repository
6. Dependent gradle plugins
7. Set some other common parameters

4.2 server:framework

The basic module, all modules in the project need to depend on this module, which has been set in server and has the following functions:

1. All projects need to use classes and beans autoloaded by spring boot starter in common.
2. Including the common classes used by the project in the http request
3. jackson package
4. redisson serialization configuration based on jackson
5. Spring data unified serialization

4.3 server:gateway

The gateway module, which acts like nginx, has the following functions:

1. gateway forwarding
2. Cross domain settings
3. spring security authentication, verification code
4. Intercept printing of content in request response
5. Global request log printing and collection
6. Add cost time-consuming monitoring to the response of all requests,
7. Add the request-id request unique id to the response of all requests, and pass it to the downstream, which can track the log downstream
8. knif4j swagger service center

There are some functional projects that need to be done when they reach a certain scale, but they have not been implemented yet.

1. request throttling
2. fuse

This module uses webflux, the web framework used by spring cloud gateway, which is different from traditional servlet.

4.4 server: business

The business module is a small top-level module that can control the dependencies and construction methods of all business modules, because most of the same functions in the system have been defined by server , so this module does not need to be If you do too much configuration, you only need to focus on the dependencies or configurations related to the following sub-business modules.

4.5 server:business:business-foundation

It is a business basic module that is similar to framework but only serves the business module. With the development of the system, it can continuously expand its functions. For example, a component needs to be set by all business modules, then it can be set in this Under the module, make a unified configuration.

Features currently available:

1. Provide business classes that all business modules need to depend on together, such as business objects and RPC remote calling interface classes. The principle of expansion is

   1. The shared code range must be limited to business
   2. Code sharing scope must be at least two or more projects
   3. Strip the business logic as much as possible, and don’t put the code that should have been placed in the business module here without thinking
2. spring mvc security, cross domain, log, global exception, http session configuration
3. Some business common parameters such as encapsulated paging parameter object, paging result object
4. mybatis plus configuration

4.6 server:business:business-web

The core business module of a system. This type of module provides the system with business capabilities and is the module that interacts with the external environment the most. This type of module can be divided into multiple modules. When the business is too complex, it can be considered to be separated and reduced by one. The complexity of the module.

However, when it is split into multiple pieces, it is necessary to consider how to design the connection between each business module, including but not limited to the following issues:

1. How to split the common business class
2. How services between systems call each other
3. How to design the use of fegin

These issues should not only be considered before development, but also must be constantly considered in the process of development and changing requirements, so as to be able to quickly adapt to new development methods.

Compared with thinking about the upper layer, development is the easiest thing. As long as the upper layer structure is defined, stripping and merging are very convenient things.

This microservice framework is designed in this way to gain as much flexibility as possible in small and medium-sized systems.

5 Third-party services used in the architecture

When using some third-party services in the architecture, you should carefully consider what impact the introduced services will bring. During the application process, you should constantly consider the advantages and disadvantages of the services themselves.

How to use third-party services is reasonable and correct. When I use the following services, I will have some problems more or less. Constantly running in and finding suitable solutions is a process of continuous improvement .

The third-party services referenced in the system are as follows. The following chapters will explain in detail why some services are used in this way, and more importantly, why they should not be used in this way .

5.1 mysql

The currently used orm is mybatis plus. Although mp is easy to use, it needs to have some restrictions, which will be introduced later.

5.2 redis

The client used is redisson, and the serialization of redisson will be introduced later.

5.3 Nacos

As a registry and configuration center, it functions well, but there are some problems and additional configuration.

5.4 elasticsearch

Use the native RestHighLevelClient, spring data .

There are two main reasons for not using spring data

1. The version upgrade of elasticsearch is too fast, and spring data can't keep up with the rhythm
2. The use of spring data requires three versions to be consistent, the version of spring data itself, the version of spring boot, and the version of elasticsearch, the use conditions are too harsh

6 Summary

In this microservice architecture, the structure of the entire project is designed from the top to the bottom, using some available features as much as possible, and stripping all the code that is not related to the business in the project, so that all modules can enjoy in one The advantages in the overall structure, clarify the respective functions of each module, and find the positioning of its own module.

These functions are not the only constants. Each system can adjust the structure according to its own actual situation. The architecture is not static and can be changed according to the actual situation, but try to follow the principle of maximum decoupling, and Consider the impact of changes in any case to facilitate developer development while maintaining the stability of the framework itself.

This framework is only suitable for some medium-sized systems, and the volume of medium-sized systems will not be too large. If there are a dozen or even dozens of modules in this architecture, it is necessary to consider whether this architecture is suitable. It may be necessary to When a more suitable architecture is developed, multiple medium-sized projects may cooperate with each other, and there may even be a gateway module closely integrated with the business.

It is also not suitable for some small projects, because there is no need to simply develop some business functions, and then it is difficult to complete all functions with a single spring boot in the case of expansion.

So no framework is unique and can solve any problem.

This series of articles is to be able to describe an ideal framework, how to fight against the unreasonable aspects of various services in the process of continuous thinking, to run in with various development habits, and how to make compromises, The process of continuous evolution can help more developers to deepen their understanding of the framework, and can make reasonable choices with ease when facing any third-party service.

This article participated in the Sifu technical essay , and you are welcome to join.