Now micro-service development based on SpringCloud is increasingly popular, and various open source projects emerge endlessly on the Internet. In practical work, we can refer to open source projects to achieve many functions out of the box, but we must abide by certain conventions and specifications.

This article combined with our actual development encountered some problems sorted out a micro service development practice specifications, welcome you clap brick advice.

Maven specification

  1. All projects must have a unified parent module

    All microservices projects rely on this parent, which manages dependencies, maven repositories, and JAR versions for unified upgrade maintenance

    Under parent, there can be core, starter, rate-limit and other custom modules

  2. The core package functions as follows:

  • Contract various development specifications in the form of POJOs; For example, BaseEntity, unified input parameter, return parameter
  • Various two-party and three-party components out of the box AutoConfig;
  • All kinds of help to improve the efficiency of development

Note: ConditionalOnClass(Ribbon. Class); ConditionalOnClass(string); ConditionalOnClass(string); @ConditionalOnBean(StringRedisTemplete.class)

  1. The 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 dependency sets, and simplify dependencies

  2. Rate – limit module

    Use to place non-generic, self-developed components

  3. Correctly distinguish between Release and Snapshot versions

    Note: If the Snapshot version is used, it will be automatically published to the Snapshot version library when deployed by MVN. For modules using Snapshot versions, Maven will automatically download the latest Snapshot version from the image server when the package is compiled directly without changing the version number.

    If the module is a Release version, it will be automatically published to the official Release library when deployed by MVN. If the module is a formal version, it will not be downloaded from the image server when compiled and packaged without changing the version number.

    In short:

    Release: official version, buggy can not continue to use this version number

    Snapshot: indicates the Snapshot version. If there are bugs, you can use the same version. The version can be automatically upgraded

Service invocation specification

  1. By introducing SDK calls between services, service consumers need to rely on apis provided by producers to facilitate upgrades with Snapshot
account
	account-api
	account-service
Copy the code

Account-api module to put the consumer needs to use things, API interface, VO, input parameters…

public interface AccountApi {... }Copy the code

Account-service Implements the interface provided by account-API

@RestController
@Log4j2
@API (tags = "user interface ")
@RequiredArgsConstructor(onConstructor = @__(@Autowired))
public class AccountController implements AccountApi {... }Copy the code
  1. The consumer invokes the producer through Feign, directly integrating with the interface provided by the producer and handling the fuses
@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);
        returnaccountClientFallback; }}@Slf4j
public class AccountClientFallback implements AccountClient {
    @Setter
    private Throwable cause;

    @Override
    public ResultData<AccountDTO> getByCode(String accountCode) {
        log.error("Query failed because the interface is abnormal" ,cause);
        AccountDTO account = new AccountDTO();
        account.setAccountCode("000");
        account.setAccountName("Test Feign");
        returnResultData.success(account); }}Copy the code

Restful Design specification

An API is a developer’s UI – just like any other UI, it’s important to make sure the user experience is carefully considered!

The following two formats can be used:

  1. / version/Access control/domain object
  2. / version/Access control/Domain object/Action

A domain object must comply with the following constraints:

  1. Domain objects use nouns instead of verbs
  2. Use domain object names directly using /ticket instead of plural /tickets
  3. The domain object relationship can be expressed at a maximum of two levels, for example, /ticket/12/message
  4. The GET, PUT, POST, and DELETE request methods must be correctly distinguished
  5. What cannot be expressed with a noun + request method can be extended to/domain objects/verbs such as POST /user/login

Access control is implemented on interfaces at the gateway layer. The rules of access control are as follows:

Pb-public All requests are accessible

Pt-protected Access is available only after token authentication

Pv-private is not accessible through the gateway and can only be called internally by microservices

The DF-default gateway requests token authentication, and requests parameters and returned results for encryption and decryption

Version:

With micro service as the strength, the entire service to upgrade

For example, a microservice has the following API

GET /v1/pb/user

POST /v1/pb/user

PUT /v1/pb/user

If the POST, v1, PB, or user needs to be upgraded, upgrade the entire micro-service /v1 to /v2 and ensure that compatible apis of the earlier versions can be accessed

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

POST /v1/ PB /user is marked as obsolete

POST /v2/pb/user

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

Code implementation:

  1. GET {version} can be any value, v1 or v2, for example, @getMapping (“/{version}/pb/user”).
  2. The POST method enforces V1 and marks it deprecated, but it can still be used
@Deprecated
@PostMapping("/v1/pb/user")
Copy the code
  1. POST {version} must be the current version, only V2
@PostMapping("/{version}/pb/user")
Copy the code

The gateway

  1. It can not undertake the function of micro-service authentication and be realized by its own service (simple services can be directly authenticated at the gateway layer). The difference between network authentication and micro-service authentication is described in detail in my other articles, which can be referred to this article: T.H.Y / 2C3
  2. Need to implement access control permissions, combined with the above Restful specification, mask/pv/**And other special requests
  3. The server traffic needs to be imported locally when the gray publishing function needs to be developed and coordinated, and the service instance can be screened by combining the metadata and request headers of NACOS. Refer to this implementation: T.H.Y / 2C6

Seeking praise and attention:

Miao Jam, an architect who writes code and a programmer who does architecture, his public account mainly shares articles on Java backend, SpringCloud micro-service architecture, database and other directions. If you are interested in micro-service, it is suggested to scan the qr code below and add a following!