syhleo commented on PR #8469:
URL: https://github.com/apache/rocketmq/pull/8469#issuecomment-2290953556

   > very nice to see gray solution, and i sort some cases that mq's users can 
be met, if meet, how to solve or extend those cases? case 1: producers are all 
gray, consumers are all gray case 5: producers are both gray and normal, 
consumers are all gray others do same up.
   > 
   > 
![image](https://private-user-images.githubusercontent.com/5908412/357816825-b4572c4b-2152-47b4-8938-94438a773aad.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjM3MTI0MDUsIm5iZiI6MTcyMzcxMjEwNSwicGF0aCI6Ii81OTA4NDEyLzM1NzgxNjgyNS1iNDU3MmM0Yi0yMTUyLTQ3YjQtODkzOC05NDQzOGE3NzNhYWQucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDgxNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA4MTVUMDg1NTA1WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9YzIzOWVjZDY2YjYxMTQ0NGI3OWZjOWY5Y2NmMGIzY2Y1MThjOWZjNzg2MjE3NTc2ZWJiNTg2MDQ0M2U2YzJkYiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.gihI8KAr7kHaIzMF8U_SVWJjTBvUXfk2SvVag1zM4xE)
   
   ![MQ灰度 
(2)](https://github.com/user-attachments/assets/1af05505-57d2-4dff-8fd5-2ece2eb3efd6)
   
   
![灰度_正常生命周期管理](https://github.com/user-attachments/assets/a416ddc7-1362-4a5d-a082-96be3feee6f8)
   
   Share the link
   
https://www.processon.com/view/link/66bdc5020ee74e516c89def5?cid=66bd5df5fb35b76d02da1e4c
   
https://www.processon.com/view/link/66bdc5252515964e0bbc2f63?cid=66bda70c0ee74e516c898985
   
   Case Scenario Description:
   In practice, the whole link gray-scale release scenario, almost all the 
services issued version will be strictly first go gray-scale release, verify ok 
and then online.
   1, environment division and gray-scale release: in the daily development 
process, will be divided into dev/test/stage/prod and other environments, test 
environment will be due to a variety of project branches and so on, derived 
from testA, testB, testC and other project environments. We can decide whether 
to add a new topic/group with a “grayscale” logo according to the actual needs 
of each environment, so as to realize the grayscale capability. However, when 
the business scale is large, this approach may cause two problems: first, the 
criticality problem, i.e., when the grayscale validation passes and switches to 
prod (e.g., the pod of the grayscale service is taken offline normally), the 
grayscale messages may be consumed by omission, which is unacceptable; and 
second, the cost problem, since doubling of each topic and group will bring 
significant cost overheads.
   For specific environments, complete isolation by adding new topics/groups 
and combining the ability to partition grayscale during grayscale in online 
environments are never in conflict and are complementary to each other.
   2, the gray-scale partitioning used in this program is, more often than not, 
by not adding a new topic/group, quasi-environment-specific (eg: prod 
environment) for gray-scale release, you can make MQ low-cost, convenient way 
to also have the ability to gray-scale. (ps: full-link grayscale scenario, 
http, gRPC and other interface calls can be gray-scale traffic forwarding, mq 
also need to have ...)
   This design ensures that each environment can perform grayscale publishing 
in an orderly and independent manner.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to