SpringCloud microservices best development practices

Nowadays, SpringCloud-based microservice development is becoming increasingly popular, and various open source projects on the Internet are emerging in an endless stream. In actual work, we can refer to open source projects to implement many out-of-the-box functions, but we must abide by certain conventions and specifications.

This article combines some of the problems encountered in our actual development to sort out a practice specification for microservice development. Welcome all the big guys to give pointers.

Maven specification

1. All projects must have a unified parent module

   All microservice projects rely on this parent, which is used to manage dependent versions, maven repositories, and jar versions for unified upgrade and maintenance

   There can be custom modules such as core, starter, rate-limit, etc. under the parent

2. The role of core core package:

• Various development specifications are agreed in the form of POJO; such as BaseEntity, unified input and return
• Various two-party and three-party components use AutoConfig out of the box;
• Various help classes to improve development efficiency, etc. XXXUtil

Note: All dependent scopes of the core package must be provided to avoid transitive dependencies. At the same time, use Condition annotations to load Beans conditionally, such as @ConditionalOnClass(Ribbon.class), @ConditionalOnBean(StringRedisTemplete.class)

3. starter module

   If you need to rely on more than 10 starters for each service, you can build a unified starter module to help them unify their dependencies, manage the dependency set, and simplify dependencies

4. rate-limit module

   Used to place non-generic self-developed components

5. Correctly distinguish between Release version and Snapshot version

   Note: If it is Snapshot version , then when mvn deploy , it will be automatically released to snapshot repository , and use snapshot version module without changing the version of 160e72119b97a2. At that time, Maven will automatically download the latest snapshot version from the mirror server.

   If Release version , then mvn Deploy automatically published to official repository , the use official version modules in not change the version number case, the compiler package if local If this version of the module already exists, will not take the initiative to download on the mirror server.

   in short:

   Release: The official version, you can no longer use this version number if there are bugs

   Snapshot: Snapshot version, if there are bugs, you can continue to use the same version number, you can automatically upgrade, recommended

Service call specification

1. By introducing sdk calls between services, service consumers need to rely on the api provided by the producer and cooperate with the snapshot to facilitate upgrades

account
    account-api
    account-service

The account-api module contains things that consumers need to use, api interface, vo, input parameters, etc...

public interface AccountApi {
    ...
}

account-service implements the interface provided by account-api

@RestController
@Log4j2
@Api(tags = "用户接口")
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class AccountController implements AccountApi {
    ...
}

2. The consumer calls the producer through feign, directly integrates the interface provided by the producer and handles the circuit breaker

@Component
@FeignClient(name = "account-service",fallbackFactory = AccountClientFallbackFactory.class)
public interface AccountClient extends AccountApi {
    ...
}

@Component
public class AccountClientFallbackFactory implements FallbackFactory<AccountClient> {

    @Override
    public AccountClient create(Throwable throwable) {
        AccountClientFallback accountClientFallback = new AccountClientFallback();
        accountClientFallback.setCause(throwable);
        return accountClientFallback;
    }

}

@Slf4j
public class AccountClientFallback implements AccountClient {
    @Setter
    private Throwable cause;

    @Override
    public ResultData<AccountDTO> getByCode(String accountCode) {
        log.error("查询失败,接口异常" ,cause);
        AccountDTO account = new AccountDTO();
        account.setAccountCode("000");
        account.setAccountName("测试Feign");
        return ResultData.success(account);
    }

}

Restful design specification

An API is a developer's UI-just like any other UI, it is important to ensure that the user experience is carefully considered!

The following two formats can be used:

1. /Version/Access Control/Domain Object
2. /version/access control/domain objects/action

domain objects need to comply with the following constraints:

1. Use nouns instead of verbs for domain objects
2. Directly use the domain object name to use /ticket instead of plural /tickets
3. The expression of domain object relationship does not exceed 2 levels at most, such as /ticket/12/message
4. Need to distinguish GET PUT POST DELETE request method correctly
5. What cannot be expressed by noun + request method can be expanded to /domain object/verb such as POST /user/login

performs access control on the interface at the gateway layer. The access control rules are divided into:

pb-public All requests can be accessed

pt-protected Requires token authentication to be accessible

pv-private cannot be accessed through the gateway, can only be called internally by the microservice

df-default The gateway requests token authentication, and the request parameters and return results are encrypted and decrypted

version:

Focus on microservices and upgrade the entire service

For example, a microservice has the following API

GET /v1/pb/user

POST /v1/pb/user

PUT /v1/pb/user

If POST /v1/pb/user needs to be upgraded, you need to upgrade the entire microservice /v1 to /v2, while ensuring that the old version of the compatible api can continue to access

GET /v2/pb/user is equivalent to GET /v1/pb/user

POST /v1/pb/user marked as obsolete

POST /v2/pb/user

PUT /v2/pb/user is equivalent to PUT /v1/pb/user

Code:

1. The GET method {version} can be any value, both v1 and v2, such as: @GetMapping("/{version}/pb/user")
2. The POST method forces the use of V1 and marks it as obsolete, but it can still be used

@Deprecated
@PostMapping("/v1/pb/user")

3. POST {version} should be the current version, only v2

@PostMapping("/{version}/pb/user")

Gateway

1. It can be implemented by its own service without assuming the microservice authentication function (simple services can be directly authenticated at the gateway layer)
   authentication is explained in detail in my other articles, please refer to this article: 160e72119b9cb4 http://t.hk.uy/2c3
2. Need to implement access control permissions, combined with the Restful specification above, shield special requests such as /pv/**
3. Need to implement the gray release function
   When developing joint debugging, it is necessary to import server traffic to the local, and combine nacos metadata and request headers to realize the screening of service instances. Refer to this article to achieve: http://t.hk.uy/2c6

Seeking praise Seeking attention:

Misty Jam, an architect who writes code, and a programmer who does architecture. His official account mainly shares articles on Java backend, SpringCloud microservice architecture, database and other directions. If you are interested in microservices, I suggest you scan the following Pay attention to the QR code!