You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@rocketmq.apache.org by "Jason.Chen" <ch...@foxmail.com> on 2022/03/16 13:32:19 UTC
回复： [DISCUSS] RIP-35 queue service framework(QSF)
sure:)
Taking a real business system (label system) as an example, when a label object is changed in the label system, an event notification needs to be initiated to inform the label search system of the change information, so that the label search system can update the search index.
This is a classic weak dependency that requires message decoupling. Using the classic solution, we need to write code to manage the mq infrastructure, assemble change objects, and send change messages on the message sender side; on the message receiver side, we also need to write code to parse the change objects and process the change messages. If you need features like extactly once consuming, it's even more cumbersome, and inevitably couples infrastructure management code and business code.
With QSF, we only need to declare the business interface and implement business logic, and annotate the interface implementation class with @QSFProvider, and annotate @QSFConsumer at the interface reference. A mq-based cross-system asynchronous call can be done like a local method call, like this:
// LabelService.java
public interface LabelService {
void labelModified(LabelInfoDTO labelDTO);
}
// LabelServiceImpl.java
@QSFProvider(topic = "topic_label", consumerId = "cid_topic_label", tags = "label_modified")
@Slf4j
public class LabelServiceImpl implements LabelService {
@Override
public void labelModified(LabelInfoDTO labelDTO) {
//business logic
}
}
//LabelManager.java
@QSFConsumer(topic = "topic_label", tag = "label_modified")
private LabelService labelService;
public boolean updateLable(LabelInfoDTO labelDTO){
// main process:update label logic
...
...
// edge process:inform label modified
labelService.labelModified(labelDTO);
}
------------------ 原始邮件 ------------------
发件人: "dev" <yukon@apache.org>;
发送时间: 2022年3月16日(星期三) 晚上8:23
收件人: "dev"<dev@rocketmq.apache.org>;
主题: Re: [DISCUSS] RIP-35 queue service framework(QSF)
Could you please provide some demos to show how we use QSFProducer/Consumer?
On Wed, Mar 16, 2022 at 6:49 PM Jason.Chen <chenhuanzu@foxmail.com> wrote:
> I am sorry that the RIP mail format is incorrect, and i write a
> well-formed google doc version here:
>
>
> https://docs.google.com/document/d/10wSe24TAls7J9y0Ql4MYo73FX8g1aX9guoxBxzQhJgg
>
>
>
>
>
>
> RIP 35 queue service framework(QSF)
>
> Status
>
> ●&nbsp; Current State: Proposed
>
> ●&nbsp; Authors: booom( booom (jason) · GitHub)
>
> ●&nbsp; Shepherds: yukon( zhouxinyu (yukon) · GitHub)
>
> ●&nbsp; Mailing List discussion: dev@rocketmq.apache.org
>
> ●&nbsp; Pull Request:
>
> ●&nbsp; Released:&nbsp;
>
> Background &amp; Motivation
>
> What do we need to do
>
> ●&nbsp; Will we add a new module? Yes.
>
> ●&nbsp; Will we add new APIs? No.
>
> ●&nbsp; Will we add new feature? Yes.
>
> Why should we do that
>
> ●&nbsp; Are there any problems of our current project?
>
> The current mq client API is intrusive, to send message or consume
> message, we should code to manage the mq infrastructure, and mixed it up
> with our business logic codes.
>
> ●&nbsp; What can we benefit proposed changes?
>
> 1. Encapsulate mq client API to support method invoking style usage.
>
> 2. The encapsulation is easily extensible, to support
> idempotence/eventually consistent/ fluid control extensions and so on.
>
> 3. Isolate the mq client manage code and the business logic code, to
> help mq users improve their systems’ maintainability.
>
> Goals
>
> ●&nbsp; What problem is this proposal designed to solve?
>
> Unobtrusive mq client usage, and easily extensible to support
> idempotence/eventually consistent/ fluid control extensions and so on.
>
> ●&nbsp; To what degree should we solve the problem?
>
> 100%.
>
> Non-Goals
>
> ●&nbsp; What problem is this proposal NOT designed to solve?
>
> 1. Add new features to classics mq client.
>
> 2. Affect compatibility.
>
> ●&nbsp; Are there any limits of this proposal?
>
> Only QSF(queue service framework) users will benefit.
>
> Changes
>
> Architecture
>
> To simplify a process, we need to consider what information is essential
> and must be provided by users to execute this process? How to properly
> organize this information so that it is most user-friendly?&nbsp;
>
>
> Along this thinking path, we have extracted the necessary parameters for
> mq calls and organized them into the java annotations @QSFConsumer and
> @QSFProvider. After that, through the extension support of spring container
> in each stage of bean life cycle, we can process @QSFConsumer @QSFProvider
> annotation in BeanPostProcessor, extract method invocation information to
> method invocation information object MethodInvokeInfo and send it out, and
> locate it through MethodInvokeInfo at the message receiving endpoint. The
> bean where the call is made, the method where it is located, the parameters
> used, and then the method is called by reflection.
>
>
>
>
>
> Interface Design/Change
>
> ●&nbsp; Method signature changes
>
> ○&nbsp; &nbsp; &nbsp; method name
>
> ○&nbsp; &nbsp; &nbsp; parameter list
>
> ○&nbsp; &nbsp; &nbsp; return value
>
> Nothing.
>
> ●&nbsp; Method behavior changes
>
> Nothing.
>
> ●&nbsp; CLI command changes
>
> Nothing.
>
> ●&nbsp; Log format or content changes
>
> Nothing.
>
> &nbsp;Compatibility, Deprecation, and Migration Plan
>
> ●&nbsp; Are backward and forward compatibility taken into
> consideration?
>
> Yes.
>
> ●&nbsp; Are there deprecated APIs?
>
> Nothing.
>
> ●&nbsp; How do we do migration?
>
> Upgrade normally, no additional migration required.
>
> Implementation Outline
>
> We will implement the proposed changes by 1 phase. (QSF is implemented and
> works well in our project)
>
> Phase 1
>
>
> Complete the QSF mq client encapsulation.
>
>
>
> Complete the QSF idempotency support
>
>
> Rejected Alternatives
>
> There are no other alternatives.
>
>
>
>
>
>
>
> ------------------&nbsp;原始邮件&nbsp;------------------
> 发件人:
> "Jason.Chen"
> <
> chenhuanzu@foxmail.com&gt;;
> 发送时间:&nbsp;2022年3月16日(星期三) 中午12:55
> 收件人:&nbsp;"dev"<dev@rocketmq.apache.org&gt;;
>
> 主题:&nbsp;[DISCUSS] RIP-35 queue service framework(QSF)
>
>
>
>
>
>
>
> Status
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Current State: Proposed
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Authors: booom( booom (jason) · GitHub)
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Shepherds: yukon( zhouxinyu (yukon) · GitHub)
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Mailing List discussion:
> dev@rocketmq.apache.org
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Pull Request:
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Released: <relased_version&gt;
>
> Background &amp; Motivation
>
> What do we need to do
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Will we add a new module? Yes.
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Will we add new APIs? No.
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Will we add new feature? Yes.
>
> Why should we do that
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Are there any problems of our current project?
>
> The current mq client API is intrusive, to send message or consume
> message, we should code to manage the mq infrastructure, and mixed it up
> with our business logic codes.
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; What can we benefit proposed changes?
>
> 1.&nbsp;&nbsp; &nbsp; Encapsulate mq client API to support method invoking
> style usage.
>
> 2.&nbsp;&nbsp; &nbsp; The encapsulation is easily extensible, to support
> idempotence/eventually consistent/ fluid control extensions and so on.
>
> 3.&nbsp;&nbsp; &nbsp; Isolate the mq client manage code and the business
> logic code, to help mq users improve their systems’ maintainability.
>
> &nbsp;
>
> Goals
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; What problem is this proposal designed to solve?
>
> Unobtrusive mq client usage, and easily extensible to support
> idempotence/eventually consistent/ fluid control extensions and so on.
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; To what degree should we solve the problem?
>
> 100%.
>
> Non-Goals
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; What problem is this proposal NOT designed to
> solve?
>
> 1.&nbsp;&nbsp; &nbsp; Add new features to classics mq client.
>
> 2.&nbsp;&nbsp; &nbsp; Affect compatibility.
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Are there any limits of this proposal?
>
> Only QSF(queue service framework) users will benefit.
>
> Changes
>
> Architecture
>
> Interface Design/Change
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Method signature changes
>
> ○&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; method name
>
> ○&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; parameter list
>
> ○&nbsp;&nbsp;&nbsp; &nbsp; &nbsp;&nbsp;&nbsp; return value
>
> Nothing.
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Method behavior changes
>
> Nothing.
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; CLI command changes
>
> Nothing.
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Log format or content changes
>
> Nothing.
>
> &nbsp;Compatibility, Deprecation, and Migration Plan
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Are backward and forward compatibility taken
> into consideration?
>
> Yes.
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; Are there deprecated APIs?
>
> Nothing.
>
> ●&nbsp;&nbsp;&nbsp; &nbsp; How do we do migration?
>
> Upgrade normally, no additional migration required.
>
> Implementation Outline
>
> We will implement the proposed changes by 1 phase. (QSF is implemented and
> works well in our project)
>
> Phase 1
>
> Complete the QSF mq client encapsulation.
>
> Complete the QSF idempotency support
>
> Rejected Alternatives
>
> There are no other alternatives.