Now the development of micro-services based on SpringCloud is becoming increasingly popular, and various open source projects are emerging one after another on the Internet. There are a lot of things you can do out of the box with open source projects, but you have to follow certain conventions and specifications.

This paper combined with some of the problems we encountered in the actual development of a micro service development practices, welcome you to give advice.

Maven specification

  1. All projects must have a single parent module

    All microservice projects rely on this parent, which is used to manage the maintenance of dependency versions, Maven repositories, and JAR versions

    In the parent layer, there can be core, starter, rate-limit and other custom modules

  2. What the core package does:
  • Agreed various development specifications in POJO form; For example, BaseEntity, Unified Entry, Return
  • All kinds of two party, three party components out of the box with AUTOCONFIG;
  • All kinds of help classes to improve development efficiency

Note: ConditionalOnClass(Ribbon. Class), conditionalOnClass, conditionalOnClass, conditionalOnClass, conditionalOnClass, conditionalOnClass, conditionalOnClass, conditionalOnClass, conditionalOnClass, conditionalOnClass, conditionalOnClass. @ConditionalOnBean(StringRedisTemplete.class)

  1. The starter module

    If you need to rely on more than 10 starters per service, you can build a unified starter module to help them unify dependencies, manage dependencies and simplify dependencies

  2. Rate – limit module

    Used to place non-generic self – developed components

  3. Distinguish correctly between Release and Snapshot versions

    Note: If the Snapshot version is deployed, it will be automatically published to the Snapshot repository when MVN Deploy is deployed. When modules using the Snapshot version are compiled and packaged directly without changing the version number, Maven will automatically download the latest Snapshot version from the mirror server.

    If it is a Release version, it will be automatically released to the official library when MVN Deploy is deployed. If the official version of the module is used, without changing the version number, it will not be downloaded from the mirror server when it is compiled and packaged if the module already exists locally.

    In short:

    -Sheldon: You can no longer use this version number if there is a bug

    Snapshot: Snapshot version. If there are any bugs, you can continue to use the same version number. It can be automatically upgraded

Service Invoke Specification

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

The account-api module puts all the things that the consumer needs to use, such as API interfaces, VO, input parameters, etc…

public interface AccountApi {
    ...
}

The account-service implements the interface provided by the account-API

@RestController @log4j2@API (tags = "User Interface ") @RequiredArgconstructor (onConstructor = @__(@Autowired)) public class AccountController implements AccountApi { ... }
  1. The consumer invokes the producer via Feign, directly integrates the interface provided by the producer and handles the fuse
@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(" query failed, interface failed ",cause); AccountDTO account = new AccountDTO(); account.setAccountCode("000"); The setAccountName (Feign "test"); return ResultData.success(account); }}

RESTful design specifications

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

You can use the following two formats:

  1. / version/access control/domain object
  2. / version/access control/domain objects/actions

Domain objects need to conform to the following constraints:

  1. Domain objects use nouns instead of verbs
  2. Use the domain object name directly using /ticket instead of the plural /tickets
  3. Domain object relationships are expressed at a maximum of 2 levels, such as /ticket/12/message
  4. You need to properly distinguish the GET PUT POST DELETE request methods
  5. What cannot be expressed as a noun + request method can be extended to a/domain object/verb such as POST /user/login

Access control is carried out on the interface at the gateway layer, and the rules of access control are divided into:

All requests to PB-PUBLIC are accessible

Pt-protected requires token authentication before it can be accessed

PV-Private is not accessible through the gateway and can only be called inside the micro-service

DF-Default gateway requests token authentication, and requests parameters and returned results to be encrypted and decrypted

Version:

With micro service as the strength, the whole service is upgraded

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, then the entire microservice /v1 needs to be upgraded to /v2, while ensuring that older versions of the API that are compatible with the version are still accessible

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

POST /v1/pb/user is marked deprecated

POST /v2/pb/user

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

Code implementation:

  1. @getMapping (“/{version}/pb/user”) @getMapping (“/{version}/pb/user”)
  2. The POST method enforces the use of V1 and is marked deprecated, but still usable
@Deprecated
@PostMapping("/v1/pb/user")
  1. Post {version} should be the current version. It can only be v2
@PostMapping("/{version}/pb/user")

The gateway

  1. It can be realized by its own service instead of the micro-service authentication function (simple services can be directly authenticated at the gateway layer). The difference between the network authentication and micro-service authentication is detailed in my other articles, please refer to this article: http://t.hk.uy/2c3
  2. Need to achieve access control rights, combined with the above RESTful specification, shielding/pv/**Special request
  3. The server traffic needs to be imported into the local area when the development of the grayscale publishing function needs to be coordinated. The service instance can be filtered by combining the metadata of NACOS with the request header. Refer to this article for implementation: http://t.hk.uy/2c6

Asking for praise and attention:

Miaomiao Jam is an architect who writes code and a programmer who does architecture. His official account mainly shares articles on Java backend, SpringCloud micro-service architecture, database and other aspects. If you are interested in micro-service, I suggest you scan the QR code below and pay attention to it!