Realization of consumer gray scale

• Grayscale Publishing
• nepxion Implementation logic of synchronization
• Asynchronous implementation ideas
  • advantage
  • shortcoming
• Detail implementation

Grayscale Publishing

Grayscale publishing is also called Canary publishing , Allow some users to use the new functions after they are released , If the function is normal , Then switch to full users , At present, the most widely used in China is nepxion This framework

Our company is from 2019 The framework was introduced in , The most direct change is :

1. You don't have to stay up all night for the release of new features
2. The number of accidents due to the introduction of new functions has decreased significantly

However, the framework currently supports gray-scale publishing of synchronous scheduling , There is no gray scale for asynchronous consumption information , With the popularity of gray in the whole company , The demand for gray scale of consumers is becoming stronger and stronger

nepxion Implementation logic of synchronization

Firstly, the synchronous gray-scale scheduling is simply sorted out :

1. Premise of synchronous scheduling -- All services are registered in the same registry -- When registering a service, you can identify whether the current service is a grayscale instance or a normal instance , Such as eureka Allow custom extensions when registering a service metadata -- Whether it's RestTemplate still Feign, Must be scheduled by service name
2. Invoked procedure -- Service discovery allows instances to be aware of other instances registered in the registry , Include meta information of the instance -- adopt loadbalance Before the service is invoked, it will enter the top note interceptor. ,serviceName→ip:port There will be instances for filtering -- Return the service instance address corresponding to the service name , call http request

At present, the grayscale of consumers is not directly provided , Maybe the author is for commercial reasons , Or not satisfied with some existing schemes , Not meeting your expectations .

Asynchronous implementation ideas

1. Grayscale consumer Not with mq Establishing a connection , But it will expose a web Interface
2. Non grayscale instances will be associated with mq Establish a channel , Message consumption first goes through a layer of section , In the aspect, the message body will be judged , Indirect consumption , Gray level calls the of gray level instance web Interface

advantage

1. Simple
2. Can make full use of the logic of the original framework , If anything goes wrong with the original framework , Because the gray judgment is the same , Therefore, direct adaptation

shortcoming

1. mq Will achieve reliable delivery , however web There is no guarantee of reliable consumption
   • At present, the project is a platform product , So here comes the question , What kind of users will first bring grayscale ? The answer is unimportant , Therefore, because web The call caused the message to be lost ( The probability is very low ) Acceptable , Also made a log record

Detail implementation

Although the code has been written and has been used by some project teams , But as a company asset , Still don't provide code , Just a few details about the implementation

1. Grayscale instances expose a web Use it directly here springmvc Of handlerMapping Interface ( Actual reference spring-boot-actuator Part of the code ), Scan all @RabbitHandler; You can use the name of the queue as web Of url; The implementation will be simple , No changes need to be made in the code of the project
2. Consumers are forwarding web After the interface , Can send a successful / Failed Events , This avoids the problem that some projects think all messages cannot be lost
3. spring-rabbit Not found and mebmvc The same local thread variable holds the request , either webmvc So there's a preprocessing ( This is )+ Post processing ( This is not. ) This collocation , So here will be for the message sent , Define a data structure , Such as upstream header Equal gray dependent parameters are packed in . There will be some intrusion into the code . such as :

    /**
     *  The upstream request Of header Information 
     */
    private final Map<String, String> headers = new HashMap<>();
    /**
     *  Additional information 
     */
    private Map<String, Object> extraData;

    /**
     *  The information actually to be sent 
     */
    private T data;