# 2. Why do you want to be a mission center?

2.1 Starting point of the Task Center:

• A. User activation: improve user experience, increase customer activity, facilitate merchants to collect user information and improve their own information network.
• B. Improve retention: guide customers to participate in tasks every day, and improve user stickiness through membership system + bonus points growth value.
• C. Increase user repurchase and customer unit price: set purchasing tasks and privileges such as purchasing with points.
• D. The old bring the new: continue to bring the new through activities such as pulling new tasks or group tasks.

2.2 Objectives of the Mission Center:

• End B: visual task configuration center for merchants to facilitate the management and control of tasks.
• C end: the user receives the completed task, asynchronously or synchronously processes the completed task, and provides scheduled task and phase task.
• Access and user: fast visual access, simple task completion receipt.
• System itself: for new task access, scalability, try to ensure the minimum change of the main process.

Third, how did we achieve this?

3.1 Our technical solution

From the existing business system, we have separated the configuration center at the B end and the task processing center at the C end, and gathered some common system components, trying to achieve atomization of interfaces, choreography and cohesion of capabilities. In combination with the common tool JAR, business system access is fast enough; At the same time, the platform general configuration is set, and the dynamic loading configuration information based on Apollo is used to local cache, so that new tasks can be accessed quickly without publishing applications.

3.2 How to connect platforms, merchants and users?

Although Youzan is a saas company, the concept of internal platform, merchants and users is maintained. It can be said that the three complement each other and will not appear independently.

• 1. The platform can be quickly accessed through the background system to approve and implement the product configuration for students.
• 2. Merchants can quickly configure task information and reward on the page.
• 3. Provide business parties with a variety of quick access to tasks, universal task scheduling and universal reward issuing ability of merchant dimensions.

3.2 What other capabilities do we offer?

3.3 Common Status of tasks

The general and reasonable state flow can quickly locate and distinguish the task completion status of c-end users. The failed and terminated businesses can rely on scheduled tasks to complete the task replay, quickly push to the end, and issue rewards, so as to avoid the problem of unsynchronization of reward information brought to users by abnormalities, and ensure the consistency within the system.

What are the core technical components we use

4.1 Idempotent control components

4.1.1 Why idempotent Components

In the landing of the task center, many scenarios need to control the unique idempotence of the task, and multiple releases will not be reissued. Previously, we mainly inserted the business unique index through the DB idempotent table to ensure idempotent, but the transaction guarantee of the database is required, that is, the idempotent stream and the business should be committed together, and the failure will be rolled back. When multi-library scenarios are used, each library of the business system needs to add a flow table and control the consistency of the business ID and fragment ID in the shard, which is tedious.

Other internal systems use distributed storage, such as Redis, to keep records of business requests. After receiving the request, the server uses atomic query and save operations (such as the setnx command of Redis) to ensure that the unique flow of business falls into storage, and controls the idempotency of the flow until the timeout period set by the business. When repeated flow is found, follow a strategy to return.

When the mission center system lands, both modes are retained, and the scalability and fast access of the storage that the access party depends on should be considered.

4.1.2 Rules for idempotent components

• Idempotent concatenation of idempotent input parameter information using supported annotations for fast access to +spEL expressions.
• Dynamic configuration push based on Apollo.
• Idempotent storage strategy:
  • 1. Cache redis storage (preferred) 2. Mysql storage etc
• Idempotent rejection strategy:
  • Returns the same result multiple times. Returns an idempotent code. Throws an exception

4.1.3 Design of idempotent components

Through the basic tool JAR package, bearing the whole idempotent component logic, to achieve the purpose of fast access. Through Apollo, relevant configuration can be dynamically pushed to achieve fast branch switching of business system, and online emergency at any time.

4.2 Integrates a common cache capability process choreography component

Because of multiple tasks, many of the underlying component capabilities can be reused directly. Many tasks have the same logic, in order to achieve the purpose of rapid access of new tasks without repeated development.

We developed a set of configuration flow choreography engine based on DB + XML, which can quickly choreograph existing logic and reduce repetitive development work.

Choreography also provides basic capabilities:

• 1. Continue to develop a dynamic template loading mechanism based on hot loading. Further increase the dynamic configurable capability of the process.
• 2. At the same time, in the general template, the cache general logic and hotspot cache functions are realized, which can be stably supported by the task center when promoting or merchants have marketing activities.

4.3 Dynamically Configuring Components

Much of the basic configuration is done through dependency profiles, or dynamic configuration at Apollo.

However, both methods have their advantages and disadvantages. In configuration file mode, although the storage capacity is not limited, applications need to be restarted after configuration changes, which is complicated. The way Apollo switches on and off can be changed dynamically, but the configuration information stored is limited to a certain length. For the multi-task platform configuration of the task center, there is a certain impact.

So we ended up using a delayed loading strategy based on JVM + Apollo, which ensures less frequent releases and the ability to change configuration information dynamically.

4.4 Independent Asynchronous Flow Logging

Traditional synchronization logging consumes system resources, and due to the characteristics of the task center, there is a lot of information about the task completion flow on the C side. Therefore, asynchronous flow events are converted into logs when the task center lands. An independent log system provides universal capabilities such as log collection, uploading, visualization, and retrieval.

5. In the future, we are still forging ahead.

In line with the principle of visualization, configuration, in order to make peripheral access easier, while reducing the principle of internal development. Next, we will continue to improve the system:

• 1. Productization of task Center operation and maintenance (under construction) : a set of product-layer applications independently developed, using visual page background management. Convenient service access and routine operation and maintenance. You can complete the configuration and online operation independently on the page.
• 2. Extension point + process co-construction based on callback and configuration (under construction) : Through extension point co-construction, the ability of process choreography is exposed to internal and external developers to complete the co-construction of task center.